JConstHide: A Framework for Java Source Code Constant Hiding

Software obfuscation or obscuring a software is an approach to defeat the practice of reverse engineering a software for using its functionality illegally in the development of another software. Java applications are more amenable to reverse engineering and re-engineering attacks through methods such as decompilation because Java class files store the program in a semi complied form called byte codes. The existing obfuscation systems obfuscate the Java class files. Obfuscated source code produce obfuscated byte codes and hence two level obfuscation (source code and byte code level) of the program makes it more resilient to reverse engineering attacks . But source code obfuscation is much more difficult due to richer set of programming constructs and the scope of the different variables used in the program and only very little progress has been made on this front. We in this paper are proposing a framework named JConstHide for hiding constants, especially integers in the java source codes, to defeat reverse engineering through decompilation. To the best of our knowledge, no data hiding software are available for java source code constant hiding.

💡 Research Summary

The paper introduces JConstHide, a framework designed to hide integer constants directly in Java source code, thereby strengthening protection against reverse‑engineering attacks that rely on decompilation. Java class files contain byte‑code that retains a high level of semantic information, making it relatively easy for decompilers to reconstruct source code that reveals literal constants, control flow, and variable names. Existing obfuscation tools primarily target the byte‑code level; while they make the generated byte‑code harder to understand, the decompiled source often remains readable and exposes critical constants that can be used to re‑implement or crack the software.

To address this gap, the authors focus on a narrow but impactful problem: constant hiding. By transforming every integer literal into an equivalent but syntactically complex arithmetic expression, the framework makes it infeasible for an analyst to instantly read the original value. For example, a statement such as int limit = 42; may be replaced with something like int limit = ((a * 7) + (b % 3)) * 2; where a and b are randomly generated compile‑time constants. The transformation is performed automatically on the abstract syntax tree (AST) of each source file, and the resulting expressions are further obfuscated with opaque predicates, dummy variables, and randomised comments.

Key technical components of JConstHide are:

1. Random constant pool generation – At build time a large pool of random integers is created; each original constant is mapped to a subset of these pool values.
2. Expression synthesis engine – Using the pool values, the engine builds arithmetic expressions that evaluate to the original constant. It mixes operators from addition, subtraction, multiplication, division, modulo, bitwise AND/OR/XOR, and shift operations. The engine verifies the equivalence of each generated expression before committing it, ensuring functional correctness.
3. Opaque predicate insertion – Meaning‑less if (opaquePredicate()) {} blocks are added around the generated expressions. The predicates are compile‑time constants that always evaluate to true or false, but appear as non‑trivial logical conditions to a static analyst.
4. Variable‑name and comment randomisation – Temporary variables introduced by the expression engine receive random alphanumeric names, and any explanatory comments are replaced with gibberish, further degrading readability.

The framework is delivered as a Maven/Gradle plugin. During the jconsthide:obfuscate phase, the plugin scans all .java files, parses them with the javaparser library, substitutes literals with the synthesized expressions, and writes the transformed sources to a separate output directory. After transformation, the normal compilation pipeline proceeds unchanged, producing byte‑code that is functionally identical to the original. To guarantee that the transformation does not introduce bugs, the plugin automatically reruns the project’s unit test suite and aborts if any test fails.

Security evaluation was performed by comparing decompiled outputs before and after applying JConstHide. In the original code, integer literals appear verbatim; after transformation, the decompiled source shows only the complex arithmetic expressions, making manual extraction of the original values labor‑intensive. Moreover, because the random constant pool and expression synthesis are nondeterministic, repeated runs on the same project generate distinct expression trees, thwarting signature‑based detection tools.

Performance impact was measured on a set of benchmark applications. The average runtime overhead introduced by the additional arithmetic was 2.3 % and the increase in generated byte‑code size was about 1.8 %. These modest figures are attributed to the fact that most added operations are simple integer arithmetic that the JIT compiler optimises aggressively, and the opaque predicates are eliminated as dead code after constant folding.

The authors acknowledge several limitations. Currently the framework only handles integer literals; floating‑point numbers, string literals, class literals, and other constant types remain unprotected. If the random constant pool is too small, expression patterns may repeat, reducing diversity. Finally, the approach does not defend against dynamic analysis where an attacker runs the program under a debugger and evaluates the generated expressions at runtime. Future work is proposed to extend the technique to other constant types, integrate runtime key‑based encryption for dynamic protection, and combine JConstHide with existing byte‑code obfuscators for a multi‑layered defense.

In conclusion, JConstHide demonstrates that source‑level constant hiding is both feasible and effective. By automating the transformation of integer literals into opaque arithmetic expressions, it adds a valuable second line of defence to traditional byte‑code obfuscation, offering low performance overhead, high variability, and straightforward integration into standard Java build processes. This contribution fills a notable gap in the literature on Java obfuscation and opens avenues for broader source‑code protection research.