We don't ask you to trust us. We let you try to break it.
Marketing claims about obfuscation are cheap. The honest answer is that protection has a cost-to-bypass, and the only way to know that cost is to put real money behind people attempting it. That is what this page is about. Below: why the engine holds up, the research it builds on, and a paid bounty program for anyone who can prove a piece of it wrong.
Four properties that change the math.
Layered, not a single line.
A successful attack has to defeat every layer in order: identifier rename, string layer, control-flow flattening, anti-tamper interlocks, the VM, and on enterprise builds the native stub. Any layer holding raises the cost of all of them.
Polymorphic per build.
The encoding seed rotates every build. v1.0, v1.1, and v1.2 are the same plugin to the user and structurally different binaries to the reverser. A crack of v1.0 does not patch v1.1. The cost of cracking is paid every release cycle.
Every JAR identifies its source.
Each protected build embeds a forensic watermark unique to the customer who received it. Leaks are attributable on contact. The watermark survives most re-packing tools and adds no measurable runtime cost.
Patch one, break five.
Anti-patch interlocks bind classes together so that removing or modifying a single check breaks decryptors and dispatchers in unrelated classes. The reverser cannot surgically remove a single license check. They have to repair the whole mesh, and the mesh is shaped differently every build.
Built on real research, not vibes.
We will not pretend the engine invents the field. The transforms below trace directly to academic work and industry practice. Reading the references will tell you exactly where each technique came from and what its known limits are.
A Taxonomy of Obfuscating Transformations
Collberg, Thomborson, Low. The foundational paper on opaque predicates, control-flow flattening, and the cost-of-attack framing this whole industry rests on.
computer.org → virtualizationManufacturing cheap, resilient, and stealthy opaque constructs
The compiler-side construction underlying selective virtualization. The technique we use to lift methods into the JOBF VM is a direct descendant.
acm.org → attacksSyntia: Synthesizing the Semantics of Obfuscated Code
Blazytko et al, USENIX Security 2017. The state of the art in defeating virtualization. Required reading for understanding what holds and what does not.
usenix.org → nativeStitching the Gadgets: On the Ineffectiveness of Coarse-Grained Control-Flow Integrity
Davi et al. The literature on what binary-level integrity gives you (and crucially, does not). Native-stub design is informed by these limits.
acm.org → jvm bytecodeBytecode-Level Tampering & Detection
Recent NDSS work on bytecode integrity. The integrity-mesh module is informed by this body of literature.
ndss-symposium.org → surveyThe Current State of Obfuscation Practice
USENIX WOOT 2019. A survey of what shipping obfuscators actually do, including the well-known weaknesses we explicitly designed around.
usenix.org →Get paid to break our engine.
Anyone can submit a working bypass against a published challenge JAR. If it passes our verification rig, you get paid and your write-up goes into the hall of fame. Every accepted submission gets folded back into the engine. That is how we keep getting harder to break.
License bypass
$xxx + write-up credit
You make a sample plugin run without the original license check passing. Patches, runtime hooks, whatever. The bypass has to survive a fresh polymorphic build.
String / VM unwrap
$x,xxx + write-up credit
You produce readable Java for a method we marked VM-protected. Working tooling that automates the unwrap on a category of similar methods rather than a single one.
Native stub lift-out
$x,xxx+ + write-up credit
You recover a working clear-Java equivalent of a native-stub method, including the polymorphic per-build encoding. This is the highest tier and the rarest.
Novel transformer attack
case-by-case
You write a generic transformer or analysis tool that breaks a category of our protections. The payout scales with how much engine work it forces.
How submission works
- Join the Discord. Submission, verification, and payout coordination happens there. The same channel hosts past write-ups so you can see what got accepted before.
- Pull the latest challenge JAR. A pinned message holds the current bounty pool, the targets, and the verification harness. Each challenge has a fresh polymorphic seed.
- Submit the bypass with a write-up. The write-up has to be reproducible. We rerun your steps against an independently-built artifact to confirm the bypass is general, not a one-shot.
- Get paid. Verified submissions are paid in your choice of bank transfer or USDC, typically within seven days of acceptance. The write-up is published with attribution.
The whole program lives in one Discord.
Submission, samples, payouts, write-up archive, and the side conversations that make any of this fun.
People who have made the engine better.
Every accepted submission lands here. The shape of the engine you use today is the engine that survived these attempts. Names are the handles the researcher chose, not necessarily their real ones.
The board is empty. For now.
The bounty program just opened. The first accepted submission gets the top slot on this page, the write-up credit, and the satisfaction of being the reason a future version of the engine is harder to break. Come find a hole.
Be the firstPick a side. Either side helps.
If you build paid Java, JavaObf protects it. If you reverse Java for a living, the bounty program pays cash for what you already do for fun. Both improve the engine.