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

[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