1
00:00:01,760 --> 00:00:02,700
Hi there.

2
00:00:02,700 --> 00:00:05,260
I hope everyone is joining DEF CON Safe Mode.

3
00:00:05,260 --> 00:00:07,580
This should be one of the talks near the end of the conference.

4
00:00:07,580 --> 00:00:10,140
I'm pretty sure it's the last one for the Car Hacking Village.

5
00:00:10,500 --> 00:00:13,520
So I hope everyone's done well and survived this long.

6
00:00:13,520 --> 00: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.

7
00:00:21,500 --> 00: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.

8
00:00:28,560 --> 00: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.

9
00:00:38,220 --> 00:00:43,500
The things I'm going to cover here don't require that you actually have listened to the main talk.

10
00:00:43,520 --> 00: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.

11
00:00:52,360 --> 00: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.

12
00:01:04,460 --> 00:01:06,660
So a little bit about me.

13
00:01:06,660 --> 00:01:07,880
My name is Patrick Kiley.

14
00:01:07,880 --> 00:01:11,020
I'm a Principal Security Consultant at Rapid7.

15
00:01:11,200 --> 00:01:14,200
I've been with them for quite a bit of time.

16
00:01:14,200 --> 00:01:15,800
I started with them in 2013.

17
00:01:16,220 --> 00:01:21,980
I've been working more recently in subjects such as avionics security.

18
00:01:21,980 --> 00: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.

19
00:01:34,280 --> 00: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.

20
00:01:45,720 --> 00: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.

21
00:01:56,870 --> 00:01:59,250
So topics we're going to cover here.

22
00:01:59,470 --> 00:02:03,590
First, we're going to go over the Model S architecture just briefly again.

23
00:02:04,310 --> 00: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.

24
00:02:17,370 --> 00:02:24,630
The screen that you see here is actually from Kvaser's database editor.

25
00:02:25,110 --> 00:02:30,910
That's a free tool that you can use to basically edit and create your own DVC files.

26
00:02:30,910 --> 00: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.

27
00:02:38,730 --> 00: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.

28
00:02:59,110 --> 00:03:03,470
Trying to put this entire DVC file on there would just basically crash the mobile app.

29
00:03:03,470 --> 00:03:05,250
It can't handle that much.

30
00:03:05,250 --> 00:03:10,850
However, trimming it down to just the signals I was interested in is really useful using this tool for that.

31
00:03:10,950 --> 00: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.

32
00:03:16,430 --> 00: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.

33
00:03:30,670 --> 00: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.

34
00:03:41,630 --> 00:03:44,610
And then from there, we're actually going to go into a BMS firmware.

35
00:03:44,610 --> 00: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.

36
00:04:02,110 --> 00:04:08,590
It's also used, on the Model S and other Tesla models.

37
00:04:09,290 --> 00: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.

38
00:04:22,210 --> 00:04:26,290
And then the instrument cluster is actually NVIDIA Tegra based as well.

39
00:04:26,410 --> 00:04:32,690
And it connects to the CID, the central display, over an Ethernet connector.

40
00:04:32,910 --> 00:04:37,750
That Ethernet connection actually connects to a service port, but it also connects to the security gateway.

41
00:04:37,950 --> 00:04:41,150
The security gateway is basically like a vehicle firewall.

42
00:04:41,610 --> 00:04:48,890
It acts as a filtering mechanism between the various CAN buses and the CID itself, the Ethernet.

43
00:04:49,490 --> 00:04:53,770
And then all the stuff that we're going to see today is actually on a powertrain CAN bus.

44
00:04:53,770 --> 00: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.

45
00:05:04,150 --> 00:05:06,630
That CAN bus runs at 500 kilobits a second.

46
00:05:07,090 --> 00:05:14,230
Other than that, it's like any other vehicle CAN bus that you've seen, 11-bit arbitration IDs, sports UDS.

47
00:05:14,570 --> 00:05:21,170
And then the other CAN buses, there are like six or seven, but the other big ones are chassis and body.

48
00:05:21,210 --> 00:05:23,810
Chassis runs at 500 kilobit, body runs at 125.

49
00:05:25,170 --> 00:05:32,510
So the BMS itself, it's the TI-TMS320C2809.

50
00:05:32,630 --> 00:05:36,370
That is a DSP microprocessor.

51
00:05:36,390 --> 00: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.

52
00:05:51,970 --> 00:05:54,110
There's a hardware backup to that.

53
00:05:54,210 --> 00:05:55,930
That's the Altera CPLD.

54
00:05:56,350 --> 00: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.

55
00:06:06,710 --> 00:06:09,910
But basically, it's a hardware backup to the TMS320.

56
00:06:09,910 --> 00: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.

57
00:06:21,230 --> 00:06:23,250
I've never actually seen the fault condition.

58
00:06:23,890 --> 00: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.

59
00:06:31,390 --> 00:06:33,750
There's also a few other devices.

60
00:06:33,750 --> 00:06:36,810
I'm going to just skip to the next slide to talk about those.

61
00:06:37,130 --> 00:06:38,770
There's a current shunt.

62
00:06:38,830 --> 00: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.

63
00:06:47,930 --> 00:06:50,650
This one actually measures quite a bit of current.

64
00:06:50,850 --> 00: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.

65
00:06:59,570 --> 00:07:01,250
The shunt runs STM8.

66
00:07:01,590 --> 00:07:03,310
There's also a pre-charge resistor.

67
00:07:03,310 --> 00:07:08,830
So the way the vehicle actually engages the contactors, it will engage one side of the contactors.

68
00:07:08,830 --> 00:07:11,410
I believe it's negative, please don't quote me on that.

69
00:07:11,470 --> 00: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.

70
00:07:25,870 --> 00: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.

71
00:07:31,210 --> 00:07:33,470
And it uses the pre-charge resistor for that.

72
00:07:33,650 --> 00:07:40,090
Then the contactors themselves, in Ludicrous they are actually replaced with higher current models.

73
00:07:40,090 --> 00:07:45,010
This is a different set of contactors that I picked up off the secondary market so I can do my research.

74
00:07:45,350 --> 00:07:49,870
I also have a single BMB board on this.

75
00:07:49,870 --> 00: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.

76
00:08:01,290 --> 00:08:08,450
It also contains bleed resistors for a battery balancing, voltage measurement, temperature measurement, etc.

77
00:08:08,450 --> 00: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.

78
00:08:18,950 --> 00: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.

79
00:08:27,870 --> 00:08:30,290
So a little bit about CAN-DBC.

80
00:08:30,510 --> 00:08:35,330
The CAN-DBC files I was able to extract from both Toolbox and the vehicle firmware.

81
00:08:36,270 --> 00:08:40,070
Here's what it looks like within Vehicle Spy after it's been imported.

82
00:08:40,230 --> 00:08:48,630
And you can actually see DI means Drive Inverter, DIS means the Front Drive Inverter.

83
00:08:48,630 --> 00:08:52,310
So DI is the Rear Drive Inverter, DIS is the Front Drive Inverter.

84
00:08:52,310 --> 00:08:57,630
You can actually see some different values being broadcast onto the CAN bus from this capture.

85
00:08:58,390 --> 00:09:03,390
And it's an interesting way of actually extracting the signals from this.

86
00:09:03,390 --> 00:09:06,110
You can actually see everything.

87
00:09:06,110 --> 00: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.

88
00:09:17,870 --> 00:09:23,910
This set of images actually shows the BMS after it was upgraded to Ludicrous.

89
00:09:23,910 --> 00:09:27,690
So it has different signals for current and power.

90
00:09:28,030 --> 00:09:30,030
Current is a hard limit.

91
00:09:30,090 --> 00:09:35,550
Once the pack has been upgraded to support Ludicrous, it goes from 1305 to 1516.

92
00:09:36,010 --> 00:09:39,590
You can see that in here is the max discharge current of 1516.

93
00:09:39,590 --> 00:09:47,010
However, the drive power max, the value you see down here is 297 kilowatts, is a variable value.

94
00:09:47,790 --> 00: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.

95
00:09:55,770 --> 00:10:01,350
So the warmer the battery gets up to a point, that drive power max will actually increase.

96
00:10:01,690 --> 00:10:05,990
But then if the car has been stomped on for a little while, it will actually decrease.

97
00:10:05,990 --> 00: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.

98
00:10:18,410 --> 00: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.

99
00:10:27,810 --> 00: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.

100
00:10:44,630 --> 00:10:47,170
And if you don't have ludicrous, you have insane mode.

101
00:10:47,250 --> 00: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.

