DOCUMENTATION · V1.0

Protect your first JAR

Go from download to verified protected output with either the desktop GUI or a repeatable CLI build.

Requirements

OreoObfuscator itself requires Java 21.Your target JAR may use Java 8 through Java 26 bytecode. Always test the protected artifact on every runtime you support.

A runnable or library JAR you are authorized to protect.
Java 21 installed and available as java.
Your OreoObfuscator license key.

Install and activate

Place the downloaded OreoObfuscator JAR in a private tools directory. Keep your original input and mapping file out of public releases.

Terminal

java -version
java -jar OreoObfuscator-1.0.0.jar license --activate YOUR-LICENSE-KEY
java -jar OreoObfuscator-1.0.0.jar license --info

The key is saved for the current operating-system user. In CI, set OREO_LICENSE as a protected secret instead of committing it.

OPTION A · DESKTOP

Use the GUI

Launch it.Double-click the JAR or run java -jar OreoObfuscator-1.0.0.jar without arguments.
Activate.Open the License tab, paste your key and select Activate.
Choose an input.Drop your JAR onto the Protect tab or use Browse. Confirm the suggested -protected.jar output.
Tune protection.Use Settings for standard options, or select a YAML file for precise configuration.
Protect.Select Protect JAR, review the console and test the output in a clean environment.

OPTION B · AUTOMATION

Use the CLI

Terminal

java -jar OreoObfuscator-1.0.0.jar protect my-app.jar my-app-protected.jar --config oreo.yml

For a deterministic build, add --seed 42001. Remove the seed when you want transformation decisions to vary between releases.

Configuration

Start conservatively, verify behavior, then increase protection around the code that carries your business value.

oreo.yml

mode: STANDARD
rename:
  enabled: true
  packages: true
  classes: true
  methods: true
  fields: true
  nameMode: ASCII
strings:
  enabled: true
  encryption: MIXED
controlFlow:
  enabled: true
  level: HEAVY
virtualization:
  enabled: true
  methods:
    - com/example/licensing/Validator.verify
keepRules:
  - com.example.api.PublicApi
mappingOutput: mapping.json

Protection modes

Mode	Use it for	Guidance
LITE	Compatibility-first builds	Good first smoke test
STANDARD	Most applications	Recommended starting point
AGGRESSIVE	Security-sensitive releases	Test all integrations
EXTREME	Selected hardened modules	Expect higher cost

Keep rules matter

Keep anything whose name is part of an external contract: public APIs, dynamically loaded classes, dependency-injection names, serializer type IDs, JNI methods or identifiers stored in custom resources. Oreo protects standard JVM contracts conservatively, but cannot infer every application-specific reflection path.

Command reference

protect INPUT OUTPUT [-c CONFIG] [--seed LONG] [--no-verify]Protect a JAR.analyze JARInspect a JAR before configuration.verify JARCheck bytecode integrity.mapping FILE [--lookup NAME]Query a private mapping file.license --activate KEY | --info | --deactivateManage the local license.

Compatibility checklist

Keep the original JAR and mapping file private.
Run the protected JAR with -Xverify:all.
Exercise startup, reflection, serialization and plugin discovery.
Test each supported JDK and framework runtime.
Virtualize selected sensitive methods, not every hot path.

Troubleshooting

A class or framework component is no longer discovered

Add the externally referenced type to keepRules, or disable package/member renaming while isolating the contract.

The protected application is slower

Reduce virtualization scope and heavy control-flow settings on hot loops. Virtualization should target high-value logic.

My signed JAR is no longer signed

Bytecode changes invalidate existing signatures. Sign the protected JAR as the final release step.