Как Gmer убивает защищенные процессы (вроде руткитов!) - Заглянем под капот Привет всем! Многие из нас использовали Gmer для поиска и удаления всякой заразы, особенно руткитов. Но задумывались ли вы, как ему удается прибить те процессы, которые намертво сопротивляются стандартному Диспетчеру задач Windows? Руткиты и другие хитрые зловреды часто используют механизмы защиты, чтобы их нельзя было просто так завершить. Давайте разберемся, как Gmer обходит эту защиту с помощью своего драйвера уровня ядра. Попытка №1: Вежливый запрос (Пользовательский режим) Когда Gmer решает, что процесс (скажем, с PID 1234) нужно завершить, он сначала действует по стандартной схеме Windows. Он использует обычные API-функции: пытается получить доступ к процессу (OpenProcess) с правами на его завершение, и если успешно – вызывает TerminateProcess. Проблема в том, что если процесс защищен (как это часто делают руткиты, используя флаги защиты на уровне ядра), то операционная система просто откажет Gmer в доступе. Стандартный метод не сработает. План Б: Вызов "тяжелой артиллерии" (Драйвер режима ядра) Вот тут-то Gmer и понимает, что нужны более серьезные меры. Его пользовательская часть (тот самый gmer.exe, который мы запускаем) отправляет специальную команду (через DeviceIoControl) своему драйверу, который работает в режиме ядра. Эта команда, по сути, говорит: "Эй, драйвер, стандартный метод не сработал. Заверши-ка принудительно процесс с PID 1234". В недрах ядра: Снимаем перчатки Теперь в игру вступает драйвер Gmer, обладающий максимальными привилегиями в системе. И вот тут начинается самое интересное: Получение доступа "с черного хода": Драйвер использует внутренние функции ядра (ZwOpenProcess), чтобы получить собственный, привилегированный дескриптор (handle) к целевому процессу. Этот дескриптор игнорирует стандартные ограничения прав доступа пользовательского режима. Отключение силового поля (Ключевой трюк!): Драйвер находит в памяти внутреннюю структуру ядра (EPROCESS), которая описывает целевой процесс. Зная точное расположение нужного поля в этой структуре (оно немного отличается в разных версиях Windows), драйвер напрямую изменяет значение этого поля, сбрасывая бит, отвечающий за защиту процесса! Это как найти главный рубильник защиты процесса и просто его выключить. Финальный удар: Теперь, когда защита процесса деактивирована, драйвер вызывает мощную функцию ядра (ZwTerminateProcess), чтобы завершить процесс. Поскольку флаг защиты был снят, эта команда выполняется успешно, в отличие от попытки из пользовательского режима. Уборка: Драйвер закрывает полученный им дескриптор процесса и сообщает пользовательской части Gmer об успехе. Заключение Как видите, Gmer не использует магию. Столкнувшись с защищенным процессом, он прибегает к помощи своего драйвера. Драйвер выполняет прямое низкоуровневое вмешательство в состояние процесса, отключая его защиту перед тем, как отдать команду на принудительное завершение. Это отлично демонстрирует, почему для эффективной борьбы с современными угрозами антируткит-инструментам необходим доступ на уровне ядра. Надеюсь, это объяснение было понятным и интересным!
Вообще это решается отключением наследования привилений ntfs у исполняемого файла и перезагрузкой. Но прога наверное очень полезная.
galenkane, Глупое это всё. Вы можете провести атаку, это делается реверсом ядра. Вообще о чём речь, если вы много знаете и знания эти некуда засунуть, то вам помогут.
Так ничего же не ясно. Что там за магические поля и чем вызовы ZwOpenProcess -> ZwTerminateProcess из драйвера отличаются от OpenProcess -> TerminateProcess из юзермода?
HoShiMin, Под копотом такое, что там сам чёрт ноги сломит. Не понимаю о чём спор. galenkane, Опишите задачу подробно, что бы понять можно было.