X hits on this document





66 / 120

table data structure that makes available the name and length of each constant; on the

other hand, the .rdata section of Wintel machine code simply contains all the constants in

the program in a contiguous, unstructured bytestream. The variable names, method

names, and string literals, in the constant pool section of Java bytecode provide a wealth

of information to a reverse engineer regarding the structure and operation of the bytecode

and hence should be obfuscated to protect the software. Therefore, we now look at

applying the technique Eliminating Symbolic Information in the context of Java bytecode.

8.1 Eliminating Symbolic Information in Java Bytecode

Variable, class, and method names, are all left intact when compiling Java source

code to Java bytecode. This is a stark difference from machine code where variable and

method names are not preserved. Sun Microsystem's Java compiler javac provides an

option to leave out debugging information in Java bytecode: specifying javac -g:none will

exclude information on line numbers, the source file name, and local variables. This

option offers little to no help in fending off a reverse engineer since none of the variable

names, methods names, or string literals are obfuscated. According to the documentation

for Zelix Klassmaster [26], a Java bytecode obfuscation tool, a high-level of protection

can be achieved for Java bytecode by applying three transformations: (1) Name

Obfuscation, (2) String Encryption, and (3) Flow Obfuscation. Unfortunately, at the time

of this writing, no free-of-charge software tool was found on the Internet that can perform

all three of these transformations to Java bytecode. A couple of tools, namely ProGuard

[29] and RetroGuard [28] are capable of applying transformation (1), and SandMark [27],


Document info
Document views545
Page views546
Page last viewedTue Jan 24 03:20:24 UTC 2017