102
00:10:58,490 --> 00:11:06,010
So even though the battery had not heated up anymore from the 22 degrees Celsius value, instantly more power is available.

103
00:11:06,010 --> 00:11:10,590
It went from 439 to 452 kilowatts.

104
00:11:11,530 --> 00:11:17,090
All right, here's a screenshot from a P90DL that someone actually gave me access.

105
00:11:17,090 --> 00:11:22,210
Let me plug into the CAN bus and capture some messages as the battery was heated a little bit.

106
00:11:22,250 --> 00: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.

107
00:11:30,110 --> 00:11:33,370
So it really seemed like pack temperature is the most dependent value.

108
00:11:33,370 --> 00:11:41,470
So it went from 22 to 31 and went from 454 kilowatts of power available to 480 kilowatts.

109
00:11:41,470 --> 00:11:44,530
You can also see region change went from 63 to 90.

110
00:11:44,530 --> 00:11:48,550
90 appeared to be a top end static value.

111
00:11:50,450 --> 00:11:53,450
So a little bit about ODX.

112
00:11:53,450 --> 00:11:58,730
ODX is an ISO standard for diagnostic communication and ECUs.

113
00:11:58,730 --> 00: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.

114
00:12:13,250 --> 00: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.

115
00:12:23,350 --> 00:12:26,030
ODX is a standard that kind of aids in that.

116
00:12:26,030 --> 00:12:36,390
It's a standard for diagnostic communication so that a specific message start always means generally the same thing.

117
00:12:36,390 --> 00: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.

118
00:12:51,290 --> 00:12:59,070
So here is one of the most interesting ODX routines if you're going to start hacking on Tesla.

119
00:12:59,070 --> 00:13:03,450
Tesla's use a static key and C for security access.

120
00:13:03,750 --> 00:13:08,050
Not the best security practice, but it's the way they decide to implement it.

121
00:13:08,390 --> 00:13:15,270
And every single time you actually request security access, you can see the 2705, that's security access.

122
00:13:16,950 --> 00:13:19,330
It says, okay, give me the seed.

123
00:13:19,330 --> 00:13:22,810
The seed is 010203 all the way up through 0F.

124
00:13:23,070 --> 00:13:25,250
And the response is always the same thing.

125
00:13:25,250 --> 00:13:32,530
So you can actually configure your CAN bus tool to send the same response every single time.

126
00:13:32,670 --> 00:13:37,190
And that's the 353437 value C is the key.

127
00:13:37,410 --> 00: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.

128
00:13:46,610 --> 00:13:52,010
And here I have a little demo actually showing how I set this up in Vehicle Spy.

129
00:13:52,010 --> 00:13:58,450
So you just send routine 27 level 5, level 5 security being the security access level.

130
00:13:58,530 --> 00:14:04,770
And then you reply with this static key as the response.

131
00:14:05,310 --> 00:14:07,590
There's a quick demo of it.

132
00:14:13,310 --> 00:14:13,670
Okay.

133
00:14:13,670 --> 00:14:17,110
Here we have a quick demonstration of security access.

134
00:14:17,110 --> 00:14:20,630
We have both routines configured within Vehicle Spy.

135
00:14:20,630 --> 00:14:23,810
The first thing we want to do is we want to request the seed.

136
00:14:23,810 --> 00:14:25,510
It's a very quick routine.

137
00:14:25,610 --> 00:14:30,570
And then from there, we actually request the key and we can see we can get a quick positive response.

138
00:14:30,590 --> 00:14:32,550
It's a very simple routine.

139
00:14:32,910 --> 00:14:34,650
Do it one more time.

140
00:14:35,470 --> 00:14:36,730
Request the seed.

141
00:14:36,730 --> 00:14:41,870
You can see the seed 1, 2, 3, 4, 5, 6, 7, 8, 9, A through F.

142
00:14:42,350 --> 00:14:44,490
And then, oh, didn't do it fast enough.

143
00:14:44,490 --> 00:14:45,550
One more time.

144
00:14:45,850 --> 00:14:47,130
Request the seed.

145
00:14:47,510 --> 00:14:48,570
Send the key.

146
00:14:48,750 --> 00:14:50,330
We got a positive response.

147
00:14:50,990 --> 00:14:56,910
A positive response shows the static value actually configured within Vehicle Spy.

