<<

Reverse Digital Forensics Rodrigo Lopes October 22, 2006

Introduction

Engineering is many times described as making practical application of the knowledge of pure sciences in the solution of a problem or the application of scientific and mathematical principles to develop economical solutions to technical problems, creating products, facilities, and structures that are useful to people. What if the opposite occurs? There is some product that may be a solution to some problem but the inner workings of the solution or even the problem it addresses may be unknown. is the process of analyzing and understanding a product which functioning and purpose are unknown. In Science in particular, reverse engineering may be defined as the process of analyzing a system's code, documentation, and behavior to identify its current components and their dependencies to extract and create system abstractions and information. The subject system is not altered; however, additional knowledge about the system is produced. The definition of Reverse Engineering is not peaceful though, especially when it concerns to court and lawsuits. The Reverse Engineering of products protected by copyrighting may be a crime, even if no code is copied. From the companies’ point of view, Reverse Engineering is many times defined as “Analyzing a product or other output of a process in order to determine how to duplicate the know-how which has been used to create a product or process”.

Scope and Goals

In the Digital Forensics’ scope, reverse engineering can directly be applied to analyzing unknown and suspicious code in the system, to understand both its goal and inner functioning. Being the program unknown, laws do not apply to this particular situation, and reverse engineering can be freely performed, whether the role is the one of a criminal or federal investigator, a company investigator or a private user. In a company’s policies, Reverse Engineering may even be contemplated as a part of its own business, to track bugs or undocumented behavior on their own products (worker programmed a ). The biggest problem is that any file is not humanly readable, it is many times in binary format or some form of compiled encoding. It is important to go from those encodings to some readable format in order to analyze the program and come to profitable conclusions. Once again and alike most operations in Forensics, the object of must not be altered, so that the outcome can be accepted as a forensically sound evidence.

Methodologies

There are several approaches for reverse engineer a program, the main methods are:

Dead Listing - Disassembly of binary, yielding some low level code () whose structure is then examined to decipher what operation is being performed. Live Tracing - Tracing execution as the target is running and watching data structures change. Behavioral - Examining how the target interacts with its environment (, registry, file system, other system components). Differential - comparing consecutive snapshots to discover changes and hypothesize an algorithm/structure.

The method described on this paper focus mainly on dead listing analysis. Before any reverse engineering can be done, it is important to detect the activity of suspicious programs. This can be done using a set of tools that monitor the system and gather data about all activity going on it. After detecting the executable that performs the suspicious activities, its decoding must be done through a or , which is the process of converting the binary executable file to a form of readable code that can be analyzed and debugged. The stage is fundamental in understanding what the program does, since looking at assembly code alone may not give a clear picture of what the program does and is also very time consuming. There are no tools that automatically reveal what the program does, human interaction Is required in order to make some sense of what is happening. While debugging the decompiled code, the investigator can stop the execution at any time and analyze the memory and internal variables, as well as open and active sockets. On the image below there is a flowchart representation of Reverse Engineering Processes. In a general way, every time a system representation is converted in a more abstract model, it is considered Reverse Engineering and the opposite, going from an abstract model to a particular specific implementation is considered engineering or Forward Engineering. While in industry Reverse Engineering is usually used at a more abstract level, going from to non-programmatic models, in forensics, this Reverse Engineering starts at the least abstract level, which is the machine code, and tries to make upper level representations, beginning at the assembly code directly derived from the binary code, which is specific for a given architecture. The analysis of this code and conversion to some higher, more intelligible, format is not an automatic process, it actually requires a great effort in time and expertise plays a lead role on the process.

Malicious software many times uses techniques to help obfuscate the code. In those situations human interaction is even more important to understand what the code is really doing.

Tools

The decompilation and debugging tools available vary with the used operating system. While tools are available for free, Windows tools may be expensive, but provide an environment that makes it easier to recover and analyze the unknown executable files.

Windows Tools:

IDA Pro (www.datarescue.com) (from $479.00 to $875.00 for a single license)

Standing for , the IDA Pro is a widely used commercial tool for disassembling and debugging binary files, supporting a wide variety of processors and . IDA Pro is specially used in the hostile or malicious code analysis.

NuMega SoftICE (www.compuware.com) offered as part of Compuware's DriverStudio has been discontinued due to a “variety of technical and business issues as well as general market conditions”

Has the ability to stop the whole operating system and hardware at any time, originally developed to debug device drivers.

wdasm32 (http://www.softpedia.com/get/Programming/Debuggers-Decompilers- Dissasemblers/WDASM.shtml)

Dissassembler/Debuger for Windows.

Hackman Suite (www.technologismiki.com)

Offers a desassembler, a and a hex Editor.

OllyDbg (http://www.ollydbg.de)

OllyDbg is a 32-bit assembler level analyzing debugger for Windows Environments

Linux Tools:

objdump (http://www.gnu.org/software/binutils/manual/html_chapter/binutils_4.html)

A part of the GNU Binary Utilities, has various options to disassemble code

dasm

A wrapper for objdump written in perl that gives most of the functionality found in Windows /

Gdb (http://www.gnu.org/software/gdb/)

Debugger from the GNU project.

Legal and Ethical issues

While there are legal implications of using reverse engineering techniques on commercial products, to use those methodologies and tools on suspicious unknown programs seems to be perfectly legal, since there is no copyright laws or end user agreements on those programs that often are illegally installed on systems. Reverse engineering is a vital resource in understanding and fighting threats such as Virus, Spyware, Trojans, and all sorts of malicious code. Anti- Virus and Security companies often use Reverse Engineering to track and fight those threats. There are several known cases where companies sue for reverse engineering their products. The Definition of reverse engineering used is important in those situations. To reverse engineer a legally bought product seems to be perfectly legal, if the purpose is integration with legacy or other proprietary systems, or even extension of functionality. It may be illegal if the knowledge obtained is used to copy the product and obtain profit out of it.

References http://www.sei.cmu.edu/str/indexes/glossary/reverse-engineering.html http://www.eweek.com/article2/0,1895,1853996,00.asp http://packetstormsecurity.org/linux/reverse-engineering/dasm http://www.technologismiki.com/en/index-h.html http://www.zeltser.com/reverse-malware-paper http://www.securityfocus.com/infocus/1637 http://www.program-transformation.org/Transform/DeCompilation http://www.ruxcon.org.au/files/Ruxcon2003_Reversing_Workshop.pdf http://staff.washington.edu/dittrich/forensics.html