On the surface, speakers play sound and microphones capture it. But older and simpler audio hardware can blur that line. A research project called SPEAKE(a)R showed that, under the right conditions, malware can retask certain PC audio jacks and use connected headphones or earphones like rough improvised microphones.
This topic came back into view after Adafruit highlighted the story. The original work comes from the 2017 USENIX paper SPEAKE(a)R: Turn Speakers to Microphones for Fun and Profit, with the full PDF available here. There is also an arXiv version if you want a quick abstract and citation page.
Why this works at all
The key idea is simple: many speaker and microphone designs use very similar physical parts. In reverse mode, a speaker can generate a signal from vibration, while a microphone turns vibration into a signal by design. That does not make every speaker a great microphone, but it does explain why the trick is physically possible in the first place.
The researchers focused on modern PCs with audio chipsets that support jack retasking or jack remapping. In plain terms, that means software can change a port from output mode to input mode. If malware gets that control, it can try to turn a headphone jack into a recording path.
What the SPEAKE(a)R research showed
The paper describes malware that reconfigures the audio path so connected headphones, earphones, or simple passive speakers can act as microphones. The researchers explain that many common PC audio codecs supported this kind of retasking, especially the Realtek families they tested. Their measurements showed that intelligible human speech could still be captured, and the paper reports eavesdropping at distances up to nine meters in test conditions.
That is what makes the work interesting from a security angle. Even if a machine has no dedicated microphone attached, or the usual microphone path is disabled, muted, or covered, audio hardware behavior can still create another route for sound capture if the system is vulnerable and already compromised.
Important limits people should know
This does not mean every desktop speaker suddenly becomes a spy device. The paper notes an important limit: the effect is mainly relevant to headphones, earphones, earbuds, and passive speakers. Many self-powered speakers have an internal amplifier, which blocks the signal path needed for this reverse use case.
It also does not mean the audio quality is perfect. The recovered sound is far weaker and rougher than what a real microphone gives. Still, from a defensive view, “good enough to understand speech” is already a serious problem.
Why this matters for makers and PC users
For makers, this is a good reminder that hardware features are not always limited to their usual labels. A port marked for output may still be flexible at the chipset level. For everyday users, the lesson is even simpler: security is not only about obvious parts like cameras and built-in microphones. It is also about how drivers, codecs, and firmware can change what connected hardware is allowed to do.
The paper lists several possible defenses, including disabling the audio codec in BIOS or UEFI when it is not needed, enforcing stricter driver policy around jack retasking, and detecting suspicious out-to-in retasking behavior. Those fixes can reduce risk, but they also trade away ease of use.
Quick takeaway
The idea sounds strange at first, but the research is real: under the right conditions, some connected audio devices can be pushed into doing a job they were not meant to do. That does not turn every speaker into a perfect microphone. It does, however, show why low-level hardware features deserve just as much attention as apps and visible peripherals.
Read the original sources
- Adafruit post: Turning speakers to microphones by hackers
- USENIX presentation page
- USENIX PDF paper
- arXiv abstract page
Related parts and topics
If you want to explore more audio and embedded projects, you can browse audio modules, microphone parts, and ESP32 boards on Circuitrocks.
Featured image note: use the supplied featured image file based on Figure 1 from the USENIX paper.
