iOS 16.5 auf einem Android-Smartphone: Booten ganz ohne Flashen

iOSAndroidXNUOpen SourceReverse Engineering

Quellen:HackiOS-Projektrepo + HN-Diskussion

Android-Smartphone startet – und auf dem Display erscheint iOS 16.5

Ein Xiaomi POCO X5 Pro 5G in der Hand: Sperrbildschirm, Systemgesten, Kontrollzentrum – alles sieht aus und reagiert wie unter iOS 16.5. In den Einstellungen unter „Allgemein“ weist sich das Gerät als iPhone X aus. Dabei wurde das Smartphone weder geflasht noch wurden Partitionen verändert. Das gesamte System startet per fastboot boot direkt aus dem Arbeitsspeicher (RAM). Ein kurzer Neustart genügt, und das Gerät kehrt unverändert zu Android zurück.

Möglich macht dies das Open-Source-Projekt HackiOS: Apples quelloffener XNU-Kernel (xnu-8796.121.2, passend zu iOS 16.5) wurde auf die Snapdragon-Plattform portiert. Daraufhin startet ein aus einer offiziellen IPSW-Datei extrahierter, vollkommen unmodifizierter iOS 16.5 Userspace: launchd, backboardd und SpringBoard initialisieren sauber, und Standard-Apps lassen sich öffnen. Nach der Veröffentlichung des Repositorys am 22. Oktober sammelte das Projekt binnen 24 Stunden 489 Stars und 93 Forks.

Was dieser Versuch in der Praxis demonstriert, geht weit über die Frage hinaus, ob sich iOS portieren lässt: Die eigentliche Mauer zwischen mobilen Betriebssystemen steht keineswegs beim Kernel – sie besteht aus proprietären Treibern und Firmware-Schichten.

iOS 16.5 Homescreen auf einem Android-Smartphone Abbildung: iOS-Homescreen auf einem Android-Gerät. Quelle: HackiOS-Repository

Der Kernel war schon immer Open Source – dort lag das Hindernis nie

Der XNU-Kernel wird von Apple bereits seit dem Jahr 2000 öffentlich bereitgestellt. Der Quellcode der Kernel von macOS und iOS ist für jeden frei einsehbar; die Apple Public Source License (APSL) gestattet Anpassungen und die Weitergabe. Das HackiOS-Repository enthält folgerichtig keine einzige Zeile urheberrechtlich geschützten Apple-Code. Der Userspace wird von jedem Nutzer selbst aus offiziellen Firmware-Paketen extrahiert, was rechtliche Distributionsprobleme von vornherein vermeidet.

Wäre der Kernel der limitierende Faktor für die Portabilität mobiler Betriebssysteme gewesen, hätte dieser Durchbruch schon vor zwanzig Jahren gelingen müssen. Dass es so lange dauerte, hat einen simplen Grund: Sobald der Kernel gebootet ist, muss er mit der Hardware interagieren – und dafür braucht es Treiber. Die Treiber für Apple Silicon und proprietäre Peripheriegeräte liegen jedoch ausschließlich als geschlossene Binärdateien vor, streng unter Verschluss bei Apple.

HackiOS löst dieses Problem durch einen vollständigen Austausch dieser Schicht: Ein eigens entwickelter EFI-Loader steuert den Bootvorgang, eigene Treiber ersetzen Apples geschlossene Module, UEFI wurde auf das Gerät portiert und eine Kompatibilitätsschicht bindet Linux-WLAN-Treiber ein. Da die Linux-Community bereits funktionierende Treiber für Snapdragon-Chipsätze entwickelt hat, leiht sich die iOS-Umgebung diese über die Kompatibilitätsschicht einfach aus. Die Bootkette ist klar strukturiert: fastboot boot lädt die angepasste UEFI-Umgebung (aus Project Silicium), UEFI führt die EFI-Anwendung xnuloader aus, und diese übergibt die Kontrolle an den maßgeschneiderten Kernel.

Den Kernel kann man aus Open-Source-Quellen übernehmen – die Treiber hingegen müssen Schicht für Schicht neu geschrieben werden. Genau hieran lässt sich die tatsächliche Dicke der Plattformbarriere bemessen.

Einstellungsseite Allgemein zeigt als Modell iPhone X an Abbildung: Einstellungen > Allgemein weist das Gerät als iPhone X aus. Quelle: HackiOS-Repository

Was funktioniert, was scheitert – und ein bezeichnendes Detail

Der Umfang der funktionierenden Komponenten übertrifft die Erwartungen: Sperrbildschirm, Wischgesten, Kontrollzentrum, Einstellungen und die darin enthaltenen Apps lassen sich problemlos bedienen. In den Screenshots der Projekt-README finden sich der Homescreen, Uhr, Kalender, Musik, Wallet, Karten und Nachrichten. Selbst die Benutzeroberfläche des App Store rendert ihre Reiter – Inhalte lassen sich allerdings nicht laden und der Login per Apple ID scheitert, da der Hardware die Secure Enclave von Apple fehlt.

Die nicht funktionsfähigen Features liefern jedoch fast noch mehr Erkenntnisse: Mobilfunk und Bluetooth verweigern den Dienst. Die Ursache führt direkt zurück zur Treiberfrage: Der Firmware-Handshake für Baseband-Modem und Bluetooth liegt auf der tiefsten Ebene proprietärer Ketten, die sich durch einfache Übersetzungsschichten nicht überbrücken lässt. Ausgerechnet diese beiden Funktionen markieren die Grenze zwischen einem echten Smartphone und einem reinen Entwicklerboard mit grafischer Oberfläche.

Besonders aufschlussreich ist ein weiteres Detail: Unter dem modifizierten Kernel funktioniert das Laden des Akkus nicht – das Gerät entlädt sich kontinuierlich. Das USB-Power-Delivery-Management basiert auf einem weiteren proprietären Firmware-Protokoll, zu dem die Entwickler noch keinen Zugang gefunden haben. Ein Smartphone, das sich trotz eingestecktem Ladekabel weiter entlädt, führt den verbleibenden Treiberaufwand anschaulicher vor Augen als jedes Architekturdiagramm.

Kontrollzentrum Abbildung: Kontrollzentrum. Quelle: HackiOS-Repository

Auch die Hürde der Kameratreiber wurde genommen

In den Diskussionsforen galt das größte Interesse dem Kameramodul. Im Ökosystem mobiler Linux-Distributionen zählt die Kamera traditionell zu den komplexesten Baustellen. In der Feature-Matrix des Projekts sind für Camera.app jedoch Front- und Hauptkamera, Live-Vorschau, Autofokus sowie HEIC-Fotoaufnahmen als voll funktionsfähig vermerkt. Nachdem die Pipeline für GPU-Displayausgabe gemeistert war, gelang auch die Anbindung der Kamera.

Große Aufmerksamkeit erregte zudem ein Vermerk in der Versionsverwaltung: Git-Commits tragen die Zeile Co-Authored-By: Claude Opus 5.5. Die Dokumentation beschreibt den Einsatzzweck präzise: Das Projekt versteht sich als experimenteller Test-Bench für Forschungszwecke, nicht als alltagstaugliches Custom-ROM. Jede Sitzung läuft bewusst nur für eine festgelegte Anzahl von Sekunden, woraufhin der Kernel sauber zurückgesetzt wird. Das sorgt für bereinigte Logs und ermöglicht automatisierten KI-Agenten das iterative Arbeiten innerhalb definierter Grenzen. Vor der Veröffentlichung des Codes am 22. Oktober kursierten lediglich Demos ohne Bauanleitung, was Skepsis bezüglich der Reproduzierbarkeit weckte. Mit dem Quellcode-Release verstummten diese Zweifel schlagartig.

Hinter dem Entwicklerteam OOSEX GANG stehen vier Personen: initiiert von @oodze, mit Unterstützung von @netusd, @wannqn und @hxfuxyyXD. Vier Entwickler erreichten im Zusammenspiel mit modernen KI-Programmierwerkzeugen ein Resultat, für das früher ein ganzes Reverse-Engineering-Team erforderlich gewesen wäre.

Das Technologie-Narrativ der Hersteller auf den Prüfstand gestellt

Hersteller haben über Jahre das Narrativ gepflegt, iOS und Android seien auf fundamentalster Architekturebene inkompatibel und Welten voneinander entfernt. HackiOS zeichnet ein nüchterneres Bild: XNU lässt sich als Open-Source-Build nutzen, der Userspace kann direkt aus offiziellen Firmware-Images gestartet werden. Die wirkliche Abschottung existiert fast ausschließlich auf der Ebene proprietärer Treiber und Binär-Firmware – und diese Barriere speist sich aus technischem Entwicklungsaufwand und rechtlichen Risiken, nicht aus einer unüberwindbaren Betriebssystemarchitektur.

Dies erklärt auch, weshalb das Vorhaben ganz ohne Flashen auskommt: Das Betriebssystem verbleibt vollständig im RAM, ohne Speicherpartitionen anzutasten. Für das Gerät besteht keinerlei Brick-Risiko, und auch für die geschäftlichen Ökosystem-Schranken der Hersteller erwächst daraus keine unmittelbare Gefahr: Ein Telefon ohne Mobilfunkanbindung taugt nicht zum Alltagsgerät. Das technische Narrativ wurde aufgebrochen, während die kommerziellen Geschäftsmodelle vorerst unberührt bleiben.

Hierin liegt der Wert von HackiOS: Es handelt sich um ein Forschungswerkzeug, nicht um ein Endkundenprodukt. Das Projekt macht sichtbar, dass die Entscheidung im Duell der mobilen Betriebssysteme nicht im Kernel fällt, sondern in jenen Treiber- und Firmware-Tiefen, die kein Hersteller freigeben will. Nun bleibt vor allem ein Meilenstein abzuwarten: der Tag, an dem der Mobilfunk online geht. Erst dann wird aus dem sich entladenden POCO tatsächlich ein funktionierendes iPhone.

Weiterführende Links:

  • HackiOS Repository (README, Commits und Screenshots)
  • Hacker News Diskussion (item?id=50196718)