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

My adventures in gaining control of my car

This site may earn commission on affiliate links.
Awesome work, @green1 . I'm about to sell my 85D and take delivery of a P100D. As soon as I get the new car, I'm going to follow you on this journey. Hopefully soon, I'll be able to collaborate with ya'll on moving forward even further.

A couple of questions and thoughts, if you don't mind:
1) I'm assuming the IC <-> CID traffic isn't encrypted? It seems like an SSL cert with client auth would be an easy patch for this exploit. I'm surprised they haven't done so already.
2) My understanding from defcon was that the CID posts the access token to the IC every 24 hours. Also, that token is a password for one of the users on the CID, which has sudoers access. I'm assuming you know that and so I'm curious why you haven't used that to escalate to root. Is the token not sent cleartext or something? In any case, it sounds like if you can get root to the IC, that will be a quick jump over to root on the CID.
3) As mentioned, I'm waiting to get my car before I'll be able to sniff traffic, but I haven't quite bridged the gap in my mind between packet sniffing and collecting the factory mode REST/JSON command. It's not like the IC ever sends that to the CID. Maybe this will become obvious once I have wireshark up and running. Were you maybe able to get the values of the gui_* constants somehow so you could generate the correct message ids for things like factory mode?
4) Do you know if the UDP knock is still a valid way of accessing the VLAN from the "mystery cable"? This would definitely be a less invasive method compared to a switch behind the dash.
5) I'm assuming you just hacked up a 12v lighter adapter and used it to power a network switch that accepts 12v?

Thanks for posting everything. It's inspiring!
 
@cryptyk - your P100D will come with 8.x. Tesla has apparently disabled the setting of variables over the VAPI without prior authentication. I should be able to help you with the endpoint you will need to hit for factory mode, but I don't think it will work.

Great point about the access token. I had the same thought. Apparently it is encrypted.

The UDP packet AFAIK is still valid. However it is a salted hashed access token sent to the broadcast address so without the token you won't get anywhere.
 
  • Informative
Reactions: davidc18
@apacheguy
Thanks - Much appreciated!
When you say the session needs to be authd: I assumed that as long as I'm on the network between the IC and CID, that the IC would keep the session authd every < 30 seconds so that the CID will accept commands. Is that not the case?

In other words, if I inject a VAPI command on the network between the IC and CID, how does the CID know that it's not from the authd IC? Are those commands signed or something?
 
@neroden, I failed to read your post because I ran into a personal attack and moved it to snippiness. Please try again.

That's unfortunate, it was full of good information.

Here's the text with what appears to be the offending "personal attacks" omitted.

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)"


The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
Did you see any compilation configuration files? Linux has insanely large numbers of configuration options in the compilation scripts. Yes, they need to disclose which ones they used.

1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

This is basic stuff. I've bought a lot of hardware with embedded software. An example is my router. I got a cute little one page piece of paper with the GPL and a copyright notice, a written offer to mail source code for the GPL-covered components on request, and the address of a website (produced by the manufacturer) where I can download the source code (so that nobody ever requests the mailing). If anyone does request the mailing, someone at the manufacturer simply downloads that section of the website onto a CD and mails it. I can show you these for many products from Intel, Netgear, etc. It's not difficult. It's not expensive. It's a sign of *incompetence* that Tesla hasn't done it.

And yes, if they don't fix this, they will get sued. Nobody in the free software business likes to sue, they'd nearly all rather have voluntary compliance, so it'll take a long time. But it'll happen.
 
  • Like
Reactions: S4WRXTTCS
@cryptyk k I think you're being given some erroneous information here.

While I haven't tried any of this on 8.x (because I refuse to downgrade) my understanding is that Tesla has not blocked setting variables on 8.x, what they have done is removed a few of my favourites (the ability to removed AP restrictions). My theory is that now that all the "important" people are likely on AP2.0 cars running Full Self Driving Alpha versions, there is no longer a need to maintain the ability to remove the restrictions on normal AP on our cars. (I'm 100% convinced that the only reason the switches existed previously was so that Elon and friends wouldn't have to live with the restrictions they force down everyone else's throats) They've simply hardcoded the restrictions in now instead of through variables.
What this means is that accessing factory mode (something Tesla still needs to do on the cars) is still available, but un-neutering AP is no longer possible.

1) I'm assuming the IC <-> CID traffic isn't encrypted? It seems like an SSL cert with client auth would be an easy patch for this exploit. I'm surprised they haven't done so already.
The data is unencrypted. There is no good reason to encrypt it. That said, Tesla may do it in the future, but if they do, know that it does NOT increase security in any way, shape, or form, and is 100% part of Tesla's ongoing war on their own paying customers.

2) My understanding from defcon was that the CID posts the access token to the IC every 24 hours. Also, that token is a password for one of the users on the CID, which has sudoers access. I'm assuming you know that and so I'm curious why you haven't used that to escalate to root. Is the token not sent cleartext or something? In any case, it sounds like if you can get root to the IC, that will be a quick jump over to root on the CID.
The information that they presented at defcon is outdated. As they said right in the presentation, many of those attack vectors had already been patched at the time of that presentation. So while yes, the key is shared over the network, there's no way of actually capturing and using it based solely on the information presented there (it's not being sent cleartext)

3) As mentioned, I'm waiting to get my car before I'll be able to sniff traffic, but I haven't quite bridged the gap in my mind between packet sniffing and collecting the factory mode REST/JSON command. It's not like the IC ever sends that to the CID. Maybe this will become obvious once I have wireshark up and running. Were you maybe able to get the values of the gui_* constants somehow so you could generate the correct message ids for things like factory mode?
If you sniff the traffic, and see the variable names in there, and then look at the defcon talk again, you may find something with a familiar looking format to try...

