Cómo DevTeam conquistó el iPhone

 (fabiensanglard.net)
1 puntos por GN⁺ 2024-03-11 | 1 comentarios | Compartir por WhatsApp
  • El primer iPhone de 2007 no se activaba sin una suscripción a AT&T en Estados Unidos, y el iPhone Dev Team buscó públicamente una forma de usarlo con otras operadoras solo por software
  • El trabajo se organizó en 6 hitos: descifrar el firmware, saltarse la activación, obtener permisos de escritura, construir una toolchain ARM/Mach-O, ejecutar apps de terceros y quitar el bloqueo de operadora
  • Los primeros avances llegaron con el análisis del ramdisk y del DMG cifrado dentro de .ipsw, además de aprovechar una falla de retransmisión en la verificación de activación de lockdownd para llegar a la pantalla de inicio
  • El permiso de escritura se obtuvo cargando el ramdisk y el kernelcache en Recovery Mode, luego modificando fstab y Services.plist para que, en vez de quedar limitado a /root/Media mediante afcd, pudiera manejar el sistema de archivos raíz
  • El desbloqueo final se automatizó con anySIM, que volcaba, parchaba y volvía a subir el firmware del baseband, y luego ejecutaba AT+CLCK="PN",0,"00000000"; Apple respondió el 27 de septiembre de 2007 con el firmware v1.1.1

El iPhone de 2007 y el objetivo de DevTeam

  • Apple lanzó el iPhone el 29 de junio de 2007, con precios de $499 para el modelo de 4GB y $599 para el de 8GB
  • Al sacarlo de la caja, el iPhone estaba inactivo y solo mostraba la pantalla Connect to iTunes; el usuario tenía que suscribirse a AT&T desde iTunes
  • Incluso después de la suscripción, el equipo seguía bloqueado a AT&T
  • En Canadá no había plan inicial de lanzamiento del iPhone, y Apple cerró un acuerdo con Rogers junto con el iPhone 3G el 11 de julio de 2008
  • El objetivo del iPhone Dev Team era lograr, solo por software, que el dispositivo pudiera usarse con cualquier operadora, y publicaban con frecuencia sus avances en el blog iphone.fiveforty.net
    • El 3 de julio de 2007 publicaron 8 actualizaciones entre las 00:00 y las 21:00

Los 6 hitos de DevTeam

  • Para usar el dispositivo bloqueado como un smartphone normal, hacían falta los siguientes pasos
    • Acceso de lectura para entender el sistema: Break DMG Password
    • Salir del estado inactivo: Bypass Activation
    • Acceso de escritura para modificar el sistema: Get Write Access
    • Una Working Toolchain para crear ejecutables personalizados
    • Un Unlock para que el baseband pudiera conectarse con cualquier operadora
    • Una app para automatizar todo el proceso: Enable Third-Party Applications
  • Según Wayback Machine, al 6 de julio de 2007 ya se habían completado 2 de los 6 hitos, y el recorrido terminó el 12 de septiembre de 2007
  • En la página de estado archivada el 25 de septiembre de 2007 aparecían como completados Decrypt Firmware, Bypass Activation, Get Write Access, Get Working Toolchain, Enable Third-party Applications, Unlock Phone

Análisis de .ipsw y lectura del sistema de archivos

  • iTunes descargaba un archivo iPhone Software con extensión .ipsw para restaurar el dispositivo, y ese archivo tenía formato zip
  • Dentro de iPhone1,1_1.0_1A543a_Restore.ipsw venían una imagen de recuperación img2, la carpeta Firmware relacionada con el baseband, el kernel de iOS kernelcache y dos archivos DMG grandes
    • El tamaño total del archivo de restauración de iOS era de unos 105MiB
  • El primer DMG, 694-5259-38.dmg, era el ramdisk usado durante la restauración y no estaba cifrado, así que podía montarse con dd
  • Aunque el ramdisk no era todo el sistema de archivos de iOS, sí permitía ver las contraseñas del usuario mobile, que ejecutaba las apps, y de root, que ejecutaba el resto de los procesos, en /private/etc/master.passwd
  • El segundo DMG, 694-5262-39.dmg, era el sistema de archivos de iOS usado en la ejecución normal y sí estaba cifrado
    • La clave fue encontrada dentro de /usr/sbin/asr en el ramdisk
    • Como era una clave y no una passphrase, no se podía usar hdiutil, así que DevTeam escribió su propia herramienta de descifrado, vfdecrypt.c
    • Tras descifrarlo, obtuvieron acceso de lectura a todo el sistema de archivos en tiempo de ejecución

