RansomCrypt: an analysis of its crypto routines.

About a week ago, I noticed a new crypto ransomware (remember gpcode?): W32/RansomCrypt. The news came from the F-Secure website. So, as soon as I gathered a sample I started my analysis, but just when I was about to finish it... A twitter update told me that F-Secure had already done the work with the decryption script!
    
Anyway here you can find some additional details about the encryption/decryption and the way it works.
   
The first executable I came across was coded in Visual Basic and was packed with a modified UPX version.
   
After unpacking the sample, I started searching for standard encryption routines, but nothing caught my attention. However the sample did contain encrypted data, and debugging some routines that looked like home made decryption code, I ended up finding a second encrypted executable within the first one.
   
Luckily, this second executable wasn't coded in Visual Basic (if you have tried to reverse some VB executable you know what I mean!),  this one was also packed, but with standard UPX. Again, I unpacked it and began searching for some encryption routines. I found three candidates: a 16-bytes xor, and two TEA routines (both encryption and decryption).
   
(If you haven't ever reversed TEA, here's a little trick to recognize it: in most cases you just have to look for the magic constant 0x9E3779B9 and the work is done.)


I also noticed some interesting APIs: FindResource, SizeofResource, LoadResource, LockResource. They made me look into the resources of the file, where I found an encrypted block. Once decrypted, this block revealed the malware configuration.

To decrypt the configuration, I debugged this decryption routine and found out that the first 16 bytes of the resource were the key for the decryption of the configuration block. The decryption algorithm was the 16-bytes xor routine I had noted earlier.

Then I noticed a loop scanning for all the files in the system, and I thought that it was probably the same that also encrypted them.

I set a breakpoint there, and followed the key generation algorithm: the malware uses the same key employed to decrypt the configuration block, but it changes the endianness of every dword.

   

Key from the resource section:    4A 2E 94 46   60 64 85 5B   5A 86 89 8C   7F 63 6C 50

Key with swapped endianness:   46 94 2E 4A   5B 85 64 60   8C 89 86 5A   50 6C 63 7F

This key, combined with the first byte of the targeted filename, leads to the final encryption key that will be used with TEA.

  

   mov     dl, [eax]       ; get first char from filename

   mov     ecx, 10h

   mov     esi, offset BaseKey

   mov     edi, offset GeneratedKey

   KeyGeneration:

   lodsb

   xor     al, dl

   rol     dl, 1

   stosb

   loop    KeyGeneration

Or in C, in you prefer:
   
   #define ROTATE_LEFT(a,n)( (a<<n) | (a >> (8-n)) )
                                 
   A = Filename[0];
   for(i = 0; i < 16; i++)
   {

   GeneratedKey[i] = StaticKey[i] ^ A;

   A = ROTATE_LEFT(A, 1);

   }

Finally I noticed that the malware doesn't encrypt the entire file, but it skips the first 0x47 bytes. I believe that this is done because the first bytes of a file usually contain a header (depending on the type of the file), and these headers may contain predictable data that may allow known plaintext attacks.

We have gone through the encryption: they key is generated starting from a static seed, and then TEA is used, so if you have been infected you can generate your decryption keys and get your files back.

You can use the python script from F-Secure, which performs the decryption automatically. However, users should note that they should NOT rename the encrypted files: the encryption key is generated combining the static key with the first character of the filename, so changing the filename of an encrypted file may cause incorrect decryption.

Alternatively, the malware prompts the user for a code that if inserted will cause the malware to decrypt all encrypted files and then remove itself. The code will be sent of course only after a user sends money to the malware author.

Can't we just get this code? Does it really work? I tried forcing the tool to accept any code (I cracked it, if you want to put it that way), and the malware did decrypt the files and remove itself. So having the code may solve the problem immediately.

Unfortunately, the code is checked pretty heavily: the string you insert is hashed five times with MD5 (the hash is performed through Windows Crypto APIs) , and then checked with a hash that is hardcoded in the configuration; something like this:

   if MD5( MD5( MD5(MD5(MD5(Code))))) == 900140074FA550671FB6916CFF4D21CC

   then DecryptAndRemove()

So, unless you have the time and patience to crack this MD5 hashes chain, you are better off calculating your own keys and decrypting the files yourself.