Qui utilisait le Mac ? Méthode knowledgeC et Biome

En bref. Pour répondre à la question « quelqu'un utilisait-il ce Mac, et quand ? », construisez des sessions déverrouillées à partir de /device/isLocked (0 = déverrouillé), confrontez-les à /display/isBacklit et /device/isPluggedIn, puis remplissez chaque session avec les applications au premier plan (Biome App.InFocus, knowledgeC /app/usage et /app/inFocus) et l'activité web. Isolez les enregistrements synchronisés depuis d'autres appareils, convertissez en heure locale avec ZSECONDSFROMGMT, et indiquez clairement ce que les données ne prouvent pas : elles montrent une activité sous un compte, pas l'identité de la personne au clavier.

Cet article constitue l'étape d'interprétation de la série. Pour le parcours dans l'outil, voir comment analyser knowledgeC.db et Biome dans votre navigateur ; pour les fichiers eux-mêmes, le guide d'analyse forensique de knowledgeC.db.

La question à laquelle on peut répondre

knowledgeC.db et Biome enregistrent des événements de « pattern of life » : des états dans le temps (verrouillé, écran allumé, sur secteur) et l'activité des applications. Ensemble, ils répondent à une question plus étroite que « qui » :

Pendant quels intervalles ce Mac était-il déverrouillé avec l'écran allumé, et qu'y avait-il au premier plan sous ce compte ?

C'est souvent suffisant pour confirmer ou écarter une chronologie, et cela indique où chercher dans d'autres artefacts.

Les flux

La signification des valeurs suit APOLLO et les travaux publiés ; les numéros de champ Biome viennent de mac_apt et d'iLEAPP (voir la référence du format SEGB). Sur les versions récentes de macOS, le suivi des applications au premier plan passe dans Biome et /app/inFocus peut être clairsemé, voire vide : c'est attendu, et ce n'est pas un signe d'effacement (knowledgeC ou Biome). Tous les Mac n'ont pas tous les flux : listez ceux présents sur vos éléments de preuve avant de planifier l'analyse.

Collectez knowledgeC.db-wal avec la base. Les événements les plus récents, souvent ceux qui comptent, peuvent n'exister que dans le WAL (récupération du WAL de knowledgeC).

Étape 1 : Construire les sessions déverrouillées

Les événements knowledgeC sont des intervalles, avec ZSTARTDATE et ZENDDATE en Mac absolute time. Une session déverrouillée est un intervalle /device/isLocked de valeur 0 :

SELECT datetime(o.ZSTARTDATE + 978307200, 'unixepoch') AS start_utc,
       datetime(o.ZENDDATE + 978307200, 'unixepoch') AS end_utc,
       datetime(o.ZSTARTDATE + o.ZSECONDSFROMGMT + 978307200, 'unixepoch') AS start_local,
       round(o.ZENDDATE - o.ZSTARTDATE) AS seconds,
       s.ZDEVICEID AS device_id
FROM ZOBJECT o LEFT JOIN ZSOURCE s ON o.ZSOURCE = s.Z_PK
WHERE o.ZSTREAMNAME = '/device/isLocked' AND o.ZVALUEINTEGER = 0
ORDER BY o.ZSTARTDATE;

Confrontez ensuite chaque session à /display/isBacklit. Un intervalle déverrouillé avec l'écran allumé constitue le cœur d'une session. Un écran allumé alors que le Mac est verrouillé correspond à quelqu'un (ou quelque chose) qui réveille l'écran sans déverrouiller. /device/isPluggedIn apporte du contexte : un portable resté sur secteur toute la journée est très probablement resté à son bureau, sans que cela le prouve.

Si /device/isLocked est absent, les intervalles de rétroéclairage combinés aux applications au premier plan donnent une approximation plus faible. Précisez-le dans le rapport.

Étape 2 : Placer les applications au premier plan dans chaque session

Biome App.InFocus stocke séparément des enregistrements « au premier plan » et « plus au premier plan ». Appariez-les par application pour obtenir des intervalles : un enregistrement « au premier plan » se termine au prochain enregistrement « plus au premier plan » pour le même bundle ID. Les lignes knowledgeC /app/usage et /app/inFocus sont déjà des intervalles.

Lisez le focus à l'intérieur des sessions déverrouillées, jamais isolément :

• un focus pendant une session déverrouillée avec l'écran allumé est le signal d'utilisation le plus fort que ces sources puissent donner ;
• un focus qui se prolonge après l'heure de verrouillage correspond à une application laissée au premier plan, pas à une activité ;
• un long intervalle de focus unique, sans aucun autre changement, peut correspondre à un écran inactif avec une seule fenêtre ouverte.

Étape 3 : Ajouter l'activité web

/app/webUsage contient le bundle ID, avec le domaine et l'URL dans ZSTRUCTUREDMETADATA ; /safari/history contient l'URL, avec le titre dans les métadonnées. Dans Biome, App.WebUsage contient l'URL, le domaine et le bundle ID. Examinez les enregistrements supprimés (état 3) et les fichiers de tombstone/ : un historique effacé peut laisser des enregistrements Biome marqués comme supprimés, dont le payload reste lisible.

Étape 4 : Isoler les appareils synchronisés

Les appareils associés au même compte Apple synchronisent certains enregistrements. Ceux-ci ne doivent pas être attribués au Mac :

• dans knowledgeC.db, regroupez les lignes par ZSOURCE.ZDEVICEID (APOLLO l'interprète comme l'UUID matériel de l'appareil d'origine) ;
• dans Biome, les fichiers situés sous .../<Stream>/remote/<device UUID>/ proviennent d'un autre appareil ; local/ correspond au Mac lui-même.

Les enregistrements synchronisés restent utiles : ils montrent ce que faisait l'autre appareil au même moment.

Étape 5 : Convertir soigneusement en heure locale

Les dates stockées sont en UTC. ZSECONDSFROMGMT est le décalage utilisé par l'appareil au moment de chaque événement : start + ZSECONDSFROMGMT donne donc l'heure locale de cette ligne. Les enregistrements Biome n'ont pas de colonne équivalente : appliquez le décalage établi à partir de knowledgeC ou des réglages système, et notez lequel vous avez utilisé. Un changement de ZSECONDSFROMGMT entre deux événements signale un changement de fuseau horaire.

Exemple commenté : FIN-MBP-03 (synthétique)

L'exemple intégré est synthétique et fictif, généré pour cet outil. MacBook FIN-MBP-03, utilisatrice dana.whitlock, lundi 2026-09-14. Le décalage du Mac est de +02:00 (ZSECONDSFROMGMT = 7200). Dans le scénario, Dana verrouille le Mac et part déjeuner à 11:58 heure locale ; la session habituelle suivante commence à 14:58 heure locale.

Deux autres observations changent la lecture :

• Enregistrements synchronisés depuis l'iPhone. Les enregistrements App.InFocus sous remote/<iPhone UUID>/ et les lignes knowledgeC avec un autre ZDEVICEID montrent Plans de 10:12 à 10:19 UTC et Messages de 10:27 à 10:29 UTC. Il ne s'agit pas d'activité sur le Mac. Ils sont cohérents avec une Dana utilisant son téléphone ailleurs, ce qui correspond au scénario, mais ils ne prouvent pas où elle se trouvait : quelqu'un d'autre pouvait avoir son téléphone, ou elle pouvait utiliser les deux appareils.
• Une session nocturne. Un déverrouillage de trois minutes à 01:12 UTC, soit 03:12 heure locale, avec Safari sur files.example. C'est la conversion en heure locale qui fait ressortir cet événement.

Les valeurs App.MenuItem proviennent d'un décodage sans schéma : ce flux n'a pas de correspondance de champs publique, le tableau cite donc les chaînes visibles sans attribuer de signification aux numéros de champ. Dans l'exemple, toutes les lignes postérieures à 10:00 UTC du knowledgeC.db système n'existent que dans le -wal : sans lui, la fenêtre de l'incident est vide.

