Todo iPhone lleva una "caja negra" llamada sysdiagnose: un archivo de diagnóstico del sistema al que los ingenieros de Apple recurren primero cuando algo falla. Mantén presionados los dos botones de volumen y el botón lateral durante aproximadamente un segundo, e iOS grabará uno en silencio en segundo plano. Una vez comprimido, sigue ocupando cientos de megabytes, repleto de ioreg, smcDiagnose, taskinfo, informes de fallos y datos de la química de la batería.

El inconveniente: nunca estuvo destinado para ti. Al descomprimirse, contiene miles de archivos y decenas de miles de líneas de texto sin formato. El valor que buscas está enterrado en la línea 10,000 de IODeviceTree.txt o dentro de algún nodo del controlador NVMe en IOService.txt. Incluso un desarrollador experimentado necesita diez minutos solo para encontrarlo.

Device Status⁺ convierte esa pared de texto en una pantalla de tarjetas legibles —completamente en el dispositivo, sin cargar un solo byte. Esta guía explica cómo funciona su Analizador de registros de diagnóstico (Diagnostic Log Analyzer), desde la captura de un sysdiagnose hasta la lectura de las tarjetas, y por qué tu teléfono no se bloqueará en el proceso.

¿Qué es Device Status⁺?

Device Status⁺ es una aplicación gratuita de monitoreo del sistema desarrollada por Space-Time Transformation Technology Co., Ltd. Requiere iOS 17.0+ y funciona en iPhone, iPad, Mac (serie M), Apple Vision Pro y Apple Watch. Junto a los paneles de CPU, memoria, almacenamiento, batería y red en tiempo real, incluye un Analizador de registros de diagnóstico dedicado para archivos sysdiagnose y un Analizador de registros de batería (Battery Log Analyzer) para el análisis diario de la batería (tratado en una guía separada).

Todo lo que se describe a continuación ocurre localmente. La pantalla de importación lo deja claro: "Todo el procesamiento ocurre en el dispositivo. No se sube nada."

¿Qué es exactamente un sysdiagnose?

Un sysdiagnose es una instantánea puntual de todo el sistema. Activada por la combinación de teclas del hardware, recopila:

• Volcados del árbol de dispositivos ioreg (IODeviceTree.txt, IOService.txt)
• Lecturas SMC (System Management Controller) y smcDiagnose
• Instantáneas de procesos taskinfo
• Informes de fallos agregados (.ips)
• Plists de la química de la batería e instantáneas del desgaste de la NAND
• Estado de la red, Wi-Fi y Bluetooth

El resultado es un archivo sysdiagnose_YYYY.MM.DD-...tar.gz que, una vez extraído, puede contener más de 2,400 entradas con cabeceras extendidas PAX. En un iPhone con restricciones de memoria, el enfoque obvio —"leer todo en la memoria y luego descomprimir"— provoca un cierre por memoria agotada (OOM). Por lo tanto, el analizador no hace eso.

Paso 1: Capturar el sysdiagnose

La parte más difícil no es el análisis. Es obtener el archivo. Device Status⁺ incluye una guía ilustrada (LogCollectionGuideView) que te lleva paso a paso a través de cada toque:

1. Mantén presionados ambos botones de volumen + el botón lateral durante aproximadamente un segundo, suéltalos tras la respuesta háptica: esto activa el sysdiagnose.
2. Sigue usando el teléfono con normalidad y espera aproximadamente 10 minutos para que finalice la recopilación.
3. Abre Configuración → Privacidad y seguridad → Análisis y mejoras → Datos de análisis y busca sysdiagnose.
4. Abre el archivo → Compartir → Guardar en Archivos → de vuelta en Device Status⁺, toca + para importarlo.

Para reducir a cero el paso de "encontrar la entrada", la guía ofrece dos atajos de un solo toque: instalar un Atajo (enlace de iCloud) y saltar directamente al panel de Análisis y mejoras mediante un esquema de Atajos.

Paso 2: Importar sin bloqueos de memoria

Aquí es donde el trabajo de ingeniería demuestra su valor. El SysdiagnoseArchiveExtractor ejecuta un pipeline de transmisión por secuencias (streaming) de dos etapas que procesa un archivo de 800 MB con solo unos pocos kilobytes de memoria de búfer.

