Simplifying Mixed-Boolean-Arithmetic obfuscation with obfuscation_analysis

obfuscation_analysis is a Binary Ninja plugin that untangles Mixed-Boolean-Arithmetic obfuscation and broken disassembly during authorized reverse-engineering of protected binaries.

Tool	mrphrazer/obfuscation_analysis — Binary Ninja plugin to analyze and simplify obfuscated code, built on msynth
Category	reverse-engineering / deobfuscation plugin (Python, GPL-2.0)
Primary Use	Collapsing MBA expressions in the HLIL decompiler view, locating corrupted functions, and inlining scattered logic during authorized reverse engineering
Safe Use	Intended for authorized malware analysis, CTF work, security research on software you own or are licensed to assess, and defensive triage of protected binaries in lab environments
Telemetry Note	Purely local analysis tool; it modifies nothing outside the analyst's Binary Ninja session, leaving simplified comments and cleaned function lists in the local database only

Reversing a hardened binary usually means spending hours fighting the protector instead of the actual logic. obfuscation_analysis, written by Tim Blazytko and Nicolò Altamura, is a Binary Ninja plugin (v1.3, Python, GPL-2.0, around 255 stars) that chips away at exactly that problem. Rather than trying to be a universal deobfuscator, it bundles a small set of focused helpers — MBA simplification, corrupted-function detection and removal, and recursive function inlining — each targeting a specific roadblock you hit when a disassembler meets deliberately hostile code. The design philosophy shows in the README: do a few things well, run them as background tasks, and log failures cleanly.

The headline feature is Mixed-Boolean-Arithmetic (MBA) simplification, built on the author's own msynth synthesis engine. MBA obfuscation buries trivial computations — a comparison, a constant, an XOR — inside long chains of interleaved arithmetic and Boolean operators that are algebraically identical but computationally opaque. The workflow is deliberately manual and analyst-driven: you highlight the HLIL expression you care about in Binary Ninja's decompiler view, then invoke Plugins -> Obfuscation Analysis -> MBA Simplification -> Slice & Simplify. Nothing is done blindly across the whole binary.

Internally, the pipeline is a nice piece of engineering worth understanding if you plan to trust its output. The plugin first performs an SSA backward slice from the selected instruction, but restricts that slice to the current basic block — a deliberate scope limitation. The slice is then translated from Binary Ninja's HLIL into Miasm IR, and Miasm IR is what gets fed to msynth, which uses a pre-computed simplification oracle to synthesize an equivalent, dramatically shorter expression. The simplified result is not destructively rewritten into the code; instead it is inserted as a comment on the same line, preserving the original for verification.

The oracle itself is pluggable. By default the plugin ships with msynth's default pre-computed simplification lookup tables, pre-configured and ready to go. If you want better coverage on unusual instruction mixes, you can point the obfuscation_analysis.mba_oracle_path setting at a larger or custom oracle file, either by editing the setting directly or browsing to the file in Binary Ninja's settings window. The README links the underlying REcon talk, "Breaking Mixed Boolean-Arithmetic Obfuscation in Real-World Applications," along with slides and an examples directory — useful context for why the slice-and-synthesize approach beats naive pattern matching.

The second helper, Corrupted Functions, addresses a different pathology: functions whose disassembly contains undefined artifacts such as empty basic blocks, invalid or overlapping instructions, or misaligned jumps. The helper walks the entire BinaryView, flags functions exhibiting these symptoms, and lists them for inspection. An optional remove action then erases every flagged function and forces a fresh re-analysis, which cleans up the function list when the original parse went wrong. The README calls out concrete cases where this matters: data blobs the disassembler mistakenly promoted to code, obfuscation stubs that break straight-line disassembly, overlapping-instruction tricks, and newer architectures where uncommon instructions confuse the lifter.

The third helper, Function Inlining, recursively inlines every callee of the selected function directly in the decompiler view, producing a single self-contained IL. With function boundaries removed, Binary Ninja can propagate data across what used to be separate units, enabling deeper constant folding, dead-code elimination, and clearer logic overall. This is particularly effective against protectors that scatter a single algorithm across chains of tiny wrappers, thunks, and accessor helpers — a classic structural obfuscation technique. The README is refreshingly honest that this can backfire: on very large functions or deep call trees the resulting HLIL can become huge and slow to render, and some decompiler optimizations actually degrade once everything is merged. To control this, Settings -> Obfuscation Analysis -> Max Function Inlining Depth bounds the recursion, defaulting to a depth of 1.

Where does this fit in an authorized workflow? The plugin explicitly complements the author's earlier obfuscation_detection project: detection flags suspicious functions statistically, and obfuscation_analysis then helps you clean and understand them. That two-stage pipeline — detect, then simplify — mirrors how a professional approaches protected malware or DRM-wrapped samples in a lab: triage broadly, then invest analyst effort only where the tooling has already pointed you. Since every helper also runs headless, the same operations can be scripted into batch triage of sample corpora, though the README does not elaborate on the scripting API itself.

The limitations section deserves attention because it defines when to trust the output. The backward slice is confined to one basic block, so variable definitions in predecessor blocks — often control-flow dependent — are ignored, leaving some MBA terms only partially resolved. The HLIL-to-Miasm translation has gaps: control-flow nodes and floating-point operations are not translated, and unsound constructs cause the expression to be skipped with a logged error. There is also a Binary Ninja 5.0 stable bug involving missing HLIL type-casts that can break slicing, fixed only in 5.1.7477-de and newer. Finally, all inherited msynth constraints apply on top. In practice this means the simplified comment is a strong hint, not a proof, and should be sanity-checked against the original expression.

Error handling is a small but telling detail. Failures surface as a concise message in Binary Ninja's Log pane, while switching the log view to Debug exposes the full traceback — the difference between an analyst-friendly notice and the detail you need to file a useful issue. Installation is standard for the ecosystem: the plugin can be installed directly via Binary Ninja's plugin manager, or manually by cloning the repo into the plugin folder and running pip install -r requirements.txt, optionally inside a virtual environment whose site-packages path must then be wired into the Binary Ninja settings.

For defenders and malware analysts, the value proposition is straightforward: MBA-based protectors and commercial obfuscators are everywhere in modern malware families, and manual algebraic untangling does not scale. By combining SSA slicing, Miasm-based IR translation, and synthesis-backed simplification inside the tool the analyst already lives in, obfuscation_analysis turns a day of symbol-pushing into a highlight-and-click operation — with documented, honest limits on what it can and cannot resolve. It is a defensive research instrument through and through: it touches nothing outside your local Binary Ninja database, and its output is a cleaner path to understanding, not to exploitation.

Official project repository for mrphrazer/obfuscation_analysis.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.