nitr0-g / binary-deobfuscation-preface-rus

This is a translated article into Russian. The original: https://calwa.re/reversing/obfuscation/binary-deobfuscation-preface

https://htmlpreview.github.io/?https://github.com/Nitr0-G/Binary-Deobfuscation-Preface-RUS/blob/main/calware%20-%20Binary%20Deobfuscation%20Preface%20RU.html

• index
• downloads
• about
• contact

Перевел Nitro

Деобфускация бинарников

Содержание

• Краткий экскурс в глубины деобфускации
• Рулзы
• The Roadmap
  • Знакомство с "врагами"
    • Комерс протекторы
    • Представляющие угрозу
    • "В благих целях"
  • Техники, подтемы и прочая ерунда
    • Instruction Substitution
    • Control Flow Flattening
    • Indirect Branches
    • Opaque Predicates
    • Function Inlining
    • Function Outlining
    • Dead Code
    • Junk Code
    • Constant Folding
    • Constant Unfolding
    • Virtualization
    • Self Modification
    • Jitting
    • Commercial Obfuscations
    • Malware Obfuscations
    • ‘Legitimate’ Obfuscations
• Вывод на сегодняшний день
• Дополнительное чтиво
• Ссылки на софт, который упоминался тута

---

Краткий экскурс в глубины деобфускации

Всем привет

Меня зовут Cal, и как вы прочитали вначале, это место, где я записываю свои опусы.

Я давно собирался собрать информацию об обфускации. Эта статья будет предисловием к моему путешествию в исследовании различных защитных механизмов и обфускации, которые они предоставляют.

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

Рулзы

Меня не интересует использование платных существующих инструментов. Я считаю, что это отталкивает как минимум часть читателей, и я против этого. Так что попрощайтесь со своей пиратской версией IDA и пр. дерьма - готовьтесь.

Кроме того, содержание этой серии в основном будет касаться образцов PE для Win64, но это не относится к инструментам. В попытке быть честным перед читателями и преодоления моего собственного знания бинарных файлов Linux я сделаю все возможное, чтобы написать несколько постов в этой области и смешать две темы, когда это будет уместно.

---

The Roadmap

В качестве начального упражнения я хотел бы изучить Obfuscator-LLVM (OLLVM). Это позволит нам создать множество гибких примеров конкретной обфускации и понять, что входит в их создание и слом. Это также послужит основой дляLLVM’s intermediate representation (IR),) и то, как мы можем использовать его(IR) для лучшего понимания работы обфускации программ.

Как только у нас будет база, мы начнем анализировать более крупные и развитые коммерческие средства защиты. В нем(OLLVM) я надеюсь поместить методы, скрывающие функцию программы, в контекст вышеупомянутогоOLLVM work.

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

---

Знакомство с "врагами"

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

Комерс

• Obfuscator-LLVM (OLLVM) (*) - https://github.com/obfuscator-llvm/obfuscator/wiki
• The Tigress C Diversifier/Obfuscator (*) - http://tigress.cs.arizona.edu/index.html
• ReWolf’s Virtualizer (*) - https://github.com/rwfpl/rewolf-x86-virtualizer
• ASProtect - http://www.aspack.com/asprotect64.html
• Obsidium - https://www.obsidium.de/show/details/en
• PELock - https://www.pelock.com/products/pelock
• Enigma Protector - https://enigmaprotector.com/
• CodeVirtualizer - https://www.oreans.com/codevirtualizer.php
• Themida - https://www.oreans.com/themida.php
• VMProtect - https://vmpsoft.com/
• GuardIT - https://www.arxan.com/application-protection/desktop-server

Люди адекватные, не продают свою поебень

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

Представляющие угрозу

• ZeusVM - https://en.wikipedia.org/wiki/Zeus_(malware)
• FinSpy VM - https://en.wikipedia.org/wiki/FinFisher
• Nymaim - https://www.cyber.nj.gov/threat-profiles/trojan-variants/nymaim
• Smoke Loader - https://www.cyber.nj.gov/threat-profiles/trojan-variants/smoke-loader
• Swizzor - https://en.wikipedia.org/wiki/Swizzor
• APT10 ANEL - https://en.wikipedia.org/wiki/Red_Apollo
• xTunnel - https://en.wikipedia.org/wiki/Fancy_Bear
• Uroburos/Turla - https://en.wikipedia.org/wiki/Turla_(malware)

