MetaCartSign in to MyCiteSeer

Include Citations | Advanced Search | Help

Include Citations | Advanced Search | Help

  Java control flow obfuscation (1998) [9 citations — 0 self]

Download:
pdf | ps
by Douglas Low
MS Thesis, Univ. Auckland
http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/thesis.ps.gz
Add To MetaCart

Abstract:

The language Java was designed to be compiled into a platform independent bytecode format. Much of the information contained in the source code remains in the bytecode, which means that decompilation is easier than with traditional native codes. As a result, software developers are taking seriously the threat of competitors using reverse-engineering to extract proprietary algorithms from compiled Java programs. We examine several technical protection techniques that could be used to hinder the reverse-engineering of software. We claim that code obfuscation is the most suitable technical protection technique that can be applied to a portable language like Java. The technique of code obfuscation involves applying obfuscating transformations to a program. These transformations make the program more difficult for a reverse-engineer to understand but do not affect the functionality of the program. We focus on a particular category of obfuscating transformations--- control flow obfuscation. Control flow obfuscations disguise the algorithms used by a program by introducing new fake control flows, creating features at the object code level which have no source code equivalent or altering the way in which statements are grouped. There are many practical aspects to be considered when applying obfuscating transformations to Java programs. The fact that Java programs are portable and are verified before execution makes obfuscating transformations more difficult to apply. The verification stage ensures that programs do not perform illegal operations, such as corrupting a user's system. Obfuscating transformations can be applied automatically to a program by a tool called an obfuscator. In this thesis, we present one possible method of implementing such an obfuscator. We first discuss the design decisions made to address implementation problems. Then, we use the obfuscator on examples of Java code and examine how effective the obfuscating transformations are in impeding reverse-engineering.

Citations

1976 A method for obtaining digital signatures and public key cryptosystems – Rivest, Shamir, et al. - 1978
549 High-Performance Compilers for Parallel Computing – Wolfe
491 A Complexity Measure – McCabe - 1976
415 Points-to analysis in almost linear time – Steensgaard - 1996
79 Toba: Java for Applications: A Way Ahead of Time (WAT) Compiler – Proebsting, Townsend, et al. - 1997
59 The undecidability of aliasing – Ramalingam - 1994
25 Programming Languages for the Java Virtual Machine," Web Site accessed on 1 October 2001 http://grunge.cs.tuberlin.de/~tolk/vmlanguages.html [29] "GCJ: The GNU Compiler for the Java Programming Language," Web Site accessed on 11 August 2001 – Tolksdorf, Universität, et al. - 2001
21 Krakatoa: Decompilation in java (does bytecode reveal source – Proebsting, Watterson - 1997
20 Control flow, data flow, and program complexity – Oviedo - 1980
14 Measurement of data structure complexity – Munson, Khoshgoftaar - 1993
12 Reverse-engineering someone else's software: Is it legal – Samuelson - 1990
8 Mocha - Java decompiler – Vliet - 1996
5 Cryptographically protected objects. http://lsewww.epfl.ch/~wilhelm/CryPO. html – Wilhelm - 1997
1 Control ow, data ow, and program complexity – Oviedo - 1980
1 Complexity cores and hard problem instances – Schoning - 1990
1 Software authorization systems – Suhler, Bagherzadeh, et al. - 1986
1 Microsystems. JavaBeans: The Only Component Architecture for Java – Sun - 1998
1 Crema | The Java obfuscator – Vliet - 1996