The DEF CON 32 Badge
Table of Contents
1. Overview
The badge, as an object to be examined rather than worn. This note exists because a bench session on 2026-09-19 produced a clean negative, and a clean negative is worth keeping: the badge drew power over USB-C and never enumerated as a USB device.
That is the observation to explain, and the first thing to establish is whether it needs explaining at all.
2. What was actually observed
Recorded before any interpretation, because the interpretation is the part likely to be wrong.
| check | command | result |
|---|---|---|
| USB device tree | system_profiler SPUSBDataType |
three host controllers, no devices |
| enumerated devices | ioreg -c IOUSBHostDevice |
0 |
| serial nodes | ls /dev/cu.* |
only /dev/cu.debug-console, which is the Mac's own |
| mass storage | ls /Volumes |
only the system volume |
| Raspberry Pi silicon | ioreg -p IOUSB -l \vert grep 2e8a |
absent |
| hotplug, 75 s window | poll on ioreg, /Volumes, /dev/cu.* | no change |
| kernel USB log, 30 min | log show --predicate 'subsystem == "com.apple.iokit.IOUSBHostFamily"' |
no events at all |
The last row is the informative one. A device that connects and fails to enumerate normally still leaves a port-status change or a failed-enumeration entry. Total silence means the host never saw a connect event on the data lines.
Meanwhile the badge charges.
3. Why charging proves less than it appears to
On USB-C, power and data are independent, and this is the crux.
A sink negotiates power over the CC lines and draws current over VBUS. None of that involves D+/D-, and none of it involves the SuperSpeed pairs. So a badge that charges has demonstrated exactly two things: the cable carries VBUS and CC, and the badge's power path works. It has demonstrated nothing whatever about whether a USB device exists behind it.
Three ordinary situations produce precisely the observation above, and the first two are not faults:
- A charge-only cable. Common in conference swag, and it has no D+/D- at all. The host sees nothing because nothing is wired to the pins it watches.
- A device with no data interface until it is asked for one. Many badges expose USB only in a bootloader mode entered by holding a button while connecting, or double-tapping reset. Before that they are a battery with opinions.
- A dead or unpopulated USB peripheral, where programming is expected to happen over SWD/JTAG through a header rather than over the connector.
4. Open questions
None of these is answered yet. They are listed in the order that would resolve the most uncertainty per unit of effort.
4.1. What is the badge, in hardware terms?
The DEF CON 32 badge talk was given by Mar Williams
(event note, Fri 2024-08-09). What the board actually carries –
microcontroller, whether the USB connector reaches it, whether there is a
separate USB-serial bridge – is not established here, and the guess worth
testing first is a Raspberry Pi part, because that would enumerate under
vendor ID 0x2e8a and present a mass-storage volume in bootloader mode. Treat it as a hypothesis
with a cheap test attached.
4.2. Does the cable carry data?
The cheapest discriminator in the whole list, and it should be done first: substitute a cable known to carry data. If enumeration appears, everything below is moot.
4.3. Is there a bootloader entry sequence?
If the cable is good and the badge still does not enumerate, the question becomes what button combination exposes the interface, which is badge-specific and documented by whoever built it rather than derivable.
4.4. Is the USB connector wired to the MCU at all?
Continuity from the connector's D+/D- to the microcontroller answers this without powering anything, and it is the point at which the question stops being a software one.
5. Why this is on the research shelf rather than the events shelf
The event note records what happened at the conference. This records what the object does on a bench two years later, which is a different subject with a different failure mode: the event note can be wrong about a date, and this can be wrong about a mechanism.
It also generalises past the badge. "The device charges, therefore the cable and port are fine, therefore the fault is in the device" is an inference that fails on USB-C specifically, and it fails the same way for every USB-C peripheral anyone debugs. That is the part worth keeping even if this particular badge turns out to have a snapped trace.
6. Status
Placeholder. Nothing here has been confirmed against hardware, and the observation section is the only part that is evidence.