Когда люди упоминают обфускацию, очень легко прийти к выводу о вирусне. Однако у этой медали есть и другая сторона, и без нее наш список был бы неполным. Ниже приведены примеры "законного" обфусцирования, которые я собрал. Это компании, стремящиеся скрыть внутреннюю работу своего кода по причинам, которые варьируются от денежного стимулирования до защиты прав потребителей (по крайней мере, так они говорят).

"В благих целях"

• Skype - https://www.skype.com/en/
• Spotify (See also Widevine) - https://www.spotify.com/us/
• Adobe Photoshop - https://www.adobe.com/products/photoshop.html
• BattlEye - https://www.battleye.com/
• EasyAntiCheat - https://www.easy.ac/en-us/
• Windows PatchGuard/Kernel Patch Protection - https://en.wikipedia.org/wiki/Kernel_Patch_Protection

Краткое примечание: некоторые из вышеперечисленных приложений были защищены с помощью записей комерс проты в нашем списке. В случае, если обфускация, реализованная этими приложениями, слишком сильно напоминает результаты работы наших коммерческих средств защиты, это будет указано и впоследствии опущено в будущих публикациях.

---

Техники, подтемы и прочая ерунда

В этом разделе я собираюсь описать методы обфускации, используемые вышеупомянутыми обфускаторами, и составить таблицу, чтобы представить распространенность указанных методов.

Instruction Substitution

Также известное как instruction mutation,

“...этот метод обфускации просто заключается в замене стандартных операторов (таких как addition, subtraction or boolean operators) функционально эквивалентными, но более сложными последовательностями инструкций”1

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

Давайте рассмотрим несколько примеров того, как это может работать.

mov eax, 1337h

Приведенный выше фрагмент кода на асме может быть преобразован во что-то вроде следующего:

add eax, 266Ch
        shr eax, 1h
        inc eax

Хотя эти два фрагмента могут выглядеть по-разному, но они всё равно функционально эквивалентны. Ниже я включил различные фазы примера функции, поскольку она преобразуется в соответствии с instruction substitution pass в OLLVM.

Original C Source Code

Clean Function Disassembly

Obfuscated Function Disassembly

Control Flow Flattening

Целью cfg является “полное сглаживание cfg программы”.2

The control flow graphздесь имеются в виду различные графы, сгенерированные инструментами анализа, которые показывают layout в виде basic blocks.

В дальнейшем,

“В cfg каждый узел(node) в графе представляет собой базовый блок, то есть прямолинейный фрагмент кода без каких-либо переходов или целей перехода; цели перехода начинают блок, а переходы заканчивают блок. Направленные edges используются для представления переходов в cf. В большинстве презентаций есть два специально выделенных блока: блок входа, через который управление поступает в граф потока, и блок выхода, через который весь cf выходит.”3

The original source code

The disassembly for our test function

The disassembly for our test function after being ran through one of OLLVM's control flow flattening obfuscation passes

Indirect Branches

An indirect branch,

“...вместо указания адреса следующей инструкции для выполнения, как в direct branch, аргумент указывает, где находится адрес”4

Простой способ представить это - последовательность инструкций, подобная следующей:

mov eax, function_address
        ...
        jmp eax

Вот пример indirect branch, взятый из одной из вышеперечисленных программ. Эта программа пронизана барчами, которые выглядят точно так же; и в то время IDA не могла следить за ними.

Opaque Predicates

“an opaque predicate is a predicate—an expression that evaluates to either “true” or “false”—for which the outcome is known by the programmer … but which, for a variety of reasons, still needs to be evaluated at run time” 5

Opaque predicates это особенно неприятная форма запутывания потока управления. Они бывают всех форм и размеров и определение opaque-ness может оказаться довольно сложной задачей.

Чтобы расширить приведенное выше объяснение, в контексте обфусцирвоанного файла это выражение “true” или “false” вычисляется в форме conditional branch. Ниже я включил небольшой пример opaque predicate.

