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

[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
стоит попробовать?)

[GG_shara]

"через пару-тройку лет майкрософт не введет еще парочку)" да.. они могут...

"а вы уверены что FILE_OBJECT создается персонально для вас а не на все открытые копии файла?"  а вот этого я не понял
там есть еще поле RelatedObject и кажется еще что-то в этом духе
и кстати, если созасться другой файл обжект то я и его помечу =) =)


"CcIsFileCached

The CcIsFileCached macro determines whether a file is cached or not.
"  ) уря                        ---> завтра отпишусь =)

[Ochkarik]

ну... вы открываете файл: диспечер файловой системы (или как его там) создает под него FILE_OBJECT и дает вам указатель на него.
вы не закрыли файл, но его открывает кто то еще - а теперь вопрос:
для второго пользователя создается и инициализируется новая структура FILE_OBJECT или отдается ссылка на первую?

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

[GG_shara]

"для второго пользователя создается и инициализируется новая структура FILE_OBJECT или отдается ссылка на первую?" а все равно
ибо

 если созасться другой файл обжект то я и его помечу =) =)

цель то пометить ФАЙЛ а не FileObject

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

[Ochkarik]

законность не очень) пока никто не видит - не посадят) а если заметят....))))
PS баиньки пойду) доброй ночи)

[GG_shara]

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

собсно лучше рассказать про "никакой метод" чем в WDK  я не смогу =)

[GG_shara]

Цитата(Олифер В.Г. "Сетевые ОС" Глава 8. "Дополнительные возможности ФС")
"
 Дисковый кэш располагается между слоем драйверов файловых систем и блок-ориентированными драйверами. При поступлении запроса на чтение некоторого блока диспетчер дискового кэша просматривает свой буферный пул, находящийся в системной области оперативной памяти, и если требуемый блок имеется в кэше, то диспетчер копирует его в буфер запрашивающего процесса. Операция ввода-вывода считается выполненной, хотя физического обмена с устройством не происходило, при этом выигрыш во времени доступа к файлу очевиден.

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


я решил проверить свой фильтр чем-то более авторитетным. ну малоль, может я действительно пропускаю некторые IRPы и поэтому не получается ВСЕГДА подменить данные которые циркулируют между приложением и ФС. взял утилиту ProccesMonitor v2.8 настроил его так чтобы показывать любые поползновения ОС в сторону подопытного файла "test.txt"
в результате было видно что Notepad.exe на прямую не посылает запросов чтения (IRP и FastIO) к этому файлу. за него это ТРИ раза делает Explorer.exe (первый раз он читает файл в кеш) и еще два раза ХЗ зачем он туда лезет...

кстати еще один нюанс, есть функция CcPurgeCacheSection которая очищает кеш  файла по его FileObject. я использую ее при обработке IRP_MJ_CREATE если вижу что целевой файл КЕШИРОВАН. т.е. принудительно очищаю кеш. и эффект был весьма положительный. Блокнот послушно читал из файла то что я ему подсовывал в IRP_MJ_READ (FastIO) не зависимо от того кто\что и сколько раз писали в этот файл ранее

есть большое желание разобраться как ДиспетчерКеша работает с драфверами ФС и фильтрами ФС,
покаместь, я думаю, что если требуемая часть файл имеется в ОЗУ - запросы типа IRP_MJ_READ (FastIORead) не послылаются воовсе... вместо этого данные сразу перекладываются в пользовательский буфер (возможно мапируются) без создания и отправки  по драйверскому стеку каких либо дополнительных IRPов.

в общем счеит сейчас  2:1 в пользу Windows 
буду думать дальше... 

[Ochkarik]

а почему 2:1? CcPurgeCacheSection не  решает проблемы? или осталась проблема отлова обращения к файлу? но это опять(насколько я понял) разрешимо если драйвер загружен при старте OC по SERVICE_BOOT_START/SERVICE_SYSTEM_START или нет? в конце концов есть еще CcFlushCache для всего.
или вы хотите более изящно поработать через что нибудь, типа CcInitializeCacheMap?

PS CreateFile ловится всегда? или только если ранее не кэшировно? я немного запутался)

[GG_shara]

проблема вот в чем
когда файл читается впервые:
 1. данные читаются с диска
 2. мой фильтр перехватывает их и расшифровывает
 3. данные в расшифрованном виде грузятся в кеш

