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

Successful connection on the Model S internal Ethernet network

This site may earn commission on affiliate links.
Scott, the excitement and press coverage comes from the fact that Tesla has put quite "normal" PC's into our cars. Until a while ago, there were no computers in cars. Then the car manufacturers started to put very proprietary computers into their cars, hiding information from us (and those pesky independent repair shops that fix your car for half the money).

Now with Tesla, they used three quite regular PCs, networked together by the very common ethernet (the same system they use in offices), and running Linux, an operating system that many engineers know inside out. The fascinating part is, that anyone equipped with an ethernet wire - cut to specs - and a laptop can listen in on the conversation that goes on between the center console, the dashboard display, and the basic car electronics.

When listening to the data streams, a connection was found based on an invention from 1984, called X11. X11 takes drawing information from a machine in a network and sends mouse and keyboard information back. "Disharmony" simply added his laptop to the Tesla network and started sending graphics to the center console. To everyones surprise, the center console and dashboard both accepted the commands and dutifully displayed the graphics that were sent.

This does not mean that anyone was able to *run* a program on the Tesla, only that he *displayed* some data from a program that ran elsewhere.

Undoubtedly though, these holes will be plugged with the next software release.

I hope that made things a little bit clearer.
 
Ah English! Thanks Wonko. I was somewhat kidding as I'm only half stupid / half Irish.
Seriously, interesting thread. As another poster noted... I would love it if it would get beyond the "read" stage and skip to write so we can make that 17" inch screen play video... while parked of course. Ordered my 60 in late March. Dont really do any long distance driving so trying to save a little $
 
Anyone know if Tesla's system(s) are vulnerable to the just-announced OpenSSL Heartbleed bug?
depends a little bit on how they implemented their OpenVPN connection. Given the time when their basic stack was built it's fairly likely that they are using one of the vulnerable OpenSSL 1.0.1 flavors. Which means there might be a good chance that one could use this to attack the link home to the mothership and get access to the SSL keys that are used. Which would then enable you to launch a MITM attack on that connection.
If I were in charge of software at Tesla, I'd update all my servers RIGHT NOW and push out a .95 (or later) flavor of 5.9 to ALL cars in the next day or two.
I don't know enough about the software versions used on either side of the connection, nor about the protection of traffic inside the VPN tunnel to make any educated statements on what a hacker might be able to access with that. My guess is that this would be great to learn more about the update process but it's unlikely to be useful to actually launch an actual attack on the car.
Also, dear analysts and press reading this, please study my signature. This is idle speculation for the TMC forums ONLY. Don't quote me out of context, don't try to build any click bait horror stories based on my words. I am NOT giving my consent for quoting this outside of TMC.
 
This is kind of off-topic, but I tested portal.vn.teslamotors.com. This is Tesla's "API" (app) server that runs SSL (https) and it's blackholing the heartbleed exploit test (a timeout).

So I think the answer right now is "no" but if I had to guess, I would guess that it was "yes" until they put an IPS or firewall rule in there.

For the curious, I used this tool:
Test your server for Heartbleed (CVE-2014-0160)



They use OpenVPN for their internal connections to the mothership. And OpenVPN uses OpenSSL for the initial encrypted connection.
 
Goodmorning,

I did some different X11 related tests and sniffed the traffic that is send between the 3 different IP adresses on the net. Although I still haven't analyzed everything yet, there is some interesting stuff.

X11:
- sending keys: I managed to send keys over network to the X server. For example I could write an address in the input box of the navigation. When that worked I tried to send different key's in the hope to open something, switch to a different application running in the background, opening a launch box or whatever. Unfortunately that didn't work. Also sending mousemovements using X11 works (altough hooking up a mouse will also work)

- killing the QtCar and the QtCarBrowser window (and thus the application) remotely using xkill. This works and result in having the "T" tesla logo background, but unfortunately nothing else is running. When the application is killed it starts up automatically again after lets say +/- 20 seconds.

- not very surprising, but dumping the rootwindow to a file for taking a screenshot also works.


Sniffing:

I sniffed the traffic that is exchanged between CID (ip adress ending with .100 or the "big screen") and the IC (ip ending with .101, the screen behind the steering wheel) and the GW (ip adress .102, I suspect some sort of CANbus - Ethernet gateway).

- I did not find any traffic going between the GW device and any other device, so it looks like this GW only uses the broadcasts that are sent over the network.

There is some data being sent between the IC and CID.

- IC to CID port 4070 is used to send commands in the json format like controlling the audio volume etc. I captured the following when scrolling the volume wheel on the steering wheel:
Code:
Fri Apr 11 20:50:18 2014 [312634]
TCP  192.168.90.101:51078 --> 192.168.90.100:4070 | AP


POST //_data_set_value_request_ HTTP/1.1.
User-Agent: ModelS/1.0.
Content-Type: text/plain.
Content-Length: 50.
.
{ "name" : "GUI_audioVolume", "value" : 0.333333 }

Fri Apr 11 20:50:18 2014 [324842]
TCP  192.168.90.100:4070 --> 192.168.90.101:51078 | AP


HTTP/1.1 200 OK.
Content-Type: application/json.
Content-Length: 38.
.
{ "_m_" : "_data_set_value_request_" }

There is a lot JSON going back and forth like "findAddressForCoordinates", etc, etc.



- SSH
There is an ssh login from the IC to the CID.

Code:
Fri Apr 11 21:03:28 2014 [137411]
TCP  192.168.90.101:22 --> 192.168.90.100:43377 | AP
<ssh data here>

This is ofcourse interesting, but probably useless for us. It's encrypted and I assume they use a preshared key for authentication. A MITM is probably useless here as the host key is most likely already exchanged and stored, and as I think they will use a preshared key.


- ic updater:

On the IC device port 28493 is a service listening called the "ic-updater". As the device already mentions, this is probably used to update the firmware of the IC device. I captured some data though, and this might be something interesting.

Code:
Fri Apr 11 20:50:48 2014 [382054]
TCP  192.168.90.101:28493 --> 192.168.90.100:41638 | AP


Welcome to Model S ic-updater (6392f6183553efaf @ 4a8c5f0f27b0758c3745b41ae7d78c234cd314b1) up 1814.443048000s!
> >


Fri Apr 11 20:50:49 2014 [381966]
TCP  192.168.90.101:28493 --> 192.168.90.100:41638 | AP


> installed_firmware_signature: O5XUMacO/uqA/7CWd2uk/lh/CMjQcoVWsWlOHcxAmR2fwMAAfsjv69jxy5SifbpS2lbBu9sy2q7vuwWWzAxRBg==
offline_firmware_signature: vzwrIntRW1TDLOCO1oRQSpbdSQjMOF9YMY5kNHhSz4X5Ytc85/woLYY0XYPm2B3RDgqI6s+F6Zxyo/QbuKsEBw==
>

So some signatures are being exchanged and/or verified.

I connected to this updater and send some random commands like "help", "ls", etc. but they all return "unknown command". However when replaying a false signature it shows:

Code:
Welcome to Model S ic-updater (6392f6183553efaf @ 4a8c5f0f27b0758c3745b41ae7d78c234cd314b1) up 89.646816000s!
> installed_firmware_signature: 123
Argument must be an HTTP URL (i.e. it should start with 'http://')
> installed_firmware_signature: http://example.com
URL argument seems incomplete.  No path.
>

So this might indicate that a firmware is fetched over http. And I wouldn't be surprised if the http daemon on the CID is used for this. It would be very nice if I can intercept a firmware image, because if the firmware image is unencrypted I might be able to analyze it and get some valuable information out of it. (ssh keys, user information, etc. etc.).


Further there is LOTS of data that I haven't analyzed yet, another example:

Code:
Fri Apr 11 21:03:27 2014 [470233]
TCP  192.168.90.102:1050 --> 192.168.90.100:40226 | AP


