After a purely software challenge (described in a previous post), I wanted to try a hardware challenge. Unfortunately, during Ph0wn, I was not well prepared and the slot to get hardware devices was short (20 minutes). Moreover, I did not look at all at some of the challenges including an easy one: Flag digger. When coming back to Switzerland on Saturday, I discuss with @Baldanos and @Pelissier_S (the authors of Flag Digger) and they gave me one of their chips to try the challenge:
To make it easier to solve (i.e. without soldering), they solder the chip on a small PCB with headers. All the pins of the chip are thus easily accessible. The challenge is the following:
Flag digger Like many IoT devices, your adventure starts with a small chip. Can you find the flag ?
Very short.
The first thing that come into mind is to identify the chip. Today with smartphones and their very good cameras, it is easy:
It is written BH1649. A quick search on Google gives... nothing interesting: bags, shoes, a plate from Illinois, etc. So let's try with the second number: 25Q32CSIO. In fact, I know a little those chips and I know that 25Q32 means something. The first hit in Google is a datasheet for a flash memory. This number (25Q32) can be read this way:
I know SPI (Serial Peripheral Interface) because I use it often for flashing my Arduinos and sometimes my 3D printer (instead of using the bootloader). It uses 4 wires: SCLK, MOSI, MISO, !SS. So let's have a look on the datasheet of our chip:
Holly Britney! It is not labeled the same way (except SCLK)! It would be too easy isn't it? I recognize VCC and VSS: it is to power the chip (+3.3V and Ground). The Wikipedia page says "While the above pin names are the most popular, in the past alternative pin naming conventions were sometimes used" and gives alternative names including our CS, SO, SI. It also explains that "In other words, MOSI (or SDO on a master) connects to MOSI (or SDI on a slave)". So CS# = !SS, MOSI = SI, MISO = SO:
I have two FTDI cables and a FTDI board:
The first cable has a FTDI FT232RL chip and the board a FTDI FT232H chip. I know that with the FT232H, it is possible to "talk" SPI (from the datasheet). With the FT232R, it is also probably possible but it is easier with the FT232H thanks to its MPSSE - multi-protocol synchronous serial engine.
But wait a minute! The chip is 3.3V and these FTDI chips are 5V. In fact, the documentation is confusing at first because it says "It's safe to use with both 3.3 volt and 5 volt signals". But what we need is to power the flash chip at 3.3V! OMB*! It is similar with the FTDI cables. They are "3.3V safe" but for the signals, not the power.
There are several solutions to this problem like using a voltage regulator (to regulate 5V down to 3.3V), but I do not have one right now (I have to purchase some). So FAIL.
One day after, I come back to this challenge. I know that the venerable Bus Pirate is able to do plently of things. "Venerable" because it is quite old now, with an old design and based on PIC microcontrollers. Apparently, it is still sold but no more developed by Dangerous Prototypes. Even their "new" version 4 is stucked somewhere:
Unfortunately it seems that Dangerous Prototypes have abandoned the Bus Pirate firmware development (and the Bus Pirate v4 also), despite that their official firmware has never reached a truly stable state: the quantity of bug report threads at forums, especially regarding flashrom, is a direct proof of that.
A quick look on my 3.6 Bus Pirate and it does have a 3.3V power line! The wiring between the Bus Pirate and the flash chip is simple, even if the labeling is, again slightly different:
To determine the orientation of the flash chip, there is a small circle in one of the corner:
We need to determine the port name. One way it to run the command:
ls -l /dev/tty.*
before connecting the Bus Pirate to the USB port of the computer, and again after. If everything goes correctly, you have a new entry listed such as /dev/tty.usbserial-A90806C4. It is possible to connect to the Bus Pirate in console mode and enter commands manually. But here what we want to do is to dump the flash and the perfect tool for that is flashrom:
flashrom -p buspirate_spi:dev=/dev/tty.usbserial-A90806C4,spispeed=1M -r flash.bin
You see immediately if the wiring is correct or not. If it is correct, flashrom will identify the flash chip: GigaDevice flash chip "GD25Q32(B)":
flashrom v1.0 on Darwin 18.2.0 (x86_64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... delay loop is unreliable, trying to continue OK. Found GigaDevice flash chip "GD25Q32(B)" (4096 kB, SPI) on buspirate_spi.
After some time, you get:
Reading flash... done.
So we have dumped the flash. But were is the flag? Let's identify the content of the dumped flash with the file command:
$ file flash.bin flash.bin: Squashfs filesystem, little endian, version 4.0, 655738 bytes, 24 inodes, blocksize: 131072 bytes, created: Thu Dec 13 16:48:17 2018
Squashfs is a compressed, read-only file system. To decompress it, you can use 7-Zip if you are using Windows. On macOS and Linux, you can install and use unsquashfs:
unsquashfs flash.bin
It creates a directory named squashfs-root/. It contains:
$ ls -la squashfs-root total 56 drwxr-xr-x 5 sebastien staff 160B Dec 13 17:46 ./ drwxr-xr-x 10 sebastien staff 320B Dec 19 15:15 ../ -rw-r--r--@ 1 sebastien staff 26K Dec 13 17:33 flag.pdf drwxr-xr-x 3 sebastien staff 96B Dec 13 17:47 lst/ drwxr-xr-x 21 sebastien staff 672B Dec 13 17:46 obj/
flag.pdf contains the flag:
English USph0wn{SP1_Fl4sh_M4st3r}
And what about those lst and obj directories? They contains files related to Hydrabus (hydrabus_dac.lst, object files, ...). Why? A mistake? I do not know.
It was a simple challenge (technically speaking) but like always, when you do not practice this kind of things, it takes time. Thank you a lot to @Baldanos and @Pelissier_S for this challenge.
Note: I have also published a solution using Hydrabus, the modern and maintained alternative to Bus Pirate.
*OMB: Oh My Britney