Что мы обычно представляем под исследованием бинарных файлов .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 спецификой.
