TL;DR: Yes, Anyone Can Decode Aircraft Datalink Traffic with ~$30 of Hardware
ACARS and VDL2 are unencrypted, unauthenticated broadcast protocols that carry real airline operational traffic in the clear. With an RTL-SDR dongle, an open-source decoder like acarsdec or dumpvdls2, and Wireshark for analysis, you can capture and read live aircraft messages from your desk today—no cracking, no exploits, just a receiver pointed at the sky.
Why Security Practitioners Should Care About ACARS and VDL2
Most cybersecurity professionals spend their days thinking about TCP/IP, TLS, and identity-aware perimeters. Aviation datalinks throw most of that out the window. The Aircraft Communications Addressing and Reporting System (ACARS) and its VHF Data Link Mode 2 successor (VDL2) move flight operations, weather reports, engine performance data, gate assignments, and company messages between aircraft and ground stations over plain VHF radio.
There is no encryption at the link layer. There is no message authentication. There is no replay protection. Anyone with a receiver can read everything, and—historically—researchers have shown that crafted uplinks were accepted by avionics without meaningful validation. This makes ACARS/VDL2 an ideal case study in unauthenticated broadcast surfaces: the same threat-modeling questions you’d ask about an unauthenticated UDP API, applied to the radio spectrum at 131 MHz. If you’ve read our coverage of protocol-level attack surfaces, the pattern will be familiar—trust is assumed because it always has been.
ACARS vs VDL2: Protocols, Frequencies and Encoding Basics
Classic ACARS uses amplitude modulation with Minimum-Shift Keying (MSK) at 2.4 kbps on designated VHF channels—131.550 MHz is the primary frequency in Europe, 131.475 MHz is common in North America, with additional regional channels around 130.025, 131.125, and 136.975 MHz depending on your location. Messages are short, addressed by aircraft registration or flight ID, and prefixed with label codes (like H1 for ACARS-to-ACARS or Q0 for ATC-related downlinks).
VDL2 (VHF Data Link Mode 2) is the digital successor. It uses D8PSK modulation at 31.5 kbps in 8.33 kHz channel spacing, with 136.975 MHz as a widely monitored ground frequency. Crucially, VDL2 carries the same ACARS upper-layer payloads—so from a content perspective you’re reading the same messages, just over a faster, CSMA-based link that carries far more traffic. VDL2 frames also include AVLC (Aviation VHF Link Control) elements with ICAO 24-bit addresses, which is useful for correlating with ADS-B.
Why does VDL2 matter? Bigger message loads, more automation, more ground stations—and, from a defensive standpoint, more of an airline’s operational nervous system flowing over a link that still lacks link-layer confidentiality or authentication.
Lab Hardware and Software Requirements
This is deliberately a low-cost lab. You need:
- Receiver: An RTL-SDR Blog V3 or V4 dongle (~$30–40). Any RTL2832U-based stick works, but the V3/V4’s improved front end helps at VHF.
- Antenna: A VHF whip or a simple dipole cut for ~131–137 MHz. Antenna placement matters more than any other variable. Indoors with a stock telescopic antenna, expect limited results.
- Host: Any Linux box (or WSL2 with caveats) with a USB port. A Raspberry Pi 4 works fine.
- Software:
git,cmake,libusb-1.0,librtlsdrdevelopment headers, andbuild-essential. OptionallySoapySDRif you want to support other SDR front ends. - Analysis: Wireshark for downstream message inspection.
Set expectations honestly: a rooftop dipole with clear horizon gets you hundreds of kilometers of range. A window-mounted whip in a city gets you enough to learn on. Ground-plane antennas you build from an SO-239 connector and four wire radials routinely outperform stock whips.
Installing and Configuring acarsdec
acarsdec (by TLeconte, hosted on GitHub) is the de facto standard open-source ACARS decoder. Build from source:
sudo apt install git cmake build-essential libusb-1.0-0-dev librtlsdr-dev
git clone https://github.com/TLeconte/acarsdec.git
cd acarsdec && mkdir build && cd build
cmake .. && make && sudo make install
Key configuration decisions:
- Input mode:
-rreads directly from an RTL-SDR device;-iconsumes an IQ stream over the network, letting you separate receiver and decoder hosts. - Multi-channel decoding: acarsdec can decode several adjacent ACARS channels simultaneously from a single 2.4 Msps capture, e.g.
acarsdec -r 0 -g 42 131.525 131.550 131.725 131.825. Specify channels without the-ooffset flag for multi-channel mode. - Gain: Start with hardware AGC or a manual gain around 35–42 dB and adjust based on decode rates. More gain is not better—overdriving the 8-bit ADC destroys decodes.
- Output:
-jemits JSON to stdout;-Nsends UDP JSON to a host:port, which is exactly what we need for Wireshark ingestion.-bwrites a raw packet format to a port instead.
A working invocation for the lab: acarsdec -r 0 -g 40 -j -N 127.0.0.1:5555 131.550
Installing and Configuring dumpvdls2
dumpvdls2 (also by TLeconte) is the VDL2 counterpart—think of it as dump1090’s philosophy applied to VDL Mode 2. Build it the same way from its GitHub repository, against the same librtlsdr dependency. It decodes D8PSK VDL2 frames, extracts AVLC information elements, and outputs both the link-control frames and the ACARS-over-AVLC payloads.
Configuration notes:
- Frequency: Start with 136.975 MHz, a heavily used ground frequency in many regions. Check region-specific frequency lists (the
VDL2channel tables on community wikis are a good start) for your area. - Sample rate trade-offs: VDL2’s 31.5 kbps D8PSK decoding is more CPU-sensitive than ACARS MSK. On a Raspberry Pi, dedicate the dongle and avoid multi-channel mode; on a desktop you’ll be fine.
- Output:
-jfor JSON lines,-bfor raw packets to a UDP port,-qto suppress per-frame console noise. Use-gfor gain just as with acarsdec.
The two tools differ in scope: acarsdec is ACARS-only and excels at multi-channel parallel decoding; dumpvdls2 speaks the VDL2 protocol stack and gives you AVLC-level visibility. Run both on separate dongles if you have them—VDL2 decoding typically requires the full receiver bandwidth for one channel.
Feeding Decoded Messages into Wireshark
Wireshark has no native ACARS dissector, so you bridge the gap with UDP payload export. Point acarsdec or dumpvdls2 at localhost:
acarsdec -r 0 -g 40 -N 127.0.0.1:5555 131.550
dumpvdls2 -r 1 -g 40 -b 127.0.0.1:5556 136.975
Then in Wireshark, capture on lo with filter udp.port == 5555. Each decoded message arrives as a UDP datagram whose payload is JSON (or a structured raw packet, depending on flags). Three practical approaches:
- JSON view: Use Decode As → UDP → DATA and enable the JSON dissector (
"Decode As"then filter onjson.value.string), letting you apply display filters likejson.value.string contains "BAW"for a specific airline code. - Hex view: For the
-braw format, each field sits at a known offset—label at one offset, registration at another—so simple display filters likedata[4:2] == 48:31isolate label H1 messages. - Custom Lua dissector: A ~30-line Lua script registering on the UDP port can extract
tail,label,msgno, andtextfields into named Wireshark columns. This is the cleanest option and a good exercise in protocol tooling.
Reading Real Captures: Message Types, Labels and Registration Numbers
A typical decoded ACARS message looks like this (abridged JSON):
{"timestamp":1735689600, "channel":2, "freq":131.55, "lvl":-12, "error":0,
"mode":"2", "label":"H1", "bds":false, "ack":false, "tail":"G-EUXM",
"flight":"BAW123", "msgno":"S21A", "text":"#CFBRI CLRNCE 321A ...n"}
How to read it:
- Downlink vs uplink: The
modecharacter and message number prefix (S= downlink from aircraft,_orM= uplink to aircraft) tell you direction. Aircraft registrations intailare your correlation key—cross-reference with ADS-B data. - Label codes:
H1(airline-to-airline messages),Q0(ATC/CPDLC-related),12(OCC-to-aircraft),B9/S2-style labels for weather and flight-plan uplinks. Label charts are published by ICAO and in airline engineering documentation. - What you’ll see: PDC (pre-departure clearances), out/off/on/in (OOOI) times, weather reports, engine trend reports, gate changes, maintenance codes. When PDC-by-DATALINK is active at an airport, you’ll see actual ATC clearances.
- What you won’t see: Passenger data, safety-critical voice, and military traffic. CPDLC over satellite datalinks (HFDL, SATCOM) uses different media entirely.
Mapping the Unauthenticated Attack Surface
Now the security analysis—and it’s sobering. At EuroControl and IEEE research venues over the past decade, academics including Strohmeier, Schäfer, Lenders, and Wilhelm (the team behind the OpenSky Network) documented practical attacks against ACARS and ADS-B: passive eavesdropping (trivially confirmed by this very lab), message injection into the uplink path, and replay, all enabled by the absence of link-layer cryptographic protections. Their published work demonstrated that ground stations historically accepted spoofed uplinks with no authentication challenge.
Enumerate the surface the way you would any unauthenticated protocol:
- Confidentiality: Zero. Everything is broadcast. Airline operational data, routing, cargo details—all readable.
- Integrity: Weak. No MAC, no signatures. Ground software must treat uplink contents as untrusted, but the protocol assumes goodwill.
- Replay protection: Absent at the link layer; message numbers are sequential, not cryptographic nonces.
Why hasn’t the sky fallen? Mitigations are procedural and architectural: ground systems validate flight IDs and message sequencing, CPDLC over newer datalinks (and future programs like ATN/IPS, which is adding network-layer security under ICAO’s data link modernization) introduces proper protections, and military links were never on ACARS in the first place. But the installed base of classic VHF ACARS remains a live case study in legacy-protocol inertia.
Blue-Team Takeaways and Defensive Framing
This lab’s value for defenders is threat modeling with ground truth:
- Anomaly detection via RF monitoring: If you operate aviation-adjacent infrastructure, passive monitoring of your own datalink channels establishes a baseline; unexpected uplink bursts or unknown addresses become detectable signals.
- Correlate with ADS-B: Matching decoded ACARS tails to ADS-B ICAO addresses (dump1090 on a second dongle) validates captures and builds a richer operational picture—the same cross-source correlation mindset you apply to SIEM data.
- Document integrity assumptions: If your organization consumes datalink-derived data (ETAs, fuel figures, position reports), write down the assumption that it’s unauthenticated. That single sentence changes procurement and architecture conversations.
CISA’s guidance on aviation cybersecurity, alongside ICAO Annex 10 and EuroControl’s ATN documentation, consistently frames datalink security as a roadmap item, not a solved problem. Your lab proves the roadmap is necessary.
Troubleshooting Weak or Zero Decodes
- Gain: The number one mistake. Back gain off until decodes appear; watch the
lvlfield in acarsdec output (aim roughly -25 to +1 dBFS, not saturated). - Antenna placement: Get near a window, elevate, and favor the horizon. Buildings block 131 MHz far more than people expect.
- Frequency check: 131.550 MHz is Europe’s primary; North America leans on 131.475 and 130.025 MHz. Zero decodes often just means the wrong channel for your region—monitor multiple channels.
- Local interference: USB3 ports, cheap power supplies, and monitors hash VHF. Use a USB extension and a powered hub, and check the noise floor in SDR software like SDR# or GQRX first.
- Verify the pipeline: Decode a known-good IQ recording (community-recorded ACARS sample files are widely available) before blaming your antenna. If the recording decodes and live RF doesn’t, it’s physical layer, not software.
- PPM correction: Calibrate your dongle’s frequency offset; a 50+ ppm error is enough to miss narrow VDL2 channels entirely.
Legal and Ethical Boundaries of Listening to Aviation Datalinks
Reception of ACARS and VDL2 is legal in many jurisdictions—the UK, most of the EU, and elsewhere permit listening to anything not specifically protected—but rules vary significantly by country, and some jurisdictions restrict interception of any radio communication regardless of content. Check your local law before building the lab. The bright line is transmission: transmitting on aviation frequencies, re-broadcasting decoded traffic, or interfering with licensed aeronautical services is illegal essentially everywhere, with severe penalties. This is a passive-only exercise. Messages you decode may contain proprietary airline data—treat captured content as confidential reference material for your own analysis, not something to publish or operationalize.
Frequently Asked Questions
Can you decrypt ACARS messages?
No decryption is needed. ACARS is transmitted in the clear with no link-layer encryption, so any receiver tuned to the right frequency with the right decoder can read it directly.
What is the difference between ACARS and VDL2?
ACARS is the older messaging protocol using AM with MSK modulation around 131 MHz at 2.4 kbps. VDL2 is its higher-speed digital successor, using D8PSK at 31.5 kbps on 8.33 kHz-spaced channels—and it carries the same ACARS application payloads over a CSMA-based link.
Is decoding aircraft datalink traffic legal?
Passive reception is legal in many countries, but rules vary and some jurisdictions restrict interception broadly. Transmitting on or interfering with aviation frequencies is illegal almost everywhere. Check local law and listen only.
How far can an RTL-SDR receive ACARS signals?
With a good antenna and line of sight to the horizon, ground-to-air VHF receptions at 100–300 km are common. Indoors with a stock antenna, expect dramatically less—possibly only overhead traffic.
Does Wireshark natively decode ACARS?
Not directly. You export decoder output as UDP payloads or structured raw packets and use display filters, the JSON dissector, or a custom Lua dissector to analyze the fields in Wireshark.
Related reading
- SSRF to Cloud Metadata: The Attack Behind Capital One and How to Stop It
- Weekly Threat Intel: Agentic AI Abuse, Fall 2026 Edge CVEs, and Infostealer Tradecraft
