Análisis forense de knowledgeC.db: guía completa de macOS

Resumen. knowledgeC.db es una base de datos SQLite que escribe el framework CoreDuet de Apple. Registra eventos de «patrón de vida» de macOS como intervalos: una app en uso, la pantalla encendida, el Mac bloqueado o conectado a la corriente, un dominio web visitado. Hay una copia del sistema y una copia por usuario, ambas en modo WAL. Cada fila de la tabla ZOBJECT pertenece a un flujo como /app/usage y lleva horas de inicio y de fin en Mac absolute time. Le dice qué apps se usaron y cuándo; no le dice quién estaba ante el teclado. En las versiones actuales de macOS muchos flujos, incluido el foco de las apps, pasaron a Biome, así que examine ambas fuentes.

Qué es knowledgeC.db

La base de datos knowledgeC es un almacén de Core Data, y por eso sus tablas y columnas llevan el prefijo Z. CoreDuet escribe una fila por evento, agrupada por flujo. A diferencia de las marcas de tiempo del sistema de archivos, que solo indican cuándo cambió un archivo, cada fila tiene un inicio y un fin, así que la base de datos responde a preguntas de duración: cuánto tiempo estuvo Terminal en uso, cuándo se apagó la pantalla, si el Mac estuvo conectado a la corriente durante la noche.

Eso la convierte en una fuente de cronología, no de contenido. Obtiene bundle IDs, URL, dominios y estados de activado/desactivado. No obtiene documentos, pulsaciones de teclas ni comandos.

Dónde se encuentra

Ambas bases de datos funcionan en modo WAL de SQLite. Los archivos complementarios knowledgeC.db-wal y knowledgeC.db-shm deben recolectarse junto con el archivo principal: los eventos más recientes a menudo solo existen en el WAL. Los comandos de recolección, las opciones de UAC y Velociraptor y los compromisos relacionados con SIP se tratan en knowledgeC.db: ubicación y adquisición; qué contiene el WAL y cómo leerlo se explica en recuperar eventos recientes de knowledgeC.db-wal.

La estructura de la base de datos

Tres tablas contienen casi todo lo que necesita un analista.

ZOBJECT: una fila por evento

ZOBJECT es la tabla de eventos.

ZSOURCE: quién produjo el evento

ZSOURCE describe al productor, con columnas como ZBUNDLEID y ZDEVICEID. APOLLO interpreta ZDEVICEID como el identificador del dispositivo de origen, lo que importa porque en la base de datos pueden aparecer filas sincronizadas desde otro dispositivo con la misma Cuenta de Apple. Agrupe por dispositivo antes de atribuir nada al Mac examinado.

ZSTRUCTUREDMETADATA: datos adicionales por flujo

ZSTRUCTUREDMETADATA contiene columnas adicionales por flujo, por ejemplo Z_DKDIGITALHEALTHMETADATAKEY__WEBDOMAIN y Z_DKDIGITALHEALTHMETADATAKEY__WEBPAGEURL para el uso web, Z_DKSAFARIHISTORYMETADATAKEY__TITLE para el historial de Safari o Z_DKNOTIFICATIONUSAGEMETADATAKEY__BUNDLEID para las notificaciones.

Las columnas varían entre versiones de macOS. Lea el esquema de la copia que tiene antes de ejecutar una consulta predefinida.

Flujos que encontrará

Los valores siguientes son los que usan los módulos de APOLLO.

Los módulos de macOS de APOLLO cubren también flujos como /app/activity, /app/intents, /app/mediaUsage y /bluetooth/isConnected. No todos los Mac tienen todos los flujos, así que enumere primero los que realmente existen:

SELECT ZSTREAMNAME, COUNT(*),
       datetime(MIN(ZSTARTDATE)+978307200,'unixepoch') AS first_utc,
       datetime(MAX(ZSTARTDATE)+978307200,'unixepoch') AS last_utc
FROM ZOBJECT GROUP BY ZSTREAMNAME ORDER BY 2 DESC;

Marcas de tiempo y zonas horarias

ZSTARTDATE, ZENDDATE y ZCREATIONDATE están en Mac absolute time: segundos, a menudo fraccionarios, desde el 2001-01-01 00:00:00 UTC. Sume 978307200 para obtener segundos Unix.

Los valores almacenados están en UTC. ZSECONDSFROMGMT registra el desfase que aplicaba el dispositivo en ese momento, de modo que puede mostrar la hora local sin adivinar la zona horaria, y un cambio de ese valor entre eventos es un indicio útil de un viaje o de un cambio de zona horaria.

SELECT datetime(ZSTARTDATE + 978307200, 'unixepoch') AS start_utc,
       datetime(ZSTARTDATE + ZSECONDSFROMGMT + 978307200, 'unixepoch') AS start_local
FROM ZOBJECT LIMIT 5;

Use UTC como referencia en el informe y muestre la hora local a su lado. Mezclar ambas en una misma cronología es la causa más habitual de errores de una o dos horas.

Retención

