Всем доброго! Налогаются ли ограничения IRQL для использования strncmp, wcsncmp, _mbsncmp? А так же на memcpy.
ограничения IRQL касаются доступа к paged памяти. а как осуществляется доступ значения не имеет. т.е. все перечисленные ф-ции потенциально "опасны"
Ponaytno, rabotat' mojno no tol'ko s pamyat'yu "NonPagedPool". U menya voznik etot vopros potomuchto, ya pitalsya izpol'zovat' RtlUnicode... funkcii v svoem driver filtre, i vspomnil chto s nimi mojno rabotat' tol'ko na IRQL s PASSIVE_LEVEL.
Если тебе только латинский текст сравнивать, т.е. коды символов не выходят за пределы 127, можешь выдрать из исходников RtlCompareUnicodeString и/или RtlEqualUnicodeString и макрос NLS_UPCASE. В макросе нужно убрать вызов TRAVERSE844W (оставить только (wch)). После этой несложной модификации они прекрасно работают и на повышенных IRQL. А strncmp, wcsncmp, _mbsncmp, в свете последних решений партии, лучше не юзать.
Погоди... я забыл, что ты FileSpy мучаешь. Тогда не пойдёт, т.к. имена файлов само-собой и на китайском могут быть.
Four-F, вот именно сижу и думаю как же быть. Первоначально для определения типа файла я использовал следующий код: Код (Text): ... PFILE_OBJECT FileObject = currentIrpStack->FileObject; char str[] = ".txt"; PVOID pdest; status = RtlUnicodeStringToAnsiString(&ansi_string,&FileObject->FileName,TRUE); if(NT_SUCCESS(status)) { pdest = strstr( ansi_string.Buffer, str ); if(pdest == NULL) { status = STATUS_UNSUCCESSFUL; } else { ... status = STATUS_SUCCESS; ... } else {status = STATUS_UNSUCCESSFUL;} } RtlFreeAnsiString(&ansi_string); } ... На тот момент, я вовсе не задумывался о IRQL, драйвер работал, но при выключении компа происходило зависание(вечный цикл), в синяк система не падала. Тут я и вспомнил об IRQL, а еще я встал припоминать попутные мелочи, хотелось бы ими поделиться. И так: - верно ли, что IRP_MJ_CREATE всегда на PASSIVE_LEVEL? - FileObject->FsContext, какой структуре его можно соотнести, в инете встречал сообщения, что именно по нему ведеться трассировка отслеживаемых файлов(файловых объектов), так ли это? - по какаим еще ресурсам можно определить искомый файл(объек)?
<font color="gray][ LuckyDevil</font><!--color--><font color="gray]: верно ли, что IRP_MJ_CREATE всегда на PASSIVE_LEVEL? ]</font><!--color--> Да. Можешь глянуть ещё "Dispatch Routines and IRQLs" в ДДК. <font color="gray][ LuckyDevil</font><!--color--><font color="gray]: FileObject->FsContext, какой структуре его можно соотнести... ]</font><!--color--> В общем случае ни к какой. FsContext и FsContext2 предназначены для хранения приватной для драйвера информации. Там может быть что угодно, стандарта нет. См. "File Streams, Stream Contexts, and Per-Stream Contexts" в ДДК. Глянь ещё в исходниках IFSKit\src\filesys, как эти поля используются.
Что-то не так, либо я не правильно понимаю происходящее, либо фильтр работает криво. В архивах OSR, многие пишут что для трассировки файлов оспользуют следующую схему: - при появлении IRP_MJ_CREATE, включают счетчик открытия и FCB. - на основании FCB в IRP_MJ_READ определяют тот ли файл пришел. Вроде все работает, т.е. я получаю FCB и он на протяжении всего процесса чтения из файла он не изменяется(т.е указатель на на контекст файлового объекта остается не изменным). Но встает другой вопрос как обнулять этот счетчик, потому что IRP_MJ_CLEANUP\CLOSE приходят сразу же после IRP_MJ_CREATE, и уже потом IRP_MJ_READ. На сколько эта ситуация корректна? Код (Text): IRP_MJ_Create: FileObject: FF96E7A8; Flags: 2180; Information: 1; FileName = \dbgview1805.LOG IRP_MJ_Create: FCB: E1D52D78; DeviceObject: FF9FA8E0 IRP_MJ_CLEANUP/IRP_MJ_CLOSE: FileObject: FF96E7A8; Name = notepad.exe:488; Flags: 1028; Information: 0; FileName = \dbgview1805.LOG IRP_MJ_CLEANUP/IRP_MJ_CLOSE: FCB=E1D52D78 IRP_MJ_READ: FileObject: FF96E7A8; Name = notepad.exe:488; Flags: 67; Information: 0; FileName = \dbgview1805.LOG IRP_MJ_READ: FCB=E1D52D78
К сожалению, тут я мало чем могу помочь. Насколько я понимаю, обработчики IRP_MJ_CLEANUP / IRP_MJ_CLOSE у тебя объеденены. Т.е. из вышеприведенного лога невозможно понять, какой именно IRP ты получил. В описании IoCreateStreamFileObject / IoCreateStreamFileObjectEx, например есть такая фраза: "File system filter driver writers should note that IoCreateStreamFileObject causes an IRP_MJ_CLEANUP request to be sent to the file system driver stack for the volume." Посмотри ещё приаттаченную статью, если ещё её не видел. ЗЫ: Насчёт стандарта на содержимое поля FsContext я, похоже, ошибался. Именно для фс там указатель FSRTL_COMMON_FCB_HEADER или FSRTL_ADVANCED_FCB_HEADER. ЗЫ: Если не разберёшься, попробуй спросить на rsdn. Там точно есть несколько человек, неплохо разбирающихся в фс. 539857008__ReferenceCounting.rar
<font color="red]ЗЫ: Если не разберёшься, попробуй спросить на rsdn.</font><!--color--> Four-F, действительно есть, только сложно мне пока с ними общаться, уровень моих знаний не позволяет мне пока качественно делать постановку вопроса, а это их там жуть как раздрожает . <font color="red]поля FsContext</font><!--color-->, более-менее понятно чт это за зверь и уже на сколько я понял трогать его не советают, в отличии от FsContext2, но... Но мой фильтр кажет что после обработки IRP_MJ_CREATE, оба поля FsContext и FsContext2, имеют ссылки на определенную область памяти, т.е. это NULL как я ожидал. Все в тех же архивах на OSRONLINE, есть такие вот сообщения: Код (Text): In a file system, we normally store this in whatever structure is pointed to by FsContext2. In a filter, this would be in your per-open-instance structure (assuming you maintain one) or in your per-file structure (where you keep track of file objects that were opened by ID, for instance). Отсюда вопрос, если я заменяю адрес который возращает мне система, на адрес своей структуры, неужели не будет никаких последствий? И еще, даже если это так, то кто будет заниматься особождением ресурса, менеджер IRP или я, если я то на соновании чего(какой информации) я должен выполнять это действие. Вообщем из первоначально кажущейся легко решаемой задачи "выявление файла, отвечающий определенным требованиям", я попал в очередной тупик.
<font color="gray][ LuckyDevil</font><!--color--><font color="gray]: если я заменяю адрес который возращает мне система, на адрес своей структуры, неужели не будет никаких последствий? ]</font><!--color--> Разумеется будут. <font color="gray][ LuckyDevil</font><!--color--><font color="gray]: даже если это так, то кто будет заниматься особождением ресурса, менеджер IRP или я, если я то на соновании чего(какой информации) я должен выполнять это действие. ]</font><!--color--> Освобождением ресурса должен заниматься его хозяин, т.е. тот кто выделил память и запихал указатель на неё в FsContext. Система делть этого не будет. В том посте Тони дальше говорит: "Apparently I wasn't clear: the FsContext2 pointer belongs to the file system. If you are a filter, you'll have to maintain your own mechanism for finding per-file-object data. There are plenty of ways of doing this, but we generally use a table lookup. Note that USING the FsContext2 pointer directly is not an option for a file system filter driver." ЗЫ:Набрав в поиске по конфе ntfsd (без кавычек) "FsContext FCB IRP_MJ_CREATE" я получил немерянное кол-во ссылок. Уверен, если всё это внимательно прочитать, то найдется ответ на твой вопрос.
Four-F, привет! Слушай я наверное скоро в психушку попаду читая архивы на OSRONLINE . Надо проконсультироваться, я более внимательно просамотрел свою трассировку, отделил MJ_CLEANUP и MJ_CLOSE, выяснилось что сразу же псоле MJ_CREATE, приходит MJ_CLEANUP, и после MJ_READ эти все пакеты адресованны одном процессу к примеру Notepad.exe, но я так и не дождался MJ_CLOSE для Notepad.exe. Все MJ_CLOSE которые мне удается поймать принадлежат к Explorer'y. Как это можно объяснить? FileSpy от Зузелы, показывает примерно туже картину, только в его случае MJ_CLOSE приходит от System'го процесса. На данный момент в своем диспечере я не делаю никакой обработки приходящь запросов, я просто отправляю все следющему за мной драйверу. Какие причины могут влият на все это?
Four-F, еще одну вещь заметил, при небольших размерах файла, IRP_MJ_READ вообще не приходит, т.е. где именно и когда именно происходит загрузка файла полнейшая загадка, могу только предположить что при вызове FASTIO_QUERY_STANDARD_INFO . Код (Text): 56 09:37:30.818 0 notepad.exe IRP_MJ_CREATE 00000884 00000000 C:\dbgvi ew251.LOG STATUS_SUCCESS FILE_OPEN CreOpts: 0x00000060 Access: 0x00120089 Share: 0x00000003 Attrib: 0x00000080 Result: FILE_OPENED 57 09:37:30.818 0 notepad.exe IRP_MJ_QUERY_VOLUME_INFORMATION 00000870 E1D950D8 C:\dbgview251.LOG STATUS_SUCCESS 58 09:37:30.818 0 notepad.exe IRP_MJ_QUERY_INFORMATION 00000870 E1D950 D8 C:\dbgview251.LOG STATUS_BUFFER_OVERFLOW FileAllInformation 59 09:37:30.818 0 notepad.exe FASTIO_QUERY_STANDARD_INFO E1D950D8 C:\ dbgview251.LOG STATUS_SUCCESS AllocationSize: 00000000-00000028 EndOfFile: 00000000-00000024 NumberOfLinks: 1 DeletePending: 0 Directory: 0 60 09:37:30.818 0 notepad.exe IRP_MJ_CLEANUP 00000404 E1D950D8 C:\dbgview251.LOG STATUS_SUCCESS 61 09:37:30.818 0 notepad.exe IRP_MJ_CLOSE 00000404 E1D950D8 C:\dbgview251.LOG STATUS_SUCCESS
Всем доброго! вот статья в продолжение темы namespace, там все так просто и легко, но на практике все иначе.
Вот тебе ещё почитать http://www.microsoft.com/whdc/driver/security/drvqa.mspx http://www.microsoft.com/whdc/driver/tips/DevNamespace.mspx http://www.microsoft.com/whdc/driver/tips/SafeNamespace.mspx http://www.microsoft.com/whdc/driver/security/drvsecure.mspx http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndev ice/html/DrvrReliab.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarc h/hh/kmarch/DevObjts_65ddffe3-ce3d-47ed-a7e7-dd2a7ff18a7b.xml.asp
