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

[wk057]

I can just see the posts now, similar to those in the phone forums: "Help!!!! I bricked my car!!!!"

LOL. Yeah, I can see people screwing things up too. I think if you're ballsy enough to root your car then you're probably smart enough to follow directions and not screw it up.

 

[Cyclone]

LOL. Yeah, I can see people screwing things up too. I think if you're ballsy enough to root your car then you're probably smart enough to follow directions and not screw it up.

Don't underestimate how stupid people who "follow A -> B -> C but couldn't wipe their own <bleep> without a map" can be!

 

[Ingineer]

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... ;-)

Well, this is how I did it, so I know it works. There is enough spare space on the CID's SSD to store plenty of activity, and after a cursory look, you can implement filters so the load is low. It has no noticeable impact on normal functioning. Besides, you don't need to run it forever. Even if you send the data offboard, a simple filter will stop the echo amplification. The devil is indeed in the details! =)

Also, you don't need a hub or switch to gain access.

- - - Updated - - -

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.

FYI, Here's the Ethernet Switch chip they are using: http://www.marvell.com/switching/assets/marvell_linkstreet_88E6060_datasheet.pdf

 

[dirkhh]

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.

Don't make me come over there and hug you...

 

[brianman]

The ability to set cruise at 255 mph is the best part of that shot for me! Imagine AP freaking over a shadow at that speed in a newer car!

Cruise is at 0mph in that picture.

 

[whitex]

Well, this is how I did it, so I know it works. There is enough spare space on the CID's SSD to store plenty of activity, and after a cursory look, you can implement filters so the load is low. It has no noticeable impact on normal functioning. Besides, you don't need to run it forever. Even if you send the data offboard, a simple filter will stop the echo amplification. The devil is indeed in the details! =)

How did you get shell access to the CID without using ethernet switch or hub given the external ethernet port is now locked down? Is there a serial console available somewhere?

 

[Laumb]

He used the internal Ethernet port connected a step further back in the system.

 

[garygid]

The Right to Repair is not a blanket Right to Modify.

I usually attempt to observe passively, and learn, without disturbing any process or timing at all.
For example, listen to a CAN bus, read only, write nothing, thus no ACK bit writing.

My investigations are for better understanding the vehicle's operation, not
for hacking or changing anything. Sure, others went further with the LEAF
and figured out how to get cell voltages and error codes, and even ask the
car to reset some groups of the error codes.

 

[Footbag]

IIRC wk you were in the camp thinking that the car had cpu/gpu performance limitations and as such it may have factored in regarding the v7 ui redesign. Have you been able to one around and learn anything more in this regard?

 

[smac]

FYI, Here's the Ethernet Switch chip they are using: http://www.marvell.com/switching/assets/marvell_linkstreet_88E6060_datasheet.pdf

Interesting, that chip also supports port monitoring... I wonder if it would be possible to connect to it's SMI lines / EEPROM and mess with the VLAN/Port mirroring settings to do something useful with the diagnostic port?

Of course now WK057 has root there is probably a way to do this form the shell , after all it must be possible to change the switches behavior or the diagnostic one couldn't have been OTA disabled..

 

[wk057]

FYI, Here's the Ethernet Switch chip they are using: http://www.marvell.com/switching/assets/marvell_linkstreet_88E6060_datasheet.pdf

Nice, thanks. Looks a little overkill for the application, really. Cool stuff though.

How did you get shell access to the CID without using ethernet switch or hub given the external ethernet port is now locked down? Is there a serial console available somewhere?

Well, if the access was gathered pre-diagnostic ethernet lock down then that's something. If not, you don't need to IC connected to ethernet for the CID to boot, so... that's what I would do and then open up the WiFi so I could connect back via WiFi. That'd be the no-additional hardware hack, but still require disassembly of the dash to do initially.

IIRC wk you were in the camp thinking that the car had cpu/gpu performance limitations and as such it may have factored in regarding the v7 ui redesign. Have you been able to one around and learn anything more in this regard?

That's a good question. I hadn't actually thought to investigate this further, but now that you mention it I think I will. It seems I may have been incorrect based on what I've observed. I've not seen much load on the CPU on either unit. Few spikes here and there, but I haven't seen it bogged down. Then again, I wasn't really trying (like, using nav or anything).

 

[Cyclone]

