SPECTER Is Mostly Not a Physical Attack

What SPECTER does

The paper — SPECTER: Covert Data Exfiltration from Air-Gapped Systems via USB Power Modulation, by Hyeongjun Choi, Ji Hyuk Jung and Ji Won Yoon (Korea University and 78ResearchLab) — went up on arXiv on 20 October 2026, with a revised version on 28 October.[1] Its threat model starts late. The adversary already has code running with root or administrator rights on an isolated host; how it got there, and how it got those rights, is explicitly out of scope.

From there the transmitter does nothing exotic. On Ubuntu it writes the kernel’s USB power-control and autosuspend settings; on Windows it disables and re-enables devices through the standard device-management tooling. No payload travels in USB data transfers, and no peripheral hardware or firmware is modified.[1] (One news write-up says the opposite on that last point; the paper is clear.[3]) A device in its active state is a 1, an inactive one a 0. Three receivers read the result:

These are laboratory demonstrations. The paper reports no systematic error rate and no effective throughput after framing, and the RF channel was never shown to work at a distance.[1][2] At these speeds nobody exfiltrates a database. What fits through is a short secret: a key, a token, a password.

The tempting reading

The obvious classification has two steps, and the first one is not in dispute. Foreign executable content runs on the host, so R-EXEC requires a #7 Malware step at the moment of execution.[4] Everything before it — the initial compromise, the privilege escalation — the paper leaves open, and so does the path: an unresolved gap, ….

The second step is where it goes wrong. The bits leave as charge, light and radio, and #8’s definition covers “exploitation of physical phenomena/emanations.”[4] Add R-SPECIFIC — a specific generic vulnerability beats the residual #1 — and the verdict seems to write itself: … → #7 → #8 + [DRE: C], for all three receivers.

That is the reasoning of a mapper who asks “is something physical involved?” instead of “what does the attacker exploit?” We have seen where it leads.

The test Spectre left behind

When we took Spectre out of #8, the correction came with a discriminator, and it is now the substrate clause of R-SPECIFIC in the v2.7 core.[5][4] A physical-layer property of the substrate — charge, voltage, electromagnetic emission, temperature, emission-borne timing, wear, material state — makes a step #8 when it is itself the exploited generic vulnerability. Where the physical layer only carries the readout, the step is classified by whatever was actually exploited.

The test never asks whether the attacker is near the machine. Rowhammer is mounted from software and stays #8; Spectre is mounted from software and is #2. And it never asks whether the signal is physical — every signal is. It asks whether the physical property is the thing being abused.

Three receivers, two clusters

Run SPECTER’s three receivers through that test and they come apart.

The radio receiver. A USB cable is not designed to broadcast its device states at 5 MHz. It does so because switching currents radiate. With ideal shielding the antenna hears nothing; the channel is gone. The emission is the exploited property, which is exactly what #8’s signal vector — energy through the medium — describes. #8, and as a bridge cluster it carries a boundary.

The mouse LED, the webcam. An LED is designed to be seen. A mouse that stops responding when its port is disabled is doing what it was built to do. Make the physics ideal and nothing changes: the LED still goes dark on command, and anyone with line of sight still sees it. No physical property is being abused. What is being abused is a designed function — software-controlled device state — carrying data it was never meant to carry. That is #1 Abuse of Functions, the same verdict our CWE mapping gives covert timing and storage channels: a path that exists by design, used as a channel.[5][6]

The charging state. Same answer. A phone is designed to detect whether its port delivers power and to show it. Ideal physics leaves that intact; the phone still reports charging on, charging off. #1.

Written out in full:

… → #7 → #8 ||[physical][@External→@Org]|| + [DRE: C]      // RF receiver
… → #7 → #1 + [DRE: C]                                   // LED, webcam, charging state

The … is an open analytical task, not a cluster. It stands for the compromise and privilege escalation the paper assumes; in a real incident it would be replaced by classified steps as the evidence comes in.

The receiver decides the cluster

Here is the part that looks odd at first. The transmitter is the same code in every case: it toggles the same USB devices through the same operating-system interfaces. Yet one run is #8 and another is #1.

That is not an inconsistency. TLCTC classifies a step by the generic vulnerability that makes it succeed, and a covert channel succeeds only when the bits reach someone. Which property carries them across is set by where the attacker listens. An antenna at the cable exploits emission. A camera pointed at an LED exploits a designed indicator. The code that modulates is the same; what is exploited is not.

It also settles why the RF path has no #1 in it. Toggling device states is designed functionality in both cases — but on the RF path it is only how the foreign code induces the physical effect, and the core says so directly: where foreign code executes in order to induce a physical effect, the path is #7 → #8.[4] Rowhammer has the same shape: the hammering loop is ordinary memory access, and nobody writes #7 → #1 → #8 for it. On the LED path, by contrast, there is no physical vulnerability left to induce. The designed state is the channel, so the designed function is the thing exploited.

What the split does not change

The #7 step is the same on every path. Each classified step asserts its own System Risk Event: the foreign code running is a loss of control on the host, and the channel step is a second one. The Data Risk Event is [DRE: C], and it happens at reception — when the bits reach an unauthorised party — not when the LED first blinks.

No Business Risk Event follows from the paper. SPECTER demonstrates a channel. It does not describe an organisation losing anything, and a path drawn from it should stop at the DRE. What an organisation would lose depends on which secret leaks — and that points to the realistic continuation. Nobody spends twenty minutes trickling out 256 bits for their own sake. A leaked key or token gets used, and credential use is always #4 (R-CRED):[4]

… → #7 → #1 + [DRE: C] → #4

The interval is minutes, not seconds. At 0.25 bit/s a 256-bit key needs about seventeen minutes on the wire; at the mouse channel’s 1 bit/s, a little over four — before any framing or error correction, which the paper does not measure. For a defender that is a long causal interval, and an unusual one: a detection window that sits inside the leak rather than after it.

Why the split matters to a defender

The point of putting a step in the right cluster is that each cluster has its own control lever and its own owner. SPECTER’s three receivers do not answer to the same one.

The paper’s own recommendations — treat USB power and device-state events as security telemetry, audit repeated enable/disable/suspend cycles, restrict software-controlled state changes — are mostly #1 controls, which fits: two of its three channels are #1. It does not test whether they work.[1] And they share a weakness worth stating plainly: telemetry collected on the host the attacker already controls with root rights is evidence the attacker can shape. Collection off the host is worth more than any detection rule on it.

None of the shielding helps against the LED, and none of the USB policy helps against an antenna on a cable the policy never sees. An “air-gap exfiltration” line in a risk register would hide exactly that.

One more lever sits outside the cluster table altogether. Controls that act on the data rather than on the step — a key held in a hardware security module, never present in host memory — belong to the Data Risk Event, row C. A secret that is not on the host cannot leak at any bit rate.

The same lesson, one letter later

Spectre taught us that where a flaw lives does not tell you what the attacker abuses. SPECTER adds the matching lesson for channels: how the bits travel does not tell you either. Charge, light and radio are all physical. Only one of them is a physical vulnerability.

A covert channel is classified at the receiver: the property the attacker listens to is the property being exploited.