148
00:14:56,970 --> 00:15:01,390
And just 303332, same things shown in the slides.

149
00:15:01,670 --> 00:15:04,990
And it's a very trivial thing to set up within Vehicle Spy.

150
00:15:04,990 --> 00:15:09,510
This is actually connected to a BMS system that's a test bench.

151
00:15:15,730 --> 00:15:16,110
Okay.

152
00:15:16,110 --> 00:15:18,270
So thank you for watching that one.

153
00:15:18,270 --> 00:15:19,570
I hope you enjoyed it.

154
00:15:19,690 --> 00:15:23,630
So the next one I'm going to kind of talk about is the shunt calibration.

155
00:15:23,630 --> 00:15:27,630
Shunt calibration over UDS was a separate routine.

156
00:15:28,570 --> 00: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.

157
00:15:36,710 --> 00:15:41,250
The shunt calibration was a critical part of that, the ludicrous upgrade for the PD5D.

158
00:15:41,710 --> 00: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.

159
00:15:53,350 --> 00:15:57,230
Those actually show the current value, but all you really need is the serial number.

160
00:15:57,230 --> 00: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.

161
00:16:04,690 --> 00:16:11,490
And you re-change CGI1, CIU1, and the CRC value to the new values.

162
00:16:11,490 --> 00:16:16,950
Even though you're reading it, the way it actually shows the write success, this is just a read screenshot.

163
00:16:18,450 --> 00:16:22,350
But once you actually get that back, there's a separate routine to write it.

164
00:16:22,350 --> 00: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.

165
00:16:31,390 --> 00:16:37,450
The one that was supposed to be used to calibrate the shunt was 31 routine control.

166
00:16:37,570 --> 00:16:45,890
So for this particular example, if you go back, you can see that the old values were 41478.

167
00:16:47,030 --> 00:16:54,750
I'm actually going to try and change these and actually write them out separately.

168
00:16:55,010 --> 00:17:03,850
So you can see in the routine control, the value is set here for CGI1, CIU1, 65286.

169
00:17:04,190 --> 00: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.

170
00:17:14,510 --> 00:17:20,950
Okay, so there are several other routines that are actually included in the ODX files.

171
00:17:20,950 --> 00:17:26,150
If you actually look at this, there are ridiculous ones just even for the battery management system.

172
00:17:26,150 --> 00: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,

173
00:17:42,270 --> 00:17:46,110
you can have some current transient issues.

174
00:17:46,570 --> 00: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.

175
00:17:53,930 --> 00: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.

176
00:18:02,110 --> 00:18:05,070
So, next thing we're going to talk about is the firmware.

177
00:18:05,210 --> 00: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.

178
00:18:14,190 --> 00: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.

179
00:18:21,190 --> 00:18:27,350
So, they'll include all the firmware for all the various possibilities for that particular vehicle.

180
00:18:28,050 --> 00: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.

181
00:18:42,410 --> 00:18:46,870
So, here's a little overview on how the Intel HEX format works.

182
00:18:46,870 --> 00:18:54,450
The first value, it always starts with a colon, and then the first value C20 is 32 bytes for HEX.

183
00:18:54,450 --> 00:19:01,150
And then we have an address of where that particular piece of firmware goes.

184
00:19:01,610 --> 00: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.

185
00:19:10,690 --> 00:19:12,470
And then you actually have data.

186
00:19:12,470 --> 00:19:15,190
And then the final value is a checksum.

187
00:19:15,370 --> 00:19:17,610
I added these spaces in for clarity.

188
00:19:17,770 --> 00: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.

189
00:19:25,010 --> 00: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 .

190
00:19:35,710 --> 00:19:44,170
So, this shows the actual data sheet for the TI-TMS320-2809.

191
00:19:44,170 --> 00:19:46,450
It actually shows the memory map .

192
00:19:46,450 --> 00: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.

193
00:19:58,830 --> 00:20:00,210
So, you can actually see it.

194
00:20:01,630 --> 00:20:07,630
3F7FF6 is actually where the initial, basically, boot-to-flash entry point.

195
00:20:07,630 --> 00:20:10,930
So, that basically tells us where the code entry point is for IDA.

196
00:20:11,650 --> 00:20:16,010
So, from that, we can actually import the data and actually go to this location.

197
00:20:16,010 --> 00: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.

