Applying Anti-Reversing Techniques to Machine Code

CS266 Software Reverse Engineering (SRE)
Applying Anti-Reversing Techniques to Machine Code
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.

Introduction, Motivation, and Considerations
 Extreme care must be taken when applying anti-reversing techniques because
most techniques ultimately change the machine code.
 In the end, if a program does not run correctly, measuring how efficient or
difficult to reverse engineer it is becomes meaningless [18].
 Anti-reversing transformations performed on source code make a program
more difficult to understand in both source and executable formats.
 These transforms can expose compiler bugs because the program no longer
looks like something a human would write.
 [18] states “any compiler is going to have at least some pathological
programs which it will not compile correctly.”
2

Introduction, Motivation, and Considerations
 Compiler failures on “pathological” programs occur because compiler test cases
are most often coded by people.
 Test cases are not typically generated by some sophisticated tool that knows
how to try every fringe case and surface every bug.
 Therefore we should not be surprised if some compilers have difficulty with
obfuscated source code.
 We now investigate the technique Eliminating Symbolic Information as it
applies to machine code.
 We previously looked at this technique in Applying Anti-Reversing
Techniques to Java Bytecode.
3

Eliminating Symbolic Information in Machine Code
 Eliminating Symbolic Information calls for the removal of any meaningful
symbolic information in machine code that is not important to the execution of
the program, but serves to ease debugging or reuse of it by another program.
 For example, if a Windows program references functions (methods)
exported by one or more libraries (DLLs), the names of those methods will
appear in the .idata (import data) section of the program binary.
 In production versions of a program, the machine code doesn't directly contain
any symbolic information from the original source code. In the executable:
 Method names, variable names (etc..), and line numbers are all absent.
 Only the machine instructions produced directly or indirectly by the
compiler [9] are present.
4

 This lack of information about the connection between the machine instructions
and HLL source is unacceptable for purposes of debugging.
 Therefore most modern compilers, like GCC, include an option to include
debugging information into an executable.
 The included debugging information allows a debugger to map one or more
machine instructions back to a particular HLL statement [9].
 To demonstrate symbolic information that is inserted into machine code to
enable debugging of an application:
 Calculator.cpp was compiled using the GNU C++ compiler (g++) with
options to include debugging information and to generate assembly source
instead of an executable (machine code).
5

6
Calculator.cpp

 The GNU compiler stores debug information in the symbol tables (.stabs)
section of the Windows PE header so that it will be loaded into memory as part
of the program image.
 The generated assembly language files CalculatorDebug.s on the next slide
shows some of the debugging information inserted by GCC.
 While this information is not a replacement for the original source code it
does provide some helpful information to a reverser.
 The GNU Project Debugger (GDB) is a source-level debugger and therefore
must access the HLL source file to make use of the debugging information.
7

8
CalculatorDebug.cpp

 Debugging information can give plenty of hints to a reverse engineer, such as
the count and type of parameters one must pass to a given method.
 An obvious recommendation is to ensure the code is not compiled with
debugging information before shipment to end-users.
 The hunt for symbolic information doesn't end with information embedded by
debuggers; actually it rarely begins there.
 Eliminating symbolic information in machine code is difficult, therefore we’ll
manually implement some familiar techniques to obfuscate the information.
 First, we will take a detour to look at obfuscation of source code and what use
cases it might address.
9

Source Code Obfuscation
 Obfuscating the Program calls for performing transformations to the source or
machine code that would render either code extremely difficult to understand
but functionally equivalent to the original.
 When delivering software to customers, they may require the source code so
that the product can be compiled using in-house build and audit procedures.
 In the likely event that the source code contains intellectual property, it can be
obfuscated without changing the the resultant machine code.
 To demonstrate source code obfuscation, COBF [23], a free C/C++ source code
obfuscator was configured and given Calculator.cpp.
 Stunnix C/C++ is a commercial source code obfuscator.
10

Basic Obfuscation of Machine Code
 [19] states “Obfuscation of Java bytecode is possible for the same reasons that
decompiling is possible: Java bytecode is standardized and well documented.”
 Machine code is not standardized; instruction sets, formats, and program
image layouts vary depending on the target platform architecture.
 Tools to assist with obfuscating machine code are much more challenging to