I notice the IC just stall or slow severely down when Nav directions change (even if I'm only getting the pop up and switched off Nav on the left "app"). Maybe without the maps loaded, there isn't much to bog down the IC?

 

[wk057]

I notice the IC just stall or slow severely down when Nav directions change (even if I'm only getting the pop up and switched off Nav on the left "app"). Maybe without the maps loaded, there isn't much to bog down the IC?

The maps actually reside on a microSD card on the CID and are shared via NFS with the IC. The IC load appears to be virtually nothing while playing around with some recorded CAN data. The CID spikes quite a bit while jumping around from task to task, though, especially when it's loading a full screen map view. This is just from memory looking at 'top' when playing around a few days ago. I actually have the setup disconnected at the moment in preparation for making a more permanent home for it to be fiddled with without having wires run everywhere around my work area.

 

[Cyclone]

But having a spaghetti bench is part of the charm!

 

[aarossig]

As a fellow tinkerer - I really enjoyed reading this thread. Looking forward to seeing where this goes.

'sub

 

[jat]

So is there a shared repository for known CAN messages? I am aware of a few linked from Exploring the Tesla Model S CAN Bus - All but that doesn't cover much.

I want to log all 4 CAN buses available on the diagnostic connector (along with external GPS/accelerometer/etc data and video of the display for correlation), and I would be happy to share the data I collect.

 

[wk057]

Reviving my thread here post-holidays.

I've rebuilt my little test setup. Little easier to work with now.

(Yes, the "Driver Assist" app icon is Lightning McQueen... lol)

I have the IC and CID ethernet's connected to a Raspberry Pi 2 that has some USB ethernet controllers connected to it and bridged. This was I can watch and get in on that traffic easily.

I have the diagnostic ethernet port out to a cable that I have connected to a NIC on my dev PC. I can open and close this port from the shell on the CID if desired. I also dropped some security so that I can ssh in via WiFi now, and have the setup prevented from contacting the outside world.

Long story short, what I can do with the CID and IC once I'm on the CID/IC ethernet network is pretty much everything that the CID can do, as expected.

I worked on the camera interface a bit, but I haven't been able to get the display to show the cam input at all yet. I've ordered another camera to try some more with. For for details, it appears that the camera is controlled by an FPGA in the CID unit that sits between the display and the main processor. Then it overlays the camera feed as directed directly to the display output. The video from the rear cam never goes through the OS of the CID. This would explain why Tesla can't utilize the rear camera video for anything related to driver assistance/autopilot. It will also make this particular goal of my project more difficult since there isn't any code or anything I can look at and disassemble to make things easier.

I managed to unlock all of the "Apps" that are available in Developer and Diagnostic mode. The software makes it pretty tricky to enable the "VehicleConfig" app... presumably because this lets you change anything you want about the car. I'm actually unsure how this particular one is ever legitimately enabled. I changed my bench setup from a base S85 to a Signature Red P85D with every option. Things like enabling/disabling supercharging ability, the 40->60 pack setting, autopilot enabled, etc are all configurable here. Most of the settings are for whether hardware for the option is present or not, but some things are software-based when the hardware is there.

I'm sure Tesla knows what their VehicleConfig app can do, so, not like I'm doing anything crazy by posting about it.

Anyway, I'm focusing my efforts on trying to find a way into the system without dismantling parts of the car. Ideally I want to enable factory mode, which opens up the diagnostic port... and thus would let me get root on the CID and IC. Physical access to the car still needed. I might be able to carry my parrot exploit further and make a scarier exploit, but probably not. Looks pretty locked down. Additionally, I reported that vulnerability to Tesla and they're closing that particular hole. No sense leaving step one of a potential exploit chain open, even if it looks like it's pretty benign.

Secondary goal is to decode more CAN data and make a standalone parser program that interprets as much as possible. At least this way I can get lots of the diagnostic info available in the diagnostic screens without needing to modify the car at all. I think that's a worthy goal.

More to come...

 

[msnow]

That setup looks really nice and clean, great job! How did Tesla react and treat you for reporting the hole? I hope they were appreciative. What, if anything, can be played with in the Radio app?

 

[green1]

Quick question, how practical is it to disable updates while enabling streaming radio and maps?

It would be useful if/when we get to the stage of modifying our own vehicles to block Tesla bricking them remotely, while still enjoying google maps and slacker radio.

 

[wk057]

That setup looks really nice and clean, great job! How did Tesla react and treat you for reporting the hole? I hope they were appreciative. What, if anything, can be played with in the Radio app?

Tesla has been great, actually, with the hacking efforts. I won't really go into detail on any of that without permission, however.

The Radio "app" just seems to be diagnostics for the AM/FM/XM tuners.

Quick question, how practical is it to disable updates while enabling streaming radio and maps?

It would be useful if/when we get to the stage of modifying our own vehicles to block Tesla bricking them remotely, while still enjoying google maps and slacker radio.

*shrugs* Just blocking the CID from connecting out to Tesla's VPN would probably be sufficient, which is pretty simple.

Google Maps and the streaming radio stuff don't go through Tesla. However, blocking the VPN would kill the Tesla mobile app. There is some mechanism for waking the car via 3G/LTE also... unsure exactly how that works.