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

Salvage Car Owners Support Group.

This site may earn commission on affiliate links.
You say, "I get well over 14v after I charge the 12v battery." Do you mean with a separate charger? And when you remove that charger the battery drops to 12-13v? (I'd be surprised if you got 14v+ from just the battery)

If I'm understanding correctly and you do not see 14v+ after removing your separate charger, the DC-DC is not providing power of course, but you've replaced that.

You have both A/C and heat which implies you have pack voltage, although a module that's out of spec. You got that rear motor fault.

Just not enough information. I wouldn't hesitate t root it. Surely there is an open-sourcer in the EU who could do that for you. (I believe Ireland is still in the EU, hopefully)

There are software ways in, but I just can not disclose. My articles will always work as long as you have control of the hardware.

Today I removed battery pack. The car still believes the pack is connected showing 108 miles on dash. It still turns on and shows PDNR. To me this shouldn’t happen when there isn’t 400v present?

Yes when I use separate charger it goes up to over 14. Then when disconnected and only connected to car it starts to discharge until the point that it is flat/dead. It receives nothing from DC converter.

I will gladly root the car but I don’t know of anyone in Ireland, UK or EU. Although I’m sure there is but unfortunately I can’t find them. I just don’t have enough experience to do it myself via your path even though it is a pretty in depth guide for people with the knowledge.

As of Friday the UK left the EU. Still technically part of EU until end of 2020.
Fun fact - when I leave my house it is faster and more convenient for me to go via a road within Ireland when basically going anywhere. So one second I’m not in EU, next I am without even showing a passport or visa. This is the main reason that trying to leave has taken so long. I may be wrong but I think I read there are over 400 border crossings from North to South, more than Eastern Europe. Everyone along the border voted to remain as the brain boxes in London had really no knowledge of this prior to putting the vote to the public.

Anyhow I believe that I have bigger problems than Boris the Blade with my P90D and still no further to finding my issue.
 
I don't think @rooter's method works for firmwares 2019.4 or newer. 2019.4 and later eliminated cron persistence.

There's probably other ways in and to persist root, but just an FYI that his instructions seem to be only applicable to firmwares before 2019.4
 
Calvin, one of the big issues as you know, was a hard border between NI & I. Don't know whether/how that was resolved but it suddenly seems to be a non-issue. Can't understand how this could have been resolved without integration. Differences over religion are stupid and regressive fighting shadows.

It makes sense that you'd still see data on the pack as it's reporting cached data. I am suspecting a pack or rear motor problem but can't prove it until we get detailed error reporting. Again this can only be done by putting the car into Diagnostic or Factory modes. In limited cases you can do the former but in all likelihood you'll need to root the car.

kdday, there is no reason that my method wouldn't work with newer versions of firmware, and in fact even with the newest hardware. If you have physical control over the hardware you can do anything. I don't know newer firmware as I choose to stay on 8.1, but if persistent cron has been eliminated I can think of ways around this, depending on whether it's a reaper process or checksummed /var. A reaper process periodically kills root in 8.1 but there's a way around that.

I infer that newer firmware partitions are protected in some way, with maybe a salted hash or checksum. Either way this must a) slow things down and b) the secret must be onboard in order to be used. I am just speculating here because I don't have the problem, but there is almost certainly going to be a solution as long as you have control over the hardware and don't care about locking Tesla out, for example recompiling sha256sum to always check clean if that's what they use.

Really the only reason we should need them is for map updates. Choose a firmware version and just be happy with that. Ditch 'Firmware Envy' as childish.
 
Last edited:
A Guy in Germany on 2019.40.2(.1?) got this message after denying software updates for a while:
file.php



Notice said:
The Tesla network is undergoing enhancements for increased security. In order to maintain compatibility with and access to connected vehicle features, this vehicle requires a software update to at least version 2019.40.2.3. If not updated prior to 1-MAY-2020, this vehicle may no longer be able to receive over-the-air software updates, access the Tesla Mobile App & associated features, utilize voice commands, receive streaming media content, and other connectivity dependent features may be impacted. Please install the available software update by selecting the yellow clock icon and choosing a convenient time. If you are persistently experiencing software update installation failure, please schedule a service appointment via the Tesla Mobile App.

Is this just scare tactics by Tesla to get more users in Europe to install a software version with crippled Autopilot 1, or to get more users to install a version with enhanced battery diagnostics?

Did anyone with insight notice security relevant changes between 2019.40.2.1 and 2019.40.2.3?
 
