Reverse Engineering TrojPix: EM Exfiltration from Air-Gapped PCs at 208 Meters

TrojPix in one sentence: what the report says and what is still unverified

The supplied report says TrojPix is an electromagnetic exfiltration technique that can pull data off an air-gapped PC from up to 208 meters away. That is the main claim.

What I can actually confirm from the material here is narrower:

• the title and summary describe an EM side-channel attack
• the target class is air-gapped computers
• the reported distance is 208 meters

What I cannot confirm from the snippet alone:

• the exact malware mechanism
• the test setup
• whether 208 meters was measured in a lab, in line of sight, or under ideal antenna conditions
• whether the figure is a maximum range, a repeatable average, or a one-off result

Separate confirmed reporting from inference

Confirmed: the report is about exfiltration via electromagnetic leakage, not via the network.

Inference: the technique likely depends on a malicious process modulating CPU activity or another internal component so the machine emits a detectable RF pattern. That is a common shape for this class of attack, but I am not treating it as proven for TrojPix without the original research write-up.

Confirmed: the target is an air-gapped machine.

Inference: if the attack is real and repeatable, the attacker’s practical requirement is not internet access. It is physical proximity, a receiver, and enough time to collect a usable signal.

Why the 208-meter claim matters to defenders

The number matters because it moves this out of the “only someone touching the box can do it” bucket. If a signal can be read from hundreds of meters away, then a perimeter wall, a parking lot, a neighboring office, or a hostile vehicle outside the facility may be enough.

That does not mean every air-gapped environment is suddenly easy to exploit. It means distance alone is not a control. Defenders need to think in terms of shielding, placement, monitoring, and operational discipline, not just “no cable, no risk.”

How electromagnetic exfiltration from an air-gapped machine is supposed to work

The basic signal path: malware, CPU activity, emissions, receiver

At a high level, the chain is simple:

1. malware runs on the isolated host
2. the malware shapes some repetitive hardware behavior
3. that behavior causes a measurable electromagnetic emission
4. a nearby receiver picks up the pattern
5. the attacker decodes the pattern into bits

The exact hardware path varies. In the literature around this space, attackers have used CPU load modulation, bus activity, power-state changes, and other timing or activity shaping. The key point is that the host does not need a network stack for leakage to happen. Any active electronics can become a transmitter under the right conditions.

Why this is not the same as network-based exfiltration

Network exfiltration is about abusing trusted paths the defender already knows exist: HTTP, DNS, cloud sync, USB bridges, email, or agent callbacks.

EM exfiltration is different in three ways:

• the transmission path is physical, not logical
• the receiver may be outside the facility boundary
• standard network controls do not see the leak

That last point is the real problem. If the data leaves through radiation, your firewall, proxy, and CASB may all be healthy while the secret still walks out the door.

What the published details appear to imply about the attack setup

The attacker side: proximity, receiver sensitivity, and line-of-sight assumptions

A 208-meter claim implies a serious receiver setup, even if the victim side is simple.

My read is that the attacker likely needed:

• a sensitive antenna or SDR-class receiver
• careful tuning to the emission band
• a path with low enough interference to decode the signal
• enough physical access to place the receiver in the right spot

Whether line of sight is required depends on frequency, shielding, and the local environment. I would not assume line of sight is always mandatory, but I also would not generalize a single lab number into “works anywhere.” Buildings, vehicles, walls, and ambient RF noise matter a lot.

The victim side: what kind of host activity would create a usable signal

For the victim machine, the attack is usually easiest when the malware can force a stable, repetitive pattern. In practice, that often means some kind of tight loop or workload shaping that changes power draw and electromagnetic leakage in a predictable way.

That leads to two defender-relevant observations:

• idle machines may not be safe if the malware can wake them up or keep them busy
• low network activity does not mean low risk if the CPU or another component is being used as the transmitter

What I would treat as confirmed only if the original write-up shows it

If the original report does not show these details, I would treat them as unverified:

• the exact bit rate
• the antenna and receiver model
• the bandwidth used
• whether the 208-meter result was repeatable
• the effect of walls, windows, and nearby interference
• whether the attack required prior local execution privileges or a specific software stack

Those details determine whether this is a lab curiosity or a field threat.

Why air gaps reduce risk but do not eliminate it

The security assumption air-gapped teams usually make

The usual assumption is straightforward: if a machine has no network path, remote theft is off the table.

That is a good assumption for many threat models, but it is incomplete. Air gaps mainly remove easy exfiltration channels. They do not automatically neutralize:

• removable media
• maintenance laptops
• physical access
• acoustic leakage
• optical leakage
• electromagnetic leakage

The mistake is treating isolated as inert.

Where that assumption breaks down in practice

It breaks down when attackers can get code onto the machine and can observe the machine from outside the trust boundary.

That may sound hard, and often it is. But hard is not the same as impossible. In a sensitive facility, the real question is not “can this happen at all?” It is “what risk remains after physical controls, media controls, and monitoring have already done their job?”