Ce que cela étaye : le Mac était déverrouillé sous dana.whitlock de 10:04:31 à 10:49:38 UTC avec l'écran allumé, et la séquence d'applications et de sites ci-dessus était au premier plan. Ce que cela n'étaye pas à lui seul : que Dana, ou une personne en particulier, se trouvait au clavier.

Ce que les données ne prouvent pas

• L'identité. Les enregistrements appartiennent à un compte et à un appareil. Un mot de passe partagé, un Mac déverrouillé laissé sans surveillance ou une prise de contrôle à distance produisent tous les mêmes enregistrements.
• L'attention. Une application au premier plan devant un écran inactif ressemble à une utilisation.
• L'exhaustivité. La rétention est d'environ quatre semaines dans knowledgeC (Sarah Edwards) et d'environ 28 jours pour la plupart des flux Biome (travaux sur iOS) ; mesurez l'enregistrement le plus ancien de chaque flux sur vos éléments de preuve. « Première utilisation » signifie « première utilisation dans les données conservées ».
• L'intention. Une visite web ou un élément de menu indique ce qui était à l'écran, pas pourquoi.

Corroborer avec d'autres artefacts

Servez-vous de ces sessions comme d'une ossature et cherchez des éléments indépendants dans les mêmes fenêtres :

• Unified logs : entrées liées à la connexion et au verrouillage de l'écran autour des bornes de la session, dans la limite de la rétention des journaux.
• TCC.db : enregistrements d'autorisations, par exemple une modification de l'« Accès complet au disque » proche de l'intervalle Réglages Système.
• Événements de quarantaine : téléchargements et leur origine, par exemple l'archive récupérée dans Safari.
• FSEvents : modifications du système de fichiers, par exemple sur un volume externe pendant l'intervalle Finder.

Chacun a ses propres limites ; traitez-les comme des éléments de corroboration, et laissez les preuves du monde physique (badges, caméras, témoins) trancher la question de l'identité.

Liste de contrôle pour le rapport

• Flux présents, enregistrements le plus ancien et le plus récent par flux, et collecte ou non des fichiers -wal.
• Sessions déverrouillées avec heures UTC et locales, et décalage utilisé.
• Activité au premier plan et web par session, avec les enregistrements d'appareils synchronisés isolés.
• Enregistrements Biome supprimés, tombstone et en échec CRC listés comme tels.
• Une phrase indiquant que les données montrent une activité de compte, pas une identité.

Questions fréquentes

knowledgeC.db peut-il prouver qui utilisait un Mac ?

Non. Il montre que le Mac était déverrouillé, que l'écran était allumé et quelles applications étaient au premier plan, sous un compte utilisateur donné. Il n'identifie pas la personne au clavier. L'attribution exige d'autres éléments, comme les relevés de badge, la vidéosurveillance, des témoignages ou des journaux d'authentification.

Quels flux knowledgeC indiquent quand un Mac était déverrouillé ?

/device/isLocked, où ZVALUEINTEGER 0 marque un intervalle déverrouillé et 1 un intervalle verrouillé, associé à /display/isBacklit (1 = allumé). Tous les Mac n'ont pas tous les flux : vérifiez d'abord lesquels existent sur vos éléments de preuve.

Pourquoi vois-je des applications d'iPhone dans le knowledgeC.db ou le dossier Biome d'un Mac ?

Les appareils associés au même compte Apple peuvent synchroniser des enregistrements. Dans knowledgeC.db, ils portent un ZSOURCE.ZDEVICEID différent ; dans Biome, ils se trouvent sous remote/<device UUID>. Ils décrivent l'autre appareil, pas le Mac examiné.

Une application au premier plan prouve-t-elle que quelqu'un l'utilisait ?

Non. Une application reste au premier plan devant un écran inactif jusqu'à ce qu'une autre prenne le focus ou que l'écran se verrouille. Confrontez les intervalles de focus aux intervalles de verrouillage et d'éclairage de l'écran, ainsi qu'à l'activité dans l'application.

Articles liés

• Analyser knowledgeC.db et Biome dans votre navigateur
• Récupérer les événements récents de knowledgeC.db-wal
• knowledgeC ou Biome sur macOS
• Format de fichier SEGB de Biome