Большое спасибо. Я написал следующий код: Код (Text): pIrp = IoGetCurrentIrpStackLocation(Irp) ... DBGOUT(("Buffer:%s", pIrp->Parameters.Others.Argument1)); в DebugView получаю: Код (Text): "Buffer: H" мм... помоему должно быть что-то другое... как мне вывести этот буфер в отладочную печать?
Никто... =)... Ммм... просто мне не с кем посоветоваться... а опыта мало... поэтому "леплю" как думаю. Сейчас попробую сформулировать свои сумбурные мысли, а Вы меня поправьте, пожалуйста. pIrp->Parameters.Others.Argument1 - Это указатель на структуру. В структуру... структура содержит определенные поля, согласно DDK. В памяти структура представлена "целостным" блоком памяти. Где каждое поле идет одно за другим согласно определению. Следовательно, каким-то образом можно вывести на экран весь дамп памяти относящийся к этой структуре как текст. Вопрос как это сделать.
Задача сводится к выводу шестнадцатеричного дампа. Что-то вроде. Код (Text): 00000000 F0 A6 00 00 00 08 02 40 00 00 02 08 08 00 00 00 00 00 00 00 ð¦.....@............ 00000014 00 00 00 00 30 00 00 00 00 00 00 15 00 00 00 08 00 80 00 00 ....0............?.. 00000028 0F 3E D2 4F 13 0E CF BA C3 5F 14 05 AF 34 DD 1F 72 FB CF 58 .>ÒO..ϺÃ_..¯4Ý.rûÏX 0000003C D6 DF 23 F1 Öß#ñ Найти где-нибудь подходящую функцию и адаптировать под себя. Гугл, например,неплохо по исходникам шариться. http://www.google.com/codesearch?q=hexdump Только какой смысл? Лучше уж сразу самому набросать код для вывода URB в структурированном виде. Что-то вроде. Код (Text): PURB pUrb = pIrp->Parameters.Others.Argument1 DBGOUT(( "Lenght : %02X\n", pUrb->Lenght )); DBGOUT(( "Function : %02X\n", pUrb->Function )); и т.д. Придется немного погеморроиться т.к. типов URB много, но тебе наверное только некоторые нужны.
Огромное спасибо. В Десятку!... Я и не знал что Гугл такой умный=)... Нашел простенький исходник SnoopyPro, в котором уже все напиано, для ВСЕХ URB=)))) Сразу куча вопросов. Главный вопрос следующий: Мой драйвер фильтр сидит в стеке под драйвером флешки, т.е. вот так: Controlling Service: "USTOR" Lower Filter: "MyUsbFilter" и вроде как (т.к. я не знаю как это проверить) перехватывает все пакеты. В DebugView выводится что-то типа: Код (Text): ... 00000282 1.45435500 'FILTER> 00000283 1.45436335 VA_Dispatch: majorFunc=15, minorFunc=0. MyUsbFilter v 2.0 00000284 1.45436668 00000285 1.45437002 'FILTER> 00000286 1.45437455 CONTROL CODE: IOCTL_INTERNAL_USB_SUBMIT_URB 00000287 1.45437729 00000288 1.45438206 -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: 00000289 1.45438731 PipeHandle = ffabe024 00000290 1.45439434 TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) 00000291 1.45439911 TransferBufferLength = 0000000d 00000292 1.45440388 TransferBuffer = 00000000 00000293 1.45440865 TransferBufferMDL = 80e1b2c8 00000294 1.45441246 00000295 1.45441413 0000: 00000296 1.45441759 55 00000297 1.45442116 53 00000298 1.45442474 42 00000299 1.45442820 53 00000300 1.45443153 a8 00000301 1.45443511 12 00000302 1.45443845 00 00000303 1.45444179 00 00000304 1.45444524 00 00000305 1.45444882 00 00000306 1.45445216 00 00000307 1.45445609 00 00000308 1.45445943 00 00000309 1.45446277 00000310 1.45446730 UrbLink = 00000000 ... Я решил сравнить данные получаемые моим фильтром и программой USBMonitor, после установки и запуска USBMonitor стек драйверов имеет следующий вид: Class Upper Filters: "hhdusbh" Controlling Service: "USTOR" Перехватываемые пакеты почти такие же, НО вот что я заметил при сравнении логов моего фильтра и USBMonitor'а: 1) "синхро пакеты (как IN так и OUT) совпадают. 2) Некотороые пакеты данных совпадают, а некоторые НЕТ. причем того что я перехватываю моим фильтром нет в логах USBMonitora, а того что есть в его логах нет в моих. Ума не приложу в чем дело. Вот ссылка на файл с основными функциями, (к посту почему-то не прикрепился)... http://www.jetflashlog.nm.ru/filter.rar Вкратце: 1) VA_Dispatch - перехватывает все MajorFunction; 2) Если приходит запрос IRP_MJ_INTERAL_DEVICE_CONTROL, то проверяем, что ControlCode == IOCTL_INTERNAL_USB_SUBMIT_URB и вызваем функцию DumpURB; 3) В функции DumpURB делаем switch по функциям данного URB запроса; 4) Если функция URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (а другие практически не использюются), то вызываем DumpTransferBuffer; 5) DumpTransferBuffer - выводит средствами отладочной печати содержимое URB - пакета.
Дело простое: ты сидишь под FDO, а драйвер USBMonitor'а над, я это две большие разницы Над usbstor никаких URB нет, там только SCSI команды. Под usbstor никаких SCSI команд нет, зато там полно URB usbstor транслирует SCSI -> URB. SCSI используется просто для стандартизации.
Ммм.... так.... я немного запутался.... Разложим по полочкам: IoDeviceControl\ReadFile\WriteFile (user mode | aplication and OS) -> (kernel mode | USTORK ) -> SCSI ( USTOR ) -> URB (шинный драйвер USB, я полагаю что это USBSTOR (Драйвер запоминающих устройств)) -> USB-пакеты (USB-порт) -> URB (устройство) ->...???... Помоему как-то так....может я что-то не понимаю... Я "вклиниваюсь" между USTOR и USBSTOR(или как его?) и перехватываю информацию в формате URB пакетов. USBMonior сажает свой драйвер над USTOR и поидее должен перехватывать SCSI команды, но то что он перехватывает, это чистой воды URB (см.: www.jetflashlog.nm.ru - 1,7 Мб (это HTML-лог)). Я думаю что он "хучит" функции нижележащих драйверов. Мне все равно не понятно почему у нас не совпадают пакеты...(не совпадают по "количеству" а не содержанию) ?
Упс... В предыдущем твоём посте я прочитал USTOR, а в мозгу запечатлелось USBSTOR. Так что кто там над кем непонятно. Но не суть. Да мало ли почему. Например, вы перехватываете разный набор Dispatch Routines. Он показывает только завершившиеся IRP, а ты и те которые идут вниз. Он показывает только удачно завершившиеся IRP, а ты все. Он не показывает IRP завершившиеся с каким-то определённым статусом, а ты все. Ну и т.д. и т.п. Тут сложно что-то сказать. IMHO, это не должно тебя беспокоить.
Допустим. Вопрос с получаемыми данными наверное слишком "мутный" для обсуждения в форуме. Есть более прикладная проблема: В "нарытом" мной коде драйвера было (результат работы был представлен выше): Код (Text): void DumpTransferBuffer(PUCHAR pBuffer, PMDL pMdl, ULONG uBufferSize, BOOLEAN bPrintHeader) { ... for(b=0; b<uBufferSize; b++) { if(0 == (b % 16)) { KdPrint(("\n %04x:", b)); } KdPrint((" %02x", pBuffer[b])); } KdPrint(("\n")); ... } Я заменил на: Код (Text): void DumpTransferBuffer(PUCHAR pBuffer, PMDL pMdl, ULONG uBufferSize, BOOLEAN bPrintHeader) { for(b=0; b<uBufferSize; b++) { if(0 == (b % 16)) { KdPrint(("\n %04x:", b)); } if (uBufferSize - b > 10) { KdPrint((" %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x", pBuffer[b], pBuffer[b+1], pBuffer[b+2], pBuffer[b+3], pBuffer[b+4], pBuffer[b+5], pBuffer[b+6], pBuffer[b+7], pBuffer[b+8], pBuffer[b+9],)); b = b + 10; } else { KbPrint((" %02x", pBuffer[b])); } } KdPrint(("\n")); ... } После изменения кода, загрузка драйвер приводит к BSOD... Не могу понять почему?=(
Народ! Извините за глупый вопрос, но я тоже новичок в разработке. Хочу сделать фильтр для USB-флешек со следующим функционалом: Есть некий конфигурационный файл, который лежит на диске C: В конфигурационном файле хранятся имена пользователей, файлы (пути), приписанные к ним, и разрешенные действия (чтение/запись). Хочется, чтобы фильтр-драйвер, с использованием данного файла разрешал или запрещал запрошенные пользователем (пользователь просто открыл флешку и пытается, например, прочитать файл) действия. Подскажите пару моментов: 1) На каком уровне удобнее реализовывать такой функционал - UpperFilter или LowerFilter? 2) Как наиболее правильно и корректно с точки зрения разработки подобных фильтров занести информацию из конфига (ведь необходимо определить текущее имя пользователя, выудить соответствующие пути файлов с правами и далее уже проверить). Буду признателен за любую помощь =)
shimaro Защита у такой флэшки будет нулевая, достаточно будет подсунуть драйверу необходимый набор прав и усе... если имеется ввиду права определенные самой Windows, то там помоему все намного сложнее чем файлы конфигурации. Если файлы конфигурации для такого фильтра "свои" и создаются отдельно для него, то ИМХО необходимо делать резидентную прогу которая будет палить что за пользователь вошел, потом согласно имени пользователя лезть в конфиг и уже на основе данных из конфига вызывать IoDeviceContol. В твоем случае фильтр должен быть Upper , т.е. если метод по которому пользователь обращается к флешке не соответствует уровню допуска, то она такой запрос не передает нижнему драйверу а "убивает" его.
Спасибо за ответ! На самом деле меня не очень сильно волнует то, как можно этот вариант обойти. Это всё, скажем так, в образовательно-познавательных целях. Формат файла конфигурации известен и он только свой для этого драйвер-фильтра. Вопросы остались скорее такого типа: 1) Насколько известно, фильтр-драйвера имени не имеют, при выхове CreateDevice указывается NULL. Каким тогда образом мы можем записать в него нашу информацию? Например, прочитанный на уровне пользовтеля конфиг + данные о текущем пользователе? Когда я в своё время писал обычный драйвер, то просто открывал его и писал в него то, что нужно. 2) Информация о том, что нужно фильтровать должна постоянно хранится в фильтре, получается. То есть когда приходит запрос прочитать файлик - то должен происходить пробег по некой сохранной структуре и сравнение на то, надо ли отсеивать. Вопрос в том - как подобные вещи хранить в фильтр-дайверах по-правильному? 3) А можно ли в самом фильтре открыть файл и вычитать оттуда всё, что нужно? Определить пользователя? Или такие вещи на данном уровне некорректны/недопустисмы? 4) Я пока еще не разбирался непосредственно в каком виде приходят пакеты при UpperFilter. Поэтому, если не сложно, можно ли сделать некоторый экскурс в эту область? Буду признателен. То есть что именно получает мой фильтр и как он узнаёт, какое действие и с каким реальным объектом на флешке что-то хотели сделать. ps. Заранее огромное спасибо =) Понимаю, многое можно было читать самому, но я делаю это параллельно =)
shimaro Для начала Кури Солдатова ОЧЕНЬ внимательно. Потом попытайся понять что такое IRP. Советую покурить Руссиновича "Внутренне устройство Microsoft Windows: Windows 2003 Server, Windows XP, и Windows 2000" потом опередились что ты хочешь, не трать силы в пустую, составь модель (схему) работы твоей защиты, и когда на схеме разберешся как все должно работать приступай к реализации. Еще раз обращаю твое внимание на то, что выбранная тобой схема имеет крайне слабую стойкость. Думаю с этим согласятся и остальные участники форума. Я около полутора лет изучаю эту область (не постоянно, но материалы накапливаются). пока пришел к выводу что ЛЮБУЮ защиту на программном уровне можно обойти драйвером, достаточно разобраться в структуре пакетов и подсунуть нужный, от пакетов ты никак не избавишься, это заложено в архитектуру Windows. Вся защита флешек сториться на аппаратном уровне, "как?" пока разбираюсь. Суть в том что это поддерживается как самими модулями памяти, так и контроллерами. Инфы по данному вопросу ОЧЕНЬ мало, собираю буквально по крупицам, если у кого что есть поделитесь, буду очень благодарен.
Всем привет. Пытаюсь сделать фильтр для USB устройства. Если правильно понял то нужно: 1.прикрутить драйвер в стек драйверов 2. поставить обработчик прерывания на определенный IRP и получить описатель pipe 3. запустить поток принимающий (из pipe ) и отправляющий данные по цепочке стека дошел до 3 и ..утонул поправте если не прав....