Editor’s Note: This post is written from the first-person perspective of a Zetier team member, reflecting on his experience at the DEFCON 2024 conference. We’re thrilled to celebrate this achievement with him!
For several years, I’ve dreamt of placing in a Capture the Flag (CTF) hacking competition at DEFCON. This was my 5th conference, and I came prepared. Months of planning and training paid off with success at the DEFCON 32 HHV CTF hosted by Hack The Box. You can read their team’s detailed writeup here.
Here’s a firsthand account of my experience:

My team and I registered through the HTB CTF (Hack The Box) portal under the name RS232Login>. The first three challenges were relatively straightforward, involving decoding .sal files to extract flags.
This task involved a networked service that relayed messages to a SPI flash bus on a Winbond W25Q128 chip via an FT2232HQ. Our goal? Overwrite a hash that was located at a specific address (persistent through reset) that was in MD5 format. We had to reference the Winbond part datasheet (click for a PDF download) and figure out which commands to send, then execute them in a Python script.
After sending some “peek” (read) commands, we were able to successfully read the entire flash out and start looking for the hash. We were looking for a 16-byte value (MD5 hash length) that had null terminators on both ends. After finding it at offset 0x401 — that’s 1025 for you decimal folk — we wiped the flash, enabled a write, and wrote to that location with the MD5sum for pizza.
The first time around, we forgot the null terminators; we struggled with that until we did a peek at 0x400/1024 and saw it was 0xFF/255. We wrote null terminators (0x00/00) and were able to connect back to another port on the target with Netcat, retrieving the flag.
Figuring this out took the brainpower of all three of us. Figure 2 contains the instructions for the Winbond flash memory we targeted.


Teammate #2 dropped us off back at our hotel for the evening, and #1 and I got to work. As #1 was trying to understand Challenge 10 and a few network services on the range, I was trying to make the hardware simple add-on (SAO) blink that Hack The Box gave us.
The goal: Program an AT32U4 to drive the LED with a one-second on-and-off period. Figure 3 (above) is a photo of the hardware the judges gave us to assemble and program.
First, I tried with my XGECU programmer (which the microcontroller is in the supported devices). I powered it up and… it was bricked. I soldered a bread tie to the MOSI pin and had access to the MISO and RST through a header, so I could use an Arduino as an ICSP. But all of my inventr.io HERO boards were not programming the bootleader correctly.
After doing chip off, bricking a few dev boards, and probably bricking the microcontroller itself, I passed out at 4 AM on Saturday. In the morning, I ended up supergluing a Raspberry Pi to the badge and ran GPIO pins directly to the SAO, making it blink.
The judges got a kick out of how large the badge was – and they awarded the points.
The next problem we solved was an error within a 6502 that was a jump indirect error. The challenge creators wrote one byte of the address (address was one word long) at the end of a page that ended in the next page.
From memory, the instruction was something like a jmp ($40ff). This would cause the processor to try to jump to whatever byte was stored in $40ff & $4000 when, in reality, it needed to jump to the address at $40ff & $4100. I stored the lower byte of the address into the accumulator, wrote the accumulator to $40fe, stored the higher byte of the address into the accumulator, and then wrote the accumulator to $40ff.
For some reason this was not functioning properly, so I rewrote the assembly to use the write addresses $3000 & $3001 (start of a page) and made the jump indirect to $3000 (which would be an infinite loop, but in this case, worked for the challenge). It gave me the flag in the console port.
The next challenge I took a crack at was a service that spit out binary 1s and 0s when connecting. The title was yoUART. This was some form of UART that just had to be decoded. I thought it was inverted, so I took every eight bits and flipped them.
This would prove incorrect.
So, I took the bits and reverse ordered them.
Nope, that wasn’t it either.
Ah, we were forgetting our transmission bits! Quickly, we put a parser together that would look for a start bit, stop bit, and parity bit. Very close. The start bit had to be a 0.
After some discussion among the community, we got the flag.
Now, our final problem. We were to send the correct commands over an I2C bus to brute-force a keypad that was attached to a microcontroller manually with a script. We had to set the channel to 35 on the SPI bus, toggle a GPIO to LOW, and dig into the source code and datasheets for more information on this abysmal keypad that was attached.
Eventually, we made up our keypad and built a list (base-14 by the way) that mapped to a dictionary that would send the relevant two-byte commands per keypress. We would send the commands and walk from the base value to the maximum with the keypad, pressing the # key every four keystrokes to submit to the microcontroller then read the LCD. There were timing issues on our first attempt.
Our output looked janky…
and we had to tweak some things…
but finally, 20 minutes before closing…
we got the flag.
This secured our third-place spot.
While this past year at DEFCON 2024 was an absolute success and met our goals of placing, my team and I look forward to future events. One day, I hope to win 1st place in a CTF hacking competition at the DEFCON conference. For those looking to participate in the challenges at DEFCON, it’s a great opportunity for training and networking. Happy hacking!
Enjoyed this article? Share on HackerNews →