In this article, I will tell about the main tools that a modern software reverser uses in his work.
A New Kind of Software For Engineering. Even the smartest of engineers would need a little help in finishing their projects. Engineering drawing software takes a huge burden off their backs by helping them draw all they need to complete certain projects.
This article is for readers, who are familiar with the Assembler language, network interaction principles, and have experience of programming for Windows using API functions.
Contents:
There are so many different software applications in the modern world, and the source code of the most of them is hidden from our sight. But there are a number of situations, when we do need to understand the logic of functioning of platforms and applications, their algorithms and specifics. That is when the legal software reversing is called up – a service provided by Apriorit software research department.
There are a lot of products to make this task easier. We are going to discuss some of the best reverse engineering software; mainly it will be tools reverse engineering tools for Windows. Notice that you can learn more details about the process and nuances of Windows software reversing in this post (great example included). If you are more interested in iOS/OS X code reverse engineering software and approaches - take a look at this post prepared by our researches.
It’s hard to name the best software reverse engineering tool – there quite a few of them, and each one resolves some specific task of the multistep reversing process. Elcomsoft ios forensic toolkit mac torrent. Let’s make a brief overview of the those applications, Apriorit researchers frequently use in their projects.
IDA Pro must be one of the best reverse engineering tools. It is an interactive disassembler, which is widely used for software reversing. It has the in-built command language (IDC), supports a number of executables formats for variety of processors and operating systems. Also it has a great number of plugins which allow to extend the disassembler functionality even further.
The main advantage of this tool is that it allows you to interactively change any element of the displayed data:
You can find more details here.
There IDA plugins, which are also worth mentioning besides the disassembler itself.
It's a plugin which adds assembler to C decompiler to IDA. The decompiler produces pretty accurate C code comparable to the one produced by human reverse engineer. It indeed has issues with complex assembler code, where the original code was specifically modified by adding the inline assemble or some manual optimization was in place. But in the common case, it decompiles the code produced by various C++ compilers, just fine, no matter the architecture.
The plugin which adds the ability to mark the execution path within the disassembler. This allows the researcher to understand which parts of the code are taking part in the execution, and if they are involved in some algorithm or feature. Basically, this plugin loads the reports of the code coverage tools into IDA database and marks code pieces, which were executed with a specific color, depending on how many times the piece was executed. So while browsing the disassembly it becomes clear which part of the code is worth attention
This plugin is intended to be used on the binaries built by Visual Studio and searches for RTTI information, which is stored in the data section of the executable file. RTTI information allows the plugin to find the class names and virtual methods of the C++ classes, and name them for the user. Also it presents the list of the found classes.
It's a tool, which uses IDA engine to compare the binaries, not as a stream of bytes, but as an assembler code. So that it's able to pinpoint code changes of two versions of the same program up to the changes in a specific function as a list of instructions which were added, removed or replaced. The changes can also be represented as code flow graph.
The plugin which analyzes the imported functions and the functions, which call them and then group them by tag: cryptography-related, registry-related, network-related, etc. Such grouping simplifies finding the part of the code responsible for specific operations.
It's a plugin which allows to emulate the execution of the disassembled code, without a need to run the application in a debugger. So it allows emulate the result of any piece of code without a fear to modify something in the system. User just specifies the start values of CPU registers and then can do step-by-step execution.
Read also:
How to Reverse Engineer an iOS App and macOS Software
CFF Explorer includes:
Find more details here.
API Monitor is an application, which intercepts API function calls. It can display input and output data. By default, there are 10,000 API functions and more than 600 COM-interfaces enabled.
You can learn more details here.
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 is not able to do.
You can learn more details here.
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.
Main features:
Learn more details here.
Fiddler is a proxy that operates with traffic between computer and remote server, and allows viewing or changing it (MITM). It can work with both HTTP and HTTPS.
You can use Fiddler to intercept traffic that goes between the application and the server.
It allows to intercept HTTP/HTTPS. It is possible to add plugins (e.g. wbxml view, which can decode wbxml), display requests/responses in different views. It contains built-in hex editor. Fiddler is also able to generate requests based on the selected one, or create a custom request.
In addition, there is the “Request to Code” plugin for Fiddler, which allows to get ready code that executes requests on C#, VB, or Python. You can download it here.
Read also:
Anti Debugging Protection Techniques With Examples
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.
Application that removes values from the Relocation table. You can download it here.
PEiD is the best tool to 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.
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.
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.
Read also:
Using Web Debugging Proxies for Application Testing
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. 360 video stitching software mac.
Gopanel 1 8 9 – manage web servers. 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: https://free-beautiful-phototomovie5300.peatix.com.
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).
Read also:
How to Reverse Engineer Software (Windows) in a Right Way
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 :)
Related services
Engineering for Cybersecurity Projects
0 
Star