[00:01.760 --> 00:06.480] Hi there. I hope everyone is joining DEF CON Safe Mode. This should be one of the talks [00:06.480 --> 00:09.420] near the end of the conference. I'm pretty sure it's the last one for the Car Hacking [00:09.420 --> 00:14.520] Village. So I hope everyone's done well and survived this long. We don't certainly have [00:14.520 --> 00:17.920] to worry about some of the main hazards that you would normally have to worry about during [00:18.080 --> 00:23.840] a DEF CON because everyone's remote. The concepts I'm going to present in this were originally [00:23.840 --> 00:29.060] intended to be part of the main Tesla reverse engineering talk that I've done. But when [00:29.060 --> 00:35.080] everything was shortened due to going remote, I decided to actually split these individual [00:35.080 --> 00:40.660] topics off and do them as a separate talk. The things I'm going to cover here don't require [00:40.660 --> 00:47.500] that you actually have listened to the main talk. However, it certainly wouldn't help [00:47.500 --> 00:51.600] if you've actually already seen that or go back and watch it if some of the concepts [00:51.600 --> 00:54.960] are on here. They're all really just going to build on some of the stuff I've already [00:54.960 --> 01:00.240] talked about, but they're also going to cover DVC and ODX and some of the firmware stuff [01:00.240 --> 01:07.360] that would really stand on its own as well. So a little bit about me. My name is Patrick [01:07.360 --> 01:13.900] Kiley. I'm a Principal Security Consultant at Rapid7. I've been with them for quite a [01:13.900 --> 01:20.520] bit of time. I started with them in 2013. I've been working more recently in subjects [01:20.520 --> 01:26.940] such as avionics security. I did some research that I released last year on CAN bus and avionics, [01:26.940 --> 01:32.480] and I've actually done quite a bit of other poking around with avionics systems as an [01:32.480 --> 01:37.420] item that I've focused on. And of course, researching the Tesla, I'm interested in Internet [01:37.420 --> 01:42.520] connected transportation platforms, hardware hacking, IoT, done quite a bit of that, and [01:42.520 --> 01:47.540] of course, autonomous vehicles and CAN bus. Tesla not being one of the autonomous vehicles [01:47.540 --> 01:51.860] I've looked at, just autonomous vehicles in general, it's a subject that I'm interested [01:51.860 --> 02:01.690] in. So topics we're going to cover here. First, we're going to go over the Model S architecture [02:01.690 --> 02:07.710] just briefly again. From there, again, I cover a little bit about the Tesla BMS, and then [02:07.710 --> 02:13.750] we're going to go into CAN bus DVC files and some of the information that we can get from [02:13.750 --> 02:18.330] that if we actually have a DVC file on your reverse engineering vehicle. The screen that [02:18.330 --> 02:28.050] you see here is actually from Kvaser's database editor. That's a free tool that you can use [02:28.050 --> 02:32.010] to basically edit and create your own DVC files. It's very helpful because you don't [02:32.010 --> 02:37.650] actually have to see the signal on the bus to go in and modify it, and you can actually [02:37.650 --> 02:42.170] trim it down. I use this to actually trim down the amount of signals that were present [02:42.170 --> 02:52.490] on a mobile app for a little wireless dongle called a Panda that was connected to the BMS, [02:52.910 --> 02:58.970] 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:07.750] It can't handle that much. However, trimming it down to just the signals I was interested [03:07.750 --> 03:12.810] in is really useful using this tool for that. So I'd encourage anyone who's interested in [03:12.810 --> 03:17.210] messing around with DVC to check this one out because it is free. From there, we're [03:17.210 --> 03:25.050] going to cover UDS and some of the routines that you're able to extract from the Tesla [03:25.050 --> 03:29.410] firmware and from the Tesla toolbox firmware and some of the useful things that you can [03:29.410 --> 03:35.030] actually do with them. I'm going to show security access and shunt calibration, the ones I actually [03:35.030 --> 03:39.670] use for this research because they're the ones I did the most work with, and I've got a couple [03:39.670 --> 03:43.910] of interactive demos for that. And then from there, we're actually going to go into a BMS [03:43.910 --> 03:50.010] firmware. We're going to talk about the things that I learned from trying to reverse the firmware [03:50.010 --> 03:56.190] itself, the nature of the firmware, the type of the way it's stored, and then some information [03:56.190 --> 04:05.010] on the TMS320, which is the primary CPU used in the battery management system. It's also used, [04:05.010 --> 04:13.270] on the Model S and other Tesla models. So just a quick overview, the Tesla Model S, [04:13.270 --> 04:19.410] the main screen that you see to the right of the driver is actually, on the older vehicles, [04:19.410 --> 04:23.890] it's NVIDIA Tegra based, newer ones, it's Intel Atom. And then the instrument cluster [04:23.890 --> 04:30.490] is actually NVIDIA Tegra based as well. And it connects to the CID, the central display, [04:30.490 --> 04:35.310] over an Ethernet connector. That Ethernet connection actually connects to a service [04:35.310 --> 04:39.230] port, but it also connects to the security gateway. The security gateway is basically [04:39.230 --> 04:46.910] like a vehicle firewall. It acts as a filtering mechanism between the various CAN buses and the [04:46.910 --> 04:53.250] CID itself, the Ethernet. And then all the stuff that we're going to see today is actually on a [04:53.250 --> 05:00.310] powertrain CAN bus. A powertrain CAN bus contains the drive units, also charging, thermal control, [05:00.310 --> 05:05.010] and any other powertrain-related controllers all exist on that CAN bus. That CAN bus runs at [05:05.010 --> 05:10.650] 500 kilobits a second. Other than that, it's like any other vehicle CAN bus that you've seen, [05:10.650 --> 05:18.150] 11-bit arbitration IDs, sports UDS. And then the other CAN buses, there are like six or seven, [05:18.490 --> 05:23.810] but the other big ones are chassis and body. Chassis runs at 500 kilobit, body runs at 125. [05:25.170 --> 05:38.250] So the BMS itself, it's the TI-TMS320C2809. That is a DSP microprocessor. It takes all the various [05:38.250 --> 05:44.870] signals coming from voltage from the individual battery packs, from the voltage sense, from the [05:44.870 --> 05:52.850] temperature sensors, and then also talks CAN bus out on the chassis itself. There's a hardware [05:52.850 --> 06:00.270] backup to that. That's the Altera CPLD. In all the research I did, that CPLD wasn't really messed [06:00.270 --> 06:06.790] with at all, except for having a signal bypass, so it wasn't actually sent to the CPLD. But [06:06.790 --> 06:12.090] basically, it's a hardware backup to the TMS320. And for some reason, there's a software fault, [06:12.090 --> 06:19.650] the CPLD will still allow the battery to function while I assume the vehicle shuts down and safely [06:19.650 --> 06:25.710] disconnects the conductors. I've never actually seen the fault condition. I've just talked to [06:25.710 --> 06:30.710] some people and learned that that's really its mission in life, is to act as a hardware backup. [06:31.390 --> 06:36.810] There's also a few other devices. I'm going to just skip to the next slide to talk about those. [06:37.130 --> 06:42.250] There's a current shunt. For those of you who aren't familiar with what a shunt is, a shunt is [06:42.370 --> 06:48.550] a way of measuring current by measuring a voltage drop across a known resistance value. This one [06:48.550 --> 06:53.990] actually measures quite a bit of current. It's a pretty ingenious device, but every device actually [06:53.990 --> 06:59.910] has its own low level of resistance that's calibrated onto the shunt itself. The shunt [06:59.910 --> 07:06.210] runs STM8. There's also a pre-charge resistor. So the way the vehicle actually engages the [07:06.210 --> 07:10.010] contactors, it will engage one side of the contactors. I believe it's negative, please [07:10.010 --> 07:18.310] don't quote me on that. And then it goes through the standard low voltage cabling to slowly bring [07:18.690 --> 07:25.870] the vehicle up slowly, as a matter of milliseconds or microseconds, as opposed to instantaneously. [07:25.870 --> 07:29.950] But basically it brings the rest of the vehicle up to the same voltage as the battery before it [07:29.950 --> 07:34.670] engages the other contactor. And it uses the pre-charge resistor for that. Then the contactors [07:34.670 --> 07:41.290] themselves, in Ludicrous they are actually replaced with higher current models. This is a different [07:41.290 --> 07:45.990] set of contactors that I picked up off the secondary market so I can do my research. I also [07:45.990 --> 07:55.410] have a single BMB board on this. There are 16 of those in the model S85 and each of them has like [07:55.410 --> 08:01.290] six different channels that talk to the six different modules of series batteries on there. [08:01.290 --> 08:06.930] It also contains bleed resistors for a battery balancing, voltage measurement, temperature [08:06.930 --> 08:12.610] measurement, etc. And then the voltage sense wires, the ones you see on the far right, those four [08:12.610 --> 08:16.850] wires actually connect to the four sides of the contactors so they can detect if a contactor is [08:18.230 --> 08:23.690] fused. So it's basically if it welds itself closed, the voltage sense can detect that but it also can [08:23.690 --> 08:31.870] be used to just detect battery voltage overall. So a little bit about CAN-DBC. The CAN-DBC files [08:31.870 --> 08:37.610] I was able to extract from both Toolbox and the vehicle firmware. Here's what it looks like within [08:37.610 --> 08:45.750] Vehicle Spy after it's been imported. And you can actually see DI means Drive Inverter, DIS means [08:45.750 --> 08:52.570] the Front Drive Inverter. So DI is the Rear Drive Inverter, DIS is the Front Drive Inverter. You can [08:52.570 --> 08:59.870] actually see some different values being broadcast onto the CAN bus from this capture. And it's an [08:59.870 --> 09:06.290] interesting way of actually extracting the signals from this. You can actually see everything. I'm not [09:06.290 --> 09:11.670] even quite sure where this image came from, if it was from a running unit or just from a unit [09:11.670 --> 09:19.550] sitting idle, but this one actually shows the two drive inverters so I wanted to share it. This set [09:19.550 --> 09:26.230] of images actually shows the BMS after it was upgraded to Ludicrous. So it has different signals [09:26.230 --> 09:32.930] for current and power. Current is a hard limit. Once the pack has been upgraded to support Ludicrous, [09:32.930 --> 09:40.650] it goes from 1305 to 1516. You can see that in here is the max discharge current of 1516. However, [09:40.650 --> 09:49.090] the drive power max, the value you see down here is 297 kilowatts, is a variable value. It varies [09:49.090 --> 09:55.090] based on the state of charge of the battery, the temperature of the battery, and how much power was [09:55.090 --> 10:00.350] used recently. So the warmer the battery gets up to a point, that drive power max will actually [10:00.350 --> 10:05.990] increase. But then if the car has been stomped on for a little while, it will actually decrease. [10:05.990 --> 10:11.190] There's a whole leaky bucket thing that's mentioned in some of the Tesla engineering [10:11.190 --> 10:18.470] docs that talks about how it'll limit the amount of power if the power has been used recently. So [10:18.470 --> 10:25.250] it's got to wait for it to basically recharge, regenerate, and I assume cool off again before [10:25.250 --> 10:32.910] it brings it back. So one of the things I found that was interesting was that as soon as max [10:32.910 --> 10:37.810] battery power was selected, so for those of you who haven't actually been into a Model S, [10:37.810 --> 10:45.670] there's chill, sport, ludicrous, and then ludicrous plus. And if you don't have ludicrous, [10:45.670 --> 10:51.230] you have insane mode. And what I actually found right away is by monitoring the CAN bus, [10:51.230 --> 10:57.950] is after putting in the setting to enable ludicrous plus, the available power went up [10:57.950 --> 11:02.670] right away. So even though the battery had not heated up anymore from the 22 degrees Celsius [11:02.670 --> 11:10.590] value, instantly more power is available. It went from 439 to 452 kilowatts. [11:11.530 --> 11:17.350] All right, here's a screenshot from a P90DL that someone actually gave me access. Let me [11:17.350 --> 11:22.430] plug into the CAN bus and capture some messages as the battery was heated a little bit. And you [11:22.430 --> 11:28.670] can see that from this, even though the state of charge went down, it went from 93 to 91 percent, [11:28.670 --> 11:33.370] the amount of power went up. 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:48.550] You can also see region change went from 63 to 90. 90 appeared to be a top end static value. [11:50.450 --> 11:58.730] So a little bit about ODX. ODX is an ISO standard for diagnostic communication and ECUs. [11:58.730 --> 12:06.590] The way a lot of other vehicles, not Tesla's, work is you can have ECUs from like several [12:06.590 --> 12:12.850] different manufacturers and they all need to be able to communicate together within a different [12:12.850 --> 12:19.750] vehicle. So you might have some Bosch units or Mitsubishi units or some other different ECUs, [12:19.750 --> 12:23.150] but they all still need to be able to communicate with one another on the CAN bus. [12:23.350 --> 12:29.990] ODX is a standard that kind of aids in that. It's a standard for diagnostic communication so that [12:31.430 --> 12:37.810] a specific message start always means generally the same thing. And this image that you see in [12:37.810 --> 12:44.670] the screenshot is actually the XML file from ODX file that I actually extracted from a toolbox [12:45.390 --> 12:50.650] 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:05.850] Tesla's use a static key and C for security access. Not the best security practice, but it's [13:05.850 --> 13:11.430] the way they decide to implement it. And every single time you actually request security access, [13:11.430 --> 13:21.190] you can see the 2705, that's security access. It says, okay, give me the seed. The seed is 010203 [13:21.190 --> 13:25.790] all the way up through 0F. And the response is always the same thing. So you can actually [13:25.790 --> 13:34.650] configure your CAN bus tool to send the same response every single time. And that's the 353437 [13:34.650 --> 13:40.830] value C is the key. The seed can be whatever it wants, but all the ones that I've tested [13:40.830 --> 13:45.050] 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:07.590] And then you reply with this static key as the response. There's a quick demo of it. [14:13.310 --> 14:18.330] Okay. Here we have a quick demonstration of security access. We have both routines [14:18.330 --> 14:23.810] configured within Vehicle Spy. The first thing we want to do is we want to request the seed. [14:23.810 --> 14:28.510] It's a very quick routine. And then from there, we actually request the key and we can see we [14:28.510 --> 14:34.650] can get a quick positive response. It's a very simple routine. Do it one more time. [14:35.470 --> 14:43.210] Request the seed. You can see the seed 1, 2, 3, 4, 5, 6, 7, 8, 9, A through F. And then, [14:43.210 --> 14:49.430] oh, didn't do it fast enough. One more time. Request the seed. Send the key. We got a positive [14:49.430 --> 14:56.910] response. A positive response shows the static value actually configured within Vehicle Spy. [14:56.970 --> 15:03.570] And just 303332, same things shown in the slides. And it's a very trivial thing to [15:03.570 --> 15:09.510] set up within Vehicle Spy. This is actually connected to a BMS system that's a test bench. [15:15.730 --> 15:19.570] Okay. So thank you for watching that one. 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:31.890] Shunt calibration over UDS was a separate routine. Those require basically you read the data from [15:31.890 --> 15:36.070] 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:48.390] But all you have to do is after you load the special firmware for the BMS is run [15:50.090 --> 15:55.750] routine22id401 and you actually get these values back. Those actually show the current value, [15:55.750 --> 15:58.670] but all you really need is the serial number. The serial number is then looked up [15:59.370 --> 16:04.690] in a Python pickle file for the values that you're going to recalibrate the shunt for. [16:04.690 --> 16:12.670] And you re-change CGI1, CIU1, and the CRC value to the new values. Even though you're reading it, [16:12.670 --> 16:16.950] 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:28.890] So for writing the shunt value, there's actually a write data by nanofire and there's actually [16:28.890 --> 16:34.250] ones for the shunt, but that's not the actual value one. The one that was supposed to be used [16:34.250 --> 16:40.630] to calibrate the shunt was 31 routine control. So for this particular example, if you go back, [16:40.630 --> 16:49.910] you can see that the old values were 41478. I'm actually going to try and change these [16:49.910 --> 16:57.750] and actually write them out separately. So you can see in the routine control, [16:58.550 --> 17:06.850] the value is set here for CGI1, CIU1, 65286. Instead of 65287, you're going to see a different [17:06.850 --> 17:13.130] value written and then see it actually read back in as the newer value. [17:14.510 --> 17:21.650] Okay, so there are several other routines that are actually included in the ODX files. If you [17:21.650 --> 17:26.150] actually look at this, there are ridiculous ones just even for the battery management system. [17:26.150 --> 17:31.010] All sorts of different ones for looking at different calibration data, looking at the [17:31.010 --> 17:37.350] RAM, reading that out, controlling the contactors, very dangerous to do if you're [17:37.350 --> 17:40.810] working on a vehicle that's actually powered on right now, because if you open the contactors [17:40.810 --> 17:48.930] at the wrong time, you can have some current transient issues. However, so just be careful [17:48.930 --> 17:53.930] with any of these, but it just found it interesting to see all the ones that were included in that. [17:53.930 --> 17:58.650] And then just the number of routines that were available in all the other modules were [17:58.650 --> 18:04.330] interesting to read out of the ODX files as well. So, next thing we're going to talk about is the [18:04.330 --> 18:10.770] firmware. So, all the UDS firmware updates, when they are passed on to the vehicle, when the [18:10.770 --> 18:16.530] car updates, they're all in Intel HEX format. They're stored on the firmware itself, at least [18:16.530 --> 18:21.930] on the Tegra under deploy seat artifacts v2, and then the module and the ID. So, they'll include [18:21.930 --> 18:27.350] all the firmware for all the various possibilities for that particular vehicle. [18:28.050 --> 18:35.390] And then what it does is it uses the file version underscore map 2.tsv to help the car identify [18:35.390 --> 18:41.270] the firmware file individually that it needs for the configuration that the car actually has. [18:42.410 --> 18:48.570] So, here's a little overview on how the Intel HEX format works. The first value, it always starts [18:48.570 --> 18:55.910] with a colon, and then the first value C20 is 32 bytes for HEX. And then we have an address [18:55.910 --> 19:03.850] of where that particular piece of firmware goes. And then 00, the next two values of the type of [19:03.850 --> 19:09.010] record, you'll see a 01 for EOF, and you'll see two other values for extended values or anything [19:09.010 --> 19:16.050] like that. And then you actually have data. And then the final value is a checksum. I added these [19:16.050 --> 19:21.930] spaces in for clarity. I tried to directly import the HEX files into IDA, but it has a problem [19:21.930 --> 19:27.590] reading HEX files with values this great. So, what I actually had to do is convert it to a [19:27.590 --> 19:34.630] TI.out format, which has the similar information on the location, but then it actually imported [19:34.630 --> 19:45.970] better. So, this shows the actual data sheet for the TI-TMS320-2809. It actually shows the memory [19:45.970 --> 19:50.870] map. And the really important thing that we need from this memory map, other than knowing where the [19:50.870 --> 19:55.470] different sections of memory are, the sections that are reserved because it is dual mapped, [19:55.470 --> 20:03.030] we're knowing where the code entry point is. So, you can actually see it. 3F7FF6 is actually where [20:03.030 --> 20:09.370] the initial, basically, boot-to-flash entry point. So, that basically tells us where the code entry [20:09.370 --> 20:16.010] point is for IDA. So, from that, we can actually import the data and actually go to this location. [20:16.010 --> 20:23.230] So, 7FF6 on the firmware that I'm looking at here points to 699B, and you can actually see the code [20:23.230 --> 20:29.330] starting. It's still not terribly helpful unless you're really, really good at reading assembly for [20:29.330 --> 20:36.190] the TMS320. However, it is there. It is interesting to actually see it, to see the code jump around, [20:36.190 --> 20:43.130] to see it all broken down into the various subroutines. And the thing that I did find very [20:43.130 --> 20:46.670] useful was actually doing some differential analysis. So, taking the different types of [20:46.670 --> 20:55.810] firmware and doing diffing on it. So, again, the assigned metadata map file tells us where the BMS [20:55.810 --> 21:05.450] firmware is for each config. This example, so, rear drive type one, four-wheel drive one, 4WD1 [21:05.450 --> 21:15.270] is P85D. Rear drive type zero and 4WD1 is an 85D. So, here we're comparing the performance [21:15.270 --> 21:20.750] rear motor to the standard rear motor. And you can see in this firmware, there's not really a [21:20.750 --> 21:27.930] whole lot of differences. If you look, the last line is just the CRC value. There are some single [21:27.930 --> 21:34.610] bit changes at three lines in the file. And then there's this other small little section, the [21:36.750 --> 21:47.050] 935F00 that you see in the actual major change in that. And the single motor version of the [21:47.050 --> 21:51.770] firmware is the same. It was just that single line that's changed. So, what I did is actually [21:51.770 --> 21:56.030] wanted to see if I could find this code in IDA and see where it was mapped to. And I was able [21:56.030 --> 22:04.170] to find it pretty easily. So, you can see within the hex, the 935F007A. This might have something [22:04.170 --> 22:09.290] to do with the power available. I don't know yet. I haven't changed it yet. Like I said, [22:09.290 --> 22:13.250] it's an ongoing project. But my goal is to actually find where the variables are that [22:13.250 --> 22:19.050] control the max power, the max power map, and just see if I can change them a little bit. [22:19.190 --> 22:24.190] See where I can actually take it. Don't think I'll ever actually do anything on a live vehicle [22:24.190 --> 22:27.950] just because it's too dangerous. I just want to see if I can figure this out. It's a challenge [22:27.950 --> 22:35.110] to me. But you can see it's actually mapped into this variable. The 935F actually comes out to 7A [22:36.170 --> 22:42.090] 935F. Right here, IDA was able to disassemble it. You can see where it is in code. The other values, [22:42.090 --> 22:46.890] you can actually find they're right around there. You can see it in a couple of the locations as [22:46.890 --> 22:53.530] well. So, again, like I said, the next step is to modify the firmware on a bench BMS and see where [22:53.530 --> 22:58.690] it takes us. There's also... I want to look for some other interesting changes with the other PAC [22:58.690 --> 23:03.790] ID codes. See if I can actually narrow it down to some variables being located in [23:04.830 --> 23:10.270] other locations. And then I'm also actually taking a really close look at the hardware. [23:10.850 --> 23:15.270] Code Composer Studio is not the most user-friendly program unless you're really used to working with [23:15.270 --> 23:22.850] it. But I do have it working somewhat with a BMS. It does have JTAG exposed and available on it. [23:24.310 --> 23:29.510] That's some other stuff that I'm working on. But obviously somebody has figured it out because [23:29.510 --> 23:34.130] they're selling it as an aftermarket tuner kit for the Model 3, the all-wheel drive Model 3. [23:34.930 --> 23:38.090] Again, I'm just doing this because I want to explore it. I don't want to make money on this. [23:38.090 --> 23:43.290] I just want to figure it out. And thank you for listening to my talk. I think we're going to move [23:43.290 --> 23:44.730] into Q&A next.