Всем привет.
Пишу MiniFilter для контроля за файловой системой, это мои первые попытки написать драйвер, поэтому могу путать терминологию и чтобы не было неоднозначностей буду приводить названия используемых функций.
Фильтр устанавливаю с помощью FltRegisterFilter, контролирую IRP_MJ_CREATE и IRP_MJ_DIRECTORY_CONTROL. Внутри колбеков с помощью PsGetCurrentProcess получаю ссылку на PEPROCESS, дальше используется пара функций для определения идентификатора процесса (PsGetProcessId) и его названия. По полученным данным принимаю решение об фильтрации. Когда запрос идет из обычных приложений, то проблем никаких нет. Но если какой-либо драйвер работает с файловой системой напрямую, то PsGetProcessId ссылается на system процесс (тесты с несколькими драйверами не проводил, но как я понимаю у каждого драйвера будет свой уникальный PEPROCESS, который будет ссылаться на system-процесс). Отсюда возникает вопрос:
Можно ли как-нибудь из PEPROCESS (или любым другим способом) понять какой конкретный драйвер работает с файловой системой?
Можно попробовать сделать перехват системных функций, тогда по точке возврата есть шанс определить драйвер, но я так понимаю, что PatchGuard мне не даст этого сделать, а возиться с отключение защиты совсем не хочется (я так понял это не тривиальная задача).
Драйвер пишу для Win10 x64 и на данный момент использовать его в других системах не планирую.

| Сообщение посчитали полезным:

сильно не вникал, но глянь --> здесь<--, может поможет.
Статье правда три года, но мне в свое время помогла найти решение для моей задачи.
Успеха!

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

plutos, спасибо за ссыль, но это не то. У меня нет проблем с написание самого фильтра (к тому же в этой же статье написано, что лучше использовать minifilter, что я и делаю). Мне нужно понять какой драйвер работает с файловой системой. К сожалению, я не понимаю многих нюансов нулевого кольца, поэтому и не понимаю в какую сторону копать.

| Сообщение посчитали полезным:

Не будет у каждого драйвера свой PEPROCESS для system-процесса.

А для чего задача фильтровать драйвера? Если это для безопасности, то смысла нет, драйвер всегда сможет при желании обойти другой драйвер.

| Сообщение посчитали полезным:

user99 пишет:
К сожалению, я не понимаю многих нюансов нулевого кольца

так может с этого и нужно начинать?
Да и цель не понятна, согласен с Archer'oм.

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

Archer, именно для безопасности и смысл есть: при желании можно много чего сделать, но чтобы это желание появилось нужно понимать, что тебя блокируют, а т.к. я свою разработку в Сеть не собираюсь выкладывать, то разработчик исходного подозрительного драйвера навряд ли будет делать лишние телодвижения.

Archer пишет:
Не будет у каждого драйвера свой PEPROCESS для system-процесса.
Не понял. У каждого драйвера свой уникальный PEPROCESS или он общий на всех? Можно ли по PEPROCESS выйти на конкретный экземпляр драйвера?

plutos пишет:
так может с этого и нужно начинать?
Может и стоит, но я понимаю на сколько глубоки эти дебри, и т.к. для меня это второстепенное направление, то тратить на изучение ринг0 несколько месяцев не могу.
Надеюсь, что есть люди, кто сталкивался с подобной задачей, и они смогут навести меня на путь истинный

| Сообщение посчитали полезным:

user99 пишет:
Надеюсь, что есть люди, кто сталкивался с подобной задачей, и они смогут навести меня на путь истинный

дело, конечно, ваше личное, но если это так важно, то может пойти прямо в раздел --> поиск специалистов <--и там попросить помощи, вместо того, чтобы ждать у моря погоды.

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

user99 пишет:
У каждого драйвера свой уникальный PEPROCESS или он общий на всех?
Не будет уникального. Контекст system-процесса один.

Нормально документированно задачу вряд ли решить. Но коль хочется нагородить костылей, коль оно так by design, можно попробовать походить по IO_STACK в IRP с целью выцепить DeviceObject самого нижнего драйвера. Другой вопрос, что ни разу не факт, что это он и начал изначально делать запрос. И коллстек тут тоже не поможет, запросы могут быть и отложенные.

| Сообщение посчитали полезным: ajax, user99

Разработка минифильтров обычно поставлена на поток", те разраб этим занимается много лет, он это делает на автомате. Вхождение туда с нуля просто невозможно. ТС взял неподьёмную задачу.

> Можно ли как-нибудь из PEPROCESS (или любым другим способом) понять какой конкретный драйвер работает с файловой системой?

Нет. PEP* это лишь системный обьект, в контексте которого выполняется ваша задача, а для фильтров это постоянно изменяющийся контекст. Он никак не связан с драйверами. Это лишь указатель на описатель текущего контекста задачи.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Вхождение туда с нуля просто невозможно. ТС взял неподьёмную задачу.
Все когда-то делается впервые и насчет неподъемности задачи явное преувеличение. Конечно полноценный антивирь (или какую-либо подобную защиту) я не напишу, особенно если учитывать разнообразность компов и что у каждого пользователя программа работает по особенному, но сделать драйвер-фильтр для себя не является такой большой проблемой (особенно если можешь хардкодить по страшному).

Всем спасибо за объяснения, у меня одна идея уже родилась как можно решить свою задачу, может чуть позже выложу основную идею - покритикуете с точки зрения своего опыта.