Etapa 1: gunzip. Utilizando zlib con inflateInit2(16 + MAX_WBITS) para una decodificación compatible con gzip, el archivo de entrada se asigna a memoria mediante mmap (se pagina bajo demanda, nunca reside por completo) y la salida se escribe en un .tar temporal en bloques de 64 KB. La memoria máxima utilizada es solo el búfer.

Etapa 2: untar. Una máquina de estados escrita a mano analiza las cabeceras USTAR / GNU / PAX entrada por entrada y escribe cada una en el disco. Soporta nombres de archivo largos GNU (tipo L), cabeceras extendidas PAX globales y por entrada (x / g), y campos de tamaño base-256. El archivo nunca se retiene en su totalidad.

Los detalles de robustez importan tanto como el proceso:

• Verificación previa de espacio en disco. Tras el gunzip, una vez que se conoce el tamaño exacto del .tar, el analizador verifica volumeAvailableCapacity buscando "un archivo tar + un margen de seguridad" antes de continuar: ningún archivo extraído a medias llenará tu almacenamiento.
• Seguridad de ruta. isSafeRelativePath rechaza rutas absolutas, caracteres nulos \0 incrustados y recorridos de directorio mediante ... Nada se escribe fuera del sandbox.
• Controles de integridad. La validación de CRC e ISIZE se delega a zlib; un gzip truncado o corrupto aparece como un error legible (inflateFailed / truncatedArchive), no como un bloqueo silencioso.
• Limpieza del .tar temporal. Un defer lo elimina sin importar si hubo éxito o error, por lo que no quedan residuos de cientos de megabytes.

Durante la extracción, la interfaz de usuario muestra un panel de progreso que distingue entre "descomprimiendo gzip (N MB expandidos)" y "N archivos extraídos" dándote la certeza de que realmente está funcionando.

Importación con un toque mediante la extensión de compartir

Puedes omitir por completo el paso intermedio por la app Archivos. La extensión sharelog reconoce un archivo sysdiagnose_*.tar.gz directamente desde la lista de Datos de análisis. Lo más importante es que la extensión no realiza ningún análisis sintáctico (parsing): su límite de memoria es demasiado pequeño para descomprimir un sysdiagnose. Solo copia el archivo en el contenedor del App Group (ShareInbox/), escribe una señal pendiente en el UserDefaults del App Group y despierta la aplicación principal a través del esquema de URL devicestatus. La aplicación principal luego ejecuta la extracción, que exige muchos recursos. El resultado se siente como si se hiciera con un solo toque.

Paso 3: Leer la descripción general del dispositivo

El SysdiagnoseOverviewParser reconstruye la identidad del dispositivo a partir de tres fuentes:

• El primer bloque Properties: {…} en remotectl_dumpstate.txt → modelo, sistema operativo, número de serie, UDID, ChipID, plataforma SoC, código de región...
• "product-name" en ioreg/IOService.txt → nombre comercial (p. ej., iPhone 17), con un respaldo integrado de ProductType → nombre.
• El nombre de la carpeta raíz → marca de tiempo de la captura (compatible tanto con el formato de diferencia horaria +0800 como con el de hora local).

Cada campo conserva tanto su clave original como una etiqueta amigable (p. ej., ChipID / 33104), para que puedas verificar una tarjeta contra la línea de registro original.

Paso 4: Explorar las siete categorías

Esta es la decisión clave del producto: sin volcados de texto sin formato, solo las métricas clave extraídas de cada archivo como tarjetas. SysdiagnoseCategoryConfig mapea los miles de archivos en siete categorías mutuamente excluyentes, listando únicamente los archivos que tienen un extractor dedicado. Es por eso que el número en el distintivo es igual a la cantidad de tarjetas que realmente verás: nunca entras a una sección y te encuentras con nada.

Los detalles que solo un experto extraería

• Química de la batería (ACAM). Analiza com.apple.batteryintelligence.batteryalgorithms-OnDeviceACAM-state.plist en tres tarjetas:
  • Identidad de la batería: número de serie de la celda, si es original, límite de voltaje de carga.
  • Material activo: retención de material activo (QLi / Qn / Qp: la fracción utilizable de iones de litio / ánodo / cátodo).
  • Envejecimiento y resistencia: crecimiento de SEI, pérdida por fisuración / cambio de fase, resistencia de los electrodos. Estas son las métricas de salud microscópicas que normalmente solo se encuentran en las herramientas internas de Apple.