Sarah Edwards (mac4n6) documentó unas cuatro semanas de eventos en knowledgeC. La depuración se hace por flujo y varía entre versiones, así que no cite en un informe una cifra tomada de la literatura: el ZSTARTDATE más antiguo de cada flujo en la consulta anterior es la ventana de retención efectiva de su evidencia, y debe figurar en sus conclusiones.

knowledgeC y Biome

En las versiones recientes de macOS, Apple ha trasladado muchos flujos a Biome, que los almacena como archivos SEGB de registros protobuf; el foco de las apps, por ejemplo, se espera en App.InFocus y no en /app/inFocus. La correspondencia flujo por flujo y lo que cabe esperar en cada versión están en knowledgeC vs Biome.

Qué demuestra y qué no

knowledgeC respalda afirmaciones como:

• este bundle ID estuvo en uso o en primer plano desde tal hora hasta tal otra;
• la pantalla estaba encendida, el Mac estaba desbloqueado o conectado a la corriente durante este intervalo;
• este dominio o esta URL se visitó en esta app, cuando existen los flujos web.

No demuestra:

• quién estaba ante el teclado. Un Mac desbloqueado con una app en primer plano es compatible con que alguien lo estuviera usando, no con una persona concreta. El método para construir ese argumento, y sus límites, están en quién estaba ante el teclado;
• qué se hizo dentro de una app. No hay nombres de archivo ni líneas de comandos;
• uso activo en todos los casos. Una app «en uso» puede ser una ventana que quedó delante de una pantalla inactiva. Combine los intervalos de apps con /display/isBacklit y /device/isLocked;
• borrado, cuando un flujo está vacío. En un Mac reciente, un /app/inFocus vacío es lo esperado.

Separe también las filas locales de las sincronizadas desde otros dispositivos mediante ZSOURCE.ZDEVICEID.

Opciones de análisis

Use lo que use, trabaje sobre copias. Abrir una base de datos WAL con un cliente SQLite normal puede provocar un checkpoint, que reescribe el archivo principal y puede vaciar el WAL que quería examinar.

Un ejemplo breve (sintético)

La colección de ejemplo incluida con la herramienta es ficticia. En el MacBook FIN-MBP-03, usuario dana.whitlock, la base de datos del sistema muestra un desbloqueo en /device/isLocked a las 10:04:31 UTC del 2026-09-14, con ZSECONDSFROMGMT = 7200, es decir, a las 12:04 hora local, mientras ella estaba comiendo. A continuación, /app/usage muestra Terminal, Ajustes del Sistema y Finder, y la base de datos del usuario muestra /app/webUsage para transfer.example, antes de un bloqueo a las 10:49 UTC. Todas esas filas están en el -wal, no en el archivo principal. Sin el WAL, la ventana del incidente parecería vacía.

Qué establece esto: el Mac estaba desbloqueado y esas apps estaban en uso durante esa ventana. Qué no establece: que lo hiciera Dana, ni ninguna persona concreta. Para cargar el ejemplo y seguir los mismos pasos, consulte analizar knowledgeC y Biome en el navegador.

Preguntas frecuentes

¿Dónde está knowledgeC.db en macOS?

Hay dos copias. La base de datos del sistema es /private/var/db/CoreDuet/Knowledge/knowledgeC.db (propiedad de root y restringida por SIP) y la base de datos del usuario es ~/Library/Application Support/Knowledge/knowledgeC.db (protegida por TCC, así que el proceso de recolección necesita «Acceso total al disco»). Ambas funcionan en modo WAL, así que recolecte knowledgeC.db-wal y knowledgeC.db-shm junto con el archivo principal.

¿Cómo convierto las marcas de tiempo de knowledgeC?

ZSTARTDATE, ZENDDATE y ZCREATIONDATE están en Mac absolute time: segundos desde el 2001-01-01 00:00:00 UTC. Sume 978307200 para obtener tiempo Unix. Los valores almacenados están en UTC; ZSECONDSFROMGMT indica el desfase, en segundos, que usaba el dispositivo en el momento del evento.

¿Por qué /app/inFocus está vacío en un Mac reciente?

En las versiones actuales de macOS, el foco de las apps se espera en el flujo de Biome App.InFocus y no en knowledgeC, así que un /app/inFocus escaso o vacío es normal y no es evidencia de borrado. Compruebe también que se recolectó el archivo -wal, porque las filas más recientes a menudo solo existen allí.

¿Demuestra knowledgeC.db quién usó el Mac?

No. Muestra que una app estaba en uso o en primer plano, que la pantalla estaba encendida o el Mac desbloqueado, en momentos concretos. No identifica a la persona que estaba ante el teclado, ni registra nombres de archivo ni líneas de comandos. La atribución requiere corroboración con otros artefactos.

Artículos relacionados

• knowledgeC vs Biome: dónde guarda macOS el uso de apps
• knowledgeC.db: ubicación y adquisición de flujos Biome
• El formato de archivo SEGB de Biome
• Recuperar eventos recientes de knowledgeC.db-wal
• ¿Quién estaba ante el teclado? Leer con cuidado la actividad de macOS