Java Bytecode Obfuscator Using Exception Handling Mechanism

• Main Authors: Pao-Chin Tsai, 蔡寶進
• Other Authors: Jia-Shung Wang
• Format: Others
• Language: en_US
• Published: 2000
• Online Access: http://ndltd.ncl.edu.tw/handle/62949161489806889919

碩士 === 國立清華大學 === 資訊工程學系 === 88 === Recently, mobile computing and enterprise computing are more and more popular over computer networks. In mobile computing, it has become common to distribute mobile programs to the clients at the time when they needed. Because the client platforms are of many types, mobile programs have to be platform-independent. To ensure that, these mobile programs should be in high-level forms and be quite similar to the original source codes. Thus, the common platform-independent codes are easy to be decompiled, and hence they may trap into the risk of malicious reverse engineering attacks. Nowadays, Java bytecode is the most widely-used platform-independent code and many Java programs have been developed and distributed. To get these programs as the form of source code, some Java decompilers, such as SourceAgain and JAD, are developed. To protect those Java bytecodes from being decompiled, the most feasible way is to obfuscate it. Normally, obfuscated code has logically the same behavior in execution as the original one, but much more difficult to be decompiled. Most of the obfuscators today concentrate on attaching many redundant links to complicate program control flow; thus, confuse the decompilers. In this thesis, we propose an effective method, which is based on the Java exception handling mechanism, to extend the obfuscation capability. We hide links in exception tables, and replace original links with redundant and fake links. We replace some branch-like instructions with the so-called exception-generating instructions whose exception handlers are the original blocks. The simplest way is to hide the links in the exception tables directly. But we can strengthen this with several indirect exception links, which make it more robust from being decompiled. Another effective way is to add some fake branches in the control flow to confuse the decompiler. The obfuscated code with faking links can be decompilable but the program logic is no longer meaningful, or even cannot be decompiled because of violating the Java language. In our experiments, the codes obfuscated using our approach are successfully protected from all of the decompilers and unobfuscators that we have found.