Toorcon 18 CTF – Forensics 250

I had a ton of fun at the Toorcon 18 CTF. On the second day of the CTF a bonus forensics challenge popped up. During the first day our forensics guy had showed me how to use Volatility so I figured I would take a crack at it. I usually don’t do forensics challenges so I knew this would be a good opportunity to learn.

Examining the file

the challenge was called Eric’s Password and we were given a file called pbrane-eric.gz. The extracted file had no file extension as seen below:


I started by running Volatility with the with the imageinfo command. This will give you information about the image and help you to determine the correct profile to use. Profiles are used to correctly perform the memory mapping: -f <filename> imageinfo


Dumping files

Next I ran a filescan to see if it would yield any results because this was the path used to retrieve the flag on a previous challenge. This didn’t give me any flags but is useful to know: --profile=<profilename> filescan -f <filename>


Hash Dumping

Next I figured if we were looking for passwords why not try to run a hashdump on the image. After referencing the usage guide I determined that I needed to get the hivelist first to determine the memory location of of the SAM file: --profile=<profilename> -f <filename> hivelist


Then I used this information to run hashdump: --profile=<profilename> -f <filename> hashdump -s <SAM memory location>


We cracked the password but quickly discovered that this wasn’t the flag. I did a bit of Googling after this to determine other password dumping techniques. this led me to the next possibility.

Dumping passwords with Mimikatz

Next we discovered that you could use a plugin that would run mimikatz on the image that can be found here. In this case you have to specify the plugin. I was attempting to do this with OSX but had to switch to Kali Linux for some reason to get this working correctly:

volatility --plugins=<plugin location> --profile=<profilename> -f <filename> mimikatz


We put the flag into the scoreboard and determined that we were successful! Very interesting technique and a great learning experience. I had to go outside my normal comfort zone to conquer this one and it was well worth it.


The route to reversing my router

I have been dabbling in reverse engineering a bit lately trying to get progressively better. While updating my router and attempting to configure some setting I figured why not attempt to reverse the firmware. Keep in mind I’m pretty new to reversing so I will include the roads blocks I hit along my journey.



Router typeASUS RT-AC53U

Firmware: Version

Description: Dual-band wireless-AC1200 router

Filetype: .zip extracted into .trx





I started by downloading the firmware on the ASUS website which was not to difficult to find:


Static File Analysis

Once I downloaded the software I simply double clicked it and it extracted into a .trx file. I was instantly pretty baffled by the file extension that I had never seen before so I ran the file command on it:

sneakerhax$ file RT-AC53U_3.0.0.4_376_3754-g5ef7c1f.trx
RT-AC53U_3.0.0.4_376_3754-g5ef7c1f.trx: data

This still did not reveal what I wanted to know so I tried running xxd on it to look for the magic bytes:

xxd -l 4 RT-AC53U_3.0.0.4_376_3754-g5ef7c1f.trx 0000000: 4844 5230 HDR0

I searched for HDR0 and was able to find some information on the openwrt website which started to clear things up. I also ran strings and hexdump which are too long to paste in this article but are good to perform during static analysis. Now I knew I had to dump the contents of the firmware image.

Extracting and Analyzing

I used binwalk to take an intial look at the file:

sneakerhax$ binwalk RT-AC53U_3.0.0.4_376_3754-g5ef7c1f.trx 

0             0x0             TRX firmware header, little endian, image size: 26750976 bytes, CRC32: 0x154FEC57, flags: 0x0, version: 1, header size: 28 bytes, loader offset: 0x1C, linux kernel offset: 0x136078, rootfs offset: 0x0
28            0x1C            LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, uncompressed size: 3482336 bytes
1269880       0x136078        Squashfs filesystem, little endian, non-standard signature, version 3.0, size: 25475764 bytes, 1420 inodes, blocksize: 65536 bytes, created: 2015-01-10 15:52:29

Now I was starting to get somewhere. I needed to extract the files still that where inside:

binwalk -Mre RT-AC53U_3.0.0.4_376_3754-g5ef7c1f.trx
Output can be found here

This worked to extract the files and I had a ton of stuff to look at. I started analyzing the output. I thought it might be a good idea to search for “version” throughout the binwalk analysis and found some interesting findings. I was attempting to find the linux kernel version:

  • POSIX tar archive (GNU), owner user name: “ter”(Username found)
  • ELF, 32-bit LSB executable, MIPS, version 1 (SYSV)(References to MIPS)
  • Found references to used software(Squid, ftp, etc)

I also searched for kernel and found some other interesting findings:

  • Packages that were being used
  • version?)

***Work in progress***