Hack in the box teaser 2015 : Forensics 1000

April 30, 2015

In preparation for the Amsterdam Hack in the box CTF this year I took a look at the Forensics 1000 challenge, the description of which you can find below.

While doing forensics on the HEAVENWEB’s server we found a possible ACTOR.
We scanned the interweb for possible traces left by this ACTOR and found an opendir containing HEAVENWEB_SCRAPE.tar.xz [sha256: 6188c47846d306f29315c5df85c507052d20e98e592e08bdf1b35b46c7f84564].
We believe they use a proprietary crypto application only known to this ACTOR.
Are you able to find the flag?
HINT: https://www.youtube.com/watch?v=zuxlLLeKZZ8

The HEAVENWEB_SCRAPE.tar.xz archive contained 2 files:

  • HITB_FOR1000_2015: data
  • HITB2015_FOR1000.dmp: ELF 64-bit LSB core file x86-64, version 1 (SYSV)

Running strings on the HITB2015_FOR1000.dmp file, we see it is an operating system memory dump:

  • /boot/vmlinuz-

Some cursory googling, coupled with the challenge name we identify the operating system as North Korea’s RedStar. Inspecting the HITB_FOR1000_2015 file we find references to a file system as well as some common encryption buzz words.

After this quick analysis, we watched the hint video and at around the 12.00 minute mark we see a demonstration of Red Star’s custom encryption application – Bokem.

The video further explains Bokem is native to Red Star and requires root privileges to run.

So, let’s install Red Star and escalate to root:

echo 'RUN"+=/bin/bash /tmp/root.sh"' > /etc/udev/rules.d/85-hplj10xx.rules
cat /tmp/root.sh
echo -e "ALL\t\ALL=(ALL)\tNOPASSWD: ALL" >> /etc/sudoers

Let’s fix networking while we are at it:

rm /etc/sysconfig/iptables

After a quick sudo –s you should be able to execute Bokem with root privileges.

Next we can create our own Bokem container, after which we identified that the challenge is also a Bokem container which we need to access.

After creating our own container, we notice the .bokem3.conf file in our current directory, which contained:


To this configuration file, we can append the container from the challenge to attempt to load it:


Unsurprisingly, the challenge container 93a0c2f4 requires a password.

Given this is a forensics challenge, let’s assume we can find what we need in the challenge. So, let’s mount our own container and dump our machine memory. Assuming you are using a virtual machine, you can do this by simply taking the .vmem file of a snapshot.

So now we have the following:

  • Our container file, to which we know the password;
  • Our memory dump, including a running and decrypted container;
  • The challenge container file, which we want to decrypt and do not know the password;
  • The challenge memory dump, hopefully including a running and decrypted container.

Let’s start by analysing our own container.

Looking at our own container with the name and password of test we notice in the header:


Which is the md5 of our password, followed by our container name.

Similarly, in the challenge container we notice in the header:


Which is the md5 of the container password (which we couldn’t crack), followed by the container name.

So we need some more information from the challenge container, let’s take another look at our running container on Red Star.

Dmsetup is a low level logical volume management tool. Dmsetup can be used to create and remove devices, get information about devices or reload tables. Using the dmsetup tool we can gain some information about the currently mapped devices on the system. Luckily, dmsetup also supports displaying of the encryption keys used.

Let’s take a look at our mapped container and its associated encryption key:

dmsetup table -showkeys bokemcrypt_000: 0 102399 crypt pilsung-cbc-essiv:sha256 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 0 7:0 1

So, our encryption key is as follows:


If we lazily search for our key in our memory dump we identify an interesting instance:

xxd -p Snapshot1.vmem | grep -A10 -B10 9f86d081884c7d659a2feaa0c55

The memory structure identified contains the md5 of our password, as well as our known encryption key some bytes above.

Doing a similar search using the password hash from the challenge, we identify a similar structure in the challenge memory:


Based on our testing container, be6b50300e87ea15da0884d5e44781ffbf8000286db03dade00ce4b64cad0bf4 appears to be the encryption key used by the challenge container.

So, let’s try and mount the challenge container using the above identified key.

We can create a device and specify a mapping table using dmsetup, for this we need the following table parameters:

start size target cipher –mode-iv:type 256-bit key iv_offset device sector_offset

We can identify most of this information from the mapping settings in our similarly sized container, except the sector offset.

Looking at the challenge container randomness with a hex editor we can identify that the file’s encryption offset appears to start at 0x200 or 512 bytes into the file. For dmsetup a sector is always defined as 512 bytes, so we can identify our new table as follows:

0 102399 crypt pilsung-cbc-essiv:sha256 be6b50300e87ea15da0884d5e44781ffbf8000286db03dade00ce4b64cad0bf4 0 /dev/loop2 1

Now we can mount the challenge container:

losetup /dev/loop2 HITB
dmsetup create HITB --table '0 102399 crypt pilsung-cbc-essiv:sha256 be6b50300e87ea15da0884d5e44781ffbf8000286db03dade00ce4b64cad0bf4 0 /dev/loop2 1' 
mount -o rw -t ext3 /dev/mapper/HITB /mnt/HITB

Once mounted, we identify a single file in the container flag_HITB.txt which contained: