Доступ к буферу данных (драйвер <---> приложение)

[GG_shara]

Доброго времени суток, форумчане.

Написал простенький драйвер-фильтр ФС.
IRP'ы и FastIO запросы перехватываю, как по учебнику.  Чтение\запись..., ну и все остальное.

Меня интересуют передаваемые данные от прикладной программы к драйверу.
Проблемы (т.е. BSOD'ы) начинаются, когда пытаюсь их, данные, слегка модифицировать.


 Драйвера ФС в основном использут Nether Buffered Nor Direct I\O способ передачи данных от приложения к драйверу.
То есть, мы, выполняясь в контексте приложения, получаем доступ к его памяти и шаманим с ней (модифицируя, копируя, сохраняя...)

Первые два метода работы с буфером данных Buffered и Direct I\O пока не обрабатываем (только проверяем их использование).

Опытным путем установил, что большинство запросов чтения\записи данных выполняется именно посредством FastIO.
В обработчике FastIOWrite пишу следующее (в обработку IRP_MJ_READ\ IRP_MJ_WRITE решил пока не лезть - просто спускаю вниз), в тестовом режиме решил модифицировать исходный буфер только при обработке FastIOWrite

Код:

BOOLEAN  
IntercepterFastIoWrite( 
    IN PFILE_OBJECT FileObject, 
    IN PLARGE_INTEGER FileOffset, 
    IN ULONG Length, 
    IN BOOLEAN Wait, 
    IN ULONG LockKey, 
    IN PVOID Buffer,
    OUT PIO_STATUS_BLOCK IoStatus, 
    IN PDEVICE_OBJECT DeviceObject 
    ) 
{
   // ... 
   // немного необходимой рутины по спусканию запроса вниз по стеку
   // ...
   
   DbgPrint (("Buff size: %i \n  buff: '%s'  ", Length, Buffer));
   int ModifOffset = 7; // ModifOffset < Length
   *((char*) Buffer + ModifOffset) = 'W'; 
   
  // ...
}

Для тестов быстренько написал простенькую программу, которая пишет в файл строку "Hello world" посредством CreateFile\WriteFile. Настроил фильтр так, чтобы он реагировал на запросы, отправляемые драйверу, только исходящие от этой программы.

 Хочу, чтобы в драфвере-фильтре буква 'w' заменилась на 'W' (world --> World), и как только я пытаюсь это делать -  BSOD, BSOD и еще раз BSOD

 Если закомментировать

Код:

  // int ModifOffset = 7; // ModifOffset < Length
  // *((char*) Buffer + ModifOffset) = 'W';

   
 
все работает, и DbgPrint добросовестно выводит записываемую информацию....

Что не так делаю?

[Ochkarik]

я честно говоря сам с  Nether Buffered Nor Direct I\O не работал... но там разве не надо дополнительных операций по залочиванию/мапированию памяти,и/или создания MDL?
(чес слово, устал как сабака, поэтому искать в DDK сил нет)))

[GG_shara]

я честно говоря сам с  Nether Buffered Nor Direct I\O не работал... но там разве не надо дополнительных операций по залочиванию/мапированию памяти,и/или создания MDL?
(чес слово, устал как сабака, поэтому искать в DDK сил нет)))

может и нужно, но ведь DbgPrint  "правильную" строку выводит

