
iOS 27 kernelcache RE: SEP-Dispatch-Map, AMFI-Diff, Ghidra-Workflow
Linux-nativer Cross-Compiler + PoC für die Aktivierung des iOS AMFI Developer Mode (arm64/arm64e)
Forschungs-Toolkit. Vergleiche die Firmware iOS 27.0.1 mit 27.2, reverse-engineere die AMFI-
IOUserClient-Dispatch-Tabelle, cross-compiliere einen Bare-Metal-IOKit-PoC von Linux aus — kein Xcode erforderlich — und aktiviere den Developer Mode auf iOS 27.0.1 über das standardmäßige Apple-Lockdown-Protokoll (verifiziert persistent auf Kernel-Ebene). Aktueller wichtigster Befund: stille ASTC/DDS-Overflow-Härtung in ImageIO, strukturell erreichbar über den generischen Decode-Pfad — MediaAnalysis-Kette bisASTCReadPlugin::initializezurückverfolgt (Sessions 28–31).
IOExternalMethodDispatch-Slot kartiert, selector 11 = armSecurityBootMode identifiziert.poc/poc.c öffnet AppleMobileFileIntegrity/AppleCredentialManager, ruft armSecurityBootMode auf und protokolliert das Ergebnis. Kein Foundation/UIKit-Ballast — reines C + IOKit.poc/build_ipa.sh erzeugt eine signierte .ipa auf CachyOS/Arch mit clang + ld64.lld + ldid. Null Apple-/Xcode-Abhängigkeiten.Die iOS-Developer-Mode-Toggle-Kette kann vollständig über das standardmäßige Apple-Lockdown-Protokoll (com.apple.amfi.lockdown) gesteuert werden. Kein Jailbreak, keine IPA, keine Entitlement-Fälschung — nur pymobiledevice3 unter Linux.
Verifiziert: Nach der untenstehenden Kette lieferte mounter query-developer-mode-status → true und das DeveloperDiskImage wurde unter /System/Developer gemountet — und beides überstand einen unabhängigen Neustart (dieselben Prüfungen sprangen zuvor auf false zurück, daher ist die Persistenz der eigentliche Beweis; siehe FINDINGS_LOCK.md).
Entferne den Passcode (Einstellungen → Face ID & Code → Code ausschalten).
Bei gesetztem Passcode antwortet AMFI auf action=1/action=2 mit Device has a passcode set.
# 1) enable → action=1 → REBOOT #1
flatpak-spawn --host python3 -m pymobiledevice3 amfi enable-developer-mode
# 2) after the device boots: post-restart accept → action=2 → REBOOT #2
# (the CLI has no separate accept command — call the service method directly,
# e.g. via poc/verify_now2.py)
# 3) reveal the Settings toggle → action=0
flatpak-spawn --host python3 -m pymobiledevice3 amfi reveal-developer-mode
flatpak-spawn --host python3 -m pymobiledevice3 mounter query-developer-mode-status # → true
flatpak-spawn --host python3 -m pymobiledevice3 mounter list # → IsMounted: true, /System/Developer
flatpak-spawn --host python3 -m pymobiledevice3 mounter auto-mount # → DeveloperDiskImage mounted successfully
| Aktion | Bedeutung | Wirkung |
|---|---|---|
0 | reveal | Zeigt den Schalter für den Entwicklermodus in den Einstellungen an |
1 | enable | Setzt das Flag, startet das Gerät neu |
2 | accept | Bestätigung nach dem Neustart, startet erneut neu |
⚠️
pymobiledevice3bricht vorzeitig ab: Wenn der Status bereitstrueist, protokolliertenable-developer-modelediglich „Developer mode is already enabled" und sendet nichts. Die beiden Neustarts sind Teil des Apple-Protokolls, nicht zufällig.
sudo pacman -S clang lld zip # compiler + Mach-O linker
yay -S ldid # entitlement injector (AUR)
# iOS SDK:
mkdir -p poc/SDK
git clone https://github.com/theos/sdks poc/tmp && mv poc/tmp/iPhoneOS*.sdk poc/SDK/iPhoneOS.sdk
cd poc
IOS_SDK=/path/to/iPhoneOS.sdk ./build_ipa.sh
# Output: EnableAMFIDevMode.ipa
# Via ideviceinstaller (libimobiledevice):
ideviceinstaller --install EnableAMFIDevMode.ipa
# Via TrollStore (if jailbroken/CT-bypass device):
# → TrollStore app → "+" → pick EnableAMFIDevMode.ipa
# Via SideStore/AltStore:
# → Add to SideStore → sign with your Apple ID
# On device (SSH / NewTerm):
./EnableAMFIDevMode 1
cat /tmp/amfi_devmode_poc.log
# Then REBOOT to activate Developer Mode
run_dvt.sh)Es existiert ein zweiter, IPA-freier Weg: das eigenständige IOKit-Binary unter Linux cross-kompilieren und
es über den iOS 17+ CoreDevice-/RSD-Tunnel auf das Gerät übertragen und es dann mit dem
DVT-Prozesssteuerungsdienst ausführen (außerhalb der App-Sandbox — kein installd, keine mit einem kostenlosen Zertifikat signierte IPA).
./run_dvt.sh enable # build (clang + ld64.lld) → deploy → `dvt launch --stream`
run_dvt.sh automatisiert die gesamte Kette:
usbmuxd, prüft das Gerät mit ideviceinfo (libimobiledevice);poc/poc.c cross zu einem reinen arm64 Mach-O (ohne Apple-Toolchain):
clang -c → ld64.lld -platform_version ios … -syslibroot … -undefined dynamic_lookup;
die SDK-Version wird aus der binären SDKSettings.plist über plistlib gelesen;dvt launch --stream auf.Status: Die Linux-Cross-Kompilierung funktioniert (es wird ein echtes
arm64Mach-O erzeugt). Der Deploy-Schritt auf dem Gerät ist noch WIP — sieheHANDOFF.md«Сессия 12». Beachte außerdem, dass der IOKit-Pfad des PoC (AppleMobileFileIntegrity-Selector 11) das plattformbeschränkte Entitlementcom.apple.private.amfi.developer-mode-controlerfordert, sodass eine nicht von Apple signierte Binärdatei vom Userclient abgelehnt wird, selbst wenn sie über DVT gestartet wird — der unterstützte Weg zum Aktivieren des Entwicklermodus ist das oben dokumentierte Lockdown-Protokoll.
Zwei saubere Schritte pro Architektur-Slice (verhindert, dass der clang-Treiber -arch/-platform_version verschluckt, wenn er an ld64.lld delegiert):
-arch arm64 -platform_version ios <min> <sdk>Erkennt automatisch clang-20...15, ld64.lld/lld, llvm-lipo, ldid. Sanfter Fallback: arm64e → arm64, wenn die Toolchain keine ptrauth-Unterstützung bietet.