# Basic Malware Reverse Engineering ## BASIC MALWARE RE WRITEUP *By Jacvbtaylor* ``` Used Ghidra and Kali Linux https://tryhackme.com/basicmalwarere completed April 10, 2023 ``` ### OBJECTIVE Using static analysis, the task at hand is to discover which string in each .exe file is going to be hashed using MD5 once it is executed. The usefulness provided by these challenges extends to real world scenarios where malware may be encrypting compromised data. Being able to discover how it is encrypted can lead to recovering the data.

### Strings1.exe\_ After importing all three .exe files into our project using [Ghidra](https://ghidra-sre.org/), the first step is to analyze the first file, *strings1.exe\_*. Starting with the symbol tree, open the functions select *entry.*

Selecting *entry* should have kick-started code population in the *Listing* and *Decompile* window. First looking at *Decompile*, a character pointer is revealed in C code that is instantiated and set to equal a defined string set as *md5\_hash.*

To uncover the full string, first double click *md5\_hash* in the *Decompile* window next moving to the *Listing* window where the ID *00424828* is shown.

Double click that ID to move the Listing to the line that reveals the flag in its entirety as the string that will be hashed upon file execution.

### Strings2.exe\_ To begin the analysis of *strings2.exe\_*, begin in the *Symbol Tree* and select *entry*.

Decompile should now reveal the following C code, listing mostly variables, defined and undefined. It is easy to assume these variables will be added in the stack from how they are assigned. additionally, a character pointer is assigned to *md5\_hash* and *local\_2c*.

Studying the local variables, it is clear that each definition is set to a hex value, excluding *local\_2c* which is defined as "*F*". Taking these values and assembling them through bash scripting allows for converting these hex values with ease.

Using rapid tables, all of the hex values were converted to ASCII characters which revealed our flag - the only thing missing was the defined value of *local\_2c* which was "*F*".

Following the steps described above discloses the string that will be hashed upon file execution.

### Strings3.exe\_ Lastly, *strings3.exe\_* can be analysed the same way by opening *functions* and *entry* in *Symbol Tree*.

The *Listing* window doesn't show enough information for our task at hand to be resolved, so we move to the *Decompile* window.

From this view, a character pointer is described to be equal to *local\_a0*, or *MD5*. This is a good implication that we are on track for the string we are looking for. Examining this entry further, two interesting fields stand out: *FindResourceA* and *LoadStringA*.

Double Clicking *FindResourceA* changes thge *Listing* window to the following lines of the code. As shown, *FindResourceA* appears to be from the *Kernel32 library* which is loaded into protected memory upon system boot-up. In other words, this library is used by Windows OS in part of the shared dynamically-linked libraries. It will be used by multiple processes while one copy is stored in memory.

With this understanding established, the new step is to locate *LoadStringA*. Double clicking this field in *Decompile* should change the *Listing* window to the following external function.

Knowing that this exe file is compiled with C code, these two linked libraries are critical for the execution inside of the Windows OS. Without loading or linking the Kernel and User DLL, the program will not be able to receive input, or produce output. Specifically for *User32* we want to focus on the *hInstance* parameter which is more clearly set inside the *Decompile* window.

Analyzing line 18, or *LoadStringA*, we can presume the string is being loaded from *0x110* and being stored in variable *local\_4a4*. Double clicking 0x110 loads the following into the Listing window, which provides a hint to the string we are looking for, but we need to be more precise.

in Ghidra, hovering over the string identifier provides insight that can be used - the decimal value of 0x110 is converted to 272.

In the Listing window, we can locate the Hex values and scroll until Rsrc String ID 272 is presented, which provides the string that will be hashed upon file execution.