затем, если данные в процессе работы обновляются и затем сохраняются на диск:
 1. мой фильтр перехватывает записываемые данные и зашифровывает их
 2. в зашифрованном виде они попадают на диск и в кеш. 

при последующем чтении данные уже не читаются из диска, а грузятся из ОЗУ (поскольку данные кешированы) сразу в память процесса. и получается так что этот момент я упускаю - notepad.exe получает данные в зашифрованном виде ВМЕСТО того чтобы получить читаемый текст

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

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

второй & третий способы ХЗ как сделать... перехватывать выховы CcCopyRead\Write?? О__о вроде официально таких способов нет..

а насчет "SERVICE_BOOT_START/SERVICE_SYSTEM_START или нет?" ДА ДА и еще раз ДА. огромная куча всевозможных тонкостей и нюансов.. кеш штука хитрая

PS CreateFile ловится всегда? или только если ранее не кэшировно? я немного запутался) - всегда (ну или я не замечл чтобы я его не видел )
но вот чтение\запись не всегда удается отследить. во всяком случае для notepad.exe. у меня такое ощущение что он вообще паразитирует на explorer.exe или svchost.exe только они юорзают файл когда я из нотепада хочу прочитать что-либо

 на сайте OSR нашел пару статей из цикла как отловить FILE_OBJECT (покаместь перевариваю их) но что я из них понял что простого сравнения двух юникодовских строк при IRP_MJ_CREATE недостаточно чтобы однозначно отловить FILE_OBJECT

[GG_shara]

З.Ы. 2 :1 потому что перехватывать файлы получилось а вот правильно обуздать кеш нет =)

[GG_shara]

форсировать использование флага  FILE_NO_INTERMEDIATE_BUFFERING     нельзя

сделал рабочий!! фильтр который шифрует данные на стадии записи\чтения инфы из диска в кеш
т.е. в кеше хранится информация в открытом виде. от Диспетчера Кеша всегда приходят запросы из KernelMode у которых стоит метод НИКАКОЙ (NEITHER) и IRP->MdlAddress != 0

хотелось бы еще попробовать сделать два оставшихся варианта, с отключением кеша, и с хранением инфы в кеше в шифрованном виде...


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

не подскажите как быть с записью? при записи шифрую информацию в буфере, затем опускаю запрос ниже по стеку, а в пост_обработчике IRP_MJ_WRITE повторно шифрую буфер (т.е. восстанавливаю исходное состояние данных) шифр на основе гаммирования. не хочется дважды запускать процесс шифрования.. была высль веделить буфер в который записать шифрованную ифу и подменить адрес в IRP->MdlAddress на него, но тогда идет двойной расход памяти....  может можно что-то придумать более гуманное? 

(выложил не весь исходник, а лишь критически важные секции) т.е.  процесс инициализации драйвера и установки обработчиков частично опущен

[Ochkarik]

вызов ExRaiseStatus() - к чему приводит? не использовал ни разу...
вечером постараюсь посмотреть... на работу пора)

[GG_shara]

ExRaiseStatus() приводит к тому что мы выйдем за границы try { /* ... */ } except блока с определенным статусом, который отловит GetExceptionCode()

ну или мы вывалимся в БСОД если не обработаем, или не сделаем вид что обработали, установленный статсус 

[Ochkarik]

просмотрел до конца.
одно замечание в IntcLockUserBuffer() выделяется IoAllocateMdl() а IoFreeMdl() для  нее вызывается только по except(EXCEPTION_EXECUTE_HANDLER). - утечка памяти?
и еще пара вопросов:
IS_INTC_DEVICE_OBJECT() и подобные проверки - разве необходимы? (хотя выглядит достаточно параноидально)))

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

[GG_shara]

одно замечание в IntcLockUserBuffer() выделяется IoAllocateMdl() а IoFreeMdl() для  нее вызывается только по except(EXCEPTION_EXECUTE_HANDLER). - утечка памяти?

я тоже думал его в ручную освобождать, но потом прочитал вот это:
"..When the IRP is completed, the system unlocks and frees all the MDLs that are associated with the IRP. The system unlocks the MDLs before it queues the I/O completion routine and frees them after the I/O completion routine executes...." http://msdn.microsoft.com/en-us/library/aa489506.aspx

будем верить документации 

IS_INTC_DEVICE_OBJECT() и подобные проверки - разве необходимы? (хотя выглядит достаточно параноидально)))

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

[GG_shara]

з.ы. OFFTOPIC
смайлы на форуме бомба

[Ochkarik]

да, но у вас MDL - локальный. вы его только для MmProbeAndLockPages() используете. а в IRP об этом ни одной ссылки не останется.

When the IRP is completed, the system unlocks and frees all the MDLs that are associated with the IRP. The system unlocks the MDLs before it queues the I/O completion routine and frees them after the I/O completion routine executes.

но

When a driver calls IoAllocateMdl, it can associate an IRP with the newly allocated MDL by specifiying a pointer to the IRP as the Irp parameter of IoAllocateMdl. An IRP can have one or more MDLs associated with it. If the IRP has a single MDL associated with it, the IRP's MdlAddress member points to that MDL. If the IRP has multiple MDLs associated with it, MdlAddress points to the first MDL in a linked list of MDLs that are associated with the IRP, known as an MDL chain. The MDLs are linked by their Next members

[Ochkarik]

упс. виноват! Irp в параметрах IoAllocateMdl  не заметил)
возражения снимаются)

[GG_shara]

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

.. а насчет двойного шифрования при записи никаких мыслей нет?

[Ochkarik]

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

получается что нешифрованные данные в кеше - это правильно. либо надо дополнительно перехватывать MapViewOfFile(или разбираться с менеджером кеша  )

[GG_shara]

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

 мысль очень павильная - я к ней сам пришел после полевых испытаний и чтения доков 

походу оставлю покаместь все как есть, походу не самый плохой вариант получился.

у меня вот только один вопрос возник, с которым пытаюсь сейчас разобраться. а что собсно происходит с кешем в процессе того как он сохраняется на диск? ну если кто-то вдруг вздумает его изменить..
я покаместь не могу себе четко представить эту картину    
в случае если мы на прямую шифруем\расшифруем данные в кеше, это ВЕСЬМА критично. думаю надо как-то запрещать модификацию... или это уже за нас делает КешМенеджер


и еще один вопрос
кому возвращается управление после того как заврешиться ComplectionRoutine(..)?  я создаю и синхронно посылаю в низ свой IRP. при пост_обработке IRP_MJ_CREATE хочу узнать доп инфу о файле который был открыт.

Код:

// сорри код пишу по памяти с головы
//complecotion IRP_MJ_CREATE
{
... 
  my_irp = IoAllocateIrp (...);

  // инициируем IRPдля IRP_MJ_QUERY_INFORMATION

  SetComplectionRoutine (SomeComplectionRoutine, ...);

  IoCallDriver (my_irp, AtachetDeviceObject);

  KeWhaitForSingleObject(...); \\ ждем до упора
  \\ ну тут понятно, мы получаем статус от IRP_MJ_QUERY_INFORMATION
  \\ и обрабатываем инфу которую нам записали в буфер (который естеснно был зараниее припасен)
  return (IoStatus);
}


SomeComplectionRoutine(...)
{
  IoFreeIrp();

  return MoreProcessingRequired; \\ кому??? кто после этого получит управление
}

P.S.
я вот думаю,  когда закончу эпопею с фильтром - сей топик оформить как статью и повесть на форуме куданить. как думаешь?

[Ochkarik]

управление я так понимаю возвращается менеджеру. в том смысле что именно он должен вызывать ComplectionRoutine(), я думаю...
больше ведь некому) логично?)
я так понимаю что это должно выглядеть примерно так:
после IoCallDriver драйвер завершает обработку и....
блин, лень писать (у меня ноут на коленках, а на столе лечу второй от вирусов)
все уже написано) http://msdn.microsoft.com/en-us/library/ms795821.aspx

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

