Ангард! Реверсирование приложения, защищенного DNGuard

Фантазия разработчиков, желающих защитить свою программу, иногда не знает границ. Часто одного навешанного на Софтину протектора им недостаточно, и, как монахиня из известного анекдота, они натягивают подряд несколько таких. Иногда этим же грешат и сами разработчики средств защиты. Случай такого симбиоза IL-обфускатора с VMProtect мы рассмотрим в сегодняшней статье.

обфускатор .NET DNGuard HVM Это было довольно долгое время, за которое он успел обзавестись изрядным количеством фич (анти-отладка и анти-дамп, полное шифрование всей информации в модуле и очень успешное противодействие статическому и динамическому анализу). Несмотря на широкую известность и хорошую изученность (в свое время CodeCracker запилил множество распаковщиков для разных версий DNGuard и родственных фреймворков), за последние несколько лет не было инструментов для анализа и распаковки актуальных версий этого обфускатора. Вплоть до того, что популярные инструменты (да и обнаруживать его легко) до сих пор даже не научились их обнаруживать. Поэтому я надеюсь, что сегодняшняя статья поможет читателям узнать, как распознать эту заразу и бороться с ней подручными средствами.

Итак, допустим, в ваши цепкие руки попала сборка, защищенная DNGuard. Есть два варианта. Первое: нам повезло, и это одна из старых изученных версий, дальше все понятно и можно смело использовать один из дамперов DNGuard_HVM_Unpacker от CodeCracker. Возможно, когда-нибудь я расскажу об особенностях и даже принципах работы утилит. Однако DNGuard быстро совершенствуется, и проект, по всей видимости, давно заброшен: последней версией поддерживаемого фреймворка была 4.2, а физическая привязка к конкретным файлам библиотек настолько сильна, что использование этих наработок просто невозможно. Малопригоден для деобфускации новых версий.

Поэтому сразу переходим к печальному варианту. Как я писал выше, текущие версии хоть и не обнаруживаются, но сильно не прячутся. В рабочем каталоге программы сразу бросается в глаза библиотека runtime.dll (или с похожим названием), с висящим на нем VMProtect по минимуму.

В библиотеке находятся две экспортируемые функции: VMRuntime И GetUserString (Или ResolveString).

Еще одна характерная особенность — раздел VMProtect. hvm0Из-за чего эта связь, как я понимаю, и получила свое название.

Однако наличие библиотеки в директории в явном виде не обязательно, последние версии научились хранить ее в зашифрованном виде в теле основной программы, порождая ее при загрузке в системные временные директории типа . нравиться Temp Или ProgramData. Сама программа, защищенная обфускатором, также выглядит вполне типично при загрузке в отладчик типа DNSPY.

Как видите, стартовый код программы характеризуется наличием класса с методами CheckRuntime, CheckString, GetUserString И так далее и импорт упомянутых выше функций из библиотеки Runtime.dll. Как и во всех серьезных обфускаторах, о которых я писал в предыдущих статьях, имена других классов, методов, строк и ресурсов жестко закодированы, а тела методов пусты или содержат исключение “Ошибка, библиотека времени выполнения DNGuard не загружена!” (И даже эту строку можно зашифровать).

Собственно, если мы попытаемся запустить такое приложение из отладчика, то максимум, что мы сможем увидеть, это инициализацию стартового кода DNGuard перед нативным вызовом VMRuntime, после чего он перехватывает JIT-компилятор и мы прощаемся с отладчиком, catch аналогичное исключение.

Попытка присоединения к запущенному процессу тоже не дает полезного результата, как и сброс его всеми известными дамперами. Поэтому закрываем DnSpy и начинаем вспоминать железо, в том числе информацию, представленную в моей статье “Реверсирование .NET. Как искать JIT-компилятор в приложениях.

Для тех, кто не читал статью, кратко напомню суть. Как известно, любая сборка .NET устроена следующим образом: кроссплатформенный IL-код хранится в специальных метаданных, из которых он загружается по мере выполнения каждого метода и компилируется в нативный код специальной функцией. Функция возвращает указатель на него. GetGit библиотеки clrjit.dllОднако фреймворк позволяет пользователю задать адрес на самом компиляторе, чем втайне пользуются создатели всевозможных обфускаторов, подменяя его собственными процедурами декодирования IL-кода.