From backchannel:

Hi rooter, I hope you're doing fine.

I was wondering if one could get persistent root by using the immutable attribute on critical files (ssh keys, shadow...). Even though someone with root access could revert those, since I expect this to be an automatic process, they might have missed that.

Do you think that would work?
Good question. Thing is, making it persistent through immutability doesn't make it persistent in the running system, since it is actually in RAM. Only /home and /var are mounted to the (non-volatile) eMMC flash.

You preserve root by running a script periodically, because there's a Tesla reaper daemon which has the temerity and impudence to kill changes like this periodically.

There is a set of scripts on GitHub which I'm moving to. I may be doing a deep-dive article on them soon if I can get permission from the talent. I've put in a pull request there with some security enhancements and we're still sorting that.

One thing I have made immutable, is my tokens in 3/etc/saccess/. I though, do not allow Tesla to access me at all (looks like my car is asleep), so I can make these immutable. This makes sure I have access no matter what I mess up, and I never have to worry. These tokens are the passwords for susers tesla1 & tesla2. (Ty, vg) Normally tokens change every day... until you cut off Tesla's infernal meddling. Naturally I've put those tokens in my laptop notes so I always have them. And they're in my partition 3 image too in my laptop in case all else fails.
 
Last edited:
If anyone has registered at my wiki pls let me know. Amazingly MediaWiki does not notify of new registrants, and I've been hit by spambots with 20,000+ phony users and countless articles on Poker, etc.

I've blocked registration, but it's no use trying to delete all these, and batch delete scripts are 7 years old and no longer work. So I have to drop the database and rebuild.
 
  • Like
Reactions: Fabricpath
A Guy in Germany on 2019.40.2(.1?) got this message after denying software updates for a while:
file.php





Is this just scare tactics by Tesla to get more users in Europe to install a software version with crippled Autopilot 1, or to get more users to install a version with enhanced battery diagnostics?

Did anyone with insight notice security relevant changes between 2019.40.2.1 and 2019.40.2.3?

This is because Tesla is terminating support for OpenVPN to connect to their servers. They are using a websockets based proxy now (Hermes-proxy). I imagine after May they will shutdown the legacy OpenVPN servers and cars not running hermes-proxy will then be unable to contact the mothership. It could be a scare tactic too, they also may see that a huge number of cars are still connecting via OpenVPN and decide not to close it.

If they do, it means cars on older software will lose connection to the mothership, which means your Tesla app will not work and you will not be offered any more updates. However, your car will still operate normally.
 
OpenVPN is a miserable VPN, but websocket is much better in a number of ways for RESTful purposes.

And Phil, yes, I have already explained all this. Don't be a Phil.

So that everyone is aware, Ingineer is one of the two commercial/mercenary rooters (wk057 being the other) who will never give -you- root to your own car. They will administer you and watch your movements and everything else you do with the car, and if they have time might help with problems, but will -never- disclose information, and will -never- admit when they have gotten information from someone else.

There are several open-source rooters now, so you don't need these guys.
 
Last edited:
  • Love
Reactions: YieldFarmer
Rooter, you clearly have integrity and maturity, so I'm not going to stoop to your level.

For anyone wondering why you can't just give it away: For starters, it takes hundreds of hours of work to find vulnerabilities. Someone has to spend a LOT of time getting in, then if someone like Rooter comes along and steals their work and publishes it, Tesla will see the method, and CLOSE it. Then nobody can benefit in the future.

It's also not just about root, it's investing the time to learn the systems and know how these cars work. I have repaired more cars than any other 3rd party, and helped hundreds of owners get their cars going again when they had no other options. I have partnered with a number of independent repair shops and they have successfully repaired hundreds of cars using my system and knowledge. Getting root does not give you enough information to know what you are doing. I have an entire backend system that I give my customers access to so they can safely get all the information from their cars anytime, anywhere.
 
Last edited:
For anyone wondering why you can't just give it away: For starters, it takes hundreds of hours of work to find vulnerabilities. Someone has to spend a LOT of time getting in, then if someone like Rooter comes along and steals their work and publishes it, Tesla will see the method, and CLOSE it. Then nobody can benefit in the future.
Many of us are well past believing this tired old saw.

Using my methods, MCU2 and up should be rootable and there is nothing Tesla can do about it. (Predictably now you will steal this idea, as you have so many of mine) There is only one way I can think of that Tesla can keep us out, and I've seen compromises to that before.

