Deep dive into imports: continuing to explore static resolution methods

Deep Dive into Imports: Continuing to Explore Static Resolution Techniques 🕵️‍♂️

Earlier we discussed how static import resolution can be implemented. However, for a complete picture, we decided to show another example of what dynamic import resolution mechanisms in malware can look like and how static analysis can turn a group of incomprehensible bytes into meaningful function names. This will help speed up the reverse engineering process and save us from having to manually annotate.

As an example, let’s look at one of the recent Formbook samples. Let it unpack, then dump it and open it in IDA Pro. After browsing through the functions, you can notice several patterns in the calls that closely resemble dynamic import resolution (screenshot 1).

❗️ It’s also worth noting that there are two hash decryption functions: decrypt_hash, which uses only the encrypted function hash, and decrypt_hash_xor, which has an additional parameter whose purpose will become clear later.

Let’s look inside both functions and see that the only difference between them is the approach to generating the key for RC4. The second parameter in decrypt_hash_xor is applied to a hardcoded key before calling the decryption function (screenshot 2).

Now we just need to understand what happens in the decrypt_rc4_buff, call, and we can write the decryptor. The contents of the function can be seen in screenshot 3.

The loops before and after the actual RC4 decryption boil down to sequential pairwise subtraction of adjacent bytes, first left to right, then right to left. The equivalent Python code is shown in screenshot 4.

🧤 The only thing left is to go through the references to these two functions and collect the arguments, then recover the original import names. To implement the first part, we’ll define a CallVisitor class and define the logic for saving the necessary call information in it (screenshot 5). This approach is more convenient than “manually” searching for arguments by reverse iterating over the instructions preceding the call, since arguments can often be obfuscated: scattered throughout the body of the calling function or computed immediately before the call.

To get the original function name from the hash, we’ll use the flare-ida utilities. Among other things, there’s already a sc_hashes.db database with precomputed hashes for standard libraries, which will allow us to quickly recover most of the imports. For libraries not in the database, you can generate hashes yourself using the script located alongside it (screenshot 6).

The result of the work can be seen in screenshot 7. More than 80% of the found functions were recovered right away.

😎 As expected, the recovered hashes were created by the crc32bzip2 algorithm, and they also appeared in earlier Formbook samples. Thus, we were able to quickly recover the imports in the sample under investigation, as well as understand the general approach to data encryption in Formbook, which significantly simplifies its analysis going forward.

#tip #reverse #malware
@ptescalator