I found a writeup of the
HackTheBox & CryptoHack Cyber Apocalypse 2021 I participated in at
How HackTheBoxCTF Exposed The Marriage of Saleae And Hardware - Equus 🐴 (Annie)
but I did some things a little different so I decided to share how I did it.
Serial Logs
After downloading the challenge file (currently available from
https://github.com/TheEquus/HackTheBoxCTF2021-Hardware-Files/raw/main/hw_serial_logs.zip)
I looked in it:
$ unzip -l hw_serial_logs.zip
Archive: hw_serial_logs.zip
Length Date Time Name
--------- ---------- ----- ----
60104 2021-04-16 17:08 serial_logs.sal
--------- -------
60104 1 file
And I had no idea what a .sal file is. It is a zip file:
$ file serial_logs.sal
serial_logs.sal: Zip archive data, at least v2.0 to extract
Searching some more hinted at logic analyzer file and I found
Logic Analyzers from Saleae
which has a
Logic analyzer Software from Saleae
page including a try before you buy version of the software for several
operating systems including Linux.
Opening the .sal file in the application gave a lot more results, I could look
at the recorded signals. Because that is what a logic analyzer does: it records
binary signals in hardware.
In the software it is easy to decode async serial protocol. So I did that.
In the challengetext it says
We have gained physical access to the debugging
interface of the Access Control System which is based on a Raspberry-Pi based
IoT device.
I looked up the default settings of the Raspberry Pi serial port which are
115200 bps, 8 bits, no parity, 1 stopbit. Using those settings I could decode
the datastream and start looking in it. Out came several big hex values and
a remark
"[ERR] Noise detected in channel. Swithcing baud to backup value".
Searching for the big hex values found a page about files removed from the
google index because of DMCA takedowns. I tried more than one and ended up
at the
same list of removals. An easter egg? But not the
solution.
The baud rate of the second part was different. But what was it? I did the
calculations the hard way (bit timings) and found out it was
74184 baud, 8 bits, even parity, 1 stopbit. Using those settings I decoded
the second part of the datastream and found data:
11.606151920000000,C,,
11.606313660000000,H,,
11.606475379999999,T,,
11.606637120000000,B,,
11.606798860000000,{,,
11.606960580000001,w,,
11.607122320000000,h,,
11.607284060000000,4,,
And that is the beginning of the flag. And it was the right flag.
Compromised
This turned out to be I2C protocol. I used the I2C analyzer in the saleae
software and started seeing data including something with
CHTB{
but there was too much data. I looked some more and noticed the ending
} data comes after an address selection of
0x2C.
$ egrep -A1 'address.+0x2C' i2c-export | grep data | awk -F, ' { print $5}'
This gave me a hexdump of the data. I decoded this to the flag.
Secure
This was something with data on a microSD card. Some searching found the
description that microSD cards use the SPI protocol. Which signal was which
took a bit of searching. When I found the clock I could find the rest after
that. Decoding the signals as SPI protocol gives a lot of data.
In the data is clearly data being read from an SD card with a FAT16 filesystem.
After some searching in the results I found the flag.
Off the grid
There was a clear explanation that this was the SH1306 OLED display. I could
set up the pinout right, but I couldn't find a datasheet easily on how to
proceed.
No score.
Discovery
This challenge had no .sal files but two docker images. One that didn't let me
in with http basic auth and one that didn't let me in with an Advanced Message
Queuing Protocol (AMQP) server. I did not find the way in even with a lot of
staring.
No score.
Hidden
Two files in the challenge:
firmware and
hidden.sal.
The file
firmware turns out to be a Raspberry Pi executable:
$ file firmware
firmware: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=572cbaa2da38724b97a40ec009c2e5b4ca452be4, not stripped
and I tried this on a raspberry and after a few tries it was clear it wants
to write a datastream to a serial port. I gave it a serial port and traced
the output with strace:
$ strace -xx -s500 -o strace.AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC ./firmware.AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC /dev/ttyUSB0
The port was set to 57600 baud, 5 bits, even parity, 2 stopbits. Running the
async serial decoder in the logic analyzer on the
hidden.sal file gave
output different from what the program sends to the serial port. In the program
was a
CHTB{AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA} and I guessed
changing the flag in the program changed the output somehow. It indeed did but
I couldn't figure out what the mapping of flag bits to output bits was. Being
tired in the evening didn't help.
No score.