1
00:00:00,870 --> 00:00:02,510
Okay, so what are we going to cover today?

2
00:00:02,510 --> 00:00:07,710
We're going to explain what a vehicle diagnostics adapter, or VDA, is to you.

3
00:00:08,250 --> 00:00:13,330
Then we're going to talk about, you know, some research we did attacking the VDA.

4
00:00:13,810 --> 00:00:18,790
And then we're going to talk about ways and approaches we took to defend the VDA.

5
00:00:19,390 --> 00:00:24,050
And then finally, we're going to talk about some educational things we did with the VDA.

6
00:00:24,210 --> 00:00:31,730
So specifically, we had four challenges in last year's Car-Convilled CTF that were based around the VDA.

7
00:00:31,730 --> 00:00:33,410
This is a picture of it here.

8
00:00:33,410 --> 00:00:35,170
We had it in Vegas mode, so...

9
00:00:38,780 --> 00:00:40,380
Yeah, look at that.

10
00:00:41,320 --> 00:00:43,960
Binary modification for Vegas mode, awesome.

11
00:00:44,420 --> 00:00:48,820
And we also did some educational things at the Cybertruck Challenge we'll talk about.

12
00:00:49,180 --> 00: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.

13
00:00:58,100 --> 00:01:00,320
We also wanted to acknowledge Dr.

14
00:01:00,320 --> 00:01:05,080
Jeremy Daly, who put us on the path to looking at VDAs.

15
00:01:05,720 --> 00: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.

16
00:01:21,880 --> 00:01:22,560
Cool.

17
00:01:26,760 --> 00:01:29,840
All right, so finally, what is a vehicle diagnosis adapter?

18
00:01:31,140 --> 00:01:36,060
So your truck has an OBD port in it.

19
00:01:36,060 --> 00:01:43,140
It's a thing that technicians can plug into to pull diagnostic information off the truck.

20
00:01:43,180 --> 00: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.

21
00:01:51,820 --> 00:01:56,320
It also sometimes is used to flash the firmware of the ECUs within the truck.

22
00:01:56,360 --> 00: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.

23
00:02:06,440 --> 00:02:11,200
And then there's a, for some reason it's always a Windows computer that plugs into the VDA.

24
00:02:11,440 --> 00: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.

25
00:02:28,180 --> 00: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.

26
00:02:32,300 --> 00: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.

27
00:02:41,560 --> 00:02:48,300
And then the micropositor connects to the vehicle network, usually over J1939, unless it's really old.

28
00:02:50,760 --> 00:02:54,460
Okay, so congratulations, we all now know what a VDA is.

29
00:02:56,920 --> 00:02:59,280
Okay, so now we're gonna talk about attacking the VDA.

30
00:03:01,780 --> 00:03:08,660
So we do a lot of embedded device security around balloons, so attacking embedded devices, it's a pretty simple formula.

31
00:03:09,160 --> 00:03:10,980
First, you need to get the thing.

32
00:03:11,880 --> 00:03:13,720
The internet is really good with this.

33
00:03:13,920 --> 00:03:19,880
Pro tip, get more than one of the things, because you'll probably break one of them in the process.

34
00:03:20,080 --> 00:03:22,280
I think you broke one of these, yeah.

35
00:03:23,320 --> 00:03:25,420
Then you wanna do the hardware reversing.

36
00:03:27,160 --> 00:03:33,440
Figure out, I guess, enumerate all the components on the board, figure out if it has JTAG, UART, stuff like that.

37
00:03:33,440 --> 00:03:37,660
Then you wanna get the firmware either from the board or from some sort of firmware update thing.

38
00:03:37,820 --> 00:03:41,240
Reverse the firmware, figure out how to update the firmware.

39
00:03:42,680 --> 00:03:47,840
And then if you can modify the firmware and put the modified firmware back on, you can change how it works.

40
00:03:48,100 --> 00:03:49,580
And then you win.

41
00:03:49,840 --> 00: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.

42
00:03:58,800 --> 00:04:00,200
And so that's where Alex came in.

43
00:04:00,200 --> 00:04:02,340
He was an intern at the time, he's a full-time employee now.

44
00:04:02,340 --> 00: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.

