1

Unlocking the Drive

Exploiting Tesla Model 3
 Who are we
2

David BERARD
Offensive security
SECURITY EXPERT
@_p0ly_ 150 Experts
Pentest, Reverse Engineering, Development,
Incident Response

Vincent DEHORS Reverse Engineering team

45 reversers
SECURITY EXPERT
@vdehors Low level research, reverse Engineering,
vulnerability research, exploit development, etc.
 Pwn2own
3

& previous work

Competition organized by ZDI

Took place in Vancouver (April 2023)

New Pwn2Own Automotive in Tokyo (Jan. 2024)

Pwn2Own 2022

Infotainment preauth RCE (Wifi)

& sandbox escape & 2 kernel bugs
 Pwn2own 2023
4

Timeline

GTW PC died
Bluetooth Exploit P2O
A useless on the plane
Vulnerabilities
& exploit Vulnerabilities service Event
Buy a new one
in Vancouver
Dec 2022 Mid Feb 2023 8 mar 2023 22-23 mar 2023
20 mar 2023

Bluetooth Bluetooth LPE Exploit

Start LPE Stabilisation
Vulnerability Finalize
research & chaining
research exploit

Mid Jan 2023 6 mar 2023 20-23 mar 2023

13 mar 2023
 Car architecture
5

Multimedia and vehicule domains separared by a gateway

Multimedia domain Vehicle domain

Actuators
ECU 1 ECU 2
Sensors

CAN 1
Infotainment Security
Gateway CAN N

Actuators
ECU 3
Connectivity Sensors
components
 Model 3 – Infotainment
Hardware
6

Gateway: SPC5748GS SoC Intel Atom or AMD Rizen

WiFi/BT

CANs
Hardware setup
7

Lab

• Multiple Infotainment ECU

• Some from Ebay
• 2 provided by Tesla

• After pwn2own 2022, Tesla gave us SSH keys to

access our units
 Exploit chain
8

Chaining three exploits for a remote-to-CAN fullchain

Infotainment Security Gateway

1
3
bsa_server process
Firmwares update
Linux Userland app

Attacker’s BCMDHD driver

Linux Kernel
PC

Bluetooth Firmware WiFi Firmware

WIFI/BT CHIP BCM4359
Bluetooth features
9

Why does the car need Bluetooth ?

Message and contact synchro.

Display received messages on the infotainment
screen

Voice call
Display received SMS on the infotainment screen

Play music
Play music from a phone using Bluetooth standards
(supported by smartphones)

Spotify
Play music from a phone using Spotify
 Bluetooth classic
10

A huge attack surface

SPP MAP
GATT
AVRCP SDP
PAN AVDTP
HID
L2CAP
RFCOMM SYNC All these acronyms are real
DUN
HCI OBEX Bluetooth protocols / profiles
BNEP HFP
FTP And there are much more…
 Bluetooth classic
Attack surface on Tesla car
11

Profiles for Audio Playback

PROFILES Service Discovery (SDP)

Retrieves the service list provided by the peer
OBEX

Advanced Audio Distribution Profile (A2DP)

SDP RFCOMM
Protocol for audio streaming

L2CAP
Audio/Video Remote Control Profile (AVRCP)
HCI Audio controls (play/stop, playlist management, …)

Hardware / RF
Basic Imaging (BIP)
Allows to transfer the Cover Art image
 Bluetooth stack
12

Implementation in the infotainment

Infotainment kernel Infotainment userland

UART
Wifi / BT UART
subsystem
TTY chardev Qtcar-
bsa_server btd
Chip UNIX DBUS
bluetooth
HCI

Whole Bluetooth stack

 bsa-server
13

Custom Bluetooth stack

Big attack surface Natural target for an attacker

A lot of bluetooth features are managed by this program
Looks like an exception in this heavily hardened system

High probability of vulnerability

Closed source vendor code written in C
Custom allocator
Sandboxes
The process is still well sandboxed
Bad hardening
Binary compiled without PIE

Debug symbols
Similar binary with debug symbols found on Github
 Vulnerability research
14

Usual Workflow for Vulnerability research

Remote GDB on physical ECU

Researcher’s laptop SSH Infotainment

gdb + pwndbg TCP gdb-server

Modified Bluez Bluetooth bsa_server

Static analysis Dynamic instrumentation

• Reverse engineering with Ghidra / IDA • Attacker device is a laptop with a standard bluetooth chip
• Help of debug symbols from another binary • Bluez recompiled to add our exploit code
• Tesla Infotainment with SSH access and gdb
 BIP
15

Reaching the BIP surface

1 Playback is configured by the phone (AVRC) OBEX GET x-bt/img-img

<image-descriptor version=‘1.0’>…</image-descriptor>

The car queries available Cover Art pictures using

2 OBEX protocol OBEX Response
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<image-properties>
...
The phone send available images description using </image-properties>
3 OBEX protocol

4 The car downloads and displays one image

 Vulnerability in BIP OOB Write
16

Heap buffer overflow in the BIP protocol implementation

▪ In the BIP parsing function (bip_xp_parse)
▪ Parsing result is stored in an allocation of 0x2800 bytes containing an array of images metadata
▪ Adding an « attachment » fills 0x100 bytes, 38 are enough to overflow (limit is 256, due to a bug)
▪ Allows writing controlled bytes after the end of an allocation (custom allocator)

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>

<image-properties>
<attachment />
<attachment />
<attachment />
...
<attachment name=“AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" />
</image-properties>
 Heap exploitation
17

Bsa-server custom heap

Custom heap management from a code base called GKI

🤯 ▪ Allocations located in arrays in the data section (no PIE = no ASLR)
▪ Very few corruption checks compared to the glibc

p_next p_next Arbitrary

p_first
id tid st type id tid st type write

< chunk data > < chunk data >

ddbaddba ddbaddba
 Code execution
18

Taking over a timer, again…

Arbitrary
Main loop
write

Application Arbitrary
Fake timer Stack Pivot ROP
timer queue Call

Shellcode
Injected C program (stage1)
All addresses are located in the binary (globals, gadgets) (Small)
so they are already known
 The end ?
19

What can we do with this code execution ?

• Dedicated UID Kafel

• No useful capability • Syscalls filtering
• No network
AppArmor
• All sandboxes activated
• Whitelist for file access
process
bsa_server
• Cannot execute anything
• But two legitimate APIs
• TTY communication
Minijail
• Dedicated chroot
• One UNIX socket to
• Empty network stack
communicate with btd
➢ Limited attack surface
 LPE
20

Arbitrary write inside the chipset firmware

Infotainment
• bsa_server communicates with Bluetooth
chipset through HCI protocol
bsa_server process
• Vendor specific commands are used to
Stage1 payload initialize the chipset (i.e. load Bluetooth
firmware patches)
Linux Userland
• At least HCI_BRCM_WRITE_RAM and
HCI_BRCM_SUPER_PEEK_POKE
HCI

commands allow arbitrary writting to the

BCMDHD driver internal chipset memory
Linux Kernel

• So stage1 injected in bsa_server can write

inside the chipset memory
Bluetooth Firmware WiFi Firmware
WIFI/BT CHIP BCM4359
 LPE
21

Gaining code execution inside the WiFi chipset

Infotainment
• Bluetooth firmware and WiFi firmware share
some memory regions
bsa_server process
• WiFi firmware RAM code is mapped at
Stage1 payload address 0x500000 in the Bluetooth part

Linux Userland • HCI_BRCM_WRITE_RAM HCI command

allows writing to the WiFi firmware RAM code
HCI

• WiFi firmware runs on an ARM core

BCMDHD driver
Linux Kernel • So stage1 injected in bsa_server can patch
WiFi firmware to inject custom code

Bluetooth Firmware WiFi Firmware • WiFi Firmware Idle task is patched to jump on
Shared
WIFI/BTmemory Stage2 payload
CHIP BCM4359 the injected code: stage2
 LPE
22

Code execution inside the WiFi chipset

Stage1 WiFi code injector

Patched WiFi Firmware idle_thread to jump in stage2

 LPE
23

Attack surface from the chipset

Infotainment
• WiFi part of the chipset uses PCIe to
bsa_server process
communicate with the main processor
- DMA
Stage1 payload - Mailbox

Linux Userland • WiFi is managed by the BCMDHD Linux driver

• Stage2 in the WiFi firmware is well placed to

attack the Linux driver
BCMDHD driver
Linux Kernel

PCIe

Bluetooth Firmware WiFi Firmware

Stage2 payload

WIFI/BT CHIP BCM4359

 LPE
24

Bcmdhd to chipset memory structures

• Some structures are shared between chipset and

driver, like pciedev_shared_t / ring_info_t

• These structures are reloaded from the chipset

memory while handling a mailbox interrupt
- In normal operation: during chipset startup, and
chipset software crash

• Stage2 can generate the mailbox interrupt to fill the

structure ring_info_t
 LPE
25

Out-of-bound write in bcmdhd

• d2h_r_idx_ptr is used as an offset to write inside a ioremap region (TCM)

• The offset is not checked to be in the TCM region!

• Ioremap places addresses in the vmalloc region

