Необязательно "глобальный", пойдет любой уникальный ид, при IRP_MJ_READ, IRP_MJ_WRITE и IRP_MJ_CLEANUP (закрытие файла).
Просто надо отличать открытый файл от других, а делать это по имени ненадежно.

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

S>Необязательно "глобальный", пойдет любой уникальный ид, при IRP_MJ_READ, IRP_MJ_WRITE и IRP_MJ_CLEANUP (закрытие файла).
S>Просто надо отличать открытый файл от других, а делать это по имени ненадежно.

FLT_RELATED_OBJECTS::FileObject создается при создании/открытии и не меняется до cleanup'а. Собственно, именно к FILE_OBJECT'у и привязывается отдаваемый в user mode описатель (HANDLE).

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

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

S>>Необязательно "глобальный", пойдет любой уникальный ид, при IRP_MJ_READ, IRP_MJ_WRITE и IRP_MJ_CLEANUP (закрытие файла).
S>>Просто надо отличать открытый файл от других, а делать это по имени ненадежно.

ETI>FLT_RELATED_OBJECTS::FileObject создается при создании/открытии и не меняется до cleanup'а. Собственно, именно к FILE_OBJECT'у и привязывается отдаваемый в user mode описатель (HANDLE).

Его самого использовать как хендл, что ли? Сделали бы лучше поле внутри него, а то чушь какая-то... Отстой эти фильтры, хуки таки лучше были. Лучше бы к хукам дописали готовые алгоритмы их фильтрования.

S>Его самого использовать как хендл, что ли?
Да, адрес объекта будет уникален от IRP_MJ_CREATE до IRP_MJ_CLOSE.

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

S>Необязательно "глобальный", пойдет любой уникальный ид, при IRP_MJ_READ, IRP_MJ_WRITE и IRP_MJ_CLEANUP (закрытие файла).
S>Просто надо отличать открытый файл от других, а делать это по имени ненадежно.

Аналогом хэндлов в минифильтрах являются FILE_OBJECT-ы.
Результатом двух разных операций Nt/ZwCreateFile будут два разных FILE_OBJECT-а.

Также рекомендую заглянуть сюда:

Managing Contexts in a Minifilter Driver
https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/managing-contexts-in-a-minifilter-driver

Если кратко: контексты позволяют связать произвольный блок информации с любым объектом, т.е. с FILE_OBJECT,
с потоком, с файлом, томом (volume), инстансом минифильтра (instance) и т.д.

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

S>Отстой эти фильтры, хуки таки лучше были.

Ну начнем с того, что хуки уже лет десять как (с x64 Windows Vista) просто тупо не функциональны из-за Patch Guard.

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

ETI>FLT_RELATED_OBJECTS::FileObject создается при создании/открытии и не меняется до cleanup'а.

Точнее говоря, до IRP_MJ_CLOSE.
После cleanup хэндл закрыт, но файловый объект еще существует и на нем могут
выполняться различные операции (обычно paging i/o).

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

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

ETI>>FLT_RELATED_OBJECTS::FileObject создается при создании/открытии и не меняется до cleanup'а.

O>Точнее говоря, до IRP_MJ_CLOSE.
O>После cleanup хэндл закрыт, но файловый объект еще существует и на нем могут
O>выполняться различные операции (обычно paging i/o).

А мне он именно при cleanup нужен, поскольку судя по MSDN, именно оно (а не close) точнее соответствует задаче "отслеживать все закрытия файлов в юзер-моде". И этот "хендл" в виде FILE_OBJECT там тоже нужен будет, чтобы связать закрытия с записью и чтением.

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

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

S>>Необязательно "глобальный", пойдет любой уникальный ид, при IRP_MJ_READ, IRP_MJ_WRITE и IRP_MJ_CLEANUP (закрытие файла).
S>>Просто надо отличать открытый файл от других, а делать это по имени ненадежно.

O>Аналогом хэндлов в минифильтрах являются FILE_OBJECT-ы.
O>Результатом двух разных операций Nt/ZwCreateFile будут два разных FILE_OBJECT-а.

И это печально.

O>Также рекомендую заглянуть сюда:

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

O>Ну начнем с того, что хуки уже лет десять как (с x64 Windows Vista) просто тупо не функциональны из-за Patch Guard.

Так потому и пишу "были", а не "есть".
Хотя на виртуалке с Windows 10 x64 все работало.
Вот тот исходник: https://github.com/mrexodia/TitanHide
Возможно, кто-то заинтересуется. Возможно, кто-то прокомментирует.

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

O>>Также рекомендую заглянуть сюда:

S>Не вижу смысла сейчас этим заниматься.
S>Я просто делаю связный список с ключом по хендлу, в который сперва записывается информация при каждом чтении\записи о каждом файле отдельно, затем при закрытии этого самого файла извлекается оттуда и передается на логгер.

Чисто для справки: вместо списка здесь эффективнее, например, AVL-дерево.
См. RtlInitializeGenericTableAvl и далее по ссылкам.

