The EDL loader key wall — why every public firehose is refused by a Galaxy Z Fold 6

Measured 2026-11-04 on a retail SM-F956B (F956BXXS4DZI1) using a real EDL cable and a hand-written Sahara client, so every claim below comes from the boot ROM itself rather than from a tool's error message.

Summary

Every freely available Qualcomm firehose programmer for Snapdragon 8 Gen 3 is signed under Samsung root 467f3020c4cc788d…. A retail Fold 6 fuses a different OEM root, 5a15730f3cf04556…, so the boot ROM refuses every one of them with Sahara NAK 0x21 (HASH_TABLE_AUTH_FAILURE).

It is not a corrupt download, not a MELF-versus-ELF problem, and not a bug in the flashing tool. The certificate chain simply does not terminate at the key the device has burned into its fuses.

Evidence 1 — the fuse, read live from the boot ROM

Sahara answers these commands before any programmer is uploaded, so they describe the device, not the file we are trying:

Evidence 2 — every public loader belongs to a different root

Parsing the signer out of the programmers we hold (official firmware package, two public collections and a bkerler database entry) gives the same answer for all four:

Four files, one root; the device fuses another. That difference alone is the refusal.

Evidence 3 — the ROM accepts our upload, then rejects it

We replaced the flashing tool with a minimal Sahara client so the device's own packets are visible. The conversation is healthy all the way through the image transfer:

RX HELLO_REQ            v3  min1  max_cmd_len 0x400  mode 0
TX HELLO_RSP            48 B, reserved 1..6, mode 0 (IMAGE_TX_PENDING)
RX READ_DATA  img=0x0d  off=0x0      len=0x40      ELF header
RX READ_DATA  img=0x0d  off=0x34     len=0x40      program headers
RX READ_DATA  img=0x0d  off=0x84     len=0x600     container image 1
RX READ_DATA  img=0x0d  off=0x684    len=0x280     container image 1
RX READ_DATA  img=0x0d  off=0x904    len=0x40      container image 2 header
RX READ_DATA  img=0x0d  off=0x938    len=0x180     container image 2 phdrs
RX READ_DATA  img=0x0d  off=0x2c904  len=0x2c70    container image 2 code
RX END_TRANSFER  image_id=0x0d  status=0x21  HASH_TABLE_AUTH_FAILURE

The ROM parsed the multi-image container, requested the exact segments in the exact order, consumed two embedded images and only then refused on hash-table authentication. That exonerates the container format and the upload path, and isolates the signature.

Protocol details that break naive clients

Anyone writing their own client will hit these two before they ever reach the signature check:

• HELLO_RSP must be exactly 48 bytes, and the reserved words should be 1,2,3,4,5,6. A 40-byte reply returns 0x05 INVALID_PACKET_SIZE; zeroed reserved words return 0x15 UNKNOWN_HOST_ERROR.
• In Sahara v3, SAHARA_64BIT_MEMORY_READ_DATA carries a 64-bit image_id (24-byte payload: image_id u64, offset u64, length u64). Parsing it as 32-bit yields a nonsense length such as 0x4000000000.
• A refused session wedges the ROM: each retry needs a physical re-attach of the cable. A USB port reset does not restart Sahara.

Evidence 4 — the chain is ECDSA-P384, so the public RSA bypass is useless here

The certificate subjects inside the programmer resolve to:

All ECDSA-P384. The well-known Qualcomm PBL short-signature flaw (October 2026) forges a Sahara programmer without any private key, but only where the leaf uses RSA with exponent 3. On this SoC there is no RSA in the boot chain at all, so that entire attack class is closed. (The AVB key further up is RSA-4096; it is a different layer and does not apply to the programmer.)

What this means in practice

• EDL on this device needs a programmer signed under the Fold 6 fuse — i.e. from a Z-line SM8650 device (Fold 6 / Flip 6) or from a Samsung service package.
• S24-family loaders (S921 / S926 / S928) are the same SoC but a different root; they are refused exactly like everything else public.
• MELF64 is a legitimate Sahara-v3 programmer format, so the container shape is never the obstacle. The signature is.
• Weakening or re-signing a loader is not possible: it requires Samsung's ECDSA-P384 private key, not a tool.

Bottom line

EDL entry works, the host side is solved, and the boot ROM is willing to talk. The single missing component is one correctly signed file. Until a Fold 6 (or Flip 6) programmer exists in public, raw partition work over EDL is impossible on this device — and that is a cryptographic fact rather than a tooling gap.

No personal data is published here: no serial number, no IMEI, no device identifier. The values shown are public-key hashes, hardware IDs and protocol codes.