Analyser knowledgeC.db et Biome dans votre navigateur
Pas à pas : charger knowledgeC.db, son -wal et les flux SEGB de Biome dans un parseur gratuit, filtrer une période, étudier les sessions et exporter.
En bref. Collectez knowledgeC.db avec son -wal et le dossier streams de Biome, déposez-les (ou un ZIP) dans KnowledgeC Parser, vérifiez l'onglet Sources, lisez les Constats, définissez une période, puis parcourez Sessions, Chronologie, Applications, Web et Biome. Exportez en CSV, en CSV Timesketch ou en JSON. L'analyse s'exécute en WebAssembly dans un Web Worker de votre navigateur ; les fichiers ne sont jamais envoyés.
Cet article est le complément pratique du guide d'analyse forensique de knowledgeC.db. Pour le raisonnement derrière l'analyse des sessions, lisez qui utilisait le Mac. Les exemples utilisent l'exemple intégré, qui est synthétique et fictif : il a été généré pour cet outil et ne provient pas d'une affaire réelle. Les libellés de l'interface peuvent légèrement évoluer avec le temps ; les étapes restent les mêmes.
Avant de commencer
| Il vous faut | Pourquoi |
|---|---|
knowledgeC.db + -wal (+ -shm), système et utilisateur | Les événements récents ne se trouvent souvent que dans le WAL |
Le dossier streams de Biome, arborescence intacte | Le nom du flux, local / remote et tombstone viennent du chemin |
La partie Users/<name>/ du chemin | L'outil attribue les fichiers à ce compte |
| Un navigateur de bureau récent | L'analyse s'exécute en WebAssembly dans un Web Worker |
Étape 1 : Collecter les fichiers
La base utilisateur (~/Library/Application Support/Knowledge/knowledgeC.db) et les flux Biome utilisateur sont protégés par TCC : le processus de collecte a besoin de l'Accès complet au disque. La base système (/private/var/db/CoreDuet/Knowledge/knowledgeC.db) est restreinte par SIP ; une image disque est généralement la voie la plus propre. Copiez les fichiers -wal et -shm avec chaque base, et calculez l'empreinte de chaque fichier.
Les commandes, les options UAC et Velociraptor ainsi que leurs lacunes sont décrites dans knowledgeC.db et Biome : emplacements et acquisition et dans le guide de collecte de la page d'accueil.
Étape 2 : Charger les fichiers
Ouvrez la page d'accueil de l'outil et déposez :
- des fichiers isolés (
knowledgeC.db,knowledgeC.db-wal, fichiers SEGB) ; - un dossier, par exemple une copie de
Library; - un ZIP d'une collecte.
Pour prendre d'abord en main l'interface, cliquez sur Essayer un exemple. L'espace de travail passe en plein écran ; appuyez sur Échap pour le quitter.
L'exemple est un MacBook fictif, FIN-MBP-03, utilisatrice dana.whitlock : un knowledgeC.db système et un utilisateur, chacun avec un -wal, et des fichiers Biome pour App.InFocus (dont un ancien fichier tombstone et un flux synchronisé depuis un iPhone), App.WebUsage, Notification.Usage, Device.Metadata et App.MenuItem, en SEGB v1 comme en v2.
Étape 3 : Vérifier l'onglet Sources
Avant de lire le moindre événement, vérifiez ce qui a été analysé :
- Chaque knowledgeC.db associé à son
-wal. L'outil lit la base comme le ferait SQLite après application du WAL, et la compare au fichier principal seul. Les lignes présentes uniquement dans le WAL, et celles que le WAL a supprimées, sont signalées. Dans l'exemple, toutes les lignes système postérieures à 10:00 UTC le 2026-09-14 n'existent que dans le WAL, et une ancienne ligne est supprimée par le WAL. Voir récupération du WAL de knowledgeC. - Portée : base système ou utilisateur, d'après le chemin.
- Fichiers Biome : nom du flux, version SEGB,
local,remote/<device UUID>outombstone, nombre d'enregistrements par état et échecs CRC. - Problèmes : un fichier qui commence par des zéros (probablement copié alors qu'il était verrouillé), un fichier SEGB tronqué, ou un fichier SEGB dont le nom de flux est inconnu parce que l'arborescence a été perdue. Le fichier
-shmest listé mais n'est pas nécessaire.
Étape 4 : Lire les Constats
L'onglet Constats résume ce qui ressort. Traitez chaque élément comme une piste : ouvrez-le, vérifiez les enregistrements sous-jacents et décidez s'il a sa place dans le rapport. L'exemple a été conçu pour que les pistes à suivre soient une session déverrouillée pendant la pause déjeuner, une première apparition de Terminal, des enregistrements web Biome supprimés et un bref déverrouillage au milieu de la nuit.
Étape 5 : Définir la période
Une période personnalisée maintient tous les onglets sur la même fenêtre :
| Contrôle | Usage |
|---|---|
| Du / Au | Réglage à la seconde, par exemple du 2026-09-14 10:00:00 au 10:55:00 UTC |
| Préréglages | Périodes rapides |
| Autour de cet événement | Centre la période sur un événement sélectionné |
| Bande de densité | Montre où les événements se concentrent, pour repérer les pics et les creux |
La période est stockée dans le hash de l'URL : un collègue qui ouvre le même lien avec les mêmes fichiers voit la même fenêtre. Elle est aussi inscrite dans le nom des fichiers exportés.
Étape 6 : Étudier les sessions et la chronologie
L'onglet Sessions répond à la question « qui était au clavier » dans la mesure où les données le permettent : des intervalles déverrouillés construits à partir de /device/isLocked, à lire en regard de l'éclairage de l'écran, de l'alimentation et des applications au premier plan. Dans l'exemple, la session de 10:04:31 à 10:49:38 UTC (12:04 à 12:49 heure locale) tombe pendant la pause déjeuner de Dana. La session montre une activité sous son compte, pas qui tapait au clavier ; l'article de méthode en explique les limites.
L'onglet Chronologie fusionne les événements knowledgeC et Biome. Les dates sont stockées en UTC ; pour les lignes knowledgeC, ZSECONDSFROMGMT donne le décalage local (+02:00 dans l'exemple). Les enregistrements Biome App.InFocus « au premier plan » et « plus au premier plan » sont appariés en intervalles par application.
Étape 7 : Examiner les applications, le web et les détails Biome
- Applications : focus et utilisation par bundle ID. Dans l'exemple,
com.apple.Terminaln'apparaît qu'à l'intérieur de la session de l'incident. - Web : URL et domaines issus de
/app/webUsage,/safari/historyetApp.WebUsage, dontfiles.exampleettransfer.example. - Biome : une ligne par flux, magasin et origine (
local,remoteavec l'UUID de l'appareil,tombstone), avec la version SEGB, le nombre d'enregistrements, les enregistrements supprimés et les échecs CRC. Cliquez sur un flux pour lister ses enregistrements ; le détail de chacun affiche son état, le résultat du CRC et les champs protobuf décodés. Les flux sans correspondance de champs publique, commeApp.MenuItem, sont décodés sans schéma et conservent les numéros de champ bruts (format SEGB).
Les enregistrements synchronisés depuis l'iPhone (remote/<UUID> dans Biome, un autre ZDEVICEID dans knowledgeC) sont signalés comme tels. Tenez-les à l'écart de l'activité du Mac.
Étape 8 : Exporter les résultats
| Export | Contenu |
|---|---|
| CSV : chronologie | Événements de la période en cours |
| CSV : applications | Totaux par application |
| CSV : sessions | Sessions déverrouillées |
| CSV Timesketch | Événements dans un format que Timesketch peut importer |
| JSON | Les événements analysés, pour les scripts et d'autres outils |
Conservez les exports avec les empreintes des fichiers sources. La période indiquée dans le nom de chaque fichier précise la fenêtre couverte par l'export.
Limites à garder en tête
- La signification des champs des payloads Biome vient de mac_apt et d'iLEAPP, pas d'Apple. Les champs non décodés restent bruts.
- Les enregistrements montrent une activité sous un compte sur un appareil, pas une identité.
- La rétention est limitée (environ quatre semaines dans knowledgeC, autour de 28 jours pour la plupart des flux Biome selon les travaux sur iOS) ; mesurez-la flux par flux.
- Pour les enregistrements importants, recoupez avec APOLLO, mac_apt ou ccl-segb.
KnowledgeC Parser est un projet indépendant, ni affilié à Apple ni approuvé par Apple.