4) Do you know if the UDP knock is still a valid way of accessing the VLAN from the "mystery cable"? This would definitely be a less invasive method compared to a switch behind the dash.
Yes it is, but again, you need the token which you have no way of obtaining to do it. As a result, that method is quite impractical.

5) I'm assuming you just hacked up a 12v lighter adapter and used it to power a network switch that accepts 12v?
For the initial work I didn't bother with a switch at all, I simply disconnected the IC from the CID, connected a computer, sent the command, and then re-connected them. I kept it that way for a few weeks, connecting a computer as needed to issue commands (I did extend the cables down to a more convenient location so I wouldn't have to do the whole dash disassembly each time)

Since that time, I have connected up a 3 port switch and a Raspberry Pi under the dash, these are powered directly from the battery with no lighter adapter. (If putting a switch in, you want to make sure there's no risk of the power coming out while driving because you'll lose communication between the IC and CID) Now whenever I want to make any changes I connect to the Pi wirelessly and tell it to issue the appropriate command. I also have it programmed to issue specific commands at regular intervals.
 
@green1 - I am confused about your earlier post which is what led me to believe the setting of variables is disabled in 8.x. have you since uncovered information that suggests this is not the case?

I do not have root access, only internal network access. That gives the ability to set various variables, but not everything. Changing the images on the screens hasn't been a priority for me though it might be possible at this level.
I have reasonably reliable information that 8.0 would block setting variables without either full root, or diagnostic port access, neither of which I have yet. So 8.0 isn't going to happen yet. (Not that Tesla has offered, so far all they're showing me is the last 7.1)

Additionally, by saying that the token is not sent clear text over the network you are implying that it is encrypted.
 
@green1 - I am confused about your earlier post which is what led me to believe the setting of variables is disabled in 8.x. have you since uncovered information that suggests this is not the case?
My current information is that setting variables is not disabled, however certain variables are no longer there to set (specifically the ones that remove the restrictions on AP)

Additionally, by saying that the token is not sent clear text over the network you are implying that it is encrypted.
That is what I am saying, yes.
 
Found a little car called "Lightning McQueen" in my developer car on the bench.

Would be nice, if Tesla enabled this screen in the actual car GUI..
IMG_6881.JPG
 
Last edited:
I think you can own a private airplane, but MUST have a certified mechanic make repairs and modifications. The Owner is not free to do whatever, but must follow rules and regulations to produce an airworthy plane. The blanket statement "If you can't modify it, you don't really own it." runs against [msnow] point that there are others lives to consider, and the long establish need to have certified mechanics working on certain machines.

Wrong. If you build the airplane you can do whatever you want as long as you call it a " wink ", "EXPERIMENTAL ", airplane. And just for good measure you have to write the word, " EXPERIMENTAL" on the outside.
 
Last edited:
  • Love
Reactions: davidc18
It appears obvious you are in a country with sane wireless services. I assure you, I am not.
"pre-paid" plans here expire after 30 days. The absolute cheapest plan in existence where I live is $15 for those 30 days, that does not include taxes, the hardware, or any data usage.
OP: While I agree wireless plans & prices really suck here in Canada, there is one cheaper alternative prepaid offering you may not know about - Speakout Wireless/7-Eleven - an MNVO operating on Rogers network

Min $25 top-up valid for 1yr, unlike the other companies' 30-day expiry. Incoming SMS free, outgoing $0.15 ea.
You can buy just a SIM, $10. However if you need data, then that's +$10 for 100MB/30days. Just came across this thread so haven't read through all its details yet, but it seems there was some idea of just using SMS... so though I'd mention Speakout in case it helps (I have several relatives using Speakout for emergency-use only, i.e. $25 lasts them a whole year).
 
OP: While I agree wireless plans & prices really suck here in Canada, there is one cheaper alternative prepaid offering you may not know about - Speakout Wireless/7-Eleven - an MNVO operating on Rogers network

Min $25 top-up valid for 1yr, unlike the other companies' 30-day expiry. Incoming SMS free, outgoing $0.15 ea.
You can buy just a SIM, $10. However if you need data, then that's +$10 for 100MB/30days. Just came across this thread so haven't read through all its details yet, but it seems there was some idea of just using SMS... so though I'd mention Speakout in case it helps (I have several relatives using Speakout for emergency-use only, i.e. $25 lasts them a whole year).
$25/yr for one way communication... starts adding up quickly if you want two way communication.

Some of the previously listed global sim options seem like a better choice if you're serious about this sort of thing. For now I don't have the need, but who knows what the future will hold.
 
  • Funny
Reactions: Skysurfer
Forgive my ignorance, I'm a Noob here!

My friends and I want to rework older Tesla's into race track performance and endurance cars. We would like to totally redo the IC (instrument cluster) with our own layouts and variable display. Has anyone done something like that here or elsewhere on the Internet?

Any help would be greatly appreciated. Thanks in advance.
 
Forgive my ignorance, I'm a Noob here!

My friends and I want to rework older Tesla's into race track performance and endurance cars. We would like to totally redo the IC (instrument cluster) with our own layouts and variable display. Has anyone done something like that here or elsewhere on the Internet?

Any help would be greatly appreciated. Thanks in advance.
endurance?? you do realize that EV's have limited range capabilities? at track like speeds you'd spend more time charging than driving. have you really thought this idea through?
 
  • Like
Reactions: TB205gti