Может кто что знает об этом (драйвер hook'er для NTсистем) ?

[Exkursъ]

Ктот что знает или у кого есть пример драйвера режима ядра для NT систем, перехватывающего обращения другого драйвера к третьему (например обращение какого - то драйвера к lpt.sys) и возвращающего этому другому перехваченному драйверу определенные значения (не те, которые возвращает lpt.sys) ?
Один из способов это hooking посредством модификации таблицы импорта драйвера, который обращается в данном примере к lpt.sys.
То есть драйвер А, который заменяет таблицу импортов драйвера B, обращающегося к драйверу С.
Если есть другие эффективные, безопасные методы, скажите какие.

[Гром]

Скажем так - ответ будет не раньше понедельника, у людей нет домашнего выхода в инет, а я не сталкивался с такими вещами.

[SlavaI]

 hooking посредством модификации таблицы импорта драйвера

 Если ты имеешь в виду переписывание указателей на ф-ции обработчики в DRIVER_OBJECT, то действительно такой способ есть, но он позволяет перехватывать входящие сообщения, но не исходящие.

Вобще-то перехват обращения от одного драйвера к другому- это проблема, так как можно перехватывать все обращения к драйверу, но из них надо выделить только идущие от определенного драйвера. Если какой-то драйвер( назовем А)общается с другим драйвером(назовем В), то способ общения может быть таким-
1) Создание IRP в драйвере А и отсылке его В. Тут ты на В ничего определить не сможешь, так как явного указания на драйвер А нигде не хранится.
2) Драйвера в одном стеке(или стеки связаны) и указатель на DEVICE_OBJECT, управляемый А, можно найти в одном из стеков IRP, пришедшего на B.

Я считаю что твоя идея о перехвате обращений одного драйвера к другому сложно осуществима в силу архитектуры NT систем- у них драйверу к которому обращаются не нужна информация о том кто к ним обращается, узнать это можно только косвенным образом, причем 100% надежного способа нет.

[dorador]

Я извиняюсь, но может проблема надуманая и товарищу подойдет драйвер фильтра?
Я так понимаю: если в системе два драйвера B и C общаются посредством каких-то ioctl, то не может же быть драйвера D, который будет общаться через те же ioctl с драйвером C, минуя драйвер B.
Или я не прав?

[SlavaI]

Я так понимаю: если в системе два драйвера B и C общаются посредством каких-то ioctl, то не может же быть драйвера D, который будет общаться через те же ioctl с драйвером C, минуя драйвер B.

Может, хотя это против правил Microsoft, но ничто не мешает это сделать, так как получить DEVICE_OBJECT какого-то устройства( а не самого верхнего в стеке) не проблема, а после этого сделать IRP и послать его на это устройство тоже легко.

[dorador]

Может, хотя это против правил Microsoft, но ничто не мешает это сделать, так как получить DEVICE_OBJECT какого-то устройства( а не самого верхнего в стеке) не проблема, а после этого сделать IRP и послать его на это устройство тоже легко.

Но драйвер B и драйвер фильтра A при этом тоже будут обойдены. То есть задачу перехвата обращений драйвера B к драйверу C драйвер фильтра A будет выполнять.

[SlavaI]

Но драйвер B и драйвер фильтра A при этом тоже будут обойдены. То есть задачу перехвата обращений драйвера B к драйверу C драйвер фильтра A будет выполнять.

Есть способ перехвата сообщений к драйверу без подсаживания фильтра над драйвером, и этот способ не позволяет обойти себя никаким способом(только если то же не сделает другой драйвер). Внимательней читай обсуждение темы и не зацикливайся на официальном DDK.

[dorador]

Есть способ перехвата сообщений к драйверу без подсаживания фильтра над драйвером, и этот способ не позволяет обойти себя никаким способом(только если то же не сделает другой драйвер). Внимательней читай обсуждение темы и не зацикливайся на официальном DDK.

Я понял тему как способ перехвата обращений драйвера B к драйверу С и только этих. И эта задача ИМХО решается фильтром. И знать кто к нему обратился фильтру не надо. Потому что к нему обращается или драйвер B или кто-то знающий про фильтр.
Если я не прав, поправьте.
А то что нельзя 100% узнать кто обратился, ИМХО в принципе, плохо.  
А то что есть способы обойти цепочку верхних драйверов и обратиться непосредственно к драйверу С ИМХО замечательно.

[Anonymous]

SlavaI, может не совсем понятно описал, попробоую еще раз: есть два драйвера, B и C, которые общаются между собой, нужно между ними " поставить " драйвер А, который не будет позволять доходить сообщения от драйвера B к драйверу С, и кроме того будет возвращать драйверу B что - то, что в " обычном " случае должен был бы врозвращать драйвер С.
То есть еще более проще - написать драйвер A, эмулирующий драйвер С.

Вот еще такие условия: название драйвера B известно.

[Anonymous]

То есть еще более проще - написать драйвер A, эмулирующий драйвер С.

Но не заменяющий драйвер С, а подменяющий.
То есть, чтобы драйвер С оставался оригинальным, но его " черную работу " выполнянл бы для драйвера B драйвер A.

[grozny]

SlavaI, может не совсем понятно описал, попробоую еще раз: есть два драйвера, B и C, которые общаются между собой, нужно между ними " поставить " драйвер А, который не будет позволять доходить сообщения от драйвера B к драйверу С, и кроме того будет возвращать драйверу B что - то, что в " обычном " случае должен был бы врозвращать драйвер С.
То есть еще более проще - написать драйвер A, эмулирующий драйвер С.

Вот еще такие условия: название драйвера B известно.

Поищи UpperFilter в XP DDK. А чего ты собрался фильтровать, если не секрет?

[Viktor Denk]

Interesno!!  :!:
U menja stoit sledujushchaja zadacha:
1) Est' staryj Soft, on rabotaet so starym Hard cherez COM-Port ( chitaet magnitnye karty, naprimer);
2) My dolzhny postavit' novyj Hard( klavy, a cherez nee vse dannye budut po PS/2 peresylat'sja) dlja novogo PC ( no bez COM-Portov);
3) Staryj Soft ne dolzhen nichego zametit';
4) Vse begaet na Win NT 4.0 (! i pri uslovii, chto ja imeju polnyj kontrol' nad driver dlja klavy, koroche quellcode).

Ja tut b'jus' i pytajus' najti kakoj - nibud' primer dlja Virtual COM-Port, chtoby iz nego zaxvatit' dannye ot klavy, chto ja delal mnogo raz, no iz DLL.
Mozhet kto - bud' podskazhet chto - nibud' po sushchestvu dela?  :idea:
Zaranee premnogo obshchestvu blagodaren!  

E-Mail: vetoshkin@lycos.de