Elyzium OBF
Code obfuscation that makes compiled C/C++ hard to read and reverse engineer.
Release candidate (0.1.0-rc1)
↓ Elyzium OBF (at build time)
Program behaves exactly as before
↓
Hard to read and reverse engineerIllustrative diagram.
The problem it solves
Software ships as compiled binaries. Even without your source code, a skilled analyst can reverse engineer the binary to recover proprietary algorithms, licence checks, and keys or strings embedded inside. Elyzium OBF makes that work take considerably more time and effort, while the program keeps behaving exactly as it did before.
Who it is for
Teams building applications, games or libraries in C/C++ that need to protect proprietary algorithms, licence-check logic or sensitive values embedded in the binary.
Use cases
- Protect licence-check code from being removed or patched.
- Keep keys, configuration strings or sensitive endpoints from showing up when someone opens the binary.
- Protect proprietary algorithms in libraries you distribute to customers.
- Raise the effort required to crack C/C++ software or games.
Key features
Protect only what matters
You mark the functions and data that are genuinely sensitive. Only those are transformed, so overall speed and binary size are largely unaffected. You do not pay a performance cost across the whole project to protect a few critical spots.
Hide sensitive constants and strings
Fixed values such as check codes or keys usually sit in plain view inside a binary. Elyzium OBF does not store them in readable form: they are reconstructed at run time, so a simple search of the file will not find them.
Obscure how the program computes
The way the program processes data is rewritten into an equivalent form that is harder to follow. An analyst has to spend much more effort to understand each step.
Remove easy clues
Function and variable names often reveal what code does. Elyzium OBF minimises these names and reorders internal layout, making it harder to guess what each part is for.
Behaviour is preserved
The goal is protection without breaking functionality. The processed program produces the same results; run your existing test suite to confirm before release.
Reproducible output
The same configuration produces the same output, so your team can track and compare release builds with confidence.
How it is deployed
Choose what to protect
Mark sensitive functions or data directly in your source code.
Enable it in the build
Add Elyzium OBF to your existing compiler command. Protecting sensitive data also requires linking a small companion library.
Build as usual
The compiler pass processes the marked code automatically.
Test before release
Run your test suite to confirm the program behaves correctly.
Technical details
| Stage | Release candidate 0.1.0-rc1 |
|---|---|
| Languages | C and C++ |
| Integration | Plugin for the Clang compiler |
| Fully qualified OS | macOS |
| Other OS | Linux builds regularly in automated CI; Windows was validated in an earlier phase |
| Scope | Only the code and data you mark |
Known limitations
We state these clearly so you know what to expect:
- macOS is currently the only operating system fully qualified for this release.
- The product raises the cost of analysis; it does not promise to stop a highly capable attacker.
- Hidden data takes slightly longer to access each time, so it suits sensitive values that are used rarely, not hot loops.
- Only the Clang compiler is supported; other compilers still build the code, but without protection.
Interested in Elyzium OBF?
Send a request for a consultation and a quote tailored to your project.