If you are thinking of all the main tools used by a modern software, then you are in luck because this article is going for them.
Therefore, if you are from someone who is familiar with network interaction principles, assembler language, and has some level of experience related to Windows programming using API functions, then you should read.
Understanding the Need for Best Software Reverse Engineering Tools.
Every day there are countless new software applications in the kind of world we live in. Furthermore, most of them have their source code hidden which makes more work while trying to understand the nuances, algorithms etc. of the said software. This is also where software reverse engineering tools come from.
There are many such tools to choose from and trying one of the best crowns can be quite difficult. Let go to applications that are frequently used.
Software Reverse Engineering Tools.
1. IDA-Pro, Hex-Rays.
It is an interactive disassembler and has an inbuilt command language or IDC. It supports a wide range of executives, operating systems and more. You can use this tool to draw diagrams, rename markers, and do more of the whole. An assembler code can be decomposed through a hex-res decompler plug-in.
IDA Pro should be one of the best reverse engineering tools. It is an interactive disassembler, widely used for software reversal. It has an in-built command language (IDC), which supports multiple executable formats for a variety of processors and operating systems. In addition it has a large number of plugins that allow disassembler functionality to be extended even further.
The main advantage of this tool is that it allows you to interactively change any element of the displayed data:
- Give the names to the functions, variables, data structures, etc
- Change the data representation (as numbers, as strings in a various encodings, as data structures)
- Build diagrams and graphs of code flow to simplify the understanding of disassembled code.
- Use the type information about function arguments and structure definitions from C++, so that the arguments and variables are automatically named.
- Automatically recognize and name the standard library functions in the assembler code and much more.
There IDA plugins, which are also worth mentioning besides the disassembler itself.
Hex Rays Decompiler
This is a plugin that adds assembler from ID decompiler to IDA. The decompoiler produces substantially more accurate C code than the one produced by a human reverse engineer. These are really problems with complex assembler code, where the original code was specifically modified by replacing the inline montage or replacing some manual customization. But in the normal state, it decomposes the code created by various C ++ compilers, just fine, no matter the architecture.
Plugin that adds the ability to mark execution paths within disassembler. This allows the researcher to understand which parts of the code are participating in the execution, and if they are involved in some algorithm or feature. Originally, this plugin marked the code coverage tool’s report in the IDA database and marked the piece of code that was executed with a specific color, depending on how often the piece Was executed. So while browsing the expression it becomes clear which part of the code is noticeable.
This plugin is to be used on binaries created by Visual Studio and searches for RTTI information, stored in the data section of the executable file. The RTTI Info plugin allows the C ++ classes to find the class names and virtual methods, and name them for the user. In addition it presents a list of found classes
BinDiff by zynamix
It is a tool that uses the IDA engine to compare bytes, not as a stream of bytes, but as assembler code. So that it is able to add code changes of two versions of the same program as a list of instructions for changes to specific functions that were added, removed, or changed. The changes can also be represented as code flow graphs.
A plugin that analyzes imported functions and functions, which calls them and then groups them by tags: cryptography-related, registry-related, network-related, and more. Such grouping simplifies finding the portion of code responsible for specific tasks.
It is a plugin that allows the execution of unsatisfied code to be simulated, without the need to run the application in the disbugger. So it allows simulating the result of any code without fear of modifying something in the system. The user only specifies the initial values of the CPU register and can then perform step by step.
2. CFF Explorer.
This includes a resource editor, PE and HEX editor, signature scanner, import editor, address converter, a disassembler, and a dependency analyzer.
CFF Explorer includes:
- PE and HEX editors
- Resource editor
- Import editor
- Signature scanner
- Address converter
- Dependency analyzer
3. API Monitor
It intercepts API function calls and can also display output and input data.
API Monitor is an application that accepts API function calls. It can display input and output data. By default, 10,000 API functions and more than 600 COM-interfaces are enabled.
It can display codes of software files, something that a simple text editor can’t do.
It is a HEX-editor that provides rich set of features and tools.
WinHex can display checksums or codes of software files, which simple text editor…..
Hiew is a binary files editor, focused on work with code. It has built-in disassembler for x86, x86-64, and ARM, assembler for x86, x86-64.
- Viewing and editing logical and physical drives.
- Searching for assembler commands by template.
- Keyboard macros.
- Built-in 64-bit calculator.
- Tools to create custom plugins.
Fiddler is a proxy that works with traffic between a computer and a remote server, and allows (MITM) to view or change it. It can work with both HTTP and HTTPS.
You can use Fiddler to stop the traffic going between the application and the server.
This allows HTTP / HTTPS to be intercepted. It is possible to add plugins (such as the wbxml view, which can decode wbxml), displaying requests / responses in different views. It has a built-in hex editor. Fiddler is also capable of generating requests or creating custom requests based on the selected one.
In addition, there is a “Request to Code” plugin for Fiddler, which allows getting ready code that executes requests over C #, VB, or Python. You can download it here.
It is an application that allows to dump a running application process and restore the import table. After that, you can run the application. You can download the application here.
8. Relocation Section Editor
Application that removes values from the Relocation table. You can download it here.
PEiD is the best tool for Reverse Engineering the use to detect the packer. By analyzing the entropy, PEiD can detect whether the application is packed or not.
There is also the KANAL (Krypto Analyzer for PEiD) plugin, which analyses PE file for the presence of known encryption algorithms.
There are various useful plugins that help to analyze PE files.
Learn more details here.
Practical software reverse engineering examples to show tools
Now let’s consider how to use mentioned reverse engineering software tools in practice, to research the applications. We will research a test application, you can download it here.
1. Opening of the researched executable in IDA-Pro
Let’s download a test application to IDA Pro. We receive the following message:
It means that something goes wrong with application: import table cannot be found. After that, we press the OK button and get the following:
The import table is almost empty. Its upper part shows that it was possible to detect a small piece of code (the blue part), and the left part shows which functions were detected (in our case, only two functions were detected). As we can see, there is a set of undetected bytes above the start function. We suppose that the application is packed by means of some packer. PeiD will help us to detect which packer was used.
Load our application.
The fact that Entry Point is located in the UPX1 section is not really saying much. It is necessary to run a scan. Just go to Options and choose “Hardcode scan”:
Then, select the folder where our application is. After scan, we will see the result:
We can see that the application is packed using UPX.
The tool contains various plugins:
We are not going to consider them all, just mentioning that one of them is able to unpack the application. We will better do this via CFF Explorer.
CFF Explorer helps to unpack the application. To do that, we go to the UPX Utility page and press the Unpack button:
After that, we can upload the application to IDA Pro, and assembler code will be restored.
We download it again to IDA Pro, which will ask whether to upload symbols from server, and we agree. Here is the result:
We see that there are code, some functions in the application, and import table. Now we run the application and debug it in IDA Pro. Select Debugger->Select Debuger->Local Win32 debugger, and then F9. As a result, we get:
The tested application detected that it was debugged, and even displayed a message that it was not registered:
We need to get rid of the fact that the application has detected a debugger.
See the import table:
At once, we can notice the NtQueryInformationProcess function. After clicking on it, we get the following list of xref functions:
Clicking on it, we can see where it is called. The third parameter is an output one, if it equals to 1, then debugger is attached to application, if it equals to 0, then debugger is not attached. Let’s see where the result of this function is written to:
We see that the third parameter contains the address of local variable (var_8). After function call, the result of the function is checked (test eax, eax). Then the value of var_8 is checked. If it is not 0, then the value is written to byte_131443C. Let’s check if this variable is used somewhere else in this function:
We’ll start from the end. This value contains the result from al (lower bytes). Before that, the esi result is written to eax, and 1 is written to esi. Above, we see the condition for writing 1 to esi: if ecx + 2 is not equal to 0. The value in ecx is large fs:30h (and then + 2), it is a verification of debugger presence bypassing the IsDebuggerPresent function (a field of undocumented PEB structure). Let’s rename this variable. Press “N” or Right click->Rename. Let’s see where it is used:
There is “…” in the end, so it is used in more places. Place the cursor over it and click «X» or Right click->Jump to xref to operand:
We already know the first places, where it is used, but not the last one. Let’s check it:
We see that it is checked whether it equals to 0. If it doesn’t, then we receive the message that there is a debugger.
We’ll consider the way to remove this verification in the “Hiew” section. It is worth noticing that IDA also allows to patch memory/code. In order to quickly find this piece of code, we’ll run the Rebase program to get the same offset as in Hiew. Select Edit->Segments->Rebase program, enter 0x400000:
Let’s get the address of the code that performs the comparison. It is 0х401329:
This value will be used in Hiew.
Let’s upload our application. First, it looks as follows:
Switch to the Decode mode. Press F4->Decode. Now we have to find the address, which we received in IDA Pro earlier. It is 0х401329. Press F5 and set the address this way:
We get code that compares our variable (g_isDebbugerPresent):
Now we can replace it with, for example, jmp to specific address, so that this condition would never be satisfied (in real applications, it can be an exception to immediately close the application).
Press F3 and then F2 to switch to the Edit mode. Enter the address of the next command after if. Add “.” in the beginning of the address, so that it would be relative:
After editing, our modified command is highlighted in yellow. Press F9 (Update), our application is saved.
If we try to run it, it is crashed.
Considering the Assembler code, we see that the new jmp will result in call esi, and esi will contain garbage instead of the MessageBox function address. We’ve missed the first mov esi, ds: MessageBox:
Therefore, let’s swap saving address to esi and our jmp. Now, we should set relative address in jmp to 14, but no longer to 1E, because the command became closer to the command we are going to.
Now, to make jmp, we should save the MessageBox address to esi.
After working with Hiew, let’s run it in IDA Pro, we go to our address:
We see that there is an unconditional jump. If we run application using debugger, we’ll receive crash, because previous command contained absolute address, and after application start, loader passes the Relocation table and adds delta to and each value to make all addresses valid. We just have to remove this value from the Relocation table. Let’s upload the original file to IDA Pro, find deleted earlier cmp, and enable option of showing commands in byte representation in IDA. Select Option->General:
This is what we get:
Cmp is a double-byte command starting with 1329, and the address starts with 132B. We can see that jmp is a one-byte command and its address is relative (it means that it shouldn’t be in the Relocation table):
Thus, we have to remove the 132A value from the Relocation table.
Open the application, changed by us, via Relocation Section Editor.
We have loaded the application and found the target value – 0x0040132A.
Remove it and save. After running, we get crash again. Go back to IDA Pro.
After removing 132A from the Relocation table and swapping jmp/mov, we also get crash. That’s because we haven’t edited the value, which previously pointed to mov, and now should point to jmp.
Open it in CFF Explorer. We have found the value, on which delta for MessageBox used to be added before. It is 1332.
Now, we’ll replace it with 132B, new value, bt which MessageBox can be found.
We run the application and see that it is not crashed any more and doesn’t show message about debugger detecting:
You can remove this message yourself :).
This program contains a number functions it can monitor. There is also a possibility to add your own functions.
Let’s monitor our application – we’ll try to find the MessageBox function calling:
I have pointed only a few functions.
Select File->Monitor New Process and set the path to our file.
After running our process, we see the list of the called functions. Let’s try to find MessageBox – here it is:
API Monitor shows which parameters were passed to it.
It is possible to set different breakpoints:
Run the monitoring of our file and here is what we get:
We can see the parameters, passed to this function.
By means of API Monitor, it is easy to monitor the network function calls and research the passed parameters (of course, if the traffic is not encrypted).
We should detect the type of binary file before exploring it. To do that, you can use any hex editor. As an example, I will use WinHex. Open file:
MZ signature at zero offset corresponds to the PE-format files (executables or shared libraries), so it is an exe file or dll.
For example, dump will look as follows:
Most file formats have its unique signatures.
In this section, we’ll consider the packed app. We are not going to unpack it, we will make its memory dump and try to run it.
To do that, open the packed executable file in IDA Pro. We do it to find the original entry point into the application (OEP), rather than the entry point of the packer.
The pusha command saves general-purpose registers to the stack. In the end, there should be popa, which pushes the stored register values. After this command, there is jmp to the original point of entry. You can use the “Search for text” option by pressing Alt + T and looking for popa.
Below the popa, there is jmp 40A191, which will eventually move to the original entry point.
Put a breakpoint in jmp and run the debugger.
Now let’s follow jmp, but IDA Pro shows:
It means that there is no code at the point, we’re going to. Therefore, IDA will create instructions in disassembled listing on the basis of bytes pointed by EIP.
0x00971A91 is the address of the original entry point after unpacking the application into memory.
Now, without closing the IDA Pro, open the Scylla in order to make the application dump and restore the import table.
In the process list, we choose our application and put OEP into the field:
Press IAT Autosearch, and then press Get imports. As a result, it shows that the import table is found.
Let’s make an application dump: press Dump, save it, then Fix Dump, and select the previously saved application.
If we run our application, it will still crash. So, we need to remove the Relocation table.
Open modified dump (it has the _SCY prefix) in CFF Explorer.
Set 0 to the «Relocation Directory RVA» field.
Check whether the ImageBase is the same as the application loaded into memory. This value can be found in IDA Pro, Edit-> Segments-> Rebase program.
Save and run your application. We receive the expected message:
In this example, I tried to show you how to work with each of the reverse engineering tools we briefly described in the first section. Anyway, the best way to master all these products is just start experimenting and researching yourself 🙂