Kaizen - Forensics #1 (find hidden partition on USB drive image)

File: forensics-1.zip

Here's the text of the Forensics #1 challenge:

Joey wanted to send some pictures to Phreak on a USB drive. Before sending the drive, Joey deleted his Gzip'd backup of his etc folder that was stored on the drive. Show Joey that he should be more careful when deleting data by recovering Joey's dsa private key file from the imaged copy of the usb drive.

After first mounting the image and failing to see anything other than picture files, I broke out testdisk, a free and open-source data recovery tool.

After running: testdisk usbbackup.img, the following screen pops up:

From here we hit enter to select the usbbackup.img disk, and we're asked to select the partition table type.

Following testdisk's hint of "None" partition type, I hit enter and am asked to select the partition:

Hitting enter again, we're asked if we want to rebuild the boot sector:

Hitting enter again, we can choose "List" to show the differences between the extrapolated boot sector and the current boot sector.

After selecting "List", we're shown a list of all recovered files and directories. Fortunately, it looks like etc.tar.gz is now present!

Untarring the tar.gz file gives us the /etc/ directory. Going to /etc/ssh/ gives us the recovered ssh keys!

In ssh_host_dsa_key, we see the following:

-----BEGIN DSA PRIVATE KEY-----
MIIBugIBAAKBgQDH2y+gcskLzub7MFN1gBncrmZrG4mU/ePWRrUjMSZdSmUUOhdy
eWr98MY8bPIArjnuaqNPeRVp7tXzaLBE7hn8BE7me7qRWp8ha1anGVOrkVz2wQzF
xeCX0INGunRUNh4XBNTO2Tf9QO99jttMPsmUl/jkkO+rftvnWf/bJnrN/h864Wcd
ygkw7io                                                 AXLaiQeR
49BbkYI The Flag is: 8555199cf63b179586e603c5b237bc90   UwIVAMaE
N2nwwJL                                                 oKi4tznM
wgm+Z+UCgYBlofxeIzHWCEZkc7Zh0nZXA3e7snpUN5M42N5Klf/b44DUNgNT6cZq
7OmKnLAdyGlATtpXWenMCWyS4Y5Pi3O91VRu9LGe/QlL16vjtYyO6soO/YMVlJP5
d3dPoSN/JXs00LuX3sNUbkxPRPQoei+RIml72+uHlBYOqvMVqZOboAIUbNqzb2ec
bMmD8sCeLoiAkefjieI=
-----END DSA PRIVATE KEY-----


We're done!

Kaizen - Binary Exploitation #1 (reverse engineering "turnstile" binary)

File: binary-expl-1.zip

While I've used tools like IDA before, I'm still pretty new to reverse engineering. The "turnstile" challenge from the kaizen CTF was a good one to practice the basics on.

The first thing I did was run file:

$ file turnstile.bin
turnstile.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

It shows that turnstile is a Linux executable file and, lucky for us, is unstripped.

Then I opened up IDA and took a look around.

Here's the disassembled main() function:

This doesn't look too bad. It initially compares argc against the constant value 2 to make sure the binary has been invoked correctly. If the check fails, it jumps to loc_80486D3, prints the usage information, and exits. It the check passes, it goes on to call isValidPassword and checks the return value (eax) to see if it's 1. 

From this, it's pretty clear that if we can find the password to make isValidPassword return 1, we'll have the flag.

Let's take a look at the disassembled isValidPassword:

Ok this looks a bit more complicated, but nothing too difficult to understand. Let's work our way backwards, looking at places where the return value (eax) is set.

It looks like it's set with both the xor eax, eax and mv eax, 1 instructions. Xor-ing a register with itself is a shorthand for clearing the register (more info here), so we definitely want to hit the move instruction instead. So how can we get there?

It looks like the 2nd and 3rd boxes together form a for loop that compares the value passed in against the password stored in memory (the 2nd box does the comparison of the password, the 3rd box is the comparison from the for loop). Now we just need to find what values it's expecting, so that we can pass the correct string in.

Looking at the top of the first block, you can see the fixed values being moved into the [ebp + var_41x] addresses. If you look at the comparison below, you can see eax is used as the offset variable to sweep through this same address range!

