райтап по крэкми с анти-дебаг защитой IsDebuggerPresent обход

[kate2000]

Застрял на крэкми с crackmes.one, уровень 3/6. Бинарь под Windows x86-32. При запуске под x64dbg программа сразу вылетает с 'wrong'. Судя по всему, там анти-дебаг. Нашёл вызов IsDebuggerPresent, запатчил возвращаемое значение на 0 через условный перехват — но всё равно падает. Есть ещё что-то, что я пропускаю?

[svelte1]

IsDebuggerPresent — это лишь один из десятка способов. Следующий кандидат — CheckRemoteDebuggerPresent, его часто ставят в паре. Ищи в импортах или через строковый поиск 'NtQueryInformationProcess' — там флаг ProcessDebugPort тоже выдаёт дебаггер. В x64dbg есть плагин ScyllaHide, он закрывает большинство стандартных техник одним кликом.

[jpearce]

ScyllaHide реально спасает жизнь в таких случаях. Но если хочешь разобраться руками — вот полный список того что стоит проверить: 1) PEB.BeingDebugged (тот самый IsDebuggerPresent), 2) PEB.NtGlobalFlag (значение 0x70 при дебаггере), 3) heap flags в PEB.ProcessHeap, 4) NtQueryInformationProcess с классом 7 (ProcessDebugPort), 5) timing-атаки через RDTSC или GetTickCount — если между двумя вызовами прошло слишком много времени, значит шагают по коду. Для RDTSC-трюков помогает плагин 'FixTSC' или патчинг самих инструкций.

[hunter22]

Тайминговые проверки вообще самые неприятные — их скриллой не обойдёшь. Я обычно ищу паттерн: два вызова RDTSC подряд, между ними какая-то операция, потом cmp и jmp. Патчу jmp на безусловный или просто ставлю брейк после второго RDTSC и руками правлю регистры.

[burg0809]

Можешь скинуть хэш бинаря или ссылку? Интересно глянуть. В крэкмях уровня 3 ещё иногда встречается SEH-антидебаг — намеренно вызывают исключение и проверяют кто его обрабатывает. Под отладчиком исключение перехватывает дебаггер, а не обработчик программы, и ветка кода идёт другая.

[svelte1]

Ещё вариант который часто забывают — проверка родительского процесса. Если ppid не explorer.exe (или конкретный лаунчер), программа считает себя запущенной под дебаггером. Лечится либо плагинами, либо запуском x64dbg от имени Explorer через inject.

[rocknrolla]

В итоге как решил? Пиши райтап — такие вещи полезно документировать, потом сам же и забудешь через полгода какой трюк там был.

[fpga_lord]

@kate2000, раз патчишь IsDebuggerPresent а оно всё равно валится, почти наверняка читают PEB напрямую через fs:[30h]+2, в обход импорта, поэтому твой перехват мимо. ScyllaHide это закроет одним кликом. Но сначала по-простому, поставь хардварный бряк на чтение байта BeingDebugged и посмотри кто его трогает, сразу вылезет вторая проверка которую пропустил.

[lxxyl]

@jpearce, список годный, только NtGlobalFlag не везде 0x70, значение собирается из FLG_HEAP_ENABLE_TAIL_CHECK и компании, под x64 смещение другое. Я бы ещё дописал старый трюк с OutputDebugStringA, под дебагом не выставляет ошибку и по GetLastError палят отладчик. Хотя для уровня 3 из 6 это уже перебор, там скорее всего тупо PEB.BeingDebugged и всё.

[GolangHacker]

уровень 3 из 6 на crackmes.one, анти-дебаг там обычно учебный, не накручивайте. Скрилла плюс бряк на entry point и за полчаса вскрывается. Если реально застрял на день, ты что-то базовое пропустил, типа что TLS callback отрабатывает раньше main и проверка сидит именно там.