The slides from our @recon talk, "Breaking Mixed Boolean-Arithmetic Obfuscation in Real-World Applications" (CC @nicolodev are now online!
Slides: https://synthesis.to/presentations/recon25_mba_obfuscation.pdf
| web | https://nicolo.dev |
| github | https://github.com/seekbytes |
The slides from our @recon talk, "Breaking Mixed Boolean-Arithmetic Obfuscation in Real-World Applications" (CC @nicolodev are now online!
Slides: https://synthesis.to/presentations/recon25_mba_obfuscation.pdf
New #BinaryNinja plugin: Obfuscation Analysis
Simplifies arithmetic obfuscation (MBA) directly in the decompiler (see demo below). Also identifies functions with corrupted disassembly.
Co-authored by @nicolodev ; available in the plugin manager.
Check it out: https://github.com/mrphrazer/obfuscation_analysis
At @recon , @nicolodev and I discuss the current state of MBA (de)obfuscation and their applications. We’ll also introduce a new #BinaryNinja plugin for simplifying MBAs in the decompiler.
Details: https://cfp.recon.cx/recon-2025/featured/
I'll also give a training: https://recon.cx/2025/trainingSoftwareDeobfuscationTechniques.html
Disassembly algorithms are often a trade-off. My new blog post analyzes linear sweep and recursive traversal, exploring their strengths and weaknesses in a self-built disassemblers.
https://nicolo.dev/en/blog/disassembling-binary-linear-recursive/
Building your own set of analysis tools is a great exercise for those who already have some basics and allows you to later move on to implement more targeted analyses in reverse engineering. Even just seeing how the different algorithms can be implemented provides a mental framework that may help when reverse engineering more difficult-to-analyse executable files, i.e. obfuscated ones. Excluding the file format, an executable file contains two main types of information: the instructions (what the CPU executes) and the data (what information the CPU uses to execute instructions). In order to reconstruct the high-level information, each analysis pipeline implements several steps: we can find parsing of the executable file, disassembly of instructions, data flow analysis, reconstruction of the flow control graph, type inference. Obtaining the several types of information is very complex due to the nature of static analysis where many undecidable problems are faced: being able to derive correct information is a difficult matter and each step in the analysis pipeline affects the final result.
Control Flow Graph is a critical element for any binary analysis framework, but its role has been underestimated sometimes (I'm looking at you, Ghidra!).
https://nicolo.dev/en/blog/role-control-flow-graph-static-analysis/
The flow control graph is an important building block in static program analysis for applying a variety of analyses that consider the flow of a program. The “flow”, described informally, represents the evolution of the program during execution time, that is, at which the CPU jumps in order to continue program execution. The graph (also called CFG for brevity) allows the first high-level elements of software to be derived in a general way from a low- or medium-level representation (we cite as an example assembly code or intermediate code). High-level elements include high-level loops (while or for loops) and execution branches (switch, if, else) that can be critical in identifying how execution evolves over time.