• Stage2 can write out of bound after the ioremap TCM region by setting d2h_r_idx_ptr to a value bigger
than the TCM size

• Need to find something to write on!

TCM ioremap buffer

write
 LPE
26

Out-of-bound write exploitation

• Process Kernel Stacks are good candidates

- Are in vmalloc region (allocated in _do_fork function)

- Can be sprayed from Stage1 by forking process multiple times
- Process children can be blocked in a syscall to stay in Kernel (i.e. clock_nanosleep)
- Write to Process Kernel Stacks is a powerful primitive => direct ROP after unblocking syscall

• Thanks to a big buffer allocated by the GPU driver, the offset (from TCM) of a process kernel stack is fixed

• Stage2 (payload in WiFi firmware) can patch a process kernel stack of a child of Stage1 (payload in
bsa_server) blocked in clock_nanosleep

Fixed offset

do_fork

do_fork

do_fork

do_fork

do_fork
do_fork

do_fork

do_fork
do_fork
do_fork

do_fork
do_fork

do_fork

do_fork

do_fork

do_fork
do_fork

do_fork

do_fork
TCM ioremap buffer i915_ggtt_init_hw

0x20007000
write
 KASLR bypass
27

& hardened kernel configuration 

Random kernel base address Reading a nice blogpost on side-

But not a lot of possibilities… channels at the same time…
0xffffffff81000000
0xffffffff82000000
0xffffffff83000000
... https://www.willsroot.io/2022/12/entrybleed.html

0xffffffffbf000000

ffffffffb0900000 179
ffffffffb0a00000 138
Similar side-channel issue ffffffffb0b00000 136
Prefetch times differ ffffffffb0c00000 44 🤔
…
ffffffffb1300000 179
 LPE
28

ROP chain

Strategy
End of a kernel process stack
Pivot
0xffffc90024007f50 │ 75 00 a0 81 ff ff ff ff 44 44 44 44 44 44 44 44 │ 1. Replace Return address by a RET gadget address
0xffffc90024007f60 │ 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 │
0xffffc90024007f70 │ 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 │
(that is executed when the clock_nanosleep
0xffffc90024007f80 │ 44 44 44 44 44 44 44 44 42 02 00 00 00 00 00 00 │ syscall ends)
0xffffc90024007f90 │ 00 00 00 00 00 00 00 00 44 44 44 44 44 44 44 44 │ 2. Use saved register as a first ROP chain
0xffffc90024007fa0 │ 44 44 44 44 44 44 44 44 da ff ff ff ff ff ff ff │
0xffffc90024007fb0 │ b1 d2 23 92 c0 55 00 00 c0 ed 63 db ff 7f 00 00 │
0xffffc90024007fc0 │ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │ Ropchain 1 (in saved registers)
0xffffc90024007fd0 │ e6 00 00 00 00 00 00 00 b1 d2 23 92 c0 55 00 00 │
0xffffc90024007fe0 │ 33 00 00 00 00 00 00 00 42 02 00 00 00 00 00 00 │ 1. Jump in copy_from_user to fill the Kernel process
0xffffc90024007ff0 │ 80 ec 63 db ff 7f 00 00 2b 00 00 00 00 00 00 00 │ stack with a second ROP chain

Ropchain 2
Last return address
Some controllable saved task registers (used to restore register values)
1. Jump in copy_from_user to override poweroff_cmd
string in the kernel memory with the command we
want to start
2. Call poweroff_work_func to start the command as
root with User Mode Helper Linux subsystem
3. Call do_exit to end the task properly
 LPE
29

root code execution

Infotainment

bsa_server process Stage3

Executed as root
Stage1 payload from the kernel

Linux Userland

BCMDHD driver
Linux Kernel

Bluetooth Firmware WiFi Firmware

Stage2 payload

WIFI/BT CHIP BCM4359

 LPE
30

root code execution

Infotainment Security Gateway

bsa_server process Stage3

Executed as root ETHERNET
Stage1 payload from the kernel

Linux Userland

BCMDHD driver
Linux Kernel

Bluetooth Firmware WiFi Firmware

Stage2 payload

WIFI/BT CHIP BCM4359

 GTW
31

Security Gateway architecture

SYSTEM NETWORKS Features

Same PCB as Infotainment Ethernet Filter CAN messages
— — —
SoC NXP MCP5748G CAN buses (Chassis/Party/Vehicle) Save log files
— —
FreeRTOS PPC-VLE Update mode
— Update other ECUs and itself
No hardware based secure-boot —
— Provide sensitive information to other
Uses its own internal flash for software ECU
(VIN/Serial/…)
—
Config Ethernet switch
 GTW
32

