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

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

This site may earn commission on affiliate links.
The problem is that root access is just that, complete access. It allows you to do anything Tesla could, including enable software options that you didn't pay for. Right now the exploits that are out there (which as far as I am aware all require physical access so its not a security issue) are known to so few individuals that its not worth Tesla's time to bother patching them. If they became public knowledge then Tesla will have much more incentive to close them

In addition a number of folks who have found exploits use them as tools for their business. If they became public knowledge that would take away from their business.

What really needs to happen is for Tesla to make an owner version of the Toolbox that lets folks do maintence/repairs.
 
Right now the exploits that are out there (which as far as I am aware all require physical access so its not a security issue) are known to so few individuals that its not worth Tesla's time to bother patching them. If they became public knowledge then Tesla will have much more incentive to close them

Tesla rapidly closes exploits as soon as they find them or people sell it to them regardless if physical access is required. If it's an exploit that gives root, Tesla will close it in short order, they don't want people on their systems. Hence, you don't say anything public and you stay in the shadows. Honestly, the only reason I speak publicly is Tesla has already given me the pole from a software perspective, so I might as well share what I learn, and warn others to stay in the shadows or faith Tesla's wrath, despite what Elon says about hacking being a gift etc, Tesla wants no part of it on their cars, except for the fact it's not their cars it's ours.
 
  • Like
Reactions: davidc18
The problem is that root access is just that, complete access. It allows you to do anything Tesla could, including enable software options that you didn't pay for. Right now the exploits that are out there (which as far as I am aware all require physical access so its not a security issue) are known to so few individuals that its not worth Tesla's time to bother patching them. If they became public knowledge then Tesla will have much more incentive to close them

In addition a number of folks who have found exploits use them as tools for their business. If they became public knowledge that would take away from their business.

What really needs to happen is for Tesla to make an owner version of the Toolbox that lets folks do maintence/repairs.

Obfuscating logical access to the physical item you own is certainly within a vendor's rights. It happens with all sorts of products, such as your phone or your DVR.

However, doing what you please (within some legally defined limits) with your own property is also your right.

So in Tesla's case, there is a value tradeoff. Tesla will happily send you firmware updates in exchange for an unhacked system. If you value that as a customer, then great.

However if you value being able to maintain your own vehicle over firmware updates, then attempting to say "root access is bad because it threatens somebody else's business model" doesn't hold for me. I frankly don't care that somebody has built their business around some close-held knowledge. I wish them all the best (and may even patronize them for products), but that doesn't mean I won't attempt to do it myself any more than I've pointed my own satellite dishes, hacked open-source firmware in to existing devices, and re-configure my on-premise ISP equioment to do things they can't, or won't, support.

There are a plethora of (routine) maintenance items that Tesla doesn't provide mechanisms for the average competent person to perform. I couldn't change my own 12V battery because they had switched to a newer model and the car's firmware configuration needed to be updated so it new the correct charging profile for the new battery type.

If you want to change your coolant, you need the correct access to tell the pumps to run a purge sequence. These are things people have been able to do on their own cars for decades.

There are also enhancements you may perform. You may be able to turn your S in to a P. In the same vein, people with standard ICE engines have also been able to remove a restrictor plate and increase the HP of their engines. Such are the chances a vendor takes when they opt to ship the same hardware across differing model lines and then differentiate by artificial means as a cost-saving measure.

You can also make modifications that jeopardize the longevity of the vehicle. You might blow up your inverter or start cracking CV joints. So? People have been throwing rods, blowing head gaskets, and spinning bearings forever. I chipped my truck. I overclock my processors. You pay to play.

I look forward to more and more knowledge about how to get access to the systems I legally own become more widely available. There will be tradeoffs, but I'm a big boy and don't need anybody else to decide for me what I should be able to do. That includes making the decision as to if I want to consider getting my future firmware updates from non-official sources.
 
I don't disagree that its your right, and I too would love to have full access. I was stating why Tesla doesn't want that, and why they would do everything possible to fix any exploits if they became commonly known.

For all of the maintence/repair stuff, that's why I said I would like Tesla to release a owner version of the Toolbox. That would theoretically allow you to do all the work you needed to, while still keeping Tesla happy by preventing you from accessing features that you had to pay for.
 
The problem is that root access is just that, complete access. It allows you to do anything Tesla could, including enable software options that you didn't pay for. Right now the exploits that are out there (which as far as I am aware all require physical access so its not a security issue) are known to so few individuals that its not worth Tesla's time to bother patching them. If they became public knowledge then Tesla will have much more incentive to close them

Tesla absolutely has patched exploits that require physical access.

Regarding your other point, newer Tesla’s have the vehicle config locked. Even with root, an owner will not be able to change the config to enable options that they didn’t pay for.

On older models even if you change a config option, Tesla can easily switch it back. If you disable the VPN to prevent this then you will lose mobile app access. Also, you run the risk of running afoul of Tesla Service the next time you bring in your vehicle. Overall, owners changing their config is a very small concern, IMO.
 
Tesla absolutely has patched exploits that require physical access.

They definite have... which, honestly, is a little annoying. If you can physically get into the car, likely because you have a key.... then I don't see the issue with accessing things you own.

Regarding your other point, newer Tesla’s have the vehicle config locked. Even with root, an owner will not be able to change the config to enable options that they didn’t pay for.

On older models even if you change a config option, Tesla can easily switch it back. If you disable the VPN to prevent this then you will lose mobile app access. Also, you run the risk of running afoul of Tesla Service the next time you bring in your vehicle. Overall, owners changing their config is a very small concern, IMO.

The problem with the new setup is that it basically prevents some part replacements, such as the battery and certain other components that require a matching configuration change.

Will see how that goes in the future. It's only a matter of time before their insistence on locking owners out of their own vehicles comes back to bite them in the ass.

Edit: fixed formatting
 
Last edited:
Regarding your other point, newer Tesla’s have the vehicle config locked. Even with root, an owner will not be able to change the config to enable options that they didn’t pay for.

That is kinda interesting. How did they do that? If I want to replace a 75 battery with a 100 battery I will no longer be able to do that because I can not change the software accordingly?
 
The problem with the new setup is that it basically prevents some part replacements, such as the battery and certain other components that require a matching configuration change.

Define new setup please? When it it become not possible to upgrade the battery? The refresh? I had high hopes to leverage your services in a few years, have they closed that off to us / you ?

Or is in this reference to MCU2 that hasn't been rooted yet?
 
AFAIK, NC's right-to-repair legislation has basically just been back burnered over and over. Unlikely to happen any time soon I'd guess.
And I am going to venture a guess and say that Tesla did not join the other manufacturers in signing on with the Alliance of Automobile Manufacturers and the Association of Global Automakers. So even 2018 models would not have any requirements.
 
I don't disagree that its your right, and I too would love to have full access. I was stating why Tesla doesn't want that, and why they would do everything possible to fix any exploits if they became commonly known.

For all of the maintence/repair stuff, that's why I said I would like Tesla to release a owner version of the Toolbox. That would theoretically allow you to do all the work you needed to, while still keeping Tesla happy by preventing you from accessing features that you had to pay for.
Perhaps I misunderstood your intent when you said: "In addition a number of folks who have found exploits use them as tools for their business. If they became public knowledge that would take away from their business."
 
Anybody played with the openvpn on CID ?

I have replaced the config file and keys from /var/etc/openvpn with my own, the tunnel comes up, vpn works fine. But I have noticed that the conf files are replaced with tesla's and I see in logs attempts to bring up tesla's openvpn ! Then I have noticed there are templates of the openvpn config files (teslavpn.conf.dev and teslavpn.conf.prod) in /usr/etc/openvpn folder.

Does anybody know what triggers the replacement of the conf file with one from the template ? I put a cron rule to check if they are changed and replace them back... it looks like they are replaced every minute or so !

I suspect qtCarNetManager does this mess, is there a way to stop this app (other than binding it to /dev/null ) ? Is it useful for something except flipping the connections and destroying the emmc with logs ?

I have connected the cid to a 4G router with ethernet cable, in order to get rid of the stupid wifi connection problems that I have since updating to ver. 8.1 and don't need anymore that crap to switch connections. Changing the default route to the 4G router seams to be working fine, except it has to be checked and maintained with a cron job, until I manage to disable qtCarNetManager. I was trying to kill it, but restarts instantly and deletes the default route at startup !

By the way, talking about the problems of the 8.1, is there a way to stop the stupid indexing of the usb music files every morning when the cid starts ? It takes more than 5 minutes and is really really annoying ! I am thinking about making an archive of the index folder and restoring at boot time ! Anybody tried this already ?
 
Greetings!

You folks all pretty much know me and my mountain of projects by now. Well, I've added one more to that ever growing list.

Behold! A Model S 17" MCU and IC running on the bench. :)

View attachment 161614

And a short video of the minor success and tinkering I've done getting these guys running on the bench:

Tesla Model S Hacking - Running the MCU and IC on the Bench - YouTube

Nothing too exciting just yet, but this is step one for sure.

I sent the video and some pics to a friend earlier and his response was: "I think you might want to go in for service. The car appears to be missing." lol

At this time I've gotten a few things accomplished:


  • Figured out the power and ground wires that run the 17", IC, and built in audio amp.
  • Figured out the connections between the IC and the MCU.
    • There is a CAN pair, an ethernet connection (via that 4-pin connector), and a wake-up signal line
  • Wired up a speaker to the center channel.
    • The alert noise the car makes can be heard. Music plays via bluetooth. No radio since I don't have the radio module.
    • This is a premium audio MCU and actually has line-level outputs for the audio channels as well as amplified outputs... not sure the purpose of the latter in the premium audio setup.
  • Figured out how to "press the brake pedal" (or at least tell the IC that's what happened)

So far it's a short list, but I plan on expanding it greatly. Since I have this unit on the bench from a salvage vehicle I have no warranty fears and basically nothing to prevent me from tinkering. If I break it... oh well, I'm not down a vehicle.

Some goals:


  • Figure out the rear view camera stuff
    • An awesome but pretty unobtrusive hack would be to be able to display whatever we want in the Camera "app".
    • I'm envisioning an HDMI aux input port...
  • Gain access to the system software
    • It's been done, and this unit is on 6.1 still. So, should be possible but I'm not sure. I'm pretty capable. If there is a way in, I'll find it.
    • From here, any number of things is possible, and that list is pretty long.
  • Hardware mod to take over the display
    • A mod to the IC and/or the MCU could potentially allow utilization of the screens by a secondary processor. This could make it so a custom piece of hardware could overlay data on the screens, intercept touch commands if desired, etc, so that the interface can be modified in all sorts of cool ways. The best part about this would be that the hack wouldn't require breaking into the software running on the units, and thus wouldn't mess up any existing functionality or any warranty related things aside from the MCU/IC modifications.
  • Find a way to gather and decode technical data about the vehicle
    • I have tons of CAN logs from working Model S vehicles. Using my bench setup I could potentially start safely decoding what these commands mean.
      • For example, I can playback some of the log to the bench setup and see if there is any result. Like, let's say I have a hunch that a certain packet is telling the battery SoC. Well, I can play that to the bench CAN bus and see if if updates the SoC display.
  • Hack enough to potentially use these units in an EV conversion project
    • Probably ambitious... but have you seen my other projects? ;)

Lot's to be done. One of the things I'll need to be able to do is convince this setup to "start" the car. Currently it won't "start" when I "press" the brake pedal since there are a lot of things it can't communicate with. I'm hoping that I can fake it out by playing back portions of CAN logs from actual vehicles and maybe eventually get the IC to the "on" screen. Keep in mind that literally the only things I have hooked up currently are the MCU and IC. No other modules that would sit on the CAN buses. So everything it is displaying about the car (battery SoC, mileage, door positions, etc) is saved and displayed since it is the last thing it saw while it was connected and powered in the actual salvage vehicle.

Essentially one of my main goals with this is to find a way to add functionality to the units one way or another that can be utilized in a working car without causing any major concerns. Additionally I want to get a better understanding of everything that the car does (specifically on the CAN bus and the ethernet connections) to potentially be able to use that info for non-Tesla based diagnostic info and such. For example, I would really love to know what my pack voltage was at any given time, or the numeric power usage value.

Should be fun, and I welcome any insight anyone might have into how to go about some of the goals I've got planned, or otherwise. Additionally, if anyone is really interested in tinkering and is able to get here physically with whatever they'd want to use to tinker, I'm all for that. I really want this car to be less of a black box than it is today.
Can you please help me bro, I'm trying hook up this mcu but I don't have the wire harness, so I have to rig it up but I can't find the diagram to power the mcu
 
Anybody played with the openvpn on CID ?

I have replaced the config file and keys from /var/etc/openvpn with my own, the tunnel comes up, vpn works fine. But I have noticed that the conf files are replaced with tesla's and I see in logs attempts to bring up tesla's openvpn ! Then I have noticed there are templates of the openvpn config files (teslavpn.conf.dev and teslavpn.conf.prod) in /usr/etc/openvpn folder.

Does anybody know what triggers the replacement of the conf file with one from the template ? I put a cron rule to check if they are changed and replace them back... it looks like they are replaced every minute or so !

I suspect qtCarNetManager does this mess, is there a way to stop this app (other than binding it to /dev/null ) ? Is it useful for something except flipping the connections and destroying the emmc with logs ?

I have connected the cid to a 4G router with ethernet cable, in order to get rid of the stupid wifi connection problems that I have since updating to ver. 8.1 and don't need anymore that crap to switch connections. Changing the default route to the 4G router seams to be working fine, except it has to be checked and maintained with a cron job, until I manage to disable qtCarNetManager. I was trying to kill it, but restarts instantly and deletes the default route at startup !

By the way, talking about the problems of the 8.1, is there a way to stop the stupid indexing of the usb music files every morning when the cid starts ? It takes more than 5 minutes and is really really annoying ! I am thinking about making an archive of the index folder and restoring at boot time ! Anybody tried this already ?
Replace /etc/init/vpn.conf with your own Upstart job @reboot with crontab
That file copies the configuration
 
  • Like
Reactions: GeorgeCM