mirror of
https://github.com/Lakr233/vphone-cli.git
synced 2026-10-02 08:04:32 +08:00
`fw patch --preset standard` spent 28.8 s of 49 s inside one patch. Sampling a Release run (8623 samples) put 93% in the vm_map_protect Shape C scan and 72% of that inside `cs_disasm` — not decoding, but in Capstone's printer: printInst / printAliasInstr / matchAliasPatterns, vsnprintf / SStream_concat, and map_set_alias_id -> name2id's strcmp chain. The real decode, AArch64_LLVM_getInstruction, was 6%. The scan is deliberately unscoped, so it walks all 8.4 MB of kernel text and was decoding five instructions at each of ~2.1M offsets only to reject nearly all of them on the first one. Gate it on the raw instruction word first, the way buildADRPIndex and the vm_map_delete scan already do. The gate only ever rejects: a word that survives takes exactly the decode and the checks it always did, and every positive determination stays Capstone's. Both encodings of `mov wD, #6` are accepted even though only MOVZ can reach the existing `mnemonic == "mov"` check — the MOV-bitmask alias applies only when the immediate is not MOVZ-encodable, so `orr w9, wzr, #6` (0x321F07E9) prints as `orr`. Letting it through anyway keeps the gate independent of that aliasing rule, which is the one way a cheap prefilter could silently narrow the match. ARM64InstTests pins both words and the printer's answer for each. patchThreadSetStateEntitlementFlag has the same shape (extended only) and gets the same treatment via isBorBL. Release, 17,3_26.4 + cloudOS 26.4: the patch step 28.81 s -> 1.28 s, whole run 48.98 s -> 21.68 s standard, ~61 s -> ~28 s extended, instructions retired 1.006e12 -> 5.38e11. Verified byte-identical: four bases (26.1 / 26.4 / 26.6.2 / 27.0) x both presets, HEAD vs HEAD+prefilter, every file in each restore tree hashed — 12/12 identical, same 172 standard / 183 extended counts, same 0x1DC6EA0 rewrite, no undeclared-patch warnings. FirmwarePatcherTests: 410 tests, 132 issues, unchanged from HEAD and all missing local reference samples. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>