| Сообщение посчитали полезным:

user99

Кривой падающий драйвер по шаблону собрать каждый сможет. Но такое не приемлемо, должна быть разработана архитектура, отсутствие корреляций с защитой. Костыльная сборка которая через раз будет отваливать ось в синь никуда не годится. Колхозить в ядре ос - не годится, за такое руки отрезать следует.
Архитектура минифильтров весьма сложна, это не общего назначения драйвера, через них проходит работа с железом. Нужно много времени на изучение всей архитектуры, только потом можно пытаться что то реализовать. Так что желание не соответствует вашим возможностям. Купите реализацию, иначе никак.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Так что желание не соответствует вашим возможностям.
Будем считать, что это было сказано с наилучшими пожеланиями, а не в попытке обидеть меня. Потому что глупо и непрофессионально писать такие вещи, не зная ничего о человеке.
difexacaw пишет:
Купите реализацию, иначе никак.
Знаешь какое у меня сложилось мнение о большинстве "специалистах" за то время, что живу на белом свете? Что как раз-таки им нужно руки поотрывать, потому что люди кичуются делают вид, что они все знаю и все умеют и всячески набивают себе цену, а когда начинаешь чуточку присматриваться, что же там эти горе "специалисты" натворили, то хочется за ними все переделать. Это касается не только программирования, но и многих вещей с которыми приходится сталкиваться (электрика, слесаря, ремонт и т.д.). Конечно это касается далеко не всех и есть действительно мастера своего дела, но отыскать нужных людей очень непросто и если тебе кто-то говорит "я работал с этим человеком, он отличный спец", тоже не является гарантией.
В любом случае это лирика, я услышал мнение, но пока буду придерживаться своей позиции и дальше писать то "что я написать не смогу"

| Сообщение посчитали полезным:

user99

Нет никакой попытки обидеть вас, лишь факты. Даже крупные конторы, в которых группы вылизывают защитные фильтры не могут добиться стабильности годами. А вы хотите самостоятельно такое реализовать. Это из области фантастики. Что бы вы не собрали оно получится анстаб и дырявое, элементарный анализ найдёт ошибки, в лучшем случае оно просто падает, но обычно через такие поделки получается доступ в км.

Хорошим примером были ав фильтры(kl, avg etc). Это показало на примере что если человек отлично может кодить в юм, то в км эти навыки бесполезны - код полное решето с точки зрения синхронизаций.

-----
vx

| Сообщение посчитали полезным:

user99, ты зацепился языками с пылью параллельных миров. Поздравляю.

| Сообщение посчитали полезным: plutos, sefkrd

Gideon Vi пишет:
ты зацепился языками с пылью параллельных миров. Поздравляю

"есть люди, которые будут говорить о чем угодно постольку поскольку они говорят о себе"
Ф.М.Достоевский (русский писатель).

Тут как раз тот случай.

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным: f13nd, bartolomeo

difexacaw, я услышал и с некоторыми моментами полностью согласен, но только с некоторыми, поэтому разработку пока не брошу

Gideon Vi,plutos, моя вас не понимать.

Вернемся к тому ради чего создавалась эта тема, а то недолог час перейдем на русскую классику, софистику и прочие сугубо философские проблемы.
Напомню суть: хочу отследить какой конкретный драйвер пытается получить доступ к файлу. Отследить через процесс невозможно, т.к. все драйверы работают в контексте системного процесса, но здесь и рождается идея: можно отследить поток. Для каждого потока можно узнать его стартовый адрес и получить взаимосвязь между потоком и драйвером. На данный момент вижу только пару нюансов:
1) некоторые потоки начинаются внутри ntoskrnl.exe (в частности с замечательной функции ExpWorkerThread), но это относится к загрузке драйвера и его выгрузке, так что это будем игнорить.
2) драйвер может замаскировать свою нить, делая запуск через какого-нибудь посредника, но опять-таки этот момент проигнорим, т.к. я борюсь не с вирусом, и там внутри такого мазохизма на данный момент нет (хотя может я о нем не знаю).
3) где-то читал, что поток можно запустить не в системном (system) процессе, а в любом другом (например, в svchost.exe или csrss.exe), на сколько знаю этим процессам нельзя полностью обрезать доступ к файлам, потому что может быть больно. Этой частью пока не занимался, но попробую почитать и провести тесты.
4) Archer писал про отложенные запросы, пока тоже не читал, что это за зверьки такие, так что будем решать проблемы по мере их поступления.
Прошу знающих людей покритиковать данную идею. Первые тесты показали, что механизм имеет право на существование, но вполне возможно, что есть какие-то подводные камни (механизмы), о которых я не знаю и которые не позволят данному способу выполнить мою задачу.

| Сообщение посчитали полезным:

Люди добрые, подскажите какие функции контролирует ObRegisterCallbacks с параметрами PsProcessType и OB_OPERATION_HANDLE_CREATE?
Я так понимаю, что должна контролироваться только одна функция NtOpenProcess или есть еще какие-то функции, после которых срабатывает данный колбек?

| Сообщение посчитали полезным:

user99
DuplicateHandle не может быть?

-----
старый пень

| Сообщение посчитали полезным:

r_e, флаг стоит только OB_OPERATION_HANDLE_CREATE (без OB_OPERATION_HANDLE_DUPLICATE) не должно

| Сообщение посчитали полезным:

Создание процесса скорее всего этот коллбек дёрнет.

| Сообщение посчитали полезным: