Tesla Model 3 Rear Drive Unit Hacking

[AMP3R]

What is the progress for now with TI Chip?

[huggyd1]

Ah. I misunderstood. The oil seal housing != oil pump.

The oil pump defaults to limp home mode if not plugged in to the Tesla SW. It's controlled over LIN using an as yet undocumented protocol. There are some captures to decode if anyone wants a simple(ish) project. It's down Damien's and my priority list due to the limp home behaviour.

Is it possible that in the last month someone has figured out the Oil Pump LIN bus controls?
It appears to do the following at startup:
0x0A | 0xFF | 0x00 | 0x35 (csum) - First LIN command received - presumably assigns 0x0A to Oil Pump motor ??
0x0A | 0xFF | 0x0D | 0x28 (csum) - Enables oil pump motor controls
0x0A | 0xFF | 0x11 | 0x24 (csum) - Sets default speed when wheel/motor is not spinning

Anyone do session captures while the motor/wheel is spinning and save the actual wheel speed / vehicle speed so we can get the speed setpoint command and actual speed feedback scaling?
Anyone create an LDF of the oil pump motor controls?

[techn0]

I have been sifting through some model 3 can logs and came across this data. Thought it might be useful for the LIN decoding. That data has to be gathered over LIN to be put on the CAN bus.

[briandilley]

Hey guys - first time posting here, this thread seemed like the right place.

I have an interesting project that some friends and I are working on. We have a rear drive unit from a plaid that we'd like to get working without swapping any hardware, we want to control it with CAN and whatever methods the vehicle does so as stock. I figured that we'd develop some hardware, software, and a process for reverse engineering the drive unit by doing so on my daughter's model 3 first, and then renting a plaid and doing so on it. We're still working on the model 3, and so my questions are about it.

We created a harness for performing a man in the middle attack on the CANbus in the rear of the vehicle, closest to the rear motor inverter. All leads are simple pass through, except for the CANbus leads (a single CAN H, and CAN L) which come out into a connector where we can "jack in" (to use cool 90s hacking terminology). We then created a simple piece of hardware using an STM32 with two CANs on board to act as the man in the middle. The idea being that we could see where each CAN message was coming from; the inverter, or the rest of the vehicle. This would help us determine which CAN messages control the inverter. We can also filter messages out from either or both sides - as well as re-write them.