PS а статья - это было бы просто великолепно) в разделе статьи давно ничего не обновлялось(

[GG_shara]

с IoManager'ом разобрался, спасибо
вроде с отправкой IRPов собственного производства вопросов больше не возникает. Запрос успешно отправлен и обработан.   хыхы


сейчас вот столкнулся с другой проблемой

хочу каким-то образом пометить определенный файл чтобы драйвер мог его опознать как свой и ШИФРОВАТЬ или НЕ шифровать в противном случае.

надумал пока следующие варианты:

• опознавать файл по его имени
  например, если путь к файлу "С:\dir\MyFile.txt" то это нужный файл.
  смущает два вопроса, первый
          ГДЕ хранить список с именами файлов?
  второй
          КАК быть в случае когда файл принесен с другого компа, например на флешке, а он уже был помечен на том компе.
• помечать имя файла
  например, если обычный файл имел имя "MyFile.txt" то помеченный будет иметь имя "MARK_MyFile.txt"
  главный недостаток что имя файла уж очень легко изменить... крайне ненадежно
  и к тому-же может возникнуть крайне не приятная путаница с английскими буквами которые похожи на русские. английское 'A' и русское 'А' визуально почти не отличимы
• дописывать в конец файла свой блок информации
      и по наличию этого блока у файла уже опознавать файл.
  очень смущает тот факт что при этом  изменяется размер целевого файла. и плюс ко всему накладные расходы на открытие и чтение конца для ВСЕХ потенциально  "своих" файлов - сильно замедлит работу системы.
• использовать потоки
  тоесть к целевому файлу прикрутить поток с определенным именем. и по наличию у файла потока с именем ":MyStraem" выносить вердикт свой\чужой
      Единственный  и главный недостаток такого метода в том, что потоки поддерживаются не всеми ФС. NTFS поддерживает потоки, а вот FAT - нет. и при копировании файла у которого есть потоки на FAT все информация о потоках будет утеряна

Windows же как-то помечает файлы Скрытй, Архивный, Шифрованный, Только_Для_Чтения... можно ли как-то нечто подобное использовать и в своих целях?

даже не думал что столкнусь с такой проблемой...

OFFTOP
P.S. вирусам и прочей компутерной живности бой!  

[Ochkarik]

атрибуты хранятся в самой файловой системе насколько я понимаю)
http://msdn.microsoft.com/en-us/library/ee332330(VS.85).aspx
для модификации используется  ZwSetInformationFile
правда есть вопрос - какие переносятся в зависимости от типа файловой системы а какие нет... боюсь что на FAT переносятся только основные. так что вариантов мало.
другой вопрос - у меня даже на флешке NTFS стоит) стоит ли заморачиваться? ну принесет пользователь файл на 3.5 дискете... он просто не сможет его прочесть)
может быть подумать над комбинацией способов? в NTFS хранить в потоках/атрибутах. при копировании применять тот или иной метод, в зависимости от целевой платформы...
еще вариант - выставлять какую нибудь определенную дату-время, например CreationTime. ее конечно тоже можно изменить... или ShortName использовать (мало кто туда полезет... под виндой)
но опять же - для чего это надо? фактически только для удобства? ) понятное дело, что пользуясь ломом - можно все сломать)

ЗЫ соблазнительный атрибут FILE_ATTRIBUTE_ENCRYPTED - только NTFS) хотя, почему бы не подумать в эту сторону? http://msdn.microsoft.com/en-us/library/aa364223(VS.85).aspx

[GG_shara]

атрибуты хранятся в самой файловой системе насколько я понимаю)
http://msdn.microsoft.com/en-us/library/ee332330(VS.85).aspx
для модификации используется  ZwSetInformationFile

эх опять  руки чешутся "придумать" еще один   флаг типо FILE_ATTRIBUTE_MY_CRYPT  0x20000  и присвоить его файлу....
но это же не совсем "правильно" а если Билли вдруг решит придумать еще пару новых атрибутов к файлу..
или еще вариант   ZwSetInformationFile просто не позволит установить такой большой атрибут файлу по причине не существования онного в системе...

другой вопрос - у меня даже на флешке NTFS стоит) стоит ли заморачиваться? ну принесет пользователь файл на 3.5 дискете... он просто не сможет его прочесть)

к сожалению стОит заморачиваться. у меня например флеш под FAT (вообще только  сегодня обратил на это внимание   )

может быть подумать над комбинацией способов? в NTFS хранить в потоках/атрибутах. при копировании применять тот или иной метод, в зависимости от целевой платформы...

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

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

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

но опять же - для чего это надо? фактически только для удобства? ) понятное дело, что пользуясь ломом - можно все сломать)

не только для удобства. эт как бы переносимость .. там вяского рода защита от дурака.. ну хочется чтобы по людски было сделано... хотя лом это такая страшная штука! (с) Доказанно Г.Фримен  

ЗЫ соблазнительный атрибут FILE_ATTRIBUTE_ENCRYPTED - только NTFS) хотя, почему бы не подумать в эту сторону?

опять же только NTFS...  не понятно как быть если кто-то!! (я таких не видел, но все же) если кто-то зашифровал свое файло родными NTFS-способами?

эх... флаг мне в руки и маркировать им файл чтоле?
а так хочется юзать потоки....

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

пока писал пробилась мысль:
сделать комбинацию двух последних методов
потоки как основной а флаг - для FATa и прочих
остается вопрос как отследить копирование файла между ФС. Бум думать. Благодарю за внимание и пинок в нужном направлении    
 


