Quick post: GlblcntUsage value

While I was checking a malware I stumbled on a piece of code using GlblcntUsage I have not seen before. GlblcntUsage is a member of MODULEENTRY32 structure and, according to MSDN, it’s defined as: “the load count of the module, which is not generally meaningful, and usually equal to 0xFFFF”. There’s a piece of code on Github written by Justin Seitz about the use of GlblcntUsage, it’s not the same sample code but it’s somehow related to the idea implemented inside the malware.

This is the scenario: the malware installs some API hooks using Martona’s hook library and, at a certain point it needs to un-hook one of them. The un-hook procedure is not directly called, the call depends on the value stored inside GlblcntUsage, here is the pseudo code:

void UnHook(hModule) {
   DWORD th32ProcessID;
   int countVal;
   
   th32ProcessID = GetCurrentProcessId();
   countVal = GetGlblcntUsageValueOfSpecificHModule(hModule, th32ProcessID);
   if (countVal != 1)
      return();
   
   /* Un-hook!!! */
}
int GetGlblcntUsageValueOfSpecificHModule(_hModule, _th32ProcessID) {
   MODULEENTRY32 me;
   HANDLE hSnap;
   uint _GlblcntUsage = 0;
   hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, _th32ProcessID);
   if (Module32First(hSnap, &me)) {
      while (me.hModule != _hModule) {
         if (!Module32Next(hSnap, &me) {
            CloseHandle(hSnap);
            return(_GlblcntUsage);
         }
      }
      _GlblcntUsage = me.GlblcntUsage;
   }
   CloseHandle(hSnap);
   return(_GlblcntUsage);
}

If the module has not been loaded the returned value is 0 otherwise it’s the content of GlblcntUsage variable. Un-hook takes place if and only if the returned count value from GetGlblcntUsageValueOfSpecificModule is exactly 1.

Another CTB-Locker related e-mail inside my junk box

While I was checking my junk e-mail folder I found something resembling a CTB-Locker e-mail type. The e-mail text is in italian language without typo errors. Opening the attachment inside a safe environment I recognize the same infection method, everything starts from the word file (this time in French language) executed by the exe file inside the attached Zip (Sha256: BF0ED6937D3B8A882FCB4EB9F22B5B69FB1ED4E35F2692BF3B7C8CFBD7266543). The only thing I haven’t seen before is the fact that the exe file is using .NET library. I decided to go deep a little bit more into the file analisys raw dumping the running malware at two random points. Applying Snippet Detector I got the next results for the two dumps:

[SNIPPET DETECTOR] Semantic match at 0x401C44
Snippet name: CTB_Locker__DecryptDownloadedExeFile
Snippet description: CTB-Locker::DecryptDownloadedExeFile decrypts the file downloaded from the net

[SNIPPET DETECTOR] Semantic match at 0x401CBF
Snippet name: CTB_Locker__ShowErrorAndExitProcess
Snippet description: CTB-Locker::ShowErrorAndProcessEnd is called when an error occurs. It format the error message, it shows it and then it terminates the malware

[SNIPPET DETECTOR] Semantic match at 0x401E90
Snippet name: CTB_Locker__CabinetCallback
Snippet description: CTB-Locker::CabinetCallback used to format the .rtf complete file path

[SNIPPET DETECTOR] Semantic match at 0x401F4B
Snippet name: CTB_Locker__MoveUnicodeString
Snippet description: CTB-Locker::MoveUnicodeString moves one unicode string into another buffer

[SNIPPET DETECTOR] Syntactic match at 0x40242D
Snippet name: CTB_Locker__ChecksumOverDecryptedExeFile
Snippet description: CTB-Locker::ChecksumOverDecryptedExeFile applies a checksum over a sequence of bytes

[SNIPPET DETECTOR] 1 syntactic snippet, 4 semantic snippet and 0 multiple matches has been found

[SNIPPET DETECTOR] Semantic match at 0xC58F
Snippet name: CTB_Locker__UnicodeStringCompare
Snippet description: CTB-Locker::UnicodeStringCompare

[SNIPPET DETECTOR] Semantic match at 0x1CDF3
Snippet name: CTB_Locker__AESDecrypt
Snippet description: CTB_Locker__AESDecrypt decrypts applying the AES algo.

[SNIPPET DETECTOR] Semantic match at 0x1F9B8
Snippet name: CTB_Locker__SHA256
Snippet description: CTB-Locker::SHA256 hash function

[SNIPPET DETECTOR] Semantic match at 0x2A5DA
Snippet name: CTB_Locker__AESEncrypt
Snippet description: CTB-Locker::AESEncrypt encrypts applying the AES algo.

[SNIPPET DETECTOR] Semantic match at 0x2CF31
Snippet name: CTB_Locker__AESEncryptExpandKey
Snippet description: CTB-Locker::AESEncryptExpandKey function used at the beginning of the AES encryption process

[SNIPPET DETECTOR] Semantic match at 0x33A0C
Snippet name: CTB_Locker__AESDecryptExpandKey
Snippet description: CTB-Locker::AESDecryptExpandKey function used at the beginning of the AES decryption process.

[SNIPPET DETECTOR] Semantic match at 0x43BD0
Snippet name: CTB_Locker__ZLibDecompress
Snippet description: CTB-Locker::ZLibDecompress

[SNIPPET DETECTOR] Semantic match at 0x683F7
Snippet name: CTB_Locker__Curve_25519
Snippet description: CTB-Locker::Curve_25519 crypto

[SNIPPET DETECTOR] Semantic match at 0x8D3F0
Snippet name: CTB_Locker__MoveExtensionsFileIntoSeparateBuffers
Snippet description: CTB-Locker::MoveExtensionsFileIntoSeparateBuffers

[SNIPPET DETECTOR] Syntactic match at 0x8D487
Snippet name: CTB_Locker__UnicodeStringAppend
Snippet description: CTB-Locker::UnicodeStringAppend

[SNIPPET DETECTOR] Semantic match at 0x8D4B0
Snippet name: CTB_Locker__GenSecretAndPublicKeys
Snippet description: CTB-Locker::GenSecretAndPublicKeys generates two distinct keys for a future use.

[SNIPPET DETECTOR] Semantic match at 0x8D5F0
Snippet name: CTB_Locker__CRCChecksum
Snippet description: CTB-Locker::CRCChecksum, crc checksum used by CTB-Locker

[SNIPPET DETECTOR] Semantic match at 0x8D624
Snippet name: CTB_Locker__GetMachineGUIDMultibyte
Snippet description: CTB_Locker__GetMachineGUIDMultibyte converts the machineGUID into multibyte

