Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Let the hacking begin... (Model S parts on the bench)

This site may earn commission on affiliate links.
Besides that, I'd also like to point out that Tesla could obviate all our decoding efforts with one firmware release. They could add some encryption, or even just scramble the CAN frames every software release so that we'd have to spend a lot of time re-mapping them.

This is unlike any CAN project I've ever attempted, so unless you have an unsupported (read: no updates) car, then you could find all our efforts wasted once they decide to make it hard for us. Not trying to say we shouldn't do it, but be warned.

It is always their option to change things at any point in time. In fact, it seems like they do tweak the communications protocols every so often. I've seen cars that send different IDs than other cars, data that has different offset or scaling factor, etc. But, it is isn't in their best interests to change things too much too often. They, after all, need to keep all their tools in sync and that gets difficult if they keep changing the protocols every month. As far as encryption goes: it's not really that easy to do reliably and securely and complicates their diagnostic tools. It isn't very likely they'd want to waste the time to do it. I wouldn't think they'd care whether we can *see* the traffic. There isn't much harm in that. The only thing they care about is people modifying the traffic. They took steps to mitigate this problem by moving many things outside the reach of CAN. For instance, the accelerator pedal is directly hard wired to the motor controller. So, your only hope to remote control the inverter with canbus would be to take over the cruise control system. And, they have special security bytes in the messages for things they care about. The security byte has a non-standard way of being calculated so you either have to build a table or reverse engineer the algorithm used to calculate that byte. If they wanted more security they could just use two security bytes or actually spend more than 30 seconds creating their security byte algorithm. It has been my experience that most of these sort of algorithms are not that tricky. I was able to track the way that security bytes are calculated on a tesla model s in a similar way to how I did it on a Coda UQM motor controller so the techniques used weren't that different. Granted, if they did a little digging they could have found ways to make it a lot harder to do. Presumably the security bytes are just a flimsy lock so that they can say they locked the doors. I wouldn't imagine they'll care much about any of this until somebody hacks a car and causes the auto pilot to drive into a bus load of orphans headed to volunteer at a soup kitchen. Since that hasn't happened I think we're not even a blip on the radar.

- - - Updated - - -

All they'd have to do is encrypt some of the critical frames. Even something relatively simple that a low-power microcontroller can handle, such as DES.

Module swaps always require a firmware update anyway, so as long as the bootloader and flashing process are consistent, then swapping modules isn't going to cause any issues. Swap the module, then update the firmware.

DES is the obvious choice because it can be used in block mode with 64 bit blocks (perfect! there are 64 bits in a message!) But, it's also LONG since been cracked wide open and canbus traffic tends to have low entropy. It'd take all of a few hours for a modern PC to find the encryption key used. Better algorithms like AES use 128 bit blocks and that would just complicate things too much.

Also, the big issue - a given input block yields a specific output block. CAN tends to have lots of duplicate frames so counter durations and such can easily be found. Also, lots of CAN frames tend to have plenty of zeros - especially on start up. If you know something about the plain text it becomes trivial to reverse the key by brute force. No, they wouldn't bother with encryption because it wouldn't really solve anything. There are some cases where I could see encryption being used - firmware updates for instance. But, encrypting everything seems kind of pointless to me.
 
  • Informative
Reactions: NiallDarwin
DES is the obvious choice because it can be used in block mode with 64 bit blocks (perfect! there are 64 bits in a message!) But, it's also LONG since been cracked wide open and canbus traffic tends to have low entropy. It'd take all of a few hours for a modern PC to find the encryption key used. Better algorithms like AES use 128 bit blocks and that would just complicate things too much.

Also, the big issue - a given input block yields a specific output block. CAN tends to have lots of duplicate frames so counter durations and such can easily be found. Also, lots of CAN frames tend to have plenty of zeros - especially on start up. If you know something about the plain text it becomes trivial to reverse the key by brute force. No, they wouldn't bother with encryption because it wouldn't really solve anything. There are some cases where I could see encryption being used - firmware updates for instance. But, encrypting everything seems kind of pointless to me.
They could use a rolling key based on a hash of a time value and something unique, such as the VIN. If the key rolled like this, real-time cracking would be much harder. Incidentally, some Pay TV systems use Tripe-DES with a rolling key generated by a seeded PRNG.

All this is crackable of course, but it's the time it takes. They could change the seeding algo with each update, then we'd have to dig around in the code and figure it out. This kind of "electronic warfare" has existed for years in pay TV. It's not bulletproof by any means, but it definitely is effective.
 
Besides that, I'd also like to point out that Tesla could obviate all our decoding efforts with one firmware release. They could add some encryption, or even just scramble the CAN frames every software release so that we'd have to spend a lot of time re-mapping them.

^This is what I was afraid of.

All of that trouble to keep people from seeing pack, motor, etc. data fly across the CAN bus. Hardly seems worth the trouble.

Perhaps also true, but Tesla has a track record of blocking attempts to access this data. If they didn't have any issue with us seeing this data, why would they not simply create a second PIN for the diagnostic screens that enables a read-only view? Something like that should take a few minutes to program I would think.
 
Was the bounty enough to buy the 90 battery pack for your home?

Not quite that much. hehe.

Congrats to you and well done Tesla, especially knowing what you are doing and recognizing the value of your work, unofficial or otherwise.

The folks I've spoken to at Tesla since starting this thread and the project have been great and are actively interested in how things go and if any issues are found. Kudos.

All of that trouble to keep people from seeing pack, motor, etc. data fly across the CAN bus. Hardly seems worth the trouble.

Yeah, seems like even if it did happen it would be super low priority.

However, I can understand a bit of a shady reason why they might not want that data out there. For example, I've been speaking with a 60 owner who has something like 12% range loss after a year or so of very normal driving, no supercharging, etc. After investigating service says it's "normal." Seems a bit not normal to me, but he has no way to actually verify that everything is normal. Maybe a brick is bad in his pack and is sagging the whole pack to not charge fully, or any other number of things. Would be simple to see at a glance what the deal was looking at some diagnostic info. What happens if it turns out something is obviously wrong after Tesla said it's "normal"? *shrugs* If nothing is out of whack, then no harm in looking. If it is, then maybe they wouldn't say so as to not have to fix the battery? Who knows.

Not saying they are doing anything like this or plan to. Just saying it can't hurt the customer if they can lay eyes on the information on their own, and it has the added benefit of keeping Tesla honest in cases like the above. Personally I'd take a bit of offense to them encrypting read-only data like voltages and such. Would throw up the "we have something to hide" red flag in my head pretty quickly.

- - - Updated - - -

If they didn't have any issue with us seeing this data, why would they not simply create a second PIN for the diagnostic screens that enables a read-only view? Something like that should take a few minutes to program I would think.

^ This. Keep in mind, the vast majority of the diagnostic screen is read-only anyway. There are only a couple of tabs that have anything that can actually do anything from there, which I'm sure less than 5 lines of code could handle disabling in a user mode.
 
  • Informative
Reactions: NiallDarwin
Not a lot of people can understand that data. Would it not potentially open the door to regular owners thinking they had problems when they don't. I agree with transparency but I think I can understand why they don't.
 
Not a lot of people can understand that data. Would it not potentially open the door to regular owners thinking they had problems when they don't. I agree with transparency but I think I can understand why they don't.


Perhaps. But if it requires a PIN (buried within the service manual) even as simple as 1234 then the average Joe isn't going to go poking around or even know it exists. Basically, only those who frequent TMC (like 5% of owners, or less?) will be spending time on the screens.
 
Even my 2002 BMW M5 has a "check control" mode that takes several steps to enable (using parts of the unique VIN), but once enabled, I can read all sorts of sensor data -- voltages, pressures, tank levels, counters, etc. It was phenomenally helpful to debug a fuel tank pump problem in my car (it has two gas tanks, L+R, and when one gets low, it's supposed to pump gas into the other tank.. I was running out of fuel with 1/2 a tank!). I can even start a full "lights and gauges" test that lights up everything like christmas.

Tesla shouldn't be 15 years behind on this stuff.
 
Even my 2002 BMW M5 has a "check control" mode that takes several steps to enable (using parts of the unique VIN), but once enabled, I can read all sorts of sensor data -- voltages, pressures, tank levels, counters, etc. It was phenomenally helpful to debug a fuel tank pump problem in my car (it has two gas tanks, L+R, and when one gets low, it's supposed to pump gas into the other tank.. I was running out of fuel with 1/2 a tank!). I can even start a full "lights and gauges" test that lights up everything like christmas.

Tesla shouldn't be 15 years behind on this stuff.
I agree. But I think Tesla is very sensitive to negative PR they could get from this. I think a lot of what we diagnose as "incompetent communication" they internally view as "avoiding possible problems".
It's disappointing. I'd much rather have access to the data. But then, I'm a data geek.
 
  • Like
Reactions: NiallDarwin
I agree. But I think Tesla is very sensitive to negative PR they could get from this. I think a lot of what we diagnose as "incompetent communication" they internally view as "avoiding possible problems".

Absolutely. They're terrified of bad PR and pretty much every stupid sounding decision they make comes back to this. Can't access data that would be useful? Well, someone might misinterpret the data and do something dumb or complain. Can't fix the car yourself? Well, you might do it wrong and crash and get on the news. They seem overly concerned with this. Knife companies don't seem to stay up at night worrying whether I'll get a brilliant drunk idea and run around naked with a knife while doing somersaults. People do stupid things. Sometimes they do those dumb things with cars. Pretty well every car company has negative PR. It's part of life. Tesla can at least rest easy that they never sat on an ignition switch problem for a decade while people died. In my opinion their paranoia about negative PR actually makes the problem worse. They're building themselves up on an impossible pedestal and some day they are going to get knocked down. The higher the rise the worse the fall. It would be better if they quit being so sensitive.
 
  • Love
Reactions: NiallDarwin
Not a lot of people can understand that data. Would it not potentially open the door to regular owners thinking they had problems when they don't. I agree with transparency but I think I can understand why they don't.


Exactly what I was thinking. It could cause more problems than it's worth: "Tesla must replace my battery pack because one module is 0.001V out!"

... and the media: "Gas tanks are better than batteries because they don't go out of balance."

Potentially dangerous information. Still (if I had a Tesla) I'd want to be able to see voltage and temperature info too.
 
"Gas tanks are better than batteries because they don't go out of balance."

Potentially dangerous information.

Heh. Back when I was even younger (ridikulus!) and even stupider (believe it or not!) than I am now, it could get downright interesting to feel the pickup truck yawing and swaying and lurching from the sloshing fuel in my 250-gallon un-baffled auxiliary tank. Oh yeah - ask me about imbalance!

(How did that story get on this thread? Sorry for the hijack, but hope you enjoyed it....)