Как отследить запись на диск файла из ДОСовской программы?

Помоги решить проблему, горю. Необходимо отследить запись на диск файла из досовской программы и проанализировать этот файл. Написал драйвер, поставил хук на 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 чудесным образом молчит. ОК?

 

frozen

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

 

frozen

Ну а с перехватом int21 таблицы IDT способ верный, вчера сам угарал с этим , всё канает.

 

кстати, а какой студией ты пользуешься ? у меня 2.7 , только вот сам не понимаю, bpint действительно молчит, ну а вот если поставить бряку непосредственно по смещению, нарисованному в дескрипторе 21, то всё превосходно работает... в 2k, xp, 2k3

 

в ДОС под 2000-м(ХП)

легко перехватывается. Найди ДОС-овкую таблицу

прерываний и поставь BPM по выполнению, на

адрес соответствующий INT 21 ( из 0:0x84 ).

Я решил сам посмотреть. Короче все ДОС-функции

в конце содержат JMP far cs:[xxxx]

и идут в область 0xfe2e:xxxx. А MAPV86

гласит , что там ROM BIOS

Я не поленился и прошлепал покомандно

всю INT 21 AH=40

Только в одном месте встретилась странная

команда типа AND LOCK .................

Выполнялась она чуть дольше других ?!

Не было никаких INT ( я уже знал что INT 13,25 и 26

не вызываются) и благополучно вышли по IRET :-(

Тут уже обсуждалась запрещенная команда С4С4,

которая на деле в NTVDM позволяет вызвать функции

из NT. Видимо здесь похожий случай.

 

CARDINAL

У меня Driver Studio 3.1. Мониторинг функций ничего вразумительного не дает. Между NtCreateFile и NtClose нет ничего даже отдаленно напоминающего функцию записи. Такое ощущение, что вызов идет не через SST по int 2e ( ntdll!NtWriteFile), а каким либо образом напрямую вызывается из (NTOSKRNL.EXE!NtWriteFile), т.е. должен присутствовать какой то драйвер режима ядра у NTVDM...( есть ли такой вообще??) Хотя опять же, также нет функций для посылки кодов драйверу... - мысли вслух.

Кому интересно, проблема уже решена другим способом, т.к. нет времени, и представляет чисто спортивный интерес.

По поводу отслеживания IRP - как узнать момент, когда нужно приаттачится к флоппи диску? Ведь он монтируется при первом обращении к нему, т.е. когда нужно, например, что то записать - непосредственно перед записью. Соответственно, нужно приаттачится до записи, что бы успеть проанализировать IRP.