================================================= 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. 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``. 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: " (``SecFuseLib``, ``GetSecurityState``). The fuses are read over Firehose with the ```` raw-memory command:: 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 ```` (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 ```` — see :doc:`/edl/interface` for the value. That path is unaffected by the QFPROM XPU fault. 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 ````/```` across LUN0–5. - Standard Firehose XML (````, ````, ````, ````, ````) applies to the 6 LUNs mapped in :doc:`/partition-map`. Write access ============ No extra signature is required at the EDL layer. PBL authenticates only the programmer (already passed). Once Firehose runs, ```` / ```` / ```` are executed by the loader, not re-authenticated by PBL. bkerler commands: ``w ``, ``wl `` (uses rawprogram*.xml), ``wf``, ``ws ``, ``e ``. 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 ````-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 ```` 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 :doc:`/edl/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 ````. - ```` 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``, ````) were exercised on this unit. 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 :doc:`/boot/secure-boot`: authenticity is off, but integrity is enforced. A zeroed/absent table is caught earlier (Sahara) than a stale one (execute hand-off). 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 ``eret``\ s 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. 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. 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: :doc:`/boot/secure-boot` (secure-boot verdict), :doc:`/partition-map` (LUN map for Firehose), :doc:`/edl/entry` (EDL entry), :doc:`/edl/interface` (advertised functions, Sahara identity, ``OEM_PK_HASH``), :doc:`/open-questions`.