mirror of
https://github.com/aljazceru/securedorg.github.io.git
synced 2026-01-03 14:24:29 +01:00
103 lines
6.2 KiB
Markdown
103 lines
6.2 KiB
Markdown
---
|
||
layout: default
|
||
permalink: /RE102/section5/
|
||
title: Setup
|
||
---
|
||
[Go Back to Reverse Engineering Malware 102](https://securedorg.github.io/RE102/)
|
||
|
||
# Section 5: Evasion Techniques #
|
||
|
||
|
||
|
||
This section will focus on identifying various evasion techniques as well as working around them during the debugging phase. Now that you will be working with an new executable, you will need to create another road map.
|
||
|
||
## Control Flow Obfuscation ##
|
||
|
||
You will notice that the shellcode is broken up into extraneous and unnecessary jumps. This is meant to throw off malware analysts. Malware that has this kind of useless instructions is usually processed with some kind of obfuscation kit (e.g., cryptors). Malware authors rarely write new shellcode and will sell, share, or reuse this code.
|
||
|
||
Going forward, you should be viewing the disassembly in graph mode, as it makes it easier to understand the control flow. Below is an example of the flow-chart mode of these jumps.
|
||
|
||
|
||
|
||
## Where to Start? ##
|
||
|
||
There are no strings for us to investigate and there are no functions parsed by IDA.. So, you need to start exploring each function one by one finding an interesting piece of code to analyze. This comes with experience. If this seems too daunting, then manual debugging is your next option. The goal is to make a road map of shellcode by working backwards.
|
||
|
||
## String Obfuscation ##
|
||
|
||
The first function call `sub_404C1E` doesn’t look like something interesting, so move on to the next function call to `sub_402B1C`. This function is a jump-wrapper for the function `sub_4059A3`.
|
||
|
||
Notice anything strange about the immediate values being placed onto the stack? These are actually strings. Breaking up strings and pushing them onto the stack is a common of hiding strings from malware analysts. Go ahead right-click these numbers and convert it to a string (R).
|
||
|
||
|
||
|
||
They should look like this afterwards:
|
||
|
||
|
||
|
||
## Dynamic Library Loading ##
|
||
|
||
With shellcode or position independent code (PIC), the code needs to load resources and libraries to work with before it performs the nefarious routines. Based on the strings above you can tell that it is going to load these libraries:
|
||
|
||
* user32
|
||
* shell32
|
||
* shlwapi
|
||
* advapi32
|
||
|
||
## Access to the Process Environment Block (PEB) ##
|
||
|
||
After the advapi32 string gets loaded onto the stack, enter the function `sub_405421`.
|
||
This function is accessing the FS segment register at offset 30. This register is commonly used by OS kernels to access thread-specific memory. This specific offset (i.e., `fs:[0x30]`) points to the Process Environment Block. This is a common shellcode tactic to get handles to loaded windows libraries a.k.a. Modules, specifically the base address of kernel32 from the PEB.
|
||
|
||
```
|
||
mov eax, 30h
|
||
mov eax, fs:[eax] ; Get the address of PEB
|
||
mov eax, [eax+0Ch] ; Get the address of PEB_LDR_DATA
|
||
mov eax, [eax+0Ch] ; InLoadOrderModuleList
|
||
mov eax, [eax] ; get the next entry
|
||
mov eax, [eax+18h] ; get Kernel32
|
||
```
|
||
|
||
|
||
|
||
The second instruction `mov eax, [eax+0Ch]` gets the address of the PEB Loader Data from the [PEB](https://msdn.microsoft.com/en-us/library/windows/desktop/aa813706%28v=vs.85%29.aspx) struct. The [PEB_LDR_DATA](https://msdn.microsoft.com/en-us/library/windows/desktop/aa813708(v=vs.85).aspx) contains the struct for the InMemoryOrderModuleList which is where it gets the pointer for Kernel32. **Note:** there are many great shellcode resources available that explain this technique. I just want you to recognize the instruction `fs:[0x30]`.
|
||
|
||
```
|
||
struct PEB_LDR_DATA {
|
||
DWORD Length; ; 0
|
||
BYTE Initialized; ; 4
|
||
void* SsHandle; ; 8
|
||
struct LIST_ENTRY InLoadOrderModuleList; ; 0ch
|
||
struct LIST_ENTRY InMemoryOrderModuleList; ; 14h
|
||
struct LIST_ENTRY InInitializationOrderModuleList; ; 1ch
|
||
};
|
||
```
|
||
|
||
Save these functions `sub_402B1C` and `sub_405421` for debugging later. Also include these into your road map for the shellcode executable.
|
||
|
||
## Checking the Filename and Path ##
|
||
|
||
Go to the next function `sub_4014AA` which is a wrapper for function `sub_401D36`. Again, this function is using an anti-analysis technique of pushing a string one by one onto the stack. Can you guess what this function is doing?
|
||
|
||
|
||
|
||
The strings are:
|
||
|
||
* sample
|
||
* sandbox
|
||
* virus
|
||
|
||
It seems the malware author wanted to detect if this executable contained strings related to malware analysis. You will need to debug this function to see which string it’s comparing these values. You will want to avoid this function because you need to get around the anti-analysis detection. Remember that functions return 0 or 1 in `eax` depending on the success or failure. You want this function to fail or return 1 because you want to get around these traps. Below the instruction `cmp eax, 1` and `jz loc_405272` is where the comparison to the return value occurs. During debugging, you would want to force the jump by changing the EFlags.
|
||
|
||
|
||
|
||
## Time to Start Debugging ##
|
||
|
||
After `jz loc_405272` there is a call to [esp+1Ch] this is actually calling a Windows API call that was loaded there by the loaded library function `sub_402B1C`. It would be tedious to go through those locations by hand, so let’s start debugging.
|
||
|
||
|
||
|
||
The next page will go over debugging the decrypted_shellcode.exe with x32dbg.
|
||
|
||
[Section 4.3 <- Back](https://securedorg.github.io/RE102/section4.3) | [Next -> Section 5.1](https://securedorg.github.io/RE102/section5.1)
|