blog
blog copied to clipboard
lewurm
Update on Tesla stuff
Sorry for leaving everyone hanging, and thanks to everyone for their interest. I've got a ton of responses via email/telegram/twitter. Also I've been asked about what happened to my amazing eMMC dumping plan.
Well, I failed.
I got the eMMC reader with an additional blank eMMC. The master plan would have been to dump the old one, change some bits in the dump, and flash the new one and solder it back. Alas I wasn't even able to dump the old one. Either it got damaged during the removal or the balling must be redone. The new one reads/writes fine.
Since then I learned a bit more about the architecture from several sources (most are private). The MCU2 (the Intel based system in Model S/X) and ICE (Model 3 MCU, also Intel based) are both using dm-verity to verify the root filesystem on boot. What's left are some other partitions that can be modified, but it's hard to gain root access via that (there was a vulnerability but that got fixed in early 2019). The take away is: When you really care about root on your car, get a MCU1 based car because that one is wide open.
However, there are update images floating around in the interwebs. See below.
Warning about in-circuit eMMC dumping
I know one person who successfully dumped the eMMC with the pin mapping I've posted in an previous blog entry.
Alas, I also heard back from two people who messed up something when attempting a dump. Since then the eMMC isn't detected by the board anymore and then basically acting as you would remove it, like I did.
Soo... be careful.
A callout to exploit writers
I've found an interesting known CVE that hasn't been patched by Tesla yet. The vulnerability enables you to set a bit in the malloc heap several times. Note, clearing a bit is not possible.
- Pro: It would only require you to attach an USB device to the car.
- Con: It's extremly easy to patch for Tesla via OTA and they most likely will do it unintentionally in a couple months.
- Con: I estimate it would take 100-200h for an experienced exploit writer to come up with something (tbh, I'm not even sure if you can really gain arbitrary code execution via that vulnerability). Said person must be on Google Project Zero level.
If you are such a person and have interest and time, please reach out to me via email/twitter/telegram/irc.
What's next
Pretty much I'm in "I give up"-mode:
- I wanted to watch YouTube in my car. That feature has been officially shipped by Tesla.
- While not exactly pretty, I can
rsyncSentry/Dashcam footage via TeslaUSB by plugging a Raspberry Pi between the car and the USB storage. - With the vehicle CAN bus being fairly easily accessible (for example via https://e-mobility-driving-solutions.com/produkt/kabelsatz-m3/?lang=en ), it's pretty straight forward to build an instrument cluster. I hacked something together on a Raspberry Pi which I might show off at some point. A lot of people seem to be happy with scan my tesla as well.
- Piracy concerns: I have some background in the console homebrew scene. I loved having a relatively cheap PowerPC Linux machine (a Nintendo Wii) back when I was a student. I hated that 99% of the people were interested in pirating games and used my exploit for that. I'm afraid similar things would happen in the Tesla Space, e.g. FSD or the recent acceleration boost on the Model 3 AWD. I don't want to be an enabler for that.
- Time constrained due to other stuff (in other news, I'm becoming a dad soon)
The only remaining reason to gain root is in the spirit of "I own the hardware, thus I want to run my own software", and maybe to understand the car's software better (e.g. check out amazing analysis by @greentheonly on Twitter ) or tracking down weird sleep issues like this (please upvote btw 😄).
A little something
Maybe you can do something useful with that:
$ printf 'magnet:?xt=urn:btih:%s&dn=tesla-model-3&tr=udp%%3A%%2F%%2Fopen.stealth.si%%3A80&tr=udp%%3A%%2F%%2Ftracker.leechers-paradise.org%%3A6969&tr=udp%%3A%%2F%%2Ftracker.coppersurfer.tk%%3A6969&tr=udp%%3A%%2F%%2Fexodus.desync.com%%3A6969\n' \
> `printf '%08x' 212127159``printf '%08x' 2033012040``printf '%08x' 1116869658``printf '%08x' 1155000322``printf '%08x' 3151054784`
Have fun!
@lewurm can you give us a little hint how we could obtain more up to date little somethings ourselves?
If I could hack it, I'd want to do things that Tesla thus far refuses to fix, like:
- do not force the turn signals on while Navigating-on-Autopilot through a fork that has an adjacent lane to the signalling side (this is a very specific case that also triggers occasionally when on AP in the right lane and it's passing exits that it confuses as forks in "dirty" e.g. rainy/bad lines situations), because this is confusing as it signals to other drivers that I might be trying to change lanes into faster oncoming traffic to their side... though I'm not signalling a lane change at all, but a fork that doesn't even need a signal
- "public charging mode" - leaving the charging status screen and the charge port LED indicator lit-up even after the car is locked, as it currently shuts these off after locking/walking away
- increase the walk-away lock time/distance, and/or have the option to disable walk-away lock at home, so the car doesn't lock/fold mirrors when I'm just walking around the other side of the car
- recognize tap-opening the charging door when the car is still locked, just the same as it recognizes when the charging cord remote-open button is pressed; currently if the car's locked, you can't tap-open the door (though I can open the back door without moving my body an inch, then it's "unlocked" and the charge door happily opens with a tap), but you can approach it with the Tesla handle and press the opener/transmitter button and it happily opens for you - why would I want to lock the charge port door for any reason??
- fix the bug with drop-down boxes in the web browser appearing off-screen, rendering web forms unusable
- make USB playback reliably resume after car wakes from sleep, not just leaving it at a blank media page like it has no earthly idea what I could possibly want it to be playing right then (speaking of which, time to hit up bandcamp for another death's dynamic shroud album~)
- put ME in control of when the 12v accessory port turns on and off - it changed when Sentry was released from being "when the screen is lit, the port is alive", to now being "any time the car is awake, the port is alive", so my dashcam is basically unusable as it's constantly powered
- give us a way to report map data issues, specifically as it relates to invisible metadata about lanes, merges, exits, etc that's used by the NoAP system, sometimes unexpectedly changing speed limit (but always in the same place), or demanding that I change lanes to the left despite there being no necessary lane changes or merges until my exit (e.g. it thinks that my lane is an upcoming exit-only lane, but it turns out to be a fork-exit)...
ahem I may have a few bugs and no outlet to report them. I can only dream that someone at Tesla is itching to find bugs to submit ;)
@lewurm can you give us a little hint how we could obtain more up to date little somethings ourselves?
As far as I know you need root on a car that receives an update, then you can grab the update from the car before applying the update. Or you know such a person doing that.
ahem I may have a few bugs and no outlet to report them. I can only dream that someone at Tesla is itching to find bugs to submit ;)
I think that's a very fair point. Most of your things that you have listed will be even hard to modify even when you have root, because you need to patch an existing binary (you still don't have source access to it, except for a few things that are implemented with shell scripts). FWIW there is a community-based collection of feature requests, might be worth it to file some of your ideas there: https://featurerequests.co/
Hi @lewurm your blog is pretty interesting!
~~The point is you can always hack the MCU using the soldering/desoldering technique, providing that you can read/write the eMMC.~~
Sorry, I didn't read the part about dm-verity carefully enough. By the way, I've just found out that the model 3 computer is an unrestricted, over-the-counter part, here in the US and in Europe, so anyone can buy it directly from tesla (not so the model S/X one, for some strange reason...).
Hey @lewurm Could you check your e-mail? I sent you some interesting stuff
Hi @lewurm your blog is pretty interesting!
~The point is you can always hack the MCU using the soldering/desoldering technique, providing that you can read/write the eMMC.~
Sorry, I didn't read the part about dm-verity carefully enough. By the way, I've just found out that the model 3 computer is an unrestricted, over-the-counter part, here in the US and in Europe, so anyone can buy it directly from tesla (not so the model S/X one, for some strange reason...).
Hey @AlexVaq, where did you find out that the model 3 computer is an over the counter part? I tried to ask someone I know at a Service Center to order a a HW3 car computer (1462554) but those are backordered. You're saying HW2.5 is available?
Just go to the Tesla parts catalog
epc.tesla.com
You might need to register, but registration to access the catalog is free. Then you look in the diagrams for the MCU. Model S/X are listed as "Tesla only", if I remember well, but surprisingly the Model 3 MCU is over the counter.
El ene. 14, 2020, a las 6:44 p. m., David Dominguez Hooper [email protected] escribió:
Hi @lewurm your blog is pretty interesting!
The point is you can always hack the MCU using the soldering/desoldering technique, providing that you can read/write the eMMC.
Sorry, I didn't read the part about dm-verity carefully enough. By the way, I've just found out that the model 3 computer is an unrestricted, over-the-counter part, here in the US and in Europe, so anyone can buy it directly from tesla (not so the model S/X one, for some strange reason...).
Hey @AlexVaq, where did you find out that the model 3 computer is an over the counter part? I tried to ask someone I know at a Service Center to order a a HW3 car computer (1462554) but those are backordered. You're saying HW2.5 is available?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
I downloaded today and it went quite fast actually.
El ene. 14, 2020, a las 4:30 p. m., Tony G [email protected] escribió:
No peers on the torrent?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
I can not get the magnet link to work, uTorrent and Qbittorrent both not finding it. Tips? :( Thanks
epc.tesla.com
Yes, it's listed as "Over-the-Counter(No VIN)", but when you ask about it, they require VIN to purchase. Maybe I'm not going through the proper channel, but hey Tesla doesn't make it easy to buy.
Just go to the Tesla parts catalog epc.tesla.com You might need to register, but registration to access the catalog is free. Then you look in the diagrams for the MCU. Model S/X are listed as "Tesla only", if I remember well, but surprisingly the Model 3 MCU is over the counter. …
The other question is which part#'s of the harness/cabling system would be useful for connecting to the MCU.
Yes, it's listed as "Over-the-Counter(No VIN)", but when you ask about it, they require VIN to purchase. Maybe I'm not going through the proper channel, but hey Tesla doesn't make it easy to buy.
Recently had a service center refuse to sell me an oil pump (otc) for a salvage...which is directly against their policy (https://www.tesla.com/about/legal#unsupported-salvaged-vehicle-policy). They are also supposed to perform for cost any non-hv service on salvage, but most of them do not realize that either.
Ugh, here is the correct magnet link:
magnet:?xt=urn:btih:0ca4cdb7792d4d484292141a44d7e802bbd147c0&dn=tesla-model-3&tr=udp://open.stealth.si:80&tr=udp://tracker.leechers-paradise.org:6969&tr=udp://tracker.coppersurfer.tk:6969&tr=udp://exodus.desync.com:6969
Ugh, here is the correct magnet link:
magnet:?xt=urn:btih:0ca4cdb7792d4d484292141a44d7e802bbd147c0&dn=tesla-model-3&tr=udp://open.stealth.si:80&tr=udp://tracker.leechers-paradise.org:6969&tr=udp://tracker.coppersurfer.tk:6969&tr=udp://exodus.desync.com:6969
Thanks, I was starting to feel dumb.
I have successfully captured the contents of the eMMC with the pinout you posted. I also broke the pad off the board at the CLK signal. It's pretty fragile and if you break it then the CLK signal doesn't get to the eMMC and that's not good. It is possible to repair it usually. So, I'd recommend people see if they can find a nearby larger component to solder to instead of the little vias or pads. In the case of the CLK signal there is a resistor right above the pad that is connected. Just solder to the end of the resistor and you'll have a nice, firm connection that won't break the board.
Can you describe how you read the memory without desoldering? And what did you use for reading?
Can somebody give some more hints regarding the ISP method, which was supposedly successful for multiple people already?
- Is, apart from the VCC connection, additional power supply required (e.g. powering the board via the normal terminal)? What supply voltage would be advised for VCC? 3.3V?
- I read something about putting the Intel SOC in reset. Any hints on this item?
@wevieee I just tried dumping the eMMC but was unsuccessful.
I'm not sure if this was because I did something wrong or I have a broken car computer. The MCU I have won't boot when I apply 12V power. The gateway works and I can ping it via ethernet and the led lights come on. However, I can't ping the main computer and the debug logs just show the bootloader boot looping. Logs: https://fn.lc/s/serial-out.txt The step after these logs should be reading from the eMMC to boot but it never gets to that stage making me wonder if there's something wrong with the eMMC itself. Interestingly it doesn't boot to the recovery image either so not sure what's going on.
I tried the method described in https://www.blackhat.com/docs/us-17/wednesday/us-17-Etemadieh-Hacking-Hardware-With-A-$10-SD-Card-Reader-wp.pdf with a cheap sd card reader.
Looking at the serial output from the CPU it didn't appear to be booting when I applied power via the sdcard reader so setting the Intel SOC to reset may not be necessary. I looked but haven't been able to find a reset pin for the Intel chip.
@collin80 did you have to put the Intel SOC in reset?
I didn't put the SOC into reset but you should. You see, one time I had both the Intel SOC and my reader running at the same time then I changed a file with the reader. DO NOT DO THAT. It causes inconsistent writes to the EXT3/4 file system and really isn't a good thing at all. If you plan to write to the eMMC you need the on-board SOC disabled in some way or you're going to have a bad time. If you want to just read the eMMC then you can do that with the SOC still running. They can both read but only one can write.
I have successfully captured the contents of the eMMC with the pinout you posted. I also broke the pad off the board at the CLK signal. It's pretty fragile and if you break it then the CLK signal doesn't get to the eMMC and that's not good. It is possible to repair it usually. So, I'd recommend people see if they can find a nearby larger component to solder to instead of the little vias or pads. In the case of the CLK signal there is a resistor right above the pad that is connected. Just solder to the end of the resistor and you'll have a nice, firm connection that won't break the board.
@collin80 Would you care to elaborate? All my SPI 1bit mode captures have failed so far. Which device you used, resistor values, wire lengths? Thanks
I've used an easyjtag device with ISP/SPI 1bit adapter, pcb test jig with micro pins. Powering eMMC VCC with 1.8v/2.8v/3.3v has given no results so far. Guessing signals to CMD/DAT0 needs to be smoothened out, like suggested to me earlier by @verygreeen. Have not had time to test that out yet tho, a bit busy at the moment.
Can post some pics if anyone is interested. Continuity tests found the pins needed for 1bit SPI on the same side of pcb (back side).
Don't mean to hijack your thread @lewurm :D
I have successfully captured the contents of the eMMC with the pinout you posted. I also broke the pad off the board at the CLK signal. It's pretty fragile and if you break it then the CLK signal doesn't get to the eMMC and that's not good. It is possible to repair it usually. So, I'd recommend people see if they can find a nearby larger component to solder to instead of the little vias or pads. In the case of the CLK signal there is a resistor right above the pad that is connected. Just solder to the end of the resistor and you'll have a nice, firm connection that won't break the board.
@collin80 Would you care to elaborate? All my SPI 1bit mode captures have failed so far. Which device you used, resistor values, wire lengths? Thanks
I've used an easyjtag device with ISP/SPI 1bit adapter, pcb test jig with micro pins. Powering eMMC VCC with 1.8v/2.8v/3.3v has given no results so far. Guessing signals to CMD/DAT0 needs to be smoothened out, like suggested to me earlier by @verygreeen. Have not had time to test that out yet tho, a bit busy at the moment.
Can post some pics if anyone is interested. Continuity tests found the pins needed for 1bit SPI on the same side of pcb (back side).
Don't mean to hijack your thread @lewurm :D
Do you have a pinout for the SPI? I'm trying to dump / write to an SPI on an MCU2, and maybe the M3 and mCU2 boards are similar enough.
Slightly off topic but what do you think about an easy way to disable the LTE modem? Perhaps by disconnecting the antennas?
Ugh, here is the correct magnet link:
magnet:?xt=urn:btih:0ca4cdb7792d4d484292141a44d7e802bbd147c0&dn=tesla-model-3&tr=udp://open.stealth.si:80&tr=udp://tracker.leechers-paradise.org:6969&tr=udp://tracker.coppersurfer.tk:6969&tr=udp://exodus.desync.com:6969
hi, is this the complete image?
Ugh, here is the correct magnet link:
magnet:?xt=urn:btih:0ca4cdb7792d4d484292141a44d7e802bbd147c0&dn=tesla-model-3&tr=udp://open.stealth.si:80&tr=udp://tracker.leechers-paradise.org:6969&tr=udp://tracker.coppersurfer.tk:6969&tr=udp://exodus.desync.com:6969hi, is this the complete image?
Seems like no, image size is small. Seems like just update image.
@collin80 I know this discussion has it's age but could you elaborate on how you read the eMMC? Did you go with 1bit SPI or the full 8? What hardware did you use? And did you finally find a way to put SoC in reset? Thanks.
It was 1 bit SPI. I took a microSD to full size SD adapter and ripped the top off of it. Then I soldered wires to the little fingers that would have gone to the microSD card. I used Lewurm's pinout to attach those wires to the proper points on the board. From there I inserted the full size card into a Transcend USB-A reader. This is important as not all devices will support 1-bit mode. But, this reader will. Here's an amazon link for it: https://www.amazon.com/Transcend-TS-RDF5K-microSDHC-Reader-Black/dp/B009D79VH4
Then, I just used persistence. I practically never tried to put the main processor into reset so I'd power on the display while inserting the sdcard adapter and try my best to get it all to work. 90% of the time it would not work. But, sometimes I could plug things in at just the right time and I would see that LINUX would report that it found a valid file system on the "sdcard". If it said that then I could mount the file system and/or use dd to copy it. It seems that getting it to start up was the hardest part. After it starts it pretty much just works. But, keep in mind what I said above - if you don't put the main CPU into reset then you cannot write to the file system and even reading could get clobbered by the main CPU also accessing the memory. But, in practice I found that to not be the case. Once the main CPU is booted and the display is just sitting there it seems viable to copy the eMMC without any trouble. If you need to write, say to change the root password, then you'll have to get the CPU into reset. There are a variety of ways, one of them is to botch the eMMC clock signal so it never gets from the CPU to eMMC. Then you can freely access the eMMC yourself, providing your own clock signal. Of course, you'd have to re-enable the CPU clock line to eMMC afterward. I accidentally broke the clock line and had to run a flywire to fix it. So, the few times I did writes I'd just make sure the CPU couldn't clock the eMMC.
Thanks for your reply @collin80. I've inspected the board in the last days and found pads which were meant for a push button it seems which is marked with "MBP RST". As the Intel thing on the back is a "Gordon Peak BMP" I guess it's a way to reset that. I tried to look for places where the reset signal pops up on the board and found an unpopulated resistor R435 just under the BMP on the back. I wonder if it's just a missing 0 ohm resistor?
I measured the signal voltage of the eMMC Dx pins and it's 1.8V. Aren't SD card reader at 3.3V? I know the eMMC is capable of 3.3V but I fear to damage the CPU.
Tomorrow a BeagleBone Black should arrive which I wanna use to read the eMMC. I think I'm going to use a level converter with 1.8V to be safe.