[SNIPPET DETECTOR] Semantic match at 0x8D876
Snippet name: CTB_Locker__TryToDecryptCandidateFile
Snippet description: CTB-Locker::TryToDecryptCandidateFile tries to decrypt a file using one of the available keys

[SNIPPET DETECTOR] Semantic match at 0x8D92C
Snippet name: CTB_Locker__DecryptWithPrivateKey
Snippet description: CTB-Locker::DecryptWithPrivateKey using elliptic curve, sha256, AES and ZLib decompression algo

[SNIPPET DETECTOR] Semantic match at 0x8DCD2
Snippet name: CTB_Locker__DetectVM
Snippet description: CTB_Locker__DetectVM tries to detect VM. Return 1 if VM is detected, 0 otherwise

[SNIPPET DETECTOR] Semantic match at 0x8E090
Snippet name: CTB_Locker__GetSytemFileProcessesVMInfo
Snippet description: CTB-Locker::GetSytemFileProcessesVMInfo performs some checks over the malware file, the system and the VM

[SNIPPET DETECTOR] Semantic match at 0x8E32E
Snippet name: CTB_Locker__CreateInitialPartOfHIDDENINFO
Snippet description: CTB-Locker::CreateInitialPartOfHIDDENINFO create the initial part of the HiddenInfo file

[SNIPPET DETECTOR] Semantic match at 0x8E567
Snippet name: CTB_Locker__RenderTextOverButton
Snippet description: CTB_Locker__RenderTextOverButton writes a specific text over the dialog button

[SNIPPET DETECTOR] Semantic match at 0x8E85C
Snippet name: CTB_Locker__RenderInfoTextOnTheDialog
Snippet description: CTB-Locker::RenderInfoTextOnTheDialog

[SNIPPET DETECTOR] Semantic match at 0x8EE52
Snippet name: CTB_Locker__RenderGUIDialog
Snippet description: CTB-Locker::RenderGUIDialog

[SNIPPET DETECTOR] Semantic match at 0x8F28D
Snippet name: CTB_Locker__ShowCTBLockerDialogWindow
Snippet description: CTB-Locker::ShowCTBLockerDialogWindow shows one of the CTB-Locker dialogs

[SNIPPET DETECTOR] Syntactic match at 0x8F3AA
Snippet name: CTB_Locker__CreateRandomSevenCharsUnicodeStringFromDwordValue
Snippet description: CTB-Locker::CreateRandomSevenCharsUnicodeStringFromDwordValue

[SNIPPET DETECTOR] Semantic match at 0x8F3D0
Snippet name: CTB_Locker__ParseResponseFromServer
Snippet description: CTB_Locker__ParseResponseFromServer parses the reply obtained from the server

[SNIPPET DETECTOR] Semantic match at 0x90455
Snippet name: CTB_Locker__DecryptHiddenInfoFile
Snippet description: CTB-Locker::DecryptHiddenInfoFile decrypts the HiddenInfo file

[SNIPPET DETECTOR] Semantic match at 0x904D7
Snippet name: CTB_Locker__DecryptHiddenInfo
Snippet description: CTB-Locker::DecryptHiddenInfo, HiddenInfo file decryption routine

[SNIPPET DETECTOR] Semantic match at 0x9054E
Snippet name: CTB_Locker__EncryptHiddenInfo
Snippet description: CTB-Locker::EncryptHiddenInfo using AES

[SNIPPET DETECTOR] Semantic match at 0x91156
Snippet name: CTB_Locker__CreateBitmapImage
Snippet description: CTB-Locker::CreateBitmapImage creates a bitmap image

[SNIPPET DETECTOR] Semantic match at 0x9354B
Snippet name: CTB_Locker__IsProcessUnderWow64Process
Snippet description: CTB_Locker__IsProcessUnderWow64Process checks to see if the process runs under Wow64Process or not

[SNIPPET DETECTOR] Semantic match at 0x93594
Snippet name: CTB_Locker__Injection
Snippet description: CTB-Locker::Injection function

[SNIPPET DETECTOR] Semantic match at 0x9363F
Snippet name: CTB_Locker_SearchProcessToInjectCodeAndInject
Snippet description: CTB-Locker::SearchProcessToInjectCodeAndInject search the right process for the code injection

[SNIPPET DETECTOR] Semantic match at 0x93D38
Snippet name: CTB_Locker__SearchStringInsideList
Snippet description: CTB-Locker::SearchStringInsideList searches for a specific string inside a list

[SNIPPET DETECTOR] Semantic match at 0xDD450
Snippet name: CTB_Locker__MemoryClear
Snippet description: CTB-Locker::MemoryClear

[SNIPPET DETECTOR] 2 syntactic snippet, 31 semantic snippet and 0 multiple matches has been found

Well, seems like nothing has changed inside the core of the malware. I can stop my analysis.

You can download the CTB-Locker local database for Snippet Detector here and try yourself.

Snippet Detector

One year ago I blogged about a tool of mine I use to recognize snippets from a disassembled binary file. The tool often speeds up my dead list analysis process. The annoying thing is that it works in cooperation with IDA, and it’s somehow a waste of time because I have to switch from one program to another and vice versa a lot of time. Since of IDA is the most used disassembler program out there I decided to morph my project into an IDA Python scripts project.

The project is called Snippet Detector (SD in short), and the aim is to collect as many disassembled snippets as I can. At the moment a snippet is indeed a defined function and it’s everything saved inside a database. The info inside the database can be later applied to a new disassembled file hoping to find one or more matches.

My idea is to exchange the saved information about a malware (or a generic disassembled file) with someone else in an easy way. Suppose I put on the net my local SD database of Zeus malware, it’s available for everyone and you can use it as a local database increasing your possibility to reduce the analysis time facing a new malware born from Zeus source code. You can even use my database to understand obscure parts of the malware itself, just like a new form of a didactical approach. At last, but not least, it could be helpful when a group of people need to work on the same target because you can pass your findings to your collegue making the reversing session a little bit faster than usual.

The database
There are basically two databases, a global and a local database. The global db is used to store all the snippets you collected during your analysis sessions. The local db is generally used to store some snippets only. Why do I need two databases? You are not obliged to use both, you can work with one, another or both databases as you prefer. The idea is to have a global database with all the snippets you have added, and a local with snippets from the current disassembled file only.

Global and local databases are implemented as SQlite db. Global db is unique and it’s stored inside SD folder; a local db is unique for a single disassembled file and it’s located inside the disassembled file folder (under “SD_local_DB” name). Inside you hard disk you will have one global db and one or more local dbs.

Syntactic and semantic matching
The check is done in two different levels: syntactic and semantic. The syntactic matching is obvious, two instructions are identical if and only if they have the same bytes; apply this method to a series of instructions and you’ll have the definition of a syntactic matching on snippets of code. The idea behind the semantic matching is easy to understand, but it needs a little introduction. Suppose to have:

C7 45 F8 38 5B 41 00   mov  dword ptr [ebp-8],  415B38h
C7 45 F4 34 12 40 00   mov  dword ptr [ebp-0C], 401234h

Two mov instructions with different bytes definition, but both of them are used to move a dword value into a dword in memory. The idea is to convert every instruction of the snippet into another one without changing the semantic meaning of it. The conversion is simply done removing the operand(s). After the conversion I’ll get something like that:

C7 45   mov  dword ptr [ebp-byte_val], dword_val
C7 45   mov  dword ptr [ebp-byte_val], dword_val

In their simplified form the two instructions are semantically identical.

This is exactly the core of my idea, if the meaning of two instructions is the same (syntactic or semantic) I could say they are used for the same thing. Applying these facts to a series of instructions I came up with the idea of this tool.

Python scripts
The pack contains eight files, but only some of them are directly executed as an IDA Python script:

• SD_AddSnippet.py: add a new snippet to the database. You decide to save the snippet inside the local or global database. The global database is located inside the script folder, the local database is inside the disassembled file folder. It saves the next informations:
  – snippet name: directly taken from the name of the function
  – snippet description: taken from the comment (if there’s one) of the function
  – syntactic bytes sequence
  – semantic bytes sequence
  – snippet comments: all the comments of the instructions
• SD_DeleteSnippet.py: delete a snippet from the local or global database
• SD_UpdateSnippet.py: update information of an already saved snippet. It’s possible to update the name/description/comments
• SD_IdentifyOneSnippet.py: try to identify one snippet only
• SD_IdentifySnippets.py: try to identify all the snippets of the disassembled file. It scans all the functions inside the currently disassembled file trying to find a possible match in the local/global database (syntactic/semantic match)

The next files are used by the previous ones:

• SD_db.py: class used to define all SQlite related operations needed by Snippet Detector scripts
• SD_Common.py: common functions definition class
• SD_Semantic.py: semantic related stuff

Installation
Snippet Detector is available at GitHub page. To install Snippet Detector, just copy every .py file inside your preferred folder.

Practical example
Here is a brief explanation of Snippet Detector in practice. Look inside ‘Test sample’ folder, I have created a simple and minimal local database with few snippets from Zeus malware (hash: 70c1be0e03046d03c02d1ffc4a858653, pwd is ‘infected’). There are only 10 saved snippets taken from various parts of the file:

    Core::initOSBasic
    Core::GetPeSettingsPath
    Crypt::crc32Hash
    Fs::_pathCombine
    MalwareTools::_getOsGuid
    MalwareTools::_generateKernelObjectName
    Process::_getUserByProcessHandle
    Registry::_setValueAsBinary
    Wahook::checkAvalibleBytes
    WinSecurity::_getUserByToken

To save a snippet is really simple, once you have completed the analysis of the function, point the cursor inside one of the instructions of the function and run SD_AddSnippet.py script. Select local or global database, nothing else.
Now, suppose you need to analyze Kins malware (hash: 7b5ac02e80029ac05f04fa5881a911b2, pwd is ‘infected’), it’s now obvious that there are some correspondences between the two malwares, but in the past it was not so obvious. Anyway, put SD_local_DB folder inside the Kins folder; now, you can run SD_IdentifySnippets.py hoping to find some matches (don’t forget to use the local database). Once the script has been totally executed you’ll see the report of the operation:

[SNIPPET DETECTOR] Semantic match at 0x407711
Snippet name: core_initOsBasic
Snippet description: static bool __inline initOsBasic(DWORD flags)

[SNIPPET DETECTOR] Semantic match at 0x41A7DB
Snippet name: Crypt_crc32Hash
Snippet description: DWORD Crypt::crc32Hash(const void *data, DWORD size)

[SNIPPET DETECTOR] Semantic match at 0x41AA43
Snippet name: Process__getUserByProcessHandle
Snippet description: TOKEN_USER *Process::_getUserByProcessHandle(HANDLE process, LPDWORD sessionId)

[SNIPPET DETECTOR] Semantic match at 0x41CAAE
Snippet name: WinSecurity__getUserByToken
Snippet description: TOKEN_USER *WinSecurity::_getUserByToken(HANDLE token)

[SNIPPET DETECTOR] Semantic match at 0x41D630
Snippet name: Registry__setValueAsBinary
Snippet description: bool Registry::_setValueAsBinary(HKEY key, const LPWSTR subKey, const LPWSTR value, DWORD type, const void *buffer, DWORD bufferSize)

[SNIPPET DETECTOR] Semantic match at 0x41DBA1
Snippet name: wahook_checkAvalibleBytes
Snippet description: static DWORD_PTR checkAvalibleBytes(HANDLE process, void *address)

[SNIPPET DETECTOR] Semantic match at 0x41EC8D
Snippet name: Fs__pathCombine
Snippet description: bool Fs::_pathCombine(LPWSTR dest, const LPWSTR dir, const LPWSTR file)

[SNIPPET DETECTOR] 0 syntactic snippet, 7 semantic snippet and 0 multiple matches has been found

SD is able to semantically identify 7 of 10 functions (it’s quite hard to find a syntactic match, you should know why…), and you can now start checking the file with a little initial help. I have also added a ‘multiple matches’ voice in case there’s a semantic corrispondence with more than one saved snippet. In this case you can decide what’s the best snippet to apply running SD_IdentifyOneSnippet.py script.

In the end
Snippet Detector is in early beta version, and I’m planning to add some more features in the future. Feel free to report bugs/comments/criticisms directly to my mail address.

CTB-Locker encryption/decryption scheme in details

After my last post about CTB-Locker I received a lot of e-mails from people asking for a complete analysis of the malware. Most of them wanted to know if it’s possible to restore the compromised files without paying the ransom. The answer is simple: it’s impossible without knowing the Master key! That key resides on the malicious server and it’s the only way to restore every single compromised file.

There are a some articles on the net about CTB-Locker’s modus-operandi. Everyone knows that ZLib is used, AES is used but only few of them mention the use of SHA256+Curve. To explain everything in details I’ll show you how encryption/decryption is done, step by step.

