I Plugged in a $20 Speaker and Wireshark Showed Me a Ghost Drive
A cheap USB speaker showed up as an empty drive. Here’s how Wireshark’s USB capture, a few tests, and a screwdriver showed what was really going on.
We had a USB speaker hit the bench that did something odd: plug it in, and Windows showed a brand-new storage device with zero bytes and no media. In a SOC, that first thought is always BadUSB. A device pretending to be something it isn’t is exactly what you don’t ignore, so we pulled it apart.
Here’s the whole investigation at a glance before we get into it.
You can actually sniff USB like it’s network traffic
Here’s the thing that genuinely made our day: we didn’t know Wireshark could do this. You think of Wireshark as a network tool: packets on a wire, IP addresses, ports. But it turns out there’s a USB capture component built right in, and it lets you watch the raw conversation between the host and the device as it happens. Every descriptor exchange, every control transfer, every SCSI command and the status it gets back, all of it live in the same interface we use every day for network work.
Once we realized that, the whole investigation changed. Instead of guessing what the device was doing from the outside, we could sit there and read it talking to the computer in real time. It felt a bit like getting X-ray vision for something we plug in a dozen times a day and never think about. That alone made the case worth it.
What the device claimed to be
When a USB device connects, it introduces itself with a set of descriptors that basically say “here’s what I am and what I can do.” This little speaker declared three personalities: an audio interface, which you’d expect, a media-key input device, which is common on speakers, and a mass-storage interface, which you wouldn’t.
That’s the full list, and it’s just as useful for what’s missing. No vendor-specific channel, no firmware-update interface, no network or wireless interface. Whatever this thing was, it couldn’t phone home.
| # | Interface | What it does |
|---|---|---|
| 0 | Mass Storage (0x08) |
The “ghost drive” |
| 1 | Audio Control (0x01) |
Volume and mute |
| 2 | Audio Streaming (0x01) |
Plays sound from the PC (16-bit stereo, 48 kHz) |
| 3 | HID (0x03) |
Media keys |
What it actually did
That storage interface is what tripped the alarm. But when the host asked for the disk, the device answered with a SCSI status of “Medium Not Present,” the same thing an empty card reader says when there’s no card in the slot. It claimed to be storage, but nothing was behind it.
Here’s the general shape of that conversation, step by step. Click a row for what it means.
- The device introduces itself: vendor, product, and how many configurations it has.
- This is where the speaker declared its interfaces, including Audio (class 0x01) and Mass Storage (class 0x08).
- Windows sees a mass-storage interface and creates a drive for it, which is why the empty "ghost drive" appears.
- The device answers like a normal disk or card reader.
- The device fails the check with a CHECK CONDITION status.
- Sense key NOT READY with "medium not present" (3A/00). Same answer as an empty card reader: storage interface, nothing behind it.
Then we tried to break it. We dragged a file onto the drive. Windows started the copy and sat at 0%. In Wireshark, not a single READ or WRITE command ever went to the device. Windows never even tried, because the drive kept saying there was nothing there. You can’t write to a disk that doesn’t exist.
Could it type commands?
The scarier BadUSB trick isn’t storage at all. It’s a device that quietly pretends to be a keyboard and types commands faster than you can blink. This speaker did declare an input device, so we pulled its HID report descriptor, which is the device’s exact list of “keys” it’s allowed to send.
It came back as 51 bytes of media controls and nothing else: volume, mute, play/pause, next and previous track.
Usage Page 0x0C (Consumer), not 0x07 (Keyboard). No letters, no shortcuts, and no way for the PC to send it
data back.
The funny part: the speaker has no buttons. It advertises sixteen media keys it physically can’t press. That turned out to be a big clue.
To be sure, we left it plugged in and untouched for ten minutes with a capture running. Zero bytes of key data.
Opening it up
Software can only tell you so much, so out came the screwdriver. The whole board is one chip, two small audio amplifiers, and some supporting parts. No card slot, no extra memory chip, no second processor, no radio.
The chip has a “JL” logo, which is Zhuhai Jieli Technology, a Chinese company that makes cheap audio chips for tons of unbranded speakers and headsets. Its date code and the date printed on the board both say 2020.
Why it happened
Our read: the speaker runs on a cheap, general-purpose chip reused across a whole family of products, including MP3 players that genuinely have onboard storage. This soundbar inherited the firmware’s storage interface without the hardware to back it up, a leftover declaration nobody trimmed out. Lazy firmware, not a payload.
The evidence lines up. The same vendor ID lists a sibling product that’s literally an “MP3 Player.” The board has no slot. The drive always reports no media. And the media keys with no buttons are the exact same pattern: template features with no hardware behind them.
What we checked
| Concern | Result |
|---|---|
| Types commands like a keyboard (BadUSB) | No. Media keys only |
| Hidden storage | No. No slot, no memory chip, always “no media” |
| Reads or writes data | No. Zero READ/WRITE commands |
| Network or wireless | No. No interface, no radio |
| Firmware-update channel | No. Not declared |
| Does anything on its own | No. Silent for 10 minutes |
Wireshark filters we used
If you want to try this on your own sketchy USB gadget, these are the filters that did the work:
usb.idVendor == 0xe2b7 # find the device (use your device's vendor ID)
usb.device_address == 21 && usb.bDescriptorType == 0x02 # full interface list
usbms || scsi # storage traffic only
scsi.sbc.opcode in {0x0a 0x2a 0xaa 0x8a} # any write attempts? WRITE(6), (10), (12), (16)
_ws.col.info contains "HID Report" # what the input device can do
usb.device_address == 21 && usb.transfer_type == 0x01 && usb.data_len > 0 # did it send anything on its own?
The takeaway
An empty drive looks scary, but the descriptors and SCSI responses tell the real story. Watch what a device claims to be, then watch what it does when you ask it to prove it. And when software can’t settle it, open the case. Sometimes a ghost drive is just a $20 speaker wearing a hand-me-down firmware costume.