Чуть больше, чем мастер ... или работа с ОС XP на низком уро

[XC™]

Мне надо всего-навсего перехватить обращение к файловой системе или к диску  в XP и разрешить либо запретить выполнения перехваченной операции .
Перехват API - не помог . Драйвер помог только на 98 ...
Помогите пожалуйстя !!!
Чуть больше, чем мастер -
Не один мастер Delphi мне еще не ответил на этот вопрос ... и вообще - я просто хочу учиться ...

[grozny]

А как делался перехват API? Низкоуровневым хуком (с суффиксом _LL ?) Или как-то ещё?

[SlavaI]

Мне надо всего-навсего перехватить обращение к файловой системе или к диску

Если только это, то вот тебе 100% правильное решение
1) для перехвата обращений к файловой системе, достаточно простого драйвера фильтра файловой системы, не пугайся рассказов о сложности фильтров файловых систем- это так только в случае если ты пытаешься нетривиально модифицировать передаваемые данные, для простого анализа и отклонения запросов все очень просто. Самая большая сложность тут- не трогать запросы от VMM, посланные на страничный файл, а также желательно не трогать запросы на подгрузку страниц в секции, но если это для юзер мода- можно отклонять. Все запросы к страничному файлу легко вылавливаются, если надо скажу как.
2) Перехват обращений к дискам- тут есть тонкость. Если на диск(раздел) смонтирована файловая система то ВСЕ интересные для тебя обращения чтения, записи и IOCTL пойдут сначала через нее(то есть тут ты их поймаешь на фильтре файловой системы), потом они будут переданы на DEVICE_OBJECT одного из драйверов- ftdisk.sys или dmio.sys, а уже с них на драйвер disk.sys. Первые два драйвера отвечают за разделы на диске, третий драйвер за разделы и весь диск(то есть запросы, адресованные всему диску пойдут на него, например модификация таблицы разбиения). Обращаю внимание- пользовательское приложение без привилегий админа не сможет напрямую работать через disk.sys.

[point]

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

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

point.

[SlavaI]

а получение нормализованного имени файла весьма трудоемкая операция...

Да ладно пугать. IRP_MJ_CREATE идет с полным именем, только нет имени диска- но это элементарно узнается или через FILE_OBJECT или через VPB. На IRP_MJ_READ/WRITE уже подправленный FILE_OBJECT, но все запросы можно прикрыть в момент создания FILE_OBJECT, или хранить соотвествие FILE_OBJECT- имя, созданное в момент обработки IRP_MJ_CREATE в фильтре.

[point]

"Да ладно пугать. IRP_MJ_CREATE идет с полным именем"

угу, особенно если учесть что имя бывает короткое и длинное, плюс related & полное, плюс комбинации длинных и коротких имен в пути, плюс FileID, плюс streeam file object, hard links...
Вам понравится...

point

[SlavaI]

угу, особенно если учесть что имя бывает короткое и длинное, плюс related & полное, плюс комбинации длинных и коротких имен в пути, плюс FileID, плюс streeam file object, hard links...
Вам понравится...  

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

[point]

Про такую вещь как собственный запрос IRP_MJ_QUERY_INFORMATION из твоего фильтра на нижележащий драйвер файловой системы слышал?

[SlavaI]

Хмм. Что-то не так? Я не понял, что ты хотел сказать.

[point]

Про такую вещь как собственный запрос IRP_MJ_QUERY_INFORMATION из твоего фильтра на нижележащий драйвер файловой системы слышал?

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

в общем чтобы закончить обмен бессмысленными заявлениями я дам ссылки на ресурсы посвященные file system filter devs

http://www.osronline.com - нужно зарегестрироваться (бесплатно) тогда станут доступны статьи и многе другое.
http://www.osronline.com/article.cfm?id=17 - IFS FAQ
http://www.ntfsd.org - архив конференции по FileSystem drivers


point.

[SlavaI]

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

Дабы закончить- нет там никакой рекурсии, я же призываю не функцию ядра вызывать, которая зашлет запрос сначала на фильтр, а сделать свой IRP, и слать его сразу на драйвер файловой системы- никакой рекурсии нет. А способ обхода рекурсии при использовании ф-ций ядра давно известен- создание вторго DEVICE_OBJECT для твоего фильтра и засылки запросов на него, на osr он где-то описан, есть в IFSD.

[XC™]

А как делался перехват API? Низкоуровневым хуком (с суффиксом _LL ?) Или как-то ещё?

1)  Пишешь прототип API функции ... (в DLL)
2)  Внедряешь DLL в чужой процесс
3)  Просматриваешь таблицу импорта этого процесса , находишь адрес функции, которую хочешь перехватить (там втупую имена функций указаны)
4)  Если надо запоминаешь старый адрес и вписываешь свой адрес ..
5)  Все ...

[point]

2SlavaI

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

при таком подходе рекурсии не будет.
а теперь раскажите мне пожалуйста как с помощью IRP_MJ_QUERY_INFORMATION Вы собираетесь получить нормализованное имя объекта? судя по Вашим знаниям Вы должны быть в курсе что с помощью нее можно получить то имя объекта которое было передано в IRP_MJ_CREATE и если оно было коротким, то таким же и останется. Есть способ заставить IRP_MJ_QUERY_INFORMATION вернуть длинное имя, но он не рекомендован к применению при большом количестве разных фильтров в стеке.
Единственный (известный мне) рекомендованный к применению способ основан на использовании IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY - надо получить имина всех объектов поочередно опрашивая все каталоги входящие в путь.