9.96      succeeded.
Update uds_bms.hex 0.51.53 => 0.51.54      succeeded.
Update bmscpld.hex 124 => 124      - skipping - succeeded.
Update chgvi.hex 0.49.59 => 0.49.59      - skipping - succeeded.
Update chgvicpld.hex 0.8 => 0.8      - skipping - succeeded.
Update chgsvi.hex 0.49.59 => 0.49.59      - skipping - succeeded.
Update chgsvicpld.hex 1.8 => 1.8      - skipping - succeeded.
Update chgph1.hex 0.49.52 => 0.49.52      - skipping - succeeded.
Update chgph2.hex 0.49.52 => 0.49.52      - skipping - succeeded.
Update chgph3.he


And there are still a lot of UDP broadcast that most likely look like CANbus messages to me, but I haven't analyzed them yet.

- - - Updated - - -

Ah, apparently there is some data flowing between the CID and the GW:

Code:
Fri Apr 11 21:03:27 2014 [455932]
TCP  192.168.90.102:1050 --> 192.168.90.100:40226 | AP


Firmware updater SVN: 4a8c5f0
Board revision: 6
3/10/2014 11:42:48 UTC
updateTime 1394451768


EPB in PARK (2) or in TOW_MODE (0)
turning off all rails
Crc check...succeeded.
Update log.cfg succeeded.
Update manifest succeeded.
Update gtw.hex 0.99.85 => 0.9
 
  • Informative
Reactions: StefanSarzio
So this might indicate that a firmware is fetched over http. And I wouldn't be surprised if the http daemon on the CID is used for this. It would be very nice if I can intercept a firmware image, because if the firmware image is unencrypted I might be able to analyze it and get some valuable information out of it. (ssh keys, user information, etc. etc.).

Interesting. It would make sense to have the CID as the distribution point for the firmware. Has your car received 5.9 yet? If not, check the http server the next time you have an alarm clock pop up on the screen. I bet you could find some cool things.
 
[xx]cpld.hex is interesting, because that will be the raw logic code for a CPLD device, some guesses...

uds_bms.hex - unified diagnostics system (common in automotive) for battery management
bmscpld.hex - battery management system CPLD
chgvicpld.hex - charge volt/current(?) mangement/controller CPLD
chgph[N].hex - charger mcu logic, phase N

You won't be able to decode cpld files (they're undocumented and proprietary to the device); these look like car firmware systems and you really probably should not go anywhere near fiddling with them. I can see if you corrupt one of these, you might break a bootloader, preventing new firmware from being loaded, and immobilising the car/disabling charging/etc.
 
Why did you get a phone call from Tesla? And why did it stop you from connecting ? ;-)

Tesla USA called Tesla France to tell them they detected hacking and/or reverse engineering intrusion in my car. Thus Tesla France called me to know what happened on my car. I explained I just connected to the car to find useful data for statistic purpose, but they advised me to stop investigation or they could void my warranty :frown:
 
Maybe something got lost in translation between Tesla US & Tesla France, but voiding the warranty for snooping on the car's network is not really an option for Tesla. In the US it would be illegal for Tesla to do so. I'd think the EU has similar laws. Warranty law in the US states that a manufacturer can only deny a warranty claim if the failure was directly caused by the owner, and then warranty is only voided for that specific part of the car. The rest of the car is still under warranty.
 
ctrl-alt-backspace??


Now, to do video is easy with X11 display redirection like this. Put a device on the ethernet and display redirect a video player to it. unfortunately the bandwidth required would be insane and most likely result in choppy video.
 
ctrl-alt-backspace??


Now, to do video is easy with X11 display redirection like this. Put a device on the ethernet and display redirect a video player to it. unfortunately the bandwidth required would be insane and most likely result in choppy video.

Not if the device has its own wireless broadband connection. Should work fine. Sound would not be integrated into the car, but would also have to come from the device.