45
00:04:10,400 --> 00: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.

46
00:04:19,600 --> 00:04:22,680
So that's what we did.

47
00:04:23,160 --> 00:04:26,920
This is a shot of the PCB of one of the VDAs.

48
00:04:27,440 --> 00: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.

49
00:04:38,540 --> 00:04:47,420
We've identified the flash, the microcontroller, and then a Wi-Fi chip and a Bluetooth chip on this board.

50
00:04:47,600 --> 00:04:50,780
Now, the more astute of you might be noticing...

51
00:04:52,880 --> 00: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?

52
00:05:06,680 --> 00:05:08,520
We don't have a great answer.

53
00:05:08,520 --> 00: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.

54
00:05:18,560 --> 00: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.

55
00:05:33,580 --> 00: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.

56
00:05:40,080 --> 00: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.

57
00:05:54,540 --> 00: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.

58
00:06:11,720 --> 00:06:19,260
So, you know, we typed in dump invalid option and then got every possible permutation of dumping we could ever want.

59
00:06:19,260 --> 00:06:20,820
So it was pretty simple.

60
00:06:20,820 --> 00:06:25,220
We're just like, hey, can we get the first copy of firmware on the device?

61
00:06:27,040 --> 00:06:30,920
And then it spits it out handy-dandy over ASCII over UART.

62
00:06:30,920 --> 00: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.

63
00:06:46,930 --> 00: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.

64
00:07:04,850 --> 00:07:13,950
So as Wyatt mentioned, this piece of hardware uses a Windows laptop in order to do the firmware update.

65
00:07:13,970 --> 00:07:20,150
And so I was a little worried because I hadn't done Windows reversing that this would be kind of complicated.

66
00:07:20,150 --> 00: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.

67
00:07:28,930 --> 00:07:31,480
So that took about two seconds to look at.

68
00:07:32,010 --> 00:07:36,330
And then we had the full firmware update file for the manufacturer.

69
00:07:40,450 --> 00:07:45,270
This is a colorized GIF of me reversing the firmware update.

70
00:07:45,570 --> 00:07:46,890
It did not take that long.

71
00:07:46,890 --> 00:07:50,710
We're not going to go into the details of how this firmware format actually works.

72
00:07:50,710 --> 00:07:55,350
But if you spend enough time looking at it, you will be able to figure it out.

73
00:07:56,050 --> 00: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.

74
00:08:08,620 --> 00: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.

75
00:08:18,780 --> 00:08:22,240
So internally, this is our tool called OFrac.

76
00:08:22,240 --> 00:08:25,040
This is what Red Balloon Security uses internally.

77
00:08:25,200 --> 00:08:26,960
It's also open source.

78
00:08:26,960 --> 00:08:28,340
You guys can try it at home.

79
00:08:28,760 --> 00: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.

80
00:08:51,380 --> 00:08:55,240
It's in Python, and we have a really snazzy GUI on the right.

81
00:08:55,400 --> 00: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.

82
00:09:03,580 --> 00: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.

83
00:09:19,400 --> 00:09:23,080
So saving a lot of time for anyone else to have to do any of the reversing.

84
00:09:29,460 --> 00: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.

85
00:09:45,100 --> 00:09:48,200
So the firmware update happened over USB.

86
00:09:48,820 --> 00:09:52,140
So, you know, computer connected to a thing over USB.

87
00:09:52,720 --> 00:09:53,640
What do you do?

88
00:09:53,640 --> 00:09:56,960
You sniff the USB traffic and store it as a PCAP.

89
00:09:57,560 --> 00:10:00,700
And then we spent a really long time reversing it.

90
00:10:00,700 --> 00: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.

91
00:10:15,440 --> 00: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.

92
00:10:33,310 --> 00:10:36,990
You just send the entire bytes of the firmware update.

93
00:10:37,390 --> 00:10:38,930
There's no encryption.

94
00:10:38,930 --> 00:10:40,150
There's no signature.

95
00:10:40,150 --> 00: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.

96
00:10:49,950 --> 00:10:52,370
For those playing at home, there's bonus points.

97
00:10:52,370 --> 00:10:56,550
This same unauthenticated firmware update works over HTTP.

98
00:10:56,550 --> 00: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.

99
00:11:10,300 --> 00: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.

100
00:11:18,120 --> 00:11:20,320
So what do we do with that?

101
00:11:20,420 --> 00: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.

102
00:11:28,960 --> 00:11:34,260
So the first thing that we normally do is just by modifying a string and seeing whether the device still boots.

103
00:11:34,900 --> 00:11:36,120
So that worked.

104
00:11:36,860 --> 00: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.

105
00:11:44,880 --> 00:11:48,300
So you can see the code on the right, pretty complicated.

106
00:11:48,300 --> 00: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.

107
00:11:56,140 --> 00: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.

108
00:12:05,920 --> 00: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.

109
00:12:12,420 --> 00:12:19,380
So this case was a little bit more difficult than normal.

110
00:12:19,380 --> 00:12:26,620
If you can see on the top left, the compiler directive, underscore, underscore, reg args.

111
00:12:27,220 --> 00:12:32,540
The calling convention for this toggle LED function was kind of abnormal.

112
00:12:32,980 --> 00:12:35,600
So the architecture of this was Motorola Coldfire.

113
00:12:36,100 --> 00: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.

114
00:12:44,800 --> 00:12:50,060
So we had to use a different toolchain written by the wonderful Dr.

115
00:12:50,060 --> 00:12:51,280
Volkel Barthelme.

116
00:12:51,880 --> 00:12:54,920
Shout out to him, who made the VBCC toolchain.

117
00:12:54,920 --> 00: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.

118
00:13:03,020 --> 00:13:04,460
Yeah, Dr.

119
00:13:04,460 --> 00:13:05,620
Volkel Barthelme.

120
00:13:05,620 --> 00:13:06,940
His website's pretty cool.

121
00:13:06,940 --> 00:13:08,380
I would definitely check it out.

122
00:13:09,200 --> 00:13:12,520
VBCC supports a lot of architectures.

123
00:13:12,520 --> 00:13:17,160
It looks like it's from the 90s, but we built it, and it worked right away.

124
00:13:17,540 --> 00:13:23,220
So just to highlight this, this is kind of how we do binary modification with OFRAC.

125
00:13:23,220 --> 00: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.

126
00:13:32,780 --> 00:13:38,480
And so in this case, we were able to call toggleLED directly in the C code that we're writing.

127
00:13:38,620 --> 00: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.

128
00:13:49,640 --> 00:13:56,380
So you get pretty readable C, that's really useful for developing binary modifications.

129
00:14:01,950 --> 00:14:02,850
Awesome.

130
00:14:02,850 --> 00: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?

131
00:14:11,130 --> 00:14:18,350
So most VDAs are used to update the engine control unit in these big trucks.

132
00:14:18,350 --> 00:14:23,810
So the workflow is you have a new engine control unit firmware from the vendor that needs to be updated.

133
00:14:23,910 --> 00:14:31,270
It gets passed to the VDA, which then directly uses it and sends it over to the ECU to flash it.

134
00:14:31,550 --> 00:14:37,210
And so the engine control unit obviously controls the engine, very important part of the car.

135
00:14:37,210 --> 00:14:45,750
That's why it's worrying in particular that the VDA is normally completely unsecured, right?

136
00:14:45,750 --> 00: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.

137
00:14:53,550 --> 00:14:58,330
Anyone could sort of walk in and do this kind of firmware change.

138
00:14:58,450 --> 00: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.

139
00:15:13,990 --> 00:15:14,770
Excuse me.

140
00:15:14,770 --> 00: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.

141
00:15:34,910 --> 00:15:38,530
Yeah, so this is kind of where the attack work ended.

142
00:15:38,530 --> 00: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.

143
00:15:52,030 --> 00:15:55,510
So you can use your imagination to think about what things like that can do.

144
00:15:56,430 --> 00: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.

145
00:16:04,690 --> 00:16:09,770
And this work kind of extends work that Dr., that Jeremy Daly and Srikanth Kumar did.

146
00:16:09,770 --> 00:16:15,970
They presented at ESCAR this year about attacking the Windows application that communicates with the VDA.

147
00:16:16,470 --> 00:16:18,050
So I'd recommend checking out that work.

148
00:16:18,050 --> 00: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.

149
00:16:29,150 --> 00: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.

150
00:16:34,490 --> 00:16:36,750
Something interesting just to think about.

151
00:16:40,380 --> 00:16:44,680
Okay, so now we're gonna defend it, we're gonna fix all the problems and go home, yay.

152
00:16:45,640 --> 00: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.

153
00:16:51,200 --> 00:16:57,280
So the immediate problem here is, you might have noticed there's Wi-Fi and Bluetooth on this VDA.

154
00:16:57,600 --> 00:17:02,800
And I think you can imagine that some people might not want that Wi-Fi and Bluetooth enabled.

155
00:17:03,120 --> 00:17:04,820
I wouldn't want it enabled.

156
00:17:05,320 --> 00: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.

157
00:17:14,180 --> 00: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.

158
00:17:30,920 --> 00: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.

159
00:17:38,940 --> 00:17:42,800
But as we all know, the code that underlines it and the hardware is still there.

160
00:17:42,800 --> 00:17:50,520
So an attacker can still modify the firmware or use an exploit to then turn on these features.

161
00:17:50,880 --> 00:17:53,060
So it's a very ripe attack surface.

162
00:17:53,660 --> 00:17:57,660
So we're going to be talking about VDAs, but I encourage you to think about, this is a broader problem.

163
00:17:57,660 --> 00:17:59,860
We have component access features, ABC.

164
00:17:59,860 --> 00:18:01,180
We don't want those features.

165
00:18:01,180 --> 00:18:03,980
We can't remove them because the vendor won't remove them.

166
00:18:03,980 --> 00:18:06,520
So how can we remove them in the binary?

167
00:18:08,800 --> 00: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?

168
00:18:21,020 --> 00:18:23,480
And of course, this is an example of a general problem.

169
00:18:23,480 --> 00: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?

170
00:18:34,000 --> 00:18:37,280
So we use a technique called autotomic binary reduction.

171
00:18:37,280 --> 00:18:39,860
So the name is derived from nature, actually.

172
00:18:39,860 --> 00:18:41,780
It's a nice place to look for inspiration.

173
00:18:42,280 --> 00: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.

174
00:18:50,180 --> 00:18:54,860
So ABR was proposed by our CEO Ong when he was a graduate student at Columbia.

175
00:18:54,860 --> 00:18:56,240
That's where the work comes from.

176
00:18:56,280 --> 00:18:59,500
So if you want to really get into the math behind it, you can look at his dissertation.

177
00:18:59,940 --> 00:19:02,620
But to simplify it, there's really just four steps.

178
00:19:02,680 --> 00: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.

179
00:19:08,500 --> 00: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.

180
00:19:18,080 --> 00:19:22,180
You want to do this very carefully, so if you're not sure, you'll leave something in.

181
00:19:22,360 --> 00: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.

182
00:19:31,320 --> 00:19:37,140
So if you think about a Bluetooth subsystem, there's usually some sort of process that initializes everything.

183
00:19:37,140 --> 00: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.

184
00:19:48,060 --> 00:19:50,460
So this graph, I think, simplifies.

185
00:19:50,460 --> 00:19:53,980
Obviously, it's more complex, but at a high level, this is the idea.

186
00:19:53,980 --> 00:19:57,600
If you have feature A and feature B, we want to remove feature A.

187
00:19:57,760 --> 00:20:03,520
We look at the control flow graph, find all the functions that are exclusively controlful, dependent on feature A.

188
00:20:03,700 --> 00:20:08,820
So function five, we cannot remove, but functions one and two, three, we can.

189
00:20:08,820 --> 00:20:11,320
And then we insert that return patch there.

190
00:20:14,880 --> 00: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.

191
00:20:24,720 --> 00:20:28,780
So we've understood how the firmware works and how we can update the firmware.

192
00:20:28,800 --> 00: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.

193
00:20:43,260 --> 00: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.

194
00:20:47,700 --> 00:20:50,940
So there's minimal human interaction needed into it.

195
00:20:55,070 --> 00:20:58,670
Okay, so identifying the feature entry points, how do you do that?

196
00:20:58,690 --> 00:21:01,930
Well, this is where you have to like, you know, roll up your sleeves and do a little reversing.

