Protection principles
A clear standard for valuable software: raise the cost of useful recovery, preserve the quality of the product.
Protect the value, define the objective#
A protection policy starts with what would hurt to lose: a proprietary algorithm, a business rule, a licensing decision or the advantage of an unreleased feature. These assets do not all need the same treatment. Identify the sensitive methods and the period during which their confidentiality matters before selecting a profile.
The objective is to increase the effort required for useful reconstruction while limiting your exposure. Ideally, the cost of an attack exceeds its expected return. That is a threat-modeling objective, not a guaranteed economic outcome: an attacker’s resources, motivation and access vary.
Assume the artifact can be inspected#
An attacker may possess the protected JAR, compare releases, inspect bytecode, attach a debugger or observe a process they control. Virtualization changes the execution representation; native compilation moves selected logic outside ordinary JVM method bodies. Neither removes the attacker’s ability to investigate runtime behavior.
Make analysis require more than one technique#
Different layers address different shortcuts. Renaming reduces semantic clues. Constant protection changes how values are represented and recovered. Control-flow transformations disrupt straightforward reconstruction. Selective virtualization or native compilation can change the representation of important methods more substantially. Their value comes from an appropriate combination, not from applying every option everywhere.
Select a stage to inspect its role. The diagram describes responsibilities, not internal implementation.
A protection policy starts with what would hurt to lose: a proprietary algorithm, a business rule, a licensing decision or the advantage of an unreleased feature. These assets do not all need the same treatment. Identify the sensitive methods and the period during which their confidentiality matters before selecting a profile.
An attacker may possess the protected JAR, compare releases, inspect bytecode, attach a debugger or observe a process they control. Virtualization changes the execution representation; native compilation moves selected logic outside ordinary JVM method bodies. Neither removes the attacker’s ability to investigate runtime behavior.
Different layers address different shortcuts. Renaming reduces semantic clues. Constant protection changes how values are represented and recovered. Control-flow transformations disrupt straightforward reconstruction. Selective virtualization or native compilation can change the representation of important methods more substantially. Their value comes from an appropriate combination, not from applying every option everywhere.
A decompiler screenshot is one observation from one tool. It does not establish resistance against every analyst or prove runtime correctness. Evaluate the exact protected build: compare behavior against the original, examine representative sensitive methods, measure startup and steady-state cost, and retain the profile and build identifier. Repeat this review when dependencies, JVM targets or protection policies change.
Evaluate the released artifact#
A decompiler screenshot is one observation from one tool. It does not establish resistance against every analyst or prove runtime correctness. Evaluate the exact protected build: compare behavior against the original, examine representative sensitive methods, measure startup and steady-state cost, and retain the profile and build identifier. Repeat this review when dependencies, JVM targets or protection policies change.