Preamble: HIDDENINFO
HiddenInfo file is the core of the malware, it’s full of precious data. There’s no need to explain every field of the file, a closer look at the first part of it would suffice because it has an important part in the encryption/decryption scheme.

DCE1C1   call    ds:CryptGenRandom
DCE1C7   lea     eax, [ebp+systemTimeAsFileTime]
DCE1CA   push    eax
DCE1CB   call    ds:GetSystemTimeAsFileTime
DCE1D1   call    ds:GetTickCount
DCE1D7   mov     [ebp+gettickcountVal], eax
DCE1DA   call    ds:GetCurrentThreadId
DCE1E0   mov     esi, eax         
DCE1E2   rol     esi, 10h                      ; Shift ThreadID
DCE1E5   call    ds:GetCurrentProcessId 
DCE1EB   xor     eax, esi                      ; ThreadID and ProcessID values inside the same dword
DCE1ED   mov     [ebp+threadID_processID], eax
DCE1F0   mov     esi, 0EB7910h
DCE1F5   lea     edi, [ebp+machineGuid]
DCE1F8   movsd                                 ; Move MachineGUID
DCE1F9   movsd
DCE1FA   movsd
DCE1FB   lea     eax, [ebp+random]             ; Random sequence of bytes
DCE1FE   push    34h                           ; Number of bytes to hash
DCE200   push    eax                           ; Sequence of bytes to hash
DCE201   mov     ecx, ebx                      ; Output buffer
DCE203   movsd
DCE204   call    SHA256                        ; SHA256(random)
DCE209   mov     al, [ebx+1Fh]
DCE20C   and     byte ptr [ebx], 0F8h
DCE20F   push    0E98718h                      ; Basepoint
DCE214   and     al, 3Fh
DCE216   push    ebx                           ; SHA256(random)
DCE217   push    [ebp+outputBuffer]            ; Public key
DCE21A   or      al, 40h
DCE21C   mov     [ebx+1Fh], al
DCE21F   call    curve_25519     

The snippet is part of a procedure I called GenSecretAndPublicKeys. The secret key is obtained applying SHA256 to a random sequence of 0x34 bytes composed by:

   0x14 bytes: from CryptGenRandom function
   0x08 bytes: from GetSystemTimeAsFileTime
   0x04 bytes: from GetTickCount
   0x04 bytes: from (ThreadID ^ ProcessID)
   0x10 bytes: MachineGuid