Once we got all of this working, we started by filtering out every single message... not allowing a single message to pass through either way. Then someone sat in the drivers seat and proceeded to try and change into "Drive" over and over again while a script allowed one ID at a time to pass through until we found the message that tells the drive unit to enter "DRIVE", "PARK", "REVERSE", etc (message 1e5) - or so we thought. I spent that night documenting our findings (which you'll find below) only to realize today that while the message id is the same (1e5), the contents of that message have changed. It seems similar - but has completely different values today than it did yesterday.

My question is this: Has anyone gotten one of these drive units working without having to swap out any hardware? Does anyone know the secret to the 1e5 message?

Side note: We made our hardware/software dump the canbus as KVaser hex format - i'll attach a few logs that we've gathered to this post. Bus 0 is the vehicle, Bus 1 is the inverter... you'll see messages from both busses.

Here are the logs from yesterday:

fresh-start.txt.zip

(937.89 KiB) Downloaded 70 times

park-to-drive-to-park.txt.zip

(406.57 KiB) Downloaded 65 times

cycle-through-gears.txt.zip

(617.46 KiB) Downloaded 60 times

And here is a log from today:

freshy.txt.zip

(3.56 MiB) Downloaded 59 times

You'll notice that the 1e5 message is very similar, but has different values in them. A counter of sorts still seems to be present in bytes 7 and 8, but bytes 1 and 2 have changed and where byte 3 was always 0 yesterday, it sometimes contains values today.

My guess is that there is some other message that is sent to or by the inverter that determines what the payload of 1e5 actually is.

Any help would be greatly appreciated


*FOLLOWS IS THE DOCUMENTATION THAT I PUT TOGETHER FOR THE PRNDL MESSAGE `1e5` that turns out is NOT VALID*
*FOLLOWS IS THE DOCUMENTATION THAT I PUT TOGETHER FOR THE PRNDL MESSAGE `1e5` that turns out is NOT VALID*
*FOLLOWS IS THE DOCUMENTATION THAT I PUT TOGETHER FOR THE PRNDL MESSAGE `1e5` that turns out is NOT VALID*

PRNDL MESSAGE
0x1e5 Seems to control the drive mode / PRNDL. It’s frequency looks about 100hz (10ms). Bytes 1 and 2 seem to be the gear, and bytes 7 and 8 are a counter that increments over 4 numbers and are specific to the gear that it is in (as indicated by bytes 1 and 2). When only 0x1e5 is allowed to come into the inverter, the inverter allows the motor to be spun, and at full power.



Gear: 52 4c
Counters: 40 c4, 60 e4, 00 84, 20 a4


0 1e5 8 52 4c 00 00 00 00 00 84 13.106999 R
0 1e5 8 52 4c 00 00 00 00 20 a4 13.117000 R
0 1e5 8 52 4c 00 00 00 00 40 c4 13.127000 R
0 1e5 8 52 4c 00 00 00 00 60 e4 13.137000 R


Gear: 52 6c
Counters: 20 C4, 40 E4, 60 04, 00 A4


0 1e5 8 52 6c 00 00 00 00 00 a4 9.259000 R
0 1e5 8 52 6c 00 00 00 00 20 c4 9.269000 R
0 1e5 8 52 6c 00 00 00 00 40 e4 9.278000 R
0 1e5 8 52 6c 00 00 00 00 60 04 9.288000 R



Gear: 58 0c
Counters: 60 AA, 00 4A, 20 6A, 40 8A

0 1e5 8 58 0c 00 00 00 00 00 4a 4.466999 R
0 1e5 8 58 0c 00 00 00 00 20 6a 4.477000 R
0 1e5 8 58 0c 00 00 00 00 40 8a 4.487000 R
0 1e5 8 58 0c 00 00 00 00 60 aa 4.496999 R


Gear: 58 2c (Drive?)
Counters: 00 6A, 20 8A, 40 AA, 60 CA

0 1e5 8 58 2c 00 00 00 00 00 6a 18.538000 R
0 1e5 8 58 2c 00 00 00 00 20 8a 18.547999 R
0 1e5 8 58 2c 00 00 00 00 40 aa 18.557999 R
0 1e5 8 58 2c 00 00 00 00 60 ca 18.568000 R



Gear: 56 2c
Counters: 00 68, 20 88, 40 A8, 60 C8

0 1e5 8 56 2c 00 00 00 00 00 68 20.417999 R
0 1e5 8 56 2c 00 00 00 00 20 88 20.428000 R
0 1e5 8 56 2c 00 00 00 00 40 a8 20.437999 R
0 1e5 8 56 2c 00 00 00 00 60 c8 20.448000 R

[kraln]

I have an interesting project that some friends and I are working on. We have a rear drive unit from a plaid that we'd like to get working without swapping any hardware, we want to control it with CAN and whatever methods the vehicle does so as stock.

The Model 3 drive units are cryptographically paired with the VCSEC. Without the appropriate handshake, the inverter won't budge. Ingineerix and EV Controls collaborated on breaking (or going around, still not clear to me) this handshake, but they aren't willing to share--the stated reason is: "obviously giving out code to bypass this would be bad as then once it gets out people can use it to steal cars". If it involved extracting key material from the onboard microcontroller in the inverter, then it'd also likely pose a legal challenge to share it, but I don't want to guess.

I am however, nevertheless, also extremely interested in driving a Model 3 RDU without modifying any hardware. I'll dig through your CAN logs (and some I have access to here...). Feel free to reach out to me if you'd like to collab.

[AMP3R]

I think it’s unlikely that ev controls and ingenext bothered too much about hacking the Model 3 inverter. They dumb have recorded specific canbus messages between the inverter and the rest of the car’s units. Then removed the motor from car, replayed this canlog and of course this particular motor came to life.

But how can you run other motors, make a primitive controller and sell it for 3k bucks with a cost of made maybe $50? It just need to copy the software from this particular inverter and learn how to flash it into the others via canbus. How to write new software to the inverter? You need to listen canbus during official tesla's firmware update. In this way, you can understand how the firmware mode is turned on and use it for your own selfish purposes.

Haven't you noticed that ev controls are smarter guys, unlike ingenext? They know how to flash firmware from their “reference” inverter via can and let to do it by yourself. While ingenext asks to send the inverter to them for flasing. Maybe they are just afraid that people will do reverse engineering and learn how to flash through canbus? Who knows...

In short, it would be great if someone on the forum could repeat the path for example of ev controls, read the firmware from a particular model 3 and so on. But I have a feeling that no one here will do this because they are afraid of future litigation? Or maybe someone would like to chip in and do reverse engineering of the controller from ev controls? Do you think they will be very offended?

[AMP3R]

To begin with, who on the forum knows how to read the firmware from the inverter?

[CatCommando]

The Model 3 drive units are cryptographically paired with the VCSEC. Without the appropriate handshake, the inverter won't budge.

so what about drive units that have never been used? do they use some standard key to start with or are the chips completely non fuctional/blank or have some sort of "starter firmware" until pairing?

I ask because Im both curious and have a brand new zero mile M3 FDU in crate coming soon and Id love to be able to contribute to all this in some way or at least be a guinea pig for testing stuff.

if there is a default "pre paired" state that we could make a dump of, Id again love to help.

[briandilley]

I’m happy to share more logs from the model 3 for help. The cryptographic pairing is unfortunate. But I should be able to get my inverter running via can snooping and emulating the rest of the vehicle right?

Has anyone documented the firmware update via CAN yet?

I’m happy to be very open with any solutions for getting this running - even if it means flashing the same firmware on every drive unit that we want to run.

[kraln]

To begin with, who on the forum knows how to read the firmware from the inverter?

The inverter's main microcontroller is a TMS320F28377D, which is its own architecture microcontroller/DSP (C28x) that dates back to the very early days of Ti--it's not ARM Cortex or AVR or anything "normal". It also has a security unit as well as encrypted flash, and code read/debug protection. There are ways to glitch out the code read and debug protection, but even doing that you're faced with trying to reverse engineer a firmware for an architecture with no tooling support and no real way to recover from a mistake.

I think it's probably easier to record a full firmware update via CAN and rebuild the firmware from there than to get it from the chip.

[kraln]

I’m happy to be very open with any solutions for getting this running - even if it means flashing the same firmware on every drive unit that we want to run.

If I was a betting man, this is where I'd place my bets on "Tesla legal has an issue with this". I'd much rather go for someting along the lines of an open-source solution which, if you have the original VESEC controller, you can use to "properly" respond to the challenges without having to reflash or anything nefarious. This would have two advantages: 1) much less legal stress 2) open for everyone to use, and of course the fact that you couldn't use it to somehow steal a car...

I'm unfamiliar with the (normal) Tesla ecosystem--is there a way to force an inverter firmware update or re-flash outside of a shop?

[P.S.Mangelsdorf]

so what about drive units that have never been used? do they use some standard key to start with or are the chips completely non fuctional/blank or have some sort of "starter firmware" until pairing?

I ask because Im both curious and have a brand new zero mile M3 FDU in crate coming soon and Id love to be able to contribute to all this in some way or at least be a guinea pig for testing stuff.

if there is a default "pre paired" state that we could make a dump of, Id again love to help.

My understanding, and I could be wrong, is that it is less a "pairing" and more a encrypted call and response between the drive unit and other computers in the car. No one has (open source anyways) broken the encryption. Even on the LDU and SDU, when the call and response was implemented, the commercial conversion solutions required reprograming the inverter to an earlier firmware without it.

There might be some sort of initial key provided when vehicles are programmed at the factory to tie the computers together, but I have no idea, it's way above my head.

Also, and feel free to not answer this, but how in the world did you get a zero mile drive unit? I thought Tesla didn't sell those? Did it "fall off a truck"?

[briandilley]

Which CANbus does this call and response come across? Speaking from the inverters point of view there's a "Party CAN" and "Vehicle CAN". I'm currently doing a man in the middle on the vehicle CAN but wonder if I should also be on the party can.

As for legal issues with Tesla - I figure if we just release the tools for acquiring the logs and firmware then anyone can do this themselves on a "live" Tesla and use it to flash their own inverters. Rather than release a copy of Tesla's firmware. Teach a man to fish so to say?

