• XSS.stack #1 – первый литературный журнал от юзеров форума

Чем можно дебажить процесс изолированный на уровне ядра?

Отслеживать

dort

RAID-массив
Пользователь
Регистрация
30.03.2020
Сообщения
94
Реакции
61
Депозит
0.004
Есть игра, защищенная анти-читом. Просто так прочитать память не дает, удается читать память только через kernel driver
Но кастомной сборкой cheat engine и сборкой драйвера ядра, удается использовть почти полный функционал cheat engine для этой игры ,включая DBVM дебаггер. Насколько я понял, это дебаггер в виртуальной машине, который позволяет дебажить целевую через драйвер устройства.
Но этот дебаггер встроенный в Cheat Engine довольно не удобный, и медленный.

Какие есть еще вараинты дебаггеров, которыми можно дебажить такие защищенные процессы?
P.S. с помощью HyperDBG мне удалось добиться только стабильного бсода системы
 
Тема интересная.
Советую для начала понять как отображаются процессы на уровне пользывателя а потом на уровне ядра, а конкретно структуры "PEB" и "_EPROCESS", относительно .

При запуске приложения происходит следуйщие:
Считывается .EXE файл, если структура файла соответствует формату PE файла то идет обращение к "Kernel32.dll" файлу каторый содержит функцию "CreateProcess" для создания процесса - это называется API вызов.

По скольку ядро отвечает за распределения ресурсов в системе, "Кernel32.dll" обращается к "ntdll.dll" с просьбой получить ресурсы для процесса, используя "NtCreateProcess " - это называется системный вызов.

В свою очередь, "ntdll.dll" обращается на премую к ядру и создает объект (структура с переменномы и пойнтерами к другим структурам) по имени "_EPROCESS". Этот объект содержит всю возможную информацию о процессе (ID процесса, загруженные модули, имя процесса и многая другая информация).

Когда "_EPROCESS" создан, он добавлен в круговой связанный список полностью создании из других объектов "_EPROCESS" - это называется рутины.

После создания и добовления объекта "_EPROCESS", "ntdll.dll" предаёт данные этого объекта обратно на уровень пользывателя, что позволяет создать объект процесса на уровне пользывателя.
Созданий объект будет называца "PEB" (Process Environmental Block - Блок Среды процесса).
В состав этого объекта войдут только честичные данные от объекта "_EPROCESS".

На этом теория грубо говоря все.
Вернемся к проблеме.

Анти-чит который находится на уровне ядра будит следить за объектом "_EPROCESS" каторый отображаед игру, а конкретно будет проверяться переменная "IsProcessDebugged" каторая как раз и будет возврощять True в случии использывания софта как Cheat Engine.

Как вариант, можно написать давольно простую программу каторая может заредить эксплоитируемый драйвер, как например HEVD, на уровне ядра, чтобы найти "_EPROCESS" анти-чита, найти переменную ответственаю за проверку "_EPROCESS" игры (будет легко найти, ищем поинтер указывуйший на место в патите где находится ID процесса игры и забываем ему место в патите где находится ID процесса самого анти-чита).

Подом образом:
✅Анти-чит работает - игра запустится.
✅Анти-чит не следит за игрой - можно пачить.

Я могу ошибаться в каких либо деталях, если кто хочет добавить\исправить я с удовольствием прочитаю :)
 
0xS3rpant сказал(а):
Анти-чит который находится на уровне ядра будит следить за объектом "_EPROCESS" каторый отображаед игру, а конкретно будет проверяться переменная "IsProcessDebugged" каторая как раз и будет возврощять True в случии использывания софта как Cheat Engine.
There's not a literal, single, official bool "IsProcessDebugged" in _EPROCESS. There's a ptr to a DebugPort (and some flags in EPROCESS.Flags) and usermode has a PEB.BeingDebugged field. But yes, the concept of "flag set if debugger's attached" does exist.
 