198
00:20:25,210 --> 00:20:30,490
It's still not terribly helpful unless you're really, really good at reading assembly for the TMS320.

199
00:20:30,490 --> 00:20:32,530
However, it is there.

200
00:20:32,530 --> 00: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.

201
00:20:41,730 --> 00:20:45,350
And the thing that I did find very useful was actually doing some differential analysis.

202
00:20:45,350 --> 00:20:50,690
So, taking the different types of firmware and doing diffing on it.

203
00:20:51,090 --> 00:20:59,530
So, again, the assigned metadata map file tells us where the BMS firmware is for each config.

204
00:20:59,810 --> 00:21:06,870
This example, so, rear drive type one, four-wheel drive one, 4WD1 is P85D.

205
00:21:07,530 --> 00:21:11,350
Rear drive type zero and 4WD1 is an 85D.

206
00:21:11,370 --> 00:21:18,090
So, here we're comparing the performance rear motor to the standard rear motor.

207
00:21:18,090 --> 00:21:21,910
And you can see in this firmware, there's not really a whole lot of differences.

208
00:21:22,110 --> 00:21:26,590
If you look, the last line is just the CRC value.

209
00:21:26,790 --> 00:21:31,590
There are some single bit changes at three lines in the file.

210
00:21:31,590 --> 00:21:43,730
And then there's this other small little section, the 935F00 that you see in the actual major change in that.

211
00:21:43,730 --> 00:21:47,690
And the single motor version of the firmware is the same.

212
00:21:47,690 --> 00:21:49,910
It was just that single line that's changed.

213
00:21:50,070 --> 00: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.

214
00:21:55,630 --> 00:21:57,350
And I was able to find it pretty easily.

215
00:21:57,390 --> 00:22:02,330
So, you can see within the hex, the 935F007A.

216
00:22:02,990 --> 00:22:06,490
This might have something to do with the power available.

217
00:22:06,490 --> 00:22:07,190
I don't know yet.

218
00:22:07,190 --> 00:22:08,250
I haven't changed it yet.

219
00:22:08,630 --> 00:22:10,450
Like I said, it's an ongoing project.

220
00:22:10,630 --> 00: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.

221
00:22:19,190 --> 00:22:21,150
See where I can actually take it.

222
00:22:21,610 --> 00:22:25,350
Don't think I'll ever actually do anything on a live vehicle just because it's too dangerous.

223
00:22:25,350 --> 00:22:27,130
I just want to see if I can figure this out.

224
00:22:27,190 --> 00:22:28,690
It's a challenge to me.

225
00:22:28,990 --> 00:22:32,190
But you can see it's actually mapped into this variable.

226
00:22:32,530 --> 00:22:36,890
The 935F actually comes out to 7A 935F.

227
00:22:37,870 --> 00:22:40,290
Right here, IDA was able to disassemble it.

228
00:22:40,330 --> 00:22:41,370
You can see where it is in code.

229
00:22:41,370 --> 00:22:44,450
The other values, you can actually find they're right around there.

230
00:22:44,610 --> 00:22:47,450
You can see it in a couple of the locations as well.

231
00:22:48,610 --> 00: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.

232
00:22:55,370 --> 00:22:59,630
There's also... I want to look for some other interesting changes with the other PAC ID codes.

233
00:23:00,010 --> 00:23:06,270
See if I can actually narrow it down to some variables being located in other locations.

234
00:23:06,750 --> 00:23:10,270
And then I'm also actually taking a really close look at the hardware.

235
00:23:10,850 --> 00:23:15,950
Code Composer Studio is not the most user-friendly program unless you're really used to working with it.

236
00:23:16,170 --> 00:23:18,930
But I do have it working somewhat with a BMS.

237
00:23:18,930 --> 00:23:22,850
It does have JTAG exposed and available on it.

238
00:23:24,310 --> 00:23:26,570
That's some other stuff that I'm working on.

239
00:23:27,090 --> 00: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.

240
00:23:34,930 --> 00:23:37,010
Again, I'm just doing this because I want to explore it.

241
00:23:37,010 --> 00:23:38,090
I don't want to make money on this.

242
00:23:38,090 --> 00:23:39,450
I just want to figure it out.

243
00:23:40,850 --> 00:23:42,610
And thank you for listening to my talk.

244
00:23:42,610 --> 00:23:44,730
I think we're going to move into Q&A next.