mov eax, 4h
        ...
        cmp eax, 4h
        je label_1
        mov eax, 224h ; * this will never execute
        jmp label_187 ; *
        label_1:
        mov eax, 22h
        ...

Теперь, как вы можете ожидать, это нереалистичный пример opaque predicate. Однако этот пример действительно иллюстрирует идею использования conditional branches для обфускации cf программы. И хотя этот пример явно довольно прост, большинство реализаций этого метода таковыми не являются. Например, приведенная выше форма opaque predicate иногда упоминается как invariant opaque predicate. 6Также есть_contextual_ opaque predicates, значение которого не является самодостаточным, но которое зависит от значения внешней переменной (invariant). 6Также не стоит забывать о dynamic opaque predicates, которые являются частью группировки предикатов, расположенных таким образом, что все возможные пути выполняют одну и ту же базовую функциональность. 6 7- Все это лишь верхушка айсберга.

Opaque predicates также обычно возникают проблемы в аналитических платформах, когда делаются определенные предположения. Например, IDA Pro - это один из примеров инструмента, который ожидает хорошего, корректного кода. 8Ниже я привел пример того, что может произойти, когда вы нарушаете предположения, сделанные в ходе бинарного анализа IDA.

'Opaque' predicate assembly code

IDA Pro continues to disassemble the code

Improved 'opaque' predicate assembly code

Confusing IDA's analysis hides proceeding instructions

Как вы можете видеть в приведенной выше демонстрации, даже простые попытки отключить инструменты анализа могут значительно изменить выходные данные. Здесь IDA сделала предположение, что один фиктивный байт данных в нашем opaque predicate был opcode expansion prefix вынуждающим команду требовать по крайней мере еще один байт. Этот следующий байт, конечно же, вставлялся в реальную инструкцию, которая должна была быть выполнена.

Если кто-то не обращал внимания, вы могли бы пропустить, что IDA сигнализировала об этом преобразовании в инструкцииjz short near ptr loc_40100E+1где+1в конце внимательный реверс-инженер сообщит, что начальный бранч пропускает один байт в своем целевом местоположении. Ниже я показал очень простое исправление для этого преобразования.

Simple fix for the above transformation

Function Inlining

“В нормальной терминалогии inline expansion, или inlining, - это оптимизация вручную или компилятором, которая заменяет function call site телом вызываемой функции”9

Function inlining - это хорошо известный метод оптимизации компилятора. 10Вас не должно удивлять, что при неправильном использовании и в сочетании с другими нашими методами обфускации inline expansion может стать довольно эффективным средством обфускации. Возьмем следующий пример:

int bar (int val)
        {
        	return val * 2;
        }
        
        int foo (int a, int b)
        {
        	int c = bar(b);
        	return a + c;
        }

Чтобы уменьшить накладные расходы при этом вызове, ваш компилятор может выполнить inline expansion и разрешить функциюbarбудет inlined into foo, показано ниже:

int foo (int a, int b)
        {
        	int c = b * 2;
        	return a + c;
        }

Что, конечно, можно было бы еще больше уменьшить, устранив зависимость от переменной c, но вы поняли суть

Теперь представьте, что вместо умножения числа на два функцияbar отвечала за запись информации о времени выполнения в файл. В этой гипотетической функции логирования предположим, что мы также решили реализовать логику "с сюрпризом" относительно типа информации, которую мы регистрируем. Если функция fooвызывалась бы для логирования, даже всего пару раз, вы уже можете начать представлять, насколько наша функция расширилась бы на уровне source level; не говоря уже о дизассемблинге.

Иронично: наиболее эффективное средство упрощения inlining function также используется в качестве метода обфускации.

Function Outlining

“Выделите фрагментов функции в их собственные функции”11

Синонимом function splitting является широкое определение (и дальнейшая реализация) выделения функций. Некоторые протекторы просто разделяют базовые блоки функции, которые затем сохраняют прямое отношение "один к одному" внутри своей parent функции. Некоторые другие средства защиты создают совершенно новые функции, используемые несколькими разными callers. Например, возьмем следующую диаграмму:

ASU's Tigress C Obfuscator "Function Splitting" Diagram (source)