For many organizations, that residual risk is low enough to accept. For others, especially defense, research, critical infrastructure, and government environments, it may not be.

How to test for EM-side-channel risk without turning the post into an abuse manual

Safe lab validation ideas for defenders

You do not need to build an exfiltration chain to learn something useful.

A safe defensive test looks like this:

• use an isolated lab machine you own
• run benign workload changes that are authorized for testing
• place a receiver in a controlled area
• compare the RF noise floor during idle, CPU load, and mixed workload conditions
• record whether any band shows repeatable modulation

A minimal capture workflow might look like this:

rtl_power -f 30M:300M:1M -i 5s -e 10m baseline.csv

Run the same capture again while the test host is under a known, authorized workload. The point is not to extract data. The point is to see whether the emissions change enough to justify stronger shielding or zoning.

What measurements matter: distance, noise floor, and repeatability

The three measurements that matter most are:

A one-time spike is not the same as a reliable side channel. Repeatability is the real concern.

What not to overclaim from a single lab result

Do not jump from “I saw emissions change in my lab” to “the machine is exploitable in production.”

That leap ignores:

• physical layout
• shielding
• ambient interference
• receiver quality
• operator skill
• workload differences
• whether the signal can carry meaningful data at all

A careful report should say what was demonstrated and what was not.

Defensive controls that actually change the risk

Hardware and facility controls: shielding, zoning, and receiver suppression

If the threat matters in your environment, the most effective controls are physical:

• use shielded rooms or racks where justified
• separate sensitive systems from exterior walls and windows
• control sight lines and receiver placement opportunities
• apply zoning so the closest credible receiver is much farther away
• evaluate emissions against your own facility geometry, not a generic lab

This is classic TEMPEST-style thinking: reduce the signal, increase the distance, and limit where an attacker can stand.

System controls: workload hardening, least functionality, and device control

On the host itself:

• remove unnecessary software
• minimize local execution opportunities
• restrict unapproved code paths
• disable or tightly control peripheral access
• keep the machine on a minimal, purpose-built image
• prevent users from running arbitrary tools on sensitive systems

These controls do not eliminate EM leakage, but they can make it much harder to create a useful modulation pattern.

Operational controls: monitoring, physical access, and clean-room procedures

Operations matter as much as technology.

• log and review physical access near sensitive assets
• control where maintenance equipment can be placed
• prohibit unvetted radios, SDRs, and similar receivers near protected zones
• use clean-room procedures for data transfer when the environment demands it
• treat temporary access to the room as part of the attack surface

Detection and incident response considerations

Indicators that are realistic to look for

You will not usually detect EM exfiltration directly from the endpoint alone. More realistic indicators are:

• unexpected physical proximity to sensitive systems
• unusual maintenance or placement of RF-capable gear
• unexplained workload patterns on isolated hosts
• unauthorized software execution on the air-gapped machine
• facility access anomalies around the suspected window

If you run RF surveys, baseline them first so you can tell normal noise from suspicious changes.

Why classic endpoint detection may miss this class of attack

EDR is good at process and behavior telemetry. It is not a spectrum analyzer.

If the malware uses legitimate processes, schedules its activity carefully, or lives in a place your EDR barely watches, you may only see a mild CPU anomaly. The actual leak is happening in physics, not in the logs.

What to preserve if you suspect a side-channel leak

If you suspect this kind of compromise, preserve:

• host logs and process timelines
• physical access records
• badge logs
• camera footage where available
• RF survey data
• hardware inventory and any nearby unknown devices

The receiver side may be outside your normal incident-response scope, but it is part of the evidence chain.

My take: this is a real niche risk, not a reason to panic

When the threat is worth serious investment

I would take this seriously when:

• the data is genuinely sensitive
• the machine is truly air-gapped
• the facility can be physically approached from outside
• the adversary model includes well-resourced operators
• the cost of a leak is far higher than the cost of stronger physical controls

In that world, EM leakage is not a theory. It is part of the threat model.

When the 208-meter headline is more alarming than practical

I would be more cautious about the headline if:

• the result came from a narrow lab setup
• the receiver was unusually good
• the signal required a very specific environment
• the bit rate was low enough to be operationally awkward
• the attack depends on prior code execution that is itself already hard to achieve

That does not make the issue fake. It makes it situational.

Conclusion: the useful lesson for security teams

The useful lesson is not that air gaps are dead. It is that air gaps are a control, not a guarantee.

A short checklist for people responsible for sensitive offline systems

• assume physical leakage is part of the threat model
• verify what your facility allows a receiver to observe
• reduce host functionality on sensitive systems
• keep untrusted devices away from protected zones
• baseline the RF environment before you need it
• preserve physical and RF evidence if you investigate a suspected leak

If TrojPix is as effective as the headline suggests, the defensive answer is not panic. It is to stop treating isolation as a binary state and start managing the full side-channel surface.