Capturing and Analyzing ADS-B Aviation Traffic with Wireshark and SDR

Aircraft are talking constantly, and to anyone with a $25 USB dongle willing to listen. Every commercial jet, cargo plane, and private aircraft equipped with a modern transponder broadcasts its GPS position, altitude, speed, and flight number in plain, unencrypted radio waves. No login. No credentials. No handshake. Just raw data flowing through the air at 1090 MHz. For developers and network security professionals, that makes aviation radio a genuinely interesting protocol study. This guide walks you through capturing those signals with a software-defined radio, decoding them into structured messages, and piping everything into Wireshark for packet-level inspection.

What ADS-B Is and Why Every Aircraft Broadcasts It

Automatic Dependent Surveillance-Broadcast is the system modern aircraft use to report their own position autonomously. Unlike traditional radar, which requires ground stations to actively ping aircraft and calculate their location, ADS-B relies on the aircraft doing the work. An onboard GPS receiver computes position, and a transponder broadcasts that data as a compact radio message roughly twice per second.

The signal carries much more than just location. Each transmission includes a 24-bit ICAO address that uniquely identifies the aircraft, plus altitude, speed, heading, and a squawk code. It transmits across 1090 MHz in Mode S format, which is the same radio mode used for secondary radar but extended with additional data fields. Reading about ADS-B technology explained gives you a thorough grounding in how cooperative surveillance replaced radar dependency in modern airspace management, and makes the hands-on capture steps that follow much easier to interpret.

In the United States, the FAA mandated ADS-B Out equipment across most controlled airspace by January 2020. European aviation authorities followed similar timelines. That means nearly every aircraft you see overhead in populated airspace is actively transmitting right now. On a good receiving day in a major city, a well-placed antenna can detect several hundred aircraft simultaneously.

The RTL-SDR Hardware That Opens the Radio Spectrum

A software-defined radio is exactly what it sounds like: a radio receiver where most of the processing happens in software rather than dedicated hardware circuits. The RTL-SDR family of USB dongles, based on the Realtek RTL2832U chip, became the entry point for this kind of experimentation after developers discovered these cheap TV tuner sticks could receive a wide frequency range, roughly 24 MHz to 1766 MHz.

For ADS-B capture, the RTL-SDR Blog V3 or any RTL2832U-based dongle with an appropriate antenna works well. You want an antenna tuned for 1090 MHz. Many kits include a telescoping antenna you can trim to roughly 6.9 cm for quarter-wave reception at that frequency. A magnetic-mount antenna purpose-built for the aircraft band outperforms the stock antenna significantly and is worth the small additional cost.

• RTL-SDR Blog V3 dongle with a good SMA connector and shielding for reduced USB interference
• 1090 MHz antenna, ideally a quarter-wave ground plane or a dedicated ADS-B whip antenna
• USB extension cable to position the antenna near a window or outdoors without significant cable loss
• Host machine running Linux, macOS, or Windows with the RTL-SDR drivers and Python 3 installed

Installing Dump1090 to Start Decoding Mode S Frames

Dump1090 is the most widely used open-source decoder for ADS-B Mode S messages. Originally written by Salvatore Sanfilippo, it has been maintained and forked by FlightAware and others into production-grade variants. The core function is direct: dump1090 drives the RTL-SDR hardware, reads raw I/Q samples from the dongle, demodulates the 1090 MHz signal, and decodes the Mode S message frames in real time.

On Ubuntu or Debian, installing the FlightAware fork is straightforward through the FlightAware PPA. For macOS, Homebrew carries a dump1090 formula. On Windows, a prebuilt binary with a built-in GUI is available directly from the dump1090 project page. Once running, dump1090 opens several TCP network ports on localhost by default. Port 30003 streams SBS-1 format messages as comma-separated lines. Port 30005 streams raw Beast binary frames. Port 30002 outputs raw Mode S hex strings, one per line, which is the format most useful for Wireshark integration.

The interactive map dump1090 serves on port 8080 is useful for confirming your setup is working. Aircraft should appear on the map within seconds of startup if you have a signal. Once you see them plotted, the decoder is working and the data is ready to be consumed by other tools downstream.

Routing Live Aircraft Data into Wireshark for Deep Inspection

Wireshark does not natively understand ADS-B Mode S protocol fields out of the box, but that does not stop you from using it as a capture and analysis tool. The approach is to capture the TCP stream that dump1090 outputs and analyze the raw message bytes, or to use a small intermediary script that repackages Mode S frames into a PCAP format Wireshark understands.

The cleanest method for most developers is capturing the raw hex stream from port 30002. A small Python script connects to dump1090 on that port, reads each hex message line, wraps it in a minimal PCAP record header complete with a timestamp, and writes the result to a named pipe. Wireshark reads that pipe live and updates its packet list as new messages arrive. The result is a live feed of aircraft transmissions displayed as discrete protocol records, refreshed in real time as planes move through your reception area.

