start	end	text
1760	6480	Hi there. I hope everyone is joining DEF CON Safe Mode. This should be one of the talks
6480	9420	near the end of the conference. I'm pretty sure it's the last one for the Car Hacking
9420	14520	Village. So I hope everyone's done well and survived this long. We don't certainly have
14520	17920	to worry about some of the main hazards that you would normally have to worry about during
18080	23840	a DEF CON because everyone's remote. The concepts I'm going to present in this were originally
23840	29060	intended to be part of the main Tesla reverse engineering talk that I've done. But when
29060	35080	everything was shortened due to going remote, I decided to actually split these individual
35080	40660	topics off and do them as a separate talk. The things I'm going to cover here don't require
40660	47500	that you actually have listened to the main talk. However, it certainly wouldn't help
47500	51600	if you've actually already seen that or go back and watch it if some of the concepts
51600	54960	are on here. They're all really just going to build on some of the stuff I've already
54960	60240	talked about, but they're also going to cover DVC and ODX and some of the firmware stuff
60240	67360	that would really stand on its own as well. So a little bit about me. My name is Patrick
67360	73900	Kiley. I'm a Principal Security Consultant at Rapid7. I've been with them for quite a
73900	80520	bit of time. I started with them in 2013. I've been working more recently in subjects
80520	86940	such as avionics security. I did some research that I released last year on CAN bus and avionics,
86940	92480	and I've actually done quite a bit of other poking around with avionics systems as an
92480	97420	item that I've focused on. And of course, researching the Tesla, I'm interested in Internet
97420	102520	connected transportation platforms, hardware hacking, IoT, done quite a bit of that, and
102520	107540	of course, autonomous vehicles and CAN bus. Tesla not being one of the autonomous vehicles
107540	111860	I've looked at, just autonomous vehicles in general, it's a subject that I'm interested
111860	121690	in. So topics we're going to cover here. First, we're going to go over the Model S architecture
121690	127710	just briefly again. From there, again, I cover a little bit about the Tesla BMS, and then
127710	133750	we're going to go into CAN bus DVC files and some of the information that we can get from
133750	138330	that if we actually have a DVC file on your reverse engineering vehicle. The screen that
138330	148050	you see here is actually from Kvaser's database editor. That's a free tool that you can use
148050	152010	to basically edit and create your own DVC files. It's very helpful because you don't
152010	157650	actually have to see the signal on the bus to go in and modify it, and you can actually
157650	162170	trim it down. I use this to actually trim down the amount of signals that were present
162170	172490	on a mobile app for a little wireless dongle called a Panda that was connected to the BMS,
172910	178970	the powertrain CAN bus on the Tesla, and then actually just listen to some individual signals.
179110	183470	Trying to put this entire DVC file on there would just basically crash the mobile app.
183470	187750	It can't handle that much. However, trimming it down to just the signals I was interested
187750	192810	in is really useful using this tool for that. So I'd encourage anyone who's interested in
192810	197210	messing around with DVC to check this one out because it is free. From there, we're
197210	205050	going to cover UDS and some of the routines that you're able to extract from the Tesla
205050	209410	firmware and from the Tesla toolbox firmware and some of the useful things that you can
209410	215030	actually do with them. I'm going to show security access and shunt calibration, the ones I actually
215030	219670	use for this research because they're the ones I did the most work with, and I've got a couple
219670	223910	of interactive demos for that. And then from there, we're actually going to go into a BMS
223910	230010	firmware. We're going to talk about the things that I learned from trying to reverse the firmware
230010	236190	itself, the nature of the firmware, the type of the way it's stored, and then some information
236190	245010	on the TMS320, which is the primary CPU used in the battery management system. It's also used,
245010	253270	on the Model S and other Tesla models. So just a quick overview, the Tesla Model S,
253270	259410	the main screen that you see to the right of the driver is actually, on the older vehicles,
259410	263890	it's NVIDIA Tegra based, newer ones, it's Intel Atom. And then the instrument cluster
263890	270490	is actually NVIDIA Tegra based as well. And it connects to the CID, the central display,
270490	275310	over an Ethernet connector. That Ethernet connection actually connects to a service
275310	279230	port, but it also connects to the security gateway. The security gateway is basically
279230	286910	like a vehicle firewall. It acts as a filtering mechanism between the various CAN buses and the
286910	293250	CID itself, the Ethernet. And then all the stuff that we're going to see today is actually on a
293250	300310	powertrain CAN bus. A powertrain CAN bus contains the drive units, also charging, thermal control,
300310	305010	and any other powertrain-related controllers all exist on that CAN bus. That CAN bus runs at
305010	310650	500 kilobits a second. Other than that, it's like any other vehicle CAN bus that you've seen,
310650	318150	11-bit arbitration IDs, sports UDS. And then the other CAN buses, there are like six or seven,
318490	323810	but the other big ones are chassis and body. Chassis runs at 500 kilobit, body runs at 125.
325170	338250	So the BMS itself, it's the TI-TMS320C2809. That is a DSP microprocessor. It takes all the various
338250	344870	signals coming from voltage from the individual battery packs, from the voltage sense, from the
344870	352850	temperature sensors, and then also talks CAN bus out on the chassis itself. There's a hardware
352850	360270	backup to that. That's the Altera CPLD. In all the research I did, that CPLD wasn't really messed
360270	366790	with at all, except for having a signal bypass, so it wasn't actually sent to the CPLD. But
366790	372090	basically, it's a hardware backup to the TMS320. And for some reason, there's a software fault,
372090	379650	the CPLD will still allow the battery to function while I assume the vehicle shuts down and safely
379650	385710	disconnects the conductors. I've never actually seen the fault condition. I've just talked to
385710	390710	some people and learned that that's really its mission in life, is to act as a hardware backup.
391390	396810	There's also a few other devices. I'm going to just skip to the next slide to talk about those.
397130	402250	There's a current shunt. For those of you who aren't familiar with what a shunt is, a shunt is
402370	408550	a way of measuring current by measuring a voltage drop across a known resistance value. This one
408550	413990	actually measures quite a bit of current. It's a pretty ingenious device, but every device actually
413990	419910	has its own low level of resistance that's calibrated onto the shunt itself. The shunt
419910	426210	runs STM8. There's also a pre-charge resistor. So the way the vehicle actually engages the
426210	430010	contactors, it will engage one side of the contactors. I believe it's negative, please
430010	438310	don't quote me on that. And then it goes through the standard low voltage cabling to slowly bring
438690	445870	the vehicle up slowly, as a matter of milliseconds or microseconds, as opposed to instantaneously.
445870	449950	But basically it brings the rest of the vehicle up to the same voltage as the battery before it
449950	454670	engages the other contactor. And it uses the pre-charge resistor for that. Then the contactors
454670	461290	themselves, in Ludicrous they are actually replaced with higher current models. This is a different
461290	465990	set of contactors that I picked up off the secondary market so I can do my research. I also
465990	475410	have a single BMB board on this. There are 16 of those in the model S85 and each of them has like
475410	481290	six different channels that talk to the six different modules of series batteries on there.
481290	486930	It also contains bleed resistors for a battery balancing, voltage measurement, temperature
486930	492610	measurement, etc. And then the voltage sense wires, the ones you see on the far right, those four
492610	496850	wires actually connect to the four sides of the contactors so they can detect if a contactor is
498230	503690	fused. So it's basically if it welds itself closed, the voltage sense can detect that but it also can
503690	511870	be used to just detect battery voltage overall. So a little bit about CAN-DBC. The CAN-DBC files
511870	517610	I was able to extract from both Toolbox and the vehicle firmware. Here's what it looks like within
517610	525750	Vehicle Spy after it's been imported. And you can actually see DI means Drive Inverter, DIS means
525750	532570	the Front Drive Inverter. So DI is the Rear Drive Inverter, DIS is the Front Drive Inverter. You can
532570	539870	actually see some different values being broadcast onto the CAN bus from this capture. And it's an
539870	546290	interesting way of actually extracting the signals from this. You can actually see everything. I'm not
546290	551670	even quite sure where this image came from, if it was from a running unit or just from a unit
551670	559550	sitting idle, but this one actually shows the two drive inverters so I wanted to share it. This set
559550	566230	of images actually shows the BMS after it was upgraded to Ludicrous. So it has different signals
566230	572930	for current and power. Current is a hard limit. Once the pack has been upgraded to support Ludicrous,
572930	580650	it goes from 1305 to 1516. You can see that in here is the max discharge current of 1516. However,
580650	589090	the drive power max, the value you see down here is 297 kilowatts, is a variable value. It varies
589090	595090	based on the state of charge of the battery, the temperature of the battery, and how much power was
595090	600350	used recently. So the warmer the battery gets up to a point, that drive power max will actually
600350	605990	increase. But then if the car has been stomped on for a little while, it will actually decrease.
605990	611190	There's a whole leaky bucket thing that's mentioned in some of the Tesla engineering
611190	618470	docs that talks about how it'll limit the amount of power if the power has been used recently. So
618470	625250	it's got to wait for it to basically recharge, regenerate, and I assume cool off again before
625250	632910	it brings it back. So one of the things I found that was interesting was that as soon as max
632910	637810	battery power was selected, so for those of you who haven't actually been into a Model S,
637810	645670	there's chill, sport, ludicrous, and then ludicrous plus. And if you don't have ludicrous,
645670	651230	you have insane mode. And what I actually found right away is by monitoring the CAN bus,
651230	657950	is after putting in the setting to enable ludicrous plus, the available power went up
657950	662670	right away. So even though the battery had not heated up anymore from the 22 degrees Celsius
662670	670590	value, instantly more power is available. It went from 439 to 452 kilowatts.
671530	677350	All right, here's a screenshot from a P90DL that someone actually gave me access. Let me
677350	682430	plug into the CAN bus and capture some messages as the battery was heated a little bit. And you
682430	688670	can see that from this, even though the state of charge went down, it went from 93 to 91 percent,
688670	693370	the amount of power went up. So it really seemed like pack temperature is the most dependent value.
693370	701470	So it went from 22 to 31 and went from 454 kilowatts of power available to 480 kilowatts.
701470	708550	You can also see region change went from 63 to 90. 90 appeared to be a top end static value.
710450	718730	So a little bit about ODX. ODX is an ISO standard for diagnostic communication and ECUs.
718730	726590	The way a lot of other vehicles, not Tesla's, work is you can have ECUs from like several
726590	732850	different manufacturers and they all need to be able to communicate together within a different
732850	739750	vehicle. So you might have some Bosch units or Mitsubishi units or some other different ECUs,
739750	743150	but they all still need to be able to communicate with one another on the CAN bus.
743350	749990	ODX is a standard that kind of aids in that. It's a standard for diagnostic communication so that
751430	757810	a specific message start always means generally the same thing. And this image that you see in
757810	764670	the screenshot is actually the XML file from ODX file that I actually extracted from a toolbox
765390	770650	from the main talk if you follow my values that we got from there.
771290	779070	So here is one of the most interesting ODX routines if you're going to start hacking on Tesla.
779070	785850	Tesla's use a static key and C for security access. Not the best security practice, but it's
785850	791430	the way they decide to implement it. And every single time you actually request security access,
791430	801190	you can see the 2705, that's security access. It says, okay, give me the seed. The seed is 010203
801190	805790	all the way up through 0F. And the response is always the same thing. So you can actually
805790	814650	configure your CAN bus tool to send the same response every single time. And that's the 353437
814650	820830	value C is the key. The seed can be whatever it wants, but all the ones that I've tested
820830	825050	and all the modules that I've tested on this one, they all require the same key.
826610	832010	And here I have a little demo actually showing how I set this up in Vehicle Spy.
832010	838450	So you just send routine 27 level 5, level 5 security being the security access level.
838530	847590	And then you reply with this static key as the response. There's a quick demo of it.
853310	858330	Okay. Here we have a quick demonstration of security access. We have both routines
858330	863810	configured within Vehicle Spy. The first thing we want to do is we want to request the seed.
863810	868510	It's a very quick routine. And then from there, we actually request the key and we can see we
868510	874650	can get a quick positive response. It's a very simple routine. Do it one more time.
875470	883210	Request the seed. You can see the seed 1, 2, 3, 4, 5, 6, 7, 8, 9, A through F. And then,
883210	889430	oh, didn't do it fast enough. One more time. Request the seed. Send the key. We got a positive
889430	896910	response. A positive response shows the static value actually configured within Vehicle Spy.
896970	903570	And just 303332, same things shown in the slides. And it's a very trivial thing to
903570	909510	set up within Vehicle Spy. This is actually connected to a BMS system that's a test bench.
915730	919570	Okay. So thank you for watching that one. I hope you enjoyed it.
919690	923630	So the next one I'm going to kind of talk about is the shunt calibration.
923630	931890	Shunt calibration over UDS was a separate routine. Those require basically you read the data from
931890	936070	the shunt and you actually have to load special firmware onto the BMS to do this.
936710	941250	The shunt calibration was a critical part of that, the ludicrous upgrade for the PD5D.
941710	948390	But all you have to do is after you load the special firmware for the BMS is run
950090	955750	routine22id401 and you actually get these values back. Those actually show the current value,
955750	958670	but all you really need is the serial number. The serial number is then looked up
959370	964690	in a Python pickle file for the values that you're going to recalibrate the shunt for.
964690	972670	And you re-change CGI1, CIU1, and the CRC value to the new values. Even though you're reading it,
972670	976950	the way it actually shows the write success, this is just a read screenshot.
978450	982350	But once you actually get that back, there's a separate routine to write it.
982350	988890	So for writing the shunt value, there's actually a write data by nanofire and there's actually
988890	994250	ones for the shunt, but that's not the actual value one. The one that was supposed to be used
994250	1000630	to calibrate the shunt was 31 routine control. So for this particular example, if you go back,
1000630	1009910	you can see that the old values were 41478. I'm actually going to try and change these
1009910	1017750	and actually write them out separately. So you can see in the routine control,
1018550	1026850	the value is set here for CGI1, CIU1, 65286. Instead of 65287, you're going to see a different
1026850	1033130	value written and then see it actually read back in as the newer value.
1034510	1041650	Okay, so there are several other routines that are actually included in the ODX files. If you
1041650	1046150	actually look at this, there are ridiculous ones just even for the battery management system.
1046150	1051010	All sorts of different ones for looking at different calibration data, looking at the
1051010	1057350	RAM, reading that out, controlling the contactors, very dangerous to do if you're
1057350	1060810	working on a vehicle that's actually powered on right now, because if you open the contactors
1060810	1068930	at the wrong time, you can have some current transient issues. However, so just be careful
1068930	1073930	with any of these, but it just found it interesting to see all the ones that were included in that.
1073930	1078650	And then just the number of routines that were available in all the other modules were
1078650	1084330	interesting to read out of the ODX files as well. So, next thing we're going to talk about is the
1084330	1090770	firmware. So, all the UDS firmware updates, when they are passed on to the vehicle, when the
1090770	1096530	car updates, they're all in Intel HEX format. They're stored on the firmware itself, at least
1096530	1101930	on the Tegra under deploy seat artifacts v2, and then the module and the ID. So, they'll include
1101930	1107350	all the firmware for all the various possibilities for that particular vehicle.
1108050	1115390	And then what it does is it uses the file version underscore map 2.tsv to help the car identify
1115390	1121270	the firmware file individually that it needs for the configuration that the car actually has.
1122410	1128570	So, here's a little overview on how the Intel HEX format works. The first value, it always starts
1128570	1135910	with a colon, and then the first value C20 is 32 bytes for HEX. And then we have an address
1135910	1143850	of where that particular piece of firmware goes. And then 00, the next two values of the type of
1143850	1149010	record, you'll see a 01 for EOF, and you'll see two other values for extended values or anything
1149010	1156050	like that. And then you actually have data. And then the final value is a checksum. I added these
1156050	1161930	spaces in for clarity. I tried to directly import the HEX files into IDA, but it has a problem
1161930	1167590	reading HEX files with values this great. So, what I actually had to do is convert it to a
1167590	1174630	TI.out format, which has the similar information on the location, but then it actually imported
1174630	1185970	better. So, this shows the actual data sheet for the TI-TMS320-2809. It actually shows the memory
1185970	1190870	map. And the really important thing that we need from this memory map, other than knowing where the
1190870	1195470	different sections of memory are, the sections that are reserved because it is dual mapped,
1195470	1203030	we're knowing where the code entry point is. So, you can actually see it. 3F7FF6 is actually where
1203030	1209370	the initial, basically, boot-to-flash entry point. So, that basically tells us where the code entry
1209370	1216010	point is for IDA. So, from that, we can actually import the data and actually go to this location.
1216010	1223230	So, 7FF6 on the firmware that I'm looking at here points to 699B, and you can actually see the code
1223230	1229330	starting. It's still not terribly helpful unless you're really, really good at reading assembly for
1229330	1236190	the TMS320. However, it is there. It is interesting to actually see it, to see the code jump around,
1236190	1243130	to see it all broken down into the various subroutines. And the thing that I did find very
1243130	1246670	useful was actually doing some differential analysis. So, taking the different types of
1246670	1255810	firmware and doing diffing on it. So, again, the assigned metadata map file tells us where the BMS
1255810	1265450	firmware is for each config. This example, so, rear drive type one, four-wheel drive one, 4WD1
1265450	1275270	is P85D. Rear drive type zero and 4WD1 is an 85D. So, here we're comparing the performance
1275270	1280750	rear motor to the standard rear motor. And you can see in this firmware, there's not really a
1280750	1287930	whole lot of differences. If you look, the last line is just the CRC value. There are some single
1287930	1294610	bit changes at three lines in the file. And then there's this other small little section, the
1296750	1307050	935F00 that you see in the actual major change in that. And the single motor version of the
1307050	1311770	firmware is the same. It was just that single line that's changed. So, what I did is actually
1311770	1316030	wanted to see if I could find this code in IDA and see where it was mapped to. And I was able
1316030	1324170	to find it pretty easily. So, you can see within the hex, the 935F007A. This might have something
1324170	1329290	to do with the power available. I don't know yet. I haven't changed it yet. Like I said,
1329290	1333250	it's an ongoing project. But my goal is to actually find where the variables are that
1333250	1339050	control the max power, the max power map, and just see if I can change them a little bit.
1339190	1344190	See where I can actually take it. Don't think I'll ever actually do anything on a live vehicle
1344190	1347950	just because it's too dangerous. I just want to see if I can figure this out. It's a challenge
1347950	1355110	to me. But you can see it's actually mapped into this variable. The 935F actually comes out to 7A
1356170	1362090	935F. Right here, IDA was able to disassemble it. You can see where it is in code. The other values,
1362090	1366890	you can actually find they're right around there. You can see it in a couple of the locations as
1366890	1373530	well. So, again, like I said, the next step is to modify the firmware on a bench BMS and see where
1373530	1378690	it takes us. There's also... I want to look for some other interesting changes with the other PAC
1378690	1383790	ID codes. See if I can actually narrow it down to some variables being located in
1384830	1390270	other locations. And then I'm also actually taking a really close look at the hardware.
1390850	1395270	Code Composer Studio is not the most user-friendly program unless you're really used to working with
1395270	1402850	it. But I do have it working somewhat with a BMS. It does have JTAG exposed and available on it.
1404310	1409510	That's some other stuff that I'm working on. But obviously somebody has figured it out because
1409510	1414130	they're selling it as an aftermarket tuner kit for the Model 3, the all-wheel drive Model 3.
1414930	1418090	Again, I'm just doing this because I want to explore it. I don't want to make money on this.
1418090	1423290	I just want to figure it out. And thank you for listening to my talk. I think we're going to move
1423290	1424730	into Q&A next.