← all write-ups
Investigationacquired · 8 min read

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.

fig. the investigation, start to finish

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.

fig. the Wireshark installer's USB Capture page: tick the box

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.

fig. the configuration descriptor: storage, audio, audio, HID. nothing else

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.

fig. the same four-step conversation, once a second, forever
fig. the ghost drive admits it's empty

Here’s the general shape of that conversation, step by step. Click a row for what it means.

⏱ simplified USB storage handshake (illustrative) · 6 events

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.

fig. keyboard vs. media keys: the descriptor tells you which one you've got

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.

fig. the descriptor, decoded byte by byte

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.

fig. the entire speaker. note the empty pads: one board design, many products

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.

fig. reading the chip: maker logo, year, batch

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.

fig. same chip, same firmware, different hardware

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.