|
|
gcp_rop_crypto2.py: issues TWO svc 0xf2 service-1 calls inside ONE FE0A-hijacked chain (the FE0A->ROP
hijack is one-shot per boot, so stateful sequences must be in one chain). Hardware-validated:
- create SHA256 -> handle 0x10 (status 0, dumped back)
- create -> create -> handles 0x10 then 0x11: multi-op sequencing + crypto CONTEXT STATE PERSISTENCE
proven on silicon
- create -> digest(0x08): input 32B placed in the GCP-window scratch and dumped back correctly; the
transform returned 0xffff0006 because op 0x08 reads ctx[5]>>3 (digest len) which create leaves 0
(it stores diglen at ctx[3]) -- op 0x08 expects the operation 'started' (ctx[5] set by a
digest-init step). Precisely characterized via sub_E0B148/sub_E1CDEC/sub_E055D0; documented as the
next lead.
Added fw/HARNESS-GCP-CRYPTO-ROP.md (mechanism, message layout, AllocateOperation tuple, buffer-
direction table off_E0AB70@0xe25850, validated results, the digest state-machine lead) and mirrored
hw/gcp_rop_crypto.py, hw/gcp_rop_crypto2.py + runners into the repo.
The harness is clean, parameterized, and hardware-validated driving real crypto operations (context
creation with state persistence) with input/output buffer plumbing and result dump-back.
|