If we use python to print out the hexadecimal characters the turnstile.bin file is expecting, we can see if it works:

$ ./turnstile.bin $(python3 -c "print('\x57\x69\x6B\x69\x6C\x65\x61\x6B\x73')")
Turnstile Unlocked.
Your passcode is: 0xcffe6b8c

It does!

Kaizen - Crypto #2 (decrypt a hidden message from a pcap file)

File: crypto-2.zip

Here's the problem text for Crypto #2:

Acid Burn often uses FTP to transfer files. Extract the image from the pcap. Use Acid Burn's ftp (not Telnet) password to unlock the hidden message in the image

The zip archive contains a pcap file, so I opened it up in Wireshark to take look around.

Right off the bat, you can see the FTP password being transmitted in cleartext:

We'll save this for later.

Looking through the pcap file, it looks like two files are transferred: dinosaur.jpg and steghide_manual.txt.

We can guess the steghide manual page is a clue that the steganography is performed with the steghide tool, so now we just need to extract the JPG file that was transferred across the line.

Using the "Follow TCP Stream" tool after right-clicking on the TCP connection that gets spawned immediately following the FTP Request, we can isolate just the bytes that corrospond to the dinosaur.jpg file.

Once we do this, we can choose "Save As" and save the bytes as a jpg file.

Using the FTP password from before with the steghide tool, we can decrypt the hidden message, "CRASHANDBURN"!

Kaizen - Android Forensics #3 (find and read the cached contents of previously viewed webpages)

File: android-forensics.zip

Here's the challenge text from Android Forensics #3:

Prior to backing up his phone, the user visited a website using his phone to generate a password. What password did he generate?

Hmm, so this one it looks like we'll need to view the content of previously fetched web browser data. Figuring there must be directories that hold the cached browser content somewhere, I navigated to the /data/data/com.android.browser/ directory.

Hoping that just searching for the text "password" somewhere within the files of this directory would lead me in the right direction, I ran grep -r "password" * and got back some interesting results.

After reading through a few of the cached webpages, it was clear that the user had used a website to generate random password strings. Eventually, I looked in the cache/webviewCache/c992b966 file, which contains the following snippet:

 29 <CENTER><H1>1 Random Password</H1></CENTER>
 30 <FONT SIZE=6>
 31 <PRE>
 32 <UL>
 33 <LI><B>eb8hapvo</B></LI>
 34 </UL>
 35 </PRE>

This is it! We've got the password.

Kaizen - Android Forensics #2 (find contents of SMS database)

File: android-forensics.zip

This problem used the same file as before, but had a different goal:

A friend asked the user to reset a password via SMS. What password did he set it to? 

Hmm, so this time we need to find and read the user's text messages.

A quick google search suggests to check where the database file is with the following command:

$ find . -name "*mmssms*"
./data/com.android.providers.telephony/databases/mmssms.db
./data/com.android.providers.telephony/databases/mmssms.db-journal

Now, opening mmssms.db, we see it's an SQLite database with the user's text messages in plaintext!

I used the Firefox extension "SQLite Manager" to browse through the messages in the mmssms.db file, which eventually led me to the password, seeyou2morrow.

Kaizen - Android Forensics #1 (find saved WiFi passwords)

File: android-forensics.zip

The kaizen CTF was also the first time I'd done a CTF challenge that involved Android forensics. I'd messed around the Android filesystem before with adb shell, but never gone looking for specific things.

Here's the challenge text:

A user created a backup of his Android phone and saved it on the Desktop. What is the wifi password of the network that the user connected to?

This is a good example of something that logically must be stored somewhere on the phone, but something that I would never think about being available to anyone with access to the filesystem.

After poking around a while wihtout any success, I thought that the string "ssid" or "SSID" would likely be stored near the password, wherever that would be...

Running grep -r "ssid" data/ yields a fair number of hits, but one sticks out in particular:

./misc/wifi/wpa_supplicant.conf:    ssid="HomeNetwork"

This looks promising... Investigating the rest of the file shows it contains the "psk" that we're looking for!

ctrl_interface=eth0
update_config=1

network={
    ssid="HomeNetwork"
    psk="lowercaseUPPERCASE"
    key_mgmt=WPA-PSK
    priority=1
}