# [MalwareBytes Reversing Malware Writeup](https://ctftime.org/event/XXX)
###### tags: `malware` `2022` `reversing` `TeamT5` `2021 winter security camp`
{%hackmd theme-dark %}
去年(2021) 獲選參加 TeamT5 的寒假資安培訓營，收穫豐富。過了一年，想說複習之前學習的逆向惡意程式內容，也順手做紀錄。為了練習英文寫作，所以接下來都是使用英文書寫，請大家包含。如果想看中文的話，也歡迎搭配其他參加大大的[技術分析文章](https://hackmd.io/ZazbIVb6TIuzi6aCLcmT3g?both#Resources) 。
:::info
***For educational usage binary***

[Binary download link](https://www.dropbox.com/s/cs1w521iylkvca8/5D9CC09A1810A440436E54F9FD06E619-aslr-disabled.bin?dl=0)

After unzipping the zip file, you are good to execute the binary.
:::

## Tools I used
- Virtual Machine
- Parallel Desktop `17.1` with Windows `10` in it
- Static Analysis
- IDA Pro `7.6`
- Detect It easy `v3.03`
- pestudio `9.27`
- Dynamic Analysis
- x32dbg `Version: Nov 26 2019`
- Network monitor
- Wireshark `Version 3.4.2`
- Fiddler `v5.0.20211.51073`

## IDA Pro great configuration(Optional)

IDA Pro has two friendly configurations that makes our analysis much more comfortable.
- Synchronize with option: It synchronizes the pseudocode and the assembly. It is easier to jump from high-level language to low-level language by synchronizing. Also, with this configuration, it's easier to make the comparison.
- Show line prefixes option: It is easier to see the exact address where the function is executed
- The result

After these two configurations, we are good to go!

## Stage-1
### Descriptions
After executing the binary, we can see a message box pop up. We can see a string from the console message that says, `I am so sorry, you failed! :(`. The string is the exact spot we start our journey! Besides that, we know the flag format is `flag{...}`.

### Observe the variables
Dragging the binary to the IDA Pro, let's start the analysis.

Now let's observe the path where it shows, `I am so sorry, you failed! :(`. To avoid this path, let's see why it chooses this failing path? From the image below, we can find out that at (1) it `call sub_4014F0`, at (2) `test al, al` , and at (3) `jnz loc_4019A5` which results in the failing path at (4). From calling convention, we know that `al` derives from `sub_4014F0` and `al=0` leads to the failing path. Hence let's examine this function and see what happened inside.

In `sub_4014F0`, we can see that there is a comparison if `sub_403380` equals `0x3B47B2E6`. If the answer is yes, we can go to the correct path at [5]. Besides that, we can find out that `szUrl` is passed to the first argument of `sub_403380`. By making the educated guess, the goal of solving the problem could be filling `szUrl` with the correct value as the input and validating the comparison.

And thus, let's find out the reference of `szUrl`.

By pressing `x` in IDA Pro, we can get the references of `szUrl`. From the image below, at [2] is where we press the `x` of `szUrl`. At [1] is the place where `szUrl` comes from. Finally, at [3] is where `szUrl` is being used.

Let's first examine [3], we can see `szUrl` is setted as an argument of function `sub_4033D0`

It's time to check function `sub_4033D0`, we can see that `szUrl` is one of the arguments of `InternetOpenUrlA`

- the esi register dervives from the argument of `sub_4033D0` which `szUrl` comes from

- From [docs-ms-InternetOpenUrlA](https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetopenurla), it is documented that the `lpszUrl` is `A pointer to a null-terminated string variable that specifies the URL to begin reading. Only URLs beginning with FTP:, HTTP:, or HTTPS: are supported.`

- To keep it simple, these functions open an URL.

Seeing the following code in `sub_4033D0`, we can determine that `InternetReadFile` is called.

- From [docs-ms-InternetReadFile](https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetreadfile), `hFile` is an `Handle returned from a previous call to InternetOpenUrl, FtpOpenFile, or HttpOpenRequest`.

So if we can confirm that the result of output from `InternetOpenUrlA` is passed through `InternetReadFile`'s first argument, we can ensure that the binary will download some contents from the `szUrl`.

And the answer is yes!

Let's examine [1] where `szUrl` comes from.

From the image below, we can see that `szUrl` is one of the arguments of `sub_4031C0`

Let's rely on the decompilation of IDA Pro. We can figure out that `szUrl` is part of the `CryptDecrypt` function
- From [docs-ms-CryptDecrypt](https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptdecrypt), we can find out that `szUrl` is served as `pbData`
- `pbData`: `A pointer to a buffer that contains the data to be decrypted. After the decryption has been performed, the plaintext is placed back into this same buffer.`

We can guess from the info we get that `szUrl` must be decrypted. After the decryption of the URL, the binary will request the URL. Eventually, the binary will download some content from the URL.

### Find out the decryption key
We know from the image below that `CryptHashData` is called to create a hash from the binary passes.
The `pbData` derives from the `key_buf`, the fourth argument of `sub_4031C0`.
This hash's importance is because it will derive the decryption key (which will be used to decrypt the `szUrl`) at `CryptoDerivekEY` later.

Now, let's find out where the `key_buf` is referenced. From the image below, we can see at least nine places `key_buf` is referenced

### Patch the anti-debugger
The `key_buf` is mangled at nine places before activating the decryption. So to protect the integrity of the `key_buf`, we have to enter each function and patch any branch that will violate the content of `key_buf`. And that means we have to fix nine functions.

There are several methods to patch the binary, you can either use PE-bear to patch (like the author of this binary does), or you can patch it by x32dbg which I prefer the latter one.
## TODO: The process of patching the anti-debug
- Tips:
- Save the patched binary each time you finish patching each function. This will save you tons of time
- How to check if we patch correctly?
- If it does not return an error that means you are good to go
:::info
**Nine addresses to patch**
1. In sub_4019D0: patch **0x401A0E** with nop bytes
2. In sub_401A50: patch **0x401A97** with nop bytes
3. In sub_401B00: patch **0x401B72** with nop bytes
4. In sub_401C20: patch **0x401C42** with nop bytes
5. In sub_402730: patch **0x402817** with nop bytes
6. In sub_402880: patch **0x4028A7** with nop bytes
7. In sub_402B70: patch **0x402D71** with nop bytes
8. In sub_402DE0: patch **0x402F7E** with nop bytes
9. In sub_401BC0: patch **0x401BE4** with nop bytes
:::
The result of patching:
It shows that `You are on the right track!` at the console with the popup `Nope :(`

### Obtain the link
Start the Wireshark and start to monitor the network. We can find that the binary is trying to query `pastebin.com` and downloading data from the website (we already know from static analysis).

To ensure `104.23.99.190` is the IP of `pastebin.com`, we can `dig pastebin.com` and confirm that's true.

To see the encrypted data, you have to enable the decrypt HTTPs options in `Fiddler` which we get the complete url [`pastebin.com/raw/9FugFa91`](pastebin.com/raw/9FugFa91)

The downloaded content

### Analyze the content from the URL
Although we obtain the contents from the URL, we still fail to continue running the binary. So let's dive down to static analysis and reveal what the binary does afterward.

Let's focus on the string `Nope :(` and `xrefs` it. It's referenced at funciton `sub_401690`

Let's discover function `sub_401690` and see the secret inside.

There are four processes in function `sub_401690`. It's worthy of analyzing this function dynamically with x32dbg.
1. Base64 decoded
2. Decompressed with RtlDecompressBuffer
3. XOR decrypted with the key from the clipboard

We can get the key `malwarebytes` from the dump data while there are a bunch of empty spaces in this binary. (reason: `malwarebytes xor 0 = malwarebytes`)

4. MZ check
From the image below, we can see that the start of the dump data is `MZ` which will be validated later. This is the `stage2.exe` binary, and we can dump the binary from x32dbg with offset `0xE400` from the start of address `0x752e40`.
- Where to find the dump data?
`Right-click the .text section -> Find in Dump -> Address: EDI`
- How to find the offset `0xE400`?
- We can find it from the clue given from the console!
- We can see `00E4`(in little Endian) and we convert it to `E400`

## TODO: Let's discuss each function seperately
#### Base64 decoded
#### Decompressed with RtlDecompressBuffer
#### XOR dcrypted with the key from the clipboard
#### MZ check
### Stage-1 Result
- Obtain second PE
- Scylla usage
## Stage-2
### Execute second PE
This is the message I got from the second PE.

## Analyze the code
1. Get ModuleFileName
2. ExpandEnvironmentStringsA
3. Compare the hash
4. EnumWindow to find the specific process
5. Check if the binary is executed in the debugger
6. XOR the shellcode
### Obtain the shellcode
Bypass the two following branches, and we can get the shellcode injected later.
- 
- 

The dump data we get will be served as shellcode. It comes from the address `0x2fe000`
- How to dump data in x32dbg? There are two ways:
1. Use [`savedata`](https://daevlin.github.io/2020/07/25/x64dbg_tips_and_tricks.html) function: `savedata file-directory,start address,offset`
2. Use x32dbg plugin `Scylla`

### Process Hollowing
Use PE-bear to inject the shellcode back to `stage.exe`. This is impressive when I see [the author's instruction video](https://youtu.be/A7jIlVTYDGY)
#### Steps
- There are 6 steps:
1. Add section in `stage2.exe`.
2. Choose the shellcode we just dump and add section name and press ok.
3. we can see the `shellcode` is added to `stage2.exe` section.
4. Change the characteristics to `e0`
- How to change?
- The result
5. Go back to assembly and set the entry point to 0x13000
6. Save the patched binary

#### Result: Get the flag!

## Conclusion
This is an interesting binary to learn Windows API, patch binary, static/dynamic analysis, dump data with x32dbg, and injecting shellcode to process.
## Resources:
- [malwarebytes tutorial](https://blog.malwarebytes.com/malwarebytes-news/2017/11/how-to-solve-the-malwarebytes-crackme-a-step-by-step-tutorial/)
- [high-level-observation-writeup](https://mauronz.github.io/mb-crackme/)
- [low-level-observation-writeup](https://29wspy.ru/reversing/SolutionHasherezadeCrackme2017.pdf)
- [TeamT5 Winter Security Camp classmates wrietup](https://medium.com/wei-zen-liu/teamt5-security-%E5%9F%B9%E8%A8%93%E5%BE%8C%E7%AD%86%E8%A8%98-windows-reversing-7545cff6aa7c)

## Notes
[cmp](https://reverseengineering.stackexchange.com/a/20897)
- `cmp A B => A - B to see if they are the same`
- If returns 0 => `A = B` => `ZF=1`

[test](https://stackoverflow.com/a/13064985/12349124)
- `test eax eax => eax AND eax to see if they are the same`
- If returns 0 => `eax = 0` => `ZF=1`

[Zero flag](https://www.wikiwand.com/en/Zero_flag): if the result equals 0 `ZF=1`
e.g. `cmp 100 100 => results in 0 => ZF=1 => JZ will be taken (which is same as JE)`
- `JE` equals `JZ`
- `JE`: Jump if cmp is equal
- `JZ`: Jump if Zero

[xor](https://stackoverflow.com/a/1396552/12349124):
- `xor eax eax` equals `mov eax, 0` but with shorter opcode