> Изучал "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 и пр. и подставление на лету своих данных. Этот способ окажется гораздо сложнее и корявее, чем если сделать все правильно - то бишь в драйвере.
Изучал "Basic Architecture of a Network Redirector" в MSDN. Там говорится, что сей чудный компонент состоит из драйвера ядра, который взаимодействует с Object Manager, Cache Manager, Memory Manager, I/O System, и проч., для обмена информацией по сетевым интерфейсам и эффективной работы, и из DLL третьего кольца, которая взаимодействует с пользовательскими программами и с драйвером ядра.
Вопросы:
1) Возможно ли использование только систем 3-го кольца? Предположим, DLL и обычная служба, поскольку в моём случае нет экзотики типа инопланетных сетевых интерфейсов и вражеских протоколов :)
2) Обязательно ли курить IFSK — "Basic Architecture of a Network Redirector" находится в разделе MSDN "Installable File System Kit: Windows Driver Kit". Может есть источники попроще, а может быть даже на русском языке?
А может я вообще не туда подался? У M$ есть ещё понятие "Remote File Systems", может мне именно это и надо? Только что-то очень мало инфы по этому вопросу, похоже это именно то, что мне надо, только где бы почитать? :-)
Основная задача: эмулировать программам третьих разработчиков некий сетевой диск или UNC-шару, которая будет давать возможность работать с неким странным хранилищем... недоступным для программ обычным путём.
Заранее всем огромное спасибо за ответы.
Драйвер, который занимается собственно обработкой запросов...08.02.06 12:36 Автор: 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 и пр. и подставление на лету своих данных. Этот способ окажется гораздо сложнее и корявее, чем если сделать все правильно - то бишь в драйвере.
Выручайте с IFSK — насколько он большой, где можно скачать. STFW что-то не помогло.11.02.06 19:15 Автор: HandleX <Александр М.> Статус: The Elderman
Ну а хелп, если очень понадобится, можно и выслать (около метра)
Help это описание по всем используемым структурам/функциям IFSK? Если да, то замыль, pls, на alex_wh(coбakа)mail.ru. Спасибо.13.02.06 13:58 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 13.02.06 13:59 Количество правок: 1
Если что могу помочь сырцами dll'ки FtpDrive...08.02.06 12:56 Автор: Killer{R} <Dmitry> Статус: Elderman Отредактировано 08.02.06 13:09 Количество правок: 2
> ЗЫ: А, да, вспомнил способ сделать все, не выходя из > третьего кольца - внедрение по Jeffrey Richter-у и перхват > всех этих NtCreateFile, NtQueryInformationFile, > NtQueryDirectoryFile и пр. и подставление на лету своих > данных. Этот способ окажется гораздо сложнее и корявее, чем > если сделать все правильно - то бишь в драйвере. Если что могу помочь сырцами dll'ки FtpDrive (http://www.killprog.com/fdrvr.html) с этим способом :). Но заимплемечено только чтение.
С таким способом есть одна большая засада: отображаемые в память файлы. Если твои апикухи ими не пользуются -все ок. Если пользуются, и для записи наверно проще всетаки написать нормальный драйвер. Я лично эмулировал отображаемые файлы в userspace на основе VirtualAlloc/PAGE_GUARD/AddVectoredExceptionHandler.
Спасибо всем за инфу, попробую всё-таки драйвер наваять...09.02.06 07:02 Автор: HandleX <Александр М.> Статус: The Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
