WEBVTT 00:01.760 --> 00:02.700 Hi there. 00:02.700 --> 00:05.260 I hope everyone is joining DEF CON Safe Mode. 00:05.260 --> 00:07.580 This should be one of the talks near the end of the conference. 00:07.580 --> 00:10.140 I'm pretty sure it's the last one for the Car Hacking Village. 00:10.500 --> 00:13.520 So I hope everyone's done well and survived this long. 00:13.520 --> 00:20.200 We don't certainly have to worry about some of the main hazards that you would normally have to worry about during a DEF CON because everyone's remote. 00:21.500 --> 00:28.520 The concepts I'm going to present in this were originally intended to be part of the main Tesla reverse engineering talk that I've done. 00:28.560 --> 00:38.220 But when everything was shortened due to going remote, I decided to actually split these individual topics off and do them as a separate talk. 00:38.220 --> 00:43.500 The things I'm going to cover here don't require that you actually have listened to the main talk. 00:43.520 --> 00:52.360 However, it certainly wouldn't help if you've actually already seen that or go back and watch it if some of the concepts are on here. 00:52.360 --> 01:02.880 They're all really just going to build on some of the stuff I've already talked about, but they're also going to cover DVC and ODX and some of the firmware stuff that would really stand on its own as well. 01:04.460 --> 01:06.660 So a little bit about me. 01:06.660 --> 01:07.880 My name is Patrick Kiley. 01:07.880 --> 01:11.020 I'm a Principal Security Consultant at Rapid7. 01:11.200 --> 01:14.200 I've been with them for quite a bit of time. 01:14.200 --> 01:15.800 I started with them in 2013. 01:16.220 --> 01:21.980 I've been working more recently in subjects such as avionics security. 01:21.980 --> 01:34.280 I did some research that I released last year on CAN bus and avionics, and I've actually done quite a bit of other poking around with avionics systems as an item that I've focused on. 01:34.280 --> 01:45.320 And of course, researching the Tesla, I'm interested in Internet connected transportation platforms, hardware hacking, IoT, done quite a bit of that, and of course, autonomous vehicles and CAN bus. 01:45.720 --> 01:52.660 Tesla not being one of the autonomous vehicles I've looked at, just autonomous vehicles in general, it's a subject that I'm interested in. 01:56.870 --> 01:59.250 So topics we're going to cover here. 01:59.470 --> 02:03.590 First, we're going to go over the Model S architecture just briefly again. 02:04.310 --> 02:17.250 From there, again, I cover a little bit about the Tesla BMS, and then we're going to go into CAN bus DVC files and some of the information that we can get from that if we actually have a DVC file on your reverse engineering vehicle. 02:17.370 --> 02:24.630 The screen that you see here is actually from Kvaser's database editor. 02:25.110 --> 02:30.910 That's a free tool that you can use to basically edit and create your own DVC files. 02:30.910 --> 02:38.730 It's very helpful because you don't actually have to see the signal on the bus to go in and modify it, and you can actually trim it down. 02:38.730 --> 02:58.970 I use this to actually trim down the amount of signals that were present on a mobile app for a little wireless dongle called a Panda that was connected to the BMS, the powertrain CAN bus on the Tesla, and then actually just listen to some individual signals. 02:59.110 --> 03:03.470 Trying to put this entire DVC file on there would just basically crash the mobile app. 03:03.470 --> 03:05.250 It can't handle that much. 03:05.250 --> 03:10.850 However, trimming it down to just the signals I was interested in is really useful using this tool for that. 03:10.950 --> 03:15.770 So I'd encourage anyone who's interested in messing around with DVC to check this one out because it is free. 03:16.430 --> 03:30.570 From there, we're going to cover UDS and some of the routines that you're able to extract from the Tesla firmware and from the Tesla toolbox firmware and some of the useful things that you can actually do with them. 03:30.670 --> 03:41.290 I'm going to show security access and shunt calibration, the ones I actually use for this research because they're the ones I did the most work with, and I've got a couple of interactive demos for that. 03:41.630 --> 03:44.610 And then from there, we're actually going to go into a BMS firmware. 03:44.610 --> 04:02.110 We're going to talk about the things that I learned from trying to reverse the firmware itself, the nature of the firmware, the type of the way it's stored, and then some information on the TMS320, which is the primary CPU used in the battery management system. 04:02.110 --> 04:08.590 It's also used, on the Model S and other Tesla models. 04:09.290 --> 04:22.210 So just a quick overview, the Tesla Model S, the main screen that you see to the right of the driver is actually, on the older vehicles, it's NVIDIA Tegra based, newer ones, it's Intel Atom. 04:22.210 --> 04:26.290 And then the instrument cluster is actually NVIDIA Tegra based as well. 04:26.410 --> 04:32.690 And it connects to the CID, the central display, over an Ethernet connector. 04:32.910 --> 04:37.750 That Ethernet connection actually connects to a service port, but it also connects to the security gateway. 04:37.950 --> 04:41.150 The security gateway is basically like a vehicle firewall. 04:41.610 --> 04:48.890 It acts as a filtering mechanism between the various CAN buses and the CID itself, the Ethernet. 04:49.490 --> 04:53.770 And then all the stuff that we're going to see today is actually on a powertrain CAN bus. 04:53.770 --> 05:03.810 A powertrain CAN bus contains the drive units, also charging, thermal control, and any other powertrain-related controllers all exist on that CAN bus. 05:04.150 --> 05:06.630 That CAN bus runs at 500 kilobits a second. 05:07.090 --> 05:14.230 Other than that, it's like any other vehicle CAN bus that you've seen, 11-bit arbitration IDs, sports UDS. 05:14.570 --> 05:21.170 And then the other CAN buses, there are like six or seven, but the other big ones are chassis and body. 05:21.210 --> 05:23.810 Chassis runs at 500 kilobit, body runs at 125. 05:25.170 --> 05:32.510 So the BMS itself, it's the TI-TMS320C2809. 05:32.630 --> 05:36.370 That is a DSP microprocessor. 05:36.390 --> 05:51.970 It takes all the various signals coming from voltage from the individual battery packs, from the voltage sense, from the temperature sensors, and then also talks CAN bus out on the chassis itself. 05:51.970 --> 05:54.110 There's a hardware backup to that. 05:54.210 --> 05:55.930 That's the Altera CPLD. 05:56.350 --> 06:06.710 In all the research I did, that CPLD wasn't really messed with at all, except for having a signal bypass, so it wasn't actually sent to the CPLD. 06:06.710 --> 06:09.910 But basically, it's a hardware backup to the TMS320. 06:09.910 --> 06:21.230 And for some reason, there's a software fault, the CPLD will still allow the battery to function while I assume the vehicle shuts down and safely disconnects the conductors. 06:21.230 --> 06:23.250 I've never actually seen the fault condition. 06:23.890 --> 06:30.710 I've just talked to some people and learned that that's really its mission in life, is to act as a hardware backup. 06:31.390 --> 06:33.750 There's also a few other devices. 06:33.750 --> 06:36.810 I'm going to just skip to the next slide to talk about those. 06:37.130 --> 06:38.770 There's a current shunt. 06:38.830 --> 06:47.370 For those of you who aren't familiar with what a shunt is, a shunt is a way of measuring current by measuring a voltage drop across a known resistance value. 06:47.930 --> 06:50.650 This one actually measures quite a bit of current. 06:50.850 --> 06:59.570 It's a pretty ingenious device, but every device actually has its own low level of resistance that's calibrated onto the shunt itself. 06:59.570 --> 07:01.250 The shunt runs STM8. 07:01.590 --> 07:03.310 There's also a pre-charge resistor. 07:03.310 --> 07:08.830 So the way the vehicle actually engages the contactors, it will engage one side of the contactors. 07:08.830 --> 07:11.410 I believe it's negative, please don't quote me on that. 07:11.470 --> 07:25.870 And then it goes through the standard low voltage cabling to slowly bring the vehicle up slowly, as a matter of milliseconds or microseconds, as opposed to instantaneously. 07:25.870 --> 07:31.210 But basically it brings the rest of the vehicle up to the same voltage as the battery before it engages the other contactor. 07:31.210 --> 07:33.470 And it uses the pre-charge resistor for that. 07:33.650 --> 07:40.090 Then the contactors themselves, in Ludicrous they are actually replaced with higher current models. 07:40.090 --> 07:45.010 This is a different set of contactors that I picked up off the secondary market so I can do my research. 07:45.350 --> 07:49.870 I also have a single BMB board on this. 07:49.870 --> 08:01.290 There are 16 of those in the model S85 and each of them has like six different channels that talk to the six different modules of series batteries on there. 08:01.290 --> 08:08.450 It also contains bleed resistors for a battery balancing, voltage measurement, temperature measurement, etc. 08:08.450 --> 08:18.950 And then the voltage sense wires, the ones you see on the far right, those four wires actually connect to the four sides of the contactors so they can detect if a contactor is fused. 08:18.950 --> 08:26.750 So it's basically if it welds itself closed, the voltage sense can detect that but it also can be used to just detect battery voltage overall. 08:27.870 --> 08:30.290 So a little bit about CAN-DBC. 08:30.510 --> 08:35.330 The CAN-DBC files I was able to extract from both Toolbox and the vehicle firmware. 08:36.270 --> 08:40.070 Here's what it looks like within Vehicle Spy after it's been imported. 08:40.230 --> 08:48.630 And you can actually see DI means Drive Inverter, DIS means the Front Drive Inverter. 08:48.630 --> 08:52.310 So DI is the Rear Drive Inverter, DIS is the Front Drive Inverter. 08:52.310 --> 08:57.630 You can actually see some different values being broadcast onto the CAN bus from this capture. 08:58.390 --> 09:03.390 And it's an interesting way of actually extracting the signals from this. 09:03.390 --> 09:06.110 You can actually see everything. 09:06.110 --> 09:16.810 I'm not even quite sure where this image came from, if it was from a running unit or just from a unit sitting idle, but this one actually shows the two drive inverters so I wanted to share it. 09:17.870 --> 09:23.910 This set of images actually shows the BMS after it was upgraded to Ludicrous. 09:23.910 --> 09:27.690 So it has different signals for current and power. 09:28.030 --> 09:30.030 Current is a hard limit. 09:30.090 --> 09:35.550 Once the pack has been upgraded to support Ludicrous, it goes from 1305 to 1516. 09:36.010 --> 09:39.590 You can see that in here is the max discharge current of 1516. 09:39.590 --> 09:47.010 However, the drive power max, the value you see down here is 297 kilowatts, is a variable value. 09:47.790 --> 09:55.770 It varies based on the state of charge of the battery, the temperature of the battery, and how much power was used recently. 09:55.770 --> 10:01.350 So the warmer the battery gets up to a point, that drive power max will actually increase. 10:01.690 --> 10:05.990 But then if the car has been stomped on for a little while, it will actually decrease. 10:05.990 --> 10:18.410 There's a whole leaky bucket thing that's mentioned in some of the Tesla engineering docs that talks about how it'll limit the amount of power if the power has been used recently. 10:18.410 --> 10:26.650 So it's got to wait for it to basically recharge, regenerate, and I assume cool off again before it brings it back. 10:27.810 --> 10:44.630 So one of the things I found that was interesting was that as soon as max battery power was selected, so for those of you who haven't actually been into a Model S, there's chill, sport, ludicrous, and then ludicrous plus. 10:44.630 --> 10:47.170 And if you don't have ludicrous, you have insane mode. 10:47.250 --> 10:58.490 And what I actually found right away is by monitoring the CAN bus, is after putting in the setting to enable ludicrous plus, the available power went up right away. 10:58.490 --> 11:06.010 So even though the battery had not heated up anymore from the 22 degrees Celsius value, instantly more power is available. 11:06.010 --> 11:10.590 It went from 439 to 452 kilowatts. 11:11.530 --> 11:17.090 All right, here's a screenshot from a P90DL that someone actually gave me access. 11:17.090 --> 11:22.210 Let me plug into the CAN bus and capture some messages as the battery was heated a little bit. 11:22.250 --> 11:30.110 And you can see that from this, even though the state of charge went down, it went from 93 to 91 percent, the amount of power went up. 11:30.110 --> 11:33.370 So it really seemed like pack temperature is the most dependent value. 11:33.370 --> 11:41.470 So it went from 22 to 31 and went from 454 kilowatts of power available to 480 kilowatts. 11:41.470 --> 11:44.530 You can also see region change went from 63 to 90. 11:44.530 --> 11:48.550 90 appeared to be a top end static value. 11:50.450 --> 11:53.450 So a little bit about ODX. 11:53.450 --> 11:58.730 ODX is an ISO standard for diagnostic communication and ECUs. 11:58.730 --> 12:13.250 The way a lot of other vehicles, not Tesla's, work is you can have ECUs from like several different manufacturers and they all need to be able to communicate together within a different vehicle. 12:13.250 --> 12:23.150 So you might have some Bosch units or Mitsubishi units or some other different ECUs, but they all still need to be able to communicate with one another on the CAN bus. 12:23.350 --> 12:26.030 ODX is a standard that kind of aids in that. 12:26.030 --> 12:36.390 It's a standard for diagnostic communication so that a specific message start always means generally the same thing. 12:36.390 --> 12:50.650 And this image that you see in the screenshot is actually the XML file from ODX file that I actually extracted from a toolbox from the main talk if you follow my values that we got from there. 12:51.290 --> 12:59.070 So here is one of the most interesting ODX routines if you're going to start hacking on Tesla. 12:59.070 --> 13:03.450 Tesla's use a static key and C for security access. 13:03.750 --> 13:08.050 Not the best security practice, but it's the way they decide to implement it. 13:08.390 --> 13:15.270 And every single time you actually request security access, you can see the 2705, that's security access. 13:16.950 --> 13:19.330 It says, okay, give me the seed. 13:19.330 --> 13:22.810 The seed is 010203 all the way up through 0F. 13:23.070 --> 13:25.250 And the response is always the same thing. 13:25.250 --> 13:32.530 So you can actually configure your CAN bus tool to send the same response every single time. 13:32.670 --> 13:37.190 And that's the 353437 value C is the key. 13:37.410 --> 13:45.050 The seed can be whatever it wants, but all the ones that I've tested and all the modules that I've tested on this one, they all require the same key. 13:46.610 --> 13:52.010 And here I have a little demo actually showing how I set this up in Vehicle Spy. 13:52.010 --> 13:58.450 So you just send routine 27 level 5, level 5 security being the security access level. 13:58.530 --> 14:04.770 And then you reply with this static key as the response. 14:05.310 --> 14:07.590 There's a quick demo of it. 14:13.310 --> 14:13.670 Okay. 14:13.670 --> 14:17.110 Here we have a quick demonstration of security access. 14:17.110 --> 14:20.630 We have both routines configured within Vehicle Spy. 14:20.630 --> 14:23.810 The first thing we want to do is we want to request the seed. 14:23.810 --> 14:25.510 It's a very quick routine. 14:25.610 --> 14:30.570 And then from there, we actually request the key and we can see we can get a quick positive response. 14:30.590 --> 14:32.550 It's a very simple routine. 14:32.910 --> 14:34.650 Do it one more time. 14:35.470 --> 14:36.730 Request the seed. 14:36.730 --> 14:41.870 You can see the seed 1, 2, 3, 4, 5, 6, 7, 8, 9, A through F. 14:42.350 --> 14:44.490 And then, oh, didn't do it fast enough. 14:44.490 --> 14:45.550 One more time. 14:45.850 --> 14:47.130 Request the seed. 14:47.510 --> 14:48.570 Send the key. 14:48.750 --> 14:50.330 We got a positive response. 14:50.990 --> 14:56.910 A positive response shows the static value actually configured within Vehicle Spy. 14:56.970 --> 15:01.390 And just 303332, same things shown in the slides. 15:01.670 --> 15:04.990 And it's a very trivial thing to set up within Vehicle Spy. 15:04.990 --> 15:09.510 This is actually connected to a BMS system that's a test bench. 15:15.730 --> 15:16.110 Okay. 15:16.110 --> 15:18.270 So thank you for watching that one. 15:18.270 --> 15:19.570 I hope you enjoyed it. 15:19.690 --> 15:23.630 So the next one I'm going to kind of talk about is the shunt calibration. 15:23.630 --> 15:27.630 Shunt calibration over UDS was a separate routine. 15:28.570 --> 15:36.070 Those require basically you read the data from the shunt and you actually have to load special firmware onto the BMS to do this. 15:36.710 --> 15:41.250 The shunt calibration was a critical part of that, the ludicrous upgrade for the PD5D. 15:41.710 --> 15:52.570 But all you have to do is after you load the special firmware for the BMS is run routine22id401 and you actually get these values back. 15:53.350 --> 15:57.230 Those actually show the current value, but all you really need is the serial number. 15:57.230 --> 16:04.690 The serial number is then looked up in a Python pickle file for the values that you're going to recalibrate the shunt for. 16:04.690 --> 16:11.490 And you re-change CGI1, CIU1, and the CRC value to the new values. 16:11.490 --> 16:16.950 Even though you're reading it, the way it actually shows the write success, this is just a read screenshot. 16:18.450 --> 16:22.350 But once you actually get that back, there's a separate routine to write it. 16:22.350 --> 16:31.390 So for writing the shunt value, there's actually a write data by nanofire and there's actually ones for the shunt, but that's not the actual value one. 16:31.390 --> 16:37.450 The one that was supposed to be used to calibrate the shunt was 31 routine control. 16:37.570 --> 16:45.890 So for this particular example, if you go back, you can see that the old values were 41478. 16:47.030 --> 16:54.750 I'm actually going to try and change these and actually write them out separately. 16:55.010 --> 17:03.850 So you can see in the routine control, the value is set here for CGI1, CIU1, 65286. 17:04.190 --> 17:13.130 Instead of 65287, you're going to see a different value written and then see it actually read back in as the newer value. 17:14.510 --> 17:20.950 Okay, so there are several other routines that are actually included in the ODX files. 17:20.950 --> 17:26.150 If you actually look at this, there are ridiculous ones just even for the battery management system. 17:26.150 --> 17:42.270 All sorts of different ones for looking at different calibration data, looking at the RAM, reading that out, controlling the contactors, very dangerous to do if you're working on a vehicle that's actually powered on right now, because if you open the contactors at the wrong time, 17:42.270 --> 17:46.110 you can have some current transient issues. 17:46.570 --> 17:53.930 However, so just be careful with any of these, but it just found it interesting to see all the ones that were included in that. 17:53.930 --> 18:01.190 And then just the number of routines that were available in all the other modules were interesting to read out of the ODX files as well. 18:02.110 --> 18:05.070 So, next thing we're going to talk about is the firmware. 18:05.210 --> 18:13.890 So, all the UDS firmware updates, when they are passed on to the vehicle, when the car updates, they're all in Intel HEX format. 18:14.190 --> 18:21.190 They're stored on the firmware itself, at least on the Tegra under deploy seat artifacts v2, and then the module and the ID. 18:21.190 --> 18:27.350 So, they'll include all the firmware for all the various possibilities for that particular vehicle. 18:28.050 --> 18:41.270 And then what it does is it uses the file version underscore map 2.tsv to help the car identify the firmware file individually that it needs for the configuration that the car actually has. 18:42.410 --> 18:46.870 So, here's a little overview on how the Intel HEX format works. 18:46.870 --> 18:54.450 The first value, it always starts with a colon, and then the first value C20 is 32 bytes for HEX. 18:54.450 --> 19:01.150 And then we have an address of where that particular piece of firmware goes. 19:01.610 --> 19:10.050 And then 00, the next two values of the type of record, you'll see a 01 for EOF, and you'll see two other values for extended values or anything like that. 19:10.690 --> 19:12.470 And then you actually have data. 19:12.470 --> 19:15.190 And then the final value is a checksum. 19:15.370 --> 19:17.610 I added these spaces in for clarity. 19:17.770 --> 19:25.010 I tried to directly import the HEX files into IDA, but it has a problem reading HEX files with values this great. 19:25.010 --> 19:35.190 So, what I actually had to do is convert it to a TI .out format, which has the similar information on the location, but then it actually imported better . 19:35.710 --> 19:44.170 So, this shows the actual data sheet for the TI-TMS320-2809. 19:44.170 --> 19:46.450 It actually shows the memory map . 19:46.450 --> 19:58.710 And the really important thing that we need from this memory map, other than knowing where the different sections of memory are, the sections that are reserved because it is dual mapped, we're knowing where the code entry point is. 19:58.830 --> 20:00.210 So, you can actually see it. 20:01.630 --> 20:07.630 3F7FF6 is actually where the initial, basically, boot-to-flash entry point. 20:07.630 --> 20:10.930 So, that basically tells us where the code entry point is for IDA. 20:11.650 --> 20:16.010 So, from that, we can actually import the data and actually go to this location. 20:16.010 --> 20:24.030 So, 7FF6 on the firmware that I'm looking at here points to 699B, and you can actually see the code starting. 20:25.210 --> 20:30.490 It's still not terribly helpful unless you're really, really good at reading assembly for the TMS320. 20:30.490 --> 20:32.530 However, it is there. 20:32.530 --> 20:39.230 It is interesting to actually see it, to see the code jump around, to see it all broken down into the various subroutines. 20:41.730 --> 20:45.350 And the thing that I did find very useful was actually doing some differential analysis. 20:45.350 --> 20:50.690 So, taking the different types of firmware and doing diffing on it. 20:51.090 --> 20:59.530 So, again, the assigned metadata map file tells us where the BMS firmware is for each config. 20:59.810 --> 21:06.870 This example, so, rear drive type one, four-wheel drive one, 4WD1 is P85D. 21:07.530 --> 21:11.350 Rear drive type zero and 4WD1 is an 85D. 21:11.370 --> 21:18.090 So, here we're comparing the performance rear motor to the standard rear motor. 21:18.090 --> 21:21.910 And you can see in this firmware, there's not really a whole lot of differences. 21:22.110 --> 21:26.590 If you look, the last line is just the CRC value. 21:26.790 --> 21:31.590 There are some single bit changes at three lines in the file. 21:31.590 --> 21:43.730 And then there's this other small little section, the 935F00 that you see in the actual major change in that. 21:43.730 --> 21:47.690 And the single motor version of the firmware is the same. 21:47.690 --> 21:49.910 It was just that single line that's changed. 21:50.070 --> 21:55.630 So, what I did is actually wanted to see if I could find this code in IDA and see where it was mapped to. 21:55.630 --> 21:57.350 And I was able to find it pretty easily. 21:57.390 --> 22:02.330 So, you can see within the hex, the 935F007A. 22:02.990 --> 22:06.490 This might have something to do with the power available. 22:06.490 --> 22:07.190 I don't know yet. 22:07.190 --> 22:08.250 I haven't changed it yet. 22:08.630 --> 22:10.450 Like I said, it's an ongoing project. 22:10.630 --> 22:19.050 But my goal is to actually find where the variables are that control the max power, the max power map, and just see if I can change them a little bit. 22:19.190 --> 22:21.150 See where I can actually take it. 22:21.610 --> 22:25.350 Don't think I'll ever actually do anything on a live vehicle just because it's too dangerous. 22:25.350 --> 22:27.130 I just want to see if I can figure this out. 22:27.190 --> 22:28.690 It's a challenge to me. 22:28.990 --> 22:32.190 But you can see it's actually mapped into this variable. 22:32.530 --> 22:36.890 The 935F actually comes out to 7A 935F. 22:37.870 --> 22:40.290 Right here, IDA was able to disassemble it. 22:40.330 --> 22:41.370 You can see where it is in code. 22:41.370 --> 22:44.450 The other values, you can actually find they're right around there. 22:44.610 --> 22:47.450 You can see it in a couple of the locations as well. 22:48.610 --> 22:54.710 So, again, like I said, the next step is to modify the firmware on a bench BMS and see where it takes us. 22:55.370 --> 22:59.630 There's also... I want to look for some other interesting changes with the other PAC ID codes. 23:00.010 --> 23:06.270 See if I can actually narrow it down to some variables being located in other locations. 23:06.750 --> 23:10.270 And then I'm also actually taking a really close look at the hardware. 23:10.850 --> 23:15.950 Code Composer Studio is not the most user-friendly program unless you're really used to working with it. 23:16.170 --> 23:18.930 But I do have it working somewhat with a BMS. 23:18.930 --> 23:22.850 It does have JTAG exposed and available on it. 23:24.310 --> 23:26.570 That's some other stuff that I'm working on. 23:27.090 --> 23:34.130 But obviously somebody has figured it out because they're selling it as an aftermarket tuner kit for the Model 3, the all-wheel drive Model 3. 23:34.930 --> 23:37.010 Again, I'm just doing this because I want to explore it. 23:37.010 --> 23:38.090 I don't want to make money on this. 23:38.090 --> 23:39.450 I just want to figure it out. 23:40.850 --> 23:42.610 And thank you for listening to my talk. 23:42.610 --> 23:44.730 I think we're going to move into Q&A next.