Очень нужна информация в какую сторону копать. Есть драйвер. Нужно пропустить через себя все IRP-пакеты и разобрать их. Буду благодарен за помощь
Вопрос непонятен. Если драйвер уже есть (надо полагать, что это фильтр), то наверное, и к стеку он уже подключен, а значит через него идут IRP (по-крайней мере, те, которые отдают вышестоящие дрова). Структура IRP известна. В чём проблема? Исходников драйверов-фильтров навалом. Например в ДДК: DDK\src\general\toaster\filter Можешь посмотреть сатью: http://www.wasm.ru/article.php?article=drvw2k16 . Там как раз простейщие фильтры. Не PnP, правда, но PnP'лейность не влияет на трафик IRP.
Нет. Задача немного сложнее Это не мой драйвер. Для работы с ним есть приложение стороннего производителя. Мне нужно ограничить его функциональность. Тоесть написать собственное приложение, которое будет использовать лишь часть его функций. Но я не знаю как устроен этот драйвер и какие диспетчерские функции он использует. Поэтому единственное, что пришло в голову - посмотреть все IRP которые идут к нему и найти точки входа, IOCTL и т.д. Или это можно сделать по-другому ? P.S. Four-F - можешь скинуть свой ICQ (если он есть). На форуме слишком большая задержка ответов
Посмотреть что драйвер обрабатывает можно с помосчью DeviceTree, когда он загружен. Ты говоришь, что тебе нужно ограничивать, значит по любом нужно знать что ограничивать. Так тебе нужно написать драйвер фильтр, который ограничивает, или "собственное приложение, которое будет использовать лишь часть его функций".
Хорошо - тогда еще раз. Мне нужно создать именно собственное приложение, которое будет использовать лишь часть функций существующего драйвера, не трогая остальные. Но я не знаю даже какие функции нужно вызывать. Я не знаю о драйвере абсолютно ничего. Именно из-за этого и возникла идея посмотреть все IRP, которые к нему идут. Для примера. Драйвер может читать и писать. Я хочу, чтоб мое приложение позволило ему только читать. Но я не знаю даже как заставить его читать, не знаю какие функции он использует (это все конечно в ПЕРЕНОСНОМ смысле
Хм .. интересно с одной стороны и завбавно с другой а ты знаешь что будет делать та программа которую ты напишешь Просто это я к тому что если ты собрался писать прогу с ограничением то проще в самой прогу вписать ограничение и не дать пользователю заюзать ту или иную функцию (например распросторанять без функций вообще а уже при паокупе патчить под оперделенную ос и железо установленное на данном компьютере) или еще какие нить методы а то получается что ты незнаешь как работает драйвер и какие у него функции , а пытаешься создать прогу которая будет использовать функции драйвера . А как тогда ты будешь писать код незнаю функций драйвера ? Может надо начать с более простого вопроса : Что делает ЭТОТ драйвер ... и где мне про него почитать .. итп
<font color="gray][ zss</font><!--color--><font color="gray]: Поэтому единственное, что пришло в голову - посмотреть все IRP которые идут к нему и найти точки входа, IOCTL и т.д. ]</font><!--color--> Если это фильтр, то к нему и так все IRP летят. Вопрос какие он обрабатывает, а какие нет и главное как. Узнать это можно только реверснув дровину. Другого способа нет. Если там не использовано ООП, то считай что тебе повезло. Заливай в IDA + SoftICE и вперёд. Если там всякие отстойные технологии типа DriverWorks от CompuWare, то тогда тебе не повезло. Времени убьешь на порядок больше. Посмотреть IRP идущие через драйвер можно с помощью... 1. DevFilter www.ntkernel.com - неплохая тулза, но нужно 100 денег. Есть фришная версия 1.12, но содержимое IRP не кажет. 2. IRP Tracker www.osr.com или www.osronline.com - генератор голубых экранов, по крайней мере, на всех моих машинах 3. Где-то у немцев ещё видел, что-то вроде IRP Tracer. Уже не помню, но тоже какой-то отстой. 4. Бряки в SoftICE. Точки входа элементарно ищутся. Если по быстрому, можно в айсе по команде driver <имя драйвера или адрес его объекта>. Или с помощью WinObjEx (есть на этом сайте). Но если это фильтр, то это ничего не даст, т.к. фильтр обязан забить весь массив MajorFunction и это, скорее всего будет адрес одной и той же функции, а она уже распределяет. DeviceTree совсем для другого. Тоже, кстати, концентрированный глюконат <font color="gray][ zss</font><!--color--><font color="gray]: P.S. Four-F - можешь скинуть свой ICQ (если он есть). На форуме слишком большая задержка ответов ]</font><!--color--> Аси нет. Пиши сюда. Это меня ни к чему не обязывает К тому же, не на мне одном свет клином сошёлся.
Перечитал ещё раз вопрос. Судя по всему, имеется драйвер фильтр, который что-то фильтрует и юзерное приложение, которое управляет параметрами фильтрации и, возможно, собирает какую-то стат. инфу. Я так понимаю тебя интересует не столько как и что драйвер фильтрует, а как этим управлять. В любом случае, юзерная прога может это делать либо через DeviceIoControl, либо через Read/WriteFile. Есть ещё всякие извратные способы, но они вряд ли используются. Для начала посмотри какие IRP_MJ_DEVICE_CONTROL к нему летят и в каком случае. Т.е. что-то сделал в проге - прилетел такой(ие)-то код(ы). Это для самого начала и для общего представления. Ну а дальше по-любому IDA и SoftICE. Тебе, кстати, может пригодиться I/O Control Code Decoder.
И все же Вы меня опять не поняли. Нет никакого драйвера-фильтра. Есть просто драйвер. А фильтр хотел вешать я, чтоб посмотреть что к нему идет. Ведь ты говоришь Так вот мне и нужно определить какие IRP_MJ_DEVICE_CONTROL он принимает и попробовать вызвать их через DeviceIoControl. За I/O Control Code Decoder большое спасибо. Правда знание кодов это лишь часть беды. Ведь необходимо определить еще и структуру буферов, которую он принимает -а это намного сложнее. Но я так понимаю - другого выхода нет ?
<font color="gray][ zss</font><!--color--><font color="gray]: Нет никакого драйвера-фильтра. Есть просто драйвер. ]</font><!--color--> Если драйвер сам по себе, тебе только проще. <font color="gray][ zss</font><!--color--><font color="gray]: А фильтр хотел вешать я, чтоб посмотреть что к нему идет. ]</font><!--color--> Скорее всего, нет смысла тратить на это время. Бери IRP Tracker и смотри (надеюсь, что не на голубые экраны как я ). <font color="gray][ zss</font><!--color--><font color="gray]: Ведь необходимо определить еще и структуру буферов, которую он принимает -а это намного сложнее. ]</font><!--color--> Естественно. И тут только реверсинг.
По научному эта штука называется Reverse Engineering. Это когда ты невероятным усилием мысли пытаешься выудить из неструктурированного потока сознания ... Короче, по простому говоря это, когда у тебя есть прога/драйвер или любая другая выполнимая сущность, а исходников нет и тебе нужно понять как она работает. Вот это и есть реверсинг, т.е. разбор по косточкам. Главные инструменты тут дизассемблер (IDA лучший из них) и дебаггер (для дров SoftICE, если на одной машине нужно дебужить). Инфы в нете море.
Дело в том, что для этого устройства есть исходник схожего драйвера под *nix. Поэтому я хотел посмотреть на размеры буферов. Если они одинаковы, то есть большая вероятность, что схожи по своей структуре. Это намного облегчит работу (хотя вероятность мала). У меня все работает без BSOD, но информации не достаточно. P.S. Four-F, попробую на основе твоей статьи что-то сварганить. Если получу результат - сообщу.
