X hits on this document





65 / 120

constructs result in compatible bytecode with optionally-utilized metadata provides the

benefit of allowing legacy Java bytecode to run on newer JVMs, however if a decompiler

doesn't know to look for the metadata, some information is lost; for example, the fact that

a program used generics would not be recovered and all collections would be of type

Object (with cast statements of course).

Recall that in Section 4.1 the Boomerang decompiler failed to decompile the

machine code for a simple C/C++ “Hello World” program, however in Section 5.1, the

Jad decompiler produced correct Java source code for a slightly larger program. Given

these results, one does need to be concerned with with protecting Java bytecode from

decompilation if there is significant intellectual property in the program. The techniques

used to protect machine code in the anti-reversing exercise solution, detailed in section

7.6, can also be applied to Java source code to produce bytecode that is obfuscated.

Since Java bytecode is standardized and well-documented there are many free Java

obfuscation tools available on the Internet such as SandMark [27], ProGuard [29], and

RetroGuard [28] which perform transformations directly on the Java bytecode instead of

on the Java source code itself. Obfuscating bytecode is inherently easier than obfuscating

source code because bytecode has a significantly more strict and organized representation

than source code—making it much more easy to parse. For example, instead of parsing

through Java source code looking for string constants to encrypt (protect), one can easily

look in the constant pool section of the bytecode. The constant pool section of a Java

Class File, unlike the .rdata section of Wintel machine code, contains a well-documented


Document info
Document views532
Page views533
Page last viewedSun Jan 22 23:24:58 UTC 2017