O>>Ну начнем с того, что хуки уже лет десять как (с x64 Windows Vista) просто тупо не функциональны из-за Patch Guard.

S>Хотя на виртуалке с Windows 10 x64 все работало.

Понятно, что в виртуальной машине с подключенным отладчиком ядра или с вырубленными
проверками цифровых подписей все работает, т.к. PatchGuard в таких сценариях не активен.
Но на реальной системе, где нет всяких отладчиков и test signing mode, из-за хуков будут
вылетать BSOD-ы CRITICAL_STRUCTURE_CORRUPTION раз в несколько минут. А на Windows 10 с
включенным Device Guard / HVCI сами хуки ядра вообще не получится поставить (из-за
ограничений на использование исполняемой памяти в ядре). Так что эта техника давно
мертва и использовать ее можно только для каких-то очень узкоспецифичных вещей.

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

O>Чисто для справки: вместо списка здесь эффективнее, например, AVL-дерево.
O>См. RtlInitializeGenericTableAvl и далее по ссылкам.

Да куда мне уперлось эта платформозависимая хрень?
Хотя и из списка я пока не делаю полноценный класс, который был бы годен для разных задач и имел все необходимые функции — но могу потом его сделать из того же исходника.
(До сих пор его у меня нет только потому, что редко пишу на C/C++. А в C#, Java это доступно из коробки.)

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

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

O>>Чисто для справки: вместо списка здесь эффективнее, например, AVL-дерево.
O>>См. RtlInitializeGenericTableAvl и далее по ссылкам.

S>Да куда мне уперлось эта платформозависимая хрень?

А при чем здесь вообще платформозависимость?
Поиск в списке выполняется за линейное время, а в дереве — за логарифмическое.
Если очень грубо, то в первом случае поиск в списке из 1000 элементов будет в
среднем выполняться за 500 операций сравнения, а во втором — за 5.

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

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

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

O>>>Чисто для справки: вместо списка здесь эффективнее, например, AVL-дерево.
O>>>См. RtlInitializeGenericTableAvl и далее по ссылкам.

S>>Да куда мне уперлось эта платформозависимая хрень?

O>А при чем здесь вообще платформозависимость?
O>Поиск в списке выполняется за линейное время, а в дереве — за логарифмическое.
O>Если очень грубо, то в первом случае поиск в списке из 1000 элементов будет в
O>среднем выполняться за 500 операций сравнения, а во втором — за 5.

В целях выгодности на будущее. Самописный список на C/C++ (как и самописное дерево) написал за раз — допилил потихоньку — и пользуешь хоть в контроллере ракеты на Марс, а тут тратить время на освоение очередного узкоспециального API... особенно не успевая по основному:
http://rsdn.org/forum/asm/7024337.flat

Автор: sergey77666
Дата: 19.01.18

:D

Здравствуйте, sergey77666, Вы писали:
O>>>>Чисто для справки: вместо списка здесь эффективнее, например, AVL-дерево.
O>>>>См. RtlInitializeGenericTableAvl и далее по ссылкам.
S>>>Да куда мне уперлось эта платформозависимая хрень?
O>>А при чем здесь вообще платформозависимость?
O>>Поиск в списке выполняется за линейное время, а в дереве — за логарифмическое.
O>>Если очень грубо, то в первом случае поиск в списке из 1000 элементов будет в
O>>среднем выполняться за 500 операций сравнения, а во втором — за 5.
S>В целях выгодности на будущее. Самописный список на C/C++ (как и самописное дерево) написал за раз — допилил потихоньку — и пользуешь хоть в контроллере ракеты на Марс
С вашими подходами к разработке и ковбойсками наскоками ракета, в контроллере которой будет использованы ваши самописные списки и деревья, просто не взлетит.
О полете на Марс можно даже не говорить.

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

N>Здравствуйте, sergey77666, Вы писали:
O>>>>>Чисто для справки: вместо списка здесь эффективнее, например, AVL-дерево.
O>>>>>См. RtlInitializeGenericTableAvl и далее по ссылкам.
S>>>>Да куда мне уперлось эта платформозависимая хрень?
O>>>А при чем здесь вообще платформозависимость?
O>>>Поиск в списке выполняется за линейное время, а в дереве — за логарифмическое.
O>>>Если очень грубо, то в первом случае поиск в списке из 1000 элементов будет в
O>>>среднем выполняться за 500 операций сравнения, а во втором — за 5.
S>>В целях выгодности на будущее. Самописный список на C/C++ (как и самописное дерево) написал за раз — допилил потихоньку — и пользуешь хоть в контроллере ракеты на Марс
N>С вашими подходами к разработке и ковбойсками наскоками ракета, в контроллере которой будет использованы ваши самописные списки и деревья, просто не взлетит.
N>О полете на Марс можно даже не говорить.

Посмотрим.
Квадрокоптер буду конструировать. Или самолет.