Bypass de activación

  • La activación normal involucraba a iTunes, al servidor de Apple albert.apple.com y a lockdownd en el iPhone
    • iTunes recopilaba DeviceID, IMEI e ICCID del equipo
    • Agrupaba esos tres valores en un token y lo enviaba al servidor de Apple
    • El servidor de Apple devolvía el token firmado con su clave privada
    • lockdownd, esperando por USB, validaba el token con la clave pública de Apple
    • Si el token venía de Apple y coincidía con la información del dispositivo, el estado cambiaba a Activated
  • El PhoneActivationServer de dvdjon parcheaba iTunes para que accediera al servidor de activación por HTTP en vez de HTTPS y redirigía la solicitud a su propio servidor
  • La clave no era crear un nuevo token firmado, sino reutilizar el mismo signed token capturado de una activación exitosa y devolverlo sin importar la entrada
  • Según explicó George Hotz, lockdownd no verificaba si DeviceID, IMEI e ICCID dentro de la respuesta coincidían con los valores reales
  • DevTeam creó una CLI tools que leía un signed token hardcodeado desde un plist y lo enviaba al iPhone, y luego la mejoró con iPhoneInterface, que funcionaba sin iTunes

Permiso de escritura y jailbreak

  • Un iPhone activado podía subir archivos como música y fotos desde iTunes, pero el proceso encargado de la carga, afcd, estaba encerrado en una chroot jail dentro de /root/Media
  • Solo la partición de usuario se montaba en lectura/escritura (rw), mientras que la partición del sistema era de solo lectura (r)
  • El objetivo era salir de esa chroot jail y poder escribir también en la partición del sistema; de ahí salió el término jailbreaking
  • El arranque del iPhone se dividía en modo normal y Recovery Mode
    • En modo normal, la secuencia era BootROM → LLB → iBoot → Kernel → Normal Mode, y cada etapa verificaba la firma de la siguiente
    • Recovery Mode se detenía en la etapa iBoot, donde iTunes cargaba el ramdisk y el kernelcache en RAM para entrar al modo de restauración
  • DevTeam investigó dentro de iTunesMobile.dll cómo escribía iTunes en el sistema de archivos durante la restauración, e identificó comandos como mount, umount y ditto
  • iPHUC era una herramienta CLI que se comunicaba con dispositivos en Recovery Mode mediante métodos privados de iTunesMobile.dll
    • El usuario ponía el equipo en Recovery Mode
    • Se enviaba el ramdisk al dispositivo y se cargaba en RAM
    • Se enviaba el kernelcache y se arrancaba el kernel apuntando al ramdisk
    • El equipo entraba en Restore Mode
  • El proceso real de jailbreak se lograba modificando fstab y Services.plist
    • En fstab, se cambiaba el montaje de la partición del sistema para que fuera rw en vez de solo lectura
    • En Services.plist, se creaba un segundo servicio afcd basado en / en lugar de /root/Media
    • Tras reiniciar, iTunes podía ver todo el sistema de archivos mediante afcd2, y tanto la partición del sistema como la de usuario quedaban en lectura/escritura
  • Más adelante, la activación y el acceso de escritura se automatizaron con la app de escritorio para Mac OS X INdependence

Toolchain y apps de terceros

  • Hay poca información pública sobre el proceso de la toolchain y la ejecución de apps de terceros, pero al menos 12 personas participaron en el trabajo
  • El 19 de julio de 2007 ya estaba lista una binutils toolchain orientada a ARM, lo que permitió ejecutar en el iPhone programas creados por el propio DevTeam
  • Con la ARM/Mach-O Toolchain de Nightwatch se compiló y ejecutó en el iPhone la primera aplicación independiente Hello World
  • GeoHotz explicó que, fuera de Apple, antes no existía esa combinación de Mach-O y ARM, así que hubo que escribirla manualmente
  • Otro objetivo de la toolchain era reconstruir MobileTerminal.h, que exponía funciones privadas de iTunesMobile.so, para comunicarse con afc sin ejecutar iTunes
  • Algunas presentaciones dicen que el kernel verificaba la firma del ejecutable antes de execl, pero se concluye que el primer iPhone no lo hacía y que eso parece haberse introducido en v1.1.1

