Skip to content

TCC.dbTCC.db-wal

TCC Parser

Qui avait le droit de lire le disque, de regarder l'écran ou de piloter le Mac ?

Décodez les bases TCC de macOS (système et par utilisateur, avec leurs journaux WAL) en autorisations, apps, chronologie et historique récupéré, avec des signalements pour les autorisations à risque. Analyse dans votre navigateur avec WebAssembly : rien n'est envoyé.

Déposez des fichiers TCC.db, un dossier ou une archive de collecte

TCC.db système et par utilisateur avec leurs -wal et -shm, MDMOverrides.plist, ou une collecte UAC, Velociraptor ou Aftermath complète (.zip, .tar.gz). Tout est décodé sur votre appareil.

Pas de données sous la main ? Essayez un exemple : le Mac synthétique FIN-MBP-03 issu d'une intrusion fictive (TCC.db + WAL pour le système et un utilisateur, plus MDMOverrides.plist).

100 % dans votre navigateur — Rust + WebAssembly, rien n'est envoyé

Comment récupérer vos données

Guide d'acquisition complet

Chaque Mac possède un TCC.db système et un par utilisateur, chacun avec un TCC.db-wal pouvant contenir les derniers changements et des versions antérieures de lignes. Copiez les dossiers com.apple.TCC entiers, pas seulement TCC.db, et conservez leurs chemins pour que l'outil sache à qui appartient chaque base.

  1. Copier les dossiers com.apple.TCC (Accès complet au disque requis)
  2. Déposer le dossier ou l'archive ici
  3. Analyse locale — rien ne quitte le navigateur

Sur le Mac en fonctionnement, accordez l'Accès complet au disque au Terminal (Réglages Système › Confidentialité et sécurité › Accès complet au disque), rouvrez-le et collez ce bloc depuis un compte administrateur. ditto copie chaque dossier com.apple.TCC tel quel, avec TCC.db-wal, TCC.db-shm et MDMOverrides.plist, et conserve l'arborescence Library/… et Users/<name>/….

Terminal · zsh / bash · admin
C=~/Desktop/tcc_case; mkdir -p "$C"
sudo ditto "/Library/Application Support/com.apple.TCC" "$C/Library/Application Support/com.apple.TCC"
for u in /Users/*; do
  d="$u/Library/Application Support/com.apple.TCC"
  [ -d "$d" ] && sudo ditto "$d" "$C/Users/$(basename "$u")/Library/Application Support/com.apple.TCC"
done
R="/private/var/root/Library/Application Support/com.apple.TCC"
sudo test -d "$R" && sudo ditto "$R" "$C$R"
sudo ditto -c -k --keepParent "$C" ~/Desktop/tcc_case.zip

Vous obtenez ~/Desktop/tcc_case et tcc_case.zip. Déposez l'un ou l'autre sur la page.

Accorder l'Accès complet au disque au Terminal écrit lui-même une ligne dans le TCC.db système : notez l'heure à laquelle vous l'avez fait pour que votre propre autorisation ne soit pas confondue avec celle de l'intrus.

Pièges

  • Sans Accès complet au disque pour le processus qui effectue la copie (Terminal, l'agent, le collecteur), la copie échoue avec « Operation not permitted » ou revient vide.
  • Prenez TCC.db-wal avec TCC.db. Les outils qui ne copient que TCC.db (tcc.yaml d'UAC, Aftermath) manquent les changements encore dans le WAL et l'historique qu'il contient.
  • Chaque compte a son propre TCC.db, y compris root sous /private/var/root.
  • N'ouvrez jamais les preuves avec sqlite3 en lecture-écriture : à la fermeture, il intègre le WAL dans TCC.db par un checkpoint et supprime le fichier -wal, effaçant l'historique que cet outil récupère. Travaillez sur des copies et calculez-en d'abord les hashes.
  • Une copie faite pendant que tccd écrit peut être incohérente ; l'outil ne rejoue que les trames WAL aux sommes de contrôle valides et liste le reste dans l'Historique.

Qu'est-ce que TCC.db ?

Transparency, Consent and Control (TCC) est le framework macOS qui décide si un programme peut utiliser la caméra, le micro, l'écran, les événements clavier, les API d'accessibilité, les dossiers protégés, l'Accès complet au disque ou l'automatisation par Apple Events. Le démon tccd enregistre chaque décision en vigueur dans des bases SQLite nommées TCC.db : une pour le système et une par utilisateur.

Chaque ligne est une décision pour un programme (bundle ID ou chemin) et un service, avec la décision (autorisé, refusé, limité), son motif, l'exigence de code du programme et la date du dernier changement de la décision. C'est un registre d'autorisations, pas un journal d'utilisation.

Où elle est stockée

  • /Library/Application Support/com.apple.TCC/TCC.db : base système (protégée par SIP et TCC), généralement Accès complet au disque, Accessibilité, Enregistrement de l'écran, Surveillance de l'entrée.
  • ~/Library/Application Support/com.apple.TCC/TCC.db pour chaque utilisateur : caméra, micro, dossiers, volumes amovibles, Automatisation et plus.
  • TCC.db-wal à côté de chaque base : le journal WAL (write-ahead log) avec les changements récents et d'anciennes copies de pages.
  • /Library/Application Support/com.apple.TCC/MDMOverrides.plist : autorisations poussées par des profils de configuration MDM (PPPC).

Pourquoi c'est important en investigation

  • Montre quels programmes pouvaient tout lire (Accès complet au disque), regarder l'écran, enregistrer les frappes ou contrôler l'interface, y compris un terminal ou un hôte de scripts par lequel tout le reste passe.
  • Date le dernier changement de chaque décision (secondes Unix, UTC) : une rafale d'autorisations pendant la fenêtre d'une intrusion est un indice fort.
  • Des clients par chemin dans des dossiers temporaires, partagés ou masqués et des exigences de code signées ad hoc signalent des outils déposés.
  • Le WAL et les pages libres peuvent conserver des autorisations supprimées ensuite avec tccutil reset.

Limites

  • Une ligne montre une décision, pas son utilisation : TCC.db ne journalise pas chaque activation de la caméra ni chaque lecture de fichier. Les traces requête par requête se trouvent dans le journal unifié (sous-système com.apple.TCC).
  • last_modified ne donne que le dernier changement ; la date de la première autorisation est perdue quand une ligne est mise à jour.
  • Les lignes supprimées ne subsistent que jusqu'à ce que SQLite réutilise l'espace ; une ligne absente ne prouve pas qu'une autorisation n'a jamais été accordée.
  • Les valeurs d'auth_reason et certaines colonnes (flags, pid, boot_uuid) ne sont pas documentées par Apple ; l'outil affiche les valeurs brutes à côté des interprétations de la communauté.

Comment obtenir les fichiers

  • Copiez le dossier /Library/Application Support/com.apple.TCC entier et le dossier ~/Library/Application Support/com.apple.TCC de chaque utilisateur, en conservant les chemins, depuis un terminal disposant de l'Accès complet au disque (voir « Comment récupérer vos données »).
  • Collectez TCC.db-wal avec chaque TCC.db ; le tcc.yaml d'UAC et Aftermath ne copient que TCC.db.
  • Depuis une image, montez le volume Data en lecture seule et archivez les mêmes dossiers.

FAQ

Mes bases TCC sont-elles envoyées quelque part ?

Non. Le parseur est écrit en Rust, compilé en WebAssembly, et s'exécute dans un Web Worker de votre navigateur. Il n'y a aucun point d'envoi ; les tables, constats et exports sont produits localement.

Quelles versions de macOS sont prises en charge ?

Toutes les structures de la table access : Mojave et Catalina (allowed, prompt_count), Big Sur à Ventura (auth_value, auth_reason, auth_version) et Sonoma et ultérieur (pid, pid_version, boot_uuid, last_reminded). Les noms de colonnes sont lus depuis le schéma propre à chaque base, et les colonnes inconnues sont affichées telles quelles.

Ai-je besoin des fichiers -wal et -shm ?

Apportez le -wal : il peut contenir les décisions les plus récentes et des versions antérieures de lignes, et l'outil le rejoue comme le fait SQLite. Le fichier -shm n'est qu'un index du WAL et n'est pas nécessaire.

Que signifie auth_value 2 ?

Autorisé. 0 signifie refusé, 1 inconnu et 3 limité. Sous Mojave et Catalina, la table avait à la place une colonne allowed (1 = autorisé), que l'outil fait correspondre aux mêmes décisions.

Qu'est-ce que la colonne csreq ?

Une exigence de signature de code compilée qui identifie le programme auquel s'applique la décision. L'outil la décode en texte, par exemple identifier "com.apple.Terminal" and anchor apple, et affiche le team ID ou le cdhash du code signé ad hoc.

Peut-il récupérer des autorisations supprimées ?

Souvent, pour les changements récents : des lignes supprimées avec tccutil reset ou via les Réglages Système peuvent subsister dans les trames WAL, dans les versions de pages remplacées par le WAL et dans les pages libres. Elles apparaissent dans l'onglet Historique jusqu'à ce que SQLite réutilise l'espace.

À propos du parseur

TCC Parser est une implémentation indépendante en Rust compilée en WebAssembly. Il lit lui-même les fichiers SQLite, d'après les spécifications publiques du format de fichier et du WAL (sqlite.org) : il peut donc rejouer le fichier -wal, lister ce que le WAL a remplacé et extraire des lignes des pages libres, ce qu'une requête SQLite classique ne montre pas. Les colonnes sont lues depuis le schéma propre à chaque base, si bien que les structures de l'ère Mojave, de l'ère Big Sur et de Sonoma et versions ultérieures sont toutes décodées. Les exigences de code (csreq) sont décodées dans le langage d'exigences documenté par Apple. Les significations d'auth_reason sont documentées par la communauté, pas publiées par Apple : vérifiez les conclusions importantes sur un Mac de test de même version et dans les journaux unifiés.

Pas à pas : charger les TCC.db de macOS et leur WAL dans un parseur gratuit, lire constats, autorisations et historique, filtrer une période, exporter.
L'évolution de la table access de TCC.db de Mojave à Big Sur et Sonoma : allowed, auth_value, auth_reason, pid, last_reminded et les autres tables.
Lire les blobs csreq et indirect_object_code_identity de TCC.db : exigences compilées, clauses anchor et identifier, clients ad hoc réduits à un cdhash.