Whatever project is more interesting to you than this must be one hell of a project. I look forward to hearing about it.
It's a woman.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
It's a woman.
Whatever project is more interesting to you than this must be one hell of a project. I look forward to hearing about it.
Guess I can tease.
- - - Updated - - -
They do some addressing inside the 8-byte data. For example, the individual pack cell group voltages are all in one CAN ID.
Can't be, since my wife swears my projects get more attention than her. lol.
Guess I can tease.
- - - Updated - - -
They do some addressing inside the 8-byte data. For example, the individual pack cell group voltages are all in one CAN ID.
Can't be, since my wife swears my projects get more attention than her. lol.
Damn!
Cool. Basically all I'm interested is in variables related to the drivetrain. Maybe a few more than the ones you hit on to show thermal controller state (passive cooling, active heating, etc.) and that would just about wrap up my interest in the diagnostic screens.
@lola, @wk - Any plans to release a guide in the coming months to show the rest of us how to sniff and parse CAN traffic? That would be awesome!
@apacheguy
Not to toot my own horn but I put together probably one of the first public guides on what connectors to buy and how to connect to buses. Available on instructables here.
In the meantime, I've been doing a lot of behind the scenes work that I haven't shared yet, soon...
Not to toot my own horn but I put together probably one of the first public guides on what connectors to buy and how to connect to buses. Available on instructables here.
In the meantime, I've been doing a lot of behind the scenes work that I haven't shared yet, soon...
Last edited:
Most cell phones have a RFC1918 address on their radios for data. The cell phone companies don't have enough IPs for everyone to have one so they do NAT like a home router does, but on a larger scale. It's a NAT pool of addresses.
jrickard
Member
This is causing an awful lot of hand wringing here guys. But you're frothing at nothing here. Sure, you should take it very seriously in the matter of people braking into your car over the wireless or via the Tesla computer system. Those kinds of vulnerabilities can cause damage and there are always those out their willing to pee in the pool.
That's kind of a different matter than taking abunch of salvage parts and wiring it up on your own bench to see what's inside. And gaining root on the Linux side, or decoding the CAN messages used to control the various systems in the car is useful, interesting, and fun. And totally harmless.
Elon Musk himself made a careful delineation between "network security" and securing a car (or by his example a computer) that someone has physical access to. He's done plenty of coding in his rise to the top and is completely aware of the issues. It's just not possible to secure hardware that you can poke with probes. So nobody does much to secure it.
Connections via wireless or ethernet connected to the public Internet are ALL of the issues of security. Diagnostics panels and CAN bus message IDs just are NOT. I'm sorry. They aren't and never will be - except to the totally stoned uninitiated and talking heads on TV.
Jason is doing some great work and we're all learning much about our cars in the process. The hand wringers worried over this simply don't understand the issues. It is not what someone can do to your car if they break in via wireless, GSM, or perhaps some sort of localized FOB/wireless combination, it's that they can break in. That's where the focus has to be on security. Tesla has no interest in your reading your cell voltages on the CAN bus. But they would be all ears if there is some weakness with the FOB action, or over the GSM link, or via their computer system that has access to the cars for rebooting and flashing new firmware. No, not flashing it with a couple of thousand dollars worth of test equipment in piece on your bench. Doing it remotely via the network.
Jack Rickard
@jrickard, I don't blame you for not reading through all ~350 posts on this thread but no one is "wringing their hands" over wk's physical access to the IC and MCU on his workbench. There was discussion about remote access which, as you point out, would be a concern but that's not what is going on here (as far as I know).
The second issue was about making changes to the software on a live car not on a bench. The question on that aspect is a bit broader because it includes safety and perhaps legal issues.
The second issue was about making changes to the software on a live car not on a bench. The question on that aspect is a bit broader because it includes safety and perhaps legal issues.
lolachampcar
Well-Known Member
I've got a bunch of designs and tools left over from a past life looking at automotive ECUs. One of them is a small dongle design that was used for, among other things, reflashing tasks. It has CAN, can run off vehicle or USB power and represents itself as a mass storage class device for pulling off data. I'm working in support of wk's efforts to generate a small, inexpensive data logging capability. The device has a reasonably powerful processor and some on board flash. The goal would be to generate a logging capability that filters and discriminates so as to generate useful data files without the need for lots of post processing.
More will be coming via WK.
More will be coming via WK.
jrickard
Member
I guess you would call it a checksum or CRC in a way. Tesla does some very tricky stuff that initially looks like it is trying to prevent tampering. I guess with some further experience with it, I think it's more a data integrity thing applied to a number of messages that are kind of critical. CAN already has a pretty robust CRC applied at the hardware level that the software guys never see. Forgetting about it, you tend to try to harden a bit anyway when it is something important with the drive train.
Basically, they like to put little software clocks or counters into CAN messages, along with the data, and then CRC that. And so the CRC byte is one series in one mode, but a different one in a different mode. And they tend to turn modes on with short bursts of these packets, which otherwise are regularly transmitted but don't do very much. So the commands for Park for example, aren't static. It sends about 13-15 packets wiht the mode change, detects an acceptance from the inverter, and then goes back to the normal state. But any change generates a CRC that appears kind of tricky because of a simple clock counter in the message indexing each frame. So you're transmitting the same data, but the crc changes because of the usually four bit clock that clicks along with each frame.
Getting over the paranoia, I don't think it has anything to do with security in the fact that someone might "break in" it's just a data integrity thing. But it does make it nearly impossible to inject change frames into the string of existing ones and get any response at all. We're just kind of focused on it in getting control of the Drive Unit for use in other cars - not in doing anything with it IN a Tesla. Our challenge is to get it to work WITHOUT a Tesla wrapped around it.
Jack Rickard
TheBlackKnight
Member
I think it's worth noting that EVTV does already sell a device that works with the Tesla Model S diag connector and also has free firmware and PC based software to go along with it:
EVTV Motor Verks Store: SavvyCAN for Tesla Model S, CAN Tools, TeslaCANKit
It is, perhaps, a bit more expensive than some other options but you get what you pay for. If it makes anyone feel better, just assume the price includes the software.
That specific device is Tesla specific but EVTV also sells the EVTVDue and CANDue 2.0. Both of those are generic. The CANDue 2.0 has two CAN buses and can log directly to a microSD card.
TheBlackKnight
Member
I've thought about writing up an accessible guide for how to do this. I know that opengarages is coming out with a new version of their manual soon: http://opengarages.org/handbook/
There is a lot that goes into this whole thing. It goes in layers. First you need the proper hardware. Then you need to capture a lot of data. Then you have to figure out how to interpret that data. It all takes a lot of time. Proper hardware and software is the foundation for the whole thing. Then, a background in discrete mathematics can't hurt.
thegruf
Active Member
Great thread.
@WK - maybe I could request a small piece of info please.
Are you able to look out the signal strength values for each of the wifi "bars" on the display?
I am convinced I have a duff wifi antenna or something, as at home I barely get one bar on the car when I get full strength on the phone.
It would be great if I could compare the "bars" against what dB signal strength my phone app is telling me.
tia
@WK - maybe I could request a small piece of info please.
Are you able to look out the signal strength values for each of the wifi "bars" on the display?
I am convinced I have a duff wifi antenna or something, as at home I barely get one bar on the car when I get full strength on the phone.
It would be great if I could compare the "bars" against what dB signal strength my phone app is telling me.
tia
TheBlackKnight
Member
I have figured out the checksum byte. I don't think it was anything standard. It is possible to capture many packets and build up a table but that always feels lame to me. It's better if you can figure out a suitable algorithm to calculate it. The bonus there is that programmers are lazy and tend to use the same algorithm everywhere so once you crack it in one place you can use it all over. I know for a fact that Nissan did this with the Leaf. Many frames use the same algorithm for the security byte / nonce / checksum / whatever you want to call it. Also, revisit the counter and replay idea. If you see traffic on the bus you can replay but one ahead on the counter. Now your frame shows up as the proper next frame. When the car tries to send its normal frame it gets rejected for being a dupe of the frame you sent. Now you are in control so long as you transmit fast enough to always be ahead of the normal sending from the real source. It is possible to do a MITM attack while the original device is also still transmitting but YMMV.
No... Not really useless. They can be plenty effective. But, for best results a MITM attack requires that you cut the can wires and place a device in between. Still, the reasons given for not doing it are valid. It could mess something up, the things you want to do might not even be exposed on the bus, etc. But, it can work.
Some day we've all got to sit down, sing Kumbaya, hold hands, and share our findings. It's getting a little weird. I know of like 4 different teams of people who are decoding Tesla Model S canbus frames and none of them are sharing that much with the others. I have most all of the things you mentioned but it's always good to get verification.
Just wanted to share that I have the same 'problem'... 1 bar in car, full strength on phone. Doesn't seem to actually be causing any issues.
lolachampcar
Well-Known Member
smac,
I'll be doing the stuff "in support of wk".... Not sure exactly what the targets will be as far as logged data but the hardware will be a simple 3" square bit with the Tesla diag cable one one side and a USB connector on the other. Any monies at all related to the project will be solely to cover costs. This is not a retail thing and will be done only to support forum members (kinda like the key fob thing I did).
Hardware will be based on one of the boards I did for this tuner-
EFIdude
I have a dozen or so of the boards around here and just need to order some cables.
I'll be doing the stuff "in support of wk".... Not sure exactly what the targets will be as far as logged data but the hardware will be a simple 3" square bit with the Tesla diag cable one one side and a USB connector on the other. Any monies at all related to the project will be solely to cover costs. This is not a retail thing and will be done only to support forum members (kinda like the key fob thing I did).
Hardware will be based on one of the boards I did for this tuner-
EFIdude
I have a dozen or so of the boards around here and just need to order some cables.
@lolachampcar
Would it not be better to reuse the OVMS hardware (that has internet connectivity)? or is this dongle just for reverse engineering. It seems like everybody goes about creating a new device every week when there is already a plethora of hardware options that can handle the bus load: teensy 3.1, CANdue, CANtact, OVMS, or the Kvaser Leaf Light on the professional end of things (I got mine for a good deal on eBay). As many in silicon valley would say, this is a software problem, everything that's out there is either closed source, garbage, or both. With the notable exception of SavvyCAN by Collin Kidder (free, cross platform, and fairly capable) and perhaps Busmaster, there aren't many good pieces of software out there, that's really where the effort is needed.
Just my 2cents
Would it not be better to reuse the OVMS hardware (that has internet connectivity)? or is this dongle just for reverse engineering. It seems like everybody goes about creating a new device every week when there is already a plethora of hardware options that can handle the bus load: teensy 3.1, CANdue, CANtact, OVMS, or the Kvaser Leaf Light on the professional end of things (I got mine for a good deal on eBay). As many in silicon valley would say, this is a software problem, everything that's out there is either closed source, garbage, or both. With the notable exception of SavvyCAN by Collin Kidder (free, cross platform, and fairly capable) and perhaps Busmaster, there aren't many good pieces of software out there, that's really where the effort is needed.
Just my 2cents
