-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
whitex
Well-Known Member
I’m an engineer and I love to tinker, fix, and modify things. I have in the past modified my cars, adding fancy displays or hidden, palm-pilot controlled radar detectors that I reverse-engineered with hidden connectors in the vents and hidden kill switches that blended-in with the car’s decor (yes, I lived somewhere where radar detectors were not legal, and yes, I know I’m dating myself by even bringing up a palm-pilot, a lot of people today don’t even know what it is). I’m following this thread with interest. However, I also recognize the flip side of the coin here. When I modified things in the past, systems were clearly separated, nothing I could do the audio system could compromise my ability to brake or blow up my fuel tank. With today’s software defined cars that is no longer the case – messing with the radio software can hang the whole system or even just prevent some safety software to run to prevent my battery catching on fire (for example by tying up the CPU or hanging/flooding communication busses, for example hanging the CAN bus). And then there is the whole connected issue, where hacking one car could become hacking the entire fleet.
I think what most people want is the ability to customize. Think iPhone – lots of ways to customize, write custom apps, but no need for Apple to give you their source code, hardware schematics, or even any way to modify the OS. The issue here is the hacking a car has much higher potential consequences than hacking an iPhone which does not control any safety critical systems. Personally, I think this will eventually boil down to a car manufacturer offering an isolated system, with hardware enforced read-only ability to read car parameters like speed and temperatures, and carefully firewalled ability to control some non-safety-critical things like cabin temperature. Maybe we are almost there, since there are apps on iOS and android devices that can read the car status via Tesla server and control some things, all that is needed is the ability to display from the iOS device to the big screen, or even a window on the instrument cluster (say left or right “app” side could be controlled by the external device). Of course you also need ability to read touch events and/or button presses.
Keep up the good and interesting work wk057!
Absolutely nothing wrong with what you’re doing in my book (IANAL). The one question I have for you, out of my own curiosity - since you have found a way to hack some of the software and display additional things on the IC or IVI screens – do you think YOU will ever feel comfortable using this information to modify the software on either of YOUR Tesla vehicles that you drive? I’m not talking reusing the knowledge to build yourself a project car using Tesla parts, I mean would you modify your own existing Model S?
I think what most people want is the ability to customize. Think iPhone – lots of ways to customize, write custom apps, but no need for Apple to give you their source code, hardware schematics, or even any way to modify the OS. The issue here is the hacking a car has much higher potential consequences than hacking an iPhone which does not control any safety critical systems. Personally, I think this will eventually boil down to a car manufacturer offering an isolated system, with hardware enforced read-only ability to read car parameters like speed and temperatures, and carefully firewalled ability to control some non-safety-critical things like cabin temperature. Maybe we are almost there, since there are apps on iOS and android devices that can read the car status via Tesla server and control some things, all that is needed is the ability to display from the iOS device to the big screen, or even a window on the instrument cluster (say left or right “app” side could be controlled by the external device). Of course you also need ability to read touch events and/or button presses.
Keep up the good and interesting work wk057!
Absolutely nothing wrong with what you’re doing in my book (IANAL). The one question I have for you, out of my own curiosity - since you have found a way to hack some of the software and display additional things on the IC or IVI screens – do you think YOU will ever feel comfortable using this information to modify the software on either of YOUR Tesla vehicles that you drive? I’m not talking reusing the knowledge to build yourself a project car using Tesla parts, I mean would you modify your own existing Model S?
dirkhh
Middle-aged Member
Ohh, the amateur lawyer in me is so itching to give you some totally incorrect advise about "bundled distribution" and the applicability of the GPL on everything in that bundle (seriously, some bone-heads have tried that line or reasoning)... but your call is correct. Since the disk image contains proprietary software created by Tesla you can NOT post that image without clearly ending up on the wrong side of the rules.
BTW, can you PM me your address so I can send you a spare drive for "savekeeping"?
Because you're a huge Ariana Grande fan?
Keep up the good and interesting work wk057!
Currently I have no intention of rooting or otherwise modifying either of the Model S I have here, mine or my wife's. But, the more I dig into things the more I'm considering it. So much cool data that could be collected and displayed!
Long term, if I don't find any no-disassembly required way in, I may eventually sit down and carefully dismantle my dash and add myself access to the IC<>CID ethernet network. Tesla can't really disable that one like the can with the diagnostic ethernet connector... although honestly I'm impressed they can do it with the diagnostic one and had the foresight to have the hardware to make it possible. I'll probably add a small ethernet hub behind the IC (yes a hub, not a switch... I want to be able to sniff the data they send between each other easily) and route an extra ethernet cable over to the glove box or something. Then I can tinker with the car as much as I like... maybe add a Raspberry PI to the network with WiFi so I can have a nice clean wireless way in.
Honestly, I think it'd be awesome to just replace the instrument cluster display with something custom and customizable, preferably without freaking out the CID. I think this would be one of the easiest and safest things to do, since the IC doesn't really control anything aside from stuff with the steering controls, which should be simple to implement in a custom display. I'm reasonably certain I could either completely replace the IC display, or overlay on top of the existing one with relative ease. Tesla did lock down the ethernet based X display stuff we saw exploited a while back, so would still need root to do it.
A problem with this is that Tesla's updates wouldn't necessarily work anymore without intervention... and that could cause issues. I'd have to extract and inspect each update to see if it will interfere with my new instrument cluster or lock me out of things before installing. Given the frequency of updates lately, which have slowed significantly, it probably wouldn't be too bad... but things would always be slightly behind. (For now, we won't factor in that I'm rejecting updates to my car anyway until they remove the autopilot limitations that are coming).
*shrugs* We'll see how it goes.
- - - Updated - - -
Yeah, I'm not a lawyer, but even I can see that posting a dump of the units publicly would be wrong. Posting the method to get your own dump on the other hand........ is still something I'm not going to do, but, would be more than legal for sure.
BTW, can you PM me your address so I can send you a spare drive for "savekeeping"?
lol
Hmm... I honestly only know that one line from that song, and it's a male singer... and I don't know who it is. lol. (Google tells me Jay-Z.
)
Shows the alphabet and numbers and such in three different fonts... not very exciting. Not even worth taking a photo... lol
Yeah, I meant that the IC displays the feedback from using them and such.
dirkhh
Middle-aged Member
Oh my. How I would love that ability. I cannot begin to tell you. but...
Yeah, that could turn into a ton of work... or you'd be stuck, just like I am now
green1
Active Member
That's really no different from a phone, my Android is rooted, but it won't automatically get any updates anymore because of it. I have the choice to unroot and return to stock, then update, then re-root if I want. Same deal here, you could put it back to stock, update, then mess with it again.
I don't expect a disk image to be shared, but I do hope for your sake that you made one before messing with too much so you can at least restore it if you mess something up too badly...
whitex
Well-Known Member
Thanks wk057, I’ll be watching. Some technical comments:
AFAIK that was done by utilizing the VLAN feature of the Ethernet switch. IMHO it was not due to foresight of having to disable this connector, but still a cleaver workaround.
Something to consider here. By connecting the IC to the hub, you can run into few problems:
- If the interface on the switch and/or the IC is configured to a fixed, say full duplex 100Mbps link and auto-negotiate is disabled (common for embedded applications, simplifies testing), you will get packet collisions not detected as such (they will be seen as corrupted packets by the MAC) since the hub is half-duplex only. A lot of communications are over UDP which does not include retransmissions. Even if the interfaces auto-negotiate today, there may come an update that make the configuration static.
- You are changing the interface from full duplex to half duplex – something Tesla is not testing. That halves the total available bandwidth and increases packet latency.
- Hubs repeat packets to all ports, so potentially you may be introducing some replay traffic back into the system. Not necessarily bad, but something not tested. If there is another repeater in the system, you could cause packet floods that can flood the network causing a DoS situation, not sure whether any safety critical stuff runs over the Ethernet, but I think it does based on the DefCon demo where they shut down the car remotely.
- Whatever receiver you connect it to, be it a Windows or Linux machine, will introduce additional traffic to the car network (broadcasts, etc). Additional traffic, additional packets that Tesla software may not be tested with.
Are you 100% sure of that? Have you ever rebooted the instrument cluster while driving? As far as I know, the main IVI can be rebooted while driving (heck, it happened to me a few times when it crashed and rebooted itself) but the IC is not supposed to be rebooted while driving. This would imply to me that it does control something that may be safety critical and/or necessary to keep the car driving safely. Also, even if the IC doesn't directly control critical things, it doesn't mean it doesn't have access to control critical functions and/or interfere (be it accidentally) with critical communications. Just something to consider...
I was thinking, what if you were to have a camera capturing the IC screen, then provide your own IC display where you overlay whatever you want over the existing display – this way you never interfere with the IC operation other than potentially screw up the display (display the wrong speed because your software is slow, miss warnings, etc, but nothing absolutely safety critical).
You are correct. The problem is that it would be very hard for you to figure out whether the update interferes or interacts with your changes. You don’t have the test resources to test your patched version of software in every situation (say your hub problem causes lost packets which cause automatic braking to lag or not function sometimes at all).
As long as you are messing only with your own car, you’re in the same boat as people who fix their own brakes or suspension. Yes you could present a danger to others, but society decided (and I agree) that some risks are worth taking in lieu of progress (you are pioneering things after all). I’ll be following your adventures!:smile:
Last edited:
HankLloydRight
No Roads
I've rebooted both screens many times while driving without any problems.
The only thing that doesn't work are the turn signals.
The only thing that doesn't work are the turn signals.
Cyclone
Cyclonic Member ((.oO))
I've rebooted while a turn signal was active and I could see reflecting off the car in front of me. That said, I couldn't tell you if it turned off as I had to stop at the red light before turning right.
Cyclone
Cyclonic Member ((.oO))
That's what I noticed. I just hadn't tried engaging them or disengaging them (and paying attention) while the reboot occurred. It freaks out the passengers though!
HankLloydRight
No Roads
The annoying part is the a/c also cuts out... Long enough to think.. Hmmm it's warning up in here a little bit.
whitex
Well-Known Member
I don't think you understood what wk057 is trying to do here. Ethernet connection through a hub or a switch would be required to get shell access to run tcpdump in the first place. Also, with a lot of traffic (and from the DefCon video it sounds like there is a lot of continuous traffic) tcpdump will seriously tie up the CPU - CID is slow enough today already. Dumping the packets in text format over the same Ethernet connection would cause an additional problem as shell packets would show up in that same dump causing a positive feedback effect - to avoid that you'd have to filter out and not dump the packets from the shell session you use to run tcpdump. The devil is in the details Ingineer... ;-)
Hmm... not sure how to prove or disprove that since it seems the actual enable/disable is done by the gateway module. Interesting that they would have a switch with VLAN support in this application in any case.
Good notes. I may just stick with my current method on the bench, and that is a PI with two USB<>Ethernet adapters, one hooked to the IC and one hooked to the CID. Then they're just bridged on the PI. And then obviously the PI's built in ethernet for my purposes.
I can easily just iptables off any packets that the PI may send to the car's network if need be while not utilizing it. And since the PI is super low power could just leave it on constant power so the IC and CID are none the wiser. Also, I don't think an ethernet break between the CID and IC would be too critical anyway. The IC immediately stops displaying any drive data when this happens, so it's not like it would be stuck displaying an incorrect speed or anything. (See below as well)
As others mentioned before I got back, the IC and CID can both be rebooted while driving with no ill effects on vehicle control. The IC specifically causes no loss of any functionality really, aside from the obvious: instrumentation. Rebooting the CID causes HVAC to disable, though.
So, I'm not too concerned about tinkering with the IC specifically. I'm pretty sure the car could function without it on completely. The CID boots without it attached and throws no errors about it. The IC is only connected to the CID via ethernet and to the body CAN bus... so really, it can't do anything too important.
Also, there is nothing drive critical going on within the ethernet network. Nothing at all. It's literally just for feeding data to the IC and CID by the gateway which is connected to all of the CAN buses. Everything important is done via CAN. The CID can request things via ethernet to the gateway to be done on the CAN bus, but this doesn't even hit the IC<>CID link (presuming that ethernet switch we talked about above is responsible!)
Yeah, initially I wasn't thinking I'd be able to root the hardware and was considering rolling an FPGA setup that could sit between the display and the IC or CID that could overlay things given by another device, and potentially even intercept and interpret touch controls in those areas. Kind of overkill with root access though, but would be completely Tesla-software agnostic.
Well, Tesla's update packages are incremental, so there usually isn't a whole lot to look at it seems. Mainly would just be looking for changes directly related to anything I changed and giving it a quick pass or fail. Worst case can always just un-hack, let it update, and rehack... probably with a backdoor left in something the update doesn't touch, just in case Tesla tries some funny business.
Yeah, I won't modify anyone else's car under pretty much any circumstances. I'm not insured for that kind of work.
At most, lets say I make an IC skin mod or something... I might release that code under GPL and others can do what they want with it, or not. Their choice. No warranties given nor implied.
- - - Updated - - -
Good point.
Last edited:
Andyw2100
Well-Known Member
I can just see the posts now, similar to those in the phone forums: "Help!!!! I bricked my car!!!!"