• Hardware de almacenamiento (NVMe + NAND). Del nodo del controlador NVMe en IOService.txt extrae el tipo de celda (SLC / MLC / TLC / QLC), tamaño de página, versión de firmware, operaciones y errores de lectura/escritura. De ASPSnapshots/asptool_snapshot.log extrae los conteos de arranque / ciclos de energía de la NAND, cantidades totales de lectura/escritura a lo largo de su vida útil, nivelación de desgaste y distribución por Band. En otras palabras: qué tipo de celda NAND tienes, cuánto se ha escrito en ella y cuánta vida útil le queda.
• Identificación del chip. El chip-id en IODeviceTree está en formato hexadecimal little-endian; el extractor lo convierte al "número T" amigable para ingeniería (p. ej., T8130), traduciendo un código opaco a un nombre en clave de silicio legible.

Técnicas de extracción que vale la pena conocer

• Los archivos grandes omiten el límite de vista previa. taskinfo, IODeviceTree.txt, IOService.txt y asptool_snapshot.log superan con creces el límite de vista previa de 4,000 líneas. Los extractores leen el archivo completo antes de analizarlo, por lo que el ranking de consumo de energía, los nodos de los chips, el controlador NVMe y el estado de la NAND nunca se pasan por alto.
• Consolidación multifile. Los CSV diarios de los ciclos de batería (BDC_Daily_*.csv) se contraen en una sola tarjeta de "ciclos de batería" (valor más reciente); todos los fallos .ips se agrupan en una única tarjeta agregada de "informes de fallos".
• Correlación entre archivos. El recuento de ciclos se lee tanto del valor B0CT actual del SMC como del historial BDC, para luego compararlos.

Historial y persistencia

Cada importación se guarda en Application Support/SysdiagnoseCases/<serial_timestamp>, con sus metadatos en SysdiagnoseHistoryStore. Reimportar el mismo archivo reutiliza la extracción existente (se ignoran duplicados mediante caseId). La lista admite deslizar para eliminar y borrar todo, y se vuelve a abrir instantáneamente, porque solo analiza de nuevo la descripción general, sin tener que ejecutar nuevamente la extracción.

Tres promesas integradas

1. Totalmente offline y en el dispositivo. Desde la descompresión hasta la extracción, no se realiza ninguna solicitud de red.
2. Legibilidad por encima del rendimiento. El objetivo final de cada análisis es una tarjeta, no el texto sin formato. Los campos originales se conservan para verificación cruzada, pero están ocultos de forma predeterminada.
3. Robustez de nivel de producción:
   • Protección contra recorrido de directorios (path-traversal), verificación previa de espacio en disco, validación de cabeceras tar y limpieza garantizada de archivos temporales.
   • Medidas de seguridad en el renderizado de archivos: SysdiagnoseFileContent limita el texto a 512 KB / 4,000 líneas y los CSV a 1,000 líneas; los extractores leen los archivos completos como respaldo, por lo que un solo archivo nunca puede agotar la memoria.
   • Traducción de errores legibles para humanos (convirtiendo inflateFailed en "el archivo está dañado o la descarga estuvo incompleta").
   • Compatibilidad de rutas entre lanzamientos (manejando tanto nuevas rutas relativas como rutas de sandbox absolutas heredadas).

Reflexiones finales

El Analizador de registros de diagnóstico no intenta mostrar los más de 2,000 archivos que hay en un sysdiagnose. Responde a las preguntas que realmente te haces — ¿Qué hardware estoy utilizando? ¿Está sana mi batería? ¿Qué tan desgastado está mi almacenamiento? ¿Por qué se bloqueó recientemente? — y te ofrece respuestas limpias, compartibles y verificables.

La captura está guiada, la importación es de un solo toque, la descompresión nunca agota la memoria y la pantalla solo muestra tarjetas. Para el compañero a largo plazo (las tendencias diarias de salud de la batería extraídas de los registros de análisis), consulta la guía del Analizador de registros de batería.