Nymaim is mostly known worldwide as a downloader, although it seems they evolved from former versions, now having new functionalities to obtain data on the machine with no need to download a new payload. Some of the exported functionalities allow harvesting passwords and browsers data from the machine, hidden on the file system until communication occurs. Payloads downloaded from the C&C are not saved locally on the machine but instead are loaded dynamically to memory with a unique internal calling convention.

One of the signature features I noticed when I began analyzing the Nymaim payload were the novel anti-reverse engineering and obfuscation techniques. Frustrating the analyzer many different code pieces for the same function requires piecing them together in order to fully understand the code. Most of the code is heavily obfuscated using ‘spaghetti code’ methods but we’ll dive into that in a 1 (bit).

In addition to the already obfuscated code, the DGA (Domain generation algorithm) use quite an interesting technique to make sure it won’t be sink-holed easily, as well as further challenging analyzation.

In this blog, I will review the anti-reverse engineering techniques the malware authors implemented in the code, explain the unique DGA they made, and show different automation concepts to conquer the code and make the analyzer’s life a lot easier.

And so it begins…

In general, when I dive into a new malware, I begin with a set of goals or objectives I need to discover and understand such as the DGA mechanism of a malware, or analyzing the protocol and functionality. When I focus on the DGA for instance, while debugging, I expect the malware to hit (at some point) a DNS resolving function such as getaddrinfo, gethostbyname or any similar API. Unfortunately, Nymaim hit none of the expected DNS resolving APIs exported. Confused for a moment, I decided to try a breakpoint on the sendto function and indeed the breakpoint is hit. It is a crafted DNS request with a messed up Call Stack and a hardcoded dns server. I can’t conclude anything definitive, I have to find the caller to the sendto function manually. Following the RETs and JMPs I finally get to the function called the sendto function. But wait, it looks so weird! (Dramatic drumming…)

no way this is the sendto function!

So, it continues! Obfuscation is legit code protection

Let us examine the IDA snippet above (Fig. 1), while keeping in mind what the sendto function looks like:

WS2_32!sendto(SOCKET s,                        const char *buf,                        int len,                        int flags,                        const struct sockaddr *to,                        int tolen)

There are 6 arguments in total. After static analysis of the code, the arguments passed on the stack don’t make much sense in terms of what sendto is expecting (value wise). Also there are 9 push opcodes in total. Something fishy is going on in there. Let’s examine the last call function call sub_1805525 which is the OPCODE I returned to manually from the sendto function.
<SpoilerAlert>

This function is one of many spaghetti functions found in the code

</SpoilerAlert>

 

To fully comprehend what is going on, we will first have to understand how the stack would look after calling this function in terms of EBP offsets:

First of all pushing EAX (arg_8) and then two more DWORDS, arg_4 (0xCF260F5F) and arg_0 (0x30D8FC16).

Then calling the function (call sub_1805525) which will put the appropriate ret address as the last value on the stack and that’s all we need to know stack-wise for now when calling this function.

Then, inside the called function, the function’s prologue happens

push ebp
mov ebp, esp

This puts into the base register (EBP) the current stack address to relatively point to stack variables using EBP and not ESP. Let’s see what this function does exactly (As seen on the IDA snippet above):
(0) + (1) Overwrite arg_8 with the RetAddress, (2) + (3) sum the values of the two DWORDS pushed on the stack (arg_0 + arg_4), (4) the result from the last operation will be added to the arg_8 which was already overwritten with the RetAddress.
Basically it receives two numbers and a dummy stack value, 3 arguments in total. Resulting in a new return address with the value of [ReturnAddress + arg_0 + arg_4].
Xreferencing this whole mathematical function shows me it is being called from 36 m
ore places. There are dozens (!) more variants of this function and about 2600 different places in which all of the variants being called inside the code.
Back to analyzing, the new address should be:
[0x0183BF0B + 0x30D8FC16 + 0XCF260F5F], cutting the 32 bit part will result in [0x0182CA80]

Great success! The above snippet (Fig. 3) is another part of the obfuscation. The function that would be called next (sub_180D32D) is some API-Wrapper. Actually there are no standard API calls anywhere in the code, everything is calculated dynamically… everything. It’s terrible I know.

Diving into that API-Wrapper function is possible (and actually required for the most part). However I won’t do that in the scope of this blog post.

So this spaghetti calling convention messes up the code and I will have to fix it if I want to do any effective static analysis of it. Before I present the solution for this problem, however, Let’s examine the rest of the unresolved issues in the calling function to sendto.

The next thing we need to investigate, is the repeated function sub_183AC7E

I will make it easy, This is a huge switch-case of putting a register value on the stack dependent of the given value. For example, the following code (our sendto scenario):

seg000:0183BED7              push 10h
seg000:0183BED9              push 72h ; 'r'
seg000:0183BEDB              call sub_183AC7E
seg000:0183BEE0             push 6Fh ; 'o'
seg000:0183BEE2              call sub_183AC7E
seg000:0183BEE7              push 6Ch ; 'l'
seg000:0183BEE9              call sub_183AC7E
seg000:0183BEEE              push 73h ; 's'
seg000:0183BEF0             call   sub_183AC7E
seg000:0183BEF5              push dword ptr [ebp-184h]

Can be translated to

push 10h
push esi
push ebx
push eax
push edi
push dword ptr [ebp-184h]

Now i can peacfully say i know everything i need to de-obfuscate this sendto call (Well not everything, i did skip the API-Wrapper function, but everything besides that) With all this new information at hand, we can move on to the next part