Security Gateway software & attack surface

• 3 main software parts

- Bootloader
- Selects between the two following modes and do software secure boot
- Update mode
- Fetches updates on the infotainment through TFTP
- Checks them and updates ECUs through CAN
- Main App mode
- Handles CAN over UDP messages and filters them
- Provides access to some sensitive values (VIN, autopilot subscriptions
etc..)
- Acts as a log server
 GTW
33

Security Gateway exploit

• GTW uses fixed addresses (no ASLR, code is in the internal flash)

• Seems to be greatly audited, and safely developed

• Logic TOCTOU bug inside the update mode => 100% stable
 GTW
34

Booting the update mode

Infotainment Security Gateway

SDCARD

XFER UPDATE.IMG TCP xfer (port 1050) Firmware main Write on SDCARD
App
REBOOT_FOR_UPDATE UDP_API (port 3500) (ROM)

REBOOT

Bootloader Read & verify

signature
(ROM)
Load & Boot

Update mode
(RAM)
 GTW
35

Update mode interactions

Infotainment Security Gateway

SDCARD
Update mode
TFTP Server (RAM) Write on SDCARD
Phase 1
Fetch & verify

Update mode
(RAM) Read
Phase 2
Apply without verify
Temp files

WRITE
/deploy (ECU_ID)

CAN
Internal ROM ECUs
 GTW
36

Update mode two phase mode

Infotainment Security Gateway

TFTP Server
FETCH 1

FETCH 2
APPLY 1
Update mode
FETCH 3
(RAM) Update mode
APPLY 2
Phase 1 (RAM)
Fetch & verify Phase 2
FETCH 4 Apply without verify
/deploy APPLY 3

APPLY 4
 GTW
37

BUG

• Update mode can be forced to fetch two times the same ECU update

• The first time if the file has a good signature the update is scheduled to be
applied, and the file is saved on the SDCARD

• The second fetch overrides the file on the SDCARD, if the signature is invalid
the first one is still scheduled, and the bad temporary file is not removed

• When applying updates, the signature is not re-checked, so the badly signed file
is applied

• This bypasses the signature check, and allows an attacker to apply arbitrary
updates, and can be used to gain code execution on the security gateway
 GTW
38

Secure boot

Security Gateway
• Bootloader verifies next stages

Bootloader • Hardware (NXP chip) doesn’t provide

(ROM) secure boot, bootloader in the internal
flash is never verified
SDCARD / FAT32
TFTP client Internal Flash
driver
• Gateway update mode allows to update
its own firmware, including the
ED25519 Signature verification bootloader

• Signature bypass in update mode =>

code exec in bootloader

Update mode Update mode App Mode

(sdcard -> RAM) (TFTP -> RAM) (ROM)
 GTW
39

Secure boot

Security Gateway
• Bootloader patch

Bootloader • Remove ED25519 signature check

(ROM)
• Use Update mode boot mechanism to
SDCARD / FAT32
TFTP client Internal Flash boot on a controlled firmware
driver
• Controlled firmware has unrestricted
ED25519 Signature verification access to the CAN vehicle & chassis
buses

Update mode Update mode App Mode

(sdcard -> RAM) (TFTP -> RAM) (ROM)
 Access to CAN busses
40

From remote to CAN

Infotainment Security Gateway

bsa_server process Stage3 Stage4

Executed as root ETHERNET
Custom firmware CAN ECUs
Stage1 payload from the kernel

Linux Userland

BCMDHD driver
Linux Kernel

Bluetooth Firmware WiFi Firmware

Stage2 payload

WIFI/BT CHIP BCM4359

 Fixes
41

Tesla Response

• bsa_server is now a PIE binary and the vulnerability has been

patched

• Bcmdhd vulnerability is patched

• Security GTW
• Now moves files with a specific name when signature is
correct
• Manifest is now signed
• If a signature check fails, the file is deleted for the SDcard
 Pwn2Own 2023
42

Synacktiv was Master Of Pwn for the second time with many entries
(Windows/macOS/Ubuntu/VirtualBox/Tesla)

First Tier 2 entry ever (could have been a Tier 1 but we had chosen
to split RCE+LPE and Gateway entries)
 Conclusion 43

Not so long of a work

Strong knowledge of the Tesla cars architecture (Pwn2Own 2022)
Hardware and debug facilities
Not well hardened binary

Great support from Tesla

Tesla provided us an ECU that can receive updates
ZDI and Tesla gave us updates
Version freeze 1 month before the event
Thanks to them

Was fun

We won a car for our future research ☺

 44

www.linkedin.com/company/synacktiv

www.twitter.com/synacktiv

www.synacktiv.com