197
00:21:02,590 --> 00:21:08,370
So on embedded systems like the VDA, this can be a little complicated, but sometimes you get lucky.

198
00:21:08,370 --> 00: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.

199
00:21:16,110 --> 00:21:18,330
This was using ColdFire.

200
00:21:18,330 --> 00: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.

201
00:21:23,650 --> 00:21:28,350
And then you can kind of start labeling the features inside the binary.

202
00:21:28,350 --> 00:21:30,810
So a new binary comes in, this whole process can be automated.

203
00:21:30,810 --> 00: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.

204
00:21:41,230 --> 00:21:49,030
So for this like proof of concept, we generalized five entry points, the OS tasks that initialize the subsystems.

205
00:21:49,030 --> 00:21:52,910
We also wanted to remove the UR debug commands because we found them super useful.

206
00:21:52,930 --> 00:21:56,950
And yeah, it should be harder to figure out how to dump the memory from the device.

207
00:21:56,950 --> 00:21:57,830
I think, yeah.

208
00:21:58,750 --> 00:22:03,710
Then we also targeted some driver initialization code for these things as well.

209
00:22:04,870 --> 00:22:06,070
And these were the results.

210
00:22:06,070 --> 00:22:09,030
So we use the ABR algorithm that we have ever balloon.

211
00:22:09,030 --> 00:22:17,390
We removed in total 574 functions and ended up being 144 kilobytes of code.

212
00:22:17,390 --> 00:22:19,210
So that was about 7% of the binary.

213
00:22:19,210 --> 00:22:20,890
And you can kind of visualize it here.

214
00:22:20,890 --> 00:22:28,850
Everything that's dark was unmodified and the stripes of green here are the areas where ABR removed the binary code.

215
00:22:29,010 --> 00:22:30,070
So it's kind of cool.

216
00:22:30,070 --> 00: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.

217
00:22:37,270 --> 00:22:45,570
Then we worked with friendly vendor person to test the image using the functional test suite that they used.

218
00:22:45,710 --> 00:22:49,990
And they confirmed that performance was consistent with the original firmware image.

219
00:22:50,010 --> 00:22:50,530
So that was great.

220
00:22:50,530 --> 00: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.

221
00:22:57,470 --> 00:23:00,050
Okay, so we didn't fix all the problems.

222
00:23:00,050 --> 00:23:04,070
So as we're reflecting on this, it's kind of Zen.

223
00:23:04,430 --> 00:23:07,710
We were able to use some of the reversing that attacker would use.

224
00:23:07,710 --> 00:23:11,090
It's the same workflow in the beginning to identify the features and remove it.

225
00:23:12,370 --> 00:23:15,190
So removing the Bluetooth and Wi-Fi code is good.

226
00:23:16,590 --> 00:23:21,350
We would challenge vendors to reconsider whether they even need it.

227
00:23:23,550 --> 00:23:25,730
Yeah, I think that's something we can all think about.

228
00:23:25,730 --> 00:23:27,310
Do we need to put this in?

229
00:23:27,450 --> 00:23:31,410
Can we support firmware builds that don't have it in?

230
00:23:31,970 --> 00:23:38,190
Another thing to think about is ideally you wanna at least not leave the headers on to JTAG and UART.

231
00:23:38,810 --> 00:23:40,530
Ideally disable them as well.

232
00:23:40,530 --> 00:23:44,010
That just makes it a little harder for people to mess with the device.

233
00:23:44,050 --> 00:23:45,970
For production devices, of course.

234
00:23:47,210 --> 00:23:50,670
So then we get to some of the lower level challenges.

235
00:23:50,670 --> 00:23:54,030
How can we make it so anyone can't modify the firmware?

236
00:23:54,110 --> 00:23:58,990
So some sort of secure firmware update mechanism, maybe a secure boot mechanism would be useful here.

237
00:23:59,350 --> 00:24:03,810
And then how do we know that the firmware hasn't been modified?

238
00:24:03,810 --> 00: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?

239
00:24:09,930 --> 00:24:12,850
There's some sort of runtime protection and monitoring could help there.

240
00:24:12,850 --> 00:24:14,850
Because then you could see that the device has been corrupted.

