поискал по Инету и Тут, быстро найти не удалось — на такой вопрос:
Как с помощью Win Api поймать ивент на событие CopyFile, Rename...?
Вернее, я хочу отловить событие на создании файла, НЕ проверка на уже созданном?
Проверить нужно только по имени. Также подлежат отлову Rename, Delate.
Like action before...
Спасибо
Re: Как с помощью Win Api поймать ивент на событие CopyFile
Здравствуйте, x64, Вы писали:
GK>>Как с помощью Win Api поймать ивент на событие CopyFile, Rename...?
x64>Писать драйвер файловый фильтр. Тебе сюда или сюда, затем сюда.
У тебя, я смотрю, на все проблемы решение — написать драйвер
С помощью Win Api это делается глобальным перехватом вызова функций CopyFile, Rename. Внедряемся в чужой процесс, перебираем все модули, прицепленные к нему, у них в таблице импорта меняем указатели CopyFile, Rename на свои.
Подробная статья была на rsdn вроде тут
Re[3]: Как с помощью Win Api поймать ивент на событие CopyFi
CEM>У тебя, я смотрю, на все проблемы решение — написать драйвер
Ты не прав, я не сторонник решений "из пушки по воробьям". И в данном случае это единственное грамотное решение. Лучше не спорь, бесполезно.
CEM>С помощью Win Api это делается глобальным перехватом вызова функций CopyFile, Rename. Внедряемся в чужой процесс, перебираем все модули, прицепленные к нему, у них в таблице импорта меняем указатели CopyFile, Rename на свои.
Хуки это, строго говоря, недокументированный метод. Не следует использовать их без крайней нужды. Я допускаю, что крайняя нужда имеет место быть в данном случае, но из первого сообщения автора этого не следует.
Re[3]: Как с помощью Win Api поймать ивент на событие CopyFi
Здравствуйте, CEMb, Вы писали:
CEM>С помощью Win Api это делается глобальным перехватом вызова функций CopyFile, Rename. Внедряемся в чужой процесс, перебираем все модули, прицепленные к нему, у них в таблице импорта меняем указатели CopyFile, Rename на свои.
Хуки это ещё хуже (в порядке убывания важности):
1) ошибка в фильтре не менее (а даже более) фатальна. Хинт: при ошибке в драйвере получишь BSOD, фильтр же может безнаказанно портить работу системы сколь угодно долго.
2) такой фильтр не выгрузить.
3) целостность UM процессов. Любая нормальная проактивная защита мигом пометит все хукнутые процессы как изменившиеся. Отрубит им сеть и напугает пользователя шквалом запросов (вполне обосновано, кстати).
4) на x64 системах 32битный фильтр идёт лесом, придётся писать две штуки, и ставить их ОБЕ в систему.
5) сложнее делать передачу данных между экземплярами фильтра.
kalsarikännit
Re[4]: Как с помощью Win Api поймать ивент на событие CopyFi
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, CEMb, Вы писали:
CEM>>С помощью Win Api это делается глобальным перехватом вызова функций CopyFile, Rename. Внедряемся в чужой процесс, перебираем все модули, прицепленные к нему, у них в таблице импорта меняем указатели CopyFile, Rename на свои.
IID>Хуки это ещё хуже (в порядке убывания важности): IID>1) ошибка в фильтре не менее (а даже более) фатальна. Хинт: при ошибке в драйвере получишь BSOD, фильтр же может безнаказанно портить работу системы сколь угодно долго. IID>2) такой фильтр не выгрузить. IID>3) целостность UM процессов. Любая нормальная проактивная защита мигом пометит все хукнутые процессы как изменившиеся. Отрубит им сеть и напугает пользователя шквалом запросов (вполне обосновано, кстати). IID>4) на x64 системах 32битный фильтр идёт лесом, придётся писать две штуки, и ставить их ОБЕ в систему. IID>5) сложнее делать передачу данных между экземплярами фильтра.
Ещё важную штуку забыл
— хуки придётся ставить на ntdll.dll, иначе часть вызовов пропустишь.
— создание файлов драйверами не перехватишь.
— вредный процесс может вызвать шлюз ядра вообще напрямую. И будет UM фильтр грустно по... покуривать в сторонке.
kalsarikännit
Re[4]: Как с помощью Win Api поймать ивент на событие CopyFi
Здравствуйте, x64, IID, Вы писали:
CEM>>У тебя, я смотрю, на все проблемы решение — написать драйвер
x64>Ты не прав, я не сторонник решений "из пушки по воробьям". И в данном случае это единственное грамотное решение.
Конечно, писать и ставить драйвер на машину только из-за отлова пары вызовов — это не "из пушки по воробьям".
x64>Хуки это, строго говоря, недокументированный метод. Не следует использовать их без крайней нужды. Я допускаю, что крайняя нужда имеет место быть в данном случае, но из первого сообщения автора этого не следует.
1. Я про хуки не говорил.
2. Хуки — в msdn описаны подробно.
0. Согласен, хуки — это крайний метод. Но драйвер под эту задачу писать... это слишком.
IID>— хуки придётся ставить на ntdll.dll, иначе часть вызовов пропустишь. IID>— создание файлов драйверами не перехватишь. IID>— вредный процесс может вызвать шлюз ядра вообще напрямую. И будет UM фильтр грустно по... покуривать в сторонке.
У человека вопрос был — перехватить пару конкретных вызовов, а не написать мега-монитор файлов
Я предложил и дал ссылку на самое простое решение в 15 строчек, реализуемое в одном проекте.
Re[5]: Как с помощью Win Api поймать ивент на событие CopyFi
Я же предупреждал — не надо спорить...
CEM>Конечно, писать и ставить драйвер на машину только из-за отлова пары вызовов — это не "из пушки по воробьям".
Именно так, когда заходит речь о файловой (и не только) фильтрации, то здесь простых решений не бывает, запомните это. Это не "как два пальца...", далеко не так...
CEM>1. Я про хуки не говорил.
А, это мне значит показалось...
CEM>2. Хуки — в msdn описаны подробно.
Да-а-а?? Ну найдёшь — я тебе оценку поставлю.
CEM>0. Согласен, хуки — это крайний метод. Но драйвер под эту задачу писать... это слишком.
По твоей логике получается, что автору можно сразу убиться об стенку, ибо кроме хуков и фильтров других решений просто нет.
CEM>У человека вопрос был — перехватить пару конкретных вызовов, а не написать мега-монитор файлов CEM>Я предложил и дал ссылку на самое простое решение в 15 строчек, реализуемое в одном проекте.
Ещё раз: простых решений здесь не бывает, надёжность предложенного тобой решения равна чуть более чем нулю.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, CEMb, Вы писали:
CEM>>С помощью Win Api это делается глобальным перехватом вызова функций CopyFile, Rename. Внедряемся в чужой процесс, перебираем все модули, прицепленные к нему, у них в таблице импорта меняем указатели CopyFile, Rename на свои.
IID>Хуки это ещё хуже (в порядке убывания важности): IID>1) ошибка в фильтре не менее (а даже более) фатальна. Хинт: при ошибке в драйвере получишь BSOD, фильтр же может безнаказанно портить работу системы сколь угодно долго. IID>2) такой фильтр не выгрузить. IID>3) целостность UM процессов. Любая нормальная проактивная защита мигом пометит все хукнутые процессы как изменившиеся. Отрубит им сеть и напугает пользователя шквалом запросов (вполне обосновано, кстати). IID>4) на x64 системах 32битный фильтр идёт лесом, придётся писать две штуки, и ставить их ОБЕ в систему. IID>5) сложнее делать передачу данных между экземплярами фильтра.
Спасибо за участие! Очень полезный спор!
Можно конечно перебором по всем Окнам и хыкать. Вот если файл пишется по сети?
Из того что я "нарыл" в инете, предлагают пользовать ЭТО.
Здравствуйте, x64, Вы писали:
x64>А вообще, если сверхвысокая точность не нужна, и чтобы без наворотов, тогда посмотри вот эти две:
x64>FindFirstChangeNotification() x64>ReadDirectoryChangesW()
Уведомлялки работают на уже пройденные события.
Мне желательно не дать записать файл если он не соответсвует Маске
Спасибо за участие! Очень полезный спор!
Можно конечно перебором по всем Окнам и хыкать. Вот если файл пишется по сети?
Из того что я "нарыл" в инете, предлагают пользовать ЭТО.
Здравствуйте, rus blood, Вы писали:
RB>Здравствуйте, gorr.ka, Вы писали:
GK>>Можно конечно перебором по всем Окнам и хыкать. Вот если файл пишется по сети?
RB>А при чем тут Окна? RB>CEMЬ говорил не про хуки на окна...
GK>>Кто нибудь с таким монстром пробовал хукать?
RB>Не надо тебе это делать. Нотификации, которые ты хочешь, в WinAPI не предусмотрены, а API-хуки или, тем более, драйвера, ты сейчас не потянешь.
RB>Может, ты просто опишешь, зачем тебе это нужно? RB>Может тогда тебе предложат более простое решение...
Задание:
На заданную папку поставить фильтр по маске на имена файлов:
— на запись
— переименование
Отлавливаться события должны ДО совершения оного события,
тоесть при пробе записать файл, проверить на соответствие по маске, и по результату разрешить или отвергнуть. То же и с переименованием.
Те же правила на Папки.
GK>Задание: GK>На заданную папку поставить фильтр по маске на имена файлов: GK>- на запись GK>- переименование GK>Отлавливаться события должны ДО совершения оного события, GK>тоесть при пробе записать файл, проверить на соответствие по маске, и по результату разрешить или отвергнуть. То же и с переименованием. GK>Те же правила на Папки.
Ещё раз: драйвер файловый фильтр. Сколько раз написать надо, чтобы дошло?
Здравствуйте, gorr.ka, Вы писали:
GK>Задание:
GK>На заданную папку поставить фильтр по маске на имена файлов: GK>- на запись GK>- переименование
GK>Отлавливаться события должны ДО совершения оного события, GK>тоесть при пробе записать файл, проверить на соответствие по маске, и по результату разрешить или отвергнуть. То же и с переименованием. GK>Те же правила на Папки.
А откуда такие требования?
Ты воюешь с пользователями или другими программами?
Что будет, если будет создан файл, имя которого не соответствует маске?
Это нужно для твоей программы или для какой-то другой?
Здравствуйте, gorr.ka, Вы писали:
GK>Задание:
GK>На заданную папку поставить фильтр по маске на имена файлов: GK>- на запись GK>- переименование
GK>Отлавливаться события должны ДО совершения оного события, GK>тоесть при пробе записать файл, проверить на соответствие по маске, и по результату разрешить или отвергнуть. То же и с переименованием. GK>Те же правила на Папки.
Здравствуйте, x64, Вы писали:
x64>Я же предупреждал — не надо спорить...
Ок, я почитаю те три линка про драйвера
CEM>>2. Хуки — в msdn описаны подробно.
x64>Да-а-а?? Ну найдёшь — я тебе оценку поставлю.
SetWindowsHookEx
CEM>>0. Согласен, хуки — это крайний метод. Но драйвер под эту задачу писать... это слишком.
x64>По твоей логике получается, что автору можно сразу убиться об стенку, ибо кроме хуков и фильтров других решений просто нет.
Не, я имел ввиду, что хуки — это крайний метод вообще, а не в данной задаче.
CEM>>У человека вопрос был — перехватить пару конкретных вызовов, а не написать мега-монитор файлов CEM>>Я предложил и дал ссылку на самое простое решение в 15 строчек, реализуемое в одном проекте.
x64>Ещё раз: простых решений здесь не бывает, надёжность предложенного тобой решения равна чуть более чем нулю.
Ок, ладно, соглашусь. Системные процессы не дадут в себя код встроить просто так.
