[00:04.540 --> 00:09.780] Hi, I'm Carl Kosher, and this talk is a look inside the 737 Communications Management Unit [00:09.780 --> 00:14.180] and some of the interesting things we've learned while reverse engineering systems. [00:14.260 --> 00:19.460] But first, the obligatory who am I slide. So I'm a research scientist at the University of [00:19.460 --> 00:24.700] Washington, but previously I was a postdoc at UC San Diego, where I did a lot of this work. [00:24.700 --> 00:29.160] In general, I'm a low-level system security researcher, so I've worked on things such as [00:29.160 --> 00:35.840] RFID systems, looked at enhanced driver's licenses, transit cards, and built some [00:35.840 --> 00:42.300] anti-relaying defenses. I also led one of the original car hacking teams, so we were the first [00:42.300 --> 00:49.160] to demonstrate a full remote compromise of a vehicle over the internet. I've reverse-engineered [00:49.160 --> 00:55.920] wireless SCADA systems involved in power distribution. I've done some proof-of-concept [00:55.920 --> 01:02.800] malware against DNA sequencers and analysis pipelines, and I'm also working on wet lab [01:02.800 --> 01:09.120] automation systems these days. So of course I'm not doing this work alone. There are a number of [01:09.120 --> 01:16.180] people involved in the AEROSEP project, and this project really came out of the previous car hacking [01:16.180 --> 01:23.860] research that we did. So of the people listed here, the ones in the top row and listed in orange [01:23.860 --> 01:31.580] were part of that original car hacking team. And that project had some pretty big impact. [01:31.580 --> 01:34.820] She thinks she's going to be able to stop right at those cones. Let's make sure that she can't, [01:34.820 --> 01:38.420] and she's going to drive right through them. We have complete control of that brake. All right, [01:38.420 --> 01:46.300] there we go. Oh no, no, no, no, no, no, no, no, no, no. Brakes didn't work, right? Oh my god, [01:46.300 --> 01:51.960] I can't operate the brakes at all. Oh my word, that is frightening. [01:53.480 --> 01:59.200] So obviously these results were pretty impactful, and inspired DARPA's approximately 70 million [01:59.200 --> 02:05.860] dollar high assurance cyber military systems, or HACMS program, to make systems provably secure [02:05.860 --> 02:11.920] against attack. But avionic systems are already engineered to a high assurance level, albeit for [02:11.920 --> 02:19.400] safety, not security. So we wondered if these safety assurance requirements translated into [02:19.400 --> 02:28.080] improved security. So the 777, 787, and A380 all have new and interesting architectures, [02:28.080 --> 02:35.720] but you can't really buy spare parts for those off of eBay. As it turns out, as 737 airframes are [02:35.720 --> 02:42.000] retired, parts do become available from auction sites, and so that's why we decided to focus on [02:42.000 --> 02:48.760] 737s. And there's actually a great website with a ton of information about the 737 that we used in [02:48.760 --> 02:54.400] our research, and they've even released a book. After investigating how the systems were integrated, [02:54.400 --> 02:59.180] we decided to focus on the communications management unit, as it connects the rest of [02:59.180 --> 03:08.240] the avionic systems to the outside world. So for example, the CMU can take messages through the VHF, [03:08.240 --> 03:14.500] HF, or satellite radios, and relay them to other avionic systems. It's also used for sending [03:14.500 --> 03:20.940] messages between pilots and ground. So since the CMU is sort of this central hub for all this [03:20.940 --> 03:26.240] messaging, it has a pretty large attack surface, and it's a pretty juicy target for looking for [03:26.240 --> 03:33.300] vulnerabilities. So aside from the display unit, all these systems live in the electronics and [03:33.300 --> 03:40.720] equipment bay. This is a view from the E&E bay from the outside, and this is what it looks like from [03:40.720 --> 03:49.100] the inside. So all of these boxes are called LRUs, or line replaceable units, because they slide in [03:49.100 --> 03:55.140] and out and connect with an interconnect backplane, making them very easy to swap out for maintenance [03:55.140 --> 04:01.740] or repair. So in the cockpit, pilots interact with these systems through these control display units. [04:01.740 --> 04:08.000] Originally, there were separate display units for messaging and for the flight management system, [04:08.000 --> 04:13.700] but they've since been combined into these multi-control display units, or NCDUs, where you can [04:13.700 --> 04:19.880] access different systems through one common interface. So for example, on the left, the MCDU [04:19.880 --> 04:26.200] is interacting with the flight management system, while on the right, the MCDU is interacting with [04:26.200 --> 04:32.400] the communications management unit, which allows the pilots to send and receive messages, request [04:32.400 --> 04:39.420] weather reports, do a whole bunch of things. So to put the communications management unit in context, [04:39.420 --> 04:44.880] we first need to talk about ACARS, which started out as a simple messaging system [04:44.880 --> 04:51.180] designed to solve one very specific problem for airlines, and that was ensuring that they paid [04:51.180 --> 04:58.360] their employees only as much as they were entitled to. And the way that it did this is through [04:58.360 --> 05:07.820] reporting these OOOI statuses, which basically indicates whether the plane is out of the gate, [05:07.820 --> 05:13.380] off the ground, on the ground, or back in the gate. And this is how airlines determine [05:13.380 --> 05:18.560] how pilots and flight attendants are paid. But since then, it's been generalized to transfer [05:18.560 --> 05:25.520] avionics data. So for example, you can push a flight plan over ACARS, or you can request a [05:25.520 --> 05:31.120] clearance from air traffic control. Airlines typically have their own applications that they [05:31.120 --> 05:36.780] add on top of this. So for example, if you've ever received connecting gate information while you're [05:36.780 --> 05:42.460] in flight, that information was likely relayed through ACARS, and it's increasingly being used [05:42.460 --> 05:49.180] to replace traditional voice-based air traffic control communications, especially in Europe. [05:49.180 --> 05:56.040] So ACARS works over multiple RF link types, including the legacy VHF ACARS radios, [05:56.040 --> 06:04.680] the new VHF VDL2 data radios, over the horizon HF data radios, and even satellite links. And [06:04.680 --> 06:10.300] since this standard came out in 1978, and has largely been unchanged since then, these messages [06:10.300 --> 06:17.480] typically aren't encrypted. And when they are, they're often encrypted using questionable methods. [06:18.000 --> 06:21.910] So the communications management unit has some interesting requirements. [06:22.300 --> 06:27.480] So obviously, air traffic control is flight critical, and so that software needs to be [06:27.480 --> 06:33.340] certified to a certain assurance level. But airlines want to add their own custom apps to [06:33.340 --> 06:39.000] these communication management units. And it's cost prohibitive and extremely time intensive [06:39.000 --> 06:46.880] to certify these. So how do CMUs allow uncertified apps to not taint certification? [06:47.620 --> 06:54.320] As it turns out, there are two major vendors of CMUs for the SEM37, and they each take [06:54.680 --> 07:02.280] a different approach to solving this problem. So the two major versions of the CMU for the SEM37 [07:02.280 --> 07:11.580] are the Collins CMU-900 and the Honeywell Mk3. So the Collins CMU-900 has 46 for running applications, [07:11.580 --> 07:17.360] 386 to handle IO, and does inter-process communication through dual-ported RAM between [07:17.360 --> 07:23.000] the two processors. It runs the Vertex real-time operating system, which I'll talk a little bit [07:23.000 --> 07:31.720] about later. Makes extensive use of x86 segments, which makes reverse engineering a giant pain. [07:31.720 --> 07:36.660] And they invented their own virtual machine instruction set that apps are compiled for, [07:36.660 --> 07:42.420] and this allows apps to be isolated without tainting certification. The other major player [07:42.420 --> 07:48.620] is the Honeywell Mk3, and it has a slightly beefier Pentium for running its applications, [07:48.620 --> 07:55.380] and uses PowerPC to handle IO. And similar to the CMU-900, it uses dual-ported RAM for [07:55.380 --> 08:02.280] inter-processor communication. However, the Pentium runs Honeywell's custom DOS real-time [08:02.280 --> 08:10.720] operating system, while the PowerPCs use Vertex, like the CMU-900. On the Honeywell Mk3, apps are [08:10.720 --> 08:15.440] database-driven, and the database processing code is written in a verifiable language [08:15.440 --> 08:19.860] that I'll describe later. So let's take a look inside some of these units. [08:19.860 --> 08:27.480] So this is the CMU-900 main processor board, and on there you have the 486, RAM, a CPLD for glue [08:27.480 --> 08:33.980] logic, a timer and interrupt controller, a real-time clock, and a serial interface chip. [08:34.240 --> 08:42.160] The IO board is responsible for interfacing with all the 429 buses. On the board we have the 386, [08:42.160 --> 08:48.600] the dual-ported RAM, and some custom ASICs that we're pretty sure are 429 transceivers, [08:48.600 --> 08:53.080] along with some analogy bits to interface with the 429 bus. [08:53.900 --> 08:59.860] So this is the Honeywell Mk3 processor board, and underneath that heatsink is a Pentium. [08:59.860 --> 09:06.460] There's also RAM, some glue logic, and a very annoying non-volatile storage system, [09:06.460 --> 09:12.320] which relies on a battery, which of course has gone dead by now, basically breaking the system. [09:12.880 --> 09:19.360] So the IO board on the Honeywell Mk3 is a rather interesting beast. The first thing that pops out [09:19.360 --> 09:24.540] to me is that there are two PowerPCs, and through our reverse engineering, it seems like only one [09:24.540 --> 09:30.540] of them is used for IO, while the second supports reflashing the system. So in the middle there is [09:30.700 --> 09:38.060] a CPLD, which we suspect interfaces the 429 transceivers with the PowerPC chips. There are [09:38.140 --> 09:43.060] a number of interesting connectivity options on here. So for example, there's an Ethernet [09:43.060 --> 09:50.240] controller on there with magnetics, probably for supporting a gate link upgrade, whereby you can [09:50.240 --> 09:59.580] push messages to the CMU over Wi-Fi. There's also a DSP chip next to an ADC, and we suspect that's [09:59.580 --> 10:07.840] used for sending ACARS messages over legacy VHF radios. But also interestingly enough, there's a [10:07.840 --> 10:15.600] V.90 modem chipset, and I'm not really sure why this exists, especially with that other DSP chip [10:15.600 --> 10:22.660] on there. Perhaps they were leaving the option open to plug a CMU into a phone line. Not really [10:22.660 --> 10:28.800] sure that would make sense on an aircraft, but it might make sense for maintenance. [10:29.780 --> 10:36.340] And of course, there's lots of JTAG connectors everywhere. It warms my heart. So let's take a [10:36.340 --> 10:43.620] deep dive into how the Honeywell Mk3 is actually constructed. So to begin our reverse engineering [10:43.620 --> 10:49.500] journey, we sacrificed one board, removed the conformal coding, pulled off the flash chips, [10:49.500 --> 10:55.720] dumped the flash chips, and ran strings on the binaries. And what we saw next was surprising. [10:56.680 --> 11:05.440] This program must be run under Win32. Wow. By looking for PE headers, we were able to carve [11:05.440 --> 11:11.180] the flash ROM into a number of interesting files. It also turns out the flash had multiple [11:11.180 --> 11:17.920] partitions. One seemed to be for flight mode, another seemed to be for update mode, and another [11:17.920 --> 11:25.940] for recovery. So as it turns out, Honeywell wrote their own realtime OS called DOS. And one of the [11:25.940 --> 11:31.800] interesting things about DOS is that its scheduler was ported to Java and formally verified by NASA [11:31.800 --> 11:36.880] to ensure that it always met its realtime requirements. As you might have guessed, [11:36.880 --> 11:43.120] it seems heavily inspired by Windows. It loads statically linked portable executables. [11:43.200 --> 11:51.340] The APIs look a lot like Win32 or the Windows NT kernel API. And in fact, while reverse engineering [11:51.340 --> 11:57.380] the kernel, if I didn't know what a parameter to a function was, I would just go to MSDN, [11:57.380 --> 12:04.540] and it would probably have the right answer. And it even has a concept of a registry, [12:04.540 --> 12:09.540] which is basically just a small binary blob of configuration parameters. [12:10.080 --> 12:16.180] So why is DOS so similar to Windows? Is it because they wanted to develop the CMU code [12:16.180 --> 12:22.780] against a Windows target? Well, this is pure speculation, but here's a map of Microsoft [12:22.780 --> 12:32.500] campus in Redmond, Washington. And right across the street is Honeywell Aerospace. So again, [12:33.020 --> 12:39.680] just speculation, but I'm guessing it was likely developed by ex-Microsoft employees. [12:40.500 --> 12:47.400] So outside of the kernel, the bulk of the CMU code is in a single executable called CMU core. [12:47.400 --> 12:53.760] And this is written in a language called SDL, the Specification and Description Language. [12:53.760 --> 13:00.460] And this was created by the ITU. And it is a language that only telecoms can love. [13:00.460 --> 13:06.540] Data structures are defined by ASN 1, and basically it's intended for building telephone [13:06.540 --> 13:13.460] switches. If you're familiar with Erlang, it's spiritually similar. SDL lets you define loosely [13:13.460 --> 13:19.160] coupled state machines that pass messages to each other. So it's ideal for protocol handling. [13:19.920 --> 13:25.680] SDL has a couple of forms that it can take. There is both a graphical and a textual form. [13:25.720 --> 13:31.920] The graphical form is shown here. So basically you write state machines that send and receive [13:31.920 --> 13:38.260] messages or are triggered by timers. And you can also execute arbitrary C code. [13:38.860 --> 13:45.880] Now there's a companion language to SDL called MSC, or Message Sequence Charts. And this lets [13:45.880 --> 13:52.200] you define protocol flows and test cases to validate your SDL against. And by writing test [13:52.200 --> 13:58.720] cases for handling 429 and ACARS messages, they can verify that the SDL code is correct. [13:58.980 --> 14:04.260] So like I said, SDL programs are composed of loosely coupled state machines called tasks. [14:04.260 --> 14:10.260] And in CMU Core, there are a lot of tasks. And many of them send messages to each other. [14:10.400 --> 14:15.200] Now, I'm not going to read through this entire list here, but I encourage you to pause the video [14:15.200 --> 14:22.340] and take a look at the list. So at this point, we have SDL code that is verified. And that SDL [14:22.340 --> 14:28.720] code is then compiled down to C code by a product called ObjectGeode, which was made by a company [14:28.720 --> 14:34.860] named, confusingly enough, Verilog. No relation to the hardware description language. [14:34.860 --> 14:40.880] But how do airlines make their own apps? Well, it turns out that the SDL code actually reads [14:40.880 --> 14:47.820] app logic from databases stored in Flash. So I'm sure you've all heard of SQL, but there's also [14:47.820 --> 14:54.040] another database language called QWEL. And the database on the Honeywell Mark 3 is an embedded [14:54.040 --> 15:01.020] version of Ingress QWEL. Now, the crazy thing is that queries are directly embedded in C files, [15:01.020 --> 15:06.020] which are then preprocessed into other C files, which are then compiled and linked against. [15:06.680 --> 15:11.700] So if you want to write a query that iterates through employee names, you can write it sort of [15:11.700 --> 15:18.700] as a pseudo for loop, as shown here. And that will be turned into a database query, and that printf [15:18.700 --> 15:25.280] will be executed for every row returned. So unfortunately, these queries are directly [15:25.280 --> 15:31.000] converted into C code, so there are no query strings in the executable. And furthermore, [15:31.000 --> 15:36.200] we don't even have any schema information, since it's known at compile time, so there is no reason [15:36.200 --> 15:43.760] to store it in Flash. So how are these apps created? Well, Honeywell has this tool called [15:43.760 --> 15:51.300] the Ground-Based Software Tool, which is used both to create HGI, the Honeywell-generated [15:51.300 --> 15:59.160] information, as well as the AMI, or the Airline Modifiable Information. And basically, this tool [15:59.160 --> 16:06.160] lets you populate the database tables that define your app. And this is used both for [16:06.160 --> 16:12.040] certified apps made by Honeywell, as well as custom operational apps made by airlines. [16:13.000 --> 16:19.080] So how do these state machines actually interact with real hardware? Well, these SDL messages are [16:19.080 --> 16:26.500] serialized and sent through DOS's inter-process communication mechanism, mailboxes, to a process [16:26.500 --> 16:33.820] called DP-RAM-IO. And DP-RAM-IO takes these messages and shoves it into the dual-ported RAM, [16:33.820 --> 16:41.280] which is shared by the PowerPCs. And the PowerPCs handle the low-level interface to the hardware. [16:41.280 --> 16:49.560] So as I said before, one seems to handle the PCMCI update cards and does little else. The [16:49.560 --> 16:55.400] other one seems to handle almost everything. Unlike the Pentium chip, the PowerPCs run the [16:55.400 --> 17:02.900] Vertex real-time OS. And the code on the PowerPCs is also written in SDL. So this makes it fairly [17:02.900 --> 17:11.000] easy to pass messages back and forth between the x86 and PowerPCs. So Vertex is a fairly old, [17:11.000 --> 17:17.320] but well-proven real-time operating system. And to emphasize this point, here's an ad from 1983, [17:17.320 --> 17:22.120] where they will buy you a VW bug if you find a bug in their OS. [17:23.960 --> 17:28.980] So there's one tricky bit about passing messages between the x86 and PowerPC. [17:29.440 --> 17:36.860] And that is x86 is little-endian, while PowerPC is big-endian. And so the way that they actually [17:36.860 --> 17:43.020] solve this is with one giant switch statement based on the message type to do the endianness [17:43.020 --> 17:50.200] swap. And that code is written in C, which of course is far more promising for bugs. [17:51.000 --> 17:57.880] And in fact, we found some. So we found some signed versus unsigned confusion and some integer [17:57.880 --> 18:04.700] overflows as well. Fortunately, they do not seem to be exploitable. So now that we have a general [18:04.700 --> 18:10.520] idea of how the CMU works, let's actually try going and see if we can find some real bugs. [18:11.100 --> 18:17.740] So static analysis of this auto-generated code is hard. So we'd like to do some dynamic analysis. [18:18.220 --> 18:25.540] Unfortunately, getting the CMU to boot was challenging. It does a lot of self-tests on [18:25.540 --> 18:32.240] startup. If something is wrong, it just won't boot. And we spent several months with it just [18:32.240 --> 18:38.840] blinking the fail light at us. Fortunately, we found some serial ports on the front maintenance [18:38.840 --> 18:44.780] port, which gave us some clues as to what was going wrong. So when we powered up the CMU, [18:44.780 --> 18:50.340] it would state that it was starting its built-in functional test. Unfortunately, after a minute, [18:50.340 --> 18:56.720] it would start spitting out error codes. And as it turns out, this was because the APM was missing. [18:56.720 --> 19:04.500] Now the APM is the airline personality module, which has the tail number, the aircraft configuration, [19:04.500 --> 19:09.820] the type of aircraft it is, and a host of other settings. So if you need to replace the CMU, [19:09.820 --> 19:16.160] you don't have to reprogram it. You just pull it out, slide in a new one, connects to the existing [19:16.160 --> 19:22.880] airplane personality module, and the new CMU knows exactly what it needs to do. Unfortunately, [19:22.880 --> 19:30.580] the only APM we could find was for the Collins CMU-900, which despite being somewhat specified [19:30.580 --> 19:38.740] by an airing standard, was totally incompatible, both logically and electrically. Fortunately, [19:38.740 --> 19:46.240] the CMU saves a copy of the last known good APM image in Flash. And so we were actually able to [19:46.240 --> 19:53.120] create an APM emulator with an Arduino. It basically just emulated an i-squart-z EEPROM, [19:53.120 --> 19:58.560] and we used the APM image that we pulled out of Flash. Now the second issue that we ran into [19:58.560 --> 20:05.940] was NVRAM battery was bad, and we didn't actually know that this was preventing the CMU from booting. [20:06.360 --> 20:11.320] We basically had to take one of the cryptic error codes out of the serial console, [20:11.320 --> 20:18.220] find where that was in the binary, figure out what triggered that string to be printed, [20:18.220 --> 20:24.580] and then discover that it was doing a test on the battery voltage. As it turns out, we just [20:24.580 --> 20:29.960] removed the battery and replaced it with a power supply, and that was good enough to make it boot. [20:30.400 --> 20:35.260] So there was actually a second serial port exposed on the front maintenance port. [20:35.260 --> 20:42.000] And once the system booted, if you pressed enter, you got an interesting maintenance menu. [20:42.200 --> 20:48.100] Another weird behavior is that if you provided input to the first serial port, [20:48.100 --> 20:55.740] you would get another menu on the second serial port. So now that we can get the CMU to boot, [20:55.740 --> 21:03.200] let's try doing something with it. And to do that, we need an MCDU and a VHF data radio. [21:03.200 --> 21:08.280] Unfortunately, we didn't have those, so we ended up writing emulators for them and connected them [21:08.280 --> 21:15.880] to the real CMU over the 429 buses. And this really kicked off the development of a test bed [21:15.880 --> 21:23.680] we called Triton to support this kind of testing and security research. So the Triton test bed is [21:23.680 --> 21:30.740] designed to support a mixture of both real and emulated devices. So for example, we have a real [21:30.740 --> 21:37.580] communications management unit, but we don't have a real printer or airborne data loader unit. [21:37.580 --> 21:44.840] So we've created emulators for those. And these devices are connected through a 429 message [21:44.840 --> 21:54.340] routing daemon, which we call R429D. And R429D both supports real 429 interfaces, as well as [21:54.340 --> 22:00.360] accepting connections from emulated avionics units. Similarly for ACARS, we have a separate daemon [22:00.360 --> 22:06.880] that emulates different network segments. For example, we have one daemon that emulates the [22:06.880 --> 22:13.560] air segment, so all the VHF data radios are connected to it. We also have a separate instance [22:13.560 --> 22:18.500] for the ground segment, and we have a virtual ground station that bridges the two segments. [22:19.920 --> 22:25.120] So a little bit about the 429 devices that the Triton test bed supports. [22:25.120 --> 22:30.980] This box here is an Ethernet to 429 converter, and this was one of the first things that we [22:30.980 --> 22:36.660] targeted. Unfortunately, it can only be configured with a static IP address, [22:36.660 --> 22:41.920] and it kept getting virtually bricked by having its IP address randomly changed to something [22:41.920 --> 22:50.240] that we didn't know. And we actually suspect that UCSD was doing network scans against this device, [22:50.240 --> 22:56.460] and it just so happened that it sent a packet to reconfigure the IP address to some garbage [22:56.460 --> 23:02.620] address. So after a couple of times of opening this up, pulling off the EEPROM, putting in the [23:02.620 --> 23:07.560] correct IP address, soldering it back on, getting it back on the network, only to have it bricked [23:07.560 --> 23:13.540] again, we decided to find a better solution. One of the primary interfaces that we use now [23:13.540 --> 23:20.120] is this Ballard USB to 429 interface. Unfortunately, it is rather expensive. [23:20.600 --> 23:27.400] We did also develop our own custom USB to 429 interface, which we called Scorpion. [23:27.400 --> 23:34.040] And if you ever saw the pilot episode of that TV show, you might understand why we called it that. [23:34.040 --> 23:42.400] It's basically an ATmegaU2 with a Holt 429 transceiver. It supports four transmit channels [23:42.400 --> 23:50.080] and eight receive channels. And this basically interfaces with the R429D daemon to expose a [23:50.080 --> 23:56.900] TCP IP interface to the 429 buses. So now that we have all this wired up, [23:56.900 --> 24:02.980] we can start doing some really interesting things. So on the left here, we have our virtual MCDU, [24:02.980 --> 24:11.740] which lets us control our real CMU. Now connected to the real CMU is our virtual VHF data radio, [24:11.740 --> 24:18.280] which we can send real ACARS messages that we pick off over the air, alter the tail number so [24:18.280 --> 24:24.580] that our CMU processes them, which then forwards it to our virtual printer program, which sends [24:24.580 --> 24:40.250] it to a real credit card receipt printer. So interacting with the CMU is all well and good, [24:40.250 --> 24:45.210] but we'd really like to have some low-level debugging capabilities. And as it turns out, [24:45.210 --> 24:51.830] the main processor board has a Pentium debug port. Now, unfortunately, the Pentium Probe mode [24:51.830 --> 25:00.090] is undocumented. Details are in the infamous Appendix H of the P5 external interface specification, [25:00.090 --> 25:06.030] which was available only under NDA from Intel. And back in the mid-90s, there were a lot of [25:06.030 --> 25:11.830] rants in Dr. Dobbs' journal about this. There was one beta version of the P5 external interface [25:11.830 --> 25:17.430] specification that had these details, but all these copies were supposedly recalled by Intel [25:17.430 --> 25:23.490] and destroyed. So, of course, there's no copies of this on the web. But while we were searching [25:23.490 --> 25:30.430] for it, we did find that there was one physical copy of an unknown version at an undisclosed [25:30.430 --> 25:37.810] university lab halfway across the world. So we sent them an email and asked if they had it, [25:37.810 --> 25:44.010] and if so, what version it was, and that we might be interested in a scan of it. [25:44.210 --> 25:51.730] And so they wrote back with a scan of the title page, which was version 1.3. And unfortunately, [25:51.730 --> 25:57.250] we needed version 3. So before we could write them back and say thanks, but no thanks, [25:57.250 --> 26:02.670] they wrote us back and said they found something very interesting inside. And sandwiched between [26:02.670 --> 26:11.050] the pages of version 1.3 was version 3. And they happened to send us a scan of the entire thing, [26:11.050 --> 26:16.270] including details of the Pentium micro-op instruction format, which is exactly what [26:16.270 --> 26:22.190] you need to use the Pentium's probe mode. So armed with this information, I added P5 [26:22.190 --> 26:28.810] debugging support to OpenOCD. And so now we can use GDB against the CMU. Unfortunately, [26:28.810 --> 26:33.490] if you halt the hardware, the watchdog timers on the other processors will notice something's [26:33.490 --> 26:39.790] amiss and reset the entire system. And the solution for this is to basically run the CMU's [26:39.790 --> 26:48.350] x86 firmware in QMU, but relaying messages to the power PCs over JTAG. And this is based on [26:48.350 --> 26:53.870] some of my earlier dissertation work on a system called Surrogates, which lets you run firmware [26:53.870 --> 27:00.530] in QMU, but proxies peripheral access over JTAG in near real time. So now we can instrument the [27:00.530 --> 27:06.870] CMU firmware, collect IO traces, do snapshots, and do all sorts of interesting dynamic analysis. [27:07.610 --> 27:12.370] So in summary, the communications management unit supports flight critical operations, [27:12.370 --> 27:19.010] which requires the firmware to be certified. But airlines desire customization. And through [27:19.010 --> 27:25.430] our reverse engineering, we've identified some somewhat unusual ways that vendors have isolated [27:25.430 --> 27:31.930] these uncertified apps from the rest of the certified system. And finally, we built a flexible [27:31.930 --> 27:37.910] testbed for further security research on avionic systems. So if you would like more information [27:37.910 --> 27:44.590] about our Triton testbed or surrogate system, check out our site at aerosec.org. Thanks!