Привет!

Возник вопрос, надеюсь Вы поможете найти на него ответ

Короче говоря, есть Lower Filter Driver для DiskDrive class.
В фильтре обрабатывается запрос IRP_MJ_SCSI, и в зависимости от того, что происходит, чтение или запись, выполняются некоторые действия:

NTSTATUS STDCALL
ScsiHandler(IN PDEVICE_OBJECT DeviceObject,
            IN PIRP Irp)
{
   PDEVICE_EXTENSION DeviceExtension;
   PIO_STACK_LOCATION Stack;
   PSCSI_REQUEST_BLOCK Srb;
   NTSTATUS Status;

   DeviceExtension = DeviceObject->DeviceExtension;

   Stack = IoGetCurrentIrpStackLocation(Irp);
   Srb = Stack->Parameters.Scsi.Srb;

   if (Srb->Function == SRB_FUNCTION_EXECUTE_SCSI)
   {
      PCDB Cdb = (PCDB)Srb->Cdb;

      switch (Cdb->CDB10.OperationCode)
      {
         case SCSIOP_READ:
            ...
            break;

         case SCSIOP_WRITE:
            ...
            break;

         default:
            DPRINT("Cdb->CDB10.OperationCode = %x", Cdb->CDB10.OperationCode);
            IoSkipCurrentIrpStackLocation(Irp);    
            Status = IoCallDriver(DeviceExtension->TargetDeviceObject, Irp);
      }
   }

   return Status;
}

Так вот вопрос заключается в том, можно ли (и если можно то как) здесь узнать имя файла, данные которого сейчас читают?
Или пишут

IO_STACK_LOCATION::FileObject нулевой, насколько я понял этот указатель используется только в случае Upper Filter (?)

Спасибо.

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

Здравствуйте, kirill_kl, Вы писали:

_>Имя файла в данном случае определить нельзя. На таком низком уровне оперции происходят с блоками данных, а не с файлами. Имя файла можно было бы определить, если бы это был фильтр к драйверу файловой системы.
Ну можно где-нибудь сбоку выяснить размещение файлов на диске (full scan, однако) и от этого плясать.
Но непонятно, что делать с метаданными и короткими файлами, которые лежат в одном секторе со своим дескриптором.
Так что FSFilter и отлов запросов NonBuffered и/или PagingIo в IRP_MJ_READ/WRITE вам поможет.
Есть FileMon имени Руссиновича и filespy вместе с sfilter'ом имени IFS/DDK. Замечательно подходят в качестве заготовки.

Здравствуйте, cppboris, Вы писали:

C>Короче говоря, есть Lower Filter Driver для DiskDrive class.
C>В фильтре обрабатывается запрос IRP_MJ_SCSI, и в зависимости от того, что происходит, чтение или запись, выполняются некоторые действия:
C>Так вот вопрос заключается в том, можно ли (и если можно то как) здесь узнать имя файла, данные которого сейчас читают?
C>Или пишут
как известно все можно. вопрос в ресурсах.

так вот в данном случае имеет смысл подумать о связке фильтров для storage & file system стека, которые будут обмениваться подобной информацией. хорошая задачка, но первым делом я бы постарался не привязываться по имени к файлам... это всего лишь один из атрибутов. и не самый удобный для использования.

C>IO_STACK_LOCATION::FileObject нулевой, насколько я понял этот указатель используется только в случае Upper Filter (?)
FileObject кто-то может использовать для своих нужд, это лишь название поля в структуре и в не-файловых драйверах может иметь (и иногда имеет) свою семантику.

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>так вот в данном случае имеет смысл подумать о связке фильтров для storage & file system стека, которые будут обмениваться подобной информацией. хорошая задачка, но первым делом я бы постарался не привязываться по имени к файлам... это всего лишь один из атрибутов. и не самый удобный для использования.
Да, я так и понял, это единственный приемлимый способ.. со связкой.

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

На начальной стадии работает перехватчик 13h, расшифровывает все что нужно и работет корректно.
Дальше, когда к работе приступает фильтр, по-началу все идет гладко (вроде бы ), а потом BSOD — ошибка чтения SOFTWARE ветки реестра (или другой, на самом деле разной на разных машинах).

Причем во время загрузки идет много запросов на запись (чего это там пишется?), а потом после одного из них — BSOD.
Отлаживаю WinDbg, но пока ничего выяснить не удается... Жуть вообще!

До появления BSOD проходит около 1000 запросов на чтение, и 400 на запись...

В общем тупик! Похоже это конец всему

Здравствуйте, Alter_, Вы писали:

A_>Здравствуйте, kirill_kl, Вы писали:

_>>Имя файла в данном случае определить нельзя. На таком низком уровне оперции происходят с блоками данных, а не с файлами. Имя файла можно было бы определить, если бы это был фильтр к драйверу файловой системы.
A_>Ну можно где-нибудь сбоку выяснить размещение файлов на диске (full scan, однако) и от этого плясать.
A_>Но непонятно, что делать с метаданными и короткими файлами, которые лежат в одном секторе со своим дескриптором.
A_>Так что FSFilter и отлов запросов NonBuffered и/или PagingIo в IRP_MJ_READ/WRITE вам поможет.
A_>Есть FileMon имени Руссиновича и filespy вместе с sfilter'ом имени IFS/DDK. Замечательно подходят в качестве заготовки.

Спасибо, но думаю до фильтра fs не дойдет...

Здравствуйте, cppboris, Вы писали:

C>В общем тупик! Похоже это конец всему
C>
когда конец всему совсем настанет — обращайтесь
такой проект я уже делал несколько лет назад.
как консультант возможно мог бы выполнить работу еще раз

> Ситуация такая что драйвер этот занимается шифрованием\дешифрованием разделов диска, в т.ч. загрузочного.

зачем шифровать загрузочный диск, папку windows и program files ?

это не фидошное идиотское "А зачем ..?"

на самом деле. вдруг я что-то упустил для себя.

единсвенная причина, это не иметь изменений системых папок "за спиной"
но это как-то ...

Здравствуйте, Serjio, Вы писали:

S>зачем шифровать загрузочный диск, папку windows и program files ?
Ну вот так "хотят"