Приведенное выше изображение должно означать, что новые функции, f1 и f2, могут содержать код, который не был изначально представлен в оригинальной функцииf(например, пролог и эпилог). Это преобразование затем включило бы другие функции, которые могут полагаться на функциональностьf1 или f2, "опустить"(подразумевается как забыть) свой собственный код и вместо этого полагаться на outlined функцию.

Позже мы рассмотрим, как именно эта функция реализована в Tigress. Тем временем мы можем провести интересное сравнение с OLLVM. В отличие от подразумеваемой функции Tigress, описывающей реализацию, OLLVM ведет себя прямо противоположным образом. Дизассемблирование OLLVM сохранит прямую связь "one-to-one" со своим parent объектом в случае splitting pass.

Dead Code

“…dead code - некая часть в asm коде программы, который выполняется, но результат которого никогда не используется ни в каких других вычислениях“ 12

Кроме того, может быть важно отметить: регистры, которые мертвый код использует на протяжении всего своего жизненного цикла, иногда называются dead registers.!

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

mov eax, 2h
        add eax, 2h
        cmp eax, 4h
        ...

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

mov ebx, 24h ; *
        mov eax, 2h
        add ebx, 12h ; *
        add eax, 2h
        mov ecx, ebx ; *
        inc ecx ; *
        cmp eax, 4h
        ...

Поскольку приведенный выше мертвый код занимает регистры ebx и ecx, эти регистры теперь можно рассматривать мертвыми. Однако это не означает, что эти регистры всегда будут оставаться мертвыми. Занятие не-мертвыми,living code, восстановит статус живых =) ebx и ecx.

Junk Code

Также известный как unreachable code,

“… То, что никогда не выполнится, так как CF никогда этого не достигнет” 13

Одна из вещей, которую приведенный выше фрагмент не распознает, заключается в том, что в случае opaque predicate, вторичное условие которого никогда не выполняется, будет существовать CF к его местоположению. Я создал пример этого ниже:

mov eax, 4h
        ...
        cmp eax, 4h
        je label_1 		; (A)
        mov ecx, 1h 		; * this will never execute
        sub ebx, ecx 		; *
        push ebx 		; *
        call function_224	; *
        label_1: 		; (B)
        ...

Инструкции, вложенные между jcc (A) и нашей первой меткой (B), являются junk code; они никогда не будут выполнены. Однако это не останавливает существование CF к их местоположению.

Constant Folding

Чтобы понять идею constant unfolding (см. ниже), ты должен сначала понять идею constant folding.

“Constant folding - это процесс распознавания и оценки постоянных выражений во время компиляции, а не вычисления их во время выполнения.” 14

Предположим, мы начали с фрагмента кода, подобного следующему:

int x = 220;
        int y = (x / 2) + 1;

Constant folding, в данном случае это просто сокращение выражения, на которое указывает наша переменная yво время выполнения:

int x = 220;
        int y = 111;

Как указывалось выше, constant folding - это форма оптимизации, выполняемая компиляторами. Непосредственно, это не тот метод, который обычно соответствует обфускации кода!; но, учитывая контекст, constant folding вполне может быть использован как средство для скрытия функции кода; как это происходит со многими оптимизациями компилятора.

Constant Unfolding

В то время как в качестве метода обфускации можно использовать как constant folding, так и constant unfolding, чаще наблюдается constant unfolding.!

Учитывая приведенный выше пример constant folding, я сконструировал более сложный пример constant unfolding ниже. Кое-что, о чем следует помнить: хотя constant folding и unfolding кажется легким делом, не позволяйте этому ввести вас в заблуждение. Помните, что сила обычно заключается в реализации.

int x = 220;
        int y = (((x - 0xAA) | 0x58) ^ (((((x / 4) * 0x138759) >> 0x10) & 0x11) + 0x6)) + 0x3;

Итак, на минутку представьте, что приведенная выше арифметика выполняется в асме, среди других операций, через flattened функцию, и все это выполняется через VM.

Virtualization

“Vcpu” 15

Это оно.

Виртуальные машины, используемые при обфускации кода, не похожи на VMware или VirtualBox. У них нет подобных технологий AMD-V или Intel VT-x(к счастью). Вместо этого VM, найденные в обфусцированных двоичных файлах, являются просто интерпретаторами.!

