Hi everyone and welcome to this introduction to ACARS.
I'm an aeronautical engineer, pilot and hacker at Pentest Partners in the UK
and I lead our aerospace work and research program. I've had the honor of working in all
sorts of environments from government networks and consumer IoT through to planes, trains and
automobiles. What we're going to be talking about is an avionics system called ACARS,
which is really just a way of sending text messages between ground and airborne stations.
This is a light touch on the topic but I'll cover the history of it,
how it's transmitted, what it's used for and current airline ops, how to decode and decipher
it and explore where the potential security issues with it are. Really what ACARS is now
is a data link and this has become really important in keeping up the efficiency and
safety of modern aircraft. So the start of the jet age of commercial passenger flying in the 1960s,
communication was pretty basic. It was voice only between aircraft and the ground. Airlines did,
and still do, pay their flight crews by block time, which is the moment from the doors closing
and the aircraft taxiing now to the moment the doors open again at the arrival gate.
I think it's probably derived from when the ground crew pull the chocks or blocks out
from the wheels to allow the aircraft to move. In the 1960s and 70s, crews would radio their off-block
times to a human on the ground, who would transcribe that into a teletype machine
and send that onto the airline's base. Remember that airlines routinely fly into airports
where there's no direct representation of that airline on the ground, so some form of remote
communication is needed back to HQ. Looking for efficiency, I guess a euphemism for not paying
crews any more than they need to. ACARS was developed as a kind of automatic time clock
system, sending the details of the out, off, on, and in times by radio. Because radio is line of
sight only, ARINC, those who developed the standard, built out a network of ground-based
transmitters to send, receive, and reload those messages around. And this whole concept hasn't
really changed much to this day. So here we are today then. Plain old ACARS is broadly what it
was back in 1978. It uses a VHF radio and a network of ground transmitters to send these messages
around. A later evolution is ACARS over Aviation VHF Link Control, which is a terrible mashup of
acronyms. IT being aerospace. This still uses a VHF line of sight radios, but on a different
frequency to give a slightly higher bandwidth. For areas outside of direct ground contact,
like over the Atlantic, High Frequency Data Link, HFTL, can also be used, but it's very slow.
Nowadays we have SATCOM, which is increasingly the transmission mode of choice for many airlines
and aircraft. There is some experimentation with using the cellular GSM networks as an ACARS
platform too, but it's only in use for one European carrier, to my knowledge. There are
several classes of load, I suppose you would call them, in the ACARS network. The aircraft themselves
and ground stations like the airlines and air traffic control, as we'll see later.
In order to route a message from an aircraft flying over, let's say Spain, back to the airline
HQ in the UK, a Data Link Service Provider is paid to pick up, route, and deliver these messages.
You have two Data Link Service Providers, DSPs, to choose from, CITA and Rockwell. Rockwell bought
ARINC Inc., including the ACARS network, back in 2013, so you might see ARINC slash Rockwell
used interchangeably.
So as we've said, the original plain old ACARS, and ACARS over ABLC, used VHF radios, so a new
direct line of sight. And that includes the earth being round, of course, to a ground station.
Aircraft are often flying pretty high up, 35,000 feet or more, so actually the range of a single
transmitter is still quite large. But you can see from CITA's coverage map here, there are lots of
gaps over oceans, Africa, and places aircraft tend not to fly very much, like northern Canada.
Running all of these transmitters and maintaining the communications links between them
is pretty expensive. Satellite coverage is also dependent on where you are in the world,
although to a lesser degree. InMarsat have coverage between plus and minus 80 degrees latitude,
although Iridium have more lower satellites and can offer polar coverage too.
There are only 15 high frequency transmitters in the world. They have long reach and are located
for polar and oceanic coverage. The costs are a bit opaque, but one Asian carrier was paying
the equivalent of a thousand dollars per megabyte on their HF service. AOA and POA are still not home
broadband prices though, and there is a bit of an old adage in that for aviation you add another
zero onto the end of what seems a reasonable price for anything. Original ACARS uses a signal
with each bit encoded as a half bit sine wave on top of the carrier, which you can see in this nice
waterfall image that most software-defined radio signals will generate for you. The modem will
briefly listen to avoid transmitting at the same time as others and send a starting tone
and then the serial data. And you can hear this as a fairly distinctive old-school style modem noise.
As is VHF, a line-of-sight, each geographic region uses a different frequency.
And this is per data link service provider as well. So ARINC, Rockwell, in Europe is a different
frequency to CITER in Europe. And the aircraft's modem will usually automatically switch frequencies
between them based on its known position. VHF Data Link 2, so AI, is an enhancement that uses
phase shift keying modulation to give a slightly higher bandwidth throughput. It also uses the
X25 routing protocol to send messages between data terminals. And I guess this sort of matches
up with the lowest three layers of the OSI model, but this X25 predates TCPIP by some considerable
time. Because of the use of X25, there is a global single frequency, but as with planar ACARS, it's
VHF and so still line-of-sight. So several satellite communication service providers offer
ACARS, including Inmarsat and Iridium, both have global coverage. But as Inmarsat has
geostationary satellites, there is no reception between plus and minus 80 degrees latitude,
as we can see in their coverage map. Iridium has a larger constellation of lower flying birds
to give complete coverage even over polar regions. There are different bandwidth and frequency
options and services from each provider, but certain frequencies are better at penetrating
water. Although aircraft tend to fly above clouds and weather, and this is not usually a problem,
but in the tropics, humid air can block signals. It is possible to intercept ground-to-air,
that is ground-to-satellite-to-aircraft communications using a suitable antenna and
software, as a signal is transmitted to the ground over a wide area. But you will not be able to see
aircraft to ground, as you're not in a middle position unless you're in space. The data is
relayed from the ground stations back into the DSP networks and then on to its destination.
Classic aero services are quite bandwidth-limited, but we've probably all been on aircraft with
in-flight Wi-Fi by now, so SATCOM program actually can be quite decent, and it's this latter capability
that is now being used in modern E&A aircraft to collect huge amounts of live data for analysis
and predictive maintenance. There are also options to transmit ACARS over long-wave,
high-frequency transmitters, and this is reserved for oceanic and polar regions.
There are actually only 15 transmitter sites and speeds are incredibly slow,
and this probably also explains the very high costs of using these services.
There is an early test of using the CELIN networks to provide ACARS services in Europe.
This actually uses a piece of equipment found on many aircraft already, which is a wireless
quick access recorder or wireless digital flight data acquisition unit. These devices capture lots
of data in flight and then relay it back to the airline once they're on the ground over a 3G
network. This same unit can be upgraded to provide a wireless link and route ACARS over that instead.
Aircraft will often maintain multiple communication links, and for a transatlantic
flight an aircraft may actually have and use all three options at various stages of the flight.
A communications management unit, CMU, is used to route ACARS traffic between the various avionics
systems and these physical links. An airline may also change the cost preferences depending on how
much they pay for various services. This CMU has access to lots of important avionics including
display unit the pilot interacts with, the flight management computer for reporting location,
and for setting height or heading as we'll see later, and for acquiring lots of maintenance
data. And believe it or not there are actual genuine printers on the flight deck too.
A brief segue on to cell call. During transatlantic or polar flights where radio
communication is intermittent and to avoid crews from having to monitor radios for a long period,
cell call was introduced where the air traffic controller can trigger an alert light or sound
or both in the cockpit and the crew then jump on the radio to listen for the actual message.
Each aircraft is assigned a four-digit code and the first pair of letters sent as a tone and then
the second, which I guess is a bit like DTMF dialing tones. As you can see there aren't that
many possible combinations so there is reuse and it's really important that crews verify the
transmission was really meant for them. Similarly now when there is an ACARS message the crew will
hear a chime noise and a data link message will appear on the displays which they can then go and
read. ACARS at its basis is simply a text message service between two parties and this concept is
now being used in air traffic control. Rather than a controller using voice radios to instruct pilots
on what to do this is sent by a ACARS message. This has the benefits of efficiency which means
more aircraft can be accommodated in a given space but also safety you know there is no confusion in
hearing about what altitude to fly to or heading etc. Both Boeing and Airbus developed their own
standards but these were merged and gave rise to the FANS 1A standard as we have today. A FANS
installation on aircraft requires certification and a minimum latency requirement. Messages will
be automatically rejected after 30 seconds if no confirmation is made. FANS is comprised of
two important services which are both sent over ACARS and that could be either VHF or SATCOM.
Controller Pilot Data Link Communication CPDLC and Automatic Dependent Surveillance Contract ADSC.
So for CPDLC, air traffic can send pilots instructions to climb to a particular altitude
or steer a heading. Before this can happen, pilots log on to a specific controller which
then shows that the data link is ready. Every instruction sent by ATC requires a positive
confirmation by the pilot. You cannot simply send a message and remote control your plane.
Different regions still have different CPDLC adoption levels. So Europe has on-route services
whereas parts of the USA only have pre-departure at airports. And this latter is really useful
because if you've ever had to note down and read back a complicated departure clearance,
you'll realize how useful this is in not only time saving but in making sure it's correct.
You might be familiar with ADS-B which is the position notification signal sent out on 1090
megahertz which contains GPS position and altitude. And this is picked up by services
like Flight Radar 24 and ADS-B Exchange. These are periodically sent out by the aircraft when
it's illuminated by primary radar. But for fans, we need more granularity and information. So ADSC
is used instead. Air traffic can request an aircraft report its position or time when
passing a certain altitude or a given waypoint. ADSC will also show what waypoints the aircraft
is currently programmed to fly to. So controllers can better understand and more efficiently
sequence traffic for arrivals into busy airports. So now we know that more ACARS is useful in broad
terms, let's have a closer look at how the messages are formatted. In plain old ACARS,
all messages are broadcast to all devices, or those that are in range of the same transmitter
at least. So there is a header that lists the destination aircraft registration. The receiver
on an aircraft will discard any messages that are not destined for it. In the header,
there is a two-character label field which indicates the type of data that the whole
message contains. There's no specific standard but there are some common ones like C1 which is
a message for the onboard printer and indeed some airlines will use different labels to indicate
the same types of data. The bulk of the transmission is taken up by the message text itself
up to a maximum of 220 characters. The character set is basic ASCII alphanumerics and some special
characters only and no unicode. These could just be standard free text type messages or they could
be engineering and maintenance data and frankly more often than not it's the latter and are quite
dull as a result. Sequential messages are sent with an incrementing number in the header so C01,
C02 for example. Because of the 220 character limit, larger messages like our maintenance data
can be split across multiple ACOLs transmissions or with a letter suffix to note their position
in the multi-part message. So for example U10A, U10B, U10C etc. The next separate message
from this particular aircraft would then be U11A and so on. The last part of the message
is a simple checksum either ATM32 which is a modified form of Fletcher's checksum or a CRC.
The CDU on an aircraft will discard any message without a valid checksum and ask for a retransmit
if possible. The checksum is designed to protect against distortion of the message in transit only.
Given we are talking about radio data links here often over long distances there is potential for
garbled. You'll probably have noticed by now that all of the examples of message I've shown are
actually human readable and that's because there's no encryption of the data in standard ACOLs at all.
Some aircraft though do send encrypted messages and these are marked by the label type 44.
There is a really great paper called Economy Class Crypto from the Oxford Aviation Security
Group and they are able to decipher these messages through a combination of brute force
and other inputs such as knowing where an aircraft was at the time it transmitted the message.
What they are able to show is that there is a static cipher key in use across all of these
terminals so its brick ones decode everywhere. Fortunately it seems that this data is mostly
engineering rather than anything sensitive but operators of this equipment should be aware their
messages are definitely not private. As ACOLs offers arbitrary text messaging and is often
made available through cabin crew terminals it's common to see company type data like our second
message here. Fortunately this particular operator seems to be aware of the limitations of ACOLs
privacy and hasn't used names here just seat numbers but not everyone is this careful.
Software and hardware on aircraft is written to design assurance levels. This is I suppose the
code quality and testing that goes into that particular component depending on the risks
that it poses to the aircraft. These hazard levels are documented in DO 178C.
Although we've seen that ACOLs is important for efficiency both in air traffic and maintenance
it doesn't directly impact on keeping an aircraft safe and airborne.
This means that generally ACOLs components are into C or D levels of assurance.
Let's step through them where ACOLs is used in different phases of flight. Airlines will provide
routes to the air pilots to help them in choosing a fuel efficient routine or avoiding forecast
weather, turbulence, icing and so on. The airline itself back at HQ will often calculate the
aircraft takeoff performance speeds like V1 and V rotate based on the number of passengers, bags,
cargo loaded and then send this directly to the aircraft for review and acceptance.
Pilots will often do their own numbers too as a cross check. As we mentioned briefly air traffic
control can provide departure clearances via ACOLs which will be added to the flight management
computer once they've been checked by the pilots. The aircraft then fly that particular set of way
points, heights and speeds after takeoff to minimize noise and improve efficiency of airspace.
The aircraft itself has a large number of sensors attached to things like doors, cargo hatches
and weight and wheel switches so we can work out what state it's in. This is then used to send our
out, off, on and in data back to the airline for paying our pilots not a penny more than they deserve.
Once in the flight the aircraft will continually be sending quite a lot of data back to the
airline's maintenance teams and often the aircraft or engine manufacturer too so they can try and
predict any maintenance needed. The aircraft will also immediately report things like a tail strike
or hard landing so the aircraft can be properly inspected at the next landing. During cruise air
traffic control will be using ACARS and CPDRC to ask the pilots to change course, routing or headings
as they need to keep everything safe and efficient. CPDRC uses AOA, so X-25 routing as we've seen.
The source and destination addresses are 24-bit IKO Mode S identifiers which are unique
per aircraft and are the same ones you can see in ADS-B transmissions like on flight radar 24.
Ground stations also have an identifier and in this message, although I've redacted the aircraft,
29D1D7 maps to London Stansted Airport. In this case this is an acknowledgement from the aircraft
to Stansted saying Wilco, which is short for will comply or I will do this. And this is different
to a simple acknowledgement with no expectation that they need to do anything. Just prior to landing
the aircraft will obtain ATIS data, Automatic Terminal Information Service, which gives data
on the runway in use, temperature, surface wind and so on. Traditionally this has been an audio broadcast
but by using ACARS this data can be obtained earlier and help the crew prepare for the right
runway in use. CPDRC is not used when immediate responses might be needed. Remember it has a
maximum of 30 seconds latency. So this is ended with arrivals and airport controller taking over
via VHF voice. The airline will also use this position info to help prepare the gate and ground
crew, turn the aircraft around as quickly as possible, obtain any maintenance reports, they can
change parts out and then also be informed which aircraft is on stand for payroll. So how can you
look at these kinds of transmissions? Well for plain old ACARS, although we have a larger number
of frequencies and two service providers, the frequencies are quite close together. So we can
use software defined radio like HACRF, RTL-SDR or even a digital TV tuner to receive them all in one
go. If you look on github you'll find ACARS deck by Thierry Lecomte for RTL-SDR or the port
of the port ACARS-SDR play by Jan Katwik for HACRF. For aerials it's VHF so you will need line of sight
to the ground station but you will see lots of aircraft if they fly over you. A telescopic one
will do just fine and it works okay just placed in my office window frankly. For AOA you'll need
Jumper VDL-2 by Tomasz Lemich. This doesn't have direct HACRF support but you can use it through
SOPI-SDR. You'll need two SDR devices to receive and decode POA and AOA at the same time though
obviously. Many people have these little tools running on a Raspberry Pi or similar for long-term
capture and indeed many people re-share with others out on the internet. You can use the plane
plotter and Windows software to capture the output of the tools and draw the locations of aircraft
from a map and so on. If you use the dash-in or dash-output HACRF's PP switches with the
destination of the machine where plane plotter is running, this is all you need to do to capture
these messages. Just a quick note on the legality of receiving and decoding these HACRF transmissions.
In true internet fashion I am definitely not a lawyer and I'm in the UK so here's my take based
on prior law, prosecution and where I live. There are still a fair number of pages, yes pages, in use
in the UK mostly amongst the emergency services. Pager POCSAG data transmissions are quite similar
serial data structures to HACRF's and are also really easily decoded with RTL-SDR. These generally contain
really horribly sensitive data like patient and medical information and these are directed to
specific recipients. So just because you can it doesn't make it legal to decode POCSAG
in the UK. Plane or HACRF's is different because all messages have to be sent to all stations
before they can decode them and then decide whether they are intended to be for them
based on the registration number of the aircraft. AOA on the other hand uses x25
and a specific terminal address for the recipient. But the legislation in the UK says you can pick up
weather and navigation transmissions which parts of HACRF's demonstrably are. So frankly who really
knows. I don't really want to be the test case though so I've redacted any example messages in
this talk and I've unfortunately decided not to do a live demo just in case something sensitive
pops up. But please check with your local jurisdiction before you start decoding these
messages though. So I want to leave you kind of with a little thought experiment for discussions
in the comments. HACRF's messages seem an awful lot like TCP sequence numbers. Could you predict the
next in the sequence? Could you send a valid HACRF's message? Could you send a valid CPDLC message?
And what if you actually did? We've noted that there's no encryption and no integrity checks
or integrity checks rather are based on a checksign. If we were designing the system today
would we implement encryption or message signing? Are there any potential problems if we do?
And my final thought. Although we can see and potentially send HACRF's transmissions around
there are always humans in the loop. We cannot take control and make an HACRF do things.
And even if we did there are a lot of other mitigation to stop aircraft coming into conflict
like air traffic controllers, their radar and systems like traffic collision avoidance system,
TCAS. Yes it's a legacy system and protocol but these are vulnerabilities on the part of ARINC,
Rockwell or CITER themselves. But we should keep in mind that when we're designing systems
and protocols how things can end up being used 40 years on.
Thanks for listening and I look forward to hearing your comments and thoughts.