Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Драйвер, который занимается собственно обработкой запросов... 08.02.06 12:36 Число просмотров: 2680
Автор: amirul <Serge> Статус: The Elderman
|
> Изучал "Basic Architecture of a Network Redirector" в MSDN. > Там говорится, что сей чудный компонент состоит из драйвера > ядра, который взаимодействует с Object Manager, Cache > Manager, Memory Manager, I/O System, и проч., для обмена > информацией по сетевым интерфейсам и эффективной работы, и > из DLL третьего кольца, которая взаимодействует с > пользовательскими программами и с драйвером ядра.
Драйвер, который занимается собственно обработкой запросов на чтение/запись/получение списка файлов и пр.. и dll-ка, которая добавляет в explorer-овское сетевое окружение нужный пункт.
> Вопросы: > 1) Возможно ли использование только систем 3-го кольца? > Предположим, DLL и обычная служба, поскольку в моём случае > нет экзотики типа инопланетных сетевых интерфейсов и > вражеских протоколов :)
Нет. Файловые системы и сетевые редиректоры это драйверы нулевого кольца.
> 2) Обязательно ли курить IFSK — "Basic Architecture of a > Network Redirector" находится в разделе MSDN "Installable > File System Kit: Windows Driver Kit". Может есть источники > попроще, а может быть даже на русском языке?
Ух ты. Классный у тебя MSDN, у меня DDK Help включен, а IFSDK Help - нет. Приходится пользоваться chm-ами из самого ifskit-а. Что же до вопроса, то да, курить IFSK обязательно (ибо именно installable filesystem тебе и нужен), а вот в каком виде (на русском или нет) ты его будешь курить - совершенно не важно, главное, чтоб правильно скурил. С другой стороны, я нигде не видел переводов DDK Help и IFSKit Help на русский. Да они не особо и нужны
> А может я вообще не туда подался? У M$ есть ещё понятие > "Remote File Systems", может мне именно это и надо? Только > что-то очень мало инфы по этому вопросу, похоже это именно > то, что мне надо, только где бы почитать? :-)
Это все равно IFS-драйвер и читать только в ifs-овском хелпе :-)
> Основная задача: эмулировать программам третьих > разработчиков некий сетевой диск или UNC-шару, которая > будет давать возможность работать с неким странным > хранилищем... недоступным для программ обычным путём.
В самом простом виде у тебя будет драйвер, который обрабатывает IRP_MJ_CREATE (для открытия файлов), IRP_MJ_CLOSE (для закрытия), IRP_MJ_DIRECTORY_CONTROL (для получения списка файлов в каталоге), IRP_MJ_QUERY_INFORMATION (для получения всякой инфы о файлах - даты/размер/является ли каталогом и т.д.)
После чего заводишь в \??\ какой нить симлинк (например \??\MyStore) и направляешь его в \Device\MyStore. Все попытки открыть MyStore\bla-bla-bla будут преобразовываться в открытие \??\MyStore\bla-bla-bla и по симлинку переходить в \Device\MyStore\bla-bla-bla. После этого когда Object Manager (функция nt!ObpLookupObjectName) наткнется на созданный в директории объетов объект \Device\MyStore она вызовет parse процедуру, связанную с типом этого объекта (в нашем случае - IopParseDevice) и передаст туда в числе прочего остаток имени (bla-bla-bla). Эта процедура подготовит IRP_MJ_CREATE и вызовет диспетчер драйвера, который создал твое устройство. Дальше все просто: файловый объект будет доступен как в текущем stack location-е (поле FileName), так и в Irp->Tail.Overlay.OriginalFileObject, а остаток имени после устройства будет лежать в FileObject->FileName. На основании этого имени можешь открывать свой файл. Контекст, связанный с данным конкретным файловым объектом можешь засунуть в FileObject->FsContext (собственно для этого данное поле и предназначено), только в начало своей структуры засунь FSRTL_COMMON_FCB_HEADER (это требование IFSK, чтобы все FsContext-ы были наследниками этой структуры :-) )
> Заранее всем огромное спасибо за ответы.
ЗЫ: А, да, вспомнил способ сделать все, не выходя из третьего кольца - внедрение по Jeffrey Richter-у и перхват всех этих NtCreateFile, NtQueryInformationFile, NtQueryDirectoryFile и пр. и подставление на лету своих данных. Этот способ окажется гораздо сложнее и корявее, чем если сделать все правильно - то бишь в драйвере.
|
|
|