имя приложения, вызвавшего драйвер

Irp->Tail.Overlay.Thread->StartAdress или Win32StartAddress, не скажу точно.



Смотрим, куда указывает этот адрес, в память какого модуля.

 

infern0

ничего не понимаю, тебе функциональность важна или красота????

 

CARDINAL

я не хочу связыватся с хуками. Генеральная идея такая - запустил драйвер - он мониторити отдает все данные. выгрузил - перестал. без доп. плясок со связыванием инфы из драйвера из из хуков.

 

IceStudent

а разве для длл и exe thread объекты будут разными ?

 

Да нет. Дело в том, чтобы посмотреть, куда указывает StartAddress: в память какого модуля.

 

ага, понял. Спасибо, буду пробовать.

 

я кстати, предлагал то же самое , но это не всегда проканает, тк длл-ка может (и чащще всего так и будет) работать в том же потоке что и приложение, поэтому вероятность ошибки весьма велика

 

Kola

Э, нет, вы путаете.



Здесь нужно определиться, что подразумевается под

, например, драйвер вызывают:

1) главный поток ехе - самое простое, получаем "some.exe".

2) другой поток ехе - результат как и в 1.

3) поток, созданный в dll - результат "some.dll".

4) поток из ехе вызывает функцию из dll, которая обращается к драйверу, результат "some.exe"



Я не пойму, что значит

?

Имелось ввиду, в том же процессе? Или то, что dll может создать поток в секции кода ехе?

 

Я имел ввиду то что код длл-ки чаще всего работает в том же потоке что и код екзешника который загрузил эту длл.

Например:

Код (Text):

1. // код ехе-шника,
2. HANDLE hDll = LoadLibrary("some.dll");
3. FARPROC func = GetProcAddress(hDll, "SomeFunction");
4. int ret = func();

весь этот код, включая код ф-ии SomeFunction будет выполняться в одном потоке, и стартовый адрес данного потока принадлежит ехе-нику

 

я как раз имел в виду ситуацию, описанную Kola. Есть exe. Оно грузит 7 или 8 дллек. Все в одном потоке. Как exe так и дллки могут вызывать драйвер. В логах драйвера я вижу смесь вызовов в которых трудно отследить цепочку типа initdevice / getdata X n / setdata X n / closedevice. А если бы для каждого вызова была возможность узнать откуда (из какого диапазона адресов) он был сделан то можно легко все проследить. А так получаются StartAddress одинаковый (случай 4 у IceStudent). именно это и надо разрулить.

 

infern0

Тогда только раскрутка стека: смотреть, кому принадлежит адрес, следующий за call DeviceIoControl

 

а не проще уж тогда перехватить вызовы конкретных функций kernel32.dll из ядра, написав для этого kmd если уж на то пошло ?????