жжесть флагггг 

[Алексей++]

GG_shara, можно сделать пометку во времени создания/изменения файла, а ещё есть поля "сводка" - там можно набацать своего мусора

[GG_shara]

оп, что за сводка?. не слыхал о такой
чем ее можно пощупать?

[Алексей++]

видно её в свойствах файла, а как добраться программно - я не разбирался


ещё жёсткий вариант - в расширение набацать сигнатуру или контрольную сумму

[Ochkarik]

сводка файла - на основании потока с названием Summary Information
ЗЫ кстати дописывать свой блок к файлу - почему бы и нет? для FAT. а для NTFS - основное - потоки.
хотя для быстродействия хорошо бы список хранить... да и расширение застолбить... тоже вариант.
и интересно... кто назначает короткое имя файла?) можно застолбить расширение в коротком имени, а длинное будет отображаться в системе)

[GG_shara]

нарыл интересную ссылку http://roddotnet.blogspot.com/2008/06/how-to-set-custom-attributes-file.html по теме

сводка файла - на основании потока с названием Summary Information

что-то я смотрел все потоки у файла через IRP_MJ_QUERY_INFORMATION c параметром FileStreamInformation и такого потока там не видел..    может плохо смотрел?

а короткое имя эт ж, вроде, первые 8мь букв имени файла?

[Ochkarik]

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


PPS вот здесь http://msdn.microsoft.com/en-us/library/ms804363.aspx
есть поле  FileShortNameInformation

[GG_shara]

Ochkarik, оке.
у меня мыслей уже куча,  после выходных и праздников буду воплощать в жизнь

ну а пока всю прекрасную половину человечества с наступающим

[Алексей++]

Ochkarik, вообще-то, имя файла одно , просто короткое можно сделать из длинного

имя длинное.одна штука
->
имя_дл~1.одн

[Ochkarik]

Алексей1153++,не все так просто) насчет того что оно "одно" - это не есть правильно)
например короткое имя файла можно изменить не меняя длинного имени файла:
ZwSetInformationFile() с параметром FileInformationClass == FileShortNameInformation
а для изменения длинного имени можно сделать вызов той же функции, но  с параметром FileInformationClass == FileRenameInformation
тут собственная специфика)  по умолчанию оно выставляется так как ты написал) да и то... что будет если файла два?)
"имя длинное.одна штука_первый"
"имя длинное.одна штука_второй"
кто из них станет имя_дл~1.одн а кто имя_дл~2.одн ? - зависит от очередности создания. и может изменится при другой очередности копирования в другую папку.... не все так просто)
 
GG_shara,  по поводу доп-атрибутов - возможно один из перечисленных ранее способов использует FILE_EA_INFORMATION http://msdn.microsoft.com/en-us/library/dd852082.aspx но скорее всего это тоже какой нибудь "системный" поток NTFS...

и к сожалению про короткие имена тоже оказалось не лучшим полем для наших целей:
http://msdn.microsoft.com/en-us/library/ms793819.aspx

The short name for a file is the short (8.3) name for the final component of the file name. Because it is generated when the file is opened, the short name is not available for an unopened file object, and it is not available in the create dispatch ("pre-create") path. It is also not available for NTFS stream file objects. Not all open files have short file names. For example, on NTFS partitions where short file name generation has been disabled, no files have short file names.

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

и к тому же
http://msdn.microsoft.com/en-us/library/cc308453.aspx

FileRenameInformation, FileShortNameInformation, and FileLinkInformation

This applies when the following operations are being performed on a file or stream:

1 The file or stream is being renamed
2 A short name is being set for the file
3 A hard link is being created for the file

[GG_shara]

по поводу доп-атрибутов - возможно один из перечисленных ранее способов использует FILE_EA_INFORMATION http://msdn.microsoft.com/en-us/library/dd852082.aspx но скорее всего это тоже какой ибудь "системный" поток NTFS...

блин нужно проверять.. ЕКСТЕНДЕТ_АТРИБУТС очень интересное поле. если оно еще и в FAT поддерживается то тогда это как раз то что нужно. поидее нужно проверять

[Ochkarik]

ага) копать надоть)

PS в FAT - очень вряд ли...

[x64]

в  общем буду думать как бороться с маппингом

File mapping работает через Paging I/O, т.е. пакеты ввода/вывода с соответствующими флагами.