-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Worth noting this is a dismantle-the-car exploit...... so not super useful for non-bench stuff. I'm not taking my car apart to do this on my own vehicles... lol. But I can play CAN data to my bench and let it decode it for me.
Why can't we just have this read only info available to us with a legit software update??? It's crazy the work you went through to get that access.
- - - Updated - - -
Interesting and positive way to look at it.
- - - Updated - - -
The video signal itself never leaves the mobile eye hardware.
HankLloydRight
No Roads
OT: I've always wondered if TM goes under, what would happen to the Supercharger network. Would they be sold off to enterprising people to operate for a fee? Or would a larger company buy the entire network and gouge us for power?
On topic: The handshake between the SC and TM-HQ would need to be replicated or hacked on the cars if this were to happen.
Cyclone
Cyclonic Member ((.oO))
I always thought the SpCs operate on a blacklist instead of a whitelist. So assuming that when interrogating the car it would report it is SpC-enabled, the SpC would allow it to charge in absense of an explicit "No". Otherwise, if a communication problem occurs or a server goes offline, you could potentially prevent the fleet from charging. I would suspect that working off blacklisting instead of whitelisting means a reasonable risk if someone fakes the "SpC-enabled" response and the SpC can't phone home to verify vs. stranding paid customers.
Also, the "internal use" SpCs could charge 40s and 60s that weren't enabled, so perhaps that was via a "Service Center use" mode. If so, one would hope Tesla Motors dying breath would be to put the entire network in SvC mode.
Laumb
smrtass.
Just realized yours says Developer mode up top and not diagnostics mode like mine says when accessing the "hidden menu" from the T up top.
There are also small differences in what's available to the user in those modes. I don't get CAN, FONTS or DEV NAV...
Never dared hitting the factory mode button as mine is my daily driver - is it simple to revert? Ecxit button or reboot ok?
you should also try the image viewer - it displays all stored image files in the system full screen on both displays. Some interesting ones show.
Also, since your setup is offline from the rest of the car - is the Thermal-tab animated like its on live cars?
any tips for me for gaining developer access - or request for images from me please PM me wk.
Don't want mine public as its as said my daily driver.
Great work you have put down!
There are also small differences in what's available to the user in those modes. I don't get CAN, FONTS or DEV NAV...
Never dared hitting the factory mode button as mine is my daily driver - is it simple to revert? Ecxit button or reboot ok?
you should also try the image viewer - it displays all stored image files in the system full screen on both displays. Some interesting ones show.
Also, since your setup is offline from the rest of the car - is the Thermal-tab animated like its on live cars?
any tips for me for gaining developer access - or request for images from me please PM me wk.
Don't want mine public as its as said my daily driver.
Great work you have put down!
Game over.
Please do not ask me how to do this just yet... while Tesla isn't patching my bench setup, I'm sure they'll patch cars in an OTA if I released how to do it publicly.
HankLloydRight
No Roads
Cyclone
Cyclonic Member ((.oO))
See your OT point. Whomever bought it next, even if they want to gouge us for it.
lolachampcar
Well-Known Member
Certainly MB would be high up on the list as they already have a car that could technically use an SpC, and I'm surprised they didn't go further during the times the two companies were more closely linked.
AFAIK VAG are looking toward higher voltage solutions for rapids.
Being a spoilt never needed an SpC kind of guy, I'd be more concerned around the whole "right to repair" / "ability to repair" piece in the _unlikely_ event Tesla folded. (There's too many chips on the table right now IMHO).
In the UK the day Rover failed the press went into overdrive of horror stories about having unmaintainable cars. Reality is that the market was more than big enough for 3rd parties to still get parts for pretty much everything, and all the technical know-how to fit them was easily available to every back street mechanic.
If for no other reason than I don't believe in monopolistic repair tie-ins, especially for older vehicles, the work Jason (and others like the guys at EVTV) give us some confidence in years to come a thriving 3rd party market can happen.
So, I didn't have much time to dive into this further until last night/this morning.
Since I have full access to the system I figured I'd try my hand at finding a good exploit that could be used on a production car without disassembling and try my hand at Tesla's bounty program with something worthwhile. I definitely have a lot more info than most to work with now, so, should be an advantage, right?
Apparently not so far. Hats off to Tesla's security team. Aside from the method I used to get in in the first place, which required a full tear down of the MCU and access to the MCU/IC network, I haven't really found any glaring security problems.
The most I can do so far is a remote exploit using a poison WiFi network that can break into the wifi connectivity module (called "parrot") as root using a pretty complicated exploit. This is a separate embedded linux system entirely. (Yes, thats four now: we have the MCU, the IC, the "gateway", and now this "parrot" module.) While interesting, I don't think it's super useful, and I'm unsure if it actually works on the latest firmware anyway. It's also a simple patch for Tesla to prevent. I'm pretty sure I could "brick" the wifi module if I really wanted to with access to it like this... but I'm not sure that counts as a safety concern. Fortunately, even with full control of the wifi module there isn't much (anything really besides mess with WiFi) I can do to the car. The MCU/IC network still isn't accessible, since the MCU's iptables blocks everything inbound from the "parrot" module even if I open up iptables on the wifi module once I'm in. Pretty cool layer of security there that I actually missed when I looked at the CID firewalling when I started attacking the wifi module thinking I would then be able to get access to the MCU network. Silly me. lol. There may still be hope for something scarier with this particular exploit, but probably not. Things are locked down pretty well if you can't get on that internal network.
Next I was working on attacking the diagnostic port security and/or the "PLEASE ENTER ACCESS CODE". Well, I figured out the access code. It's the long randomly generated 24 hour rotated security token... which is generated by the MCU and sent to Tesla via the encrypted VPN. So, no dice there for a no-disassembly exploit either. I can unlock the diagnostic port as well, but it also requires this rotating token that is impossible to offline generate (it's literally a random token generated by the MCU itself). And I also can't just blast tokens at it hoping to get the right one because it limits to one attempt per 5 seconds. Well played, Tesla. I tried a few other potential tricks to sneak some packets in, but was no good.
So, with knowledge of the internals I started looking at the browser a little. Gave up on that quickly since it's run as its own user that is blocked via iptables from accessing anything cool.
There don't appear to be any CAN messages that would enable diagnostic mode or anything like that either.
Since I have full access to the system I figured I'd try my hand at finding a good exploit that could be used on a production car without disassembling and try my hand at Tesla's bounty program with something worthwhile. I definitely have a lot more info than most to work with now, so, should be an advantage, right?
Apparently not so far. Hats off to Tesla's security team. Aside from the method I used to get in in the first place, which required a full tear down of the MCU and access to the MCU/IC network, I haven't really found any glaring security problems.
The most I can do so far is a remote exploit using a poison WiFi network that can break into the wifi connectivity module (called "parrot") as root using a pretty complicated exploit. This is a separate embedded linux system entirely. (Yes, thats four now: we have the MCU, the IC, the "gateway", and now this "parrot" module.) While interesting, I don't think it's super useful, and I'm unsure if it actually works on the latest firmware anyway. It's also a simple patch for Tesla to prevent. I'm pretty sure I could "brick" the wifi module if I really wanted to with access to it like this... but I'm not sure that counts as a safety concern. Fortunately, even with full control of the wifi module there isn't much (anything really besides mess with WiFi) I can do to the car. The MCU/IC network still isn't accessible, since the MCU's iptables blocks everything inbound from the "parrot" module even if I open up iptables on the wifi module once I'm in. Pretty cool layer of security there that I actually missed when I looked at the CID firewalling when I started attacking the wifi module thinking I would then be able to get access to the MCU network. Silly me. lol. There may still be hope for something scarier with this particular exploit, but probably not. Things are locked down pretty well if you can't get on that internal network.
Next I was working on attacking the diagnostic port security and/or the "PLEASE ENTER ACCESS CODE". Well, I figured out the access code. It's the long randomly generated 24 hour rotated security token... which is generated by the MCU and sent to Tesla via the encrypted VPN. So, no dice there for a no-disassembly exploit either. I can unlock the diagnostic port as well, but it also requires this rotating token that is impossible to offline generate (it's literally a random token generated by the MCU itself). And I also can't just blast tokens at it hoping to get the right one because it limits to one attempt per 5 seconds. Well played, Tesla. I tried a few other potential tricks to sneak some packets in, but was no good.
So, with knowledge of the internals I started looking at the browser a little. Gave up on that quickly since it's run as its own user that is blocked via iptables from accessing anything cool.
There don't appear to be any CAN messages that would enable diagnostic mode or anything like that either.
Last edited:
I'd check to see what they are using for a random number generator, it may not be so random. I assume every MCU generates it's own keys (not just the access code) but that also may not be true.
Depends on how they are gathering entropy. This was a problem especially on older kernels when there isn't a spinning drive in the system. I believe it's a pretty old kernel in there right? It's possible there's a more finite set of keys that are generated each time an MCU is turned on for the first time.
Widespread Weak Keys in Network Devices - factorable.net
Appropriate sources of entropy [LWN.net]
Laumb
smrtass.
The access codes generated by Tesla for user input in the GUI is 5 signs long, letters and ciphers combined, all lower case.
that gives access to the diagnostic screens. Is your longer codes for the developer mode instead?
that gives access to the diagnostic screens. Is your longer codes for the developer mode instead?
