WEBVTT 00:00.870 --> 00:02.510 Okay, so what are we going to cover today? 00:02.510 --> 00:07.710 We're going to explain what a vehicle diagnostics adapter, or VDA, is to you. 00:08.250 --> 00:13.330 Then we're going to talk about, you know, some research we did attacking the VDA. 00:13.810 --> 00:18.790 And then we're going to talk about ways and approaches we took to defend the VDA. 00:19.390 --> 00:24.050 And then finally, we're going to talk about some educational things we did with the VDA. 00:24.210 --> 00:31.730 So specifically, we had four challenges in last year's Car-Convilled CTF that were based around the VDA. 00:31.730 --> 00:33.410 This is a picture of it here. 00:33.410 --> 00:35.170 We had it in Vegas mode, so... 00:38.780 --> 00:40.380 Yeah, look at that. 00:41.320 --> 00:43.960 Binary modification for Vegas mode, awesome. 00:44.420 --> 00:48.820 And we also did some educational things at the Cybertruck Challenge we'll talk about. 00:49.180 --> 00:58.100 So Alex and I are on stage today, but Edward and Sam did a lot of this work as well as a team effort, so we wanted to acknowledge them. 00:58.100 --> 01:00.320 We also wanted to acknowledge Dr. 01:00.320 --> 01:05.080 Jeremy Daly, who put us on the path to looking at VDAs. 01:05.720 --> 01:21.620 And Friendly Vendor Person, who will not be named today, but helped give us some of the VDAs for some of the educational things, and was a really good partner working with us to shine light on this part of trucking security. 01:21.880 --> 01:22.560 Cool. 01:26.760 --> 01:29.840 All right, so finally, what is a vehicle diagnosis adapter? 01:31.140 --> 01:36.060 So your truck has an OBD port in it. 01:36.060 --> 01:43.140 It's a thing that technicians can plug into to pull diagnostic information off the truck. 01:43.180 --> 01:51.160 I think the VIN number comes through there as well, so you can pull the VIN number through there, and also some information from some of the ECUs or the controllers on the truck. 01:51.820 --> 01:56.320 It also sometimes is used to flash the firmware of the ECUs within the truck. 01:56.360 --> 02:05.460 So the idea is you pull into a service station, you can plug in there, and I guess the way they do it is there's a little computer, the VDA, that actually plugs into the truck. 02:06.440 --> 02:11.200 And then there's a, for some reason it's always a Windows computer that plugs into the VDA. 02:11.440 --> 02:26.920 So you have like a Windows laptop with these vendor DLLs that, there's kind of like a joint protocol, I think it's called RP-1210, that everyone used to talk to the VDA, then the VDA talks to the truck, and it pulls data back and forth from it. 02:28.180 --> 02:32.300 And you can kind of see here on the right, this is kind of a diagram of the VDA we looked at. 02:32.300 --> 02:41.480 So on the right, there's the computer interface, so the USB, Bluetooth, and Wi-Fi, also is how you connect directly to the VDA. 02:41.560 --> 02:48.300 And then the micropositor connects to the vehicle network, usually over J1939, unless it's really old. 02:50.760 --> 02:54.460 Okay, so congratulations, we all now know what a VDA is. 02:56.920 --> 02:59.280 Okay, so now we're gonna talk about attacking the VDA. 03:01.780 --> 03:08.660 So we do a lot of embedded device security around balloons, so attacking embedded devices, it's a pretty simple formula. 03:09.160 --> 03:10.980 First, you need to get the thing. 03:11.880 --> 03:13.720 The internet is really good with this. 03:13.920 --> 03:19.880 Pro tip, get more than one of the things, because you'll probably break one of them in the process. 03:20.080 --> 03:22.280 I think you broke one of these, yeah. 03:23.320 --> 03:25.420 Then you wanna do the hardware reversing. 03:27.160 --> 03:33.440 Figure out, I guess, enumerate all the components on the board, figure out if it has JTAG, UART, stuff like that. 03:33.440 --> 03:37.660 Then you wanna get the firmware either from the board or from some sort of firmware update thing. 03:37.820 --> 03:41.240 Reverse the firmware, figure out how to update the firmware. 03:42.680 --> 03:47.840 And then if you can modify the firmware and put the modified firmware back on, you can change how it works. 03:48.100 --> 03:49.580 And then you win. 03:49.840 --> 03:57.760 So this is pretty complicated, so when we started working on this, we decided that it was so hard that only our interns could do it. 03:58.800 --> 04:00.200 And so that's where Alex came in. 04:00.200 --> 04:02.340 He was an intern at the time, he's a full-time employee now. 04:02.340 --> 04:07.580 So he's gonna walk you through the work he did as an intern, you know, trying to figure out how this thing works. 04:10.400 --> 04:19.100 Awesome, so the first step that we always go through when reversing a new device is grabbing your favorite screwdriver set and taking it apart. 04:19.600 --> 04:22.680 So that's what we did. 04:23.160 --> 04:26.920 This is a shot of the PCB of one of the VDAs. 04:27.440 --> 04:37.680 And as you can see, the vendor did a great job making connecting to JTAG and UART super hard by giving us really awesome adapters to use and just plug into. 04:38.540 --> 04:47.420 We've identified the flash, the microcontroller, and then a Wi-Fi chip and a Bluetooth chip on this board. 04:47.600 --> 04:50.780 Now, the more astute of you might be noticing... 04:52.880 --> 05:03.820 the Wi-Fi chip has a Wi-Fi and Bluetooth stack, but there's also a Bluetooth chip on the board, which begs the question, why? 05:06.680 --> 05:08.520 We don't have a great answer. 05:08.520 --> 05:17.960 I think these memes probably illustrate some of our confusion as to why there were two independent Bluetooth stacks on this device, but it had both. 05:18.560 --> 05:33.560 So once we took a look at the hardware and read a couple of data sheets, we were able to make a super legit power adapter to plug in the VDA in a way that it's not normally powered. 05:33.580 --> 05:39.060 Yeah, this is what happens when you tell an intern to power a VDA, but it gets the job done, so that's cool. 05:40.080 --> 05:52.400 And then just grab your favorite female adapter cables to connect to the UART and not have to do any work with that, really, because the vendor provided a handy-dandy interface. 05:54.540 --> 06:11.720 So once we connected to the UART, unlike most devices that try and obfuscate and make it really difficult to find out what the debug options are on a shell, the vendor just gave us a really easy way of dumping memory. 06:11.720 --> 06:19.260 So, you know, we typed in dump invalid option and then got every possible permutation of dumping we could ever want. 06:19.260 --> 06:20.820 So it was pretty simple. 06:20.820 --> 06:25.220 We're just like, hey, can we get the first copy of firmware on the device? 06:27.040 --> 06:30.920 And then it spits it out handy-dandy over ASCII over UART. 06:30.920 --> 06:41.420 So, you know, I wrote a really complicated extraction algorithm, which is dump the whole firmware to serial and then write a Python program to convert that into binary. 06:46.930 --> 07:04.590 So once we actually had the bytes of the firmware sitting in memory on the device, what we wanted to do is reverse engineer the file format that actually puts those bytes on the device so then we can see whether we can actually change the bytes that are put on the device. 07:04.850 --> 07:13.950 So as Wyatt mentioned, this piece of hardware uses a Windows laptop in order to do the firmware update. 07:13.970 --> 07:20.150 And so I was a little worried because I hadn't done Windows reversing that this would be kind of complicated. 07:20.150 --> 07:28.930 But it turns out the firmware update format file was just put in the files for the application on Windows, like called firmware.bin. 07:28.930 --> 07:31.480 So that took about two seconds to look at. 07:32.010 --> 07:36.330 And then we had the full firmware update file for the manufacturer. 07:40.450 --> 07:45.270 This is a colorized GIF of me reversing the firmware update. 07:45.570 --> 07:46.890 It did not take that long. 07:46.890 --> 07:50.710 We're not going to go into the details of how this firmware format actually works. 07:50.710 --> 07:55.350 But if you spend enough time looking at it, you will be able to figure it out. 07:56.050 --> 08:05.470 And once we did that, we knew how the vendor firmware update file translates to the bytes actually sitting in memory on the device. 08:08.620 --> 08:18.780 So once we'd done all that really complicated reversing work, we wanted a way to be able to replicate that so no one would have to go through the same process. 08:18.780 --> 08:22.240 So internally, this is our tool called OFrac. 08:22.240 --> 08:25.040 This is what Red Balloon Security uses internally. 08:25.200 --> 08:26.960 It's also open source. 08:26.960 --> 08:28.340 You guys can try it at home. 08:28.760 --> 08:50.540 And it allows us to very easily go through all of the steps that we normally do to reverse engineer and modify firmware so we can identify arbitrary binary formats, unpack them, analyze them, make the changes that we want, and then repack them up in the format that the device expects. 08:51.380 --> 08:55.240 It's in Python, and we have a really snazzy GUI on the right. 08:55.400 --> 09:00.060 If you guys want to take a look at it in more depth, we'll be at our booth over there demoing it. 09:03.580 --> 09:18.840 So after I reverse the format, we can write a script in Python that specifies the firmware format and allows us to make the modifications programmatically and have it spit out a binary that we can just drop back on the device. 09:19.400 --> 09:23.080 So saving a lot of time for anyone else to have to do any of the reversing. 09:29.460 --> 09:44.920 So now that we know how to make the firmware file for the device to take, we wanted a more fun way of putting it on the device than just putting that file back in the Windows file system and clicking through the vendor tool to actually put it on. 09:45.100 --> 09:48.200 So the firmware update happened over USB. 09:48.820 --> 09:52.140 So, you know, computer connected to a thing over USB. 09:52.720 --> 09:53.640 What do you do? 09:53.640 --> 09:56.960 You sniff the USB traffic and store it as a PCAP. 09:57.560 --> 10:00.700 And then we spent a really long time reversing it. 10:00.700 --> 10:10.380 We're going to go through the protocol later and then wrote our own little Python script to just do the firmware update and then got rid of our Windows laptop because we don't really like Windows. 10:15.440 --> 10:31.000 So to go over the super complicated update procedure of this device, you first have to send hex 3 and then the size of the firmware update in hex as a USB packet and then wait for it. 10:33.310 --> 10:36.990 You just send the entire bytes of the firmware update. 10:37.390 --> 10:38.930 There's no encryption. 10:38.930 --> 10:40.150 There's no signature. 10:40.150 --> 10:47.030 It has a CRC check, but you basically just slop it in a USB packet and it just takes it up and rewrites the firmware. 10:49.950 --> 10:52.370 For those playing at home, there's bonus points. 10:52.370 --> 10:56.550 This same unauthenticated firmware update works over HTTP. 10:56.550 --> 11:04.850 So if you have Wi-Fi on the device, you could very easily just connect to the access point and then do this exact same update format over HTTP. 11:10.300 --> 11:18.120 So now we have a full way of having bytes that we can modify our computer and putting it on the target device. 11:18.120 --> 11:20.320 So what do we do with that? 11:20.420 --> 11:28.960 Well, the first thing that we always do when performing this type of analysis is testing that are unpacking and repacking and this whole process works correctly. 11:28.960 --> 11:34.260 So the first thing that we normally do is just by modifying a string and seeing whether the device still boots. 11:34.900 --> 11:36.120 So that worked. 11:36.860 --> 11:44.320 And then we wanted to do something more fun, which we showed you at the beginning, which was the LED toggle that we hooked into ping. 11:44.880 --> 11:48.300 So you can see the code on the right, pretty complicated. 11:48.300 --> 11:56.140 But again, we used OFRAC, which is our custom unpacker and packer tool, in order to put this code into the binary. 11:56.140 --> 12:05.900 And specifically, we used OFRAC with a tool we wrote called Patchmaker, which allows us to compile C into bytes and then link it into the full firmware image. 12:05.920 --> 12:11.940 So it's really easy to iterate and write code and just plunk it back in the binary without having to deal with any linking. 12:12.420 --> 12:19.380 So this case was a little bit more difficult than normal. 12:19.380 --> 12:26.620 If you can see on the top left, the compiler directive, underscore, underscore, reg args. 12:27.220 --> 12:32.540 The calling convention for this toggle LED function was kind of abnormal. 12:32.980 --> 12:35.600 So the architecture of this was Motorola Coldfire. 12:36.100 --> 12:44.800 And for this specific function, you needed to pass in the first argument as a register, which kind of messed with our compiler toolchain. 12:44.800 --> 12:50.060 So we had to use a different toolchain written by the wonderful Dr. 12:50.060 --> 12:51.280 Volkel Barthelme. 12:51.880 --> 12:54.920 Shout out to him, who made the VBCC toolchain. 12:54.920 --> 13:02.560 And then we just had to integrate it into our tool and compile that code in, and then, boom, just add in our modification. 13:03.020 --> 13:04.460 Yeah, Dr. 13:04.460 --> 13:05.620 Volkel Barthelme. 13:05.620 --> 13:06.940 His website's pretty cool. 13:06.940 --> 13:08.380 I would definitely check it out. 13:09.200 --> 13:12.520 VBCC supports a lot of architectures. 13:12.520 --> 13:17.160 It looks like it's from the 90s, but we built it, and it worked right away. 13:17.540 --> 13:23.220 So just to highlight this, this is kind of how we do binary modification with OFRAC. 13:23.220 --> 13:32.520 We can use runPingCMD as a function we found in the binary, and we wanted to overplace it so whenever we pinged, we would toggle the LED lights. 13:32.780 --> 13:38.480 And so in this case, we were able to call toggleLED directly in the C code that we're writing. 13:38.620 --> 13:49.640 And then using Patchmaker, we can compile this code and then link it in so that all the addresses just work with the target binary, and then just use OFRAC to copy it back into the target binary. 13:49.640 --> 13:56.380 So you get pretty readable C, that's really useful for developing binary modifications. 14:01.950 --> 14:02.850 Awesome. 14:02.850 --> 14:11.030 So, so far we showed you a cool demo with LEDs, like why do we care about this ability to modify the former of the VDA? 14:11.130 --> 14:18.350 So most VDAs are used to update the engine control unit in these big trucks. 14:18.350 --> 14:23.810 So the workflow is you have a new engine control unit firmware from the vendor that needs to be updated. 14:23.910 --> 14:31.270 It gets passed to the VDA, which then directly uses it and sends it over to the ECU to flash it. 14:31.550 --> 14:37.210 And so the engine control unit obviously controls the engine, very important part of the car. 14:37.210 --> 14:45.750 That's why it's worrying in particular that the VDA is normally completely unsecured, right? 14:45.750 --> 14:53.550 Like this is a device that technicians use at the dealership, not really locked up, not a part of anyone's threat model. 14:53.550 --> 14:58.330 Anyone could sort of walk in and do this kind of firmware change. 14:58.450 --> 15:09.950 And then in addition, you know, since we found so many ways to update this firmware, really not a good thing that this is a critical path in terms of getting firmware on the engine controller. 15:13.990 --> 15:14.770 Excuse me. 15:14.770 --> 15:32.810 So, you know, as a result, you could, for example, put an implant on the VDA, wait for an engine controller update, add your own modifications to it, and then unbeknownst to anyone else, you now have code running on the ECU of that big truck, which is obviously really not great. 15:34.910 --> 15:38.530 Yeah, so this is kind of where the attack work ended. 15:38.530 --> 15:51.170 We were able to, as you see, modify the firmware to put it in Vegas mode, flash the LED lights, which is fun, but those LED lights are what tell the technician that the device is on or off, if Wi-Fi is connected, if data is being transmitted. 15:52.030 --> 15:55.510 So you can use your imagination to think about what things like that can do. 15:56.430 --> 16:04.590 Alex mentioned, you know, sometimes firmware updates, these ECUs pass through this device, some diagnostic data come out, so it's a really nice place for an attacker to sit. 16:04.690 --> 16:09.770 And this work kind of extends work that Dr., that Jeremy Daly and Srikanth Kumar did. 16:09.770 --> 16:15.970 They presented at ESCAR this year about attacking the Windows application that communicates with the VDA. 16:16.470 --> 16:18.050 So I'd recommend checking out that work. 16:18.050 --> 16:29.150 They looked at the Windows DLLs and found that it was pretty easy to insert shim DLLs into the process and peek and poke and manipulate packets on the Windows laptop. 16:29.150 --> 16:34.490 So kind of all the way down to the truck, there's all these places where you can insert and manipulate the traffic. 16:34.490 --> 16:36.750 Something interesting just to think about. 16:40.380 --> 16:44.680 Okay, so now we're gonna defend it, we're gonna fix all the problems and go home, yay. 16:45.640 --> 16:50.940 So we're not actually gonna fix all the problems today, we're just gonna focus on some of the low-hanging fruit. 16:51.200 --> 16:57.280 So the immediate problem here is, you might have noticed there's Wi-Fi and Bluetooth on this VDA. 16:57.600 --> 17:02.800 And I think you can imagine that some people might not want that Wi-Fi and Bluetooth enabled. 17:03.120 --> 17:04.820 I wouldn't want it enabled. 17:05.320 --> 17:13.700 I think people maintaining military vehicles might not want to have Wi-Fi access point on their VDAs they're plugging in, or Bluetooth as well. 17:14.180 --> 17:29.920 But this is kind of a classic situation in not just automotive, but all embedded devices where the vendors, either they don't want to or can't remove the hardware components and software components that these features are implemented on. 17:30.920 --> 17:38.780 And so the way you disable the features is essentially flipping a bit in a config file saying, don't turn on Wi-Fi, don't turn on Bluetooth. 17:38.940 --> 17:42.800 But as we all know, the code that underlines it and the hardware is still there. 17:42.800 --> 17:50.520 So an attacker can still modify the firmware or use an exploit to then turn on these features. 17:50.880 --> 17:53.060 So it's a very ripe attack surface. 17:53.660 --> 17:57.660 So we're going to be talking about VDAs, but I encourage you to think about, this is a broader problem. 17:57.660 --> 17:59.860 We have component access features, ABC. 17:59.860 --> 18:01.180 We don't want those features. 18:01.180 --> 18:03.980 We can't remove them because the vendor won't remove them. 18:03.980 --> 18:06.520 So how can we remove them in the binary? 18:08.800 --> 18:20.880 Okay, so what we're going to do today to talk you through and what we did is like, how can we apply a binary patch to the VDA firmware that removes all the code that underpins these features without having any side effects on the device? 18:21.020 --> 18:23.480 And of course, this is an example of a general problem. 18:23.480 --> 18:32.560 How do we remove features XYZ from component A so there's no side effects and those features can't work and the attack surface isn't there for people to use? 18:34.000 --> 18:37.280 So we use a technique called autotomic binary reduction. 18:37.280 --> 18:39.860 So the name is derived from nature, actually. 18:39.860 --> 18:41.780 It's a nice place to look for inspiration. 18:42.280 --> 18:49.840 So autotomy is when animals will shed a part of their body when they're being attacked to make it harder for predators to catch them. 18:50.180 --> 18:54.860 So ABR was proposed by our CEO Ong when he was a graduate student at Columbia. 18:54.860 --> 18:56.240 That's where the work comes from. 18:56.280 --> 18:59.500 So if you want to really get into the math behind it, you can look at his dissertation. 18:59.940 --> 19:02.620 But to simplify it, there's really just four steps. 19:02.680 --> 19:08.200 First, you identify the high-level feature that you don't want, and then you identify the entry point in the code for it. 19:08.500 --> 19:17.700 Then you can use analysis tools to identify all the code and data that are exclusively controlful, dependent on those entry points. 19:18.080 --> 19:22.180 You want to do this very carefully, so if you're not sure, you'll leave something in. 19:22.360 --> 19:31.320 And then you remove that code and data, and then you replace the high-level entry point with a return patch that makes sense if the program ever calls it. 19:31.320 --> 19:37.140 So if you think about a Bluetooth subsystem, there's usually some sort of process that initializes everything. 19:37.140 --> 19:47.240 You can remove the code for that and insert a return negative one, or it depends on what is actually in the system, but return code that will tell the system this is not up and it's not going to run. 19:48.060 --> 19:50.460 So this graph, I think, simplifies. 19:50.460 --> 19:53.980 Obviously, it's more complex, but at a high level, this is the idea. 19:53.980 --> 19:57.600 If you have feature A and feature B, we want to remove feature A. 19:57.760 --> 20:03.520 We look at the control flow graph, find all the functions that are exclusively controlful, dependent on feature A. 20:03.700 --> 20:08.820 So function five, we cannot remove, but functions one and two, three, we can. 20:08.820 --> 20:11.320 And then we insert that return patch there. 20:14.880 --> 20:24.720 So the workflow for this is fairly standard, and actually, Alex did most of the work already that you need human input for now in. 20:24.720 --> 20:28.780 So we've understood how the firmware works and how we can update the firmware. 20:28.800 --> 20:43.260 So next step is just to identify the feature points, and then all of the actual autotomy work about identifying the code that needs to be removed and removing it and packing the firmware, we can completely automate right now with the work we have. 20:43.260 --> 20:47.400 And what we're doing as a company is we're trying to move up the stack to automate this entire process. 20:47.700 --> 20:50.940 So there's minimal human interaction needed into it. 20:55.070 --> 20:58.670 Okay, so identifying the feature entry points, how do you do that? 20:58.690 --> 21:01.930 Well, this is where you have to like, you know, roll up your sleeves and do a little reversing. 21:02.590 --> 21:08.370 So on embedded systems like the VDA, this can be a little complicated, but sometimes you get lucky. 21:08.370 --> 21:16.110 So in this case, you can use symbols to find leaked source code online that you can use to then label the functions in your project. 21:16.110 --> 21:18.330 This was using ColdFire. 21:18.330 --> 21:23.650 So in this case, we use Gija, but you can use, you know, any other disassembly tool as well to do this. 21:23.650 --> 21:28.350 And then you can kind of start labeling the features inside the binary. 21:28.350 --> 21:30.810 So a new binary comes in, this whole process can be automated. 21:30.810 --> 21:39.370 You can start with the debug strings within the binary and then work up to find the functions and then automate this process removing that code. 21:41.230 --> 21:49.030 So for this like proof of concept, we generalized five entry points, the OS tasks that initialize the subsystems. 21:49.030 --> 21:52.910 We also wanted to remove the UR debug commands because we found them super useful. 21:52.930 --> 21:56.950 And yeah, it should be harder to figure out how to dump the memory from the device. 21:56.950 --> 21:57.830 I think, yeah. 21:58.750 --> 22:03.710 Then we also targeted some driver initialization code for these things as well. 22:04.870 --> 22:06.070 And these were the results. 22:06.070 --> 22:09.030 So we use the ABR algorithm that we have ever balloon. 22:09.030 --> 22:17.390 We removed in total 574 functions and ended up being 144 kilobytes of code. 22:17.390 --> 22:19.210 So that was about 7% of the binary. 22:19.210 --> 22:20.890 And you can kind of visualize it here. 22:20.890 --> 22:28.850 Everything that's dark was unmodified and the stripes of green here are the areas where ABR removed the binary code. 22:29.010 --> 22:30.070 So it's kind of cool. 22:30.070 --> 22:37.270 You can see like throughout the binary, there's huge swaths of functions that are just not needed and attackers can't use it anymore. 22:37.270 --> 22:45.570 Then we worked with friendly vendor person to test the image using the functional test suite that they used. 22:45.710 --> 22:49.990 And they confirmed that performance was consistent with the original firmware image. 22:50.010 --> 22:50.530 So that was great. 22:50.530 --> 22:55.810 We basically showed we were able to remove this feature and the regular performance of the device wasn't modified at all. 22:57.470 --> 23:00.050 Okay, so we didn't fix all the problems. 23:00.050 --> 23:04.070 So as we're reflecting on this, it's kind of Zen. 23:04.430 --> 23:07.710 We were able to use some of the reversing that attacker would use. 23:07.710 --> 23:11.090 It's the same workflow in the beginning to identify the features and remove it. 23:12.370 --> 23:15.190 So removing the Bluetooth and Wi-Fi code is good. 23:16.590 --> 23:21.350 We would challenge vendors to reconsider whether they even need it. 23:23.550 --> 23:25.730 Yeah, I think that's something we can all think about. 23:25.730 --> 23:27.310 Do we need to put this in? 23:27.450 --> 23:31.410 Can we support firmware builds that don't have it in? 23:31.970 --> 23:38.190 Another thing to think about is ideally you wanna at least not leave the headers on to JTAG and UART. 23:38.810 --> 23:40.530 Ideally disable them as well. 23:40.530 --> 23:44.010 That just makes it a little harder for people to mess with the device. 23:44.050 --> 23:45.970 For production devices, of course. 23:47.210 --> 23:50.670 So then we get to some of the lower level challenges. 23:50.670 --> 23:54.030 How can we make it so anyone can't modify the firmware? 23:54.110 --> 23:58.990 So some sort of secure firmware update mechanism, maybe a secure boot mechanism would be useful here. 23:59.350 --> 24:03.810 And then how do we know that the firmware hasn't been modified? 24:03.810 --> 24:09.790 How do we know that the VDA that's on the shelf in my technician's office hasn't been tampered with? 24:09.930 --> 24:12.850 There's some sort of runtime protection and monitoring could help there. 24:12.850 --> 24:14.850 Because then you could see that the device has been corrupted. 24:18.360 --> 24:23.540 Okay, so we've attacked, we've defended, and now let's talk about some education we did. 24:23.540 --> 24:36.280 So we repurposed this research to build two educational things to kind of take these real world problems and make it challenges that people can use to kind of learn about this specific issue. 24:38.620 --> 24:49.400 And this is another area where the friendly vendor person helped us out because we only had two of these devices, but we were able to, at the Cybertruck Challenge, have, for the last two years, a two hour workshop. 24:50.800 --> 25:06.800 So the Cybertruck Challenge is a pretty cool event that's held every year where a bunch of students are paired up with industry experts in automotive, specifically truck security, and then a bunch of vendors come with fleets, and there's a bunch of education that happens, 25:06.800 --> 25:09.600 and then a bunch of assessments that students do on the devices. 25:09.700 --> 25:11.220 So I encourage you to check it out. 25:11.220 --> 25:14.540 There's also some really good educational resources on the website as well. 25:14.720 --> 25:19.660 So if you're not super familiar with J1939, that's a good place to start. 25:20.060 --> 25:22.880 But anyway, in our workshop, we walked them through this process. 25:22.880 --> 25:26.980 They physically took apart the devices, dumped the firmware. 25:27.080 --> 25:31.760 Getting UART was a really fun moment when you get the shell there. 25:31.760 --> 25:41.100 One thing that we've kind of observed is that familiarity with command line tools is something that probably we could build on more. 25:41.100 --> 25:46.580 So connecting the UART, getting screen working, and stuff like that, it was a really good moment for the students. 25:46.780 --> 25:52.680 And then we walked them through the bootstring modification, and a contained environment where they could toggle the LED lights there. 25:55.040 --> 25:56.320 A little more fun, though. 25:56.320 --> 26:03.680 Last year, as part of the Car-Wrecking Village CTF, we had a bunch of these VDA boards here, and four challenges. 26:04.080 --> 26:05.940 So challenge one was a real-world challenge. 26:05.940 --> 26:13.200 We gave them a PCAP, and we gave them a modified firmware image and said, flash this image on the device. 26:13.400 --> 26:18.440 And so there, the flag printed in the boot shell once you're able to flash the device. 26:19.440 --> 26:21.680 Challenge two was a little too difficult. 26:21.680 --> 26:22.760 It was ambitious. 26:23.400 --> 26:26.140 I think we would remove it if we did it again at CTF. 26:26.140 --> 26:30.980 But there, the challenge was to essentially put the device in Vegas mode. 26:31.780 --> 26:44.360 And then challenge three, there's a really good write-up online that kind of walks through the process, but challenge three involved finding a super -military-grade encryption scheme on the device. 26:44.660 --> 26:49.620 I think it was just a bunch of XORing data against the XOR repeating key. 26:50.560 --> 26:57.080 And so the write-up's really cool because they showed you how they use the ability to map the firmware to load a Giger project, find the function. 26:57.080 --> 27:01.200 And I think they actually emulated the function in this to get the decrypted key there. 27:01.340 --> 27:03.500 And then challenge four was OTA to save the day. 27:03.500 --> 27:10.660 So we had the Wi-Fi access points turned on and you had to do the firmware update procedure, but over the air. 27:14.120 --> 27:16.440 Okay, so just to recap. 27:20.150 --> 27:23.330 Yeah, so that's the binary modified image in Vegas mode. 27:23.330 --> 27:25.630 We talked about what VDAs are. 27:26.090 --> 27:33.390 We showed how it's relatively straightforward to try to modify the firmware on them and attack it. 27:33.390 --> 27:35.550 We can think about what that implies to the industry. 27:35.830 --> 27:43.230 We talked through some ways which binary modifications can be made to harden the image, so we don't need to go to the end manufacturers if we want to. 27:43.470 --> 27:44.850 And we talked about how we can use... 27:44.850 --> 27:46.290 I think this is a really good takeaway point. 27:46.290 --> 27:53.970 You've used real-world research and convert it into challenges to educate both students and also push people out of their comfort zone. 27:53.970 --> 27:57.110 I think this was the first VDA that was at the Carr-Akenville CTF. 27:57.970 --> 28:01.810 And yeah, I think we just wanna acknowledge Edward and Sam who couldn't be here today. 28:02.870 --> 28:06.470 Jeremy and the friendly vendor person for helping out with this. 28:09.410 --> 28:11.150 So, oh, and lastly... 28:13.510 --> 28:14.450 We're at Red Balloon. 28:14.450 --> 28:16.050 We're hiring now. 28:16.790 --> 28:22.290 So if you wanna learn more about OFRAC for this work, we can take some questions now, but we also have a booth over at the Carr-Akenvillage. 28:22.330 --> 28:29.130 And we have two different CTF challenges that we contributed to the Carr-Akenvillage CTF this year as well. 28:29.130 --> 28:31.390 So yeah, thanks for your time.