0xS3rpant сказал(а):
Как вариант, можно написать давольно простую программу каторая может заредить эксплоитируемый драйвер, как например HEVD, на уровне ядра, чтобы найти "_EPROCESS" анти-чита, найти переменную ответственаю за проверку "_EPROCESS" игры (будет легко найти, ищем поинтер указывуйший на место в патите где находится ID процесса игры и забываем ему место в патите где находится ID процесса самого анти-чита).

Подом образом:
✅Анти-чит работает - игра запустится.
✅Анти-чит не следит за игрой - можно пачить.
Это работает не так, и не так просто как вам кажется, а так же античит сканирует другие процессы, следит за их действиями
 
Дебажить такой процесс можно, с помощью встроенного в чит енджн DBVM дебаггера (https://www.cheatengine.org/aboutdbvm.php)
И античит это не видит (по крайней мере никаких мер администрация игры не предпринимает)
Просто не очень удобный дебаггер и довольно медленно работает, и хотелось бы узнать есть ли такие же дебаггеры как DBVM которые работают из виртуальной машины
 
dort сказал(а):
Какие есть еще вараинты дебаггеров, которыми можно дебажить такие защищенные процессы?
P.S. с помощью HyperDBG мне удалось добиться только стабильного бсода системы
в древние времена был такой скальпель, как SoftICE

SoftICE — отладчик режима ядра для Microsoft Windows[1]. Разработана для управления процессами на низком уровне Windows, причём таким образом, чтобы операционная система не распознавала работу отладчика. В отличие от прикладного отладчика, SoftICE способен приостановить все операции в Windows, что очень важно для отладки драйверов.

Изначально разработан компанией NuMega, которая включала его в пакет программ для быстрой разработки высокопроизводительных драйверов под названием Driver Studio, который впоследствии был приобретён Compuware. Последняя версия была выпущена для Windows XP, с 2007 года продукт снят с поддержки.

Отладчик также был популярен как инструмент для взлома программного обеспечения.
 
0xS3rpant сказал(а):
Тема интересная.
Советую для начала понять как отображаются процессы на уровне пользывателя а потом на уровне ядра, а конкретно структуры "PEB" и "_EPROCESS", относительно .

При запуске приложения происходит следуйщие:
Считывается .EXE файл, если структура файла соответствует формату PE файла то идет обращение к "Kernel32.dll" файлу каторый содержит функцию "CreateProcess" для создания процесса - это называется API вызов.

По скольку ядро отвечает за распределения ресурсов в системе, "Кernel32.dll" обращается к "ntdll.dll" с просьбой получить ресурсы для процесса, используя "NtCreateProcess " - это называется системный вызов.

В свою очередь, "ntdll.dll" обращается на премую к ядру и создает объект (структура с переменномы и пойнтерами к другим структурам) по имени "_EPROCESS". Этот объект содержит всю возможную информацию о процессе (ID процесса, загруженные модули, имя процесса и многая другая информация).

Когда "_EPROCESS" создан, он добавлен в круговой связанный список полностью создании из других объектов "_EPROCESS" - это называется рутины.

После создания и добовления объекта "_EPROCESS", "ntdll.dll" предаёт данные этого объекта обратно на уровень пользывателя, что позволяет создать объект процесса на уровне пользывателя.
Созданий объект будет называца "PEB" (Process Environmental Block - Блок Среды процесса).
В состав этого объекта войдут только честичные данные от объекта "_EPROCESS".

На этом теория грубо говоря все.
Вернемся к проблеме.

Анти-чит который находится на уровне ядра будит следить за объектом "_EPROCESS" каторый отображаед игру, а конкретно будет проверяться переменная "IsProcessDebugged" каторая как раз и будет возврощять True в случии использывания софта как Cheat Engine.

Как вариант, можно написать давольно простую программу каторая может заредить эксплоитируемый драйвер, как например HEVD, на уровне ядра, чтобы найти "_EPROCESS" анти-чита, найти переменную ответственаю за проверку "_EPROCESS" игры (будет легко найти, ищем поинтер указывуйший на место в патите где находится ID процесса игры и забываем ему место в патите где находится ID процесса самого анти-чита).

Подом образом:
✅Анти-чит работает - игра запустится.
✅Анти-чит не следит за игрой - можно пачить.

Я могу ошибаться в каких либо деталях, если кто хочет добавить\исправить я с удовольствием прочитаю :)
А где можно структурировано почитать о том, как можно найти структуру _EPROCESS в памяти ядра, ну и про саму структуру?
 
dort сказал(а):
А где можно структурировано почитать о том, как можно найти структуру _EPROCESS в памяти ядра, ну и про саму структуру?
WinDBG: dt nt!_EPROCESS
www.vergiliusproject.com

Vergilius Project

Take a look into the depths of Windows kernels and reveal more than 60000 undocumented structures.
www.vergiliusproject.com www.vergiliusproject.com
 
dort сказал(а):
как можно найти структуру _EPROCESS в памяти ядра, ну и про саму структуру?
У каждого процесса в системе своя EPROCESS, а ядро оси связывает их все в последовательную цепочку. Для этого в структурах EPROCESS имеются 2 указателя на следующую Forward, и предыдущую Backward структуру в общей цепочке. При такой организации, если найти любую из структур EPROCESS, то двигаясь по указателям вперёд (или назад) можно обойти весь список активных процессов, и сделав круг вернуться опять к себе. Линк на свою EPROCESS можно получить в ядре функцией PsGetCurrentProcess(), однако для своих нужд ядро читает свою переменную PsActiveProcessHead, которая хранит указатель на структуру процесса "system" - именно этот процесс считается в доках началом связанного списка LIST_ENTRY. Вот логи в отладчике WinDbg:

Код: 
0: kd> dps nt!PsActiveProcessHead       <-------- Запросить дамп по адресу переменной

fffff800`02c2e960  fffffa80`039ce1c8    <-------- Указатель на EPROCESS "system"
fffff800`02c2e968  fffffa80`0467bc88
fffff800`02c2e970  00000000`00000000
fffff800`02c2e978  00000000`00000000

0: kd> dt _eprocess fffffa80`039ce1c8-0x188 UniqueProcessId ActiveProcessLinks ImageFileName Peb
ntdll!_EPROCESS
   +0x180 UniqueProcessId    : 0x00000000`00000004         <------------------------------------ PID процесса SYSTEM ----//
   +0x188 ActiveProcessLinks : _LIST_ENTRY [ 0xfffffa80`04b57c88 - 0xfffff800`02c2e960 ]  <----- Связанный список -------//
   +0x2d8 ImageFileName      : [15]  ""                    <------------------------------------ Строка с именем процесса
   +0x330 Peb                : 0x00000000`00000000 _PEB    <------------------------------------ Нет линка на PEB

0: kd> db fffffa80`039ce1c8-0x188+0x2d8
fffffa80`039ce318  00 00 00 00 00 00 00 00-53 79 73 74 65 6d 00 00  ........System..  <--------- Имя процесса
fffffa80`039ce328  00 00 00 00 00 00 00 02-00 00 00 00 00 00 00 00  ................
fffffa80`039ce338  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
fffffa80`039ce348  78 ef 9c 03 80 fa ff ff-78 3f c3 03 80 fa ff ff  x.......x?......

Проблема здесь в том, что если вы и получите указатель на EPROCESS жертвы, то для доступа к ней вам понадобится блокировка от стороннего вмешательства, которую не так просто получить на современных ОС. Вы можете читать память любых процессов в ядре, но для их модификации вам потребуется дескриптор защитного мьютекса синхронизации, значение которого известно только ядру, как создателю процесса. Если сможете найти мьютекс, то есть доступ на RW, иначе облом.

community.osr.com

PsGetCurrentProcess and PsActiveProcessHead

Hello All , I want to enumrate the EPROCESS struct information for all running process and want to manipulate it. I have PsActiveProcessHead pointer,I saw it in debug symbols… I want to trverse the Process list using AcriveProcessHead pointer , can anybody explain me , what type of...
community.osr.com community.osr.com
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх