Details withheld to preserve integrity of future course offerings.
Contact me for full write-up.
Overview
This was a simulated security audit against a company and device manufactured by the teaching staff of my Ethical Hacking course. The project was formatted as a CTF challenge on real hardware. We were provided an SoC board and tasked with applying the skills we learned throughout the semester to exploit the device and find all specified flags.
The Brief (in brief)
“The Node” is a line of IoT devices used by AVENGERS Manufacturing, Inc to collect data across their manufacturing floors. The client is concerned that sensitive data could be leaked from the device, and would like you to test their security. The client’s main concerns are with: a password protected internal debug shell, sensitive data stored in internal and external memory, and physical I/O streams. A fellow pen-tester has discovered a public GitHub repository with device specs, and talk of a USART accessible shell.
Skills & Tools
| Hardware | Software | OSINT |
|---|---|---|
| UART/Serial adapters | openOCD | Physical inspection |
| JTAG/SWD debugger | telnet | Datasheet analysis |
| SPI communicator | flashrom | Memory mapping analysis |
| Pinout/Signal identification | John the Ripper | |
| Reset button cycling | Ghidra |
The Task
While not a real production device, the board I was provided with came with operational firmware and 5 embedded flags. It was up to me to find any external resources I required and determine how to approach the audit.
Each flag was designed to represent one of the client’s security concerns, and are as follows:
UART Communication Flag
This flag was acquired by accessing and interacting with the device’s debug shell.
Password Cracking Flag
This flag was acquired by breaking the password protection of the debug shell, therefore revealing any sensitive information hidden behind it.
Internal Memory Flag
This flag was acquired by dumping and analyzing the firmware running on the board, therefore revealing any stored authentication secrets or sensitive data.
External Memory Flag
This flag was acquired by dumping and scanning the contents of an external flash memory chip, revealing all sensitive production data stored there.
I/O Stream Flag
This flag was acquired by finding and receiving the undisclosed communication method used by the device, allowing for a hypothetical long-term tap into sensitive data streams.
Bonus Decompilation
In order to prove the authenticity of our results the teaching staff provided a flag_to_proof command in the device’s debug shell. This command could take our discovered flag, which was the same across all boards, and give us a unique proof used to verify that our assigned board was used for the assignment.
While completing the project I noticed that this process was likely a simplified salt + hash scheme. This implied that the firmware had both a standardized hashing algorithm, and a device specific hash; the combination of which would produce this “unique proof”.
Since I had access to the full firmware binary and too much curiosity for my own good, I decided to hunt down the “unique proof” mechanism. Using ghidra and some reconnaissance help from a neat MCP server I experimented with, I was able to identify the hashing function in question. After painstakingly tracing the function and some ghidra based confusion, I found a pointer to the device’s obfuscated salt.
This extracurricular task was one of my favorite parts of the project, and was a great exercise in finding obfuscated secrets that could have been missed by standard analysis tools.