Repository navigation
Replies: 1 comment
Follow-up: original factory MELF loads successfully; Firehose authentication is now confirmedFurther RAM-only diagnostics on amethyst/SM7635 changed the diagnosis:
Question: is there a documented authorized authentication integration or an original signed DevPrg reference known to work with this SM7635 profile? We are not assuming generic signatures for older Xiaomi targets apply here. The authorization required by the resident Firehose programmer is distinct from the MBNv7 image signature accepted during Sahara. It is also distinct from Xiaomi account activation. No device serial or IMEI included. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Question
Is there a documented MBNv7/MELF authentication requirement for this SM7635 profile that explains rejection of the first signed component, despite matching OEM root and SoC metadata? Are there original publicly redistributable DevPrg references or additional read-only Sahara diagnostics that could distinguish QTI root rejection from metadata/policy rejection?
This request concerns firmware recovery diagnostics only. No activation-lock changes are requested.
Device information read directly through Sahara
Files
Both 1764304 bytes, original unmodified files:
MELF container at0, first ELF32 RISC-V at4864; later ELF components at188272,1162064,1465160. First signed component MBNv7 common SWID0x35, QTI metadata antirollback0, OEM1, soc_hw_versionsA018, OEM72/product0, MRCindex0. OEM root DER SHA384 matches CMD3. Embedded ECDSA-SHA384 signatures and segment hash tables verify offline against embedded certificates; this does not prove target trust in the QTI root.
Embedded QTI root SHA384:
467F3020C4CC788D2A27A6E097FFA7BFC24E82C2D56953D3B45B494CDBA5C2422A947D2C81B5752B8A2AC9EAC8ACDF34
Reproduction already performed
RAM-only transfer, image ID 13. Both original files produce the following READ_DATA64 requests in comparable runs:
(0,64), (52,64), (116,4096), (4212,652), (4864,64), (4916,384), (176896,11376).
Total: 16700 bytes. Last range is the first component hash/signature/certificate segment. Recorded outgoing buffer lengths and SHA256 match original file ranges. No USB wire capture yet.
Late target response:
04000000100000000d00000021000000
END_IMAGE_TX, image13, status0x21 (ErrorHashTableAuthFailure).
Observed using a guarded Python Win32 COM implementation and actual upstream strongtz/edl-ng Sahara/WindowsQudTransport from commit
4a658eee465a84b13c53b338edfd22bd08e4b211. The implementations share the installed QUD driver. No DONE sent after failure, no Firehose/storage commands. The independent client's default HELLO response used compatible protocol2; successful chip information session used command mode protocol3. We do not infer from successful CMD10 that either loader is accepted.Previously extracted official 2026 OTA xbl: first component code/data and all six certificates match the factory TME. ECDSA signature bytes differ; both verify offline. This is not a third DevPrg candidate.
Constraints
Please suggest read-only diagnostics or original signed recovery references. No flash, erase, factory reset, partition changes, key patching or fuse writes have been performed or are requested.
Diagnostic summary prepared on 23 October 2026.
Related existing discussion: #641 concerns UFS FFU files; this question concerns pre-Firehose authentication. I am not reporting a demonstrated bug in bkerler/edl.
All reactions