LakrandClaude Opus 5
8d7d914f52
Xcode could not install anything onto a guest unless it was signed with an Apple leaf certificate, even though the guest runs unsigned code perfectly well. Measured on a booted 26.6.2 guest: unsigned and ldid-shaped bundles fail at 0xE800801C, a `codesign --sign -` bundle at 0xE8008014, all from +[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:]. A bundle pushed in through vphoned's apps.install, signed with nothing but this project's own signature, installs and reaches the foreground — so the kernel, lsd and SpringBoard already accept it and installd's check is the only gate. libmis accepts an ad-hoc signature outright when the caller passes the AllowAdHocSigning option, which installd never does, and it fills the whole info dictionary itself. So libmisfix.dylib interposes MISValidateSignatureAndCopyInfo and adds the option, and cfw install attaches it to installd with an LC_LOAD_WEAK_DYLIB. Nothing in the dyld shared cache is touched, deliberately: writing a cache code page is what leaves a 27.0 guest unable to boot in #532. The same dylib answers the other refusal. A paid team's profile fails at 0xE8008012 because the VM's UDID is in nobody's ProvisionedDevices, and only a free personal team gets auto-registration. misagent obtains that UDID from MGCopyAnswer -- its other source, an emulated UDID in the kernel's codesigning configuration, is unreachable here: the sysctl is a four-byte flags word and amfi_emulate_device_udid is in neither the kernelcache nor TXM. Interposing MGCopyAnswer lets libmisfix.plist name a device the team has already registered. Off until a UDID is set there. What Xcode and lockdown report is unchanged and still the guest's own UDID; TXM builds that one from the device tree before the kernel runs. The two answers disagree on purpose, because agreeing would mean a re-restore for a UDID that still could not match a real device's. Also fixes #532's second defect: DyldSharedCacheMISTrustAuthPatcher now recognises its own output, so a second cfw install reports alreadyPatched instead of aborting the install. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sibling guest components
make -C VPhoneGuestComponents package cross-compiles guest components with
Xcode's iPhoneOS SDK. The archive contains signed arm64e binaries, two camera
tweak filter plists, and the GPU provenance note:
| Component | Archive contents |
|---|---|
| Camera app hook | camfix/libcamfix.dylib, camfix/libcamfix.plist |
| Camera daemon hook | vcamcaptured/libvcamcaptured.dylib, vcamcaptured/libvcamcaptured.plist |
| Launchd hook | launchhook/launchdhook-vphone.dylib |
| Process injection bridge | systemhook/SystemHook-vphone.dylib |
| iOS 27 app registrar | vpregister/vpregister |
| PCC GPU driver | gpu/README.md (source and extraction flow; no Apple binary) |
The archive is a local build artifact, not a VM bootstrap. cfw install places
the launchd hook, SystemHook, and camera hooks in /usr/lib, and the
vphoned environment update replaces changed copies in a running guest. SystemHook
loads libvcamcaptured.dylib into /usr/libexec/cameracaptured and
libcamfix.dylib into apps that have AVFoundation loaded; neither camera hook
needs ElleKit or a bootstrap. After a bootstrap installs ElleKit, the launchd hook
inserts SystemHook into xpcproxy, bootstrap executables, and apps started
directly by launchd. Inside xpcproxy, SystemHook carries itself into the
final executable through posix_spawnp. Injected App and bootstrap processes
carry the hook to their child executables through posix_spawn, posix_spawnp,
and execve. SystemHook loads the selected bootstrap's
usr/lib/TweakLoader.dylib in App and bootstrap processes when it exists;
ElleKit owns tweak selection and loading. It logs PID and executable path to
/var/mobile/Library/Caches/vphone-systemhook.log, falling back to the app's
own Library/Caches when sandboxed.
DISABLE_TWEAKS=1 and the safe-mode flags skip injection.
Irisin installs ElleKit's own TweakLoader.dylib in the selected bootstrap.
The required GPU bundle is extracted from the selected PCC firmware by
vphone-cli fw prepare and copied into the VM during JB installation. No
Apple GPU binary is stored in this directory, the archive, or the shipped app.
See Research/Guest/virtual_camera_transport.md for the camera transport
validation and the hook installation prerequisites.