1 00:00:04,540 --> 00:00:14,180 Hi, I'm Carl Kosher, and this talk is a look inside the 737 Communications Management Unit and some of the interesting things we've learned while reverse engineering systems. 2 00:00:14,260 --> 00:00:17,240 But first, the obligatory who am I slide. 3 00:00:17,460 --> 00:00:24,700 So I'm a research scientist at the University of Washington, but previously I was a postdoc at UC San Diego, where I did a lot of this work. 4 00:00:24,700 --> 00:00:37,800 In general, I'm a low-level system security researcher, so I've worked on things such as RFID systems, looked at enhanced driver's licenses, transit cards, and built some anti-relaying defenses. 5 00:00:37,860 --> 00:00:47,460 I also led one of the original car hacking teams, so we were the first to demonstrate a full remote compromise of a vehicle over the internet. 6 00:00:47,500 --> 00:00:53,200 I've reverse-engineered wireless SCADA systems involved in power distribution. 7 00:00:53,600 --> 00:01:04,960 I've done some proof-of-concept malware against DNA sequencers and analysis pipelines, and I'm also working on wet lab automation systems these days. 8 00:01:05,760 --> 00:01:08,460 So of course I'm not doing this work alone. 9 00:01:08,460 --> 00:01:17,820 There are a number of people involved in the AEROSEP project, and this project really came out of the previous car hacking research that we did. 10 00:01:17,820 --> 00:01:27,200 So of the people listed here, the ones in the top row and listed in orange were part of that original car hacking team. 11 00:01:27,500 --> 00:01:31,580 And that project had some pretty big impact. 12 00:01:31,580 --> 00:01:33,600 She thinks she's going to be able to stop right at those cones. 13 00:01:33,600 --> 00:01:36,220 Let's make sure that she can't, and she's going to drive right through them. 14 00:01:36,220 --> 00:01:37,980 We have complete control of that brake. 15 00:01:37,980 --> 00:01:39,400 All right, there we go. 16 00:01:39,860 --> 00:01:44,180 Oh no, no, no, no, no, no, no, no, no, no. 17 00:01:44,180 --> 00:01:45,520 Brakes didn't work, right? 18 00:01:45,520 --> 00:01:48,400 Oh my god, I can't operate the brakes at all. 19 00:01:48,640 --> 00:01:51,960 Oh my word, that is frightening. 20 00:01:53,480 --> 00:02:07,420 So obviously these results were pretty impactful, and inspired DARPA's approximately 70 million dollar high assurance cyber military systems, or HACMS program, to make systems provably secure against attack. 21 00:02:07,420 --> 00:02:13,760 But avionic systems are already engineered to a high assurance level, albeit for safety, not security. 22 00:02:13,760 --> 00:02:21,500 So we wondered if these safety assurance requirements translated into improved security. 23 00:02:21,700 --> 00:02:32,200 So the 777, 787, and A380 all have new and interesting architectures, but you can't really buy spare parts for those off of eBay. 24 00:02:32,640 --> 00:02:43,320 As it turns out, as 737 airframes are retired, parts do become available from auction sites, and so that's why we decided to focus on 737s. 25 00:02:43,320 --> 00:02:51,760 And there's actually a great website with a ton of information about the 737 that we used in our research, and they've even released a book. 26 00:02:51,820 --> 00:03:02,120 After investigating how the systems were integrated, we decided to focus on the communications management unit, as it connects the rest of the avionic systems to the outside world. 27 00:03:03,500 --> 00:03:13,120 So for example, the CMU can take messages through the VHF, HF, or satellite radios, and relay them to other avionic systems. 28 00:03:13,180 --> 00:03:17,600 It's also used for sending messages between pilots and ground. 29 00:03:17,680 --> 00:03:27,460 So since the CMU is sort of this central hub for all this messaging, it has a pretty large attack surface, and it's a pretty juicy target for looking for vulnerabilities. 30 00:03:28,240 --> 00:03:34,640 So aside from the display unit, all these systems live in the electronics and equipment bay. 31 00:03:35,200 --> 00:03:41,860 This is a view from the E&E bay from the outside, and this is what it looks like from the inside. 32 00:03:42,560 --> 00:03:56,540 So all of these boxes are called LRUs, or line replaceable units, because they slide in and out and connect with an interconnect backplane, making them very easy to swap out for maintenance or repair. 33 00:03:56,740 --> 00:04:01,740 So in the cockpit, pilots interact with these systems through these control display units. 34 00:04:01,740 --> 00:04:17,380 Originally, there were separate display units for messaging and for the flight management system, but they've since been combined into these multi-control display units, or NCDUs, where you can access different systems through one common interface. 35 00:04:17,560 --> 00:04:34,000 So for example, on the left, the MCDU is interacting with the flight management system, while on the right, the MCDU is interacting with the communications management unit, which allows the pilots to send and receive messages, request weather reports, 36 00:04:34,000 --> 00:04:35,860 do a whole bunch of things. 37 00:04:35,860 --> 00:04:55,400 So to put the communications management unit in context, we first need to talk about ACARS, which started out as a simple messaging system designed to solve one very specific problem for airlines, and that was ensuring that they paid their employees only as much as they were entitled to. 38 00:04:55,600 --> 00:05:11,740 And the way that it did this is through reporting these OOOI statuses, which basically indicates whether the plane is out of the gate, off the ground, on the ground, or back in the gate. 39 00:05:11,740 --> 00:05:16,040 And this is how airlines determine how pilots and flight attendants are paid. 40 00:05:16,160 --> 00:05:20,120 But since then, it's been generalized to transfer avionics data. 41 00:05:20,120 --> 00:05:27,280 So for example, you can push a flight plan over ACARS, or you can request a clearance from air traffic control. 42 00:05:27,960 --> 00:05:32,360 Airlines typically have their own applications that they add on top of this. 43 00:05:32,460 --> 00:05:49,180 So for example, if you've ever received connecting gate information while you're in flight, that information was likely relayed through ACARS, and it's increasingly being used to replace traditional voice-based air traffic control communications, especially in Europe. 44 00:05:49,180 --> 00:06:04,540 So ACARS works over multiple RF link types, including the legacy VHF ACARS radios, the new VHF VDL2 data radios, over the horizon HF data radios, and even satellite links. 45 00:06:04,540 --> 00:06:12,340 And since this standard came out in 1978, and has largely been unchanged since then, these messages typically aren't encrypted. 46 00:06:12,340 --> 00:06:17,480 And when they are, they're often encrypted using questionable methods. 47 00:06:18,000 --> 00:06:21,910 So the communications management unit has some interesting requirements. 48 00:06:22,300 --> 00:06:30,340 So obviously, air traffic control is flight critical, and so that software needs to be certified to a certain assurance level. 49 00:06:30,340 --> 00:06:35,960 But airlines want to add their own custom apps to these communication management units. 50 00:06:35,960 --> 00:06:41,220 And it's cost prohibitive and extremely time intensive to certify these. 51 00:06:41,460 --> 00:06:46,880 So how do CMUs allow uncertified apps to not taint certification? 52 00:06:47,620 --> 00:06:57,320 As it turns out, there are two major vendors of CMUs for the SEM37, and they each take a different approach to solving this problem. 53 00:06:57,460 --> 00:07:06,540 So the two major versions of the CMU for the SEM37 are the Collins CMU-900 and the Honeywell Mk3. 54 00:07:06,920 --> 00:07:18,940 So the Collins CMU-900 has 46 for running applications, 386 to handle IO, and does inter-process communication through dual-ported RAM between the two processors. 55 00:07:19,000 --> 00:07:24,480 It runs the Vertex real-time operating system, which I'll talk a little bit about later. 56 00:07:24,720 --> 00:07:31,720 Makes extensive use of x86 segments, which makes reverse engineering a giant pain. 57 00:07:31,720 --> 00:07:40,900 And they invented their own virtual machine instruction set that apps are compiled for, and this allows apps to be isolated without tainting certification. 58 00:07:41,140 --> 00:07:51,460 The other major player is the Honeywell Mk3, and it has a slightly beefier Pentium for running its applications, and uses PowerPC to handle IO. 59 00:07:51,460 --> 00:07:57,580 And similar to the CMU-900, it uses dual-ported RAM for inter-processor communication. 60 00:07:58,220 --> 00:08:07,680 However, the Pentium runs Honeywell's custom DOS real-time operating system, while the PowerPCs use Vertex, like the CMU-900. 61 00:08:07,980 --> 00:08:17,080 On the Honeywell Mk3, apps are database-driven, and the database processing code is written in a verifiable language that I'll describe later. 62 00:08:17,080 --> 00:08:19,860 So let's take a look inside some of these units. 63 00:08:19,860 --> 00:08:33,980 So this is the CMU-900 main processor board, and on there you have the 486, RAM, a CPLD for glue logic, a timer and interrupt controller, a real-time clock, and a serial interface chip. 64 00:08:34,240 --> 00:08:39,420 The IO board is responsible for interfacing with all the 429 buses. 65 00:08:39,840 --> 00:08:53,080 On the board we have the 386, the dual-ported RAM, and some custom ASICs that we're pretty sure are 429 transceivers, along with some analogy bits to interface with the 429 bus. 66 00:08:53,900 --> 00:08:59,860 So this is the Honeywell Mk3 processor board, and underneath that heatsink is a Pentium. 67 00:08:59,860 --> 00:09:12,320 There's also RAM, some glue logic, and a very annoying non-volatile storage system, which relies on a battery, which of course has gone dead by now, basically breaking the system. 68 00:09:12,880 --> 00:09:17,860 So the IO board on the Honeywell Mk3 is a rather interesting beast. 69 00:09:17,920 --> 00:09:28,800 The first thing that pops out to me is that there are two PowerPCs, and through our reverse engineering, it seems like only one of them is used for IO, while the second supports reflashing the system. 70 00:09:28,980 --> 00:09:37,140 So in the middle there is a CPLD, which we suspect interfaces the 429 transceivers with the PowerPC chips. 71 00:09:37,340 --> 00:09:41,280 There are a number of interesting connectivity options on here. 72 00:09:41,280 --> 00:09:53,500 So for example, there's an Ethernet controller on there with magnetics, probably for supporting a gate link upgrade, whereby you can push messages to the CMU over Wi-Fi. 73 00:09:53,500 --> 00:10:05,200 There's also a DSP chip next to an ADC, and we suspect that's used for sending ACARS messages over legacy VHF radios. 74 00:10:05,220 --> 00:10:16,520 But also interestingly enough, there's a V.90 modem chipset, and I'm not really sure why this exists, especially with that other DSP chip on there. 75 00:10:16,520 --> 00:10:21,620 Perhaps they were leaving the option open to plug a CMU into a phone line. 76 00:10:22,120 --> 00:10:28,800 Not really sure that would make sense on an aircraft, but it might make sense for maintenance. 77 00:10:29,780 --> 00:10:33,180 And of course, there's lots of JTAG connectors everywhere. 78 00:10:33,180 --> 00:10:34,960 It warms my heart. 79 00:10:35,360 --> 00:10:41,000 So let's take a deep dive into how the Honeywell Mk3 is actually constructed. 80 00:10:41,860 --> 00:10:53,000 So to begin our reverse engineering journey, we sacrificed one board, removed the conformal coding, pulled off the flash chips, dumped the flash chips, and ran strings on the binaries. 81 00:10:53,000 --> 00:10:55,720 And what we saw next was surprising. 82 00:10:56,680 --> 00:11:00,540 This program must be run under Win32. 83 00:11:01,040 --> 00:11:02,240 Wow. 84 00:11:02,660 --> 00:11:09,040 By looking for PE headers, we were able to carve the flash ROM into a number of interesting files. 85 00:11:09,040 --> 00:11:12,160 It also turns out the flash had multiple partitions. 86 00:11:12,160 --> 00:11:19,680 One seemed to be for flight mode, another seemed to be for update mode, and another for recovery. 87 00:11:19,900 --> 00:11:25,360 So as it turns out, Honeywell wrote their own realtime OS called DOS. 88 00:11:25,400 --> 00:11:35,520 And one of the interesting things about DOS is that its scheduler was ported to Java and formally verified by NASA to ensure that it always met its realtime requirements. 89 00:11:35,520 --> 00:11:39,480 As you might have guessed, it seems heavily inspired by Windows. 90 00:11:39,500 --> 00:11:43,120 It loads statically linked portable executables. 91 00:11:43,200 --> 00:11:49,380 The APIs look a lot like Win32 or the Windows NT kernel API. 92 00:11:49,620 --> 00:12:00,260 And in fact, while reverse engineering the kernel, if I didn't know what a parameter to a function was, I would just go to MSDN, and it would probably have the right answer. 93 00:12:01,020 --> 00:12:09,540 And it even has a concept of a registry, which is basically just a small binary blob of configuration parameters. 94 00:12:10,080 --> 00:12:13,300 So why is DOS so similar to Windows? 95 00:12:13,320 --> 00:12:18,220 Is it because they wanted to develop the CMU code against a Windows target? 96 00:12:18,400 --> 00:12:25,600 Well, this is pure speculation, but here's a map of Microsoft campus in Redmond, Washington. 97 00:12:26,460 --> 00:12:30,520 And right across the street is Honeywell Aerospace. 98 00:12:30,920 --> 00:12:39,680 So again, just speculation, but I'm guessing it was likely developed by ex-Microsoft employees. 99 00:12:40,500 --> 00:12:47,400 So outside of the kernel, the bulk of the CMU code is in a single executable called CMU core. 100 00:12:47,400 --> 00:12:53,760 And this is written in a language called SDL, the Specification and Description Language. 101 00:12:53,760 --> 00:12:56,780 And this was created by the ITU. 102 00:12:56,780 --> 00:13:00,460 And it is a language that only telecoms can love. 103 00:13:00,460 --> 00:13:07,700 Data structures are defined by ASN 1, and basically it's intended for building telephone switches. 104 00:13:07,700 --> 00:13:11,760 If you're familiar with Erlang, it's spiritually similar. 105 00:13:11,760 --> 00:13:16,840 SDL lets you define loosely coupled state machines that pass messages to each other. 106 00:13:16,840 --> 00:13:19,160 So it's ideal for protocol handling. 107 00:13:19,920 --> 00:13:22,560 SDL has a couple of forms that it can take. 108 00:13:22,560 --> 00:13:25,680 There is both a graphical and a textual form. 109 00:13:25,720 --> 00:13:28,680 The graphical form is shown here. 110 00:13:28,680 --> 00:13:34,960 So basically you write state machines that send and receive messages or are triggered by timers. 111 00:13:34,960 --> 00:13:38,260 And you can also execute arbitrary C code. 112 00:13:38,860 --> 00:13:44,860 Now there's a companion language to SDL called MSC, or Message Sequence Charts. 113 00:13:44,860 --> 00:13:50,800 And this lets you define protocol flows and test cases to validate your SDL against. 114 00:13:51,140 --> 00:13:58,720 And by writing test cases for handling 429 and ACARS messages, they can verify that the SDL code is correct. 115 00:13:58,980 --> 00:14:04,260 So like I said, SDL programs are composed of loosely coupled state machines called tasks. 116 00:14:04,260 --> 00:14:07,240 And in CMU Core, there are a lot of tasks. 117 00:14:07,240 --> 00:14:10,260 And many of them send messages to each other. 118 00:14:10,400 --> 00:14:17,340 Now, I'm not going to read through this entire list here, but I encourage you to pause the video and take a look at the list. 119 00:14:18,000 --> 00:14:21,660 So at this point, we have SDL code that is verified. 120 00:14:21,660 --> 00:14:31,980 And that SDL code is then compiled down to C code by a product called ObjectGeode, which was made by a company named, confusingly enough, Verilog. 121 00:14:31,980 --> 00:14:34,860 No relation to the hardware description language. 122 00:14:34,860 --> 00:14:37,820 But how do airlines make their own apps? 123 00:14:37,960 --> 00:14:44,640 Well, it turns out that the SDL code actually reads app logic from databases stored in Flash. 124 00:14:44,840 --> 00:14:50,240 So I'm sure you've all heard of SQL, but there's also another database language called QWEL. 125 00:14:50,240 --> 00:14:56,120 And the database on the Honeywell Mark 3 is an embedded version of Ingress QWEL. 126 00:14:56,560 --> 00:15:06,020 Now, the crazy thing is that queries are directly embedded in C files, which are then preprocessed into other C files, which are then compiled and linked against. 127 00:15:06,680 --> 00:15:14,280 So if you want to write a query that iterates through employee names, you can write it sort of as a pseudo for loop, as shown here. 128 00:15:14,280 --> 00:15:21,700 And that will be turned into a database query, and that printf will be executed for every row returned. 129 00:15:22,860 --> 00:15:29,940 So unfortunately, these queries are directly converted into C code, so there are no query strings in the executable. 130 00:15:30,260 --> 00:15:37,960 And furthermore, we don't even have any schema information, since it's known at compile time, so there is no reason to store it in Flash. 131 00:15:39,140 --> 00:15:41,500 So how are these apps created? 132 00:15:41,600 --> 00:15:57,380 Well, Honeywell has this tool called the Ground-Based Software Tool, which is used both to create HGI, the Honeywell-generated information, as well as the AMI, or the Airline Modifiable Information. 133 00:15:57,600 --> 00:16:04,740 And basically, this tool lets you populate the database tables that define your app. 134 00:16:04,740 --> 00:16:12,040 And this is used both for certified apps made by Honeywell, as well as custom operational apps made by airlines. 135 00:16:13,000 --> 00:16:17,120 So how do these state machines actually interact with real hardware? 136 00:16:17,220 --> 00:16:29,260 Well, these SDL messages are serialized and sent through DOS's inter-process communication mechanism, mailboxes, to a process called DP-RAM-IO. 137 00:16:29,300 --> 00:16:36,760 And DP-RAM-IO takes these messages and shoves it into the dual-ported RAM, which is shared by the PowerPCs. 138 00:16:37,140 --> 00:16:41,280 And the PowerPCs handle the low-level interface to the hardware. 139 00:16:41,280 --> 00:16:48,980 So as I said before, one seems to handle the PCMCI update cards and does little else. 140 00:16:49,140 --> 00:16:52,300 The other one seems to handle almost everything. 141 00:16:52,600 --> 00:16:57,280 Unlike the Pentium chip, the PowerPCs run the Vertex real-time OS. 142 00:16:57,660 --> 00:17:01,280 And the code on the PowerPCs is also written in SDL. 143 00:17:01,280 --> 00:17:07,820 So this makes it fairly easy to pass messages back and forth between the x86 and PowerPCs. 144 00:17:08,480 --> 00:17:13,960 So Vertex is a fairly old, but well-proven real-time operating system. 145 00:17:14,080 --> 00:17:22,120 And to emphasize this point, here's an ad from 1983, where they will buy you a VW bug if you find a bug in their OS. 146 00:17:23,960 --> 00:17:28,980 So there's one tricky bit about passing messages between the x86 and PowerPC. 147 00:17:29,440 --> 00:17:34,900 And that is x86 is little-endian, while PowerPC is big-endian. 148 00:17:35,100 --> 00:17:43,860 And so the way that they actually solve this is with one giant switch statement based on the message type to do the endianness swap. 149 00:17:44,380 --> 00:17:50,200 And that code is written in C, which of course is far more promising for bugs. 150 00:17:51,000 --> 00:17:53,100 And in fact, we found some. 151 00:17:53,100 --> 00:17:59,540 So we found some signed versus unsigned confusion and some integer overflows as well. 152 00:17:59,980 --> 00:18:03,380 Fortunately, they do not seem to be exploitable. 153 00:18:03,400 --> 00:18:10,520 So now that we have a general idea of how the CMU works, let's actually try going and see if we can find some real bugs. 154 00:18:11,100 --> 00:18:14,960 So static analysis of this auto-generated code is hard. 155 00:18:14,960 --> 00:18:17,740 So we'd like to do some dynamic analysis. 156 00:18:18,220 --> 00:18:22,780 Unfortunately, getting the CMU to boot was challenging. 157 00:18:23,440 --> 00:18:26,520 It does a lot of self-tests on startup. 158 00:18:26,560 --> 00:18:29,580 If something is wrong, it just won't boot. 159 00:18:29,580 --> 00:18:34,600 And we spent several months with it just blinking the fail light at us. 160 00:18:35,420 --> 00:18:42,300 Fortunately, we found some serial ports on the front maintenance port, which gave us some clues as to what was going wrong. 161 00:18:42,800 --> 00:18:48,320 So when we powered up the CMU, it would state that it was starting its built-in functional test. 162 00:18:48,500 --> 00:18:52,720 Unfortunately, after a minute, it would start spitting out error codes. 163 00:18:52,960 --> 00:18:56,720 And as it turns out, this was because the APM was missing. 164 00:18:56,720 --> 00:19:08,060 Now the APM is the airline personality module, which has the tail number, the aircraft configuration, the type of aircraft it is, and a host of other settings. 165 00:19:08,060 --> 00:19:11,620 So if you need to replace the CMU, you don't have to reprogram it. 166 00:19:11,620 --> 00:19:21,560 You just pull it out, slide in a new one, connects to the existing airplane personality module, and the new CMU knows exactly what it needs to do. 167 00:19:21,940 --> 00:19:37,640 Unfortunately, the only APM we could find was for the Collins CMU-900, which despite being somewhat specified by an airing standard, was totally incompatible, both logically and electrically. 168 00:19:37,920 --> 00:19:44,160 Fortunately, the CMU saves a copy of the last known good APM image in Flash. 169 00:19:44,160 --> 00:19:49,500 And so we were actually able to create an APM emulator with an Arduino. 170 00:19:49,500 --> 00:19:56,520 It basically just emulated an i-squart-z EEPROM, and we used the APM image that we pulled out of Flash. 171 00:19:56,520 --> 00:20:05,940 Now the second issue that we ran into was NVRAM battery was bad, and we didn't actually know that this was preventing the CMU from booting. 172 00:20:06,360 --> 00:20:22,800 We basically had to take one of the cryptic error codes out of the serial console, find where that was in the binary, figure out what triggered that string to be printed, and then discover that it was doing a test on the battery voltage. 173 00:20:23,260 --> 00:20:29,960 As it turns out, we just removed the battery and replaced it with a power supply, and that was good enough to make it boot. 174 00:20:30,400 --> 00:20:35,260 So there was actually a second serial port exposed on the front maintenance port. 175 00:20:35,260 --> 00:20:42,000 And once the system booted, if you pressed enter, you got an interesting maintenance menu. 176 00:20:42,200 --> 00:20:52,920 Another weird behavior is that if you provided input to the first serial port, you would get another menu on the second serial port. 177 00:20:53,420 --> 00:20:57,820 So now that we can get the CMU to boot, let's try doing something with it. 178 00:20:57,820 --> 00:21:03,200 And to do that, we need an MCDU and a VHF data radio. 179 00:21:03,200 --> 00:21:12,040 Unfortunately, we didn't have those, so we ended up writing emulators for them and connected them to the real CMU over the 429 buses. 180 00:21:13,040 --> 00:21:21,020 And this really kicked off the development of a test bed we called Triton to support this kind of testing and security research. 181 00:21:21,760 --> 00:21:28,200 So the Triton test bed is designed to support a mixture of both real and emulated devices. 182 00:21:28,440 --> 00:21:37,580 So for example, we have a real communications management unit, but we don't have a real printer or airborne data loader unit. 183 00:21:37,580 --> 00:21:40,780 So we've created emulators for those. 184 00:21:41,160 --> 00:21:48,480 And these devices are connected through a 429 message routing daemon, which we call R429D. 185 00:21:48,620 --> 00:21:58,080 And R429D both supports real 429 interfaces, as well as accepting connections from emulated avionics units. 186 00:21:58,160 --> 00:22:03,220 Similarly for ACARS, we have a separate daemon that emulates different network segments. 187 00:22:03,380 --> 00:22:11,840 For example, we have one daemon that emulates the air segment, so all the VHF data radios are connected to it. 188 00:22:11,840 --> 00:22:18,500 We also have a separate instance for the ground segment, and we have a virtual ground station that bridges the two segments. 189 00:22:19,920 --> 00:22:25,120 So a little bit about the 429 devices that the Triton test bed supports. 190 00:22:25,120 --> 00:22:32,020 This box here is an Ethernet to 429 converter, and this was one of the first things that we targeted. 191 00:22:32,540 --> 00:22:44,000 Unfortunately, it can only be configured with a static IP address, and it kept getting virtually bricked by having its IP address randomly changed to something that we didn't know. 192 00:22:44,060 --> 00:22:57,500 And we actually suspect that UCSD was doing network scans against this device, and it just so happened that it sent a packet to reconfigure the IP address to some garbage address. 193 00:22:57,840 --> 00:23:10,920 So after a couple of times of opening this up, pulling off the EEPROM, putting in the correct IP address, soldering it back on, getting it back on the network, only to have it bricked again, we decided to find a better solution. 194 00:23:11,140 --> 00:23:17,700 One of the primary interfaces that we use now is this Ballard USB to 429 interface. 195 00:23:17,700 --> 00:23:20,120 Unfortunately, it is rather expensive. 196 00:23:20,600 --> 00:23:27,400 We did also develop our own custom USB to 429 interface, which we called Scorpion. 197 00:23:27,400 --> 00:23:34,040 And if you ever saw the pilot episode of that TV show, you might understand why we called it that. 198 00:23:34,040 --> 00:23:39,580 It's basically an ATmegaU2 with a Holt 429 transceiver. 199 00:23:39,880 --> 00:23:44,620 It supports four transmit channels and eight receive channels. 200 00:23:44,820 --> 00:23:53,960 And this basically interfaces with the R429D daemon to expose a TCP IP interface to the 429 buses. 201 00:23:54,360 --> 00:23:59,480 So now that we have all this wired up, we can start doing some really interesting things. 202 00:23:59,480 --> 00:24:05,720 So on the left here, we have our virtual MCDU, which lets us control our real CMU. 203 00:24:05,820 --> 00:24:27,040 Now connected to the real CMU is our virtual VHF data radio, which we can send real ACARS messages that we pick off over the air, alter the tail number so that our CMU processes them, which then forwards it to our virtual printer program, which sends it to a real credit card receipt printer. 204 00:24:37,290 --> 00:24:44,150 So interacting with the CMU is all well and good, but we'd really like to have some low-level debugging capabilities. 205 00:24:44,270 --> 00:24:48,810 And as it turns out, the main processor board has a Pentium debug port. 206 00:24:49,050 --> 00:24:53,750 Now, unfortunately, the Pentium Probe mode is undocumented. 207 00:24:53,750 --> 00:25:03,750 Details are in the infamous Appendix H of the P5 external interface specification, which was available only under NDA from Intel. 208 00:25:03,750 --> 00:25:06,970 And back in the mid-90s, there were a lot of rants in Dr. 209 00:25:06,970 --> 00:25:08,710 Dobbs' journal about this. 210 00:25:08,710 --> 00:25:18,590 There was one beta version of the P5 external interface specification that had these details, but all these copies were supposedly recalled by Intel and destroyed. 211 00:25:18,770 --> 00:25:21,890 So, of course, there's no copies of this on the web. 212 00:25:21,890 --> 00:25:33,150 But while we were searching for it, we did find that there was one physical copy of an unknown version at an undisclosed university lab halfway across the world. 213 00:25:33,150 --> 00:25:44,010 So we sent them an email and asked if they had it, and if so, what version it was, and that we might be interested in a scan of it. 214 00:25:44,210 --> 00:25:50,610 And so they wrote back with a scan of the title page, which was version 1.3. 215 00:25:50,610 --> 00:25:53,650 And unfortunately, we needed version 3. 216 00:25:53,730 --> 00:26:01,530 So before we could write them back and say thanks, but no thanks, they wrote us back and said they found something very interesting inside. 217 00:26:01,530 --> 00:26:07,350 And sandwiched between the pages of version 1.3 was version 3. 218 00:26:07,850 --> 00:26:19,190 And they happened to send us a scan of the entire thing, including details of the Pentium micro-op instruction format, which is exactly what you need to use the Pentium's probe mode. 219 00:26:19,510 --> 00:26:24,590 So armed with this information, I added P5 debugging support to OpenOCD. 220 00:26:24,630 --> 00:26:27,890 And so now we can use GDB against the CMU. 221 00:26:28,110 --> 00:26:35,930 Unfortunately, if you halt the hardware, the watchdog timers on the other processors will notice something's amiss and reset the entire system. 222 00:26:35,950 --> 00:26:46,650 And the solution for this is to basically run the CMU's x86 firmware in QMU, but relaying messages to the power PCs over JTAG. 223 00:26:46,770 --> 00:26:58,990 And this is based on some of my earlier dissertation work on a system called Surrogates, which lets you run firmware in QMU, but proxies peripheral access over JTAG in near real time. 224 00:26:59,010 --> 00:27:06,870 So now we can instrument the CMU firmware, collect IO traces, do snapshots, and do all sorts of interesting dynamic analysis. 225 00:27:07,610 --> 00:27:15,270 So in summary, the communications management unit supports flight critical operations, which requires the firmware to be certified. 226 00:27:15,270 --> 00:27:17,850 But airlines desire customization. 227 00:27:18,330 --> 00:27:30,230 And through our reverse engineering, we've identified some somewhat unusual ways that vendors have isolated these uncertified apps from the rest of the certified system. 228 00:27:30,230 --> 00:27:36,390 And finally, we built a flexible testbed for further security research on avionic systems. 229 00:27:36,390 --> 00:27:43,830 So if you would like more information about our Triton testbed or surrogate system, check out our site at aerosec.org. 230 00:27:43,830 --> 00:27:44,590 Thanks!