Исходный, невиртуализированный код базового файла был преобразован в пользовательский байт-код(PCODE). Этот PCODE передается интерпретатору, задачей которого является имитация действий указанного базового двоичного файла.

Orean's CodeVirtualizer vm-based protection diagram (source)

Выше я прикрепил скрин работы комерс виртыCodeVirtualizer. Как вы можете видеть, упрощенный код слева преобразуется в совершенно другой набор команд справа.

Я понимаю, что приведенного выше объяснения не хватает. Проблема с подробным описанием этого метода обфускации сейчас заключается в потенциальной вариативности его реализации. Итак, давайте поставим точку в этом вопросе. Я значительно подробнее остановлюсь на этой технике в следующих постах.

Self Modification

Это код, который изменяет сам себя, сейчас бы не хотелось говорить об этом, так как он тоже зависит от реализации

Однако мне не терпится изучить эту технику, поскольку она потребует от нас создания нескольких примеров для отработки.

Jitting

Наконец, я хочу кратко обсудить концепцию jitting.

“В нормальной терминологии JIT-компиляция (также динамическая трансляция или компиляции во время выполнения) - это способ выполнения кода, который включает компиляцию во время выполнения программы - во время выполнения – а не перед выполнением”.17

Можно многое сказать о потенциале этой техники. Это тот, который, как я полагаю, используется только в Tigress C Diversifier. Это также техника, которую мы будем развивать в примерах, которые мы создаем.

Что интересно так это то, чтоTigress также включает в себя возможность реализовать преобразование, называемое JitDynamic, который “... похож на Jit-преобразование, за исключением того, что jit-код постоянно модифицируется и обновляется во время выполнения”18. Тогда этот метод было бы лучше классифицировать как самоизменяющийся код.

Приведенная ниже таблица в значительной степени основана на информации, которую я прочитал у других; и процитирована соответствующим образом. Данные, в которых отсутствуют ссылки, в значительной степени спекулятивны или подкреплены проведенными мной исследованиями, которые не будут обнародованы. Приложения, методы и порядок их использования - все это может быть изменено. Со временем этот фрагмент будет заменен, и вместо существующих ниже будут использованы цитаты из моего собственного исследования. А пока отнеситесь ко всему, что приведено в таблице ниже, с недоверием и ознакомьтесь с этими цитатами (если таковые имеются).

---

Commercial Obfuscations

Application

Instruction Substitution

Control Flow Modification

Indirect Branches

Opaque Predicates

Function Inlining

Function Outlining

Dead Code

Junk Code

Constant Unfolding

Virtualization

Self Modification

Jitting

Tigress

✅19

✅19

✅19

✅19

✅19

✅19

✅19

✅19

✅19

✅19

✅19

✅19

Themida

✅20

✅!

✅!

✅!

❌!

✅!

✅!

✅!

✅!

✅20

❌!

❌!

VMProtect

✅21

✅!

✅!

✅21

❔

✅21

✅21

✅21

✅!

✅21

❌!

❌!

GuardIT

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

PELock

✅22

✅22

✅22

✅22

❌!

✅22

✅22

✅22

❌!

❌!

❌!

❌!

OLLVM

✅23

✅24

❌!

✅25

❌!

✅24

❌!

✅25

✅23

❌!

❌!

❌!

CodeVirtualizer

✅26

❌!

❌!

❌!

❌!

❌!

❌!

❌!

❌!

✅26

❌!

❌!

ReWolf’s Virtualizer

❌!

❌!

❌!

❌!

❌!

❌!

❌!

❌!

❌!

✅27

❌!

❌!

Enigma Protector

✅28

❔

❔

❔

❌!

❔

❔

❔

❔

✅28

❌!

❌!

Obsidium

❌!

❔

❔

❔

❌!

❔

❔

❔

❔

✅29

❌!

❌!

ASProtect

❌!

❔

❔

✅30

❌!

❔

❌!

✅30

❔

❌!

❌!

❌!

Malware Obfuscations

Application

Instruction Substitution

Control Flow Modification

Indirect Branches

Opaque Predicates

Function Inlining

Function Outlining

Dead Code

Junk Code

Constant Unfolding

Virtualization

Self Modification

Jitting

ANEL

❌!

✅31

✅31

