Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

There are two ways of opening a Tesla (or most cars). First, pressing a button uses rolling codes. Second, a challenge-response model is used for passive entry, such as being close to the car.

The key fob has a quite a few electronic components. The device has a BLE microcontroller, a certified secure element(?) and a range extender. In order to see what was going on, the author set up a very elaborate logic analyzer to see all flow of data between the different chips.

The remote entry goes from the microcontroller, to the secure element and then transmits over BLE. The passive entry does the same thing, except that we receive a challenge from the car prior. Only the secure element knows the secret to let us in.

The BLE is simply a peripheral. So, a phone app, or some other device, can connect to the device. The BLE interface has an Over-Air-Download, which allows us to change the firmware of the device. Additionally, the APDU interface allows for direct communication with the secure element. Some actions are blocked over BLE.

The Over The Air (OTA) has a signature check which is done but then ignored. This allows for arbitrary firmware to be installed onto the keyfob. So, how do we modify the firmware?

The attackers decided to not write custom firmware or patch the original. Instead, they change occurrences of jumps (in case statements) and see if the block list is gone. If that's the case, then we're good. They brute forced these checks until everything just works.

The current flow requires that the battery be taken out of the remote: this is not ideal. In order to get around this, the cars BCM (body control module) can be used to send a wake-up command to the device.

The flow for the attack works like this:

1. Send wake-up command with known VIN number to a remote. This opens the BLE interface.
2. Connect via BLE to do the OTA update to add custom firmware. This removes the blocked ADPS commands.
3. With the removal of the blocklist, we can request a code for unlocking the car. This will be returned back to the attacker.

This gives an attacker access to the inside the car. But, can we drive off with the car?

The hackers looked into how to create a keyfob that would allow them to drive away with the car. To do this, an insane amount of reverse engineering was done on the Tesla engineering Toolbox, UDS and the provisioning of keys done by Toolbox. If the key can be re-provisioned for the car, then we can take the car for ourselves.

The pairing protocol and key provision process is crazily complicated. However, for whatever reason, the key provisioning process is NOT used, allowing for trivial adding of a fake keyfob. The final step of the attack is to connect to the diagnostic port and pair the modified key fob to the car.

The author leaves us with a few points:

• OTA updates are a blessing and a curse
• A Secure Element does not guarantee a secure system. Cryptography is typically bypassed, not penetrated. This was essentially an encryption oracle attack.
• Everything has more attack surface with bluetooth.
• Embedded systems are in a hostile env. General purpose MCUs with security critical operations are quite bad.

The author leaves their twitter and email handle. There is also a paper presentation and a video of the actual attack in action. Overall, amazing research where the attacks were not that complicated; they just took quite a bit of effort to understand how the system works.