CTF Writeup - Flare-On 2016 - 02: DudeLocker

• Name - DudeLocker
• Category - Reverse Engineering
• Points - 2
• Description - n/a
• Binary - Download here

The zipped folder contains 2 files, a binary and a .doc file which contains gibberish. To make things more interesting(?), the executable does not output anything and exits straight away.

Loading in IDA and running the first few instructions from the main function (sub_4019A0) we immediately notice the basic block which is causing the program to end prematurely:

The function is searching for a folder called Briefcase on the desktop. If not found, the program follows the exit route. Creating the folder and re-running the program we still don't get anything. This time the program fails on the comparison of the VolumeSerialNumber obtained from the GetVolumeInformation function in sub_401040:

The value for the VolumeSerialNumber is expected to be 0x7DAB1D35. We patch the function to look like this:

Now we will always get the desired value. Re-running the program we now get some interesting results: the contents of all the files in the Briefcase folder are encrypted, an image is dropped in this same folder and we get a surprise:

The background image changes to this annoying picture. If you haven't realised by now, the aim of the challenge is to decrypt the doc file. There are 2 routes we could take, either we can recreate the encryption algorithm and use it to decrypt, or use the program itself to decrypt our file for us since the algorithm is symmetric. Of course we will opt for the latter. This technique is facilitated by the fact that both the CryptEncrypt and CryptDecrypt are very similar:

 BOOL WINAPI CryptEncrypt(
    _In_    HCRYPTKEY  hKey,
    _In_    HCRYPTHASH hHash,
    _In_    BOOL       Final,
    _In_    DWORD      dwFlags,
    _Inout_ BYTE       *pbData,
    _Inout_ DWORD      *pdwDataLen,
    _In_    DWORD      dwBufLen
 );

 BOOL WINAPI CryptDecrypt(
        _In_    HCRYPTKEY  hKey,
        _In_    HCRYPTHASH hHash,
        _In_    BOOL       Final,
        _In_    DWORD      dwFlags,
        _Inout_ BYTE       *pbData,
        _Inout_ DWORD      *pdwDataLen
 );

The only difference between them is that CryptEncrypt takes an extra parameter at the end. Since this will be pushed first onto the stack before the function is called, we can leave everything as is and just change the call to CryptDecrypt instead. The function now looks like this:

We put the doc file in the Briefcase folder and run the program again. Apart from the ransomware background, we get the result: