Reverse Engineering 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. Reverse engineering is the process of analyzing and understanding a product which functioning and purpose are unknown. In Computer 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 design 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 software 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, copyright 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 backdoor). The biggest problem is that any executable 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 analysis 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 (assembly language) 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 (Operating System, 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 decompiler or disassembler, which is the process of converting the binary executable file to a form of readable code that can be analyzed and debugged. The debugging 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 source code 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 Linux 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 Interactive Disassembler, the IDA Pro is a widely used commercial tool for disassembling and debugging binary files, supporting a wide variety of processors and compilers. 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 debugger 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 decompilers/disassemblers 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, Malware 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 programmers 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 .