Defeating BlackMatter's string obfuscation

There are 25 calls of a function at address 004064cc which receives a byte array as an argument. All the data buffers passed to this function are global variables and live in the program's .data-section. A quick peek into those memory areas showed, that all the content seems to have very high-entropy and is garbage to the human eye. An indicator that the .data-section houses strings, was that the function calls often happen just before API-calls like RegCreateKeyExW and others.

A closer look at the a/m function at address 004064cc – illustrated in fig. 1 – revealed, that within in its body the following steps were performed:

1. Retrieve the size \(n\) of the given buffer by looking at the preceding dword
2. Allocate \(n\) bytes of memory
3. If the allocation succeded
   • Copy the content of the given buffer to the newly allocated memory chunk
   • Call actual decoding function at 00401713
4. Return the pointer to the newly allocated (and now decoded) buffer

As this is just a setup function, which prepares the decoding, a closer look at the function at address 00401713 – here labeled decodeWithLCG – is needed. Within this function a loop iterates over the buffer with a stepsize of four bytes. In each iteration a pseudo-random dword is generated, which is used to XOR the current four bytes as fig. 2 illustrates.

The interesting thing here is the way the pseudo-random numbers are generated, which is done by utilizing the linear congruential generator (LCG) algorithm, which is implemented in the function at address 00401769 – here labeled getRandViaLCG. This is a fast and easy to implement method for generating a sequence of pseudo-randomized numbers. On Wikipedia the formula which defines the LCG is defined by recurrence relation as follows:

\(X_{n+1} = \left( a X_n + c \right)\bmod m\)

where \(X\) is the sequence of pseudorandom values, and

\(m, 0 < m\) — the modulus

\(a,0 < a < m\) — the "multiplier",

\(c, 0 \le c < m\) — the "increment"

\(X_0, 0 \le X_0 < m\) — the "seed" ⁴

The implementation in the BlackMatter-binary matches this formal description very well as fig. 3 illustrates:

Looking at the decompiled representation after having performed some variable renaming, the similarity is even more striking:

\(m\) is here 0x8088405, \(c\) is 1 and the seed \(X_0\) is hard-coded as the first dword of the .rsrc-section. The only difference from the a/m formula is, that instead of doing a modulo-operation a binary shift by 32 bits is used to get the "remainder" after performing the previous calculations with 64-bit integers.

Having reversed this scheme and knowing, that the function at address 004064cc is used as a setup function, it is relatively easy to decode all strings within the binary. @sysopfb published a Python2-script to automatically decode the .data-section and print the results to stdout, which can be found here. Altough this is very helpful, it does not aid much during the reversing process, because the code references are lost. Therefore a Ghidra-script was created, which decrypts all buffers, that are passed in the "setup function" at address 004064cc, which initiiates the decoding process. The script is hosted on Github as BlackMatterDecodeLCG.java. It performs the following steps to decode all obfuscated scripts:

1. Ask the user for the name of the function, which sets up the buffer for the decoding
2. Retrieve the seed by reading the first dword of the .rsrc-section of the PE-file
3. Find all calls of the specified function
4. For each call:
   • Retrieve the address of the passed buffer
   • Read the preceding dword, which specifies the length \(n\) of the data to decode
   • Generate the $n$-element sequence of pseudo-random numbers and perform the XOR-operations
   • Update the buffer's bytes in the memory

After running this script all the strings in the .data-section are stored in cleartext and are accessible during further analysis. Unfortunately, there is more string obfuscation, encoded stackstrings to be specific, which are discussed in the next section.

Obviously, it is needed to install the Unicorn Engine on the system first:

# Clone Unicorn's repo
git clone https://github.com/unicorn-engine/unicorn.git

# Compile the code and install Unicorn's engine
cd unicorn
./make.sh
sudo ./make.sh install

Then build and install Unicorn's Java-bindings, which are already included in Unicorn's repository:

cd unicorn/bindings/java
# This path change was needed for me
sed -i 's@#include "unicorn_Unicorn.h"@#include "unicorn/unicorn_Unicorn.h"@' unicorn_Unicorn.c
# Assemble the .jar and the .so
make jar
make lib

# Install the shared lib
sudo cp libunicorn_java.so /usr/lib/jni/

There are several options to add the unicorn.jar to Ghidra's build path as it is discussed in this Github issue. Personally, I prefer to place the external .jar-files to use in my scripts inside the directory ${GHIDRA_INSTALL_DIR}/Ghidra/patch, like so:

# Add unicorn.jar to Ghidra's build path
sudo mv unicorn.jar ${GHIDRA_INSTALL_DIR}/Ghidra/patch

If you need code completion in Eclipse, add the .jar-file to your build path by right clicking on it and choosing "Add to build path".

After completing the above mentioned steps, you should be able to import Unicorn in your Java-classes by adding

import unicorn.*

and be able to create Ghidra scripts, which emulate code in the binary to analyze.

For a full but rather simple Python example refer to this script called bm_stackstrings.py. The general structure of the code is adapted from Jason Reaves' blog post on the decryption of BazaarLoader-strings with the help of Unicorn's Python-library ⁷, but the regex-pattern was adapted to BlackMatter's code blocks ⁸ and the script was ported to Python 3.

I took this approach as a base for the creation of a Ghidra script which emulates either the instructions in the code range selected in Ghidra's UI or specified by a start and an end address queried via a dialog from the user. After the region of interest to emulate is defined, memory has to be allocated for the code segment and the stack segment. Afterwards the memory region marked in Ghidra's UI is copied to the code segment and the stack segment is filled with zeros. Then the emulation of the code is kicked off. When the emulation has finished, the stack is read and scanned for the existance of a printable string. If one was found, it will be set as a comment just before the start address. If you want to try it yourself or just have a peek into a full example of Unicorn's usage in a Ghidra script, refer to

https://github.com/jgru/grus-ghidra-scripts/blob/main/blackmatter/BlackMatterStackStrings.java.

Win32_ShadowCopy.ID='%s'
Global\%.8x%.8x%.8x%.8x
Times New Roman
Control Panel\Desktop
WallPaper
WallpaperStyle
Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}

BlackMatter Ransomware encrypted all your files!
To get your data back and keep your privacy safe,
you must find %s file
and follow the instructions!

<snip>

Accept: */*
Connection: keep-alive
Accept-Encoding: gzip, deflate, br
Content-Type: text/plain
{
"bot_version":"%s",
"bot_id":"%s",
"bot_company":"%.8x%.8x%.8x%.8x%",
%s

{
"bot_version":"%s",
"bot_id":"%s",
"bot_company":"%.8x%.8x%.8x%.8x%",
"stat_all_files":"%u",
"stat_not_encrypted":"%u",
"stat_size":"%s",
"execution_time":"%u",
"start_time":"%u",
"stop_time":"%u"
SOFTWARE\Policies\Microsoft\Windows\OOBE
DisablePrivacyExperience
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
AutoAdminLogon
DefaultUserName
DefaultDomainName
DefaultPassword
bcdedit /set {current} safeboot network
bcdedit /deletevalue {current} safeboot
bootcfg /raw /a /safeboot:network /id 1
bootcfg /raw /fastdetect /id
SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce