El formato de archivo tracev3, explicado

En resumen. Un archivo .tracev3 es un flujo de chunks. Un chunk de encabezado describe la máquina y el arranque, los chunks de catálogo enumeran los procesos y subsistemas, y cada catálogo va seguido de chunksets: bloques comprimidos con LZ4 que contienen entradas firehose (los mensajes de registro), cadenas oversize y registros statedump y simpledump. El texto procede de los archivos uuidtext y dsc, y la hora, de timesync. Esta es la estructura que decodifica Unified Log Parser, mediante el analizador de código abierto de Mandiant compilado a WebAssembly.

La estructura que se describe a continuación sigue el trabajo público de ingeniería inversa de Mandiant (macos-UnifiedLogs) y de Joachim Metz (libyal dtformats). Apple no documenta el formato, y los campos marcados como desconocidos en esas fuentes también lo son aquí.

Chunks y preámbulos

Cada chunk empieza con un preámbulo de 16 bytes: una etiqueta de 32 bits, una subetiqueta de 32 bits y un tamaño de datos de 64 bits. Los chunks se rellenan hasta múltiplos de 8 bytes. Las etiquetas relevantes son:

Por tanto, un archivo siempre empieza con los bytes 00 10 00 00, y así es como el analizador lo reconoce, se llame como se llame.

Encabezado

El encabezado registra la base de tiempo de Mach (numerador y denominador), el tiempo continuo en que se inició el archivo, el desfase de zona horaria y el indicador de horario de verano, además de subchunks con la versión de compilación (por ejemplo 25G83), el modelo de hardware (Mac14,14), el UUID de arranque, el PID de logd y la ruta del archivo de zona horaria. El UUID de arranque vincula cada entrada a una sesión de arranque y a los registros timesync correctos. La pestaña Fuentes del analizador muestra estos valores.

Catálogo

Un catálogo describe las entradas de los chunksets que le siguen:

• una matriz de UUID: de los binarios que generaron entradas y de la caché compartida;
• una tabla de cadenas de subsistema y categoría;
• entradas de proceso: PID, ID de usuario efectivo, el índice del UUID del ejecutable principal y del UUID de la caché compartida, los UUID adicionales (bibliotecas cargadas) con sus direcciones de carga y los subsistemas que utilizó el proceso;
• descriptores de subchunk: intervalo de tiempo, tamaño sin comprimir y algoritmo de compresión de cada chunkset.

Las entradas firehose hacen referencia a su proceso mediante un par de identificadores que se resuelven en esta tabla, y a su subsistema mediante un pequeño índice.

Chunksets

Un chunkset es un bloque comprimido. La mayoría usan LZ4 con el encabezado de bloque bv41 de Apple (bv41- indica un bloque sin comprimir); las versiones más recientes también pueden usar LZBITMAP, que el analizador admite. Una vez descomprimido, un chunkset vuelve a ser una secuencia de chunks.

Firehose

Un chunk firehose tiene un preámbulo con un tiempo continuo base y, a continuación, las entradas. Cada entrada tiene un tipo de actividad (log, activity, trace, signpost, loss), un tipo de registro (Default, Info, Debug, Error, Fault o un tipo de signpost), indicadores, un ID de hilo, un delta de tiempo y un área de datos. Los indicadores señalan dónde está la cadena de formato: en el propio archivo uuidtext del proceso (ejecutable principal), en la caché compartida (dsc), en un desplazamiento absoluto o relativa a otro UUID. El área de datos contiene los argumentos: números, cadenas o referencias a datos privados y a cadenas oversize.

Oversize

Los argumentos demasiado grandes para la entrada se almacenan en chunks oversize, identificados por una referencia de datos. Pueden estar en un archivo posterior al de la entrada que apunta a ellos, por lo que un analizador debe conservar los datos oversize de un archivo a otro y volver a intentar resolver las entradas pendientes al final.

Statedump y simpledump

Los statedumps son instantáneas que un proceso escribe bajo demanda: un plist, un protobuf o un objeto personalizado con un título ("TCC Authorization Cache" es uno de ellos). Los simpledumps son mensajes cortos que registran launchd y algunos otros procesos sin cadena de formato.

uuidtext y dsc: el texto que falta

Un archivo uuidtext (/private/var/db/uuidtext/XX/…, donde XX es el primer byte del UUID y el nombre del archivo son los 30 dígitos hexadecimales restantes) comienza con la firma 0x66778899, enumera rangos del espacio de direcciones del binario, contiene las cadenas de formato correspondientes y termina con la ruta del binario. Un archivo dsc (uuidtext/dsc/<32 hex>, firma hcsd) hace lo mismo para toda la caché compartida de dyld y nombra cada framework que contiene.

Para reconstruir un mensaje, el analizador localiza el archivo correcto a partir del UUID del catálogo y de los indicadores de la entrada, lee la cadena de formato en el desplazamiento registrado y aplica los argumentos al estilo de printf: %d, %s, %@, %{public}s, %{private}@ y decodificadores de tipo como %{errno}d, %{uuid_t}.16P o %{bool}d. Los argumentos privados que no se capturaron aparecen como <private>.

timesync

Los archivos timesync contienen, para cada UUID de arranque, un encabezado (firma 0xbbb0, base de tiempo, hora de arranque) y registros que emparejan un tiempo continuo con una hora real. La hora real de una entrada es la hora del registro anterior más cercano más el tiempo continuo transcurrido, multiplicado por la base de tiempo: 125/3 en Apple silicon y 1/1 en Intel.

Qué implica esto en la práctica

• Recopile uuidtext, dsc y timesync junto con los archivos tracev3 (guía de recopilación).
• Aun así, espere algunas entradas "no resueltas": puede faltar una cadena en los archivos que Apple conservó.
• Compare las entradas importantes con log show. Validado con un archivo real, el analizador reconstruyó de forma idéntica alrededor del 99 % de los mensajes de registro, actividad y estado; los signposts difieren en la presentación.

Consulte el glosario para cada término o abra sus propios archivos en el analizador.