[00:05.920 --> 00:09.720] Hi everyone and welcome to this introduction to ACARS. [00:10.900 --> 00:15.400] I'm an aeronautical engineer, pilot and hacker at Pentest Partners in the UK [00:16.320 --> 00:21.680] and I lead our aerospace work and research program. I've had the honor of working in all [00:21.680 --> 00:27.240] sorts of environments from government networks and consumer IoT through to planes, trains and [00:27.240 --> 00:33.440] automobiles. What we're going to be talking about is an avionics system called ACARS, [00:33.440 --> 00:38.660] which is really just a way of sending text messages between ground and airborne stations. [00:39.280 --> 00:42.400] This is a light touch on the topic but I'll cover the history of it, [00:42.400 --> 00:48.100] how it's transmitted, what it's used for and current airline ops, how to decode and decipher [00:48.100 --> 00:54.880] it and explore where the potential security issues with it are. Really what ACARS is now [00:54.880 --> 00:59.060] is a data link and this has become really important in keeping up the efficiency and [00:59.060 --> 01:07.300] safety of modern aircraft. So the start of the jet age of commercial passenger flying in the 1960s, [01:07.300 --> 01:13.640] communication was pretty basic. It was voice only between aircraft and the ground. Airlines did, [01:13.640 --> 01:19.080] and still do, pay their flight crews by block time, which is the moment from the doors closing [01:19.080 --> 01:23.960] and the aircraft taxiing now to the moment the doors open again at the arrival gate. [01:24.140 --> 01:28.140] I think it's probably derived from when the ground crew pull the chocks or blocks out [01:28.140 --> 01:34.780] from the wheels to allow the aircraft to move. In the 1960s and 70s, crews would radio their off-block [01:34.780 --> 01:39.500] times to a human on the ground, who would transcribe that into a teletype machine [01:39.500 --> 01:45.940] and send that onto the airline's base. Remember that airlines routinely fly into airports [01:45.940 --> 01:50.880] where there's no direct representation of that airline on the ground, so some form of remote [01:50.880 --> 01:56.840] communication is needed back to HQ. Looking for efficiency, I guess a euphemism for not paying [01:56.840 --> 02:01.400] crews any more than they need to. ACARS was developed as a kind of automatic time clock [02:01.400 --> 02:09.040] system, sending the details of the out, off, on, and in times by radio. Because radio is line of [02:09.040 --> 02:14.220] sight only, ARINC, those who developed the standard, built out a network of ground-based [02:14.220 --> 02:19.380] transmitters to send, receive, and reload those messages around. And this whole concept hasn't [02:19.380 --> 02:27.420] really changed much to this day. So here we are today then. Plain old ACARS is broadly what it [02:27.420 --> 02:33.500] was back in 1978. It uses a VHF radio and a network of ground transmitters to send these messages [02:33.500 --> 02:41.480] around. A later evolution is ACARS over Aviation VHF Link Control, which is a terrible mashup of [02:41.480 --> 02:48.220] acronyms. IT being aerospace. This still uses a VHF line of sight radios, but on a different [02:48.220 --> 02:54.820] frequency to give a slightly higher bandwidth. For areas outside of direct ground contact, [02:54.820 --> 03:01.530] like over the Atlantic, High Frequency Data Link, HFTL, can also be used, but it's very slow. [03:02.300 --> 03:06.760] Nowadays we have SATCOM, which is increasingly the transmission mode of choice for many airlines [03:06.760 --> 03:12.840] and aircraft. There is some experimentation with using the cellular GSM networks as an ACARS [03:12.840 --> 03:19.400] platform too, but it's only in use for one European carrier, to my knowledge. There are [03:19.400 --> 03:25.460] several classes of load, I suppose you would call them, in the ACARS network. The aircraft themselves [03:25.460 --> 03:30.580] and ground stations like the airlines and air traffic control, as we'll see later. [03:30.860 --> 03:37.120] In order to route a message from an aircraft flying over, let's say Spain, back to the airline [03:37.120 --> 03:43.820] HQ in the UK, a Data Link Service Provider is paid to pick up, route, and deliver these messages. [03:44.320 --> 03:51.560] You have two Data Link Service Providers, DSPs, to choose from, CITA and Rockwell. Rockwell bought [03:51.560 --> 03:58.240] ARINC Inc., including the ACARS network, back in 2013, so you might see ARINC slash Rockwell [03:58.240 --> 03:59.880] used interchangeably. [04:01.780 --> 04:09.240] So as we've said, the original plain old ACARS, and ACARS over ABLC, used VHF radios, so a new [04:09.240 --> 04:14.580] direct line of sight. And that includes the earth being round, of course, to a ground station. [04:14.940 --> 04:20.360] Aircraft are often flying pretty high up, 35,000 feet or more, so actually the range of a single [04:20.360 --> 04:25.860] transmitter is still quite large. But you can see from CITA's coverage map here, there are lots of [04:25.860 --> 04:33.040] gaps over oceans, Africa, and places aircraft tend not to fly very much, like northern Canada. [04:33.660 --> 04:37.280] Running all of these transmitters and maintaining the communications links between them [04:37.280 --> 04:42.780] is pretty expensive. Satellite coverage is also dependent on where you are in the world, [04:42.780 --> 04:48.540] although to a lesser degree. InMarsat have coverage between plus and minus 80 degrees latitude, [04:48.540 --> 04:55.860] although Iridium have more lower satellites and can offer polar coverage too. [04:56.040 --> 05:02.240] There are only 15 high frequency transmitters in the world. They have long reach and are located [05:02.240 --> 05:09.260] for polar and oceanic coverage. The costs are a bit opaque, but one Asian carrier was paying [05:09.260 --> 05:16.620] the equivalent of a thousand dollars per megabyte on their HF service. AOA and POA are still not home [05:16.620 --> 05:22.220] broadband prices though, and there is a bit of an old adage in that for aviation you add another [05:22.220 --> 05:29.220] zero onto the end of what seems a reasonable price for anything. Original ACARS uses a signal [05:29.220 --> 05:34.780] with each bit encoded as a half bit sine wave on top of the carrier, which you can see in this nice [05:34.780 --> 05:40.840] waterfall image that most software-defined radio signals will generate for you. The modem will [05:40.840 --> 05:46.160] briefly listen to avoid transmitting at the same time as others and send a starting tone [05:46.620 --> 05:53.070] and then the serial data. And you can hear this as a fairly distinctive old-school style modem noise. [05:54.800 --> 05:59.990] As is VHF, a line-of-sight, each geographic region uses a different frequency. [06:00.360 --> 06:07.280] And this is per data link service provider as well. So ARINC, Rockwell, in Europe is a different [06:07.280 --> 06:13.080] frequency to CITER in Europe. And the aircraft's modem will usually automatically switch frequencies [06:13.080 --> 06:22.540] between them based on its known position. VHF Data Link 2, so AI, is an enhancement that uses [06:23.080 --> 06:28.860] phase shift keying modulation to give a slightly higher bandwidth throughput. It also uses the [06:28.860 --> 06:34.600] X25 routing protocol to send messages between data terminals. And I guess this sort of matches [06:34.600 --> 06:41.980] up with the lowest three layers of the OSI model, but this X25 predates TCPIP by some considerable [06:41.980 --> 06:50.180] time. Because of the use of X25, there is a global single frequency, but as with planar ACARS, it's [06:50.180 --> 06:59.100] VHF and so still line-of-sight. So several satellite communication service providers offer [06:59.620 --> 07:06.660] ACARS, including Inmarsat and Iridium, both have global coverage. But as Inmarsat has [07:06.660 --> 07:11.180] geostationary satellites, there is no reception between plus and minus 80 degrees latitude, [07:11.180 --> 07:16.740] as we can see in their coverage map. Iridium has a larger constellation of lower flying birds [07:16.740 --> 07:22.580] to give complete coverage even over polar regions. There are different bandwidth and frequency [07:22.580 --> 07:27.960] options and services from each provider, but certain frequencies are better at penetrating [07:27.960 --> 07:34.780] water. Although aircraft tend to fly above clouds and weather, and this is not usually a problem, [07:34.780 --> 07:42.000] but in the tropics, humid air can block signals. It is possible to intercept ground-to-air, [07:42.000 --> 07:47.180] that is ground-to-satellite-to-aircraft communications using a suitable antenna and [07:47.180 --> 07:53.360] software, as a signal is transmitted to the ground over a wide area. But you will not be able to see [07:53.360 --> 08:00.480] aircraft to ground, as you're not in a middle position unless you're in space. The data is [08:00.480 --> 08:05.820] relayed from the ground stations back into the DSP networks and then on to its destination. [08:06.640 --> 08:12.280] Classic aero services are quite bandwidth-limited, but we've probably all been on aircraft with [08:12.280 --> 08:19.440] in-flight Wi-Fi by now, so SATCOM program actually can be quite decent, and it's this latter capability [08:19.440 --> 08:25.400] that is now being used in modern E&A aircraft to collect huge amounts of live data for analysis [08:25.400 --> 08:32.680] and predictive maintenance. There are also options to transmit ACARS over long-wave, [08:32.680 --> 08:37.540] high-frequency transmitters, and this is reserved for oceanic and polar regions. [08:37.540 --> 08:42.520] There are actually only 15 transmitter sites and speeds are incredibly slow, [08:42.520 --> 08:46.440] and this probably also explains the very high costs of using these services. [08:48.580 --> 08:53.740] There is an early test of using the CELIN networks to provide ACARS services in Europe. [08:53.740 --> 08:58.720] This actually uses a piece of equipment found on many aircraft already, which is a wireless [08:58.720 --> 09:05.340] quick access recorder or wireless digital flight data acquisition unit. These devices capture lots [09:05.340 --> 09:10.000] of data in flight and then relay it back to the airline once they're on the ground over a 3G [09:10.000 --> 09:17.080] network. This same unit can be upgraded to provide a wireless link and route ACARS over that instead. [09:19.490 --> 09:24.090] Aircraft will often maintain multiple communication links, and for a transatlantic [09:24.090 --> 09:30.650] flight an aircraft may actually have and use all three options at various stages of the flight. [09:30.970 --> 09:36.970] A communications management unit, CMU, is used to route ACARS traffic between the various avionics [09:36.970 --> 09:43.550] systems and these physical links. An airline may also change the cost preferences depending on how [09:43.550 --> 09:49.850] much they pay for various services. This CMU has access to lots of important avionics including [09:49.850 --> 09:56.170] display unit the pilot interacts with, the flight management computer for reporting location, [09:56.170 --> 10:00.790] and for setting height or heading as we'll see later, and for acquiring lots of maintenance [10:00.790 --> 10:05.970] data. And believe it or not there are actual genuine printers on the flight deck too. [10:08.250 --> 10:14.590] A brief segue on to cell call. During transatlantic or polar flights where radio [10:14.590 --> 10:20.350] communication is intermittent and to avoid crews from having to monitor radios for a long period, [10:20.350 --> 10:25.490] cell call was introduced where the air traffic controller can trigger an alert light or sound [10:25.490 --> 10:31.010] or both in the cockpit and the crew then jump on the radio to listen for the actual message. [10:31.470 --> 10:38.190] Each aircraft is assigned a four-digit code and the first pair of letters sent as a tone and then [10:38.190 --> 10:44.290] the second, which I guess is a bit like DTMF dialing tones. As you can see there aren't that [10:44.290 --> 10:50.130] many possible combinations so there is reuse and it's really important that crews verify the [10:50.130 --> 10:56.950] transmission was really meant for them. Similarly now when there is an ACARS message the crew will [10:56.950 --> 11:02.750] hear a chime noise and a data link message will appear on the displays which they can then go and [11:02.750 --> 11:10.930] read. ACARS at its basis is simply a text message service between two parties and this concept is [11:10.930 --> 11:16.250] now being used in air traffic control. Rather than a controller using voice radios to instruct pilots [11:16.250 --> 11:22.770] on what to do this is sent by a ACARS message. This has the benefits of efficiency which means [11:22.770 --> 11:28.130] more aircraft can be accommodated in a given space but also safety you know there is no confusion in [11:28.130 --> 11:34.570] hearing about what altitude to fly to or heading etc. Both Boeing and Airbus developed their own [11:34.570 --> 11:41.810] standards but these were merged and gave rise to the FANS 1A standard as we have today. A FANS [11:41.810 --> 11:47.690] installation on aircraft requires certification and a minimum latency requirement. Messages will [11:47.690 --> 11:54.830] be automatically rejected after 30 seconds if no confirmation is made. FANS is comprised of [11:54.830 --> 12:01.450] two important services which are both sent over ACARS and that could be either VHF or SATCOM. [12:01.470 --> 12:09.710] Controller Pilot Data Link Communication CPDLC and Automatic Dependent Surveillance Contract ADSC. [12:11.850 --> 12:17.950] So for CPDLC, air traffic can send pilots instructions to climb to a particular altitude [12:17.950 --> 12:23.490] or steer a heading. Before this can happen, pilots log on to a specific controller which [12:23.490 --> 12:29.690] then shows that the data link is ready. Every instruction sent by ATC requires a positive [12:29.690 --> 12:35.310] confirmation by the pilot. You cannot simply send a message and remote control your plane. [12:36.030 --> 12:41.890] Different regions still have different CPDLC adoption levels. So Europe has on-route services [12:41.890 --> 12:48.830] whereas parts of the USA only have pre-departure at airports. And this latter is really useful [12:48.830 --> 12:53.170] because if you've ever had to note down and read back a complicated departure clearance, [12:53.170 --> 12:58.230] you'll realize how useful this is in not only time saving but in making sure it's correct. [12:59.810 --> 13:06.650] You might be familiar with ADS-B which is the position notification signal sent out on 1090 [13:06.650 --> 13:12.530] megahertz which contains GPS position and altitude. And this is picked up by services [13:12.530 --> 13:20.130] like Flight Radar 24 and ADS-B Exchange. These are periodically sent out by the aircraft when [13:20.130 --> 13:27.770] it's illuminated by primary radar. But for fans, we need more granularity and information. So ADSC [13:27.770 --> 13:34.830] is used instead. Air traffic can request an aircraft report its position or time when [13:34.830 --> 13:40.970] passing a certain altitude or a given waypoint. ADSC will also show what waypoints the aircraft [13:40.970 --> 13:46.890] is currently programmed to fly to. So controllers can better understand and more efficiently [13:46.890 --> 13:54.190] sequence traffic for arrivals into busy airports. So now we know that more ACARS is useful in broad [13:54.190 --> 14:00.150] terms, let's have a closer look at how the messages are formatted. In plain old ACARS, [14:00.150 --> 14:05.130] all messages are broadcast to all devices, or those that are in range of the same transmitter [14:05.130 --> 14:11.130] at least. So there is a header that lists the destination aircraft registration. The receiver [14:11.130 --> 14:17.110] on an aircraft will discard any messages that are not destined for it. In the header, [14:17.730 --> 14:22.310] there is a two-character label field which indicates the type of data that the whole [14:22.310 --> 14:29.350] message contains. There's no specific standard but there are some common ones like C1 which is [14:29.430 --> 14:34.530] a message for the onboard printer and indeed some airlines will use different labels to indicate [14:34.530 --> 14:41.010] the same types of data. The bulk of the transmission is taken up by the message text itself [14:41.010 --> 14:48.050] up to a maximum of 220 characters. The character set is basic ASCII alphanumerics and some special [14:48.050 --> 14:54.370] characters only and no unicode. These could just be standard free text type messages or they could [14:54.370 --> 14:59.330] be engineering and maintenance data and frankly more often than not it's the latter and are quite [14:59.330 --> 15:08.230] dull as a result. Sequential messages are sent with an incrementing number in the header so C01, [15:08.230 --> 15:15.390] C02 for example. Because of the 220 character limit, larger messages like our maintenance data [15:15.390 --> 15:21.210] can be split across multiple ACOLs transmissions or with a letter suffix to note their position [15:21.210 --> 15:29.190] in the multi-part message. So for example U10A, U10B, U10C etc. The next separate message [15:29.190 --> 15:36.090] from this particular aircraft would then be U11A and so on. The last part of the message [15:36.090 --> 15:43.590] is a simple checksum either ATM32 which is a modified form of Fletcher's checksum or a CRC. [15:43.590 --> 15:49.090] The CDU on an aircraft will discard any message without a valid checksum and ask for a retransmit [15:49.090 --> 15:55.710] if possible. The checksum is designed to protect against distortion of the message in transit only. [15:55.990 --> 16:01.430] Given we are talking about radio data links here often over long distances there is potential for [16:01.430 --> 16:08.070] garbled. You'll probably have noticed by now that all of the examples of message I've shown are [16:08.070 --> 16:13.430] actually human readable and that's because there's no encryption of the data in standard ACOLs at all. [16:14.150 --> 16:20.110] Some aircraft though do send encrypted messages and these are marked by the label type 44. [16:20.590 --> 16:25.550] There is a really great paper called Economy Class Crypto from the Oxford Aviation Security [16:25.550 --> 16:30.010] Group and they are able to decipher these messages through a combination of brute force [16:30.010 --> 16:36.110] and other inputs such as knowing where an aircraft was at the time it transmitted the message. [16:36.110 --> 16:40.790] What they are able to show is that there is a static cipher key in use across all of these [16:40.790 --> 16:47.310] terminals so its brick ones decode everywhere. Fortunately it seems that this data is mostly [16:47.310 --> 16:52.450] engineering rather than anything sensitive but operators of this equipment should be aware their [16:52.450 --> 16:58.950] messages are definitely not private. As ACOLs offers arbitrary text messaging and is often [16:58.950 --> 17:04.810] made available through cabin crew terminals it's common to see company type data like our second [17:04.810 --> 17:10.470] message here. Fortunately this particular operator seems to be aware of the limitations of ACOLs [17:10.470 --> 17:17.310] privacy and hasn't used names here just seat numbers but not everyone is this careful. [17:18.990 --> 17:25.590] Software and hardware on aircraft is written to design assurance levels. This is I suppose the [17:25.590 --> 17:30.230] code quality and testing that goes into that particular component depending on the risks [17:30.230 --> 17:36.810] that it poses to the aircraft. These hazard levels are documented in DO 178C. [17:37.450 --> 17:42.110] Although we've seen that ACOLs is important for efficiency both in air traffic and maintenance [17:42.110 --> 17:46.390] it doesn't directly impact on keeping an aircraft safe and airborne. [17:46.710 --> 17:52.110] This means that generally ACOLs components are into C or D levels of assurance. [17:53.690 --> 17:59.070] Let's step through them where ACOLs is used in different phases of flight. Airlines will provide [17:59.070 --> 18:03.510] routes to the air pilots to help them in choosing a fuel efficient routine or avoiding forecast [18:03.510 --> 18:09.510] weather, turbulence, icing and so on. The airline itself back at HQ will often calculate the [18:09.510 --> 18:16.570] aircraft takeoff performance speeds like V1 and V rotate based on the number of passengers, bags, [18:16.570 --> 18:21.150] cargo loaded and then send this directly to the aircraft for review and acceptance. [18:21.590 --> 18:26.790] Pilots will often do their own numbers too as a cross check. As we mentioned briefly air traffic [18:26.790 --> 18:31.850] control can provide departure clearances via ACOLs which will be added to the flight management [18:31.850 --> 18:37.910] computer once they've been checked by the pilots. The aircraft then fly that particular set of way [18:37.910 --> 18:43.870] points, heights and speeds after takeoff to minimize noise and improve efficiency of airspace. [18:44.430 --> 18:48.970] The aircraft itself has a large number of sensors attached to things like doors, cargo hatches [18:49.590 --> 18:55.070] and weight and wheel switches so we can work out what state it's in. This is then used to send our [18:55.070 --> 19:01.270] out, off, on and in data back to the airline for paying our pilots not a penny more than they deserve. [19:04.030 --> 19:09.730] Once in the flight the aircraft will continually be sending quite a lot of data back to the [19:09.730 --> 19:16.310] airline's maintenance teams and often the aircraft or engine manufacturer too so they can try and [19:16.310 --> 19:21.250] predict any maintenance needed. The aircraft will also immediately report things like a tail strike [19:21.250 --> 19:27.650] or hard landing so the aircraft can be properly inspected at the next landing. During cruise air [19:27.650 --> 19:33.050] traffic control will be using ACARS and CPDRC to ask the pilots to change course, routing or headings [19:33.050 --> 19:42.710] as they need to keep everything safe and efficient. CPDRC uses AOA, so X-25 routing as we've seen. [19:42.890 --> 19:48.950] The source and destination addresses are 24-bit IKO Mode S identifiers which are unique [19:48.950 --> 19:55.410] per aircraft and are the same ones you can see in ADS-B transmissions like on flight radar 24. [19:56.210 --> 20:01.970] Ground stations also have an identifier and in this message, although I've redacted the aircraft, [20:03.810 --> 20:09.510] 29D1D7 maps to London Stansted Airport. In this case this is an acknowledgement from the aircraft [20:09.510 --> 20:16.030] to Stansted saying Wilco, which is short for will comply or I will do this. And this is different [20:16.030 --> 20:23.010] to a simple acknowledgement with no expectation that they need to do anything. Just prior to landing [20:23.010 --> 20:29.250] the aircraft will obtain ATIS data, Automatic Terminal Information Service, which gives data [20:29.250 --> 20:35.730] on the runway in use, temperature, surface wind and so on. Traditionally this has been an audio broadcast [20:35.730 --> 20:40.590] but by using ACARS this data can be obtained earlier and help the crew prepare for the right [20:40.590 --> 20:47.650] runway in use. CPDRC is not used when immediate responses might be needed. Remember it has a [20:47.650 --> 20:53.170] maximum of 30 seconds latency. So this is ended with arrivals and airport controller taking over [20:53.170 --> 20:59.790] via VHF voice. The airline will also use this position info to help prepare the gate and ground [20:59.790 --> 21:04.570] crew, turn the aircraft around as quickly as possible, obtain any maintenance reports, they can [21:04.570 --> 21:13.620] change parts out and then also be informed which aircraft is on stand for payroll. So how can you [21:13.620 --> 21:17.960] look at these kinds of transmissions? Well for plain old ACARS, although we have a larger number [21:17.960 --> 21:23.700] of frequencies and two service providers, the frequencies are quite close together. So we can [21:23.700 --> 21:31.320] use software defined radio like HACRF, RTL-SDR or even a digital TV tuner to receive them all in one [21:31.320 --> 21:39.620] go. If you look on github you'll find ACARS deck by Thierry Lecomte for RTL-SDR or the port [21:39.620 --> 21:50.440] of the port ACARS-SDR play by Jan Katwik for HACRF. For aerials it's VHF so you will need line of sight [21:50.440 --> 21:57.340] to the ground station but you will see lots of aircraft if they fly over you. A telescopic one [21:57.340 --> 22:05.700] will do just fine and it works okay just placed in my office window frankly. For AOA you'll need [22:05.700 --> 22:13.180] Jumper VDL-2 by Tomasz Lemich. This doesn't have direct HACRF support but you can use it through [22:13.180 --> 22:21.180] SOPI-SDR. You'll need two SDR devices to receive and decode POA and AOA at the same time though [22:21.180 --> 22:27.960] obviously. Many people have these little tools running on a Raspberry Pi or similar for long-term [22:27.960 --> 22:34.180] capture and indeed many people re-share with others out on the internet. You can use the plane [22:34.180 --> 22:40.080] plotter and Windows software to capture the output of the tools and draw the locations of aircraft [22:40.080 --> 22:47.020] from a map and so on. If you use the dash-in or dash-output HACRF's PP switches with the [22:47.020 --> 22:51.900] destination of the machine where plane plotter is running, this is all you need to do to capture [22:51.900 --> 22:59.420] these messages. Just a quick note on the legality of receiving and decoding these HACRF transmissions. [22:59.620 --> 23:05.340] In true internet fashion I am definitely not a lawyer and I'm in the UK so here's my take based [23:05.340 --> 23:12.540] on prior law, prosecution and where I live. There are still a fair number of pages, yes pages, in use [23:12.540 --> 23:20.100] in the UK mostly amongst the emergency services. Pager POCSAG data transmissions are quite similar [23:20.100 --> 23:27.540] serial data structures to HACRF's and are also really easily decoded with RTL-SDR. These generally contain [23:27.540 --> 23:33.260] really horribly sensitive data like patient and medical information and these are directed to [23:33.260 --> 23:39.380] specific recipients. So just because you can it doesn't make it legal to decode POCSAG [23:39.380 --> 23:46.320] in the UK. Plane or HACRF's is different because all messages have to be sent to all stations [23:46.940 --> 23:51.040] before they can decode them and then decide whether they are intended to be for them [23:51.040 --> 23:56.700] based on the registration number of the aircraft. AOA on the other hand uses x25 [23:56.700 --> 24:04.060] and a specific terminal address for the recipient. But the legislation in the UK says you can pick up [24:04.060 --> 24:10.140] weather and navigation transmissions which parts of HACRF's demonstrably are. So frankly who really [24:10.140 --> 24:15.520] knows. I don't really want to be the test case though so I've redacted any example messages in [24:15.520 --> 24:20.680] this talk and I've unfortunately decided not to do a live demo just in case something sensitive [24:20.680 --> 24:26.080] pops up. But please check with your local jurisdiction before you start decoding these [24:26.080 --> 24:33.000] messages though. So I want to leave you kind of with a little thought experiment for discussions [24:33.000 --> 24:40.160] in the comments. HACRF's messages seem an awful lot like TCP sequence numbers. Could you predict the [24:40.160 --> 24:48.000] next in the sequence? Could you send a valid HACRF's message? Could you send a valid CPDLC message? [24:48.220 --> 24:53.940] And what if you actually did? We've noted that there's no encryption and no integrity checks [24:53.940 --> 25:00.080] or integrity checks rather are based on a checksign. If we were designing the system today [25:00.620 --> 25:06.280] would we implement encryption or message signing? Are there any potential problems if we do? [25:08.400 --> 25:13.880] And my final thought. Although we can see and potentially send HACRF's transmissions around [25:13.880 --> 25:20.100] there are always humans in the loop. We cannot take control and make an HACRF do things. [25:20.100 --> 25:25.140] And even if we did there are a lot of other mitigation to stop aircraft coming into conflict [25:25.140 --> 25:31.600] like air traffic controllers, their radar and systems like traffic collision avoidance system, [25:31.600 --> 25:38.500] TCAS. Yes it's a legacy system and protocol but these are vulnerabilities on the part of ARINC, [25:38.500 --> 25:43.280] Rockwell or CITER themselves. But we should keep in mind that when we're designing systems [25:43.280 --> 25:47.480] and protocols how things can end up being used 40 years on. [25:48.700 --> 25:52.380] Thanks for listening and I look forward to hearing your comments and thoughts.