Reversing and Patching Java Bytecode

CS266 Software Reverse Engineering (SRE)
Reversing and Patching Java Bytecode
Teodoro (Ted) Cipresso, teodoro.cipresso@sjsu.edu
Department of Computer Science
San José State University
Spring 2015
The information in this presentation is taken from the thesis “Software reverse engineering education”
available at http://scholarworks.sjsu.edu/etd_theses/3734/ where all citations can be found.

 Good-quality Java source can often be generated from Java bytecode with little
difficulty due to certain characteristics of bytecode:
 Platform-independent (consistent) instruction set and layout/format.
 Very rich, well-structured metadata about Classes, Methods, and Variables:
 names and datatypes (e.g., String personName, Map personRecord).
 Method signatures (includes Constructors).
 Generating HLL source (e.g., C/C++) from machine code is challenging due to
high variation in the output of compilers on different platforms and unavoidable
loss of information that occurs when compiling a HLL down to machine code.
 Note: Symbolic information may be included in machine code when
specifying a compiler’s “debug” option (e.g., -g, -debug, TEST).
2

(cont’d)
 The following diagram illustrates the difference in how Java bytecode and
machine are processed during execution:
3

(cont’d)
 The following formal definitions of machine code and Java bytecode apply:
 Machine code: “Machine code or machine language is a system of
instructions and data executed directly by a computer's central processing
unit” [14]. Machine code contains the platform-specific machine instructions
to execute on the target processor.
 Java bytecode: “Bytecode is the intermediate representation of Java
programs just as assembler is the intermediate representation of C or C++
programs” [15]. Java bytecode contains platform-independent instructions
that are translated to platform-specific instructions by a Java Virtual
Machine.
4

(cont’d)
 Machine code is stored in files with varying extensions (*.exe, *.dll, *.so,..,);
extensions are dependent upon the operating system.
 On the contrary…
 Java bytecode is always stored in files that have a *.class extension.
 The Java Language Specification allows at most one top-level public class to be
defined per *.java source file and requires that the bytecode be stored in a file
with whose name matches the pattern TopLevelClassName.class.
 Collections of Java classes, such as those for an application or class library, are
stored together in an archive file with a *.jar extension.
5

Decompiling and Disassembling Java Bytecode
 Bytecode is stored in a binary format that is not human-readable and therefore
must be “disassembled” in order to be read.
 Oracle’s Java Development Toolkit (JDK) comes with javap, a command-line
tool for “disassembling” Java bytecode.
 To say that javap disassembles bytecode is a misnomer because the output of
javap is unstructured text which cannot be compiled back to bytecode.
 The assumption is you already have the *.class file.
 The output of javap is nonetheless useful as a debugging and performance
tuning aid since one can see which JVM instructions are generated from high-
level Java language statements.
6

7
javap demo

 The result of disassembling Java bytecode is a pseudo-assembly language, a
language that cannot be compiled or assembled but serves to provide a more
abstract, readable representation of the bytecode.
 While it may seem possible to use a hex editor directly modify Java bytecode in
a *.class file, this is similar in difficulty to editing machine code in a hex editor.
 However, libraries exist for deserializing and serializing bytecode using in-
memory Java object models. This allows programmatic modification.
 Decompiling then recompiling Java bytecode after making modifications is
perhaps the most straightforward way to reverse and patch Java applications.
20

Java Bytecode Reversing and Patching Exercise
21
PasswordVault.jar

22
PasswordVault.jar

23
PasswordVault.jar

24
PasswordVault.jar

25
PasswordVault.jar

26
PasswordVault.jar

27
FrontEndPlusV1andV2.zip

28

29

30

31

32

33

34

35

36
PasswordVault.jar

37
PasswordVault.jar

38
PasswordVault.jar

39
PasswordVault.jar

Byte Code Engineering Library (BCEL)
 BCEL provides a convenient way to analyze, create, and manipulate Java
Bytecode (Java *.class files).
 Perform static analysis, dynamic create, or transform Java bytecode.
 High level of abstraction of the Java class file format relieves the programmer
from internal details of the Java class file format.
 BCEL is used in projects such as compilers, optimizers, obfuscators, code
generators and analysis tools.
 Development activity has been low over the past few years.
 The ASM project on objectweb is an alternative.
40

Byte Code Engineering Library (BCEL) API
 The BCEL API abstracts the Java Virtual Machine and reading and writing binary
Java class files. The API consists mainly of three parts:
 A package that may be used to read and write class files from or to a file.
The main data structure is JavaClass.
 Usage: analyze Java classes without having the source files at hand.
 A package to dynamically generate or modify JavaClass or Method objects.
 Usage: insert analysis code, strip information, implement a code
generator back-end of a Java compiler.
 Various code examples and utilities such as a class file viewer.
41

42
[BCEL Manual]
Java Class
File Format

Byte Code Engineering Library (BCEL) API
45
BCEL demo

Reversing and Patching Java Bytecode

Related slideshows

More Related Content

Reversing and Patching Java Bytecode