✅31

❌!

❌!

✅31

✅31

✅31

❌!

❌!

❌!

Smoke Loader

❌!

✅32

❔

✅32

❌!

✅32

❌!

❔

❔

❌!

✅32

❌!

Nymaim

❌!

✅33

✅33

✅34

❌!

❌!

❔

❔

✅34

❌!

❌!

❌!

xTunnel

❌!

❔

❔

✅35 36

❌!

❌!

✅37

✅35

❔

❌!

❌!

❌!

Uroburos/Turla

❌!

❔

❔

✅38

❌!

❌!

❔

✅38

❔

❌!

❌!

❌!

FinSpy VM

❌!

❔

❌!

✅39

❌!

❌!

✅39

✅!

✅39

✅40 39

❌!

❌!

ZeusVM

❌!

❔

❔

❔

❌!

❌!

❔

❔

❔

✅41

❌!

❌!

Swizzor

❌!

❔

❔

❔

❌!

❌!

✅42

❔

❔

❌!

❌!

❌!

‘Legitimate’ Obfuscations

Application

Instruction Substitution

Control Flow Modification

Indirect Branches

Opaque Predicates

Function Inlining

Function Outlining

Dead Code

Junk Code

Constant Unfolding

Virtualization

Self Modification

Jitting

BattlEye

✅!

✅!

✅!

✅!

❌!

✅!

✅!

✅!

✅!

✅!

❌!

❌!

EasyAntiCheat

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

Photoshop

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

Spotify

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

❔

PatchGuard

❌!

✅43 44

✅45

❔

❌!

❌!

❔

❔

❔

❌!

✅46

❌!

Skype

❌!

✅47

✅47

✅47

❌!

❌!

❌!

❔

❔

❌!

❌!

❌!

Примечание: Во многих вышеуказанных приложениях используются различные формы модификации CF, которые не являются CF flattening. Таким образом, я обобщил эту категорию в таблице выше.

---

Вывод

В этом посте я сделал несколько смелых и амбициозных заявлений. Системы, подобные PatchGuard они мне совершенно неизвестны. Вредоносное ПО, подобное Turla и Sednitэто спонсируемые государством угрозы с высокоприоритетными целями. Не говоря уже о том, что обфускация, используемое всеми вышеперечисленными защитами и т.п. штукой, считается сложным - очень трудным для работы материалом. Существует нехватка простых, прямолинейных решений; и исследования по разработке такого инструментария, как правило, проводятся в академических кругах.

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

Как бы то ни было, сейчас я даю вам обещание: мое исследование будет применимо к современной обфускации. Я не буду отклоняться от цели, которые я сформулировал изначально.

Чтиво

Выше я упоминал, что наиболее заметные исследования в области деобфускации в основном проводятся в академических кругах. Обычно эти ресурсы сухие, и их трудно прочесть. Итак, чтобы не утомлять вас скучными и умозрительными исследованиями, ниже я сделал все возможное, чтобы перечислить ресурсы, которые, по моему мнению, были практичными и привлекательными.