implement and expensive to acquire. (I have not found any free tools).
 EXECryptor is an industrial-strength machine code obfuscator.
 When applied to the machine code for the Password Vault application,
EXECryptor rendered it extremely difficult to understand.
 EXECryptor fails to start in Windows 8.1 due to an anti-debug error.
12

 Direct machine code obfuscations can be hard to analyze or follow, so we'll
perform obfuscations at the source code level and observe differences in the
assembly code generated by the GNU C/C++ compiler.
 Success is achieved when an obfuscated program has the same functionality as
the original, but is more difficult to understand during live or static analysis.
 There are no standards for code obfuscation, but it's relatively important to
ensure that the obfuscations applied to a program are not easily undone
because deobfuscation tools can be used to eliminate easily identified
obfuscations [5].
 We now look at the source and disassembly for VerifyPassword.cpp, a simple
C++ program that contains a simple if-test for a password.
 We then embed a simple cipher to protect sensitive constants.
13

14
VerifyPassword.cpp

15
.text
section
.rdata
section

16
VerifyPasswordObf.cpp

17
.text
section
.rdata
section

18
http://www.frida.re/

20
Dump of
.rdata
Start @
0x443000
Run exe in
new window

21
Run Frida
Script
Plaintext
extracted

23
Run exe in
new window
Dump of
.rdata
Start @
0x445000

24
Run Frida
Script
Ciphertext
extracted

25
http://www.frida.re/

26
max.c
We want to
call max()
dynamically
using Frida
Keep the program
resident

27
Debug statements
from int max(x,y)
function

28
Run max.exe using
OllyDbg File->Open
Specify
arguments

29
int max(x,y)
0x4012F0
X >= Y ?

31
Run max.exe
in new window
max.exe stays
resident

32
Run max.py 2x to
invoke max(x,y)
in max.exe

33
Password Vault Anti-Reversing Exercise
 The machine code anti-reversing exercise asks one to create a new executable
version of the Password Vault application where the following transformations
are applied:
 Encryption of string literals (data obfuscation).
 Obfuscation of the numeric representation of the password record limit
(computation obfuscation).
 Obfuscation of the method that performs the record limit check
(control flow obfuscation).
Contains both
unobfuscated and
Obfuscated source

34
Data Obfuscation
 Encryption of String Literals (data obfuscation):
Strings are decrypted each time they are used using a bundled cipher.

35
Computation Obfuscation
 Obfuscation of the numeric representation of the password record limit
(computation obfuscation):
Complex evaluations obscure the actual condition.

36
Computation Obfuscation (cont’d)
 Obfuscation of the numeric representation of the password record limit
(computation obfuscation) (cont’d):
Testing for a function of a number can slow a reverser down.

37
Control Flow Obfuscation
 Obfuscation of the method that performs the record limit check
(control flow obfuscation):
 We introduce some non-essential, recursive, and randomized logic to the
password limit check to make it more difficult for a reverser to perform
static and/or live analysis.
 Since no standards exist for control flow obfuscation, a custom algorithm
was designed to hinder live and static analysis through use of recursive and
randomized procedure calls.
 Recursion grows the stack considerably, making stepping through the code
difficult, while randomization makes execution unpredictable (breakpoints
may not trigger & run traces differ).

38
Control Flow Obfuscation (cont’d)
A control flow obfuscation algorithm for the record limit check.
Depth of the recursion is
randomized on each check
of the limit.
Random procedure call
targets generate and
return a number that is
added to an instance
variable, preventing the
procedures from being
identified as NOOPs by a
code optimizer.

39
 To measure the effectiveness of the control flow algorithm in hindering
analysis, three execution traces of the section of the code containing the record
limit check were compared.
 The Levenshtein Distance (LD) was computed between the three traces where
each instruction in the trace was compared. LD was modified to consider each
line as opposed to each character.
 The execution traces were collected using OllyDbg and had to be cleaned of
disassembly artifacts such as line numbers, base addresses, and comments in
order to ensure that the analysis was fair.

40
Comparison of executions of record limit check on identical program input.

Applying Anti-Reversing Techniques to Machine Code

More Related Content

Similar to Applying Anti-Reversing Techniques to Machine Code (20)

Recently uploaded (20)

Applying Anti-Reversing Techniques to Machine Code