я в WDK долго рылся -  ничего такого не нашел  =(

там только пишут что нужно всю работу с памятью затолкать в try{ .... } exept, отлавиливать все исключения  и чтобы обязательно  был ProbeForWrite

[Ochkarik]

а lockMemory там нет?

[Ochkarik]

http://msdn.microsoft.com/en-us/library/cc264614.aspx

When a driver receives an IRP that specifies an I/O operation using neither buffered nor direct I/O, it must do the following:

1 Check the validity of the user buffer's address range and check whether the appropriate read or write access is permitted, using the ProbeForRead and ProbeForWrite support routines. The driver must enclose its accesses to the buffer's address range within a driver-supplied exception handler, so that a user thread cannot change the access rights for the buffer while the driver is accessing memory. If the probe raises an exception, the driver should return an error. The driver must call these routines within the context of the thread that made the I/O request; therefore, only a higher-level driver can perform this task.
2 Manage buffers and memory operations in one of the following ways:
   -- Carry out its own double-buffering operations, as the I/O manager does for drivers that use buffered I/O. For more information, see Using Buffered I/O.
   -- Create its own MDLs and lock down the buffer by calling the memory manager's support routines, as the I/O manager does for drivers that use direct I/O. For more information, see Using Direct I/O.
   -- Perform all necessary operations on the user buffer directly in the context of the calling thread. The driver must wrap its access to the buffer within a driver-supplied exception handler, in case a user thread changes either the access rights for the buffer or the data in the buffer while the driver is accessing memory. For more information, see Handling Exceptions.

ЗЫ думайте ушел спать

[GG_shara]

Ochkarik,
 читал эту тему...
Думал, что третий вариант
"- Perform all necessary operations on the user buffer directly in the context of the calling thread. The driver must wrap its access to the buffer within a driver-supplied exception handler, in case a user thread changes either the access rights for the buffer or the data in the buffer while the driver is accessing memory. For more information, see Handling Exceptions."

и означает, что мы просто берем и модифицируем данные нужным нам спосбом...  посредством "затолкать в try{ .... } exept, отлавиливать все исключения,  и чтобы обязательно  был ProbeForWrite "

Наверное, имеет резон попробовать первые два способа.))

Ochkarik, спасибо за надание пинка в нужном направлении.

[Ochkarik]

поищите в DDK и на OSR у Они - были ссылки о том как с памятью работать. СОВСЕМ не факт что fastIO вызывается в том же контексте вызываемого процесса. уже не помню.
и вопрос - правильно ли вы отделяете именно не прямой метод обращения к буферу...

[GG_shara]

в принципе я был прав, при идентификации "никакого метода"  чтобы получить доступ к пользовательскому буферу, нужно все операции завернуть в try{}exept и проверить валидность буфера. моя проблема была в том, что во время записи на диск пользовательский буфер доступен ТОЛЬКО  для чтения...  я не обращая внимания на ProbeForWrite пытался МОДИФИЦИРОВАТЬ его. ну естесенно что система с грохотом умирала при этом ))

теперь столкнулся с другой проблемой, данные при записи то мне все равно НАДО модифицировать, а буфер закрыт (читай нехочу, а вот модифицировать низя)
походу придется свой IRP отправлять с "правильными" данными, а перехваченый - убивать

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

не знаешь, может есть еще способы решения данной проблемы?

СОВСЕМ не факт что fastIO вызывается в том же контексте вызываемого процесса

плохо... буду искать в доках... прошу помочь хотя бы с приблизительным ориентиром поисков (я покаместь новичёк в драйверосторении)

правильно ли вы отделяете именно не прямой метод обращения к буферу...

(не прямой, я так понимаю "никакой") думаю да. хотя особо не задавался этим вопросом (раз не Buffered и не Direct I\O значит "Никакой" )))))

[Ochkarik]

а если после обработки - восстанавливать исходные данные?
если ProbeForWrite не выходит - значит стоит флаг у сегмента что он только на чтение. модификация флага через таблицу... запамятовал) GDT что ли... посмотрите у Руссиновича.
через таблицу - это несколько кривоватый метод будет... если данных не очень много (не десятки МБайт/сек)- лучше копировать.

почитайте Руссиновича. там очень  хорошо все расписано было.
PS и у Уолтера Они

[GG_shara]

алгоритм восстановления данных хоть и обратимый но трудоемкий (шифровать хочу)

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

блин, походу точно буферизацию прийдется делать с отменой ИРПов   

