RF Attacks on Aviation's Last Line of Defense Against Mid-Air Collisions (TCAS II)
This talk demonstrates practical radio frequency (RF) injection attacks against the Traffic Alert and Collision Avoidance System (TCAS II) used in aviation. The researchers show how to manipulate TCAS II by spoofing transponder signals to trigger false traffic and resolution advisories, effectively disabling collision avoidance capabilities. The presentation highlights the lack of authentication and encryption in legacy aviation protocols and provides a methodology for testing these systems using software-defined radio (SDR) and custom hardware testbeds. The findings underscore the vulnerability of critical safety systems to low-cost, software-based RF attacks.
Why Your Next Flight Might Be Vulnerable to RF Spoofing
TLDR: Researchers at DEF CON 32 demonstrated that the Traffic Alert and Collision Avoidance System (TCAS II) is fundamentally insecure due to a lack of authentication and encryption in its legacy protocols. By using software-defined radio (SDR) and custom hardware, they successfully spoofed transponder signals to trigger false traffic and resolution advisories. This research proves that critical aviation safety systems can be manipulated with relatively low-cost, software-based RF attacks, exposing a massive gap in modern aviation security.
Aviation security often feels like a black box, shielded by the assumption that proprietary, expensive hardware is inherently secure. The reality is far more fragile. The Traffic Alert and Collision Avoidance System (TCAS II) is the last line of defense against mid-air collisions, yet it relies on protocols designed in 1987 that lack even basic authentication or encryption. If you can transmit on the correct frequencies, you can talk to the system.
The Mechanics of the Attack
TCAS II operates on a request-reply ranging protocol using the 1030 MHz and 1090 MHz bands. Ground stations and other aircraft interrogate a target, and the target responds with its altitude, range, and identity. Because the protocol is collaborative and lacks cryptographic verification, it is trivial to inject malicious traffic if you have the right hardware.
The researchers built a testbed using an SDR to simulate an aircraft transponder. The goal was to manipulate the TCAS II logic by injecting false signals that force the system to believe a collision is imminent. By precisely timing these responses, an attacker can trick the victim aircraft into triggering a Resolution Advisory (RA). An RA is a direct command to the pilot to climb or descend to avoid a collision. If you can force an aircraft to perform an unnecessary, abrupt maneuver, you have successfully compromised the safety of that flight.
Technical Constraints and Timing
The primary challenge in this research was not the RF transmission itself, but the timing constraints. The TCAS II protocol requires a response within a very narrow window of 128 microseconds. Standard SDR frameworks are designed for throughput, not latency, and they often introduce jitter that makes meeting these timing requirements impossible.
To overcome this, the team had to strip away everything that could introduce latency. They disabled power-saving features, hyperthreading, and GPU acceleration on their workstation. They even bypassed standard memory allocation routines, opting for a custom hugepages allocator to ensure the system could respond in real-time.
# Example of pinning a process to a specific core to reduce latency
taskset -c 1 ./tcas_spoofer --frequency 1090 --mode-s
By optimizing the software stack to this extreme, they achieved a response time within 0.2 microseconds, well within the protocol's tolerance. This level of precision is what separates a theoretical vulnerability from a functional, weaponizable exploit.
Real-World Applicability
For a pentester or security researcher, this research highlights the danger of "security through obscurity." Many aviation systems are protected by the belief that the barrier to entry is too high for anyone but a nation-state. This work proves otherwise. With roughly $10,000 in off-the-shelf hardware and a deep understanding of the Mode-S protocol, an attacker can achieve results that were previously thought to be impossible.
During an engagement, you would not be looking for SQL injection or buffer overflows. You would be looking for the ability to interact with the physical layer. If you are testing an IoT device or a critical infrastructure component that uses wireless communication, the lesson here is clear: if the protocol does not have built-in authentication, you must assume that any signal you receive is potentially malicious.
The Defensive Reality
Defending against this is difficult because the vulnerability is baked into the standard itself. You cannot simply patch a protocol that is hardcoded into thousands of aircraft transponders globally. The only path forward is a complete overhaul of the collision avoidance standards to include cryptographic identity verification. Until that happens, the aviation industry is relying on the fact that the barrier to entry for this type of attack is still higher than that of a typical web application exploit.
This research is a wake-up call. We are seeing the convergence of software-defined radio and critical infrastructure, and the results are exactly what we should expect when legacy protocols meet modern, accessible tooling. If you are working in this space, stop assuming that the physical layer is safe. Start testing your systems against the assumption that an attacker can inject any signal they want. The next time you look at a CVE related to radio protocols, remember that the impact is not just data theft—it is the potential for physical, real-world consequences.
Vulnerability Classes
Tools Used
Up Next From This Conference

Breaking Secure Web Gateways for Fun and Profit

Listen to the Whispers: Web Timing Attacks That Actually Work

Abusing Windows Hello Without a Severed Hand
Similar Talks

Unmasking the Snitch Puck: The Creepy IoT Surveillance Tech in the School Bathroom

Anyone Can Hack IoT: A Beginner's Guide to Hacking Your First IoT Device

