Browse documentation
Start
Overview Getting started How it works
Protection passes
Overview Nativization Class name obfuscation Method & field renaming String & constant encryption Control-flow flattening Decompiler-resistant wrapping Anti-tamper checksums Anti-debug detection Resource & asset encryption Native library bundling Loader & runtime hardening Build-time watermarking
Exclusions & configuration
Overview Reflection by name ServiceLoader JPMS module descriptors Spring proxying Proxy-library internals Config-driven keep rules Trial / evaluation mode Configuration reference
Compatibility
Overview JDK & class files Platforms Frameworks & reflection Build integration & deployment
Trust
Security model Known limitations
Account
Licensing
Documentation / Security model

Security model

RJNI raises the cost of extracting logic from a shipped Java application. It does not claim to defeat a determined, well-resourced reverse-engineering effort against a native binary. No protection tool in this category can make that claim, and RJNI does not.

Adversary tiers

TierCapabilityPosture
CasualRuns an off-the-shelf decompiler against the shipped JAR, no further effort.The primary tier RJNI is built to raise the cost against, nativization removes the method body a decompiler would otherwise reconstruct.
Motivated amateurReads native-library disassembly, uses javap/bytecode viewers, spends time on strings and symbols. Partially raised: string/resource encryption and decompiler-resistant wrapping increase the cost here, without fully defeating this tier.
Determined reverserHas the native binary, a disassembler, time, and the skill to reconstruct logic from native code by hand. Out of scope. RJNI raises the cost of extraction; it does not claim to defeat a determined effort against the compiled native artefact.

What RJNI defends against

An attacker targets a Java application for one of two reasons: extracting proprietary business logic (an algorithm, pricing logic, a licensing check, domain-specific IP, the core value of nativizing and obfuscating a method), and bypassing an embedded licence or DRM check. The second is why loader and runtime hardening exists, the small bootstrap that loads the native library is the lowest-effort attack surface for someone trying to patch out a licence gate without breaking the native protection at all, so it goes through the same protection pipeline as your own code instead of being left unobfuscated.

What RJNI does not claim

  • Nativization removes the Java method body available to ordinary bytecode decompilers, it does not make the underlying logic unrecoverable.
  • RegisterNatives is a name-based JNI API, so a nativized method's name and descriptor remain visible as plaintext strings inside the compiled native library, structurally unavoidable without abandoning JNI as the relinking mechanism.
  • Every obfuscation and encryption pass here raises the cost of a casual or moderately motivated attack. None of them is presented as unbreakable.
  • Native binaries remain analysable by a sufficiently capable attacker with a disassembler and enough time.
  • Anti-tamper checksums detect a class file edited in isolation after protection; they do not resist an attacker who edits the checksum resource and the class together, or who modifies a running JVM directly.
  • Anti-debug detection is scoped to JDWP, to avoid false positives against legitimate production monitoring agents, it is not a general instrumentation or dynamic-analysis countermeasure.
  • Not a defence against a fully instrumented dynamic-analysis attack, attaching a debugger or instrumentation framework to the running native process, hooking JNI calls at runtime, beyond the specific JDWP-attach case anti-debug detection covers.
  • Not a defence against side-channel or hardware-level attacks. Out of scope.
PreviousBuild integration & deployment