с чтением из файла таких проблем походу  быть не должно, там все просто в буфер прочитали туда же его же и расшифровали

[Ochkarik]

Они - есть на русском. очень рекомендую - много времени экономит.
во втором издании 2007 года. это "глава 7 чтение  запись данных". 350 страница. подраздел "третий метод")
"если не установлен один из флагов DO_DIRECT_IO или DO_BUFFERED_IO, по умолчанию IOменеджер просто передает виртуальный адрес пользовательского режима и количество байтов."
(  stack->Parametrs.Read.Length или   stack->Parametrs.Write.Length)
"НИКОГДА не пытайтесь просто обратится к памяти по указателю, полученному из пользовательского режима"
обращение с использованием:
if (Irp->RequestorMode != KernelMode)
{
  _try
  {
    IoAllocateMdl() + MmProbeAndLockPages()
    или     
    ProbeForRead()
    после собственно обращение к памяти
  }
  _except(...) { .....}
}

[Phodopus]

Написал простенький драйвер-фильтр ФС.
IRP'ы и FastIO запросы перехватываю, как по учебнику.

Что за учебник? Есть ссылка?! 

[GG_shara]

Phodopus,
ну на самом деле конкретного учебника нет
я их много читал.
а вообще вот здесь https://forum.shelek.ru/index.php/topic,14645.0
модератор все достойные учебники перечислил и коменты к ним неплохие дал (за что ему от меня личный респект)

Ochkarik,

блин, походу точно буферизацию прийдется делать с отменой ИРПов   

меня посетила другая мысль. при "Neither method" можно подменить значение указателя Buffer (при обратотке FastIOWrite) или pIRP->UserBuffer (при обработке IRP_MJ_WRITE) на любой другой - нужный нам буфер.

проверил догадку - все работает отлично.

теперь хочу сделать следующуее: мы имеем (в контексте процесса пославшего запрос к драйверу) адрес на буфер в котором хранятся данные. выделяем новую область памяти(в адресном пространстве того же процесса) и заполняем ее требуемым нам образом. после чего просто подменяем адрес исходного буфера вновь созданным. и никакой  отмены ИРПов, со всеми вытекающими, уже не надо, а просто отправляем запрос дальше по стеку (исходный буфер мы естеснно не модифицируем)

 это решение мне в разы больше нравится чем предыдущее.

из возможных "подводных камней":
1. как правильно выполняясь в контексте приложения выделить новый блок памяти чтобы ничего собой случайно не затереть? думаю простым mallc() отделаться не удастся =(    и как потом этот-же блок правильно освободить?? меня порядком смущает тот факт что мы каждый раз выполняемся в контексте другого процесса... (хранить список все буферов выделенных в каждом процессе.. некрасиво как-то...)

2. как быть с FastIO?
ты говорил что далеко не факт что они гарантированно выполняются в контексте процесса..
такая неопределенность сильно смущает. и одна из причин в том что ProbeForRead нельзя юзать в КернелМоде (а как это проверить при обработке FastIO ума не приложу. метод "if (Irp->RequestorMode != KernelMode) { ProbeForXxx(); }" тут явно не катит)
да и вообще, если мы не в контексте процесса обрабатываем FastIoWrite то ОЧЕНЬ вряд ли что PVOID Buffer будет ссылаться прямиком на ту область памяти что нам нужна... а это дополнительные нюансы которые нужно учесть... но для этого их нужно как-то отследить

3. в WDK пишут "only highest-level drivers, such as FSDs, can use this method ..." если я пишу драйвер фильтр,
обычно он будет первым в стеке до тех пор пока кто-то еще не решит добавить еще один фильтр, который станет поверх меня. как сего избежать и остаться на верхушке стека раз это так кретично?


очень интересует авторитетное мнение на сей счет =)

[Ochkarik]

