Ghidra 11.x и деобфускация OLLVM — какие плагины реально работают в 2026

[Planed]

Получил на анализ бинарь скомпилированный с OLLVM — control flow flattening + bogus control flow, x86_64 Linux. В Ghidra картина ужасная, функции по 2000+ инструкций с кучей мусорных блоков. Пробовал плагин D-810 — работает, но не полностью, часть флэттенинга остаётся. Что сейчас используете для деобфускации OLLVM в Ghidra? Есть ли что-то лучше D-810 или надо комбинировать?

[Rhemix]

D-810 это хорошая база, но под конкретный вариант OLLVM его часто надо допиливать. Смотри на версию: если обфускация через Hikari или более новый форк типа goron — паттерны немного другие и D-810 может пропускать. Пробовал miasm2 как внешний движок для symbolic execution + D-810 для предобработки — комбинация работает лучше.

[catbert1]

Для флэттенинга хорошо работает подход через граф доминаторов: ищешь диспетчерский блок (тот что имеет много предшественников), восстанавливаешь реальные переходы через анализ переменной-селектора. В Ghidra это можно сделать через PCode API + скрипт на Python/Java. Есть готовый скрипт на GitHub — ищи «ghidra ollvm deflat», несколько форков с разной степенью зрелости.

[k8sveteran]

Честно скажу: для серьёзного OLLVM я перехожу на Binary Ninja с плагином BNIL-based deobfuscator или angr для symbolic execution. Ghidra хорошо читает структуры, но для динамического анализа потока управления angr+claripy дают более предсказуемый результат. Workflow: Ghidra для первичного анализа и восстановления типов, angr для деобфускации конкретных функций.

[svelte1]

Важный момент который часто упускают: богус контрол флоу проще всего убирается через taint analysis — смотришь какие условные переходы зависят от непрозрачных предикатов (константы типа `(x*x + x) % 2 == 0`), их всегда одна ветка живая. Ghidra PCode emulator умеет отслеживать константные выражения, можно написать скрипт за вечер.

[sainty]

Если бинарь не слишком большой — попробуй Qiling для динамической трассировки с логированием всех переходов, потом визуализируй реальный граф вызовов. На 2000-инструкционной функции это даёт сразу понять реальный поток без разбора всех мусорных веток. Qiling + Unicorn под капотом, скриптуется на Python нормально.

[VueMaster]

@catbert1, согласен что angr для серьёзного OLLVM надёжнее, но есть практический нюанс: angr на x86_64 бинарях с большим количеством вызовов libc начинает сильно тормозить из-за symbolic execution через strcmp, memcpy и прочие функции. Спасает хук на libc — заменяешь их конкретными SimProcedures или вообще выкидываешь из анализа. Без этого на функции 2000 инструкций можешь ждать результата часами. Второй момент: Ghidra 11.1 добавила улучшенный P-Code SSA, это делает написание деобфускационных скриптов на Java заметно удобнее чем в 10.x — стоит посмотреть если давно не пробовал.

[arich]

По опыту с похожим бинарём: комбинация которая у меня дала лучший результат — сначала Qiling для снятия динамической трассы и определения реального CFG, потом этот CFG импортирую обратно в Ghidra через скрипт, и уже работаю с почищенным графом в декомпиляторе. D-810 после этого находит оставшиеся паттерны флэттенинга намного точнее потому что мусорные ветки уже отброшены. Единственное — Qiling требует нормально настроенный rootfs под целевую архитектуру, на x86_64 Linux это несложно, но занимает время на первый раз.

[kingcnut]

@arich, taint analysis для bogus control flow это правда быстрый win. Только добавлю: у некоторых форков OLLVM непрозрачные предикаты генерируются не из арифметики а из глобальных переменных инициализируемых в конструкторах — там простой анализ константных выражений не срабатывает. Видишь в PCode что условие зависит от глобала, а значение глобала не выводится статически. В таком случае помогает один прогон через Qiling с записью значений глобалов на входе в каждую функцию — потом подставляешь их в taint и всё встаёт на место.