Пользователь
- Статус
- Оффлайн
- Регистрация
- 21 Окт 2018
- Сообщения
- 219
- Реакции
- 338
Всем привет. На связи я, Dark_Bull! Сегодня я с вами не надолго, но буду делиться с вами новым способом обхода(нашел сам) VMProtect 3.5.0 x64 build 1213;
=========================================================
Все опыты проводились на Windows 10 x64 1909 (Сборка ОС 18363.1016) – процессор Intel
Подопытный: C++ x64 PE-файл, максимальный пресет защиты от протектора
TitanHide – не использовался
=========================================================
=========================================================
Все опыты проводились на Windows 10 x64 1909 (Сборка ОС 18363.1016) – процессор Intel
Подопытный: C++ x64 PE-файл, максимальный пресет защиты от протектора
TitanHide – не использовался
=========================================================
Давайте разбираться, что же такого завезли нам в новой версии.
Для начала подготовим ScyllaHide:
Далее, в настройках ядра самого отладчика(x64dbg) нужно установить “Тип точек останова по умолчанию” на “UD2”:
Всё дело в том, что UD2 меньше обнаруживается самим VMProtect, пользуйтесь) Наверняка, если хотите, подгрузите TitanHide, но мне не пригодился.
Дело в том, что как вы могли заметить, при отладке какого-либо приложения, защищенного новой версией протектора, вы, как в старых версиях, не получаете 3-nop-исключения. Всё это происходит из-за одного трюка вмпшки, который мы с вами сейчас будем обходить. Плагины тоже не могут это обойти, т.к. вызов происходит непосредственно через SYSCALL.
Ищем все SYSCALL’s путем поиска паттерна “0F0568”, где “0F05” – сама инструкция SYSCALL, а “68” – нужен для отсеивания лишних SYSCALL’s.
Далее, устанавливаем на все наши найденные инструкции брейкпоинты.
И нажимаем “Выполнить” до тех пор, пока в регистре RAX не будет значение 0xD.
Почему 0xD? Потому что это и есть новый трюк протектора. Дело в том, что SYSCALL 0xD, это вызов WinAPI-функции “NtSetInformationThread” с константой, которая думаю вам всё скажет своим названием - “ThreadHideFromDebugger”(или же 0x11, значение лежит в регистре RDX):
Далее меняем 0x11, в регистре RDX на любое другое, но только не 0x11, будете получать результат выполнения функции в регистре RAX с ошибкой – не обращайте внимание на нее, всё хорошо ?
УДАЛЯЕМ ВСЕ ТОЧКИ ОСТАНОВА, и только после этого нажимаем “Выполнить”
Вуаля, что мы видим? Наши заветные NOP-исключения:
Секция с кодом программы расшифрована. Далее просто ставим аппаратный бряк на ваше OEP, как его искать, думаю вы знаете) Ну или WinAPI-шные функции брякайте. GetCommandLineA - ваш друг
Пожалуйста, зарегистрируйтесь или авторизуйтесь, чтобы увидеть содержимое.
Последнее редактирование:
Теперь ждём, как сольют байпасс фейсита
