Kalud
Active Member
It is indeed appropriately wired. Its the OVMS Roadster cable and on the Model S its connected (by default) on the powertrain (CAN3)
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
It is indeed appropriately wired. Its the OVMS Roadster cable and on the Model S its connected (by default) on the powertrain (CAN3)
lolachampcar
Well-Known Member
This is really interesting.
How possible is it to map and decode CAN packs, in order to make a phone app with functionality similar to OBD2 apps like Torque? Meaning, seeing temperatures, wattages and other specs real-time? I'd be more than happy to contribute with android coding, if someone can help me with the hardware and the actual packet decoding.
The next idea would be to intercept and modify packets. I am thinking how cool would it be to plug a CAN 'thing' in between to connectors somewhere in the car, and:
1. Pick up and forward all packets, except
2. Intrepret and adjust the value of certain recognised packets before injecting them to the bus.
That way you could, for instance, adjust the height of the air suspension. I'd like a SLAMMED mode (for parking and low-speed showing off), and a slightly lower low.
How possible is it to map and decode CAN packs, in order to make a phone app with functionality similar to OBD2 apps like Torque? Meaning, seeing temperatures, wattages and other specs real-time? I'd be more than happy to contribute with android coding, if someone can help me with the hardware and the actual packet decoding.
The next idea would be to intercept and modify packets. I am thinking how cool would it be to plug a CAN 'thing' in between to connectors somewhere in the car, and:
1. Pick up and forward all packets, except
2. Intrepret and adjust the value of certain recognised packets before injecting them to the bus.
That way you could, for instance, adjust the height of the air suspension. I'd like a SLAMMED mode (for parking and low-speed showing off), and a slightly lower low.
I can't imagine a scenario where Tesla would allow owners to modify packets. Huge safety, liability and warranty issues.
tinm
2020 Model S LR+ Owner
I noticed in one of the GPS data screens the car knows what the altitude is. I sure wish this were exposed in the normal driving UI somewhere.
@apacheguy and @msnow
There is pretty much no way (short of removing the connector) that Tesla could block access, I have actually seen the wiring of the diagnostic connector in relation to the center console and it's hardwired to all the buses once it comes out of the CID. Unlike ethernet, CAN was designed in the 80's when "cybersecurity" and "DEFCON" weren't even a topic at most automotive firms. In addition, with ethernet if you so much as plug in a connector to a computer you start to have a conversation and your presence is announced, this on top of the various ways that you can lockdown a wired network (which Tesla has decided to do). Not so with the CAN bus, you can almost always send and receive, though the various ECU's can be hardened against message injection, further there is no way to shutdown a device in listen only mode, meaning that while Tesla could make it difficult to inject messages, they can't take away the ability to read what's going on (thats 95% of what most of us want to do anyway).
I am so tired of people assigning Tesla a "god" like omnipotence just because the car has an internet connection, JB and Elon will not rappel down from your ceiling to whisk you off to a detention facility if you decide to tinker with your car, nor should they. As many at the EFF would argue, you have the right to do what you want with property you paid for, especially something which is the second largest investment after your house.
There is pretty much no way (short of removing the connector) that Tesla could block access, I have actually seen the wiring of the diagnostic connector in relation to the center console and it's hardwired to all the buses once it comes out of the CID. Unlike ethernet, CAN was designed in the 80's when "cybersecurity" and "DEFCON" weren't even a topic at most automotive firms. In addition, with ethernet if you so much as plug in a connector to a computer you start to have a conversation and your presence is announced, this on top of the various ways that you can lockdown a wired network (which Tesla has decided to do). Not so with the CAN bus, you can almost always send and receive, though the various ECU's can be hardened against message injection, further there is no way to shutdown a device in listen only mode, meaning that while Tesla could make it difficult to inject messages, they can't take away the ability to read what's going on (thats 95% of what most of us want to do anyway).
I am so tired of people assigning Tesla a "god" like omnipotence just because the car has an internet connection, JB and Elon will not rappel down from your ceiling to whisk you off to a detention facility if you decide to tinker with your car, nor should they. As many at the EFF would argue, you have the right to do what you want with property you paid for, especially something which is the second largest investment after your house.
Last edited:
Encryption? Not easily with the kind of low end hardware and slow data rates that are typical of CAN. It was designed to be fast and cheap, remember the engineering triangle, "good, fast or cheap" pick two, the auto folks weren't thinking this would be a big hacking target so good wasn't on the table. That said, there is a lot more error checking and arbitration that automakers could do to better protect against injection attacks.
Also, you are assuming that Tesla wants to put serious money towards locking out a few curious nerds and in the process have to rewrite millions of line of code, not to mention lag the whole system down with some kind of encryption scheme (most of which are easily broken at this level), see Miller and Valsek's research into the Ford, child's play.
Also, you are assuming that Tesla wants to put serious money towards locking out a few curious nerds and in the process have to rewrite millions of line of code, not to mention lag the whole system down with some kind of encryption scheme (most of which are easily broken at this level), see Miller and Valsek's research into the Ford, child's play.
Last edited:
lolachampcar
Well-Known Member
The automotive world is considering FlexRay which helps to address the issue of non-design resident players entering the network. Luckily, this has yet to really take hold.
As for trying to play man in the middle with CAN, it is a bad idea and it will not achieve some of the desired goals. First, the bad idea part. Functionality critical communication busses in cars should not be messed with. The reasons should be patiently obvious. Second, most critical closed loop control is done at the module level with only high level information and command/control occurring over CAN. Take the suspension example. The suspension module controls per corner ride height. It will accept CAN commands to move to a preset height like high and low. It will also monitor wheel speed sensor CAN data put on the bus by the ABS module so as to make pre-determined decisions about speed related ride height changes. Note that all the work is being done within the suspension module so intercepting and altering messages does not work to achieve a given goal.
On the encryption side, OEMs have moved to encrypting some CAN bus communications. Some manufacturers are now encrypting update data prior to transmitting it over CAN to the car so that CAN sniffers can capture the update but still not have access to the unencrypted binary image of that update.
As for trying to play man in the middle with CAN, it is a bad idea and it will not achieve some of the desired goals. First, the bad idea part. Functionality critical communication busses in cars should not be messed with. The reasons should be patiently obvious. Second, most critical closed loop control is done at the module level with only high level information and command/control occurring over CAN. Take the suspension example. The suspension module controls per corner ride height. It will accept CAN commands to move to a preset height like high and low. It will also monitor wheel speed sensor CAN data put on the bus by the ABS module so as to make pre-determined decisions about speed related ride height changes. Note that all the work is being done within the suspension module so intercepting and altering messages does not work to achieve a given goal.
On the encryption side, OEMs have moved to encrypting some CAN bus communications. Some manufacturers are now encrypting update data prior to transmitting it over CAN to the car so that CAN sniffers can capture the update but still not have access to the unencrypted binary image of that update.
First of all, I never said people shouldn't be able to read the data, I said "MODIFY". I was responding to the second part of the @amund7 post. As @lolachampcar and many others upthread have pointed out that can have unintended consequences not the least of which is some "tinkerer" messing with something on their car that could impact other people from a safety perspective. Also discussed upthread and in many other legal, automotive and other forums is whether you have a right to "do what you want" with the software just because you paid a lot for the car. I'm not going to spend more cycles on that discussion or whether or not it's Tesla's IP because I don't think it's worth repeating and there's varying views on this but you should know that that topic is not a settled issue just because you say it.
lolachampcar
Well-Known Member
msnow,
If you do "go there" on right to modify you should likely touch on Tesla's failure to publish modifications to the Linux core
If you do "go there" on right to modify you should likely touch on Tesla's failure to publish modifications to the Linux core
msnow,
If you do "go there" on right to modify you should likely touch on Tesla's failure to publish modifications to the Linux core
Good point however that's likely a licensing issue if they don't have permission to make mods on the OS and could very well face the same IP arguments.
Been away from this project again a bit with another project having a little more priority. Eventually I'll share the other project, but for now let's stick with this one.
First, Tesla can't stop people from getting on the CAN buses. They're exposed in the diagnostic connector, and they're actual buses not just something hooked to an ethernet switch that can be disabled later. There is literally no way Tesla can, through software, remove access CAN on the diagnostic connectors. That would need to be a hardware change.
Next, I don't think Tesla will bother encrypting any CAN data. There would be a lot of overhead on that for very little gain. Something that 99.9% of their customers couldn't give two craps about, too, so why waste the resources? I believe they CAN do it. Most of the modules are pretty capable I'd think. But it wouldn't be worth it and would probably cause reliability concerns.
That said, Tesla does make *modifying* CAN values pretty tricky. For example, there were some hacks of other cars where people flooded the CAN bus with stuff to make it do certain things. That wouldn't work nearly as easily on a Model S even with access to the CAN bus. First, most of Tesla's important CAN messages, especially ones that control things, include an extra checksum. Then, they include a counter to ensure messages are received in order. Then on top of that, on more important stuff, they include a nonce that further obfuscates the checksum and such. I haven't figured out the checksum, seems non-standard. So, if I were to do some kind of CAN attack I'd have to log hundreds of thousands of packets into a table and pull from it in order to even attempt something which would likely only be successful at most for a few packets (maybe 0.1s) before the real packets took hold again. Just speculation there, but it wouldn't even be worth trying.
MITM attacks on CAN devices are pretty useless too, for reasons @lolachampcar already explained, and others.
But, back to the project at hand, reading and deciphering CAN data isn't too much of an issue. Just tedious figuring out what everything is.
So far I've nailed down things like battery pack voltage, current, vehicle speed, cruise settings, pack temperature, individual cell group voltages, individual battery module temperatures, throttle position, and some other misc stuff. That's probably 0.01% of the data available on CAN3 alone. lol. Granted a lot of that data no one probably cares about.. I don't particularly think an owner needs the 32-bit checksum of the firmware on the fast charger control module displayed anywhere, for example... but that info is on the bus a few times per second.
There are definitely some variations in the messages between firmware versions and vehicle configuration, though. So, going to take some time to get all of those right, and will certainly require updating down the road if anything changes. Any tools made for the purpose will need to keep that in mind. An example being that on the P85 the pack current is reported with no offset. On the P85D it's reported with an offset of -1000A. So, decoding the P85D data using the P85 method makes it look like the car is in super regen most of the time, and vice versa P85D data would make make a P85 look like it's pegging the power meter even in regen. lol.
First, Tesla can't stop people from getting on the CAN buses. They're exposed in the diagnostic connector, and they're actual buses not just something hooked to an ethernet switch that can be disabled later. There is literally no way Tesla can, through software, remove access CAN on the diagnostic connectors. That would need to be a hardware change.
Next, I don't think Tesla will bother encrypting any CAN data. There would be a lot of overhead on that for very little gain. Something that 99.9% of their customers couldn't give two craps about, too, so why waste the resources? I believe they CAN do it. Most of the modules are pretty capable I'd think. But it wouldn't be worth it and would probably cause reliability concerns.
That said, Tesla does make *modifying* CAN values pretty tricky. For example, there were some hacks of other cars where people flooded the CAN bus with stuff to make it do certain things. That wouldn't work nearly as easily on a Model S even with access to the CAN bus. First, most of Tesla's important CAN messages, especially ones that control things, include an extra checksum. Then, they include a counter to ensure messages are received in order. Then on top of that, on more important stuff, they include a nonce that further obfuscates the checksum and such. I haven't figured out the checksum, seems non-standard. So, if I were to do some kind of CAN attack I'd have to log hundreds of thousands of packets into a table and pull from it in order to even attempt something which would likely only be successful at most for a few packets (maybe 0.1s) before the real packets took hold again. Just speculation there, but it wouldn't even be worth trying.
MITM attacks on CAN devices are pretty useless too, for reasons @lolachampcar already explained, and others.
But, back to the project at hand, reading and deciphering CAN data isn't too much of an issue. Just tedious figuring out what everything is.
So far I've nailed down things like battery pack voltage, current, vehicle speed, cruise settings, pack temperature, individual cell group voltages, individual battery module temperatures, throttle position, and some other misc stuff. That's probably 0.01% of the data available on CAN3 alone. lol. Granted a lot of that data no one probably cares about.. I don't particularly think an owner needs the 32-bit checksum of the firmware on the fast charger control module displayed anywhere, for example... but that info is on the bus a few times per second.
There are definitely some variations in the messages between firmware versions and vehicle configuration, though. So, going to take some time to get all of those right, and will certainly require updating down the road if anything changes. Any tools made for the purpose will need to keep that in mind. An example being that on the P85 the pack current is reported with no offset. On the P85D it's reported with an offset of -1000A. So, decoding the P85D data using the P85 method makes it look like the car is in super regen most of the time, and vice versa P85D data would make make a P85 look like it's pegging the power meter even in regen. lol.
