Tesla M3 Factory fitted FDU Control using CAN

[ravikashi]

Hello Forum members,

My objective is to control the factory fitted Front Drive Unit using the CAN interface by spoofing CAN messages.

I saw EV_Builder's post a couple of months back about taking this route and succeeding in getting the RDU spinning which is similar to what I intend to do on the FDU.

I want to seek your advise on how to proceed in this direction, CAN DBC files and such will be great help!

Regards,
Ravi

[Boxster EV]

Hi,

Welcome!

This forum specializes in opensource replacement logic boards to run tesla/OEM components such as drive units.

There isn't a focus on spoofing CAN messages to OEM logic boards.

[Bratitude]

Hello Forum members,

My objective is to control the factory fitted Front Drive Unit using the CAN interface by spoofing CAN messages.

I saw EV_Builder's post a couple of months back about taking this route and succeeding in getting the RDU spinning which is similar to what I intend to do on the FDU.

I want to seek your advise on how to proceed in this direction, CAN DBC files and such will be great help!

Regards,
Ravi

the main reason folks here don’t can spoof Tesla stuff all that often, is the high development/ research cost coupled with the fact that if open sourced Tesla would push updates that would break the effort. so hardware replacement rout is taken.

but feel free to post about it

[jon volk]

Simple search on github yields an extensive dbc.....
https://github.com/joshwardell/model3dbc

[ravikashi]

This forum specializes in opensource replacement logic boards to run tesla/OEM components such as drive units.
There isn't a focus on spoofing CAN messages to OEM logic boards.

I saw what the contributor - EV_Builder did. It is very much the same I want to do. So, asked.
I understand the preferred approach in the forum. Thanks for the reply.

[ravikashi]

the main reason folks here don’t can spoof Tesla stuff all that often, is the high development/ research cost coupled with the fact that if open sourced Tesla would push updates that would break the effort. so hardware replacement rout is taken.
but feel free to post about it

Thank you for the reply. I see the point of "SW update breaking the effort" and also the effort to understand and extract 64 bits in the CAN message. Its no easy task and which is why I seek support. some of the experienced guys here would had made progress in this direction.

Looking at some of the messages from the DB I received, the Checksum field of one message is different from the other and its quite hard to make sense of it.

[ravikashi]

Simple search on github yields an extensive dbc.....
https://github.com/joshwardell/model3dbc

Hello Jon,
thank you for the link. I have this .dbc file. It is very helpful.

[Jack Bauer]

So as others have pointed out we focus more on hardware solutions here particulalry for inverters and exclusively for Tesla drive units. The reason for that is we want to have universally applicable solutions so wherever/whenever/however you got a drive unit this will just work. We do spoof can to things like chargers/dcdc converters and those sort of things but not drive units. Drive units are rather different in that they feature a challenge/response between the drive unit and the car to determine if its ok to enable. Tesla brought this in (in my opinion) as a response to high profile clickbait media stories of "car hacking" and it means drive units cannot be swapped between cars without being reprogrammed.

So if your goal is to just get one drive unit working for your own application then that's fine. But if I for example wanted to get a can based solution to work for the masses it would involve flashing a know firmware with a know encryption key and can message format to that drive unit using the can bootloader. I'm sure EV_Builder and others will chime in. I only know the broad strokes and as stated I'm looking for a universal solution hence the hardware attack. You will find very little information on the details as its kept very secret by those that know in order to protect their business model and also it would not take Tesla that long to ruin their day with the next firmware revision. Personally I'm in favor of any solution that gets motors spinning and am amazed by the skill and have respect for those who CAN hack the CAN side of Tesla drive units. Shame its not reciprocated at times ...

[EV_Builder]

What Damien says, and be aware that allot of third parties upload a older non IMMO firmware, US firmware, one of the first versions was even uploaded from the board (at the early stages it wasn't protected to read from the chip).

So you think you benefited of the latest changes but indeed could be damaging your motor/inverter because you rolled back an software release. i know of third parties where you send them your board and others don't sell you the controller only, but only the complete package including motor/inverter etc.
Not all of them have the SDU available either.

If you are lucky the front motors are easier, i suspect that because they are slaves so big chance that they actuate by the merci of the rear motor itself.

[ravikashi]

Drive units are rather different in that they feature a challenge/response between the drive unit and the car to determine if its ok to enable. Tesla brought this in (in my opinion) as a response to high profile clickbait media stories of "car hacking" and it means drive units cannot be swapped between cars without being reprogrammed.

Woah! this challenge-response is going to be real pain in the *neck*. I am sure it will be mutual authentication and a really large encryption block size. It will be time bound during Ignition.

So if your goal is to just get one drive unit working for your own application then that's fine. But if I for example wanted to get a can based solution to work for the masses it would involve flashing a know firmware with a know encryption key and can message format to that drive unit using the can bootloader.

I don't think I can "root" the FDU with such a firmware . I have access to a complete functioning car. I am thinking of a microcontroller with 2 CAN bus interfaces and insert it "as a man in the middle" between FDU and rest of the car, allow then authentication process to complete and then start spoofing messages as necessary to control the FDU.

I'm sure EV_Builder and others will chime in. I only know the broad strokes and as stated I'm looking for a universal solution hence the hardware attack. You will find very little information on the details as its kept very secret by those that know in order to protect their business model and also it would not take Tesla that long to ruin their day with the next firmware revision. Personally I'm in favor of any solution that gets motors spinning and am amazed by the skill and have respect for those who CAN hack the CAN side of Tesla drive units. Shame its not reciprocated at times ...

Me too, hats off to the guys who created the CAN db from nothing - making sense of seemingly random stream of bits need a different level of commitment and skill.

https://teslaownersonline.com/members/jwardell.1513/ <--- His work is inspiring.

[ravikashi]

What Damien says, and be aware that allot of third parties upload a older non IMMO firmware, US firmware, one of the first versions was even uploaded from the board (at the early stages it wasn't protected to read from the chip).

Oh! wow "non-immo" binary is cool. But there is only so much you can do with it. I wonder if there are decompilers that work on the TMS320 MCU used.

If you are lucky the front motors are easier, i suspect that because they are slaves so big chance that they actuate by the merci of the rear motor itself.

I tried to find the message actually commands the required torque to the FDU by the process of elimination with a "CAN bridge" that allows me to block messages I want. I got list of MsgIDs from the CAN DB and kept blocking the messages from the car reaching the FDU; until; DU reported no torque in the MsgID 0x1D5 or a fault was displayed on the dashboard. Surprisingly, there is no message that controls the torque. It only needs the BMS status(0x212), and HVBattVoltAmp(0x132) to not set a fault. I am now wondering how is the torque command coming into the FDU?

[collin80]

Me too, hats off to the guys who created the CAN db from nothing - making sense of seemingly random stream of bits need a different level of commitment and skill.

https://teslaownersonline.com/members/jwardell.1513/ <--- His work is inspiring.

Well, it wasn't all from nothing. Sometimes there are secret ways that the info is gathered that don't entirely involve looking at streams of bits. But, yeah, JWardell has put a lot of time and energy into decoding things and creating databases of signals.

[collin80]

Oh! wow "non-immo" binary is cool. But there is only so much you can do with it. I wonder if there are decompilers that work on the TMS320 MCU used.

Yes, there are. Yes, some of us have done that too. But, it isn't like it spits out

Code: Select all

void CommandMotor(float torque)
{
    DoFancyStuff.powerMotor(torque);
}

Instead you get an insane mish-mash of terrible code that doesn't compile, snakes everywhere, has no comments and no good variable names. Quite often it has no good function names either. It helps to disassemble/decompile firmware but it's still a long uphill climb through barbed wire and gun fire.

[EV_Builder]

Yep, decompilers are not usefull on their own...

Yes, there is a message for the torque request for the FDU by the way its called 'DIS';

Send me an DM with the ID's it spitsout by itself.

[ravikashi]

Hello:

Does any one know the fields of the message ID below?
0x187
0x2D5

They show up on the Party CAN ---> FDU.

[Jack Bauer]

If its any help I can do a capture from my m3 fdu on its own and publish the log. Still has its elon brain intact.....for now

[ravikashi]

If its any help I can do a capture from my m3 fdu on its own and publish the log. Still has its elon brain intact.....for now

There are 2 CAN buses to FDU VehicleCAN and PartyCAN right?
If its not too much work, can you please capture logs from both CAN networks and publish the log?

What beats me is, "What is the primary command input to the FDU to put torque on the wheel?" I blocked 0x118 (this carries the acc pedal position, brake status and immo status among others) and still it does not seem to complain.