diff --git a/src/hardware-physical-access/firmware-analysis/README.md b/src/hardware-physical-access/firmware-analysis/README.md
index 53e6a858542..4d728a48417 100644
--- a/src/hardware-physical-access/firmware-analysis/README.md
+++ b/src/hardware-physical-access/firmware-analysis/README.md
@@ -394,11 +394,44 @@ $ ls vendor-app/assets/firmware
 firmware_v1.3.11.490_signed.bin
 ```
 
+### Updater-only anti-rollback bypass in A/B slot designs
+
+Some vendors do implement an anti-downgrade **ratchet**, but only inside the *updater* logic (for example a UDS routine over CAN, a recovery command, or a userspace OTA agent). If the **bootloader** later checks only the image signature/CRC and trusts the partition table or slot metadata, rollback protection can still be bypassed.
+
+Typical weak design:
+
+- Firmware metadata contains both a version descriptor and a **security ratchet** / monotonic counter.
+- The updater compares the image ratchet against a value stored in persistent storage and rejects older signed images.
+- The bootloader does **not** parse that ratchet and only verifies header, CRC, and signature before booting the selected slot.
+- Slot activation is stored separately in a partition table or per-slot generation counter and is **not cryptographically bound** to the exact firmware digest that was validated.
+
+This creates a **validate-one-image / boot-another-image** primitive in dual-slot systems. If the attacker can make the updater mark slot B as the next boot target using a current signed image, and can later overwrite slot B before reboot, the bootloader may still boot the downgraded image because it only trusts the already-committed slot metadata.
+
+Common abuse pattern:
+
+1. Upload a **current signed** firmware into the passive slot and run the normal validation/switch routine so the layout marks that slot as next active.
+2. **Do not reboot yet**. Re-enter the slot-preparation/erase routine in the same session.
+3. Abuse stale boot-state or stale slot-selection logic so the updater erases the **same physical slot** that was just promoted.
+4. Write an **older but still signed** firmware into that slot.
+5. Skip the validation routine that enforces the ratchet and reboot directly.
+6. The bootloader selects the promoted slot, verifies only signature/integrity, and boots the old image.
+
+Things to look for when reversing A/B update implementations:
+
+- Slot selection derived from **boot-time flags** that are not refreshed after a successful switch.
+- A `prepare_passive_slot()`-style routine that erases a slot based on stale state instead of the **current committed layout**.
+- A `part_write_layout()`-style function that only bumps a **generation counter** / active flag and does not store the validated image hash.
+- Ratchet checks implemented in userspace or updater code, but **not** in ROM / bootloader / secure boot stages.
+- Erase or recovery routines that leave the slot marked as bootable even after its content was removed and rewritten.
+
 ### Checklist for Assessing Update Logic
 
 * Is the transport/authentication of the *update endpoint* adequately protected (TLS + authentication)?
 * Does the device compare **version numbers** or a **monotonic anti-rollback counter** before flashing?
 * Is the image verified inside a secure boot chain (e.g. signatures checked by ROM code)?
+* Does the **bootloader enforce the same ratchet** as the updater, instead of only checking signature/CRC?
+* Is slot activation metadata **bound to the validated firmware digest/version**, or can a slot be modified after promotion?
+* After a slot switch succeeds, is the device forced to reboot or are later update/erase routines still reachable in the same session?
 * Does userland code perform additional sanity checks (e.g. allowed partition map, model number)?
 * Are *partial* or *backup* update flows re-using the same validation logic?
 
@@ -432,5 +465,6 @@ To practice discovering vulnerabilities in firmware, use the following vulnerabl
 - [Exploiting zero days in abandoned hardware – Trail of Bits blog](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/)
 - [How a $20 Smart Device Gave Me Access to Your Home](https://bishopfox.com/blog/how-a-20-smart-device-gave-me-access-to-your-home)
 - [Now You See mi: Now You're Pwned](https://labs.taszk.io/articles/post/nowyouseemi/)
+- [Synacktiv - Exploiting the Tesla Wall Connector from its charge port connector - Part 2: bypassing the anti-downgrade](https://www.synacktiv.com/en/publications/exploiting-the-tesla-wall-connector-from-its-charge-port-connector-part-2-bypassing)
 
 {{#include ../../banners/hacktricks-training.md}}