Flare-on 3 – Challenge 2

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

The archive for this challenge included 2 files.

BusinessPapers.doc: data
DudeLocker.exe: PE32 executable (console) Intel 80386, for MS Windows

I first took a look at the .doc file and it looks to be random data.


After doing some initial analysis on the executable file, I found many references to encryption routines in the imports. This program looks to act like ransomware. Diving into the functionality, the program first looks for a directory named “Briefcase.”

If it can not open the directory, it jumps to an error accusing the person of being a reverse engineer!

After it validates, it can open the directory properly; a routine is called checking the drive’s serial number looking for a specific value. If the value doesn’t match, the program errors out. If the hard drive’s serial number matches, it jumps to the routine to decode the encryption key. The drive’s serial number and a pointer, the encoded data stored in the .data section, are passed into the mw_decode_key function.

The mw_decode_key function does what I have named it, it decodes the key used in the data encryption. It uses a simple xor loop to decode the key.

Now that we have the key decoded it is time for the program to set up and execute the encryption routines. As a way to summarize the overall process, I have created the following diagram showing the connections between all of the functions. The boxes colored in blue are handles to data structures and the boxes in green are variables containing a value. The first step in the entire process to set up the Provider which acts as a glue between the key generation functions. From here let us go through each box in numbered order.

Section 1 is used first to create a Hash of the key based on the SHA1 algorithm. Next, it takes this Hash and derives an AES256 key from the Hash and stores it the Key Handle. The key finally has its mode set a CBC cipher.

Section 2 is used to create the IV portion of the key. This is derived from an MD5 hash of the name of the file. This section writes the data to a Hash Handle then copies it out of the handle into the KP_IV parameter of the Key Handle created in section 1.

Finally, in section 3, where files are encrypted, the original file is opened and read into a File Buffer which is then read by the CryptEncrypt function that reads the Key Handle and executes the encryption writing it back to the buffer. The buffer is then written back to the original File Handler, overwriting the data on disk.

After looking over all of this crypto routine and using a debugger to extract both the main AES key and the IV key values, I created a decryption script in python to extract what I had assumed is encrypted data in the BusinessFiles.doc file. The following script uses the wincrypto and cryptodome packages to more or less follow the process I just outlined instead, decrypting the data.

# need wincrypto and cryptodome packages

from Crypto.Cipher import AES
from Crypto.Hash import MD5
from wincrypto import CryptCreateHash, CryptHashData, CryptDeriveKey
from wincrypto.constants import CALG_SHA1, CALG_AES_256
import magic

encryted = 'BusinessPapers.doc'
encypted_data = open(encryted, 'rb').read()

key = b'thosefilesreallytiedthefoldertogether'
md5_clear = bytes(encryted.lower(),"UTF-8")

# Derive Key
sha1_hasher = CryptCreateHash(CALG_SHA1)
CryptHashData(sha1_hasher, key)
d_key = CryptDeriveKey(sha1_hasher, CALG_AES_256)

# Create IV data
iv = MD5.new()

aes = AES.new(d_key.key, AES.MODE_CBC, iv=bytes.fromhex(iv.hexdigest()))
decd = aes.decrypt(encypted_data)

print (decd[:20])

hFireWrite = open("test.bin", 'wb')

The output of this script writes the data to disk and provides a preview of the first 20 bytes and the magic block info from the data.

JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, Exif Standard: [TIFF image data, big-endian, direntries=8, manufacturer=Minolta Co., Ltd., model=DiMAGE G500, orientation=upper-left, xresolution=140, yresolution=148, resolutionunit=2], baseline, precision 8, 576x410, components 3

Success we have found the flag!


A funny feature of this challenge is that it leaves a ransom note. The note is an image in the resources section of the file. This image is extracted and written to the disk. Then it set the wallpaper using the SystemParametersInfoW API call.

Author: Ben Mason

Technical Architect - Computer Networking - Security - Electronics Hobbyist - Sometimes Photographer - Spaceflight - Cat Enthusiast - HAM KC1GDJ

Leave a Reply

Your email address will not be published. Required fields are marked *