Files
vphone-cli/VPhoneExecutable/VPhoneVirtualization
LakrandClaude Opus 5 fe3cf50c6b Stop editing the shared cache to accept an online-authorized profile
`cfw install` fails outright on a pristine 24A435 cache:

    Patch site not found: checkTrustAndAuthorization: the prologue at
    0x22406F814 neither seeds 0xE8008026 nor already reads
    `pacibsp ; mov x0, #0 ; retab` — MIS has been rewritten

The cache really is pristine — the same run reports a first-time
`maxSlide 0x20000000 -> 0x0` and fresh lsd, libxpc and lockdown-mode
writes — so this is not the already-patched anchor that was fixed for
26.x. 24A435's checkTrustAndAuthorization matches neither shape.

Teaching the patcher the new shape would be the wrong fix. Even where it
applies, this patch stops an iOS 27 guest booting (issue #532): TXM
rejects the re-attested page, dyld cannot map libSystem, and initproc
never starts. Making it apply on 24A435 turns a failed install into a
guest that installs and then does not boot.

libmisfix.dylib already does the same job from userspace, and by the
better route — it steers the call instead of forging the return.
`vpWidenedOptions` passes `RespectUppTrustAndAuthorization = false`, and
libmis calls checkTrustAndAuthorization only when that flag is set, so
0xE8008026 is never produced and the success path still fills `info`
with the CdHash and entitlements its callers read. Nothing is written to
the cache, so there is nothing for TXM to reject. `cfw install` injects
it into installd and misagent.

So `standard` blocks the patch, and it is renamed dyld-cfw-mis_trust_auth
-> dyld-exp-mis_trust_auth as the naming rule requires for a patch the
standard preset leaves off. The patcher and the `cfw patch-mis-trust-auth`
verb are unchanged and still work when it is ticked on; `experimental`
is Kind=All and still turns it on.

The gap this leaves: libmisfix rides in installd and misagent, so the
hook covers installation, while an app signed with a free personal-team
certificate is launched by SpringBoard, which asks MIS itself. On a 26.x
base that launch can still hit 0xE8008026. Ad-hoc and ldid-signed apps
are unaffected — they carry no profile, so the online-authorization
branch is never reached — and paid teams never were. Closing it means
injecting the hook into SpringBoard, which needs SystemHook's posix_spawn
route rather than a load command.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-30 18:08:04 +09:00
..