Here we are with another of the malware reverse engineering challenges from MalwareTech — this time Ransomware.
These are static analysis challenges and therefore require a disassembler and not a debugger or dumper. Presumably most people reading this will be using the article as guidance. As such please follow standard practice and use an airgapped virtual machine, and do not run the ransomware file unless you WannaCry.
Apologies, couldn’t help myself, anyway let’s begin.
You can find the MalwareTech challenges here. This time round, we’ll use IDA Pro.
Ranomsomware1:
The administrator for FlagCorp was using an outdated Windows 7 system and got infected with some ransomware. We believe this variant was most likely written by a scriptkiddie due to the fact it was so badly designed it encrypted itself. One of our malware analysts was able to recover the encryption function from memory but doesn’t know much about cryptography. Can you find a way to decrypt flag.txt?
If we start by having a look at the files provided in the challenge, we can find a folder called ‘EncryptedFiles’.
One of the files within here is a text file with the following message:
Could’ve at least tidied up their spelling… anyway. We have the flag.txt_encrypted file and need to decrypt this using the ransomware.exe_ file. Opening up the ransomware.exe_ file in IDA PRO, and looking at the sub_401000 function, we can see it has two parameters.
lpFileName is associated with the CreateFileA function (fileapi.h). This creates or opens a file or I/O device. The most commonly used I/O devices are file, file stream, directory, physical disk, volume, console buffer, tape drive, communications resource, mailslot, and pipe. The funciton returns a handle that can be used to access the file or device for various types of I/O depending on the file or device and the flags and attributes specified.
We can see the similarities with the subvalues here. The function opens an existing file. It then uses a second CreatFileA function, reading the opened file using the ReadFile function (see below), then WriteFile followed by the CloseHandle function.
Somewhere in between opening the existing file and writing the new file is an encryption mechanism, which presumably is below:
The function loops over the bytes of the file and XOR’s the byte with a key. This is done in increments of 1 as you see the jmp opcode at the end of the function section above — file(i) = key(i) + 1. There is a parameter which adds the value in 20h to ecx which is then XOR’d. Therefore, the key is located at 20h
The information here doesn’t give a lot so let’s look at the encrypted pictures for hints. Interestingly the folder is Pictures then Sample Pictures:
Do you know what’s interesting? These appear to be stock photos that come with devices by default. A little more digging and I found these sample photos are for Windows 7 OS.
If we download Jellyfish.jpeg from archive.org and compare this with the encrypted version of that file we may be able to get more information on how to obtain the flag. Using Beyond Compare we can compare the two files to see any changes.
This shows that the executable opens the initial file and XOR’s it with the encrypted file. The result at 20h is the encryption key.
Key: 6E DD 9B 0E 45 5D 5E 92 97 CC AB 77 80 B4 0E 54 3D F5 A7 79 AA 93 5B 83 A9 D3 8D 2D B8 0F 40 0F
Finding a sample script for something similar online, we can amend this script to work for our encrypted flag:
jelly_unencrypted = bytearray(open("Jellyfish.jpg", "rb").read(0x20))jelly_encrypted = bytearray(open("Jellyfish.jpg_encrypted", "rb").read(0x20))
key = []
for i in range(0x20):
key.append(jelly_encrypted[i] ^ jelly_unencrypted[i])
file = open("flag.txt_encrypted", "rb")
buffer = bytearray(file.read())
flag = ""
for i in range(len(buffer)):
flag += chr(buffer[i] ^ key[i % 0x20])
print(flag)
If we move all files into the Sample Pictures folder and run the script we get the flag:
Answer: FLAG{XOR-MAKES-KNOWN-PLAINTEXT-AND-FREQUENCY-ANALYSIS-EASY}
And that wraps up this challenge — as always, stay safe!
