Мужики помогите старому программеру. Лет 8 ничего не писал, ASM знаю хорошо, но под виндой никада не писал. Может кто на пальцах расскажет. Проблема такая: нужно перехватывать все открываемые файлы в формате JPG и писать их в какуюнить директорию. Система WINXP. Покопался по нету, почитал про хуки, но так до конца и не понял работает-ли это под XP. Кому не в лом расскажите, плиз!

К сожалению, придется писАть драйвер-фильтр файловой системы. Примеры есть в DDK.

хуки тут не помогут, увы.
посмотри как работуют антивирусные мониторы, которые проверяют файлы при их открытии (смотреть понятное дело нужно драйвер, который кстати говоря, будет очень легко доработать для твоих нужд, достаточно лишь вставить код проверки а jpg ли это и если да, то копируем его куда макр телят не гонял).
можно так же модифицировать экспорт KERNEL32.DLL - функцию CreateFile, она у всех процессов отобажается по одному и тому же адресу, но делать это нужно из ядра, т.к. NT поддерживает копирование при записи и если ты смодифицируешь ее с прикладного уровня, то она просто ращепится и все).

Заметка: не все то открытия файлов с водятся к CreateFile. Испробовал,т.к. такое уже написал. Куча прог ломется и ч/з OpenFile. Стыдно, что на смотрел на коды CreateFile и OpenFile - может как и связаны. Самое надежное - это Io-версия - она всесильна. А реальный пример незатрагивание CreateFile - это запустить DOS ч/з эмулятор и там всё покатит ч/з OpenFile.

На васме есть исходник утилиты Руссиновича - filemon .

> Заметка: не все то открытия файлов с водятся к CreateFile.
из нормальных - все, ну хорошо, NtCreateFile/ZwCreateFile

> Стыдно, что на смотрел на коды CreateFile и OpenFile - может как и связаны.
если мне не изменяет память, OpenFile это "обертка" вокруг CreateFile, оставленная для совместимости с 16-битным ПО от win 3.1, хотя может сейчас она стучиться прямо в NTDLL
ну хорошо, тогда надо падчить импорт NTDLL

> На васме есть исходник утилиты Руссиновича - filemon .
filemon перехватывает IRP-запросы, а это можно делать только с уровня драйверов

Так же можно падчить Int 2Eh, а точнее тот самый адрес в таблице сервисов. Правда погеморнее будет, т.к. у разных wind-ов они разные.
А про поводу NtCreateFile/ZwCreateFile, то лучше, конечно, NtCreateFile, т.к. в него уходит ZwCreateFile. А самое надежное, повторюся, IoCreateFile.

Но это уже смешно, т.к. надо было перехватить какой-то jpeg а мы тут накушаемся стока гадости... Эти ф-ии с огромной частотой используют. Взяли да в ядро залезли...

Может легче пропадчить какую-либо прогу, которая является потенциальнам просмоторщиком этих файлов, библиотеки её и т.д. Ведь половина из них используют стандартные библиотеки. В реестре можно посмотреть на крайняк, кто открывает соответствующее расширение. Ну и ... её.

> А самое надежное, повторюся, IoCreateFile.
это факт, т.к. NtCreateFile является оччень тонкой прослойкой вокруг IoCreateFile, но IoCreateFile не экспоритируется NTDLL и через 2E недоступна, так что я не вижу смысла торогать ее. мы же не с драйверами воевать собрались, надеюсь ;)

> т.к. в него уходит ZwCreateFile
NtCreateFile и ZwCreateFile ссылаются на одну функу, но перехватывать надо обе, т.к. заранее не известно, что будет вызвано

> Эти ф-ии с огромной частотой используют. Взяли да в ядро залезли...
да, так и до глюкодрома недалеко

> В реестре можно посмотреть на крайняк, кто открывает соответствующее расширение. Ну и ... её.
помню, что в реестре есть ключ, перечисляющий библиотеки, загружающиеся автоматом, не сейчас не помню какой, так вот если в него дописать нашу dll, тогда из dllmain можно будет падчить непосредственно импорт всех запускаемых файлов, правда тут есть одно "но", - а что программа вызывает библиотеку (типа mfc), руками которой и отркывает файл? тогда в импорте createfile уже не окажется, а поддерживать все библиотеки - лениво.

с другой стороны, если стоит задача _глобального_ перехвата всех открываемых файолов, то красивых решений нет и не будет, т.к. перехватчик должен быть глобальным.

ren5
Кароче, открываешь книжку Свена Шрайбера "Недокументированные возможности Windows 2000". И, там есть пример драйвера-фильтра. В принципе, для файлов тебе достаточно перехватить Native API, подправив адреса соответствующих точек обработчиков в таблице SDT на свои обработчики. Не знаю, для чего конкретно тебе это нужно, может быть, тебе придётся писать фильтр над FS драйвером, но, допустим мне, что бы сифровать расшифровывать на лету ввод вывод в определённый файл от конкретного приложения хватили именно этого....


NtCreateFile и ZwCreateFile ссылаются на одну функу, но перехватывать надо обе, т.к. заранее не известно, что будет вызвано

ссылаются в NTDLL.DLL а что нам там делать ??? в NTOSKRNL это совершенно разные точки... ZW проходят через SDT и кучу фильтров и проверок, ну а NT фтыкаютца конкретно в код. А так как если перехват осуществлять преимущественно от приложения , а не от всей системы, то вызовы пройдут через шлюз системного сервиса в любом случае, ну , а там SDT. Ну и тыкать туда наши обработчики.. блин, наскока я помню, писал то давно уже.....


помню, что в реестре есть ключ, перечисляющий библиотеки, загружающиеся автоматом, не сейчас не помню какой, так вот если в него дописать нашу dll, тогда из dllmain можно будет падчить непосредственно импорт всех запускаемых файлов, правда тут есть одно "но", - а что программа вызывает библиотеку (типа mfc), руками которой и отркывает файл? тогда в импорте createfile уже не окажется, а поддерживать все библиотеки - лениво.


да, есть такой ключик, работает тока под NT, что нам и нужна, в принципе. Описана у Рихтера. Фчера перечитывал. Тока, нафига нам нужен этот механизм то ?


ren5
и последнее, вряд ли ядро, хихи, блин, без запроса от приложения, будет открывать .jpg. Вот своп, другое дело, а поскольку jpg не своп, то сам знаешь как поступить.

"...каждому MS Office по свопу !!!" ГЫЫЫЫЫЫЫЫЫЫЫЫ !!


если мне не изменяет память, OpenFile это "обертка" вокруг CreateFile, оставленная для совместимости с 16-битным ПО от win 3.1, хотя может сейчас она стучиться прямо в NTDLL
ну хорошо, тогда надо падчить импорт NTDLL


интересно, а шо же есть ntCreateFile и ntOpenFile в NTOSKRNL ? как то я пытался найти взаимосвязь между ними в виде общей функции... нифига не нашёл. Хотя , не спорю, может был не внимателен.

Мужики, спасибо всем, щас буду копать документацию

"если мне не изменяет память, OpenFile это "обертка" вокруг CreateFile"

NTSTATUS
NtOpenFile(
OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN ULONG ShareAccess,
IN ULONG OpenOptions
)

...

return IoCreateFile( FileHandle,
DesiredAccess,
ObjectAttributes,
IoStatusBlock,
(PLARGE_INTEGER) NULL,
0L,
ShareAccess,
FILE_OPEN,
OpenOptions,
(PVOID) NULL,
0L,
CreateFileTypeNone,
(PVOID) NULL,
0 );
}

----------------------/////\\\\\--------------------
NTSTATUS
NtCreateFile(
OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN PLARGE_INTEGER AllocationSize OPTIONAL,
IN ULONG FileAttributes,
IN ULONG ShareAccess,
IN ULONG CreateDisposition,
IN ULONG CreateOptions,
IN PVOID EaBuffer OPTIONAL,
IN ULONG EaLength
)

...

return IoCreateFile( FileHandle,
DesiredAccess,
ObjectAttributes,
IoStatusBlock,
AllocationSize,
FileAttributes,
ShareAccess,
CreateDisposition,
CreateOptions,
EaBuffer,
EaLength,
CreateFileTypeNone,
(PVOID)NULL,
0 );
}

До этого этапа OpenFile и CreateFile идут порознь и встречаются только в IoCreateFile.

З.Ы. Только для уточнения. Не в укор!