насчет подмены указателя - как говорится "правильно мыслишь, Шарапов!")))
далее...
1. функция кажется была - надо искать. если я с ring-3 функциями не путаю.
откуда malloc - в ядре? не пугайте меня)
строчки Irp->RequestorMode != KernelMode я, честно говоря, сам не очень понимаю... подразумеваются запросы от процесса(нити) созданного в kernel, что ли?
хранить список буферов для каждого процесса - смотря какая обработка. возможно их можно локально  в функции создавать, и перед выходом уничтожать. чего их потом хранить то?

2.  я не так говорил) я говорил "не факт" в том смысле, что неплохо бы проверить - а как оно на самом деле) а точнее почитать DDK и Руссиновича с Они. - вот это надо понять в первую очередь.

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

[jne100]

>> строчки Irp->RequestorMode != KernelMode я, честно говоря, сам не очень понимаю

Из Они: "RequestorMode will equal one of the enumeration constants UserMode or KernelMode, depending on where the original I/O request originated. Drivers sometimes inspect this value to know whether to trust some parameters." Т.е. если посылка IRP была инициирована из UserMode, как в большинстве случаев и происходит, RequestorMode равен User. Если же RequestorMode равен KernelMode, пакет был послан другим драйвером из KernelMode`а (скажем при помощи IRP_MJ_INTERNAL_CONTROL), и следовательно у него нет ассоциированного с ним виртуального UserMode пространства и никакого контекстно зависимого указателя он передать не мог, как-то так

[GG_shara]

и снова я
всем драсте 

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

в общем решил потестить я свое творение на Виндосовсом Notepad.exe (он же Блокнот)
и столкнулся с проблемой что при чтении файла с диска подмена буферов не сработала, то есть блокнот прочитал именно то что было сохранено в файле
хотя при записи на диск подмена буферов работает нормально

в своем фильтре я перехватываю все IRP_MJ_READ\WRITE и FAST_IO_READ\WRITE целевого приложения

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

  файлмпинги там всякие...

[Ochkarik]

посмотрите notepad.exe при помощи DependencyWalker-а. он вам покажет используемые notepad.exe функции API.
помимо CreateFileW используется так же CreateFileMappingW/MapViewOfFile - через что работает не знаю...
если установлен Syser или Softice - попробуйте поставить бряки на эти функции. посмотрите чем он открывает эти файлы. пройдитесь по стеку выполнения. ну и интернет конечно)

ищите что нибудь типа http://www.google.ru/search?hl=ru&newwindow=1&q=CreateFileMapping+NtMapViewOfSection+IRP&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=&aq=f&oq=
и конечно же http://www.google.ru/search?q=IRP_MJ_READ+notepad

http://www.osronline.com/showThread.cfm?link=72139
посмотрите http://www.rsdn.ru/forum/asm/2668640.all.aspx
ЗЫ форумы wasm не открываются - смотрите сохраненные googl-ом страницы
там кажется что то с декодированием имени не так... что ли..
и отпишитесь - что получилось по поиску) самому интересно)

[GG_shara]

в ходе тестирования фильтра заметил что порой приходит IRP_MJ_READ метод чтения "НИКАКОЙ", у которого IRP->UserBuffer равен нулю.  что интересно, этот запрос приходит не от UserMode (как обычно при чтении) а из KernelMode
роя документацию по WDK нашел что с этим делать - по сути данные передавались как MDLAdress и когда я его успешно обработал - по содержимому буфера стало видно что это подопытный файл. я подозреваю что это операционка кеширует файл из-за того что Блокнот "грешит" GreateFileMaping\MapViewOfFile
в доказательство могу сказать что при повторном обращении к тому же файлу (перед этим Блокнот был специльно закрыт) мой фильтр не зафиксировал никаких телодвижений к файлу  со стороны Блокнота кроме IRP_MJ_CREATE
но поскольку файл был успешно получен Блокнотом - следовательно данные были взяты из кеша.
либо кто-то другой прочитал файл а затем неким магическим  образом передал его в блокнот

в  общем буду думать как бороться с маппингом
есть идея касательно пост-обработки IRP_MJ_CREATE если FileObject->SectionObkectPointer->DataSectionObject != 0 то данные уже загружены в памяти (т.е. прокешированы) дальше нужно раскуривать по ходу движения

если есть мысли на сей счет буду рад услышать..

[GG_shara]

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

[GG_shara]

цитата из книги Внутреннее устройство Microsoft Windows (гл. 11)
Марк Руссинович   Дэвид Соломон   

[Ochkarik]

хм.. прикольный метод) надо будет взять  на вооружение) получается  IRP запросы фактически могут быть подменены  программными прерываниями на уровне PASSIVE_LEVEL... как при обращении к свопируемой памяти)  тогда получается, что надо либо хуки на мапирование как-то ставить, либо.... на прерывание подкачки страниц садится, что как-то кривенько выглядит...
хм. а действительно, какими функциями операционка подкачку виртуальной памяти осуществляет? механизм при мапировании файла видимо тот же должен использоваться?

я правильно понял что все удалось побороть путем "правильной" обработки  IRP_MJ_READ от KernelMode? или пока в процессе?) то бишь не получается сами данные отловить?

[GG_shara]

получается да
если ОС предварительно прокешировала какой-либо файл
и некая программа пытается прочитать его --> пошлет IRP_MJ_CREATE при пост обработке которого в FileObject->SectionObkectPointer->DataSectionObject будет не 0 (я так понимаю это будет адрес в памяти куда был прокеширован сей файл) и как следствие ФС не получит запрос IRP_MJ_READ на чтение данных. тоесть данные как пойдут в обход драйвера ФС, поскольку данные уже прокешированы в память и программа на свой запрос получит MapView на этот файл.

я думаю что хучить и спуфить функции Диспетчера Кеша дело неблагодарное хотя  вполне реальное.  уж слишком тонко работает этот механизм, и малейшая неточность приведет к очень нежелательным последствиям. это все из того же Руссиновича.

 думаю чтобы решить сию проблему, нужно просто загрузить свой фильтр перед тем как запуститься Диспечер кеша в процессе загрузки винды. я уверен в том что он все равно работает через драйвер ФС.

кстати, если интересно могу более детально рассказать об этом  IRP_MJ_READ с "НИКАКИМ" методом чтения из KernelMode. просто у меня все это дело на работе, а наизусть я всего не помню - могу и приврать немного =)

[Ochkarik]

если раскажите - было бы великолепно) дополнительный опыт никому не помешает)))
хучить функции ядара действительно  как-то некрасиво...
но я так понял что отловом такого CreateFile обращения к файлу - вопрос модификации(IRP_READ_FILE) данных не решается? если только не... можно попробовать тоже отмапировать тот же файл драйвером и получить указатель на ту же память(если это возможно в ядре)? это раз.
второе: можно произвести фиктивную запись в файл - таким образом кэш перестанет быть валидным, хотя вряд ли это приведет к переоткрытию файла приложением... о! сметить туда-обратно имя? винда может сбросить кэш. хотя это тоже не красиво.

[GG_shara]

совсем забыл
нужно мнение эксперта, если в структуре FileObject незаметно смодфицировать пару неиспользуемых байт какого-нить read-only члена. сильно ли это огорчит ОСь? что вообще значит эта грозная надпись в WDK read-only?
я вот туда write свои лапы =) и никто ниче усе работает как раньше

[GG_shara]

"но я так понял что отловом такого CreateFile обращения к файлу - вопрос модификации(IRP_READ_FILE) данных не решается?" - нет, не решается потому что он (IRP_MJ_READ) вообще не приходит.

а насчет метода "пошевелить файл" чтобы его заново откешировали.. если я правильно понял Русиновича то файл не сразу запишется на диск, мы отфодифицируем данные в памяти, на которые сылается исходное приложения и все все все остальные. это уже потом когда-нибуть это новое представление файла будет записано на диск ... вроде как-то так

про IRP из KernelMode расскажу, но уже завтра (кстати кажется ты говорил читать дословно DDK, я это все именно там и вычитал )

[GG_shara]

"но я так понял что отловом такого CreateFile обращения к файлу - вопрос модификации(IRP_READ_FILE) данных не решается? если только не... можно попробовать тоже отмапировать тот же файл драйвером и получить указатель на ту же память(если это возможно в ядре)? это раз."
это конечно мысль - мне она самому в голову приходила, но первое как это сделать? просто в тупую через NtXxx функции попытаться прочесть файл? или прибрать к рукам адрес MapView в памяти? ИМХО  уж слишком оно накручено выйдет
с точки зрения надежности это не лучшее решение, а как по  мне - то чем надежней и быстрее тем лучше. посему буду пробовать грузиться как можно раньше и уже тогда ДиспетчеруКеша отдам "правильные" данные

З.Ы. я с Вашего разрешения на ты перейду =)

[Ochkarik]

1. означает только то что означает... значит трогать на надо))) а иначе - как повезет...  стабильности это точно не прибавит. а точно - только microsoft знает) тут я пас... хотя пофантазировать можно. но это лучше применительно к цели фантазировать) допустим мы меняем структуру. дальше фантазии на тему: кто после этого будет ей пользоваться) создается она видимо при открытии существует до закрытия файла.
а дальше надо думать - что меняем, и кому в дальнейшем "оно" может потребоваться для работы) ну и... поле для фантазий)


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

3. кстати может что нибудь из этого раздела пройдет? разбираться правда... но в любом случае просмотреть раздел стоит)
http://msdn.microsoft.com/en-us/library/ms791433.aspx
http://msdn.microsoft.com/en-us/library/ms791417.aspx
http://msdn.microsoft.com/en-us/library/ms791427.aspx

ЗЫ сколько же в ядре функций... я офигеваю) раньше этот раздел и не открывал толком ни разу)
ЗЗЫ запросто)

[GG_shara]

"кто после этого будет ей пользоваться" --> ну как кто будет пользоваться, я естесенно =)
"cоздается она видимо при открытии существует до закрытия файла" --> да, я хочу как-то пометь структур принадлежащую определенному файлу. чтобы он был особенным по сравнению с другими. и это было сразу видно при обработке других IRPов и FastIO. а помечать хочу при IRP_MJ_CREATE

собсно в FileObject есть одно поле в котором храниться ULONG Flags всего 28 флагов, а ULONG как мы знаем имеет 32 бита т.е. 6 бит мы можем спокойно лапать и нам за это по идее ничего не будет
вот и я лапаю их... и вроде бы ничего нет

насчет 2го пункта +1. хотя можно лапать файл после того как обработали его IRP_MJ_CREATE (ох и любю же я этот ИРП)))  думаю где-то там можно найти и хендел на файл...

посмотрел сие обилие функций  - и очень надеюсь что с ДиспетчеромКеша тягаться не прийдется 

[Ochkarik]

ну во-первых, то что используются только 28 флагов не говорит о том что через пару-тройку лет майкрософт не введет еще парочку)
про существование до закрытия... а вы уверены что FILE_OBJECT создается персонально для вас а не на все открытые копии файла? - вопрос...
а чего его лапать после IRP_MJ_CREATE если он уже отмапирован?)
обилие... да не такое оно и страшное на первый взгляд....
http://msdn.microsoft.com/en-us/library/ms791436.aspx
а дальше набор read/write/copy функций.

PS грубо говоря... очень грубо)

[Ochkarik]

и самое забавное)
http://msdn.microsoft.com/en-us/library/ms791422.aspx
стоит попробовать?)