ebctf 2013 For-100 write up

Challenge:

After a recent attack, we found this encrypted file. Luckily, we made a memory dump, can you decrypt the file?
Archive password: lcoXse3oa3Uicioc

Files can also be found here: http://ctf.zone/EbCTF-2013-08/Forensics/100/

Download and unzip the memory dump, check the file type

Also check the strings, so it could be linux 64 bit

Pre-requisites:
We will be using volatility to investigate the memory dump, and a suitable linux profile to read it. In this case, for convenience, we can simply download Ubuntu 12.04 64bit and run it in VM
http://www.ubuntu.com/download/desktop/questions?distro=desktop&bits=64&release=lts
after setting up the VM for Ubuntu, we will install volatility (you may also need to install subversion beforehand)
in Ubuntu 64bit open the terminal,  to install subversion:
$ sudo apt-get install subversion
To install volatility:
sudo  svn checkout http://volatility.googlecode.com/svn/trunk/ volatility
$ cd volatility
$ sudo python setup.py install
*note: the path in the sample codes may be different (subject to your own environment)

To create Linux Profile (Ubuntu1204-64bit) for read the memory dump
ref:  https://code.google.com/p/volatility/wiki/LinuxMemoryForensics

To install dwarfdump:
$ apt-get install dwarfdum
$ cd volatility/tools/linux
$ make
$ head module.dwarf

Making the profile:

From above, we found “BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic”, we may create the profile from Ubuntu12.04 64bit with System.map-3.5.0-23-generic

$ sudo zip volatility/volatility/plugins/overlays/linux/Ubuntu1204.zip volatility/tools/linux/module.dwarf /boot/System.map-3.5.0-23-generic

Ubuntu1204.zip will be created, we can see “LinuxUbuntu1204x64” profile

$ python vol.py  --info | grep Linux

Everything is ready, we can analyze the memory dump, There's a python2 process (pid=1317), we will want to examine it further
$ python  vol.py --profile=LinuxUbuntu1204x64 -f memory.dump linux_pslist

We will use linux_bash to check for any clues in the history
$ python vol.py --profile=LinuxUbuntu1204x64 -f memory.dump linux_bash

Two important findings here,
python2 ctf.py ‘ i hide my ‘
kill -s SIGUSR 1317
the python was executed with argument “ i hide my”, and eventually the process was killed by SIGUSR1

The python code could still be in the memory, so we grep the strings
$strings memory.dump | grep SIGUSR1

“signal.signal(signal.SIGUSR1, encrypt)” seems to be part of the python
We save the strings in a text file and do another search for the rest of the codes
$ strings memory.dump > memory.dump.txt
Search the string “signal.signal(signal.SIGUSR1, encrypt)” in text editor, we could find the python codes around
Now we’ve got key1: ‘is this where’, key2: ‘ i hide my ’, and now we have to find key3 in order to decrypt the “flag” file

We try examine the python process memory for what could be input as argument
$ python vol.py --profile=LinuxUbuntu1204x64 -f memory.dump linux_proc_maps -p 1317
We see “[heap]” between python2 and encrypt, it could be string of the input

We dump the memory for further analysis
$ python vol.py --profile=LinuxUbuntu1204x64 -f memory.dump linux_dump_map -p 1317 –dump-dir output/
$ grep -r 'i hide my' output/
These two files should contain “i hide my”,  Let’s search the strings in these two files
Ha! We got sth. useful! ‘is this where i hide my secrets?’, so key3 is “secrets”!

You may also simply search for memory.dump strings to find “is this where i hide my secrets”

Now we modify the python code to see if it can decrypt the flag, we got key1, key2 and key3, and we print the result of decrypt

Finally we got the flag :)
ebctf{55169c1c241aa20412da94b3fcbf8506}

PlaidCTF 2014 For-400 write up

Challenge:

The Plague is using state of the art systems for storing his data. Our operatives managed to steal [a drive](zfs-ff06f37193caa92456e9c03090c80600.tar.bz2) from one of his servers, but it seems like our haste may have led to some uber-corruption. Can you get the data off the drive to track down The Plague?

From the question title, “disk” is kind of corrupted zfs drive. In order to recover the data as quick as possible, recovery tools like UFS Explorer Pro is used. Open the “disk” with it, you can see one file “not_the_key”.

Opening “not_the_key”, it’s really not the key… dig deeper

Then trying to recover the data from “disk”, three files are found.
key.xor_encrypted
not_the_key
xor_key

Extract the files, two of them look interesting. “xor_key” and “key.xor_encrypted” look self-explanatory, let’s try to “xor” them. The python code “xor” the two files.

from binascii import unhexlify, hexlify

def str_xor(s1, s2):
    return "".join([chr(ord(c1) ^ ord(c2)) for (c1,c2) in zip(s1,s2)])

def get_bytes_from_file(filename):  
    return open(filename, "rb").read()  

encByte = get_bytes_from_file('key.xor_encrypted')

keyByte = get_bytes_from_file('xor_key')

s = ''.join(chr(ord(c1) ^ ord(c2)) for c1, c2 in zip(encByte[-len(keyByte):], keyByte))

print s

Run the python code, the flag is here

===========================================================

Alternate Method:

Hex analysis approach to dig out the files, assuming we did not use UFS Explorer, we can use Hex Editor like WinHex

Oh well, we did not have clues, so we did some key word search, how about “key”?

Ok, we got “not_the_key”. Scroll up, it looked interesting, and we copy the block out.

Then we got “not_the_key” file and it asks us to dig deeper again. .\/. OK, find next... We continue to “dig deeper” and continue to search, we see three names:

key.xor_encrypted

not_the_key

xor_key

Ok, it's a bit by chance, we found that there's a 0x200 block ... 

And we scroll down to get another 0x200 block to see if we can do an XOR... 

oh yeah, it could perfectly do the XOR and get the cute shark again -_-.....