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