Что мы обычно представляем под исследованием бинарных файлов .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.
Читать далееИсточник: Хабрахабр
Источник: Gley (Перспективный мониторинг)
Другие материалы на сайте b.Z - Записки о гаджетах, людях и музыке