4.3. Firehose fuse read and secure-boot confirmation

Scope: the QFPROM read path, the write path, and PBL’s validation of the programmer itself, as characterized via Firehose access on this unit.

4.3.1. Secure boot not enforced

PBL validates a Sahara-supplied programmer’s signature chain against OEM_PK_HASH only when SEC_BOOT is blown. On a secure-booted device, a programmer signed by a different OEM, or unsigned/test-signed, is rejected at Sahara.

On this unit a foreign lenovo_motorola programmer was accepted: it loaded and dumped the whole device. SEC_BOOT is therefore not enforced. The accepted loader’s HWID is 0000000000000000.

4.3.2. QFPROM / fuse read

There is no fuse partition. QFPROM fuses are memory-mapped registers, not storage. On this SoC they are in the SECURITY_CONTROL block at base 0x00780000:

• DTB: qfprom@780000 { compatible="qcom,qfprom"; reg=<0x780000 0x7000>; read-only; } with fuse rows addressed as 0x780000 + offset (e.g. feat_conf8@6024 → 0x786024, gpu_speed_bin@6015 → 0x786015).

• XBL memory map: 0x00780000, 0x00010000, "SECURITY CONTROL", MMAP_IO (64 KB window; the corrected fuse shadow is the first 0x7000).

• XBL reads these as “Feature Config Row 0/1” and prints “Secure Boot: <state>” (SecFuseLib, GetSecurityState).

The fuses are read over Firehose with the <peek> raw-memory command:

<?xml version="1.0" ?>
<data><peek address64="0x780000" size_in_bytes="0x7000" /></data>

Or with bkerler edl: edl peek 0x780000 0x7000 qfprom_corr.bin (full region) / edl peekhex 0x780000 0x100 (spot read).

Status on this unit: the stock lenovo_motorola loader does not implement <peek> (compiled out). A peek-capable read-only loader (the project’s tools/roloader) was used instead, but peekhex 0x780000 0x100 on this window returns USBError(5, Input/Output Error) — XPU protection. No raw QFPROM dump has been produced.

OEM_PK_HASH was instead read via Sahara CMD_EXEC/OemPkHash, not Firehose <peek> — see EDL / Firehose interface for the value. That path is unaffected by the QFPROM XPU fault.

4.3.3. Confirmed working programmer

• Programmer: _READONLY/z_Loaders/lenovo_motorola/0000000000000000_[REDACTED]_fhprg.bin (filename encodes HWID 0x0000000000000000 and a PK-hash/serial-style tag, redacted here since it ties this loader build to specific hardware).

• Confirmed functional on this unit (above); proven operations below.

• Setup: bkerler edl V3.62, --memory=ufs. Proven operations: gpt (all 6 LUNs’ GPT + backup), rl … --skip=userdata (full read of all 6 LUNs, ~33 MB/s), Firehose <configure>/<read> across LUN0–5.

• Standard Firehose XML (<configure>, <program>, <read>, <erase>, <patch>) applies to the 6 LUNs mapped in Partition map and checksums.

4.3.4. Write access

No extra signature is required at the EDL layer. PBL authenticates only the programmer (already passed). Once Firehose runs, <program> / <erase> / <patch> are executed by the loader, not re-authenticated by PBL. bkerler commands: w <part> <file>, wl <dir> (uses rawprogram*.xml), wf, ws <sector> <file>, e <part>.

No write was actually exercised on this unit during this analysis — the following is inferred from the authentication model, not observed directly. Because secure boot is unfused, images written (xbl/abl/boot/…) are also not verified at boot, so a modified/test-signed image is expected to run unchecked. On that basis, write access is unrestricted by signature or boot-time checks for normal <program>-writable partitions; RPMB and UFS write-protect regions remain out of reach (see the constraints below).

The GPT read-only attribute is not a barrier for EDL. 34 of 61 LUN4 partitions carry GPT attribute bit 60 (read-only) — aop_a / tz_a / abl_a / modem_a / dsp_a / keymaster_a / … . That flag makes fastboot flash refuse them, but Firehose <program> writes raw sectors and ignores GPT attributes, so EDL can still write them.

Constraints and unknowns:

• The loader’s advertised functions include program, erase, patch, firmwarewrite, setbootablestoragedrive, fixgpt (see EDL / Firehose interface), so writes are exposed. A genuine write was not performed. Active slot is a; patch the inactive b slot.

• RPMB and any UFS hardware write-protect / boot-LUN config are not writable via normal <program>.

