 Hi, everyone, and welcome to this introduction to ACARS. I'm an aeronautical engineer, pilot, and hacker at PENTA's 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 at the start of the Jeff Tage 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 pulled 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. It would transcribe that into a teletype machine and send that onto the airline space. 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 developed as standard, built out a network of ground-based transmitters to send, receive, and relay 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, 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 with one European carrier, to my knowledge. There are several classes of node, I suppose you recall, 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, CYTA and Rockwell. Rockwell bought Herring, Inc., including the ACARS network, back in 2013. So you might see Herring slash Rockwell used interchangeably. So as we've said, the original plain old ACARS and ACARS over ABLC use VHF radios, so 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 scientists 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. In Marsat, have coverage between plus and minus 80 degrees latitude, although Eurydium 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 $1,000 per megabyte on their HF service. AOA and POA are still not home broadband prices though. And there is a bit of an odd outage in the, for aviation, you add another zero onto the end of what seems reasonable price for anything. Original A-cars 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 a void 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 it's VHF, a line of sight, each geographic region uses a different frequency. And this is per data link service provider as well. So ARINC.ql in Europe is a different frequency to CYTA in Europe. And the aircraft's modem will usually automatically switch frequencies between them based on its known position. VHF data link two, so AOA, is an enhancement that uses phase shift keying modulation to give a slightly higher bandwidth through it. 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 this global single frequency, but as with plain RLA cars, it's VHF and so still line of sight. So several satellite communication service providers offer A-cars, including INMOSAT and Iridium, both have global coverage, but as INMOSAT has geostationary satellites, there is no reception between plus and minus 80 degrees attitude, 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 tends 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 the 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 onto its destination. Classic error services are quite bandwidth limited, but we've probably all been on aircraft with in-flight Wi-Fi by now. So SACCOM program actually can be quite decent. And it's this latter capability that is now being used in modern ENAWD aircraft to collect huge amounts of live data for analysis and predictive maintenance. There are also options to transmit over 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 satellite 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, said. 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 the display unit that the pilot interacts with, the flight management commuter 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 onto 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 actual 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 control using voice radios to instruct pilots on what to do, this is sent via an ACARS message. This has the benefits of efficiency, which means more aircraft can be accommodated in a given space, but also safety, in that there is no confusion in hearing about how to shoot a flight to or head in and so forth. 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 an 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 SACOM, 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 ahead. Before this can happen, pilots log on to a specific controller which then shows that the data link is ready. Every instruction sent by ADSC requires a positive confirmation by the pilot. You cannot simply send a message and remote control the 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 you're 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, 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 ADS-C is used instead. A traffic can request an aircraft report its position or time when passing a certain altitude or a given waypoint. ADS-C 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 what ACARS is used for 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 type 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 unique code. These could just be standard free text type messages, or they could be engineering and maintenance data. And frankly, more often 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 maintenance data can be split across multiple ACARS transmissions, or with a letter suffix to denote their position in the multi-part message. So for example, U10A, U10B, U10C, et cetera. 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 ATN32, 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, an article 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 cargo. You'll probably have noticed by now that all of the examples of messages I've shown are actually human readable, and that's because there's no encryption of the data in standard ACARS 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 Scooter Group, and they are able to decipher these messages through a combination of brute force and other inputs, 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 cypher key in use across all of these terminals, so it's brick-once decoded 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 ACARS 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 ACARS 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 ACARS is important for efficiency, both in air traffic and maintenance, it doesn't directly impact keeping an aircraft safe and airborne. This means that generally ACARS components are into C or D levels of assurance. Let's step through, then, where ACARS 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, high-sign, 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 ACARS, which will be added to the flight management commuter once they've been checked by the pilots. The aircraft then fly that particular set of waypoints, 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 waiting on wheel switches, so it can work out what state it's in. This is then used to send our out-of-on and in-data back to the airline for paying our pilots not up any 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, our traffic control will be using ACARS and CPDLC to ask the pilots to change course, routing, or headings as they need to keep everything safe and efficient. CPDLC uses AOA, so 25 routes in, as we've seen. The source and destination addresses are 24-bit IKO mode-ass 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, two 9D1D7 maps to London Standard Airport. In this case, this is an acknowledgement from the aircraft to Samsung saying Wilco, which is short for Wilcomply, 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, 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 runway in use. CPIDLC 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 how much the 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 the ACARS, RTL-SDR, or even a digital TV tuner to receive them all in Mongo. If you look on GitHub, you'll find ACARS deck by Thierry Laconte for RTL-SDR or the part of the port ACARS-SDR play by Jan Katwick for Hakarev. 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 telescope pick, one will do just fine and it works okay, just place in my office window frankly. For ALI, you'll need Dump FDL-2 by Tomasz Lemek. This doesn't have direct Hakarev support, but you can use it through SOPE-SDR. You'll need two SDR devices to receive and decode PLA and ALI 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 reshare with others out on the internet. You can use the plane potter, a window software to capture the output of the tools and drill the locations of aircraft from the map and so on. If you use the dash-n or dash-output ACARS-PP switches with the destination of the machine where a plane potter 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 ACARS 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 POC data transmissions are quite similar serial data structures to ACARS 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 POC-SAC in the UK. Plane-old ACARS is different because all messages have to be sent to all stations before they can decode them and then decide whether they're 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 whether a navigation transmissions, which parts of ACARS demonstratively 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. ACARS messages seem an awful lot like two CP sequence numbers. Could you predict the next in the sequence? Could you send a valid ACARS message? Could you send a valid CP DLC 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 checks on. 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 ACARS transmissions around, there are always humans in the loop. We cannot take control and make an aircraft 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, TICAS. Yes, it's a legacy system in Portugal, but these are vulnerabilities on the part of our Inc, Rockwell or site to 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.