El problema fundamental que aborda HackiOS es la portabilidad y la interoperabilidad de sistemas operativos de propósito general en arquitecturas de hardware diversas, un desafío recurrente en la computación. Específicamente, busca demostrar la viabilidad de ejecutar un sistema operativo fuertemente acoplado a un ecosistema de hardware propietario, como iOS, en plataformas de hardware genéricas basadas en ARM. Esto es relevante en un contexto donde la virtualización y la abstracción de hardware son pilares de la infraestructura moderna, pero la portabilidad de kernels de sistemas operativos completos sigue siendo un área de investigación activa y compleja.
Históricamente, la portabilidad de kernels entre arquitecturas o plataformas de hardware dispares ha sido un esfuerzo monumental, a menudo requiriendo reescrituras significativas de drivers y subsistemas de bajo nivel. Proyectos como Linux en diversas arquitecturas ARM han demostrado la flexibilidad de kernels de código abierto, pero la adaptación de un kernel propietario como XNU de Apple, diseñado para un conjunto específico de SoC y periféricos, a hardware de terceros es un logro técnico notable. Este proyecto resalta la importancia de la abstracción de hardware y la modularidad en el diseño de kernels, incluso cuando no son explícitamente diseñados para ello.
Arquitectura del Sistema
La arquitectura de HackiOS se basa en una cadena de arranque personalizada y una serie de capas de abstracción para el hardware Android. El proceso comienza con el fastboot boot en el teléfono Android, que carga un cargador UEFI (Mu-Silicium, un port de Project Silicium) en RAM. Este UEFI, a su vez, lanza xnuloader, una aplicación EFI personalizada que es responsable de cargar el kernel XNU de iOS y la imagen del sistema en la RAM del teléfono.
El kernel XNU modificado (xnu-8796.121.2 de iOS 16.5) se ejecuta sobre esta plataforma. Las modificaciones incluyen la adaptación de la configuración base del BCM2837 (un SoC de Raspberry Pi) y la implementación de drivers específicos para el hardware del POCO X5 Pro 5G. Esto implica la creación de reemplazos para subsistemas clave de Apple, como IOSurface, IOMobileFramebuffer, AppleKeyStore y el stack de red. Para la GPU (Adreno 642L), se utiliza Mesa/freedreno, y para Wi-Fi (WCN6750), se emplea el driver ath11k de Linux a través de una capa de compatibilidad LinuxKPI. El almacenamiento persistente se maneja con APFS, con la imagen del sistema en RAM y el volumen raíz de iOS en el flash del teléfono. Se utilizan sustitutos para minicrypto (en lugar de corecrypto) y para las políticas de seguridad AMFI y Sandbox.
Una vez que el kernel XNU está operativo, lanza el userspace de iOS 16.5 sin modificar. Esto incluye launchd, backboardd, SpringBoard y las aplicaciones de iOS. La interacción entre el kernel y el userspace se mantiene intacta, con la excepción de la inyección de librerías personalizadas (usando DYLD_INSERT_LIBRARIES a través de kern.exec_inject) en procesos clave como backboardd, SpringBoard y mediaserverd para proporcionar servicios HID virtuales y dispositivos de audio personalizados (RedwoodAudio.driver).
Flujo de Arranque de HackiOS en POCO X5 Pro 5G
- 1 Android Fastboot El teléfono arranca en modo fastboot, se usa `fastboot boot` para cargar el U...
- 2 UEFI (Mu-Silicium) Cargado en RAM, proporciona un entorno de arranque compatible con EFI.
- 3 xnuloader (EFI App) Aplicación EFI personalizada que carga el kernel XNU y la imagen del sistema ...
- 4 XNU Kernel (Modificado) El kernel de iOS 16.5 con parches para hardware Android y drivers personaliza...
- 5 iOS 16.5 Userspace Procesos de usuario de iOS (launchd, SpringBoard, apps) se ejecutan sin modif...
- 6 Inyección de Librerías Librerías personalizadas inyectadas en procesos clave para servicios HID/Audio.
- 7 Interacción con Hardware Drivers personalizados (GPU Adreno, Wi-Fi ath11k, Touchscreen) interactúan co...
- 8 Sesión de iOS El usuario interactúa con iOS; al finalizar, el kernel devuelve el control al...
| Capa | Tecnología | Justificación |
|---|---|---|
| orchestration | UEFI (Mu-Silicium) | Proporciona el entorno de arranque de bajo nivel y la interfaz para cargar el cargador personalizado. |
| orchestration | xnuloader | Cargador EFI personalizado responsable de preparar el entorno y cargar el kernel XNU y la imagen del sistema en RAM. |
| compute | XNU Kernel (iOS 16.5) | El núcleo del sistema operativo, modificado para ejecutarse en hardware Android, gestionando recursos y proporcionando servicios de bajo nivel. Parches para BCM2837 como base, drivers personalizados para hardware Android. |
| compute | iOS 16.5 Userspace | El entorno de usuario completo de iOS, incluyendo `launchd`, `SpringBoard` y aplicaciones, ejecutándose sin modificaciones. |
| networking | ath11k (Linux Wi-Fi driver) | Driver de Wi-Fi adaptado para el kernel XNU a través de una capa de compatibilidad `LinuxKPI` para el chip WCN6750. |
| compute | Mesa/freedreno | Implementación de OpenGL ES para la GPU Adreno 642L, permitiendo la renderización de CoreAnimation y otras interfaces gráficas de iOS. |
| storage | APFS | Sistema de archivos de Apple utilizado para gestionar el almacenamiento, con la imagen del sistema en RAM y el volumen raíz en el flash del teléfono. |
| security | minicrypto | Sustituto de `corecrypto` de Apple para operaciones criptográficas. vs corecrypto |
| security | AMFI / Sandbox stand-ins | Implementaciones sustitutas de las políticas de seguridad de Apple para la integridad del código y el sandboxing de aplicaciones. vs AMFI, Sandbox |
Trade-offs
Ganancias
- ▲ Portabilidad del kernel XNU a hardware no-Apple
- ▲ Ejecución del userspace de iOS sin modificar
- ▲ Flexibilidad de desarrollo e investigación en un entorno controlado
Costes
- ▲ Funcionalidad incompleta (ej. celular, Bluetooth, carga, Secure Enclave)
- △ Rendimiento potencialmente inferior al nativo
- ▲ Complejidad de la cadena de herramientas y configuración
ios165/fetch.sh # downloads 7.4 GB from Apple's CDN and extracts what is needed (5-15 min)
common/build.sh qemu-virt # builds the APFS images (and the kernel, if the toolchain is there)
common/run.sh qemu-virt # a 20-minute session in a QEMU window./xl enter # Android -> fastboot -> our loader in RAM (fastboot boot); it brings up its own USB link
./xl ramdisk # upload the system image into the phone's RAM (2.5 GB, ~80 s), once per loader session
XL_SECS=900 XL_CMDLINE="touchscreen=1 cpufreq=1 bootcpu=7 cpus=8 gpu=1 wifi=1 adsp=1" ./xl run
./xl screenshot shot.png
./xl reboot # back to AndroidFundamentos Teóricos
Este proyecto se conecta directamente con los principios de la virtualización de hardware y la abstracción de sistemas operativos, conceptos explorados en profundidad en la literatura académica desde los primeros días de la computación. La idea de un 'hypervisor' o 'monitor de máquina virtual' (VMM) se remonta a los trabajos de IBM en los años 60 y 70, como el sistema CP/CMS. Aunque HackiOS no es un hypervisor en el sentido estricto de virtualizar una máquina completa, comparte el objetivo de aislar un sistema operativo de su hardware subyacente y presentarle una interfaz de hardware virtualizada o adaptada.
Los desafíos de portar un kernel a una nueva plataforma de hardware son análogos a los problemas de diseño de sistemas operativos distribuidos donde la heterogeneidad es la norma. La necesidad de reemplazar drivers propietarios y adaptar el kernel para interactuar con periféricos no nativos es un ejemplo práctico de la capa de abstracción de hardware (HAL) y la importancia de una interfaz bien definida entre el kernel y el hardware. La investigación en sistemas operativos ha enfatizado durante mucho tiempo la separación de preocupaciones y la modularidad para facilitar la portabilidad, aunque kernels monolíticos como XNU a menudo presentan desafíos únicos en este aspecto. El uso de LinuxKPI para el driver Wi-Fi es un ejemplo de reutilización de código y adaptación de interfaces, un tema recurrente en la ingeniería de software de sistemas.