Jan 6, 2016
ken830 Do you have the time and/or resources to check if the FPGA code is protected?�
Jan 6, 2016
andrewket I would guess SMS.�
Jan 6, 2016
green1 That may or may not be an issue, with that level of access you may be able to build your own app. or maybe just find a way to lock down software changes (somehow write protect important files, and deny any upgrades?)
In the end, I'm going to want full control of the device I own, but I'm not going to want to give up the daily convenience features to get it.�
Jan 6, 2016
wk057 I'm not sure. In my experience FPGA stuff is nearly impossible to reverse engineer anyway, so probably not going to try. I'm actually reasonably certain I have the FPGA binary, actually, from an update file.
My guess as well... just not sure exactly how that gets handled.
I suppose you could allow it to connect to the VPN for the remote app, and just squash the updater, ssh access, etc. Locking out software updates would be simple. *shrugs*
Just would depend on what the actual goals are. I'm actually considering pretty much replacing the instrument cluster display software with something custom... as a down the road project. Would be pretty simple, overall. Just a matter of interpreting the flood of UDP messages (basically CAN messages) that come from the gateway and CID and displaying them in a useful fashion.
I'm still trying to determine the purpose of the body CAN connection that the IC has connected directly...�
Jan 6, 2016
Dbitter1 My guess is when we get the point of complete pwn3rship, the talent of people like you and the other tech types that gravitate to Tesla vehicles could probably come up with a pretty bad-ass replacement for it. With a LOT more functionality the masses probably would never care about.
As a former nuclear power plant operator, I'm very disappointed I can't see the coolant loops diagnostic screen as my normal display. Would make me... feel more at home in the car.
�
Jan 6, 2016
msnow Perhaps AT commands (since its GSM). That's a known published command set and it supports SMS I think.�
Jan 6, 2016
apacheguy Huh, really? I thought it was done all via SMS since the LTE drops out when the car sleeps.
Edit: Oops, already suggested up thread.
Oh, hell yeah! I'd love to get access to the thermal screen.�
Jan 6, 2016
wk057 Yeah, most of this stuff is pretty benign. If Tesla made a version of this diagnostic mode that was read only (as in, no buttons to push that actually do anything) I don't see what the harm would be... and it would satisfy most.
I'm going to go ahead and go through some of it any take some screenshots. Most of the fields are blank on my bench setup because the rest of the car is "MIA" (actually used in the error codes)... but at least it gives an idea of the type of data available. Some of it is completely broken on my setup, too... unless I play some real CAN logs into the CAN buses. Then stuff pops to life.
Plus there is the panel on the IC (in my photo above) that has a bunch of cool data that would be awesome to activate. Heck, I'd be happy with just that.�
Jan 6, 2016
apacheguy Since you now have an "in" it would be awesome if you could gently hint that read-only diagnostic access would essentially halt all desire to break-in to the software. I honestly can't imagine that there are blackhat hackers out there wanting to root the CID of the Model S. They've got much bigger targets in mind. I really think diagnostic access is a win-win.
Yeah, that widget on the IC is kinda cool. What data actually populates battery temp? I thought the battery had a total of like 16 sensors, so do they all get averaged when reported as pack temp or is one randomly selected?�
Jan 6, 2016
supratachophobia I would really like to see cooling information as well as cooling fan speed and real-time kW usage from pack heater.�
Jan 6, 2016
wk057 I did talk briefly about a "geek mode." Seems there are, rightfully, things with higher priority.
I think the "Battery" one is an average of all of the sensors, and the "Batt Outlet" one is the sensor at the end of the cooling loop. Brick min and max are the lowest and highest individual cell group voltages from the whole pack. BMS is the full pack voltage. All of this gets populated when I play CAN recordings to the power train CAN of my bench setup.
Me too. Lots of data here.
And here is the part where some people will get angry at me for some reason... (maybe because I'm using too much bandwidth?
(Click to get full quality versions)
All shots taken with the screenshot save program the car uses when sending bug reports and such... and a few of them somewhat sanitized to scrub potentially identifying info, obviously, and added my little watermark.
The DOCS tab isn't interesting... just has some images of a few of the manual pages describing the under-hood fuses... nothing important. The APPS tab you see in my earlier photo.
The cool thing is, when I play back CAN data this info is updated in near real-time. This is how everything looks with just the CID and IC connected. I didn't get a shot of the BMS screen since it doesn't work until I play some CAN data and I didn't have that set back up yet.
The CAN tab is awesome. I mean, pretty much EVERYTHING the car does can be monitored from there. There are hundreds... perhaps thousands of variables that can be shown.
There is nothing really secret in these screenshots, so I really don't see any harm in posting them. Enjoy.�
Jan 6, 2016
Cyclone What in the world are "Grasshopper mode" and "Quiet HVAC" ?? I look forward to whatever else you end up learning/sharing. Thank you!�
Jan 6, 2016
Johan
Grasshopper=valet mode�
Jan 7, 2016
kaneda Amazing work, I'm really enjoying reading this thread
I count 18 entries listed in the boot loader sections, beside the obvious ones like BMS, have you identified what & where are the different controllers/ECU are and their fonctions ?
That many different places to tinker with ....�
Jan 7, 2016
andrewket Since the goal is power savings, my guess is the radio/cellular module has a signal line to the CID that changes state upon receiving an SMS to wake it up. This way only the radio module has to stay powered. "Always connected" keeps the CID powered and the VPN up, and energy savings OFF keeps everything powered.
Have you found a way to determine the car's mobile number? It would be interesting to test if the receipt of any SMS causes it to wake up, or only from a specific sender, or if the payload itself has an authenticator.�
Jan 7, 2016
msnow Looks like the mobile number, IMEA, etc are on the MCU screenshot but obfuscated.�
Jan 7, 2016
Johan The IMEI nr is there, but not the phone number... at least when I had a chance to look in my car's diagnostic menu all it said after "Phone number" was: "----"�
Jan 7, 2016
msnow Why block out the data on the screenshot then? Let's see what wk says about it.�
Jan 7, 2016
Johan Here's how it looked in my car:
�
Jan 7, 2016
jaguar36 I'd love to have that Thermal tab as an option to view.
Whats the difference between the Lat/Long and the Nav corrected Lat/Long?�
Jan 7, 2016
scaesare You misspelled "get excited"...
:wink:�
Jan 7, 2016
HankLloydRight My head is exploding with possibilities if we had access to all of this data as read-only via an API or SDK.
Also, what is a "Wheal"??
�
Jan 7, 2016
mmccord So the ability to supercharge is a setting on the car itself? I know this isn't the plan, but in theory someone could root a 40 and turn it into a 60 w/supercharger access?�
Jan 7, 2016
andrewket The working theory has been that primary control of supercharging is a car config option. So yes, if you could root a car you could enable supercharging. However, the superchargers themselves likely maintain a VIN blacklist, so Tesla can still block rogue cars.�
Jan 7, 2016
Johan When I was able to have a look in my car, on firmware 7, they fixed the typo
I'm guessing the config toggle to unlock SC is "Fast Chg Allowed = true".�
Jan 7, 2016
Muzzman1 Here's a couple more with data for reference. At the time I did not realize that it needed to be full screen, and I was already freaking out that I was allowed to see what I was seeing and taking pics to boot, so I never went full screen. Sorry for that!
�
Jan 7, 2016
wk057 Your v7 shot shows those config options for other radars that I was refering to upthread a while back....
The cell does have a "phone number" on mine, but it appears to be too long to be a real phone number...�
Jan 7, 2016
Johan Did you notice in the CAN subsection under DAS (presumably Driver Assistance System) in the myriad of variables reported through the CANbus, presumably from the Mobileye hardware directly? There's a lit of interesting stuff there that would give a lot of insight in to how the AP system is actually doing what it's doing, if you could record all the data live while driving.�
Jan 7, 2016
green1 care to share length and format (and maybe the first 4 digits?)�
Jan 7, 2016
wk057 I forget exactly where I spotted it on mine, but yeah probably somewhere in the CAN data. Keep in mind my bench is v6.1, so only has hidden autopilot type stuff.
15 digits starting with 8823... the cell IP when connected briefly was in the 10.0.0.0/8 range.�
Jan 7, 2016
green1 obviously the 10.0.0.0/8 is private internal, was that the VPN IP, or the connection's IP? (it is possible that the carrier is using carrier grade NAT before it even gets to the VPN)
882 is the international networks country code, this is for devices that are not expected to be tied to a specific country. I'm going to guess that after 8823 the next digit is a 7 (882-37 is AT&T mobility's international networks code) If it's not a 7, I'd really like to know what it is...
So, yes, that does appear to be the cell number, and can probably be used to send it an SMS (+882XXXXXXXXXXXX) though I can't even guess at what the billing structure will be�
Jan 7, 2016
Johan My "Cell sim" starts with 8947 (47 is the country code for Norway, so you're on to something).�
Jan 7, 2016
Carspotter Daily Wk056 - just had this idea - I don't have a clue about the inner workings, but this may help: connect the wifi adapter-antenna - try to connect to your network & find the tesla update server ip, then replace it by port-forwarding and make the car think it's updating to 7.1, but actually update it to your hacked version. Just a thought...
Awesome hacks!�
Jan 7, 2016
msnow I'd be surprised if that number was still provisioned and active from the carrier (AT&T). That would mean some processes broke down. Maybe I should not be surprised.�
Jan 7, 2016
Cyclone It may not be active and provisioned anymore. The info could be the last state of the SIM. Absent a purge or null data being sent to reprogram the SIM, I would imagine it would still think it has its old number and just not connect successfully. In a cell phone with an inactive number, the SIM can remember its last state and trying to use it puts you through the carrier's automated system to reactive service.�
Jan 7, 2016
wk057 My bench SIM is definitely still active. I pinged google a few times before disabling it.�
Jan 7, 2016
lolachampcar Cables arrived today.
The CAN Spec calls out-
Red is optional power to CAN device (from car to DB9 pin 9)
Black is Ground DB9 pin 3
White is CanH DB9 pin 7
Yellow is CanL DB9 pin 2
Ixxat usb-can manual page 7
http://www.ixxat.com/docs/librariesprovider8/default-document-library/products/can-pc-interfaces/usb-to-can-v2-manual-english.pdf?sfvrsn=2
or
CAN Bus Pin Out, and CANopen pinout, with Signal names
WK,
Can you confirm gnd, CanH and CanL on the Tesla side connector?�
Jan 7, 2016
wk057 Cool!
Out and about at the moment but I'll verify when I get back to the house.�
Jan 7, 2016
wk057 Sent PM. It looks like the cables you have are appropriately wired.�
Jan 7, 2016
lolachampcar Agreed.... Nice that they are a direct connection to most existing DB9 based CAN tools. I'll log some data tomorrow then generate a dedicated logger for values of interest.�
Jan 7, 2016
Kalud It is indeed appropriately wired. Its the OVMS Roadster cable and on the Model S its connected (by default) on the powertrain (CAN3)�
Jan 7, 2016
tom66 Wonder if you switch the car to dual motor config if the coolant/thermal diagrams change... hmm�
Jan 7, 2016
apacheguy I'm sure they do for the DU coolant loop.�
Jan 7, 2016
wk057 They don't on my bench, but again this is firmware from what would be early dual motor stuff.�
Jan 7, 2016
wk057 Side note: I usually idle in ##teslamotors on freenode IRC if anyone is ever around and wants to toss some ideas around. Pretty good crew there these days.�
Jan 9, 2016
lolachampcar Cable works right out of the box no modification needed.�
Jan 10, 2016
amund7 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.�
Jan 10, 2016
apacheguy The only problem with such an app is I worry Tesla would block access just like they did with the diagnostic connector. If a CAN based info app were released, we'd need a robust mechanism to ensure Tesla could not simply flip a switch and disable it.�
Jan 10, 2016
msnow I can't imagine a scenario where Tesla would allow owners to modify packets. Huge safety, liability and warranty issues.�
Jan 10, 2016
tinm 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.�
Jan 10, 2016
obrien28 @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.�
Jan 10, 2016
apacheguy Good to know. So the CAN data cannot be encrypted at the ECU level?�
Jan 10, 2016
obrien28 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.�
Jan 10, 2016
lolachampcar 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.�
Jan 10, 2016
msnow 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.�
Jan 10, 2016
lolachampcar 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�
Jan 10, 2016
msnow 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.�
Jan 10, 2016
wk057 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.�
Jan 10, 2016
mmccord Whatever project is more interesting to you than this must be one hell of a project. I look forward to hearing about it.�
Jan 10, 2016
tom66 wk, does Tesla use 29-bit addressing for these messages? I can't think otherwise how they can stick so much distinct data into the bus.�
Jan 10, 2016
andrewket It's a woman.�
Jan 10, 2016
wk057 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.�
Jan 10, 2016
msnow Damn!�
Jan 10, 2016
yak-55 Is that woman 7.0 or woman 7.1 I wonder ...�
Jan 10, 2016
andrewket A tesla driving sim? Hahah awesome.
Edit: upon further inspection, it looks like you picked up another car? Hmm.�
Jan 10, 2016
apacheguy 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!�
Jan 10, 2016
obrien28 @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...�
Jan 10, 2016
rdrcrmatt
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.�
Jan 11, 2016
jrickard 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�
Jan 11, 2016
msnow @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.�
Jan 11, 2016
lolachampcar 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.�
Jan 11, 2016
smac @lolacarchamp, I look forward to the fruits of this endeavour, and would certainly be interested if something concrete is available to purchase.
One question, are you envisaging this to be Model S (/X) specific?�
Jan 11, 2016
jrickard 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�
Jan 11, 2016
TheBlackKnight 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.�
Jan 11, 2016
TheBlackKnight 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.�
Jan 11, 2016
thegruf 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�
Jan 11, 2016
TheBlackKnight 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.�
Jan 11, 2016
Footbag 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.�
Jan 11, 2016
lolachampcar 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.�
Jan 11, 2016
obrien28 @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�
Jan 11, 2016
lolachampcar Likely correct...... I'm simply trying to generate a capability for those here to easily capture targeted data. I just happen to have a hardware platform that allows me to filter messages and arrange data for efficient storage.
That said, if there is already something out there that meets the need, I have no problem standing down. I'll concentrate on doing something just for me as I would prefer not to drag around my netbook and the IXXAT tool every time I want to capture some data.
I've heard of SavvyCAN and will look into further.�
Jan 11, 2016
lolachampcar Just looked at a youtube video demo of SavvyCAN. EVTV is painful to watch at times. The ability to build and use "DBC" (not sure exactly what he was saying) files to display engineering units for logged CAN data is nice provided you have the CAN frame definitions. I suspect most of the work here will be in properly defining the CAN messages.
From my perspective, I'm used to working with the IXXAT tools to capture data and simply write VS utilities to manipulate data as needed. I then move the knowledge over to my hardware such that I log only select data and store in binary when space is a concern or in ASCII text in engineering units when people simply want a txt file off the device (which appears as a simple USB drive). There was no way previous projects would support several hundreds of dollars in hardware which is why the board was originally built.
The above approach also allows for selective data logging at high speeds. For example, very high resolution current/voltage could be logged at or near bus frame rates when current exceeds a pre-determined value. This would allow for accurate acceleration runs to be logged with high frame rates. Add wheel speed and now you have a simple way to capture vehicle performance.
Again, this may not have any application here. Given that I do not write apps for general consumption, I'm just pitching in where I CAN (pun intended).�
Jan 11, 2016
wk057 Yeah, seems like the hard work is decoding the CAN frames into something useful. Performance logging is a goal of mine, for sure.
For example, looking at the Tesla in-dash CAN debugging tool on the bench setup while playing back data from a 0-60 launch is cool. Can see the individual motor powers and torque values and see it shift power from one motor to the other during the launch. However, Tesla's in-dash tool doesn't tell me HOW to decode it or what IDs it is. Still have to work that out by hand. But, I'm able to verify that I have the right data using the bench.�
Jan 11, 2016
int32_t
I'd argue that it is good. It's an intelligently designed protocol with address priority built-in, and doesn't suffer from overloading and unreliability issues like Ethernet simply because things don't talk unless they've got something to say. If a taillight doesn't work, it's not because it dropped off the network (!) ... it's just burnt out. If your computer can't access the 'net, for whatever reason it's been booted off the network. CAN was never intended to stream HD video to the center console, so why should slow bit-rates automatically make CAN "not good?" The protocol fulfills its design requirments. Ethernet fulfills its own requirements, and impeccable reliability doesn't seem to be one of them. Highly reliable should earn CAN some "good," no?�
Jan 11, 2016
XxMFxX :love: subscribing�
Jan 11, 2016
andrewket The wifi in the car is deaf. I installed an access point in the garage it's so bad.�
Jan 11, 2016
HankLloydRight It has trouble staying connected to my wifi hotspot on my iPhone 6s. By "trouble", I mean "almost never".�
Jan 11, 2016
obrien28 @int32_t
I totally agree with you, CAN is simple (though some would say "less" secure) and should probably stay that way for the sake of reliability and speed. The good benchmark I was referring to was more from the perspective of Pentagon level security (which even Ethernet can't boast).
The issue comes once the elite "hacker" crowd gets involved, who, knowing nothing about the needs or reasons of the automotive industry, give talks featuring HACK and TESLA in the same slide, this of course (after some bozo at Forbes blows it out of the water) gets Tesla fans knickers in a bunch because they know even less about the complicated systems that make their vehicle work, so they in turn write posts on TMC freaking out that some Russian guy named Pavel is going to take control of their car from Siberia and asking why Tesla hasn't encrypted, obfuscated and padlocked this so called "CAN bus". Little do they know the layers of security (both physical and digital) that prevent people from tampering with things at the actual bus level, like Tesla's restrictive gateway which is the only link between the in-car CAN and ethernet networks or the CRC and counter bits added to most critical CAN messages. Instead they tell us that we shouldn't look too closely at our own cars because we might let the "magical pixies" out of the computer, or worse yet get kidnapped by Elon's private SWAT team, all of which is utter horse...well you get the idea ;-)
**steps off soapbox**�
Jan 11, 2016
dirkhh Really? Hmm. I can see all four of my own networks from the car in the garage plus half a dozen neighbor's networks. I can connect to my home network when I'm parked out front on the street.�
Jan 11, 2016
andrewket I think you're the first person I've "heard" say nice things about the S's wifi.�
Jan 11, 2016
dirkhh That can't be. I constantly get chastised for being too negative. But seriously - on my Model S 60 (built April/13) the WiFi was iffy. With the car from March 15 I have never had any WiFi problems.�
Jan 11, 2016
wk057 The Model S wifi sucks so bad because the antenna for the wifi is just a little wire that is barely outside the the *back* of the 17" screen near the bottom. So the antenna is buried deep inside the dash, and it's a crappy antenna.
*whistles innocently...*
(yes I know the revision is displayed wrong... hehe)�
Jan 11, 2016
Kalud Wow :scared:�
Jan 11, 2016
zax123 So you managed to upgrade your bench setup?�
Jan 11, 2016
miamibeacher I want a sig red P85D! How do I get one? [emoji12]�
Jan 11, 2016
TheBlackKnight I'm the person who wrote SavvyCAN. The whole reason it exists is to reverse engineer canbus protocols. So, it has lots of features that I wanted while doing reverse engineering. I also wrote the GVRET firmware that runs on EVTVDue and CANDue boards. It is my opinion and hope that these tools are useful for a wide range of canbus work. I've specifically done my best to make the EVTV tools work well enough to operate at the bus rate found on a Tesla canbus such that no filtering is necessary. We routinely capture all traffic as it comes in without missing frames. Technically the hardware and firmware support filtering but I basically never use that capability. It's easier to decide later that you don't want certain messages and filter them in software than it is to find that you needed a certain frame ID and now you don't have it.
If you've got access to IXXAT hardware then chances are the SavvyCAN compatible canbus dongles aren't anything special. However, I'm always willing to add new file formats so if you want to load and save in whatever format your IXXAT tools normally use I'll add it. SavvyCAN is under fairly steady development. Usually it progresses as I find new things I'd like to do. It's cross platform so there are binaries for WIndows, OSX, and Linux. I do the development on Linux primarily.
So, anyway, hello everyone. I've been lurking for a long time in this thread and just haven't gotten around to registering an ID and trying to post until now.�
Jan 11, 2016
S4WRXTTCS I have a May 2015 build, and it's easily one of the most frustrating things about the car.
I've tried everything that I can think of, but nothing works long term. Long term being able to go more than a week with it reconnecting just fine after going for a drive.
I tried putting an extender in the garage, but that didn't work.
I tried putting an extender before the extender, but that didn't work either.
I tried moving the extenders around, but that didn't work either.
I can get the maximum bars, but then when I leave and come back I get 2 bars with it not reconnecting.
Short of giving up, and putting an access point in my garage I have no idea what to do.
I might get so desperate that I get a wifi antenna with the right connector, and ask the service people to stuff it in. Assuming its near the 17inch screen. Why they didn't put it in the mirrors with the other antenna I don't know. I know there are lots of good discussions on the good and bad side of hacking within this thread on hacking. But, to me one of the best hacks that can be done is: Better WIFI.
I wouldn't mind so much if the car would update its firmware. It hasn't done an update since the original V7.0. At least then I wouldn't be so OCD about it.
It doesn't help that in my garage I get close to no cell signal. My phone gives me full strength for wifi, and no bars for cell. My car gives me a bar or two for cell, and no wifi.�
Jan 11, 2016
andrewket I thought it was in the passenger side mirror? And why a sig and not a founder's ?�
Jan 11, 2016
HankLloydRight I'm getting the LTE upgrade next month. Is there some wifi extender antenna I can buy and ask them to plug it into the wifi board replacing the existing antenna? Is that connector accessible during the LTE upgrade?�
Jan 11, 2016
obrien28 I hate to sound like a party pooper guys, but unless you think that your MS wifi issues are somehow related to rooting the Linux center console than might I suggest creating a different thread?�
Jan 11, 2016
S4WRXTTCS It's related to the operations of the center console, and it's sitting on WK057's bench. He is the one who let us know where the antenna was at, and is logically the one to ask what connector it uses (or a picture of it). So we could put a better antenna in its place.
His hacking is about more than rooting the Linux console. In fact I'm here for the CAN bus info, and all the info people have provided. So technically I'm getting in my own way, and aside from this post I'll leave the wifi stuff alone.�
Jan 11, 2016
dirkhh Weird. And here I thought they had just improved it in the 2015 cars... apparently I just got lucky and the little wire that I have is GOOD wire
Shiny. Is this a second car or did you upgrade the first one? Given the way you were talking about "the other project" I'm leaning towards thinking that you found another salvage car (since the insurance companies tend to declare a lot of Teslas complete losses I wouldn't be surprised if they are available at a decent price...).
I'm curious about the mismatched build number, though. That's odd... Hmm. Why would you get that if this car came with 7.0...?�
Jan 11, 2016
MDK I had a similar problem, then I noticed that my car would connect to the access point inside the house when I pulled into the driveway, and stayed connected to it even though the signal dropped so low no data would come through - and despite there being another access point on the same SSID inside the garage.
I created another SSID specific to the garage AP ("Mothership" seemed appropriate) and the car now connects with full signal every time. (reported as 99% signal by the AP)
Putting a dedicated AP rather than an extender will help fix your issue, but Tesla could also fix it with a firmware update by doing a re-scan if the signal drops below a usable level.�
Jan 11, 2016
obrien28 Actually the antenna is not just a short wiring leading from the CID, there is a a real antenna embedded in the passenger side mirror, as documented here and by personal experience. I am aware that wk57 is doing more than just rooting the Linux console, the issue is the half a dozen posts about wifi issues that seemingly don't have anything to do with the CAN bus or ethernet networks, which is of the topic of this thread.
I'm not trying to single you out but I find posts on TMC tend to veer towards superficial issues with the Model S far too often.�
Jan 11, 2016
wk057 There is no connection on the CID for an external WiFi antenna. There are external GSM antennas and a GPS antenna connected. The GSM antennas are in the mirrors.�
Jan 11, 2016
obrien28 I would check again, connector reference #X804 media control unit RF WIFI it leads to the pass side door. What model is the car (dash?) you have on your test bench.�
Jan 11, 2016
S4WRXTTCS According to Undocumented | TeslaTap it's in the mirror. Did it change at some point? My build is 2015 so it's likely in the mirror. I'm pretty sure MDK is correct about the problem I'm experiencing, and it's the only viable solution for me.�
Jan 11, 2016
wk057 I stand corrected. On the PCB the connector is labeled WiFi. On the outside metal the label wasn't legible and I thought it was something else. So the little antenna that is hanging out of the back of the unit must be extra, and is sufficient for picking up my home wifi AP about 20' away from the bench.�
Jan 12, 2016
thegruf
upthread my original question was if WK could identify the gain settings for each the wifi bars on the display. Hopefully not unreasonable given the access he has, clearly lots of other priorities though.
Agree trhe thread should not be derailed by extensive wifi discussions, though even WK got a fragment of help back re identifying a connector and the location of the antenna.
so, WK how about a Model X for your next car?
... and if you can get a pic of a 3 then ... you probably best not print!�
Jan 12, 2016
S4WRXTTCS Is there a separate antenna for bluetooth?
In my own hobby projects I don't even need an antenna to get my AP to connect as long as it's just 10-20ft or so.
- - - Updated - - -
I was trying to keep it more on the technical side of things WK057 could see on his bench, and plus I knew the smart people were watching. So it was kinda like a two for one deal.
But, I can definitely see where you're coming from. Sometimes it's worse than that. Right now in the V7.1 thread they're talking about burger joints.�
Jan 12, 2016
andrewket I have an SSID for my garage for the same reason. It also makes it easier to monitor traffic from the Teslas, and detect things like software updates.�
Jan 12, 2016
Andyw2100 And take-out sushi. Don't leave out the take-out sushi.
If you're in the mood for dessert, the Supercharger thread is talking about donut shops.�
Jan 12, 2016
andrewket I'm a primary contributor to both the burger joint and sushi threads. I find the discussion about firmware and superchargers very distracting.�
Jan 12, 2016
obrien28 And... we are officially off topic folks, I probably should have kept my mouth shut to begin with **facepalm**
@S4WRXTTCS
Glad you can see where I'm coming from, it's hard enough to get a thread that is actually on a technical topic (I saw one yesterday complaining about the feel of the plastic dead pedal), then you throw in trying to actually keep it on topic and you have yourself an uphill battle.
To those reviewing take-away places: I have nothing against burger or sushi places (I really like both) but we do have an off topic sub-forum for this kind of stuff.
@wk057 Glad I could help, I thought antenna locations were common knowledge, given Tesla Taps rundown (which has been out for ages and was pre service manual stuff), learn something new everyday�
Jan 12, 2016
Ingineer WiFi connection on the back of the MCU:
WiFi Antenna found in right mirror:
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.
Wk, the little wire-glob is an external Bluetooth antenna. The early MCUs had the antenna on the PCB INSIDE the metal cage! So some time in 2013, they added that external BT antenna to make it work (!) better.�
Jan 12, 2016
obrien28 @Ingineer Thanks for the picture Phil, where did you procure your bench setup from, a part out or salvage car?�
Jan 12, 2016
jrickard Well yes, that's rather the issue. The dongle doesn't matter as long as it works. Unfortunatelyl, the Tesla does some higher packet loads than like a VOlt or a Leaf so you need something moderately quick. But after that it is a software game. I don't think anything can touch Collin's SavvyCAN effort this side of Vector which well get you to $10,000 worth of software rather quickly.
we just did a little thing for fun that I posted in Batteries and Chargers. Arthur Hebert originally roughed out the pattern in 6F2 listing all the battery voltages and battery temperature sensor data. Collin and I kind of worked out how to do the bit pattern and wrote a very tiny little program to monitor the bus, snag 6F2s, and put ASCII out the USB port with all the battery voltages and temperatures.
You can download the source at http://media3.ev-tv.me/TeslaModelSPackVoltages.ziphttp://media3.ev-tv.me/TeslaModelSPackVoltages.zip�
Jan 12, 2016
wk057 I agree they *could* make things difficult... but I doubt they will. Doing so adds complexity on their end as well. Almost certainly not worth the effort. Also would potentially cause issues with module swaps and such. *shrugs*
As mentioned up-thread a bit, I was definitely a bit off on the WiFi antenna matter. The little wire on the back goes to the WiFi module, which happens to also be the Bluetooth module. Add to that the fact that the metal insert on mine doesn't have readable stamping for camera and wifi. I only knew the camera one was the camera because of the connector. So I'm hoping I wouldn't have been alone in my confusion.
So, I'll note that the image up thread of the IC of a partly dismantled P85D is um... my P85D. hehe.
The CID screenshot of my sweet signature red P85D is my bench running a hacked together copy of the 7.0 firmware copied from my real P85D. The release number is wrong because I didn't change it. Purpose being is that the v6.1 I have on my bench normally is pretty out dated. A lot of the CAN stuff has changed slightly since then, such as the BMS power number scaling and such. So, having the 7.0 diagnostic screen is worthwhile to have working on my bench.
In other news, I won a nice bounty from Tesla's bug bounty program for reporting and detailing an exploit I mentioned briefly earlier in this thread regarding the WiFi module.
- - - Updated - - -
Nice, Jack!
I was working a bit of 6F2, but I hadn't gotten everything situated yet. I knew what data was in which message... it sends 4 cell voltages or 4 temperatures per message, starting with cell 0, then the 32 temperatures. The temperatures are pairs of inlet/outlet temperatures for each module, 2 modules per message. I believe these are physically reversed depending on which side of the pack the module is on, too.�
Jan 12, 2016
Ingineer 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.�
Jan 12, 2016
jrickard Yah. It's 24 messages with four battery voltages in each, followed by 8 with temp sensors. The first byte is an index so you know where in the pack you are.
The other 7bytes are a 56 bit packed array with each value being 13 bits and a trailing flag noting whether it is voltage or temperature. Tesla has this 13-bit thing on the brain. Apparently someone deep in teh company just can't count to 16. They give out about 13. So we have run into a lot of 13 bit numbers.
Jack�
Không có nhận xét nào:
Đăng nhận xét