The scenario
The 2026 eCTF challenge tasks each team with building a Hardware Security Module (HSM), a dedicated embedded device for secure file storage and encrypted device-to-device file transfer. The HSM runs as firmware on the TI MSPM0L2228 microcontroller and exposes two distinct interfaces to the outside world.
Management Interface
PIN-protected channel for user interactions such as creating files, managing permissions, and retrieving status.
Transfer Interface
Device-to-device channel for secure file exchange between HSMs over a direct UART connection.
Host Interface
Serial connection to a host computer running organizer-provided tools to initiate operations and read results.
The security model is built around permission groups. Every file stored on an HSM belongs to a group, and each HSM holds differentiated permissions per group: receive (request files from other devices), write (create new files), and read (return file contents to an authorized user). Crucially, an HSM can store files it has no read permission for, deliberately separating data possession from data access.
The competition runs in two phases. During the design phase, teams implement and harden their HSM firmware, earning flags through an automated testing service that validates both functional correctness and security properties. In the attack phase, teams receive boards provisioned with every other team's firmware and attempt to break their security implementations to capture flags. Each team therefore defends its own design while actively attacking everyone else's.
What I worked on
Three pieces of work this season: one hardening change during the design phase, then in the attack phase, one attack I ran against other teams' devices and one I researched without finishing. The unfinished one went after the PIN check, which is the same gate the team spent the design phase trying to make unbreakable.
Hardening: unpredictable memory layout
On the defensive side, I explored randomizing the order of functions in the compiled binary so the firmware's memory layout is less predictable. Because the device runs a fixed image, runtime address randomization (ASLR) isn't available, but shuffling function placement at build time is a static analogue that makes it far harder for an attacker to reliably overflow a buffer into a known, useful location.
Attack phase: UART man-in-the-middle
During the attack phase I targeted teams that left their Transfer Interface unencrypted. By sitting in the middle of the UART link between two HSMs, I could intercept and relay traffic to capture sensitive data in transit, directly exploiting the missing confidentiality our own design was built to provide.
Attack research: timing work toward fault injection
The PIN check is the single gate in front of every privileged operation on the device, and a constant-time comparison does nothing to stop you if you can make the processor skip the comparison altogether. That makes voltage fault injection the obvious thing to point at it: drop the supply rail for a very short window, at exactly the right moment, and the core mis-executes.
I did not get a glitcher built inside the competition window. What I did do was the measurement work underneath one: bench work on an actual eCTF board, using an external light source as a repeatable trigger reference to establish when the operations I cared about actually happen. The hard part of glitching is not the glitch, it is knowing the moment to fire it, and that timing is the piece that carries forward.
I looked at electromagnetic fault injection as the alternative and settled on voltage glitching, on accessibility grounds: I could build the rig myself, I would have direct physical access to the board's supply rail, and as a first attempt at fault injection it was the easier of the two to reason about. Building it is the plan for next year's competition.
The team's design
For context on what I was defending: the HSM the team shipped encrypted every stored file under a freshly generated AES-CBC key, then wrapped that key with the file group's ECC public key, so a device can hold a file it is cryptographically unable to read. Transfers used a challenge-response handshake, with an AES-CMAC-signed nonce bound to the slot and file-group ID, so a device cannot pull files it has no receive permission for. Both were built on wolfSSL / wolfCrypt. Those pieces were a collaborative design effort across the team.
The PIN path is the part worth detail, because it is what the attack phase comes for. PINs are stored only as SHA-256 hashes and verified with a constant-time comparison, so a flash leak never exposes the PIN and timing analysis cannot walk it out byte by byte. A brute-force lockout with a cooldown, designed to persist across power cycles, closes the power-cycling shortcut. UART read and write paths are bounded by explicit maximum lengths and slot indices are range-checked, which is what keeps a malformed request from overflowing a buffer or the file table.
Tufts finished 19th out of a field of roughly 100 teams in the 2026 competition.