Does the inverter have OTP? Are there "things" on the inverter than uniquely identify it? "things" that are used as part of the handshake?

Also curious - Tesla allows for their hardware to be flashed to older versions of firmware?

[davefiddes]

Does the inverter have OTP? Are there "things" on the inverter than uniquely identify it? "things" that are used as part of the handshake?

Yes. The TMS320F28377D has a whole security sub-system with a pair of secure zones for each of the two processors. There is a region of OTP to store unique identifiers and security keys and the device is capable of secure booting from flash. Tesla enables a large chunk of the security capabilities of the chip. They haven't locked out everything they could with the OTP security bits so you can still get access to almost the entirety of the chip including the JTAG interface provided you wipe the contents first. The only bits on my inverter I have been unable to access are the security key stores which figures.

For more details have a read at TMS320F2837xD Dual-Core Microcontrollers Technical Reference Manual which is freely downloadable.

Not to be a party pooper and IANAL but I think the US DMCA applies here (https://en.wikipedia.org/wiki/Anti-circumvention). Circumventing access controls for interoperability purposes seems to be allowed under the reverse engineering provision...when/if people get their cars stolen it might get quite spicy for those involved though.

FWIW the approaches Damien and I are using largely driven by our skills, tools, availability of information and inclination rather than worry about litigation. Complicated way of saying we're not smart enough.

[briandilley]

when/if people get their cars stolen it might get quite spicy for those involved though.

This argument is silly to me. Couldn't I just used the commercially available solutions out there to steal a car anyway?

[davefiddes]

I personally wouldn't want to argue with a bunch of lawyered up ex-Telsa owners and Tesla Inc should the worst come to the worst. If you are cool with that fair enough. I probably spent too long on Slashdot in the late 90s and early 2000s.

[briandilley]

I personally wouldn't want to argue with a bunch of lawyered up ex-Telsa owners and Tesla Inc should the worst come to the worst. If you are cool with that fair enough. I probably spent too long on Slashdot in the late 90s and early 2000s.

haha - understandable

[P.S.Mangelsdorf]

Which CANbus does this call and response come across? Speaking from the inverters point of view there's a "Party CAN" and "Vehicle CAN". I'm currently doing a man in the middle on the vehicle CAN but wonder if I should also be on the party can.

That, I don't know.

Also curious - Tesla allows for their hardware to be flashed to older versions of firmware?

My understanding is that was what several commercial suppliers were doing for their LDU.

Most of my understanding comes from the "Why do we replace the brain board in the LDU rather than use emulation" explanations around here, and some from those commercial suppliers explanation of why, for instance, they need to supply the drive unit and control board together.

[CatCommando]

There might be some sort of initial key provided when vehicles are programmed at the factory to tie the computers together, but I have no idea, it's way above my head.

Also, and feel free to not answer this, but how in the world did you get a zero mile drive unit? I thought Tesla didn't sell those? Did it "fall off a truck"?

I actually just purchased it on Ebay of all places (item 195819903318 if you wanna look), its yet to ship. the description says they ordered it and just never used it. in the photos and other items they have for sale it looks to be just some kind of luxury german car body shop in Miami or something as there is also a Hyundai motor in crate next to it. but the M3 FDU is still in a tesla branded crate still and its absolutely spotless so who knows really until I get it.

as for Tesla not selling them Im not sure that is the case (maybe luckily for us), even in their own online part catalog this part model number 1120960-10-H is listed as "Sales Restriction - Unrestricted" instead of "Restricted" "Tesla only" or "over the counter" as other parts seem to be classified. strangely a re-manufactured version of the same unit IS marked as "Tesla Only"

it could just be a right to repair sort of thing where they let you have a whole unit simply to avoid legal trouble? IDK but id love to know why and if it would be easy to just get them new directly from tesla for projects or for reverse engineering other units.

in any case Im going to try and make a 3d scan of the thing while its still semi suspended in crate either using my iphone 15 and photogramertry or one of these Intel realsense depth cameras ive got laying around.

[CatCommando]

Once we got all of this working, we started by filtering out every single message... not allowing a single message to pass through either way.

You'll notice that the 1e5 message is very similar, but has different values in them. A counter of sorts still seems to be present in bytes 7 and 8, but bytes 1 and 2 have changed and where byte 3 was always 0 yesterday, it sometimes contains values today.

My guess is that there is some other message that is sent to or by the inverter that determines what the payload of 1e5 actually is.

your whole method of doing this is super cool, Id love for more details as ideally I too would want to control the unit unmodified via just canbus if possible.

so you are man in the middle recording the cars shifting commands, are you also already trying to replay the recorded canbus data? replaying with only the inverter seeing the same command the second time? like for instance maybe you rev with the pedal and then immediately replay it again? are you able to introduce latency and delay the commands and find out the limits there? like shift using the car but add a false delay before the inverter finally sees it?

unless the inverter has some storage it constantly writes to, or like a real time clock to give it a different frame of reference you would imagine your replay attack or a delayed command would work once its all "authorized" post the initial car handshake, unless the handshake is EVERY command.

could that handshake or seed value be part of the data you already filtered out? how does it know THIS time not to just listen to the same stream of commands it got last time?

Id be curious what hardware specifically prevents us from just pulling a Bill Murry in Ground Hogs Day. what would happen if it was narrowed down to physical hardware difference and someone had like 5 identical inverters isolated from each-other but fed the same sensor data, same commands, the same battery voltage etc, wouldnt that allow you to figure out "the handshake"or at least how challenge/response keys work?

I wish I could throw 20k at this just to mess around.

[P.S.Mangelsdorf]

I actually just purchased it on Ebay of all places (item 195819903318 if you wanna look), its yet to ship. the description says they ordered it and just never used it. in the photos and other items they have for sale it looks to be just some kind of luxury german car body shop in Miami or something as there is also a Hyundai motor in crate next to it. but the M3 FDU is still in a tesla branded crate still and its absolutely spotless so who knows really until I get it.

as for Tesla not selling them Im not sure that is the case (maybe luckily for us), even in their own online part catalog this part model number 1120960-10-H is listed as "Sales Restriction - Unrestricted" instead of "Restricted" "Tesla only" or "over the counter" as other parts seem to be classified. strangely a re-manufactured version of the same unit IS marked as "Tesla Only"

it could just be a right to repair sort of thing where they let you have a whole unit simply to avoid legal trouble? IDK but id love to know why and if it would be easy to just get them new directly from tesla for projects or for reverse engineering other units.

in any case Im going to try and make a 3d scan of the thing while its still semi suspended in crate either using my iphone 15 and photogramertry or one of these Intel realsense depth cameras ive got laying around.

Huh, that's interesting. I need to try to order some parts direct from Tesla and see what I can and can't get. Ebay is likely still the cheaper option, but if we can get some stuff directly from them, that'd be good to know.

[briandilley]

Huh, that's interesting. I need to try to order some parts direct from Tesla and see what I can and can't get. Ebay is likely still the cheaper option, but if we can get some stuff directly from them, that'd be good to know.

I just signed up with our business information... i'll report back on how it goes

[briandilley]

your whole method of doing this is super cool, Id love for more details as ideally I too would want to control the unit unmodified via just canbus if possible ....

We've decided to table this for the time being. It doesn't seem like we're going to be able to control _any_ unit with the methods that we're attempting to use. At best we'd only be able to control a unit that we've pulled out of another vehicle, after scanning it while on the vehicle.

Our end goal wasn't to get the model 3 working anyway, it was to get a plaid drive unit working because we've got one in the shop... but we don't have the rest of the car so it's basically useless at this point

[briandilley]

Given that they use the same inverter form factor - what's the status of the model 3 open inverter replacement board? How feasible would it be for us to use two of them to run the plaid drive unit?

[P.S.Mangelsdorf]

Given that they use the same inverter form factor - what's the status of the model 3 open inverter replacement board? How feasible would it be for us to use two of them to run the plaid drive unit?

Not sure the status but my guess is that once they're ready, it would be highly feasible to use them in the Plaid unit, if the Plaid is truly just 2 M3 inverters, at least in form-factor. Even if they use more powerful switching electronics, if the structure is the same, they should be compatible from a control perspective.