проблема с относительным путем чаще всего решается с помощью написания кеша открытых объектов - в этом решении есть свои тонкости...

описание всех трюков можно найти в сети...

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

point.

[SlavaI]

 Вы должны быть в курсе что с помощью нее можно получить то имя объекта которое было передано в IRP_MJ_CREATE

Кто это такое сказал? По моему никакого стандарта нет. Оно будет таким, как его реализовали в драйвере, в частности как оно сохранено в FCB, который один на несколько FILE_OBJECT, которые могут быть открыты по разному- коротким именем, через RelatedFileObject и т.д. То есть с этим утверждением я не согласен. Действительно из CCB можно вытянуть инфу об открытии и вернуть короткое имя например и обрезать возвращаемое имя, полученное из полного.

[point]

Кто это такое сказал? По моему никакого стандарта нет. Оно будет таким, как его реализовали в драйвере, в частности как оно сохранено в FCB, который один на несколько FILE_OBJECT, которые могут быть открыты по разному- коротким именем, через RelatedFileObject и т.д. То есть с этим утверждением я не согласен.

да собственно Вы лично можете быть не согласны c чем угодно - факт остается фактом.
это не мое утверждение - не сочтите за труд поискать в архивах ntfsd - там это обсуждалось...


point.

[SlavaI]

да собственно Вы лично можете быть не согласны c чем угодно

Так я с этим не согласен, так как если напрячься и открыть код, например fastfat, то там написано

   //  1) short name: use FinalNameLength to tear off the path from FullFileName
    //      and append the UNICODE converted short name.
    //  2) long name: just use FullFileName
    //
    //  We bias to the name the user thinks they opened by.  This winds
    //  up fixing some oddball tunneling cases where intermediate filters
    //  translate operations like delete into renames - this lets them
    //  do the operation in the context of the name the user was using.
    //
    //  It also matches what NTFS does, and so we have the definition of
    //  correct behavior.

bias. То есть сделан выбор, но никак не стандарт, а "fixing some oddball".

[point]

2SlavaI:

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

point.

[SlavaI]

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

Да, ладно. Я поспорить хотел

[point]

2SlavaI:

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

на мой взгляд MS плохо специфицировал требования к именам этих объектов. Если бы были четко определены требования то такой чехарды с именами не было бы изначально...

point

[XC™]

Мне надо всего-навсего перехватить обращение к файловой системе или к диску

Если только это, то вот тебе 100% правильное решение
1) для перехвата обращений к файловой системе, достаточно простого драйвера фильтра файловой системы, не пугайся рассказов о сложности фильтров файловых систем- это так только в случае если ты пытаешься нетривиально модифицировать передаваемые данные, для простого анализа и отклонения запросов все очень просто. Самая большая сложность тут- не трогать запросы от VMM, посланные на страничный файл, а также желательно не трогать запросы на подгрузку страниц в секции, но если это для юзер мода- можно отклонять. Все запросы к страничному файлу легко вылавливаются, если надо скажу как.
2) Перехват обращений к дискам- тут есть тонкость. Если на диск(раздел) смонтирована файловая система то ВСЕ интересные для тебя обращения чтения, записи и IOCTL пойдут сначала через нее(то есть тут ты их поймаешь на фильтре файловой системы), потом они будут переданы на DEVICE_OBJECT одного из драйверов- ftdisk.sys или dmio.sys, а уже с них на драйвер disk.sys. Первые два драйвера отвечают за разделы на диске, третий драйвер за разделы и весь диск(то есть запросы, адресованные всему диску пойдут на него, например модификация таблицы разбиения). Обращаю внимание- пользовательское приложение без привилегий админа не сможет напрямую работать через disk.sys.

Мне нужен именно 1-й пункт ... Помогите пожалуйста !

[SlavaI]

Мне нужен именно 1-й пункт ... Помогите пожалуйста !

Пиши свой e-mail, вышлю пример драйвера фильтра. Там есть все, что тебе нужно, переделай его как тебе надо(на самом деле- выкинь не нужное). Драйвер естественно на C.

[SlavaI]

на мой взгляд MS плохо специфицировал требования к именам этих объектов. Если бы были четко определены требования то такой чехарды с именами не было бы изначально...

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

[point]

Создается впечатление(во всяком случае у меня)- эта модель драйверов находится на своем пределе, она неконтроллируема и тяжело понимаема.

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

point

[XC™]

Пиши свой e-mail, вышлю пример драйвера фильтра.

Prog.TM@mail.ru за ранее спасибо !

[XC™]

SlavaI, И еще один очень глупый вопрос не по теме (извините за это) :
а кто имеет право нажимать '+' / '-' ? Только админы ?

[SlavaI]

а кто имеет право нажимать '+' / '-' ? Только админы ?

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

[SlavaI]

А вот еще- в следующий раз не пиши почтовый адрес в открытую, делай например так
Prog.TM $собака_гав_гав$ на сайте $ mail.ru
а то спамерские роботы, сканирующие сеть в посиках адресов тебя засекут. Чем сильнее извратишь, тем лучше.

[SlavaI]

XC™,  послал, там аттачмент в пол мега, но по моему должен пролезть на mail.ru, если не пройдет- пиши, будем резать на части.

[Гром]

XC™, только набрав определенное колличество сообщений ты можешь жать + и -

[Anonymous]

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