Средний

7 мин

11K

Что мы обычно представляем под исследованием бинарных файлов .NET? Обычно все просто: открываешь сборку в DnSpy или ILSpy, получаешь очень близкий к исходнику C# (может и не очень близкий, а обфусцированный) и дальше уже думаешь не про восстановление логики, а про анализ исходного кода — даже не нужно нажимать F5...

В стандартных .NET-сборках компилятор сохраняет символы приложения в виде метаданных, необходимых для работы рантайма и рефлексии. DnSpy даже поддерживает экспорт содержимого сборки в проект для Visual Studio, что размывает границу между исследованием исходников и бинарного файла.

Но платформа от Microsoft развивается, и теперь .NET-приложения могут исполняться не только через CLR, но и компилироваться в машинный код целевой платформы с помощью Ahead-Of-Time. Исторически первым таким решением стал NGEN (2002) — установочная предкомпиляция для .NET Framework, однако он требовал ручного запуска, дублировал IL-код и не обновлялся автоматически при изменении рантайма. Затем, в 2015 году, появился .NET Native — первый полноценный AOT, но исключительно в UWP-приложениях для Windows Store. В современной ветке .NET (Core/5+) следующим шагом стал ReadyToRun (2019), с возможностью переключения на IL, а затем и Native AOT, в котором была полностью убрана зависимость сборки от рантайма .NET.

В данной статье рассмотрим, с чем может столкнутся реверсер при исследовании .NET приложений, собранных с использованием Ahead-Of-Time компиляции в современных версиях .NET.

Тестовый код

Чтобы проследить изменения в сборке .NET приложений, сравним три разных способа доставки одного и того же кода. Соберём небольшой тестовый проект в трёх вариантах:

• Обычный управляемый IL-код под CLR;

• ReadyToRun;

• Native AOT.

Среда эксперимента: Windows x64, .NET SDK 8.0.419, runtime 8.0.25.

Для сопоставления получившихся сборок возьмем код, чуть более сложный, чем вывод Hello, world. В нём опишем небольшой некриптографический хеш-генератор LicenseEngine со статическими методами DeriveKey, MixBlock и точкой входа Main:

static class LicenseEngine
{
    [MethodImpl(MethodImplOptions.NoInlining)]
    public static int DeriveKey(string name, int salt)
    {
        var value = salt ^ 0x5A17;
        for (var i = 0; i < name.Length; i++)
        {
            value = (int)BitOperations.RotateLeft((uint)value, 5) ^ name[i];
            value += i * 17;
        }

        return value & 0x7FFFFFFF;
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    public static ulong MixBlock(ReadOnlySpan<byte> data, ulong seed)
    {
        var acc = seed ^ 0x9E3779B185EBCA87UL;
        for (var i = 0; i < data.Length; i++)
        {
            acc ^= data[i];
            acc *= 0x100000001B3UL;
            acc = BitOperations.RotateLeft(acc, 7);
        }

        return acc;
    }

    public static void Main(string[] args)
    {
        var key = DeriveKey("hello", 1337);
        Console.WriteLine($"Derived key = {key}");

        byte[] payload = System.Text.Encoding.UTF8.GetBytes("Hello, world!");
        ulong seed = (uint)key;
        seed = MixBlock(payload, seed);
        Console.WriteLine($"Mixed hash (ulong) = 0x{seed:X16}");
    }
}

.NET Common Language Runtime: IL

Обычно стандартная сборка .NET содержит только управляемый код (Intermediate Language - IL, MSIL, CIL), а CLR/CoreCLR уже JIT-компилирует его в машинный код в момент выполнения:

Такой бинарь собирается без специальных флагов:

dotnet publish -c Release -o artifacts/coreclr

После сборки, перед нами классический исполняемый файл .NET с PE, DOS, CLI заголовками. DnSpy без проблем восстановил тестовый LicenseEngine. К примеру, метод DeriveKey:

Важно отметить, что при использовании режимов сборки CLR или ReadyToRun, в зависимости от значения флага PublishSingleFile, сборка может производится раздельно (apphost в EXE, а .NET-код в DLL) или одним EXE файлом (зависимости и IL код). При PublishSingleFile=true DetetctItEasy не сможет подсказать нам о наличии IL кода в сборке — пользовательский код вместе с зависимостями будет храниться в оверлее бинарного файла.

Для наглядности в тестовых сборках не будет использоваться флаг PublishSingleFile (кроме NativeAOT, в нем этот флаг выставлен всегда).

ReadyToRun: IL + ASM

С ростом популярности .NET для создания самых разных типов приложений, возросла потребность в оптимизации медленного запуска, обусловленного JIT.

ReadyToRun был впервые представлен в .NET Core 3.0 (2019) как способ ускорения исполнения — здесь IL-код используется только для совместимости и переоптимизаций, тогда как CLR использует нативные инструкции, скомпилированные перед исполнением (Ahead-Of-Time compilation).

Для сборки R2R необходимо указать PublishReadyToRun=true:

dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true -o artifacts/r2r

В CLI-заголовке появляется ManagedNativeHeader, указывающий на заголовок директории ReadyToRun — READYTORUN_HEADER с магическими-байтами RTR\x00 (0x00525452):

ReadyToRun часто воспринимают как «почти Native AOT», но для реверсера это не совсем так. По файлу с R2R видно сразу три вещи.

Во-первых, размер DLL вырос с 6 до 20 КБ. Теперь он содержит и IL и нативный код.

Во-вторых, R2R уже платформозависим. Если обычная IL-сборка была архитектурно-нейтральной, то здесь DLL привязана к Amd64:

В-третьих, DnSpy всё ещё работает. Он все так же хорошо декомпилирует IL. Например, метод MixBlock:

IDA так же определяет .NET сборку:

Но теперь мы можем найти реализацию любой функции под amd64, например, все той же MixBlock:

Так как в R2R методы хранятся в двух форматах, возникают вопросы: что именно будет исполняться во время работы программы и как это патчить в случае необходимости?

При запуске R2R сборки, рантайм .NET будет исполнять предпочтительно нативную реализацию методов, но ровно до того момента как вызываемый метод «нагреется» (более 30 вызовов). В таких случаях в ход вступает Tiered Compilation — CLR использует JIT и перекомпилирует IL в Tier 1 с наилучшей оптимизацией. То есть заранее узнать, какой именно код будет исполнен — нативный (Tier 0) или IL (Tier 1), — возможно не всегда.

Если мы хотим поменять инструкции и в отладчике проследить все изменения, можно смело использовать DnSpy. Он исполняет только IL и все патчи в нем будут применяться при отладке. Такое поведение DnSpy связано с тем, что его настройки по умолчанию не поддерживают оптимизации IL и встроенный дебаггер принудительно JIT-компилирует весь промежуточный код, игнорируя ReadyToRun. Проблема лишь в том, что без отладчика CLR будет исполнять нативный код, что напрямую повлияет на результат.

Ещё один вариант — заставить целевой бинарь всегда использовать JIT через переменные окружения CLR:

set COMPlus_ReadyToRun=0

После этого мы сможем посмотреть, как CLR JIT-компилирует и исполняет байткод с помощью COMPlus_JitDisasm=SomeFunc. В этом случае можно смело патчить IL-код и запускать бинарь без R2R.

Вся эта необычная логика исполнения ReadyToRun-приложений наталкивает на мысль о сокрытии кода в одной из его форм хранения. Такая техника называется R2R stomping, подробное исследование этого метода было описано в статье Checkpoint Research.

Native AOT: ASM

В .NET 7+ (2022) появилась возможность собирать self-contained приложения, заранее скомпилированные в нативный код и не использующие JIT во время выполнения. После публикации это полностью нативный исполняемый файл, для которого уже нужен классический дебагер и дизассемблер машинного кода целевой платформы.

Для сборки NAOT необходимо указать PublishAot=true:

dotnet publish -c Release -r win-x64 -p:PublishAot=true -o artifacts/nativeaot

Секции тестового Native AOT-файла выглядят так:

Вот и ответ на вопрос, почему реверс .NET-приложений может ассоциироваться и с IDA Pro. Перед нами x64 PE: без CorHeader и открытых метаданных, с нативными секциями и характерным экспортом DotNetRuntimeDebugHeader:

NAOT позволяет усложнить реверс инжиниринг файла из коробки: теперь у исследователя не будет «исходников» из DnSpy, а без отладочных символов у него не будет вообще ничего для статического анализа. Помогут только FLIRT сигнатуры или BinDiff.

Но все же эта программа написана не на C++ (хотя и очень похоже обилием таблиц виртуальных функций), а поэтому .NET сохраняет некоторую информацию в метаданных.

В тестовой Native AOT DLL можно найти строки: LicenseEngine, DeriveKey, MixBlock. Эти имена сохранены для поддержки рефлексии, трейса стека и т. д. Зато статические строковые литералы из Main вроде "hello" в файле отсутствуют и ссылаются на неинициализированные данные в секции hydrated:

Дело в том, что в NAOT часть рантайм-структур хранится в секции .rdata в компактной форме и десериализуется во время выполнения процесса (data-rehydration). В уже известной нам директории ReadyToRun находятся ссылки на эти данные — DEHYDRATED_DATA и FROZEN_OBJECT_REGION. Эти структуры включают:

• Таблицы методов — содержат методы класса, как C++ Vftable, но с дополнительными метаданными (тип, размер, хэш-код, количество реализуемых интерфейсов и т. д). Так как в C# каждый класс является наследником System.Object — минимальный набор методов: ToString(), Equals(), GetHashCode();

• Объекты — состоят из информации для сборщика мусора, полей класса и указателя на таблицу методов;

• Объекты строк и массивов (frozen objects).

Native AOT .NET 7 еще не поддерживал data-rehydration, в .NET 8 структуры десериализуются в специальную секцию hydrated, в .NET 9 дополнительной секции нет — распаковка происходит в .data, а в 10 версии .NET данный функционал перестал применяться по-умолчанию в Windows-сборках (используется только при OptimizationPreference=Size).

Сериализация структур, огромное количество таблиц виртуальных функций, разница реализаций NAOT для 7-10 версий платформы значительно затрудняют статический реверс-инжиниринг сборок Ahead-of-Time. Для упрощения анализа Native AOT приложений мы разработали плагин для IDA Pro ida-nativeaot. Проект был вдохновлён идеями из дополнения ghidra-nativeaot для Ghidra.

Плагин десериализует dehydrated-структуры .NET NativeAOT (строки и массивы) в секцию hydrated/.data, восстанавливает таблицы методов на основе поиска System.Object и его наследников, а также применяет FLIRT сигнатуры NAOT для PE/ELF .NET версий от 7 до 10.

После использования плагина, псевдокод целевой программы становится намного понятнее для анализа:

Параллельный мир: Unity, Mono и IL2CPP

Если смотреть чуть шире, то похожий сдвиг от IL к машинному коду давно произошёл и в мире Unity. Игровой движок с ростом популярности так же столкнулся с проблемами скорости и мультиплатформенности среды .NET. И стал решать их по-своему, опередив в AOT самих Microsoft и представив IL2CPP в 2015 году.

IL2CPP — это не режим публикации CLR и не разновидность Native AOT в экосистеме .NET. У Unity свой пайплайн: код сначала компилируется в обычный IL, а потом Unity-конвейер переводит его в C++, из которого уже получается нативный бинарь.

Из-за этого практическая разница для реверса выглядит так:

• В Unity Mono-сборках достаточно открыть Assembly-CSharp.dll в dnSpy/ILSpy;

• В Unity IL2CPP-сборках привычного байткода для анализа нет. Основными артефактами становятся нативный модуль вроде GameAssembly.dll и файл global-metadata.dat.

Так что реверс .NET — это не только про DnSpy и IL. На практике исследователю вполне могут повстречаться как анализ гибридного ReadyToRun, так и Native AOT нативного бинаря с .NET спецификой.