Remote debugger и защита от отладки. Упаковщик ExeCryptor

Помогите, пожалуйста, разобраться какая защита может использоваться, как ее обнаружить и как обойти.
Дано:
Windows XP в режиме отладки, в BOOT.INI прописан ключ /debug и /debugport
Программа упакована с помощью ExeCryptor. Если запустить эту программу, то операционка зависнет и это без подключенного отладчика. Если запустить отладчик на компе, который коннектиться для отладки, то увидим, что произошла точка останова в самой программе.
VirtualKD-Redux не меняет ситуацию.
Для отладки используется WinDbg, но это не имеет значение, т.к. зависон происходит именно при загрузке ОС в режиме отладки и запуске программы без подключенного отладчика.

Может кто сталкивался и сможет подсказать в какую сторону копать? Искал на просторах инета, но про ExeCryptor очень мало информации. Я так понимаю, что каким-то образом ставится бряк, а потом происходит модификация кода, если он проставился, но каким образом это происходит? (Это предположение, могу ошибаться)

 

c каких то пор ExeCryptor начал работать на уровне ядра?

о каком файле защищенном EC идет речь? почему для его отладки надо аж ядерный дебаггер?

 

Зависает из-за того, что ядро с включенным ядерным отладчиком ловит int 3 и ждёт, когда подключится отладчик, чтобы передать ему управление. ExeCryptor специально для такого поведения ничего не делал - систему морозит само ядро.
А конкретно эта антиотладочная проверка может выглядеть следующим образом:

Код (C++):

1. bool isDebuggerPresent = false;
2. __try
3. {
4.     __debugbreak();
5.     isDebuggerPresent = true; // Отладчик "проглотил" брейкпоинт: раз мы попали сюда - значит, нас отлаживают.
6. }
7. __except (EXCEPTION_EXECUTE_HANDLER)
8. {
9.     // Отладчика нет, т.к. на int 3 вылетело исключение
10. }

В случае ядерного отладчика ядро ловит __debugbreak(), останавливает систему и ждёт, пока ты подключишь отладчик.

 

Вот лишь некоторые из них: https://anti-debug.checkpoint.com/
Более того, софт может определить режим работы Win "defaul/debug" в ключе реестра: HKLM\SYSTEM\CurrentControlSet\Control=SystemStartOptions. Если режим отладки включён, то должна быть надпись "Debug" и "Port:XX". Определить, смотрит-ли ваш софт в реестр, можно любым апи-шпионом.

Какая версия, и как вы это узнали?
Если через DiE, то в его папке "DB\PE" лежат сигнатуры упаковщиков, по которым они чекаются. Там-же можно посмотреть либы + импорт/экспорт из них, в окне дампа по сигнатурам найти фиктивную ЕР пакера, etc. Для сбора инфы этого будет достаточно, т.к. DiE работает с образом файла на диске, не запуская его.

Кроме того есть дизассемблеры типа HIEW, в котором сразу можно подправить пару байт. Да и вообще обычный x64Dbg думаю решит здесь большинство проблем, т.к. скрывает себя от софта. Кстати чтобы завесить систему, ExeCryptor создаёт оооооочень много потоков, тч ищи CreateThread() в цикле.

PS\\ вот линк на туториары по почти всем пакерам:
https://storage.eymd.net/Technology...sing/Tuts4You Collection/Unpacking Tutorials/

 

Я не говорил, что работает на уровне ядра EC работает.

BE2Works v4.52 (Bohol)

Можно и другой, мне просто так проще отлавливать события. По EC сложно блуждать и удобней уже при частичной распаковки при каком-нибудь событие остановиться. Еще Windows XP на виртуалке крутится, а работать с дебаггером на виртуалке не очень удобно.

Я примерно так и подумал. Спасибо за код! Примерно понял как обойти эту ловушку. А есть возможность временно отключить поведение ядра по "int 3"?

Прикольный ресурс. Спасибо!

То что нужно! Премного благодарен!

Понял. Учту!

Да, через DiE, показывает "EXECryptor(2.2.4)[-]". Насчет либов и EP понял.

Если не продвинусь с WinDbg, то буду с x64Dbg пробовать, он мне и больше нравится. Просто думал, что с WinDbg попроще будет.

Еще раз спасибо всем, что ответили! Теперь есть пища для размышления, чтобы дальше продвигаться.
Вообще "Unpacker ExeCryptor 2.x.x. version 1.0 beta2" хорошо с распаковкой справился. Остались только антиотладочные приемы и проверка на изменения в файле. Сейчас при запуске выскакивает ошибка "File corrupted!" и происходит закрытие приложения.

--- Сообщение объединено, 13 фев 2024 ---

Было так "DEBUG DEBUGPORT=BAZIS FASTDETECT NOEXECUTE=OPTIN", убрал "DEBUG DEBUGPORT=BAZIS", но все равно срабатывает точка останова. Я так понимаю, что если бы по "INT 3" происходил бряк, то отладчик бы это обозначал, например при загрузке ОС и останове в отладчике так и прописывается "INT 3".
Вот с каким сообщением выкидывает в дебаггер

 

так WinDbg всегда останавливается на ЕР системного загрузчика образов.
теперь, как только отладчик остановится, вы установите бряк на точку-входа в программу, а потом жмите "g".
делается это так:

Код (Text):

1.  
2. ;// это системная точка
3. ntdll!LdrpDoDebuggerBreak+0x30:
4. 00000000`77737800 cc              int     3
5.  
6. ;// ставим свой бряк на точкe-входа в программу
7. 0:000> bp @$exentry
8.  
9. ;// проверим его..
10. 0:000> bl
11. 0 e 00000000`00402000     0001 (0001)  0:**** image00000000_00400000+0x2000
12.  
13. ;// теперь GO..
14. 0:000> g
15. Breakpoint 0 hit
16. image00000000_00400000+0x2000:
17. 00000000`00402000 4889e5          mov     rbp,rsp
18.  

--- Сообщение объединено, 13 фев 2024 ---

это если гонять в WinDbg под реальной машиной, а не коннектиться к клиенту

 

Это если через "Launch executable" запускать приложение. На скрине ниже скинул как выглядеть будет (write.exe запускал). Это бы я победил
Если же отладка происходит через remote, то при запуске приложения на удаленной машине брякаться не должно, а у меня происходит бряк и это в самой программе, а не в системной процедуре винды (Второй скрин прикрепил, чтобы понятно было).

 

BestMann, другой софт пробовал запускать на клиенте? WinDbg так-же на него реагирует?
Просто когда соединяешь клиента "сом-шнурком", отладчик функционирует в режиме ядра kd, и он может не видеть софт-уровень юзверя. Можешь попробовать приаттачиться к драйверу и посмотришь, где WinDbg остановится.