Das Offset-Problem, über das keiner spricht

Du hast ein Kernel-Read/Write-Primitive auf iOS. Glückwunsch – und jetzt? Die Jailbreak-Research-Community investiert enorm in die Gewinnung von Primitives, dokumentiert aber kaum, was in den zehn Minuten danach passiert. Ein Post vom 5. April 2026 auf reversesociety.co ändert das – er zeigt eine wiederholbare Methodologie zur Extraktion von Struct-Offsets aus stripped XNU-Kernelcaches, validiert auf iOS 16.7.12 auf einem iPhone X (Build 20H364) mit Binary Ninja, ohne Kernel Development Kit.

Ausgangspunkt war ein Kernel-R/W-Primitive, das Opa334 teilte und das strukturell dem in der DarkSword-Malware genutzten ähnelt. Dieses Detail ist bemerkenswert: Die Technik, die ein Forscher nutzt, um proc-Offsets auf einem Test-Gerät zu mappen, ist dieselbe, die ein Malware-Autor in einer dokumentierten Threat-Campaign einsetzte. Die Methodologie ist neutral. Die Absicht nicht.

←HEUTE: iOS 16.7.12-Kernelcaches werden stripped ausgeliefert – keine Symbole, rohes ARM64, vollständiger KASLR in Kraft.
→3012: Während Embedded-Firmware härtet und BACnet-Controller ARM-Kerne adoptieren, zieht die Offset-Extraktions-Disziplin von Jailbreak-Research in Smart-Building-Sicherheits-Audit-Workflows.
Fulcrum: Die gleiche Cross-Referencing-Methode, die heute eine proc-Struktur mapped, wird morgen eine Building-Automation-Controller-Memory-Layout mappen.

Die Systemarchitektur hinter der Technik

XNU ist Apples Open-Source-Hybrid-Kernel – aber der iOS-Production-Build weicht von der veröffentlichten Quelle ab. Kernelcaches aus IPSW-Firmware-Paketen kommen ohne Symbole an. Das klingt wie eine Sackgasse. Es ist keine, aus einem strukturellen Grund: Die Namen exportierter Accessor-Funktionen bleiben auch in stripped Binaries erhalten.

Das ist die tragende Einsicht. Funktionen wie proc_pid(), vnode_mount() und kauth_cred_getuid() sind dünne Wrapper – eine Load-Instruction, ein Return. In Binary Ninja dekompiliert (oder IDA Pro mit Hex-Rays oder Ghidra), geben sie den Field-Offset direkt preis:

// _proc_pid at 0x5c892c
return *(arg1 + 0x60);

Diese einzelne ldr w0, [x0, #0x60] sagt dir: struct proc hat p_pid bei Offset +0x60, und das w-Register (nicht x) bestätigt, dass es 32-Bit ist. Wiederhol das über kauth_cred_getuid, kauth_cred_getruid, vnode_vtype, und du hast eine funktionierende Offset-Tabelle – komplett aus dem Binary gebaut, kein Debugger angehängt.

Der Workflow läuft in drei Phasen. Erste: Lokalisiere die Kernel-Base, indem du rückwärts liest, bis du das Mach-O-Magic (0x100000cfeedfacf) findest, dann berechne den KASLR-Slide. Zweite: Finde Anker-Globals – allproc, kernproc, nprocs – via adrp/ldr-Instruction-Paare im __DATA-Segment; das sind Einstiegspunkte in Kernel-Datenstrukturen von einer bekannten Adresse. Dritte: Arbeite die Accessor-Funktionen systematisch ab, nutze die XNU-Open-Source-Release als Map (Feldnamen, Struct-Header), aber niemals als Wahrheit – Apple addiert, entfernt und sortiert Felder zwischen Versionen um. Der proc_ro-Split, eingeführt in iOS 15.2+, erscheint in älteren XNU-Source-Releases überhaupt nicht.

Das ipsw-Extraction-Tool behandelt Kernelcache-Decryption; blacktop/symbolicator kann eine partielle Symbol-Tabelle wiederherstellen, um manuelle Suche zu reduzieren. Der Author überging absichtlich das Kernel Development Kit, um direkte ARM64-Assembly-Arbeit zu erzwingen – eine Disziplin-Wahl, die portablere Ergebnisse liefert.

Was das am Schreibtisch diese Woche bedeutet

PAZ-Leser, die iPhones und iPads vor Ort deployen – für Autodesk BIM 360-Model-Review, AR-Messungen oder Site-Dokumentation – laufen auf der gleichen Kernel-Attack-Surface, die diese Methodologie exponiert. Ein kompromittiertes Kernel-R/W-Primitive auf einem Field-Device ist kein theoretisches Risiko: es ist die Vorbedingung für Credential-Diebstahl, Process-Injection oder stille Daten-Exfiltration aus Project-Storage. Der EU Cyber Resilience Act (CRA), in Kraft ab Ende 2027, wird Vendors von Connected Products – inklusive Mobile-BIM-Viewer, die in Europa verteilt werden – verlangen, Vulnerability-Handling und Patch-Timelines zu dokumentieren. Zu wissen, wie ein Post-Primitive-Offset-Extraction-Angriff aussieht, ist Teil des Threat-Modells, das deine MDM-Policy berücksichtigen muss.

Die Methodologie-Transferierbarkeit ist der schärfere Punkt für technisch orientierte Leser. Binary-Analysis-Tools – Binary Ninja, Ghidra – sind nicht iOS-spezifisch. Die gleiche Accessor-Funktions-getriebene Offset-Recovery, die eine ucred-Struktur mapped, gilt für ARM-basierte BACnet-Controller, IoT-Sensoren und Building-Automation-Firmware. Siguza’s frühere Arbeiten zu iOS-Kernel-Internals (öffentlich dokumentiert seit 2016) und Google Project Zero’s iOS-Research etablieren, dass diese Technik-Klasse von beiden Verteidigern und Angreifern gut verstanden wird. Die Lücke ist fehlende Dokumentation für Engineers, die nicht Vollzeit-Security-Researcher sind.

Atelier: Wenn dein Büro eine iPad-Flotte für Site-BIM verwaltet, führe jetzt eine Firmware-Audit-Baseline durch: bestätige, dass Geräte auf iOS 16.7.12 oder aktuell sind, dokumentiere deinen MDM-Enrollment-Status, und flagge sideloaded Apps an deinen IT-Security-Contact. Ein stripped Kernelcache reicht aus, um dein Project-Network zu mappen, wenn ein Attacker bis zu einem Kernel-Primitive kommt – die obige Methodologie zeigt exakt, wie schnell diese Eskalation voranschreitet.

Hole dir den reversesociety.co-Post, öffne Binary Ninja’s Free-Tier gegen einen decrypted Kernelcache (nutze ipsw zum Extrahieren), und trace einen Accessor – _proc_pid ist der klarste Startpunkt. Selbst wenn Kernel-Sicherheit nicht deine Domain ist, transferiert sich die Binary-Lesedisziplin direkt auf Firmware-Analyse von embedded Building-Systemen. Mach es einmal auf einem Known-Good-Target und du verstehst die Attack-Surface deiner Smart-Building-Infrastruktur auf eine Art, die dir kein Vendor-Datasheet geben wird.

Quelle: Hacker News