• Diablo - Deobfuscation: By Hand (https://diablo.elis.ugent.be/node/54)
• The Tigress C Diversifier/Obfuscator: Transformations (http://tigress.cs.arizona.edu/transformPage/index.html)
• Intermediate Representation - Wikipedia (https://en.wikipedia.org/wiki/Intermediate_representation)
• Usenix - Disassembling Obfuscated Binaries (https://www.usenix.org/legacy/publications/library/proceedings/sec04/tech/full_papers/kruegel/kruegel_html/node3.html)
• Optimizing Compiler (Specific Techniques) - Wikipedia (https://en.wikipedia.org/wiki/Optimizing_compiler#Specific_techniques)
• Compiler Optimizations for Reverse Engineers - Rolf Rolles, Mobius Strip Reverse Engineering (https://www.msreverseengineering.com/blog/2014/6/23/compiler-optimizations-for-reverse-engineers)
• Udupa, Sharath K., Saumya K. Debray, and Matias Madou. “Deobfuscation: Reverse engineering obfuscated code.” 12th Working Conference on Reverse Engineering (WCRE’05). IEEE, 2005. (https://ieeexplore.ieee.org/abstract/document/1566145)
• Deobfuscation: recovering an OLLVM-protected program (https://blog.quarkslab.com/deobfuscation-recovering-an-ollvm-protected-program.html)
• Aspire - Publications (https://aspire-fp7.eu/papers)
• Creating Code Obfuscation Virtual Machines - RECon 2008 (https://www.youtube.com/watch?v=d_OFrP-m2xU)

---

References

1. Obfuscator-LLVM: Instruction Substitution - https://github.com/obfuscator-llvm/obfuscator/wiki/Instructions-Substitution ↩

2. Control Flow Flattening (Wikipedia) - https://github.com/obfuscator-llvm/obfuscator/wiki/Control-Flow-Flattening ↩

3. [PDF] Masking wrong-successor Control Flow Errors employing data redundancy - https://ieeexplore.ieee.org/abstract/document/7365827 ↩

4. Indirect Branch (Wikipedia) - https://en.wikipedia.org/wiki/Indirect_branch ↩

5. Opaque Predicate (Wikipedia) - https://en.wikipedia.org/wiki/Opaque_predicate ↩

6. Thomas Ridma. “Seeing through obfuscation: interactive detection and removal of opaque predicates.” In the Digital Security Group, Institute for Computing and Information Sciences. 2017. - https://th0mas.nl/downloads/thesis/thesis.pdf ↩ ↩2 ↩3

7. Palsberg, Jens, et al. “Experience with software watermarking.” Proceedings 16th Annual Computer Security Applications Conference (ACSAC’00). IEEE, 2000. - https://ieeexplore.ieee.org/document/898885 ↩

8. Hex-Rays: IDA and obfuscated code - https://www.hex-rays.com/products/ida/support/ppt/caro_obfuscation.ppt ↩

9. Inline Expansion (Wikipedia) - https://en.wikipedia.org/wiki/Inline_expansion ↩

10. Eilam, Eldad. *Reversing: Secrets of Reverse Engineering*. Wiley, 2005. Print. - https://www.wiley.com/en-us/Reversing%3A+Secrets+of+Reverse+Engineering+-p-9780764574818 ↩

11. The Tigress C Diversifier/Obfuscator: Function Splitting - http://tigress.cs.arizona.edu/transformPage/docs/split/index.html ↩

12. Dead Code (Wikipedia) - https://en.wikipedia.org/wiki/Dead_code ↩

13. Unreachable Code (Wikipedia) - https://en.wikipedia.org/wiki/Unreachable_code ↩

14. Constant Folding (Wikipedia) - https://en.wikipedia.org/wiki/Constant_folding ↩

15. Virtual Machine (Wikipedia) - https://en.wikipedia.org/wiki/Virtual_machine ↩

16. Self-Modifying Code (Wikipedia) - https://en.wikipedia.org/wiki/Self-modifying_code ↩

17. Just-in-time Compilation (Wikipedia) - https://en.wikipedia.org/wiki/Just-in-time_compilation ↩

18. The Tigress C Diversifier/Obfuscator: Dynamic Obfuscation - http://tigress.cs.arizona.edu/transformPage/docs/jitDynamic/index.html ↩

19. The Tigress C Diversifier/Obfuscator: Transformations - http://tigress.cs.arizona.edu/transformPage/index.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

20. Oreans: Themida Overview - https://www.oreans.com/Themida.php ↩ ↩2

21. VMProtect Software Protection: What is VMProtect? - http://vmpsoft.com/support/user-manual/introduction/what-is-vmprotect/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6

22. PELock: Software protection system - https://www.pelock.com/products/pelock ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

23. Obfuscator-LLVM: Instruction Substitution - https://github.com/obfuscator-llvm/obfuscator/wiki/Instructions-Substitution ↩ ↩2

24. Obfuscator-LLVM: Control Flow Flattening - https://github.com/obfuscator-llvm/obfuscator/wiki/Control-Flow-Flattening ↩ ↩2

25. Obfuscator-LLVM: Bogus Control Flow - https://github.com/obfuscator-llvm/obfuscator/wiki/Bogus-Control-Flow ↩ ↩2

26. Oreans: CodeVirtualizer Overview - https://oreans.com/CodeVirtualizer.php ↩ ↩2

27. [PDF] ReWolf’s x86 Virtualizer: Documentation - http://rewolf.pl/stuff/x86.virt.pdf ↩

28. The Enigma Protector: About - https://enigmaprotector.com/en/about.html ↩ ↩2

29. Obsidium: Product Information - https://www.obsidium.de/show/details/en ↩

30. David, Robin, Sébastien Bardin, and Jean-Yves Marion. “Targeting Infeasibility Questions on Obfuscated Codes.” arXiv preprint arXiv:1612.05675 (2016). - https://arxiv.org/pdf/1612.05675 ↩ ↩2

31. Carbon Black: Defeating Compiler-Level Obfuscations Used in APT10 Malware - https://www.carbonblack.com/2019/02/25/defeating-compiler-level-obfuscations-used-in-apt10-malware/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6

32. CERT.PL: Dissecting Smoke Loader - https://www.cert.pl/en/news/single/dissecting-smoke-loader/ ↩ ↩2 ↩3 ↩4

33. ESET: Dymaim Obfuscation Chronicles - https://www.welivesecurity.com/2013/08/26/nymaim-obfuscation-chronicles/ ↩ ↩2

34. CERT.PL: Nymaim Revisited - https://www.cert.pl/en/news/single/nymaim-revisited/ ↩ ↩2

35. [PDF] ESET: En Route with Sednit (Part 2) - https://www.welivesecurity.com/wp-content/uploads/2016/10/eset-sednit-part-2.pdf ↩ ↩2

36. [PDF] Sebastien Bardin, Robin David, Jean-Yves Marion. “Deobfuscation: Semantic Analysis to the Rescue”. Presentation at Virus Bulletin (2017). - https://www.virusbulletin.com/uploads/pdf/conference_slides/2017/Bardin-VB2017-Deobfuscation.pdf ↩

37. [PDF] Robin David, Sebastien Bardin. “Code Deobfuscation: Intertwining Dynamic, Static and Symbolic Approaches”. Presentation at BlackHat Europe (2016). - https://www.robindavid.fr/publications/BHEU16_Robin_David.pdf ↩

38. [PDF] ESET: Diplomats in Easter Europe Bitten by a Turla Mosquito - https://www.eset.com/me/whitepapers/eset-turla-mosquito/ ↩ ↩2

39. Mobius Strip Reverse Engineering: A Walk-Through Tutorial, with Code, on Statically Unpacking the FinSpy VM (Part One, x86 Deobfuscation) - https://www.msreverseengineering.com/blog/2018/1/23/a-walk-through-tutorial-with-code-on-statically-unpacking-the-finspy-vm-part-one-x86-deobfuscation ↩ ↩2 ↩3 ↩4

40. Github: Rofl Rolles’ Static Unpacker for FinSpy VM - https://github.com/RolfRolles/FinSpyVM ↩

41. Miasm’s Blog: ZeusVM Analysis - https://miasm.re/blog/2016/09/03/zeusvm_analysis.html ↩

42. Pierre-Marc Bureau, Joan Calvet. “Understanding Swizzor’s Obfuscation Scheme”. Presentation at RECon (2010). - https://archive.org/details/UnderstandingSwizzorsObfuscationScheme-Pierre-marcBureauAndJoanCalvet ↩

43. CSDN iiprogram’s Blog: Pathguard Reloaded, A Brief Analysis of PatchGuard Version 3 - https://blog.csdn.net/iiprogram/article/details/2456658 ↩

44. Uninformed: Subverting Patchguard Version 2; Obfuscation of System Integrity Check Calls via Structured Exception Handling - http://uninformed.org/index.cgi?v=6&a=1&p=8 ↩

45. Uninformed: Subverting Patchguard Version 2; Anti-Debug Code During Initialization - http://uninformed.org/index.cgi?v=6&a=1&p=5 ↩

46. Uninformed: Subverting Patchguard Version 2; Overwriting PatchGuard Initialization Code Post Boot - http://uninformed.org/index.cgi?v=6&a=1&p=12 ↩

47. [PDF] Philippe Biondi, Fabrice Desclaux. “Silver Needle in the Skype”. Presentation at BlackHat Europe (2006). - https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf ↩ ↩2 ↩3

Check out my Github