Topic analysis

Tesla Wall Connector bootloader bypasses the firmware downgrade ratchet

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 . We described the full update flow over Single-Wire CAN in the first article . In short: 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. After diffing the old firmware against version 24.44.3 , we focused on switch_to_new_firmware() , the function that handles UDS routine 0x201 : check_image_and_antidowngrade() is new. It parses the firmware segments, recomputes their CRCs, then calls verify_firmware_segments_platform() for the ratchet comparison: 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: And the slot gets immediately erased. There is no way to keep an old image in flash through the official path. 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: 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? Routine 0xFF00 calls prepare_passive_slot() , which selects which physical slot is "passive" based on the current boot flags, then erases it: 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: 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. 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. 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. 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: 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. 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.