openinverter forum

For anyone who has tried reverse engineering Tesla parts, one of the biggest headaches is CAN messages changing from one revision of firmware to another.

I wanted to try flashing more uniform firmware on devices to reduce some of those headaches. Thankfully, all of the Tesla ECUs support flashing updates via UDS, which is a fairly standard way for CAN connected devices to do updates. The biggest challenge is knowing how to unlock an ECU after it poses an access challenge.

I looked up some security research papers and found the following: every Tesla CAN ECU (not the car computer, autopilot) seems to do the same thing. When you do a UDS access request, it responds with the exact same seed / challenge:
The key is then each byte ^ 0x35

I tested this with my PCS and found that it was able unlock the ECU. Of course, Tesla had disabled reading the firmware, but this does give us an option to overwrite it with new firmware.

While I don't have any firmware myself, would anyone that does have access to Tesla firmware files be interested in giving this a shot? I can share an firmware update script for anyone interested in trying it out.

Okay, you've written a script. How do you decide what exactly to flash?

AMP3R wrote: ↑Tue Apr 07, 2026 2:13 pm Okay, you've written a script. How do you decide what exactly to flash?

I remotely connected to a 2017 Tesla Model 3 that's been updated to the latest firmware from Tesla. I used the secure shell in service mode to see what firmware options were already downloaded onto it. In the `deploy/seed_artifacts_v2` folder, there's sub-folders for each ECU that has different revision folders with the binaries

I'll use the PCS as an example. I'd flash the pcs/610/<binary file.hex> to the TMS320. The address at which I write the firmware to it is dependent on each ECU. Luckily, Tesla has used a lot of TMS320F28377 chips throughout the car so the memory map is the same. As long as you have the correct address in it, it shouldn't be too crazy to write the appropriate firmware to the correct spot.

Does that answer the question? I'm assuming this is what you did with the motor inverter to update it to the latest version from Tesla so that you can control it entirely over CAN instead of the accelerator pedal input you needed from previous revisions of the firmware.

If someone who has gotten access to those firmware binaries can test it out, it might validate a solution to homogenizing some of the reverse engineering work

Okay, let's say you flash the inverter. What next? All the interest lies in the immobilizer.

AMP3R wrote: ↑Tue Apr 07, 2026 7:47 pm Okay, let's say you flash the inverter. What next? All the interest lies in the immobilizer.

At least for now, I'm not particularly interested in that. The PCS is the main thing I'd like to get going since it's a commodity piece of hardware for charging + DCDC conversion but has big variances in the CAN messaging. I'm sure there's other Model 3 parts like the BMS + charge ports for which this could be useful too.

But to answer your question, you can probably remove the immobilizer pairing from the firmware itself. You can use Ghidra or any other RE tool to patch that out of the firmware (or at least learn about how the security challenge mechanism works and respond correctly). I've had to do this before to make parts serviceable for reuse in PEVs.