Desbloqueo del baseband y anySIM

  • El iPhone se dividía entre la parte smartphone, donde corría iOS, y la parte baseband, encargada del teléfono y el módem
    • Cada sistema tenía su propia RAM, CPU, almacenamiento, firmware y oscilador
    • Ambos se comunicaban mediante comandos AT por una línea UART montada en /dev/tty.baseband
  • El comando AT necesario para el desbloqueo se conocía desde muy temprano
    • AT+CLCK="PN",0,"xxxxxxxx"
    • xxxxxxxx era la NCK o Network Control Key, y se creía que era única por dispositivo
    • El número de intentos estaba limitado a entre 3 y 10; después de eso, el firmware podía quedar bloqueado de forma rígida a AT&T
  • El baseband también tenía su propio BootROM y cadena de confianza, con verificación de firmas
  • MuscleNerd explicó que en el baseband no había una red de seguridad como DFU/Recovery Mode, así que tocar mal el NOR o las imágenes podía arruinar el dispositivo de forma permanente
  • En julio de 2007, DevTeam hizo ingeniería inversa del baseband dentro de .ipsw y también analizó /usr/local/bin/bbupdater del ramdisk para entender los comandos que subían un nuevo baseband
  • La primera CLI, iUnlock, necesitaba varios archivos como el firmware volcado nor y ICE03.12.06_G.fls
  • Después apareció la app más simple anySIM, que se podía copiar al teléfono y ejecutar con un solo botón
  • anySIM funcionaba en este orden
    • Abría /dev/tty.baseband y configuraba los parámetros del módem
    • Volcaba a /tmp el baseband de 4MiB, es decir, el NOR
    • Cargaba el baseband en RAM
    • Cargaba el secpack ICE03.12.06_G.fls obtenido del ramdisk
    • Parchaba en RAM los comandos del baseband para permitir el desbloqueo con cualquier NCK
    • Volvía a subir el baseband parcheado
    • Ejecutaba AT+CLCK="PN",0,"00000000" y AT+CLCK="PN",2

El truco de -0x400

  • En condiciones normales, el firmware del baseband parcheado no debería pasar la verificación de firma y la carga tendría que fallar
  • El bypass usaba un offset de minus 0x400
  • GeoHotz explicó que los primeros 0x400 bytes no se usaban antes de validar la firma, así que bastaba con empezar a escribir 0x400 bytes antes
  • Después, según explicaciones de lectores en Hacker News, el baseband recibía el nuevo firmware en bloques de hasta 0x800 bytes
    • No guardaba los 4MiB completos en RAM para luego verificar checksum y escribir a flash
    • Los bytes recibidos se escribían inmediatamente en flash, pero solo los primeros 0x400 bytes se almacenaban temporalmente en RAM
    • Al terminar la carga, el baseband verificaba el checksum
    • Si fallaba, esos primeros 0x400 bytes almacenados en buffer no se escribían a flash y se descartaban
  • El método -0x400 consistía en escribir primero datos basura 0x400 bytes antes de la ubicación original del firmware y luego enviar los 4MiB del firmware
    • El checksum fallaba y esos 0x400 bytes basura se descartaban
    • Pero el resto del nuevo firmware ya había quedado escrito en flash en la posición correcta