Curve25519 is used to generate the corresponding public key. You can recognize the algo from Basepoint vector because it’s a 0x09 byte followed by a series of 0x00 bytes (For a quick overview over the Elliptic curve algorithm used by the malware take a look here: http://cr.yp.to/ecdh.html).
GenSecretAndPublicKeys is called two times, so two private and two public keys are created. I name them as ASecret, APublic, BSecret and BPublic.

DCF1E7   mov     [esp+274h+public], offset MasterPublic   ; MPublic key
DCF1EE   push    eax                                      ; BSecret
DCF1EF   lea     eax, [ebp+Shared_1]                      ; Shared_1
DCF1F5   push    eax                                              
DCF1F6   call    curve_25519     
DCF1FB   add     esp, 0Ch
DCF1FE   lea     eax, [ebp+Shared_1]
DCF204   push    20h                                               
DCF206   push    eax                                               
DCF207   lea     ecx, [ebp+aesKey]                        ; Hash is saved here
DCF20A   call    SHA256

SHA256(curve_25519(Shared_1, BSecret, MPublic))
Shared secret computation takes place. MPublic is the Master public key and it’s visible inside the memory address space of the malware. The Master secret key remains on the malicious server. To locate the Master public key is pretty easy because it’s between the information section (sequence of info in various languages) and the “.onion” address. Shared secret is then putted inside SHA256 hash algorithm, and the result is used as a key for AES encryption:

DCF20F   lea     eax, [ebp+aesExpandedKey]
DCF215   push    eax
DCF216   mov     edx, 100h
DCF21B   lea     ecx, [ebp+aesKey]
DCF21E   call    AEXExpandKey
DCF223   add     esp, 0Ch
DCF226   xor     edi, edi
DCF228   lea     ecx, [ebp+aesExpandedKey]
DCF22E   lea     eax, [edi+0EF71ACh]
DCF234   push    ecx
DCF235   push    eax
DCF236   push    eax
DCF237   call    AES_ENCRYPT     ; AES encryption

The malware encrypts a block of bytes (named SecretInfo) composed by:

SecretInfo:
   ASecret              ; a secret key generated by GenSecretAndPublicKeys
   MachineGuid          ; Used to identify the infected machine
   Various information (fixed value, checksum val among others)

Not so hard but it’s better to outline everything:

     ASecret = SHA256(0x34_random_bytes)
     Curve_25519(APublic, ASecret, BasePoint)
     BSecret = SHA256(0x34_random_bytes)
     Curve_25519(BPublic, BSecret, BasePoint)
     Curve_25519(Shared_1, BSecret, MPublic)
     AES_KEY_1 = SHA256(Shared_1)
     Encrypted_SecretInfo = AES_ENCRYPT(SecretInfo, AES_KEY_1)

Part of these informations are saved inside HiddenInfo file, more precisely at the beginning of it:

HiddenInfo:
   +0x00 offset: APublic
   +0x24 offset: BPublic
   +0x44 offset: Encrypted_SecretInfo

So, two public keys are visible, but private key ASecret is encrypted. It’s impossible to get the real ASecret value without the AES key…
Ok, now that you know how HiddenInfo file is created I can start with the file encryption scheme.

CTB-Locker file encryption

C74834   lea     eax, [ebp+50h+var_124]   ; Hash will be saved here
C7483A   push    eax             
C7483B   lea     eax, [ebp+50h+var_E4]
C74841   push    30h             
C74843   lea     edi, [ebp+50h+var_D4]
C74849   push    eax                      ; 0x30 random bytes
C7484A   rep movsd               
C7484C   call    SHA256Hash
   ...
C7486E   push    eax                      ; BasePoint
C7486F   lea     eax, [ebp+50h+var_124]
C74875   push    eax                      ; CSecret: SHA256(0x30_random_bytes)
C74876   lea     eax, [ebp+50h+var_B4]
C74879   push    eax                      ; CPublic
C7487A   call    curve25519               ; Generate a public key
C7487F   push    offset dword_C943B8      ; DPublic: first 32 bytes of HiddenInfo (*)
C74884   lea     eax, [ebp+50h+var_124]
C7488A   push    eax                      ; CSecret
C7488B   lea     eax, [ebp+50h+var_164]
C74891   push    eax                      ; Shared_2
C74892   call    curve25519               ; Generate shared secret
C74897   lea     eax, [ebp+50h+var_144]
C7489D   push    eax
C7489E   lea     eax, [ebp+50h+var_164]
C748A4   push    20h
C748A6   push    eax                      ; Shared_2
C748A7   call    SHA256Hash               ; SHA256(Shared_2)
   ...
C74955   push    34h
C74957   push    [ebp+50h+var_18]         ; Compression level: 3
C7495A   lea     eax, [ebp+50h+PointerToFileToEncrypt]
C7495D   push    eax                      ; Original file bytes to compress
C7495E   call    ZLibCompress    
   ...
C74B1F   push    [ebp+50h+var_4]
C74B22   lea     ecx, [ebp+50h+expandedKey]   ; SHA256(Share_2) is used as key
C74B28   push    [ebp+50h+var_4]
C74B2B   call    AES_Encrypt                  ; It encrypts 16 bytes per round starting from the first 16 bytes of the ZLib compressed file
C74B30   add     [ebp+50h+var_4], 10h 
C74B34   dec     ebx                          ; Decrease the pointer to the bytes to encrypt
C74B35   jnz     short loc_C74B1F             ; Jump up and encrypt the next 16 bytes

It’s quite easy indeed, it uses the same functions (SHA256, Curve, AES). To understand what’s going on you only have to follow the code. The operations sequence is:

     CSecret = SHA256(0x30_random_bytes)
     Curve_25519(CPublic, CSecret, BasePoint)
     Curve_15519(Shared_2, CSecret, APublic) (*)
     AES_KEY_2 = SHA256(Shared_2)
     ZLibFile = ZLibCompress(OriginalFile)
     Encrypted_File = AES_Encrypt(ZLibFile, AES_KEY2)

(*) DPublic inside the disassembled code is indeed APublic (first 32 bytes of HiddenInfo)

That’s the way how CTB-Locker encrypts the bytes of the orginal file. These bytes are saved into the new compromised file with some more data. A typical compromised file has the next structure:

   +0x00 offset: CPublic
   +0x20 offset: AES_Encrypt(InfoVector, AES_KEY_2)
   +0x30 offset: AES_Encrypt(ZLibFile, AES_KEY2)

InfoVector is a sequence of 16 bytes with the first four equals to “CTB1”, this tag word is used to check the correctness of the key provided by the server during the decryption routine.
The decryption demonstration feature, implemented by the malware to prove that it can restore the file, uses
AES_KEY_2 directly. If you remember the key was saved inside HiddenInfo, there are a total of five saved keys.
In this case if you have CSecret you can easily follow the process described above (remember that APublic comes from the first 32 bytes of HiddenInfo), but without CSecret it’s impossible to restore the original files.

It’s important to note that in the encryption process CTB-Locker doesn’t need an open internet connection. It doesn’t send keys/data to the server, it simply encrypts everything! Internet connection is needed in the decryption part only.

CTB-Locker file decryption
At some point, before the real decryption process, there’s a data exchange between the infected machine and the malicious server. The malware sends a block of bytes (taken from HiddenInfo) to the server and the server replies sending back the unique decryption key. The block is composed by the BPublic key, SecretInfo and some minor things:

DataToServer:
   32 bytes: BPublic
   90 bytes: SecretInfo
   16 bytes: general info

The malware uses the key to restore the files. Do you remember the decryption part from my last post? Well, the real decryption scheme is not so different. There’s one more step, the calculation of the AES key. To do that the unique key sent by the server is used to decrypt every file:

     curve_25519(Shared, Unique_Key, first_0x20_byte_from_compromised_file)
     AES_DECRYPTION_KEY = SHA256(Shared)
     ZLibFile = AES_Decrypt(Encrypted_File, AES_DECRYPTION_KEY)
     OriginalFile = ZLibDecompress(ZLibFile)

The unique key is sent just one time, so the decryption method needs only one key to decrypt all the compromised files. How is it possible?

My explanation
From HiddenInfo part I have:
     Curve_25519(APublic, Asecret, BasePoint)
     Curve_25519(BPublic, BSecret, BasePoint)
     Curve_25519(Shared_1, BSecret, MPublic)
     AES_KEY_1 = SHA256(Shared_1)
     Encrypted_SecretInfo = AES_ENCRYPT(SecretInfo, AES_KEY_1)

The server receives DataToServer and it applies the principle of elliptic curve:

     Curve_25519(Shared_1, MSecret, BPublic)

Shared_1 from the server is equal to Shared_1 calculated in the HiddenInfo creation part.
Now, with Shared_1 it AES decrypts SecretInfo obtaining ASecret key. ASecret is the key used to decrypt all the compromised files.

From Encryption part:
     Curve_25519(CPublic, CSecret, BasePoint)
     Curve_15519(Shared_2, CSecret, APublic)
     AES_KEY_2 = SHA256(Shared_2)
     ZLibFile = ZLibCompress(OriginalFile)
     Encrypted_File = AES_Encrypt(ZLibFile, AES_KEY_2)

Saying that, here is how to use ASecret in the decryption process (applying the same EC principle):
     Curve_25519(Shared_2, ASecret, CPublic)
     AES_KEY_2 = SHA256(Shared_2)
     ZLibFile = AES_Decrypt(Encrypted_File, AES_KEY_2)
     OriginalFile =ZLibDecompress(ZLibFile)

So, ASecret is the Unique_Key computed by the server and it’s used to decrypt every file. That means one thing only, without MSecret you can’t restore your original files…

Final thoughts
There’s nothing much to say really. CTB-Locker is dangerous and it will damage systems until people will do double-click over attachments.. sad but true.

Feel free to contact me for comments, criticisms, suggestions, etcetc!

CTB-Locker: files decryption demonstration feature

The idea of this blog post was born after reading an italian article about CTB-Locker. I don’t remember where I read it, but a single phrase caught my attention. It sounds like: “the malware proves that it’s able to decrypt some files, so the keys are saved somewhere”. I received a CTB-Locker sample on my personal mail box, so I decided to give it a try, just to satisfy my curiosity.
The post is based on a reversing session over a single file (810d51f6a5b4f8396ecf9407e427b999b316ecc28d53a759401143442b1a5cf8), but I think you can apply the general scheme to another sample of the same family.

Basically, all the information required by the malware are saved inside two distinct files: HelpFile and HiddenInfo. You won’t find these two files on an infected machine because these are confidential names I used while I was reversing the malware, the real names are generated following a precise scheme. To understand how the real names are generated I have to introduce the very first crypto scheme used by the malware, this is very important for the entire encryption/decryption process.

Everything starts from the value of the key:
HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid
The malware removes ‘–‘, converting everything into a sequence of 32 bytes (i.e. “463109ab-151a-463a-348e-79bbc9369cbd” becomes b’\x46\x31\x09\xab\x15\x1a\x46\x3a\x34\x8e\x79\xbb\xc9\x36\x9c\xbd’). Then SHA256 is applied:
CoreHash = SHA256(converted_MachineGUID)

CoreHash is composed by 8 dwords and each one of them is used for a specific job, for this blog post I’ll focus on the first and fourth dwords.

The HelpFile real name is constructed calling the next function with the CoreHash’s fourth dword as input:

Random file name generation

The real name is 7 bytes long and every single char is built after two simple math operations. HelpFile has “.html” extension and it’s used to show ransom info to the infected user, it’s just like a *FAQ* page on how to restore all the compromised files. The message is available in four languages: de, it, nl and en.

FAQ

This is the it version, but you can easily identify the server addresses, the tor access and the public keys. The last part of the file contains the list of the compromised files. Well… interesting but the keys I was searching for are not here!

The real name of HiddenInfo is obtained in the same way, but this time the parameter passed to the routine is the first dword of CoreHash. The file is without extension, it’s an hidden file and there are 0x28E meaningless bytes inside.
HiddenInfo is very important and it has a specific format, but everything is visible after a quite simple decryption process.

The malware uses AES:

DD1163 mov ecx, 0EF93F8h            ; Decryption key: CoreHash
DD1168 call AESExpandKey
...
DD1181 lea edi, [esi+27Eh]          ; Decryption starts from block at offset 0x27E
DD1187 Decrypt_32_bytes_block:
DD1187 lea eax, [ebp+expandedKey]   
DD118D push eax
DD118E push edi                     ; Block to decrypt
DD118F push edi                     ; Output buffer (bytes are replaced)
DD1190 call AESDecrypt
DD1195 add esp, 0Ch
DD1198 dec [ebp+arg_0]              ; initial value is 0x27E
DD119B dec edi                      ; Update the pointer to the block to decrypt
DD119C cmp [ebp+arg_0], 0
DD11A0 jge Decrypt_32_bytes_block

I told you it’s simple.
This file is important for the malware, and to be sure of its integrity the malware uses a checksum algo over the first 0x28C decrypted bytes:

DD11A2 push 28Ch                    ; Number of bytes used for the checksum
DD11A7 mov ecx, esi                 ; Sequence of 0x28E decrypted bytes
DD11A9 call Checksum                ; ax gets the final value
DD11AE pop ecx
DD11AF pop edi
DD11B0 cmp [esi+28Ch], ax           ; Is checksum ok?
DD11B7 jnz short corrupted_file

The value from the last two bytes of HiddenInfo is the valid checksum value, it was calculated during the encryption process. If the checksum is ok, at the end of the procedure you have the clean and readable HiddenInfo file. It’s full of hidden info, but in this case I’m interested in a minor part of the file only. Let’s start with this interesting block of 160 bytes:

5 keys in sequence

What’s behind the selected bytes starting from 0xEC offset? It’s the sequence of 5 keys used by the malware in the demonstration process to correctly decrypt 5 files. I have 5 keys and nothing else, the malware doesn’t specify the name of the files associated to the defined keys. To get the list of the 5 files I had to reverse the malware a little bit more, look here:

Decrypt candidate file

The idea is simple: it tries to apply the keys to every single compromised file. It stops the process when all the right candidate files are found. The malware has a complete list of the compromised files. How does he know what’s the right key?

Check decrypted candidate

As you can see, in order to pass the *key test*, the malware decrypts a little part of the candidate file only (bytes from 0x20 to 0x2F offset). The resulting 16 bytes of a valid candidate are:
4 bytes: unique string “CTB1”, it’s the same for every compromised file
4 bytes: number of bytes of the original file
4 bytes: number of bytes of the compromised file
4 bytes: fixed value 1
The first and last dword are used in the key check. In the end of all, there are two simple checks to get the connection between a candidate file and his key.

Now that the key has been found the malware is ready to restore the original file. This is done in two distinct steps, and it involves the entire file except the first initial 0x30 bytes.

DCE780 mov [ebp+var_8], eax
DCE783 decrypt_next_block: 
DCE783 lea eax, [ebp+expandedKey]
DCE789 push eax
DCE78A push [ebp+var_4]             ; Buffer of 16 bytes to decrypt 
DCE78D push [ebp+var_4]             ; Save the result in the same buffer
DCE790 call AESDecrypt              ; Decrypt the current block
DCE795 add [ebp+var_4], 10h         ; Switch to the next block
DCE799 add esp, 0Ch
DCE79C dec [ebp+var_8]              ; Update the number of block to decrypt
DCE79F jnz short decrypt_next_block

Decryption is done in blocks of 32 bytes (16 from the file and 16 equals to 0x00). The last step consists in a Zlib decompression (the compression is done with level 3).
Now you have your original file back.

Conclusion: the CTB-Locker demonstration process works with some files only and the keys are all hardcoded inside HiddenInfo file, it’s impossible to restore other files following this method.

Curiosity satisfied, see you soon!

Nullcon HackIM 2015: Forensics 500 writeup

To complete the level I have to find the size of a pagefile stored inside a 4Gb file.

First of all I tried to understand what kind of file is this:

python filehunter.py -l Image

ELF at the beginning, FileHunter reveals some more info about it:

python filehunter.py -d 0 ELF Image

Hmm, the type of the first three entries is ok but the last one seems to be odd. What’s ‘pmem’?
Looking at the start offset I hoped to find a familiar header:

python filehunter.py -sb 0x7ff7e120 Image

WinPMEM was used to dump memory, this tool can also acquire pagefile and it’s included inside Rekall Memory Forensic Framework. To get the right answer for this forensics level I used Rekall:

rekal.exe -f Image / pagefiles

‘-f’ option is used to load the image file. Once the file has been loaded I tried the ‘pagefiles’ command. Rekall is able to show the size of the pagefile: 2146951168

Flag is: flag{2146951168}

PS. look at the end of the Image file, there’s another pmem header showing the answer. 500 points in few seconds… easy money!

# PMEM
---
PreviousHeader: 0x7ff7e120
PagefileOffset: 0x7ff7e1f5
PagefileSize: 0x7ff7e000

Solution to Kirjava crackme#3: a simple virtual machine

Here’s my solution to a nice crackme, not so hard but enjoyable. The crackme rules are simple:
1. No patching!
2. A valid solution has a keygen and a tutorial!
Extra info: just a very simple algo with some anti-analysis tricks

The crackme is not packed/protected, I decided to start looking at the disasm output.
GetDlgItemTextA function is used to read both name and serial. Once the checks over name and serial are passed (strlen(name) > 4, strlen(serial) == 8) you’ll face the next snippet:

403ED0 nop
403ED1 mov ecx, dword_40ADB0
403ED7 call 4033A0
403EDC test eax, eax
403EDE jz short loc_403ED0
403EE0 mov ecx, dword_40ADB0
403EE6 cmp dword ptr [ecx+4], 0FFh
403EED mov esi, ecx
403EEF jnz short loc_403F19
...
Show congratulation box
...
403F16 retn 10h
403F19
...
Show error notification box
...
403F3E retn 10h

It’s obvious, first of all I have to understand what’s the content of the procedure at 0x4033A0 address is. The procedure’s code is really long but a trained eye understands immediately what’s behind everything. Why? Mainly because there’s a big switch, and there are a lot of snippets with common things like “esi+0C”, “esi+438”, “add ecx, value”. When I face this kind of algorithm I always start trying to verify if it’s an implementation of a Virtual Machine or not. I could be wrong but most of the time VM protections are easily identificable. To verify the correctness of my assumption is quite easy, a glance to the snippets used to implement VM instructions is enough.

(0x00: nop):
403A45 nop
403A46 add [esi+438h], ebx   <-- update eip by 1
403A4C pop edi
403A4D pop esi
403A4E xor eax, eax
403A50 pop ebx
403A51 retn

This is the first snippet I checked, it only adds one to the dword pointed by esi+0x438. That’s a nop, almost every VM has a nop instruction.
Let’s take a look to another snippet:

(0x61: mov reg_i, dword_val):
4036F4 mov ecx, esi
4036F6 call loc_403360
4036FB test al, al
4036FD jz loc_40342F
403703 mov eax, [esi+438h]   <-- eip
403709 movzx edx, byte ptr [eax+1]   <-- register index
40370D mov eax, [eax+2]   <-- dword value
403710 mov [esi+edx*4+0Ch], eax   <-- save the value inside register
403714 add dword ptr [esi+438h], 6   <--- update eip
40371B pop edi
40371C pop esi
40371D xor eax, eax
40371F pop ebx
403720 retn

The snippet is used to move a dword value inside a register. The instruction has two parameters, the register index and the value to move.
As you can see it’s really easy to understand every single snippet with a possible VM implementation in mind.

The VM implemented inside the crackme is simple:
eip is stored at [esi+0x438]
flag is stored at [esi+0x42]
there are 8 dword registers stored from [esi+0xc] to [esi+0x28]
starting from [esi+0x2c] there’s a private memory buffer

It’s all quite easy except the memory buffer that needs some more details. The memory buffer used by the VM contains data that are not stored in a sequential way. What does it mean? Think of a memory buffer like a dword sequence where each bytes inside a dword has a specific meaning:
1° byte: is used to store the username’s chars
2° byte: is used to store the right_serial’s chars
3° byte: is used to store the fake serial’s chars
4° byte: you can live without knowing its meaning
So, an hypotetical piece of memory could be:

[esi+0x2c]: 5A 59 31 00   61 69 32 00   69 59 33 00 ...

where you can clearly see part of the username (“Zai”), part of the right serial (“YiY”) and part of the fake serial (“123”).
How does the crackme read a specific byte from the username, or the serial? The memory is addressed by a dword at [esi+0x42c], each byte of the dword is used as an index position of a specific byte of the username/right serial/fake serial.
i.e.: [esi+0x42c] = 02 00 01 00 means that the next operation over the:
– username will be done with the 1° byte of the 3° dword of the memory buffer (char ‘i’ of “Zai”)
– right serial will be done with the 2° byte of the 1° dword of the memory buffer (char ‘Y’)
– serial will be done with the 3° byte of the 2° dword of the memory buffer (char ‘2’)

Having said that, here is a description of the 0x62 VM opcode used to move a byte from memory buffer to a register.

mov reg_i, memory_buffer_j:
00403750 mov ecx, esi ; case 0x62
00403752 call loc_403360
00403757 test al, al
00403759 jz loc_40342F
0040375F mov eax, [esi+438h]   <-- eip
00403765 movzx ecx, byte ptr [eax+2]   <-- 2° operand
00403769 movzx edx, byte ptr [ecx+esi+42Ch]   <-- memory index position (refer to name, fake serial or right serial position)
00403771 movzx eax, byte ptr [eax+1]   <-- 1° operand
00403775 lea ecx, [ecx+edx*4+2Ch]   <-- position inside memory
00403779 movzx edx, byte ptr [ecx+esi]   <-- get byte from memory buffer
0040377D mov [esi+eax*4+0Ch], edx   <-- store byte into register
00403781 mov ecx, [esi+438h]
00403787 movzx edx, byte ptr [ecx+2]
0040378B add [edx+esi+42Ch], bl   <-- add 1 to the memory index position
00403792 add dword ptr [esi+438h], 3   <-- eip update
00403799 lea eax, [edx+esi+42Ch]
004037A0 pop edi
004037A1 pop esi
004037A2 xor eax, eax
004037A4 pop ebx
004037A5 retn

Every VM memory operation has the ability to increment the index memory pointer value, memory is read/write in sequential order.

Just another thing and then I’ll show you the complete algorithm with a simple keygen. Do you remember when I said “flag is stored at [esi+0x42]”? The VM has some conditional jump instructions and the only way to decide to jump or not depends on the value of a specific flag. This VM has one single flag, it takes 3 possible values: 1, 2 or 3 according to the result of a VM instruction like this one:

(0x81: cmp reg_i_val, dword_val):
40397C mov ecx, esi
40397E call loc_403360
403983 test al, al
403985 jz loc_40342F
40398B mov edx, [esi+438h]   <-- eip
403991 movzx ecx, byte ptr [edx+1]   <-- 1° parameter: reg index
403995 mov eax, [esi+ecx*4+0Ch]   <-- get dword value from reg
403999 mov ecx, [edx+2]   <-- 2° parameter: dword value
40399C cmp eax, ecx   <-- compare the two dword values
40399E jnz short loc_4039B2
4039A0 add edx, 6
4039A3 pop edi
4039A4 mov [esi+8], bl   <-- values are equal: flag = 1
4039A7 mov [esi+438h], edx
..
4039B8 mov byte ptr [esi+8], 3   <-- flag value 3
...
4039CB mov byte ptr [esi+8], 2   <-- flag value 2

There’s a compare between two values, one from a register and the other from a dword value. The flag at [esi+8] is updated depending on the compare result.
You can now imagine how a conditional jump instruction looks like:

4038C3 cmp byte ptr [esi+8], 2   <-- check flag value
4038C7 jnz loc_4035F9
4038CD sub ecx, [ecx+1]   <-- get the jump offset value
4038D0 pop edi
4038D1 mov [esi+438h], ecx   <-- jump!
...
4035F9 add ecx, 5   <-- add length conditional jump instruction
4035FC pop edi
4035FD mov [esi+438h], ecx   <-- update eip

The VM instructions are taken starting from 0x40A000, here is the initial byte sequence:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 61 01 00 00 00 00 61 02 00 00 00 00...

I showed you few instructions but the VM instruction set is simple, there are basically almost all the instructions of an x86 instruction set: mov, cmp, conditional jump and direct jump. Parameters are stored using little-endian system. The VM doesn’t have call instructions, and so it doesn’t need a real stack implementation.

The interesting part of the VM algorithm is:

0:   00                  nop 
     00                  nop
     00                  nop            
     00                  nop 
     00                  nop 
     00                  nop 
     00                  nop 
     00                  nop  
     00                  nop 
     00                  nop 
     00                  nop 
     00                  nop 
     00                  nop 
     00                  nop
     61 01 00 00 00 00   mov reg_1, 0x00000000 
     61 02 00 00 00 00   mov reg_2, 0x00000000 
     61 03 00 00 00 00   mov reg_3, 0x00000000
     61 04 00 00 00 00   mov reg_4, 0x00000000
     61 06 00 00 00 00   mov reg_6, 0x00000000
     61 07 00 00 00 00   mov reg_7, 0x00000000
     61 00 00 00 00 00   mov reg_0, 0x00000000
     20 00 00            mov m_0, 0x00
     00                  nop 
     20 00 01            mov m_0, 1
3F:  40 02               jmp $+2
41:  00                  nop 
42:  05 04               inc reg_4
     00                  nop 
     62 01 00            mov reg_1, m_0   <-- get current char from name
     00                  nop 
     81 01 00 00 00 00   cmp reg_1, 0x00000000
     00                  nop
     01 01               add reg_5, reg_0, reg_1
     00                  nop 
     60 05 00            mov reg_0, reg_5
     00                  nop 
57:  54 15 00 00 00      ja $-0x00000015
     00                  nop 
     06 04               dec reg_4
     00                  nop
     60 00 03            mov reg_3, reg_0
     13 AC DC 00 00      mul reg_5, reg_0, 0x0000DCAC
     61 07 4A 00 00 00   mov reg_7, 0x0000004A
6E:  40 02               jmp $+2
     00                  nop 
     63 07 03            mov m_3, reg_7
74:  46 06               loop $-0x06
     00                  nop 
     00                  nop  
     00                  nop 
     60 05 00            mov reg_0, reg_5
     00                  nop 
     17 88 77 66 55      xor reg_5, reg_0, 0x55667788
     00                  nop 
     60 05 00            mov reg_0, reg_5 
     00                  nop 
     14 15 00 00 00      div reg_5, reg_0, 0x00000015
     00                  nop 
     60 05 00            mov reg_0, reg_5
     00                  nop 
     03 06               mul reg_5, reg_0, reg_6
     60 05 00            mov reg_0, reg_5
     00                  nop 
     03 04               mul reg_5, reg_0, reg_4
     60 05 00            mov reg_0, reg_5 
     60 00 01            mov reg_0, reg_1 
     61 07 08 00 00 00   mov reg_7, 0x00000008 
A5:  14 3C 00 00 00      div reg_5, reg_0, 0x0000003C
     60 06 00            mov reg_0, reg_6 
     11 41 00 00 00      add reg_5, reg_0, 0x00000041
     60 05 00            mov reg_0, reg_5 
     63 00 01            mov m_1, reg_0           <-- save right serial char
     03 01               mul reg_5, reg_0, reg_1
     60 05 00            mov reg_0, reg_5 
     07 01               xor reg_5, reg_0, reg_1
     60 05 00            mov reg_0, reg_5 
     03 04               mul reg_5, reg_0, reg_4
     60 05 00            mov reg_0, reg_5 
     07 06               xor reg_5, reg_0, reg_6  
     60 05 00            mov reg_0, reg_5 
     17 00 BB 00 DD      xor reg_5, reg_0, 0xDD00BB00
     60 05 01            mov reg_1, reg_5 
D4:  45 2F               jnz_7 $-0x2F
     61 07 07 00 00 00   mov reg_7, 0x00000007 
     20 00 02            mov m_pos_2, 0x00       <-- my fake serial 
     20 00 01            mov m_pos_1, 0x00       <-- right serial
E2:  62 01 02            mov reg_1, memory_buffer_2
     62 02 01            mov reg_2, memory_buffer_1
     85 01 02            cmp reg_1, reg_2
     43 10 00 00 00      jb $+0x00000010
     44 0B 00 00 00      ja $+0x0000000B
F5:  45 13               jnz_7 $-0x13
     00                  nop  
     00                  nop 
     00                  nop 
     FF                  VM_SUCCESS

The implemented algorithm is quite easy, once you have the instructions sequence on a paper you can easily write a keygen. Here is a quick and dirty implementation of the keygen:

   sum = 0;
   for(int i=0;i< strlen(name);i++) 
      sum += (__int8)name[i];
   sum = (sum * 0xDCAC) ^ 0x55667788;
   q = sum / 0x15;
   r = sum % 0x15;
   len = strlen(name);
   tmp1 = (q * r) * len;	
   tmp2 = tmp1;
   for(int j=0;j<8;j++) {
      r = tmp2 % 0x3c;
      serial[j] = (char)(r + 0x41);
      tmp2 = ((((tmp1 * (__int32)serial[j]) ^ tmp1) * len) ^ r);
      tmp1 = tmp2 ^ 0xDD00BB00;
   }

Valid combinations are:
ZaiRoN / YiYaiQMm
crackmes.de / nmUQuME]
reversing / emAMy]Qy

That’s all folks!