Harder to read, still standard code
- Renames symbols, keeps standard instructions
- Decompilers can often recover the logic
Blackout converts your most sensitive code into custom virtual machine bytecode, so decompilers and disassemblers have nothing readable to recover. Protect your Java and Native applications from cracking and tampering.
Obfuscated code is still standard code. Virtualized code isn’t.
Virtualize the methods that matter in your JAR.
Protect chosen code in your native binaries.
Send your JAR or executable.
Code is lifted to an IR.
IR becomes VM bytecode.
Encrypt, harden, deliver.
Sensitive logic runs on a custom virtual machine.
Keep endpoints and keys out of static analysis.
Makes patching and repackaging much harder.
Protect only what matters and keep performance.
Obfuscation rewrites your code but keeps it in standard instructions, so decompilers can often recover it. Virtualization replaces the original instructions with custom virtual machine bytecode, so there is nothing readable left to recover.
Java applications from Java 4 to Java 27, and native applications for Windows, macOS, and Linux on x64. Support for arm64 and riscv64 is in progress.
Blackout is highly optimized, so most applications run without noticeable impact. Particularly complex methods may see some slowdown, which is why you choose which methods or code regions to protect: virtualize the sensitive logic and leave performance-critical paths untouched.
No. Lapse.re works on your compiled JAR or executable. Uploaded files are stored only while they are processed and deleted when processing completes.
Nothing is impossible, but reversing virtualized code is extremely complex and time-consuming, even with automated tools and AI. For best results, combine it with server-side enforcement of critical secrets.
Contact us with your application, its platform, and what you need to protect. We confirm scope, deliverables, and conditions before any order is accepted.