• <program> bypasses AVB/dm-verity, so a bad write can break boot, but EDL is itself the unbrick path (PBL keeps accepting this loader), so recovery is available.

• No writes were performed during this analysis; only read operations (gpt, rl, <read>) were exercised on this unit.

4.3.5. The PBL hash gate

Whether writing partition images needs extra signing is answered above (no). A separate question is whether a modified programmer loads. On-device testing settled it: PBL enforces the programmer’s ELF per-segment SHA-384 hash table, but not its root-of-trust signature.

Programmer	Hash table	Signature	Result
Stock (unmodified)	correct	original	boots
Patched + hash recomputed	corrected	stale/original	boots
Patched, stale hash	wrong	stale	passes Sahara, crashes at execute (USBError(19))
Hash table zeroed	absent	stale	rejected at Sahara (Target failed to initialize)

A patched loader boots if and only if its SHA-384 hash table (the MBN hash-table segment, ph1 @0x80934000 on the stock loader) is recomputed to match the modified segments, and needs no OEM re-signing. This is consistent with the secure-boot-not-fused verdict of Secure boot and image signing: authenticity is off, but integrity is enforced. A zeroed/absent table is caught earlier (Sahara) than a stale one (execute hand-off).

4.3.6. Nested EL3 secure-monitor image

The stock programmer is a multi-image container, not a single ELF: alongside the EL1 Firehose loader it carries a second, nested hashed-ELF at outer vaddr 0x14950000 (entry 0x14953000, outer PT_LOAD flags 0x05000005). PBL runs this nested image FIRST, at EL3 — it programs SCR_EL3/VBAR_EL3, resets the EL1 register state, and erets down to the EL1 loader’s entry. An EL1-only image (the 0x14950000 segment absent or zeroed) makes PBL execute zero bytes at EL3, which faults and resets the device before the EL1 loader ever runs.

Unlike the outer image (hash-checked but not signature-checked, per the table above), this nested image’s signature IS enforced: PBL verifies it against the secure-world root of trust, which is unconditionally present regardless of SEC_BOOT fusing. On-device bisection (2026-09-13) proved this by swapping only the nested EL3 code segment while recomputing its SHA-384 hash slot correctly:

Nested EL3 code segment	Result
Stock (byte-for-byte, hash recomputed)	boots
Clean-room reimplementation, hash correct	rejected (reset)
Stock with one byte flipped, hash correct	rejected (reset)

A hash-only integrity check (as the outer image gets) would have accepted the one-flipped-byte and clean-room variants once their hash slots were recomputed; both were rejected instead, so the nested image is the one place on this unit where PBL enforces authenticity, not just integrity. The stock QTI-signed EL3 monitor must be carried byte-for-byte in any working programmer; there is no clean-room substitute for it on this unit.

4.3.7. Sahara load-address validation

PBL also validates each Sahara segment’s destination address, not just its hash. A programmer whose DDR-scratch segments load outside this SoC’s reserved window is NAK’d with Sahara END-status 0x12 (SAHARA_NAK_INVALID_DEST_ADDR; bkerler mislabels it “Invalid data size received in image header”).

• Works on this Bitra/SM6350 unit: scratch/hash-table segments at 0x80711000 / 0x80934000 (inside the DTB reserved window xbl_aop_mem@0x80700000 … smem@0x80900000).

• Rejected: a foreign build (e.g. meizu _peek) with segments at 0x85e10000 / 0x85e2a000 — a different SoC’s DDR base.

The redacted filename tag is a signing hash, not a SoC-compatibility guarantee. A patched loader should always be derived from the known-good lenovo_motorola base, whose load addresses already match. A rejected upload leaves PBL inert at 9008; power-cycle to recover — nothing is written, PBL is ROM.

4.3.8. Provenance

Source:

user-supplied working programmer plus static EDL dump images in ../_READONLY/; on-device EDL sessions (2026-09-12, 2026-09-13).

Method:

foreign lenovo_motorola …[REDACTED]…_fhprg.bin loaded via bkerler edl V3.62 over UFS; full read of all 6 LUNs; the PBL hash-gate behaviour (integrity enforced, authenticity open) and Sahara load-address rejection observed on-device. QFPROM addresses and secure-boot state derived from the dump’s DTB and XBL memory map.

Cross-refs:

Secure boot and image signing (secure-boot verdict), Partition map and checksums (LUN map for Firehose), EDL / 9008 entry and the deep-flash cable (EDL entry), EDL / Firehose interface (advertised functions, Sahara identity, OEM_PK_HASH), Open questions and limits of analysis.