Obfusk8: Библиотека обфускации на C++17

Obfusk8 — это легкая, header-only библиотека на C++17, предназначенная для значительного усиления обфускации ваших приложений, что делает обратную разработку значительно более сложной задачей. Она достигает этого с помощью разнообразных методов во время компиляции и выполнения, направленных на защиту логики и данных вашего кода.

---

Содержание

1. Основные стратегии обфускации
2. Зависимости
3. Визуализация
4. Анализ движка и профиль обнаружения
5. Структурные и криминалистические характеристики
6. Использование
7. Сборка
8. Демо
9. Вклад и обратная связь

---

Основные стратегии обфускации

1. Обёртывание функции main (макрос _main)

Точка входа вашего приложения (main) преобразуется в сложный, многоуровневый движок обфускации:

• Выполнение виртуальной машины (концептуально): Перед выполнением вашего кода main_body мини-ВМ (эмулируемый процессор) запускает последовательность «зашифрованных» инструкций. Это скрывает истинную точку входа и начальные операции. Состояние ВМ (регистры, счётчик команд, ключ диспетчеризации) инициализируется случайными значениями во время выполнения.
• Непрямое выравнивание потока управления (ICFF): Критические циклы внутри макроса _main (как в прологе, так и в эпилоге) преобразуются в сложные конечные автоматы. Поток управления не является прямым, а определяется сильно «зашифрованными» переменными состояния. Ключи кодирования/декодирования этих переменных состояния динамичны, они зависят от состояния ВМ, счётчиков циклов, случайности времени компиляции (например, __COUNTER__, __LINE__, __TIME__) и глобального непрозрачного начального числа. Это делает статический анализ потока управления чрезвычайно сложным.
  • Используются два различных движка ICFF (obf_icff_ns_dcff и obf_icff_ns_epd) с разной логикой перехода состояний и генерацией ключей, что ещё больше усложняет анализ.
• Фиктивный поток управления (макросы OBF_BOGUS_FLOW_*): По всему _main внедряются многочисленные вводящие в заблуждение шаблоны переходов и запутанные условные конструкции. Они используют операторы goto в сочетании с непрозрачными предикатами (условия, которые всегда истинны или ложны, но вычислительно дороги или трудно определяемы статически). Это создаёт лабиринт ложных путей для дизассемблеров и декомпиляторов.
  • Включает OBF_BOGUS_FLOW_LABYRINTH, OBF_BOGUS_FLOW_GRID, OBF_BOGUS_FLOW_SCRAMBLE, OBF_BOGUS_FLOW_WEAVER, OBF_BOGUS_FLOW_CASCADE и OBF_BOGUS_FLOW_CYCLONE для генерации разнообразных и сложных фиктивных потоков.
• Антианализ и антиотладка (макрос Runtime, SEH):
  • Принудительные исключения и SEH: Используется Structured Exception Handling (SEH) для создания путей, включающих принудительные исключения. Блоки __except могут изменять состояние программы, что затрудняет её отслеживание, если отладчик пропускает исключения.
  • Проверки отладчика (концептуально): Макрос Runtime содержит условия, которые при выполнении (из-за определённых состояний ВМ или временных задержек) могут вызвать __debugbreak() или выбросить исключения, предназначенные для нарушения сеансов отладки.

2. Виртуальный ISA-движок (obf_vm_engine)

Ключевой компонент обфускации макроса _main:

• Эмуляция мини-ЦПУ: Эмулирует процессор с волатильными регистрами (r0, r1, r2), счётчиком команд (pc) и ключом диспетчеризации (dispatch_key). Он выполняет пользовательские «инструкции» (обработчики).
• Обфусцированные инструкции: Обработчики инструкций ВМ выполняют операции, которые сильно маскируются с помощью смешанной булево-арифметики (MBA) и битовых манипуляций. Обработчики включают арифметику, битовую логику, искажение ключей, мусорные последовательности, условные обновления, эмуляцию памяти и искажение счётчика команд.
• Динамическая диспетчеризация: Выбор следующего обработчика инструкций ВМ рандомизируется с помощью нескольких механизмов диспетчеризации:
  • Диспетчеризация на основе регистра (reg_dispatch_idx).
  • Диспетчеризация на основе таблицы памяти (перемешанная таблица указателей на функции get_mem_dispatch_table).
  • Смешанная диспетчеризация (mixed_dispatch_idx). Ключ диспетчеризации (dispatch_key) постоянно мутирует, что делает последовательность выполняемых обработчиков высоконепредсказуемой.
• Мутация таблицы обработчиков: Сама таблица обработчиков инструкций ВМ (vm_handler_table) мутируется во время выполнения в прологе и эпилоге _main, что ещё больше скрывает поведение ВМ.

3. Шифрование строк на этапе компиляции (OBFUSCATE_STRING из AES8.hpp)

• Скрытые строки: Шифрует все строковые литералы на этапе компиляции с помощью модифицированного шифра AES.
• Динамические ключи: Ключи шифрования уникальны для каждого экземпляра строки и формируются на основе содержимого строки, расположения файла (__FILE__, __LINE__) и времени сборки (__DATE__, __TIME__).
• Дешифрование по требованию: Строки расшифровываются в стеке только при обращении к ним во время выполнения, что минимизирует время нахождения их открытого текста в памяти.
• (Опционально) Обманные PE-секции: Может хранить зашифрованные строки в пользовательских PE-секциях, предназначенных для имитации распространённых сигнатур упаковщиков, что потенциально может ввести в заблуждение аналитиков (функция, специфичная для MSVC, из AES8.hpp).

4. Скрытый вызов Windows API (STEALTH_API_OBFSTR / STEALTH_API_OBF из Resolve8.hpp)

• Скрытие IAT: Позволяет избежать создания прямых, легко идентифицируемых записей для Windows API в таблице импорта (IAT).
• Разрешение на основе PEB: Динамически находит базовые адреса загруженных DLL и адреса функций API, напрямую анализируя структуры данных Process Environment Block (PEB) во время выполнения. Это обходит стандартные GetModuleHandle и GetProcAddress для первоначального разрешения, если они сами ещё не разрешены этим механизмом.
• Хэшированные имена: Использует хэширование на этапе компиляции (пользовательский алгоритм CT_HASH) имён DLL и API для поиска. Это предотвращает появление имён DLL и API в открытом виде в данных, связанных с импортом, или в таблицах строк двоичного файла при использовании этих макросов.

5. Движок косвенного системного вызова (K8_SYSCALL)

Obfusk8 теперь включает современный механизм косвенного системного вызова для обхода пользовательских перехватчиков (EDR/AV) и проверок статического анализа.

• Разрешение «Сортировочная шляпа»: Вместо чтения секции .text ntdll.dll (которая часто перехватывается или отслеживается) движок анализирует экспортный каталог. Он фильтрует функции, начинающиеся с Zw, сортирует их по адресу в памяти и определяет номер системного вызова (SSN) на основе их индекса. Это позволяет разрешить SSN, не затрагивая исполняемый код.
• Латеральное выполнение гаджетов: Движок не содержит инструкцию системного вызова (0F 05) в собственном двоичном файле. Вместо этого он находит действительный гаджет syscall; ret в памяти ntdll.dll во время выполнения.
• Чистые стеки вызовов: Выделяется пользовательский thunk, который переходит к гаджету ntdll. Для ядра ОС и датчиков безопасности системный вызов выглядит так, как будто он законно происходит из ntdll.dll, что поддерживает чистоту стека вызовов.
• Использование: Просто используйте K8_SYSCALL("ZwOpenProcess", ...) вместо NtOpenProcess.