For offline analysis, the same script can write to a PCAP file instead of a pipe. You accumulate an hour or two of traffic, then open the file in Wireshark at your own pace. This approach works well for studying specific aircraft behaviors, like how position reporting changes during approach or departure phases, without having to track live traffic simultaneously.

Reading the Protocol Fields in Each Captured Frame

Each Mode S message starts with a downlink format byte that identifies the message type. DF17 is the ADS-B extended squitter that carries position, velocity, and identification data. The 24-bit ICAO address follows immediately after the downlink format byte, identifying the specific aircraft. After that comes the message payload, and the frame closes with a 24-bit CRC for error detection. Decoding these fields manually in Wireshark’s hex editor teaches you the protocol structure faster than reading any specification document, because you are working with real aircraft in your local airspace rather than synthetic examples.

Choosing the Right ADS-B Decoding Software

Dump1090 is not the only option for pulling Mode S messages off the air. Several other tools exist, each with different platform support, output formats, and compatibility with downstream analysis tools. The right choice depends on your operating system, your preference for output format, and how tightly you need to integrate with Wireshark or other packet analysis pipelines.

Decoding Software Capabilities and Wireshark Compatibility

Software	Platform	Output Format	Network Port	Wireshark Ready
dump1090-fa	Linux, macOS, Windows	JSON, Beast binary, raw hex	30002, 30003, 30005	Yes, via PCAP pipe
rtl1090	Windows only	SBS-1 text, binary	30003	Partial, SBS-1 only
readsb	Linux, Raspberry Pi	JSON, Beast, raw hex	30002, 30005	Yes, via PCAP pipe
Virtual Radar Server	Windows, Linux, macOS	JSON API, KML, SBS-1	HTTP API	Via external adapter

Protocol Fields That Tell the Full Aircraft Story

Once live frames start appearing in Wireshark, knowing which fields to focus on speeds up your analysis considerably. ADS-B messages encode different information types in the same basic frame structure, differentiated by a Type Code field embedded in the message body. Understanding what each Type Code signals tells you instantly what kind of data you are looking at in any given capture.

• ICAO Address (bits 9 to 32): A 24-bit unique identifier tied to the aircraft’s registration, permanent and globally unique across the fleet
• Type Code (bits 33 to 37): Determines whether the message carries identification, surface position, airborne position, velocity, or operational status
• Compact Position Reporting pairs: Position is encoded across two alternating frames (even and odd), requiring both to compute actual latitude and longitude via the CPR algorithm
• Velocity fields: Encoded as separate east/west and north/south velocity components rather than a single speed and heading value, which you then reconstruct mathematically
• CRC checksum (final 24 bits): Used for error detection only, with no cryptographic properties whatsoever

The CPR position encoding is one of the more instructive aspects of the protocol from a developer’s standpoint. A single ADS-B frame does not contain a directly readable latitude and longitude. You need two consecutive frames of opposite parity to reconstruct position using the CPR decoding algorithm. Dump1090 handles this automatically, but tracing it frame by frame in Wireshark shows exactly how geographic coordinates get packed into compact bit fields, a technique that appears in other low-bandwidth telemetry protocols as well.

When the Sky Has No Firewall

The most striking thing about ADS-B from a security standpoint is what the protocol is missing entirely. There is no digital signature. There is no authentication header. There is no mechanism for a receiving station to verify that a message actually came from the aircraft it claims to represent. Any radio transmitter capable of generating a valid Mode S frame at 1090 MHz can inject aircraft positions into the airspace surveillance picture, and a receiver has no cryptographic basis to distinguish real transmissions from fabricated ones.

Security researchers have demonstrated ADS-B spoofing in controlled environments for years. A receiver sees phantom aircraft, fake flight paths, or deliberate position offsets applied to real aircraft. The protocol was designed in an era when spectrum access was expensive and hardware-based forgery was impractical. The attacker model simply was not a design consideration when the standard was written.

Reviewing ADS-B Out standards confirms that current regulatory frameworks focus on equipment performance and position accuracy, without addressing message authentication directly. ICAO working groups have studied ADS-B security enhancements at length, but deployed cryptographic authentication in the global aviation fleet remains an unresolved engineering and coordination challenge.

For the security-minded developer, ADS-B is a useful case study in how protocols designed for reliability and coverage can fail to account for adversarial conditions. The same architectural pressure appears across IoT sensor networks, industrial control telemetry, and vehicle-to-vehicle communications: broadcasting maximizes coverage, but verification adds complexity that original designs did not prioritize.

Capturing and analyzing ADS-B with a cheap SDR dongle and Wireshark takes an afternoon to set up. What it gives you is a live, real-world view into how an unauthenticated broadcast protocol operates at global scale. The aircraft overhead are not just traffic. They are a continuous protocol laboratory, transmitting freely, open to anyone willing to tune in.