El final y el juego del gato y el ratón que vino después

  • La guía completa para hacer el desbloqueo por software se publicó el 12 de septiembre de 2007
  • Junto con ella se publicaron casos de éxito por continente, incluyendo uno de Canadá
  • Apple respondió rápido con el lanzamiento del firmware v1.1.1 para iPhone el 27 de septiembre de 2007
  • La barra de progreso de DevTeam se reinició con Decrypt 1.1.1, Get Write Access 1.1.1, Activate 1.1.1, Unlock 1.1.1, Enable Third-party Applications 1.1.1
  • Desde ese momento empezó el juego del gato y el ratón entre Apple y la comunidad de hackeo del iPhone, y continuó después

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-03-11
Opiniones en Hacker News
  • Es un método común en actualizaciones de firmware. Los primeros 0x400 bytes son un encabezado que el cargador de la etapa anterior debe verificar antes de arrancar esta etapa, así que recibe los datos y los escribe libremente, pero no escribe el encabezado.
    Como no hay encabezado, no deriva en ejecución de código, así que es seguro; al final verifica la firma completa y, si pasa, escribe el encabezado para volver válida toda la imagen.
    El truco aquí es escribir primero 0x400 bytes de basura 0x400 bytes antes de la ubicación donde quieres escribir. Esa parte se trata como encabezado, solo se bufferiza y no se escribe realmente; el resto de los datos transferidos sí se escribe en la ubicación deseada. Después la verificación de firma falla y, como los primeros 0x400 bytes que originalmente no querías no se escriben, es un éxito.
    • A lo que llaman “modo de recuperación” creo que en ese momento se le decía modo DFU. Era “Device firmware update”, y no estoy seguro de si entonces lo llamaban “recovery”, porque ya pasaron más de 15 años.
    • iZsh(https://x.com/izsh1911) también podría saberlo, pero perdí contacto hace más de 10 años.
  • Como era de esperarse de un texto de Fabien, está bien escrito y es muy detallado. Recuerdo haber visto cómo analizaban en ese entonces este mecanismo de protección del iPhone; desde entonces ha sido un viaje realmente largo.
    Creo que todo quedaría completamente claro si alguien explicara más el desplazamiento de -0x400 aplicado antes de escribir los datos.
    • El desplazamiento de -0x400 parece funcionar más o menos así:
      con Seek(fd, 0xA0020000 - 0x400); se posiciona 0x400 antes del lugar donde deben escribirse los datos, y con SendWrite(fd, foo, 0x400, false); se rellenan con ceros los primeros 0x400 bytes que se quieren escribir.
      Luego, con SendWrite(fd, fw, fwsize, true); se rellenan los bytes restantes con los datos reales y se llama a SendEndSecpack(fd);. El iPhone copia los datos posteriores a los 0x400 bytes, es decir, todos los datos que querías escribir, y después intenta verificar la firma, que falla. Si la verificación de firma hubiera tenido éxito, los primeros 0x400 bytes que quedaron en cero también se habrían copiado en ese momento.
  • Para dejar constancia histórica: yo hice iPHUC, y se me ocurrió ese nombre cuando tenía 19 años. La persona que usaba el nick “nightwatch” fue una figura clave en el jailbreak inicial y en acuñar el término “jailbreak”, y fue realmente genial trabajar con él.
    Creo recordar que también estuvo a cargo del exploit de PDF o TIFF que desbloqueó la PSP. Vivía en algún lugar de Sudamérica, probablemente trabajando en una universidad, pero eso es todo lo que sé.
    Fue una época muy divertida y aprendí mucho. Sin embargo, George Hotz puso en riesgo la seguridad de algunas personas que ayudaron con el acceso a documentación en japonés, pese a repetidas solicitudes de que no lo hiciera; eso fue muy frustrante y finalmente fue la razón por la que el dev team dejó el proyecto.
    • Me viene a la mente que entre las personas que ayudaron a entender la arquitectura ARM había alguien con el nick “pineapple”. En ese entonces ARM era relativamente nuevo, y por eso las primeras interfaces de usuario tenían muchas piñas. Eran personas realmente buenas, y lamento no haber seguido en contacto.
    • Me gustaría saber más, dentro de lo que se pueda decir sin riesgo de una demanda por difamación, sobre cómo George Hotz puso en riesgo la seguridad de la gente.
  • La estructura de concatenar DeviceID, IMEI e ICCID para crear un token, enviarlo al servidor de Apple albert.apple.com para que lo firmara con la clave privada de Apple, y luego hacer que lockdownd en el dispositivo lo verificara con la clave pública de Apple y cambiara el estado a “Activated”, suena como un precursor del OAuth actual.
  • Ah, aquellos buenos tiempos. Cuando hackear el iPhone era fácil… o más que fácil, mucho más fácil que ahora.
  • Me da curiosidad con qué herramienta hicieron el diagrama de flujo. Parece basado en texto y hasta podría verse mejor que mermaid.
  • Como anécdota que recuerdo, yo estaba en el canal de IRC cuando el lanzamiento de iPhone OS 1.1 bloqueó el jailbreak. Uno de los métodos descubiertos entonces era hacer downgrade a 1.0.2, hacer jailbreak al teléfono y luego crear un enlace simbólico desde el directorio /root/Media, accesible desde iTunes, hacia /.
    Ese enlace se mantenía durante la actualización y, después de actualizar el firmware, se podía acceder a rootfs. En ese entonces no se llamaba iOS, sino iPhone OS.
  • En los primeros iPhone, parece que la “S” significaba seguridad. Fue consecuencia de intentar lanzar el primer producto.
    Es parecido a lo que pasa con las automotrices. Conviene no comprar los primeros años modelo de un producto o plataforma nuevos.
    • No hay consenso sobre qué significaba la “S”, y Apple tampoco lo explicó oficialmente. “Successor”, “Second” y “Speed” parecen más o menos plausibles, pero no hay una respuesta real.
      Por lo general, la “S” era una marca que indicaba una actualización menor frente al modelo base.