$ cat writeup.md…
$ cat writeup.md…
hackthebox
Task: Analyze ATmega328p firmware dump to find what data was sent to a slave device. Solution: Disassemble Intel HEX firmware, identify bit-banged SPI pattern (MOSI/SCK triplets), decode transmitted bytes to reveal the flag.
$ cat /etc/rate-limit
Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.
Concerned about the integrity of devices produced at a remote fabrication plant, management has ordered a review of our production line. This revealed many things, including a weird embedded device in one of our serial networks. In attempting to remove it, we accidentally triggered a hardware failsafe, which resulted in the device stopping working. However, luckily we extracted the firmware prior to doing so. We need to find out what it did to the slave device it was tapped into, can you help us? The microcontroller of the device appears to be an atmega328p.
Provided files:
extracted_firmware.hex — firmware dump in Intel HEX format from ATmega328p microcontrollerThe firmware is provided in Intel HEX format. Convert to ELF and disassemble:
avr-objcopy -I ihex -O elf32-avr extracted_firmware.hex firmware.elf avr-objdump -D -m avr5 firmware.elf > disasm.txt
Key point: use -m avr5 — this is the ATmega328p architecture (AVR with 16-bit instructions, 16 KB flash).
Disassembly revealed a clear structure:
| Address | Contents |
|---|---|
0x00–0x67 | AVR interrupt vector table (26 vectors, all → reset 0x7c, except vector 0 → 0x68) |
0x68–0x7c | Standard C runtime init: clear r1, set SREG, initialize stack at 0x08FF, call main |
0x80–0x86 | GPIO initialization on PORTB |
0x88–0x8CA | Massive block of sbi/cbi instructions — this is the bit-banging |
0x8CC–0x8E8 | Clear lines and delay loop |
0x8EA–0x8EC | cli + infinite loop (halt) |
...
$ grep --similar