There is some sensitive information which I recognize and respect, and have/will never published. And there is definitely space for pay services done by talent to earn money for their time, but not the way you do it, sir.

No love lost between you and I Phil, so 'nuff said.
 
Last edited:
From backchannel:

{redacted} said:
Hello! I just read your discussion with Phil about rooting.
You said:

I have worked daily for three months already since december to understand Model 3's file system and its difference from Model S MCU1. I would be glad if you could share some information I don't know about, because, what I learned:

a) It is impossible to access Model 3 MCU's shell. Tesla disabled Tesla1/Tesla2 token system and added SSH authorized key from their side, so no password needed to log in but impossible since the key is in volatile partition (P1/P2). There are no paswords at shadow file at all.

b) There was a security hole till early 2018 (there was a possibility to create file in /var partition that would open the SSH shell / disable the authorized_keys)

c) It is impossible to change authorized SSH keys because P1 and P2 partitions are guarded by dm-verity, if something is changed in those partitions, system simply doesn't boot.

I gained access to Model 3's gateway and I was able to change the config, but there were no options to gain root access from gateway. Also, the gateway is totally different than in MCU1.

I even had a thought to create customized bootloader and kernel so there was no dm-verity, and that would open all the doors. But it would take a few months to create one.

I know that {redacted} has access to Model 3's root, since he worked together with {redacted} and they managed to create an exploit together. You can read about it on Reddit or here if you haven't already:

----------------------------------
{redacted}

Model 3 LRWD

69 points·1 year ahgo

Huge amount of the work is credit of {redacted}, who spent many months finding the initial exploit that gave temporary root access (reset on reboot), while I was able to work with him to find a way to get persistence and read/write ability on the rootfs. From when I started, it took about a month total time, probably on the order of ~100 hours of direct work.

----------------------------------

You can try googling the text part of this, I can't send you direct link, because forum thinks it is a spam.

I have never held MCU2 in my hands so I can't say that it is totally the same as in Model 3's MCU, but I find no holes there to gain root access. Is there something I don't know about yet and you would mind sharing with me?

Thanks for reading!

{redacted}
First of all, your English is flawless.

I don't have MCU2 or up so have no direct experience with them. But I can say that when you have control over the hardware, you have everything.

When you unsolder the flash and mount it in a chip carrier there is nothing you can't do. dm-verity is pernicious for sure, but there are solutions.
Disable DM-Verity and Forced Encryption [Zip Download]
 
  • Like
Reactions: YieldFarmer
From backchannel:


First of all, your English is flawless.

I don't have MCU2 or up so have no direct experience with them. But I can say that when you have control over the hardware, you have everything.

When you unsolder the flash and mount it in a chip carrier there is nothing you can't do. dm-verity is pernicious for sure, but there are solutions.
Disable DM-Verity and Forced Encryption [Zip Download]

And if things are encrypted? Like they supposedly are on the 3 and Y?
 
If what is encrypted? It can't be encrypted if it is expected to run.

Whatever convolutions you can think of there is a way around it if you have control over the hardware, with almost no exceptions.

Another aspect of this is how much is Tesla willing to sacrifice in order to keep us out? Any measures they take, cost performance and functionality... and is the percentage of owners who hack significant enough to affect the whole population? Have hacking owners caused ANY road problems? ANY?!

Come on...
 
If what is encrypted? It can't be encrypted if it is expected to run.

Whatever convolutions you can think of there is a way around it if you have control over the hardware, with almost no exceptions.

My understanding is that in the Model 3, the STORAGE is encrypted (the eMMC), and this is not the case for the Model S/X. This would severely hamper abilities to compromise the car, even with access to the hardware.

Have you successfully rooted a Model 3?
 
I do not have a model 3. The storage is encrypted? Well there must be a freakin' key there, right there in the hardware.

And actually M3 has a daemon called dm-verity, which I'd just remarked on above in my post 855. It checks every sector for hash.

Everyone is so frightened these days. Education and learning is the solution. Either live in the Hell of fearful or go to the trouble of learning.
 
  • Like
Reactions: YieldFarmer
Can you guys share what you guys did for (Voltage supply too low) ?. The car was drivable and was able to unlock the charging port but while I was waiting for the airbags to be delivered couple of things happened as below :
  • v10 got installed.
  • Took off the airbag module to reset the crash code.
  • Installed the airbags.
Around those the car started throwing voltage supply too low and shutdown. Replaced the v12 battery and checked the fuses/pyrofuse but still can’t find the problem.

Any help will be appreciated.