The Tools : Reverse engineering for beginners

Published by Sundareswaran on

Chapter – 1

part – 6

 

Reversing tools

Reversing is all about the tools. The next areas describe the basic types of tools that are employed backward engineering. Many of these tools were not specifically created as reversing tools but can be quite useful nonetheless. Chapter 4 offers an in-depth discussion of the different types of tools and introduces the specific tools which will be used throughout this book. Let’s take a brief look at the several types of tools you will end up dealing with.

System-Monitoring – Reversing tools

System-level reversing requires a variety of tools that sniff, monitor, explore, and otherwise expose the program being reversed. Most of these tools display information gathered by the operating-system about the application and its environment. Because almost all communications between a program and the outdoors world have the operating system, the operating system can usually be leveraged to extract such information. System-monitoring tools can monitor social networking activity, file accesses, registry access, and so on. There are also tools that expose a program’s use of operating system objects such as mutexes, pipes, events, and so forth. Many of these tools will be talked about in Chapter 4 and throughout this book.

Disassemblers – Reversing tools

As I described earlier, disassemblers are programs that take a program’s executable binary as input and generate textual files which contain the assembly
language code for the complete program or areas of it. This is a relatively simple process considering that assembly vocabulary code is simply the textual mapping of the object code. Disassembly is a processor-specific process, but some disassemblers support multiple CPU architectures. A top quality disassembler is a key component in a reverser’s toolkit, yet some reversers prefer to just use the built-in disassemblers that are embedded in some low-level debuggers (described next).

Debuggers – Reversing tools

If you’ve ever tried even the simplest software development, you’ve most likely used a debugger. The particular basic idea behind a debugger is that developers can’t really envision everything their program can do. Programs are usually just too complex for a human to really anticipate every single potential end result. A debugger is a program that allows software developers to observe their program although it is working. The two simplest features in a debugger are the ability to established breakpoints and the capability to trace through program code. Breakpoints allow users to select a certain functionality or code line any place in the program and instruct the debugger to stop program execution once that line is reached. Whenever the program reaches the breakpoint, the debugger halts (breaks) and displays the current state of the program. At that point, it is possible to either release the debugger and the program will continue running or to get started on tracing through the program.

Debuggers allow users to trace through a program although it is running (this is also known as single-stepping). Tracing means the program executes one the line of code and then stalls, allowing the user to observe or even modify the program’s state. The user can then perform the following line and repeat the process. This allows designers to view the exact flow of a program at a pace more appropriate for human understanding, which is about a billion times slower than the pace the program usually runs in. By installing break points and doing a trace for through programs, developers can watch a program closely as it executes a problematic section of code and tries to determine the source of the problem. Because developers have access to the source code of their program, debuggers present the program in source-code form and allow developers to set breakpoints and search for through source lines, although the debugger is actually working with the device code beneath. For a reverse, the debugger is almost as important as it is to an application developer, but for slightly different reasons.

First and foremost, reversers use debuggers in disassembly mode. In disassembly setting, a debugger uses a built-in disassembler to take apart object code on the fly. Reversers can step through the disassembled program code and essentially “watch” the CPU as it’s working the program one training each time. Just as with the source-level debugging performed by software developers, reversers can install breakpoints in locations of interest in the disassembled code and then examine the condition of the program. Regarding some reversing tasks, the only thing you are going to need is a good debugger with good built-in disassembly capabilities. Having the ability to step through the code and watch as it is executed is very an invaluable element in the reversing process.

Decompilers – Reversing tools

Decompilers would be the next step up from disassemblers. A decompiler takes an executable binary file and efforts to produce readable high-level language
code from it. The concept is to try and reverse the compilation process, to obtain the original source file or something such as it. On the vast majority of systems, actual recovery of the original source code isn’t really possible. There are important elements in most high-level languages that are just omitted during the compilation process and are impossible to recover. Still, decompilers are powerful tools that in some situations and environments can reconstruct a very readable source code from the program binary. Chapter 13 discusses the process of decompilation as well as restrictions and demonstrates just how effective it can be.


Leave a Reply

Your email address will not be published. Required fields are marked *