Obfuscation-as-a-Service: Making Reverse Engineers Work for It

Modern reverse-engineering tools have made binary analysis more accessible than ever. With Ghidra and a debugger, an analyst can recover program structure, trace execution, and identify sensitive logic in an afternoon, often for free. For commercial software, licensing systems, anti-cheat solutions, and security-sensitive applications, that is a real problem.

This talk is built on OaaS (Obfuscation-as-a-Service), an open-source project under the pointblank-club organization that we built to make reverse engineering measurably more expensive. We treat obfuscation as an economic problem, not a cryptographic one. The goal is not to make code impossible to read, but to make analysis cost more than it is worth.

We walk through both sides of the attacker's toolkit. On the static side, we demonstrate symbol stripping, string encryption, constant obfuscation, import hiding, and control-flow flattening via LLVM and OLLVM, showing before-and-after diffs of what the decompiler sees. On the dynamic side, we go deep on five anti-debugging techniques: self-debugging via ptrace/TracerPid, timing checks using rdtsc cycle deltas, software breakpoint detection via .text checksums, hardware breakpoint detection through debug registers Dr0 to Dr3, and exception-based traps using INT3/SEH/VEH. For each one, we explain the mechanism, show the implementation, and discuss why it is hard to bypass cleanly.

Everything runs on open-source infrastructure including LLVM, MLIR, OLLVM, and Ghidra. We close with an honest look at the trade-offs around binary size, performance overhead, and the reliability risks of aggressive passes. The audience is invited to try breaking the techniques themselves.

• A clear mental model of static vs. dynamic analysis from the defender's perspective

• Five anti-debugging techniques explained at implementation depth and how to bypass them

• Concrete, FOSS-based obfuscation techniques you can apply to your own binaries

• An honest view of the trade-offs: binary size, performance overhead, and reliability risks