Как снять vmprotect с dll

Обновлено: 06.07.2024

На сайте я скачал триальную версию и запросил для нее пробный ключ, который мне и прислали на имейл. Теперь можно начинать изучение программы и ее механизма регистрации.

Процесс

Программа устанавливается в директорию C:\Program Files (x86)\Deleaker как standalone, хотя есть вариант интеграции Deleaker в Visual Studio в виде дополнения (.vsix). Но я не пользуюсь Visual Studio, и для меня такой способ был недоступен.

В директорию были установлены такие файлы.

Запускаем программу и вводим присланный ключ. Софтина обещает нам пробный период использования.

Инструменты, которые нам понадобятся

x64dbg — отладчик;
DIE aka Detect It Easy — анализатор файлов;
CFF Explorer — PE-редактор;
MASM — компилятор.

Итак, проверив все исполняемые файлы анализатором DIE, в директории установленной программы находим две DLL’ки, «накрытые» VMProtect:

Я предположил, что механизм (код) лицензирования (регистрации) находится именно в них.

Зачем нужны две DLL’ки?

Забегу вперед: DLL’ки идентичны, единственное различие — одна 32-битная, другая 64-битная. Механизм лицензирования (регистрации) используется только из deleakersdk32.dll, что облегчает нашу задачу.

Далее я открыл deleakersdk32.dll в CFF Explorer и зашел в директорию Export. Там нашлись четыре экспортируемые функции с говорящими именами.

Эти функции как раз и отвечают за лицензирование (регистрацию) программы.

Но это не беда, мы просто запускаем Deleaker.exe и аттачимся к процессу x64dbg.

В окне Symbols отладчика, в левой половине находим и выделяем курсором нашу DLL. Справа мы увидим список ее импортируемых и экспортируемых функций. Нас интересуют только те, что мы обнаружили ранее в CFF Explorer. Выделяя по очереди курсором функции, нажимаем клавишу F2, тем самым устанавливая точки останова (breakpoints) на начало исполнения кода этих функций.

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Анализ вредоносных программ, защищающих себя от анализа, — это всегда дополнительные трудности для вирусного аналитика. Программа может быть обфусцирована, чтобы избежать детектирования сигнатурными и эвристическими анализаторами антивирусов или затруднить специалисту ее статический анализ. Можно, конечно, запустить программу в виртуальной среде, но и от такого исследования ВПО могут иметь средства защиты. В общем, это постоянная борьба. Злоумышленники придумывают и дорабатывают свои методы обфускации, могут использовать их на этапе разработки программы или обрабатывать уже готовые, скомпилированные модули. Никто не мешает им воспользоваться готовыми продвинутыми решениями, которые созданы специально для защиты легитимного программного обеспечения от анализа и взлома.

Одним из таких популярных решений уже давно является протектор VMProtect. После того как вирусописатели стали активно использовать для своих программ подобные взломанные протекторы, антивирусные компании создали "черные" и "серые списки" таких решений и начали детектировать образцы по самому коду протекторов. Сейчас наблюдается очередная волна активного использования VMProtect злоумышленниками для защиты вредоносного ПО от детектирования и анализа. Но и исследователи не стоят на месте: есть замечательные решения по деобфускации и девиртуализации VMProtect. Основное из них — VTIL Project исследователя Can Bölük. Но и оно, к сожалению, не является панацеей.

Текущая волна использования VMProtect характеризуется активным применением протектора китайскими вирусописателями для защиты своих вредоносных драйверов Windows x64. Известно, что анализ подобных драйверов — головная боль вирусных аналитиков. Получив очередной такой драйвер на анализ, Андрей Жданов, специалист по проактивному поиску киберугроз Group-IB, решил поделиться достаточно простыми подходами, которые облегчат анализ этих вредоносных программ.

Что нам потребуется:
1. The Interactive Disassembler (IDA) 7.0 и выше
2. Виртуальная среда — гостевая ОС Windows 7 x64 или выше
3. Python
4. Volatility (я использовал Volatility 3)
5. Unicorn

Этап 1: получение дампа драйвера

Загружаем драйвер в виртуальной среде. Для этого можно воспользоваться штатной утилитой sc.exe:

sc create <svc_name> binpath= <driver_path> type= kernel start= demand

Или загрузить драйвер с помощью утилиты DriverLoader, которая использует функцию NtLoadDriver:

DriverLoader_x86-64.exe <driver_path> <svc_name>

Если при загрузке возникли проблемы, связанные с цифровой подписью драйвера, — можно воспользоваться утилитой dseo013b.exe (Driver Signature Enforcement Overrider).

После успешной загрузки снимаем полный дамп памяти. Если виртуальная машина (например, VMware) при снимке создает корректный дамп памяти, то можно обойтись и снимком памяти.

Используем Volatility для извлечения всех модулей ядра из дампа:

vol -f <dump_path> -o <dest_dir> Modules --dump

Проверяем, что среди них есть и наш драйвер, а остальные модули пока оставляем — они пригодятся нам позже.

Мы получили дамп исследуемого драйвера. Это не исходный файл до обработки с помощью VMProtect — начальные значения данных утеряны — но его уже можно открыть в IDA и пытаться анализировать, хоть и не в полной мере.

Этап 2. Получение списка вызовов импортируемых функций

Весь код дампа драйвера содержит вызовы, подобные call sub_F88004CFEFE9 . Тело самой функции содержится в секции .vmp0 и представляет собой обфусцированный код с множеством условных и безусловных переходов и манипуляциями с регистрами. Таким образом VMProtect обфусцирует каждый вызов импортируемой функции в "защищенном" файле. Обычно вызов импортируемой функции выглядит так:

FF 15 08 2A 00 00 call cs:LoadLibraryA

VMProtect заменяет его на следующий вызов:

E8 08 72 03 00call vmp_LoadLibraryA

Функция vmp_LoadLibraryA в процессе работы получает фактический адрес функции LoadLibraryA и передает ей управление. Но, как мы видим, после вызова такой обфусцированной функции может оставаться байт, что надо учитывать при анализе в IDA. Возврат из обфусцированной функции в этом случае осуществляется правильно, на следующий после этого байта адрес.

На данном этапе необходимо получить список адресов таких функций. Для этого мы с помощью скрипта IDAPython осуществляем перебор всех функций секции .vmp0 , вызов которых осуществляется извне, из другой секции.

В итоге получаем список RVA (Relative Virtual Address) таких функций в текстовом файле:

Этап 3. Получение оригинальных адресов импортируемых функций

Чтобы получить адреса оригинальных импортируемых функций, воспользуемся кодом самих обфусцированных функций VMProtect. Для этого загрузим полученный дамп драйвера как shellcode в отладчике x64dbg в виртуальной среде. Для запуска в качестве shellcode можно воспользоваться готовой утилитой или разработать свою, которая просто выделяет память (VirtualAlloc), копирует туда shellcode и передает ему управление. Однако здесь следует сделать замечание: это справедливо для дампа, где RVA и позиции в файле совпадают. В противном случае необходимо загружать дамп как PE-файл, по секциям.

Передавать управление на заголовок MZ драйвера мы, конечно, не будем, а поместим на это место код вызова каждой обфусцированной функции. Будем пошагово отлаживать ее код и в конечном итоге извлекать оригинальный адрес импортируемой функции. С помощью x64dbgpy и скрипта на Python можно полностью автоматизировать этот процесс: сначала скрипт считывает из текстового файла список RVA обфусцированных функций, а по окончании сохраняет уже в другой текстовый файл список RVA и соответствующих им оригинальных адресов импортируемых функций:

Читайте также: