fulldecent/system-bus-radio: Sending AM Radio From a Machine With No Transmitter

What system-bus-radio actually transmits, and who needs it

The project's premise is stated in its first line: it transmits radio on computers or phones without radio transmitting hardware. The README frames the audience around air gapping, the practice of removing internet, wireless, Bluetooth, USB, external storage and audio from a machine. The claim is that even in that state, a program can still put energy into the air.

The intended reader is not someone shopping for a radio stack. It is someone who needs a physical demonstration that a CPU executing ordinary instructions radiates, and that the radiation can carry a modulated signal a nearby receiver can decode. The README points to the TEMPEST guidelines published by the US National Security Agency and the US Department of Defense as the public background, and says the project simply adds to that discussion. That framing matters: the artifact is an argument, not a product.

A second audience is educational. A tune file plus a receiver is a cheap way to show that memory writes are electrical events with a spectrum. The repository invites readers to send results, including makes and models of all equipment involved, and to edit TEST-DATA.tsv directly through a pull request.

How CPU memory writes become an AM signal

The mechanism is narrower than the headline suggests. According to the technical explanation, emissions come from the `_mm_stream_si128` instruction writing through to a memory address. The README is explicit that this is a choice, not a requirement: replacing it with a simple `x++;` will work too, and the author's experience is that `_mm_stream_si128` produces a stronger signal. So the program is really a loop that generates switching activity on the bus, timed to shape a waveform.

That waveform is square wave modulation. The README includes an ASCII diagram showing a SIGNAL section and a CARRIER section separated in time, which is the key to how the receiver can tell the two apart. The carrier is the raw emission from the writes; the signal is the envelope the program imposes by turning that activity on and off.

The README lists the conditions a frequency must satisfy to reach the radio at all: emitted by the processor and other subsystems, escaped the shielding, passed through air or obstructions, accepted by the antenna, and selected by the receiver. Every one of those is a filter, and the program only controls the first. That is why the README describes the working frequency as found by trial and error rather than computed.

Timing is handled with platform APIs rather than a portable abstraction. The notes list Mach calls such as `mach_absolute_time()`, `mach_wait_until()` and `clock_sleep_trap()`, alongside `nanosleep()`, and reference `TIME_ABSOLUTE` and `TIME_RELATIVE` clock constants. The author also says it would be nice to improve the method to be more portable and not require SSE extensions. That is an open request, not a completed feature.

Building it and playing a first tune

The README gives the build path directly: enter the implementations folder, select any of them, and compile using `make`. There is no package manager step and no published release artifact beyond the 1.0.0 initial public release, so the source tree is the distribution.

make

The README's reference run is specific about hardware: a 2015 model MacBook Air, a Sony STR-K670P radio receiver with the included antenna, tuned to 1580 kHz on AM. Those details are not decoration. The frequency was found by trial and error for that equipment, and the README warns that different hardware will certainly have different frequency response.

Once built, the program takes a tune file as its argument. The README uses the bundled example:

./main ../../tunes/mary_had_a_little_lamb.tune

The expected result is the Mary Had a Little Lamb tune playing repeatedly. If you hear nothing, the README's own account of antenna placement is the first thing to reproduce: at the beginning the author placed the antenna directly on top of the number 4 key, which worked best on any AM frequency, and moving it back reduced the number of frequencies that worked until only 1580 kHz remained. There is also a browser version linked from the README for a quick look before you compile anything.

Range, hardware sensitivity and the portability gap

The most concrete limitation is range. On the equipment above, the author reports clear transmission over two meters of open air or one meter through drywall. That is a desk-scale result. Nothing in the README suggests it scales, and the list of conditions the emission must survive explains why: shielding, obstructions and antenna response all subtract from whatever the processor emits.

The second limitation is that the working frequency is an empirical property of a specific machine and receiver pair. The README states that different results will be achievable with different equipment, and that moving the antenna changed which frequencies worked. A reader who copies the command but not the hardware should expect a null result rather than a bug.

The third is portability. The implementation is built around SSE streaming stores and Mach timing calls. The README acknowledges the SSE dependency and asks for a more portable method. If you are on a platform without those primitives, the repository layout is your guide: implementations/ holds the variants, and tests/ and tunes/ hold supporting material, but the README does not document a portable fallback path.

Finally, the project is candid that this is a demonstration. The README asks readers to post test results using Raspberry Pi and other embedded systems, noting those may be good targets because of less shielding and hardening. That is an invitation because the data does not exist yet, not because a supported configuration exists.

How it differs from RTL-SDR and from GSMem

The repository ships an RTL-SDR-GUIDE.md, which makes the contrast concrete. RTL SDR is a receive path: a separate computer with RTL SDR hardware listens for system bus signals. That is the opposite direction from this project, which is the emitter. If your goal is to observe emissions rather than produce them, the guide in this repository is the relevant document, and the C program is not.

The closer comparison is GSMem, cited in the README as the inspiration for using `_mm_stream_si128`. GSMem, per that citation, is about data exfiltration from air-gapped computers over GSM frequencies. The difference is in ambition and in band. This project modulates a square wave onto a frequency chosen by trial and error, in the AM broadcast region where a consumer receiver can be tuned by hand. GSMem targets cellular frequencies. If you need to reason about a realistic exfiltration channel, the AM broadcast demonstration is a teaching artifact; the cited paper is the research.

A third option is simply not to use software at all. Any machine with a radio transmitter does this job properly, which is exactly the capability the air-gap scenario removes. The point of this project is the case where that option is unavailable.

Licence and the cost of keeping it running

The repository is MIT licensed. For a research tool that is permissive in the usual way: you can reuse and modify the code, and the licence text in LICENSE is the authority on terms. This is a statement about the project's licence file, not legal advice; if the emissions work matters to your organisation, the compliance question is about what you are transmitting and where, not about the MIT text.

Upgrade cost is low in the conventional sense because there is almost nothing to upgrade. The only listed release is 1.0.0 from 2016-10-27, the initial public release, and the last push to the repository was on 2026-03-18. There is no versioned dependency tree to track and no changelog to read between releases. What you do inherit is hardware coupling: the timing code targets Mach APIs and the emission loop targets SSE, so a platform move is a code change rather than a configuration change. Budget for that, not for dependency bumps.

Editorial conclusion

Use system-bus-radio if you are studying TEMPEST-style emissions, teaching how switching activity becomes RF, or reproducing the documented 1580 kHz result on the 2015 MacBook Air and Sony STR-K670P setup. Do not adopt it as a communication path: the README reports two meters of open air or one meter through drywall, the code depends on SSE streaming stores, and the repository's own notes ask for help making it portable. Before you build anything on it, confirm the tune file you intend to play exists under tunes/, confirm your receiver covers the band you are testing, and check TEST-DATA.tsv for a setup close to your hardware.

Frequently asked questions

Official sources

1. fulldecent/system-bus-radio on GitHub
2. License: MIT
3. Project website
4. README
5. Releases