Related to #763 I began looking into how the Tesla App now sends signed commands to the vehicle. I would like to share what I have found by intercepting the App network traffic, which is very easy to do with a rooted phone as there is no certificate pinning, and hope for more research to happen. I hope we will someday be able to properly document what I would call the "Tesla Signaling/Hermes Protocol" as part of this project.
First of all, the owner API is still heavily used by the app. There is no reason to suspect the owner API in its entirety will go away anytime soon, as I have read so many times. It will "just" loose all "api/1/vehicle/../command/.." REST endpoints, as vehicles require end-to-end signed commands which is a thousand times more secure and to the benefit of all vehicle owners! The wake_up and vehicle_data endpoint is used by the app every few seconds, and pure data loggers will continue to work just fine!
The Tesla App can not send commands without also being registered as a phone key. For the phone key function it generates a private key on the phone and likely transfer that public key to the vehicle via Bluetooth. Details about generating and transfering such a key is also found in teslas vehicle-sdk. The SDK also contains all there we kneed to know about generating signed commands and can send them via the Fleet API or via Bluetooth. Since we likely won't have access to the Fleet API as vehicle owners, I was interested how the App continues to function.
Payload {"uuid": "<some uuid>"}
Response { "token": "<jwt found in some protobuf messages>" }
With the first token, a WebSocket connection is opened on HERMES_URI wss://signaling.vn.teslamotors.com/v1/mobile with
Header "X-Jwt: <jwt to talk to hermes>
And they now exchange some sort of protobuf based binary packets. A command in the App very clearly generates a new exchange on that WebSocket channel and nothing else on the network. Decoding the protobuf shows strings like vehicle_device.<my VIN>.cmds and what I guess is a wrapped message in the same signed command protobuf layout that the vehicle-sdk is generating to send via BLE or to the Fleet-API's signed_command endpoint.
This is the end of my knowledge so far. More revesing of the protobuf message description is required to generated what I guess is first some "handshake" and then the command messsages. I unfortunately can't/won't share my full binary capture as it contains private information and credentials.
This is how one can talk to hermes on the command line:
Related to #763 I began looking into how the Tesla App now sends signed commands to the vehicle. I would like to share what I have found by intercepting the App network traffic, which is very easy to do with a rooted phone as there is no certificate pinning, and hope for more research to happen. I hope we will someday be able to properly document what I would call the "Tesla Signaling/Hermes Protocol" as part of this project.
First of all, the owner API is still heavily used by the app. There is no reason to suspect the owner API in its entirety will go away anytime soon, as I have read so many times. It will "just" loose all "api/1/vehicle/../command/.." REST endpoints, as vehicles require end-to-end signed commands which is a thousand times more secure and to the benefit of all vehicle owners! The wake_up and vehicle_data endpoint is used by the app every few seconds, and pure data loggers will continue to work just fine!
The Tesla App can not send commands without also being registered as a phone key. For the phone key function it generates a private key on the phone and likely transfer that public key to the vehicle via Bluetooth. Details about generating and transfering such a key is also found in teslas vehicle-sdk. The SDK also contains all there we kneed to know about generating signed commands and can send them via the Fleet API or via Bluetooth. Since we likely won't have access to the Fleet API as vehicle owners, I was interested how the App continues to function.
The App performs a POST on HERMES_AUTHORIZATION endpoint, https://owner-api.teslamotors.com/api/1/users/jwt/hermes
There is also a second POST on HERMES_VEHICLE_AUTHORIZATION endpoint, https://owner-api.teslamotors.com/api/1/vehicles/:vehicle-id/jwt/hermes
With the first token, a WebSocket connection is opened on HERMES_URI wss://signaling.vn.teslamotors.com/v1/mobile with
Header "X-Jwt: <jwt to talk to hermes>And they now exchange some sort of protobuf based binary packets. A command in the App very clearly generates a new exchange on that WebSocket channel and nothing else on the network. Decoding the protobuf shows strings like
vehicle_device.<my VIN>.cmdsand what I guess is a wrapped message in the same signed command protobuf layout that the vehicle-sdk is generating to send via BLE or to the Fleet-API's signed_command endpoint.This is the end of my knowledge so far. More revesing of the protobuf message description is required to generated what I guess is first some "handshake" and then the command messsages. I unfortunately can't/won't share my full binary capture as it contains private information and credentials.
This is how one can talk to hermes on the command line:
Without a valid token there is a "authorization denied" message.