241
00:24:18,360 --> 00:24:23,540
Okay, so we've attacked, we've defended, and now let's talk about some education we did.

242
00:24:23,540 --> 00: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.

243
00:24:38,620 --> 00: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.

244
00:24:50,800 --> 00: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,

245
00:25:06,800 --> 00:25:09,600
and then a bunch of assessments that students do on the devices.

246
00:25:09,700 --> 00:25:11,220
So I encourage you to check it out.

247
00:25:11,220 --> 00:25:14,540
There's also some really good educational resources on the website as well.

248
00:25:14,720 --> 00:25:19,660
So if you're not super familiar with J1939, that's a good place to start.

249
00:25:20,060 --> 00:25:22,880
But anyway, in our workshop, we walked them through this process.

250
00:25:22,880 --> 00:25:26,980
They physically took apart the devices, dumped the firmware.

251
00:25:27,080 --> 00:25:31,760
Getting UART was a really fun moment when you get the shell there.

252
00:25:31,760 --> 00: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.

253
00:25:41,100 --> 00:25:46,580
So connecting the UART, getting screen working, and stuff like that, it was a really good moment for the students.

254
00:25:46,780 --> 00:25:52,680
And then we walked them through the bootstring modification, and a contained environment where they could toggle the LED lights there.

255
00:25:55,040 --> 00:25:56,320
A little more fun, though.

256
00:25:56,320 --> 00: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.

257
00:26:04,080 --> 00:26:05,940
So challenge one was a real-world challenge.

258
00:26:05,940 --> 00:26:13,200
We gave them a PCAP, and we gave them a modified firmware image and said, flash this image on the device.

259
00:26:13,400 --> 00:26:18,440
And so there, the flag printed in the boot shell once you're able to flash the device.

260
00:26:19,440 --> 00:26:21,680
Challenge two was a little too difficult.

261
00:26:21,680 --> 00:26:22,760
It was ambitious.

262
00:26:23,400 --> 00:26:26,140
I think we would remove it if we did it again at CTF.

263
00:26:26,140 --> 00:26:30,980
But there, the challenge was to essentially put the device in Vegas mode.

264
00:26:31,780 --> 00: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.

265
00:26:44,660 --> 00:26:49,620
I think it was just a bunch of XORing data against the XOR repeating key.

266
00:26:50,560 --> 00: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.

267
00:26:57,080 --> 00:27:01,200
And I think they actually emulated the function in this to get the decrypted key there.

268
00:27:01,340 --> 00:27:03,500
And then challenge four was OTA to save the day.

269
00:27:03,500 --> 00: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.

270
00:27:14,120 --> 00:27:16,440
Okay, so just to recap.

271
00:27:20,150 --> 00:27:23,330
Yeah, so that's the binary modified image in Vegas mode.

272
00:27:23,330 --> 00:27:25,630
We talked about what VDAs are.

273
00:27:26,090 --> 00:27:33,390
We showed how it's relatively straightforward to try to modify the firmware on them and attack it.

274
00:27:33,390 --> 00:27:35,550
We can think about what that implies to the industry.

275
00:27:35,830 --> 00: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.

276
00:27:43,470 --> 00:27:44,850
And we talked about how we can use...

277
00:27:44,850 --> 00:27:46,290
I think this is a really good takeaway point.

278
00:27:46,290 --> 00: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.

279
00:27:53,970 --> 00:27:57,110
I think this was the first VDA that was at the Carr-Akenville CTF.

280
00:27:57,970 --> 00:28:01,810
And yeah, I think we just wanna acknowledge Edward and Sam who couldn't be here today.

281
00:28:02,870 --> 00:28:06,470
Jeremy and the friendly vendor person for helping out with this.

282
00:28:09,410 --> 00:28:11,150
So, oh, and lastly...

283
00:28:13,510 --> 00:28:14,450
We're at Red Balloon.

284
00:28:14,450 --> 00:28:16,050
We're hiring now.

285
00:28:16,790 --> 00: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.

286
00:28:22,330 --> 00:28:29,130
And we have two different CTF challenges that we contributed to the Carr-Akenvillage CTF this year as well.

287
00:28:29,130 --> 00:28:31,390
So yeah, thanks for your time.