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

Тема в разделе "WASM.RESEARCH", создана пользователем BestMann, 13 фев 2024.

  1. BestMann

    BestMann New Member

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

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

    alex_dz Active Member

    Публикаций:
    0
    Регистрация:
    26 июл 2006
    Сообщения:
    340
    c каких то пор ExeCryptor начал работать на уровне ядра?

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

    HoShiMin Well-Known Member

    Публикаций:
    5
    Регистрация:
    17 дек 2016
    Сообщения:
    1.427
    Адрес:
    Россия, Нижний Новгород
    Зависает из-за того, что ядро с включенным ядерным отладчиком ловит 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(), останавливает систему и ждёт, пока ты подключишь отладчик.
     
  4. Marylin

    Marylin Active Member

    Публикаций:
    0
    Регистрация:
    17 фев 2023
    Сообщения:
    110
    Вот лишь некоторые из них: 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/
     
  5. BestMann

    BestMann New Member

    Публикаций:
    0
    Регистрация:
    2 мар 2021
    Сообщения:
    3
    Я не говорил, что работает на уровне ядра 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".
    Вот с каким сообщением выкидывает в дебаггер
     

    Вложения:

  6. Marylin

    Marylin Active Member

    Публикаций:
    0
    Регистрация:
    17 фев 2023
    Сообщения:
    110
    так 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 под реальной машиной, а не коннектиться к клиенту
     
  7. BestMann

    BestMann New Member

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

    Вложения:

  8. Marylin

    Marylin Active Member

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