Tomāto-Tomăto, Potāto-Potăto It’s all the same

The two problems i aim to solve, fixing that spaghetti code calling convention, and to fix the push_reg function. These two functions rule most of the code, so fixing these two should be a huge step forward in understanding the code and statically analyzing it.

So how is it done? Easy, Magic!

or in its unofficial name, IDA-Python, scripting an automation process to go over all of the code, wherever one of these functions occur, fix it and change it to a simpler and more readable code format while retaining the same functionality.

So let’s get practical shall we? Starting with the push_reg function

I need to change every call to that function, which is made up of two opcodes:

6A XX               push <BYTE>
E8 XX XX XX XX      call <DWORD>

Push and Call, which are both in total 7 bytes in memory. If I could replace these 7 bytes with the appropriate values of the Push <Register> and do it over all of the code, it will be a big step in de-obfuscating the code.

So now that I know exactly what I want to replace, I wrote a script which does exactly that:

PUSH_REGISTER_ADDR = 0x0183AC7E
PUSH_REG_VALUE = 0x6C
SIZEOF_PUSH_BYTE = 2
  
def fix_reg_push(function_address):
               patched_counter = 0
               unpatched_counter = 0
               values_to_patch = {PUSH_REG_VALUE : 0x50,        # push eax
                            PUSH_REG_VALUE + 1 : 0x51,      # push ecx
                            PUSH_REG_VALUE + 2 : 0x52,      # push edx
                            PUSH_REG_VALUE + 3 : 0x53,      # push ebx
                            PUSH_REG_VALUE + 5 : 0x55,      # push ebp
                            PUSH_REG_VALUE + 6 : 0x56,      # push esi
                            PUSH_REG_VALUE + 7 : 0x57,      # push edi}
  
            # Go through all xrefs
            for xcall in XrefsTo(function_address):
             
                            # Make code if is not already
                            opcode_length = idc.MakeCode(xcall.frm - SIZEOF_PUSH_BYTE)
                            if SIZEOF_PUSH_BYTE != opcode_length:
                                            print " [*] fix_reg_push not code [0x%08X]" % push_addr
                                            not_code_counter += 1
                                            continue
                                             
                            # Obtain previous opcode address
                            push_addr = idc.PrevHead(xcall.frm)
                             
                            # Sanity check 2
                            if "push" != GetMnem(push_addr):
                                            print " [*] fix_reg_push not push instruction [0x%08X]" % push_addr
                                            print GetMnem(push_addr)
                                            not_push_counter += 1
                                            continue
  
                            # Get new value
                            push_value = GetOperandValue(push_addr, 0)
                            byte_val = values_to_patch.get(push_value, None)
                            if None == byte_val:
                                            print " [*] fix_reg_push unexpected push value [0x%08X]" % push_addr
                                            bad_push_counter += 1
                                            continue
  
                            # Patch code
                            idaapi.patch_word(push_addr, 0x04EB) # EB 04 -> Jmp $+4...
                            idaapi.patch_long(push_addr + 2, 0x90909090) #
                        idaapi.patch_byte(push_addr + 6, byte_val)
  
                            patched_counter += 1
            print " [*] fix_reg_push - Total: [%d]\npatched functions: [%d]\nunpatched functions: [%d]" % (patched_counter + unpatched_counter, patched_counter, unpatched_counter)
  
             
def main():
            fix_reg_push(PUSH_REGISTER_ADDR)
  
if "__main__" == __name__:
            main()

The code above is separated into a couple of sections:

Calling my fix_reg_push function with the appropriate function address which handles the push register by value
Running through all the Xrefs of the function and making IDA identify the bytes as code if it hasn’t already. Otherwise there would be issues identifying opcodes later in the script
Making sure the xref is valid and working as expected. I don’t want to create any weird code patches so I make some necessary sanity checks
Patching the code, changing the 7 original bytes to PUSH <reg> and JMP <byte> for better code clarity.

Lets examine the before and after results:

Before	After

As you can see, I translated the reg_push functions (all of them) to a readable simple de-obfuscated push opcodes which have a length of one byte. I could have just done a NOP-slide for the rest of the bytes left, but I decided to implement a jmp opcode instead with the memory I had left to overwrite. It’s a matter of taste. The code became much more readable and now I can finally read which register represents which value on the stack. This function was fixed at over 3,900 places in the code. So it was definitely worth it.

And that’s it for the first part.

Patching the code on IDA made everything a lot more readable in terms of static analysis. Next, there is still that spaghetti calling convention I will have to fix, but as I investigated more of the code, I noticed there are dozens of variations with different calculations being made, and for each one of those, there are a dozen more duplications which look identical to each other. The only logical thing left for me to do, was to make a regex to find every matching function.

Fortunately finding the common base between all functions wasn’t so hard. All of them have more or less the same prologue, and pretty much the same epilogue. So creating some kind of byte regex to find all of them (and fix them!) isn’t very hard. So I’ve done just that.

After automatically finding all of these spaghetti functions, I will patch the code just as I have done with the ‘push_reg‘ functions. Only this time I have a lot more “space” in terms of bytes to do so

In total, there are 16 bytes, that I would like to change to just CALL (5 bytes), so I have enough space to override as I want. This method is practically the same as the method I used before. So there is no reason to put another code block to show how its done. Looking for all variants of these functions gave me a result of almost 100 different variations, with a total of approximately 3,000 different Xrefs in the code (for all variants).

The final result after patching both the spaghetti calling convention and the push registry by value: