Помоги решить проблему, горю. Необходимо отследить запись на диск файла из досовской программы и проанализировать этот файл. Написал драйвер, поставил хук на ZwWriteFile. Запись через эту функцию не проходит, т.е. файл создается обычным ZwCreateFile, закрывается ZwClose, но пишется через что-то другое. Есть подозрение на ZwVDMControl. У кого есть какие мысли поделитесь, если не трудно. Спасибо. P.S. Система WinXP.

Почему не просто перехват int 21h ?

Потому что программа работает в Windows XP, под NTVDM. Перехват int 21h насколько я помню можно было делать в чистом DOSe. Или может я что то не знаю?

Единственное что нашел в инете - прототип этой функции: ZwVdmControl performs a control operation on a VDM.
NTSYSAPI
NTSTATUS
NTAPI
ZwVdmControl(
IN ULONG ControlCode,
IN PVOID ControlData
);
т.е. вероятно, в зависимости от ControlCode выполняется определенная операция (м/б и запись на диск файла)...
Я все еще горю, приз хелп!!

>Почему не просто перехват int 21h ?
А разве файл только так можно создать?

Если дела так пошли, то мож стоит перехватывать IRP ? Приаттачся к девайсу и получай чё надо.

А NtWriteFile или ещё чё пробывал? Это имеет смысл, т.к. хук на zwcreatefile для NTVDM не катит - она обращается к openfile. Может и с read/write тоже самое.

_Chingachguk_ > Почему не просто перехват int 21h ?
frozen > Потому что программа работает в Windows XP ...
Кто мешает запустить исследуемую программу из bat-файла, первой строчкой которого будет резидент следящий за int13h, int21h, int26h и т.п.?

q_q
В SoftIce набираем
bpint 21 if (ah==3c) || (ah==3d) || (ah==40) || (ah==5b) || (ah==6c)

И ставим бряки на
3c - CreateFile
3d - OpenFile
40 - WriteFile
5b - CreateNewFile
6c - Extended Create/Open

Если прога написанна на BP то при выводе на экран будут бряки на 40(запись) с handle =1

Мысля у меня, конечно, дикая, но тем не менее она есть :)
Может быть стоит попробовать бряк на ntvdm.exe!DispatchInterrupts ?

MoKC0DeR все правильно написал. Если прога досовская то она слыхом не слыхала от NTVDM и юзает только то, чему с рождения учили (int 21h). Проще надо быть :)

frozen
Всё очень просто. Когда создаётся процесс NTVDM, в таблице IDT чудесным образом появляется дескриптор, накоторы указывает селектор 21H, то есть досовский инт. Любой вызов данного прерывания из процесса ntvdm приводит к дёрганью этого инт в главной таблице, который затем отправляется к драйверу, оттуда библиотеке vdm а затем, уже последние вызывают системные функции для работы с файлами (NtReadFile, NtWtiteFile и тд). Делаешь просто. Пишешь драйвер, и всовываешь обработчик в дескриптор 21h таблицы IDT, только имей в виду, что придётся согласовать 16 и 32 битные код, так как 21h описывает точку входа в 16 разрядном сегменте. Ну это уже просто. Таким образом ты сможешь контролировать этот процесс. Не веришь, проверь айсом. А кроме того, это на каждом заборе написано..

Спасибо всем кто ответил.
1)хук на zwcreatefile для NTVDM не катит - файл в данной программе создается именно этой функцией.
2) с перехватом IRP мысль была, но решил доделать так как начал.
3) Bat с резидентом это очень просто и не подходит, т.к. программа должна работать скрытно, а отслеживаемую программу можно запустить и без bat`a.
4) про int 21 в DOSe это итак понятно. Кстати, bpint 21 ничего не дает - молчит...(по поводу IDT и т.д.)
5) самое главное. Все вызовы в конце концов проходят через Native API. Итак, меня с самого начала интересовало, при помощи какой функции Native API осуществляется запись в файл из NTVDM. Файл создается NtCreateFile, закрывается - NtClose, но!! ЗАПИСЬ ОСУЩЕСТВЛЯЕТСЯ НЕ NtWriteFile. Более того. Мониторинг системных вызовов (strace), не показывает вообще никаких функций, подходящих для записи.
Вот. Так что это может быть за функция???

Ну уж если так плохо, так начнинизу: предположим ( :-))) ), что запись/чтение проходит ч/з IRP. Ну и наверно ч/з IofCallDriver, вконце концов. Цель - поймать кто это послал, и прошагать обратко по ret-коммандам прошагать до вызавающей ф-ии. Тогда _ТОЧНО_ можем знать, кто это там пишет... Знаем, что можно в SoftIce поставить:
BPX IofCallDriver IF (ECX==pDriverObjectXXX)
ну и типа тогда и начнем обратно шагать по RET.

Как узнать pDriverObjectXXX:
Можно поставить хук - BPX ObReferenceObjectByHandle if (*(esp+04)== HANDLE)
,где HANDLE – хэндл файла. Ну этим уж Ты точно располагаешь.
После, пишешь
D ESP+5*4 , и затем
P RET
Тем самым, окажешься в моменте завершившейся ObReferenceObjectByHandle, а по адресу ESP+5*4 будет Твой pDriverObjectXXX.

Готово. Можешь хучить IofCallDriver.
Тем самым, вызавая:
IRP EDX при остьнове на этом бряке, получаешь кучу доп. Инфы. В том числе и об pFileObject.

P.S. Знаю, что ч/з ?-е место, но… тоже способ :-)

В принципе, можно попробовать поставить bpm на хэндл, возвращаемый "OpenFile".

frozen
Госспади, яж тебе сказал, что делать, это сработает

CARDINAL
уже последние вызывают системные функции для работы с файлами (NtReadFile, NtWtiteFile и тд). - мне и надо, узнать эту функцию!! Ну не вызывается NtWriteFile, яж ясно написал, и не раз. А еще я написал, что bpint 0x21 чудесным образом молчит. ОК?