Two secrets, one tiny screen

The badge looks playful because it is: two badges can “mate” their light patterns by showing each other a pair of QR codes. Underneath that exchange is a small RISC-V computer, protected storage, authenticated encryption and a shared secret. The fun question was whether a sealed badge would give up either of its two prizes.

It did—but not over USB or serial. In the end, the most reliable output device was the badge’s own 128×128 OLED. We made it blink eight bytes at a time and filmed the screen with a phone.

First: what does badge “mating” do?

The first badge displays a request QR containing a fixed header and a fresh 12-byte nonce. The second badge creates a nine-byte gamete from its light genes, pads it to 16 bytes, and protects it with AES-256-GCM-SIV under the shared exchange key. The encrypted response QR goes back to the first badge, which authenticates it, mixes those incoming traits with its own, and lets the owner choose Keep or Revert.

The two targets

K0 is why one browser can now act like a virtual mate: once it knows the badge’s request nonce, it can make a valid encrypted gamete response. K0 does not unlock the badge’s encrypted filesystem by itself, and recovering it did not mean AES had failed. We had to get the badge to do the protected work for us.

The foothold: an unsigned jump

The loader image has a signed body, but its first 132 bytes are outside the signature. That space includes the very first jump instruction executed after validation. Boot1’s update console can write those RRAM bytes before boot, so changing just that jump redirected execution into a small payload while the rest of the signed loader still validated.

That gave us machine-mode execution on our own badge, but machine mode alone was not the finish line. The hardware guard identifies callers from their virtual-memory context. The payload built the same user-mode, ASID-3 identity used by the trusted keystore service, read the protected data there, then returned to machine mode to display it.

We did not break AES or directly punch through the hardware ACL. We gained code execution, then recreated the identity the guard was designed to trust.

Turning the screen into a data link

By this stage USB was gone and the usual debug paths were unavailable. The payload therefore drew each eight-byte page as an 8×8 bit grid: one byte per row, most-significant bit on the left. A page marker, a known UUID control, and CRC values let the decoder reject bad frames instead of trusting a visually plausible result.

Flag1 needed six tagged pages: one diagnostic page, one control page and four data pages. The K0 path used seven. It first reconstructed the badge’s PDDB master-key inputs on-chip, authenticated the wrapped .System key with AES-KWP, initialized the external flash in QPI mode, then swept decrypted pages for the exchange-key record. A published SHA-256 prefix narrowed candidates; a full captured AES-GCM-SIV tag authenticated the final key.

What mattered

1. Unsigned control flow is still control flow. Excluding a signature header is dangerous when executable bytes live inside it.
2. Privilege is not identity. The successful read required the exact trusted user-mode context—not merely “more privilege.”
3. A control must test the same claim. A readable UUID proved the display path, while authenticated AES-KWP and GCM-SIV checks proved the protected results.
4. A screen can be a protocol. Page tags, repetition and CRCs turned shaky phone video into dependable bytes.