Obfuscating Java Programs by Translating Selected Portions of Bytecode to Native Libraries

Code obfuscation is a popular approach to turn program comprehension and analysis harder, with the aim of mitigating threats related to malicious reverse engineering and code tampering. However, programming languages that compile to high level bytecode (e.g., Java) can be obfuscated only to a limited extent. In fact, high level bytecode still contains high level relevant information that an attacker might exploit. In order to enable more resilient obfuscations, part of these programs might be implemented with programming languages (e.g., C) that compile to low level machine-dependent code. In fact, machine code contains and leaks less high level information and it enables more resilient obfuscations. In this paper, we present an approach to automatically translate critical sections of high level Java bytecode to C code, so that more effective obfuscations can be resorted to. Moreover, a developer can still work with a single programming language, i.e., Java.

💡 Research Summary

**
The paper addresses the inherent weakness of Java‑style high‑level bytecode for code protection. Even after compilation, Java bytecode retains abundant metadata—class, method and field names, type signatures, and clear‑text constant pools—that can be exploited by reverse engineers. To mitigate this, the authors propose an automated pipeline that selectively translates annotated Java methods into native C code, compiles the C into a shared library, and links it back to the original Java program via the Java Native Interface (JNI).

Developers mark sensitive methods with a custom @Obfuscate annotation. After the Java source is compiled to .class files, the transformation tool scans the bytecode, identifies the annotated methods, and rewrites each method’s body: it removes the original bytecode, adds the native modifier, and inserts a call to System.loadLibrary in the class’s static initializer. The removed bytecode is then processed opcode by opcode. Because the Java Virtual Machine (JVM) is stack‑based, the translator emulates the operand stack and the local variable array in C using statically sized arrays of 64‑bit jvalue elements. Each JVM opcode is mapped to a sequence of C statements that push, pop, or manipulate these arrays. Arithmetic opcodes (IADD, ISUB, etc.) become direct C arithmetic expressions; logical and arithmetic shift instructions are handled with explicit casts to preserve Java’s signed‑shift semantics. Control‑flow opcodes (goto, if, tableswitch, lookupswitch) are translated into C labels, goto statements, and switch constructs, while dead labels after unconditional returns are omitted to keep the generated C code syntactically valid.

Method invocations and field accesses pose a special challenge because the native side cannot directly reference Java symbols. The translator therefore generates JNI reflection calls: INVOKEVIRTUAL, INVOKESTATIC, etc., become (*env)->CallMethodByName, and GETFIELD/PUTFIELD become (*env)->GetFieldByName / (*env)->SetFieldByName. This preserves the original semantics while allowing the native code to interact with Java objects, throw or check exceptions, and access the runtime environment.

The resulting C source files are compiled with a standard C compiler for the target platform, producing a portable shared library (e.g., libObf.so on Linux, Obf.dll on Windows). At runtime, the Java class loads this library, and calls to the formerly annotated methods are dispatched to the native implementation. Because the transformation occurs after Java compilation, all usual Java compile‑time checks (type safety, access control, etc.) remain intact, and developers continue to write and maintain only Java code.

The authors evaluate their approach on several benchmark programs. They measure the size of the generated native library, the runtime overhead introduced by stack emulation and JNI calls (typically a 5–15 % increase), and, most importantly, the resistance to reverse engineering. By applying existing C‑level obfuscation tools (e.g., OLLVM, Tigress) to the generated native code, they demonstrate a substantial increase in analysis difficulty: the high‑level identifiers and structural information present in the original bytecode are no longer available, and the native binary is harder to decompile. The method also scales to other JVM languages such as Kotlin, Scala, and Clojure, because the transformation works on the bytecode level rather than source language specifics.

In contrast to full‑program Java‑to‑C translators like Caffeine, this selective approach preserves compatibility with platform‑specific frameworks (e.g., Android Activity subclasses) that require Java‑only signatures, while still enabling strong obfuscation on critical code paths. The paper concludes that selective native translation offers a practical trade‑off: modest performance cost for a significant gain in code protection, and it opens the door for integrating mature C‑oriented protection techniques into the Java ecosystem without burdening developers with multi‑language maintenance.