Ajouter un pivot e-mail forensique avec OCR, métadonnées et normalisation des données #107

New issue

Closed

opened 2026-07-23 17:14:41 +02:00 by fy59 · 1 comment

fy59 commented 2026-07-23 17:14:41 +02:00

Owner

Copy link

Ajouter un pivot e-mail forensique avec OCR, métadonnées et normalisation des données

Contexte

Labfy Investigation permet déjà d’importer des preuves, de conserver leurs empreintes, d’analyser certains fichiers EML, d’exécuter un OCR sur des RIB et d’extraire des métadonnées avec ExifTool.

Ces fonctionnalités doivent maintenant être réunies dans un flux cohérent permettant d’exploiter une preuve .eml et ses pièces jointes comme point de départ d’un pivot d’enquête.

Un e-mail frauduleux peut contenir ou transporter :

• des adresses e-mail ;
• des noms de domaine ;
• des adresses IP et relais SMTP ;
• un identifiant Message-ID ;
• des images ;
• un RIB ;
• un IBAN ;
• un BIC ;
• un nom de titulaire ;
• un nom de banque ;
• des documents PDF ;
• des métadonnées techniques ;
• des liens avec d’autres preuves, entités ou relations.

Ces informations ne doivent pas être intégrées automatiquement comme des faits établis. Elles doivent être extraites, normalisées, présentées à l’utilisateur, corrigées si nécessaire, puis confirmées explicitement.

Problème

Les analyses existantes sont encore trop séparées :

• l’analyse EML produit des informations techniques ;
• l’OCR bancaire analyse un fichier isolé ;
• ExifTool produit des métadonnées ;
• les extractions ne sont pas toujours présentées dans un parcours unique ;
• certaines valeurs peuvent encore être enregistrées sous des formulations incohérentes ;
• la différence entre valeur brute, valeur normalisée, valeur dérivée et valeur confirmée n’est pas toujours clairement représentée ;
• les pièces jointes ne sont pas encore exploitées automatiquement comme fichiers dérivés de l’e-mail source.

Le projet doit éviter deux erreurs opposées :

1. enregistrer automatiquement des résultats OCR potentiellement faux ;
2. transformer toutes les valeurs en listes fermées alors que des éléments comme un IBAN, un BIC, un nom ou une adresse sont naturellement uniques.

Objectif

Créer une action complète de pivot e-mail permettant de :

1. analyser les en-têtes et la structure MIME d’un fichier .eml ;
2. extraire ses pièces jointes sans modifier la preuve originale ;
3. calculer les empreintes et métadonnées des fichiers extraits ;
4. exécuter l’OCR sur les images et PDF compatibles ;
5. détecter les données bancaires et autres identifiants utiles ;
6. normaliser les valeurs sans masquer leur forme originale ;
7. présenter toutes les propositions dans une interface de révision ;
8. intégrer uniquement les éléments confirmés ;
9. créer ou réutiliser les entités et relations correspondantes ;
10. conserver la provenance complète de chaque donnée.

Principes de données

Chaque donnée extraite doit pouvoir distinguer :

• la valeur brute observée ;
• la valeur normalisée ;
• la valeur dérivée localement ;
• la correction apportée par l’utilisateur ;
• le statut de vérification ;
• la confiance ;
• la preuve source ;
• l’extraction source ;
• la date d’extraction ;
• l’outil et sa version.

Une valeur brute ne doit jamais être modifiée.

Une correction utilisateur doit être conservée séparément de la valeur brute.

Un résultat OCR ne doit jamais être automatiquement considéré comme confirmé.

Analyse du message EML

L’analyse doit extraire et présenter au minimum :

• From ;
• Sender ;
• Reply-To ;
• Return-Path ;
• To ;
• Cc ;
• Bcc lorsqu’il est présent ;
• Subject ;
• Date ;
• Message-ID ;
• In-Reply-To ;
• References ;
• MIME-Version ;
• Content-Type ;
• Authentication-Results ;
• SPF ;
• DKIM ;
• DMARC ;
• l’ensemble des en-têtes Received, dans leur ordre réel.

Les dates doivent être conservées sous leur forme brute et normalisées en UTC lorsque leur analyse est possible.

Les adresses IP ou noms d’hôtes présents dans la chaîne SMTP doivent recevoir un rôle proposé parmi un vocabulaire contrôlé :

• source déclarée ;
• relais SMTP ;
• serveur destinataire ;
• infrastructure privée ;
• rôle indéterminé.

Une adresse IP observée dans un en-tête Received ne doit jamais être automatiquement présentée comme l’adresse IP personnelle du suspect.

Extraction des pièces jointes

Chaque pièce jointe doit devenir un fichier dérivé de la preuve EML.

L’extraction doit :

• préserver la preuve originale ;
• assainir les noms de fichiers ;
• neutraliser les chemins absolus et les traversées ../ ;
• gérer les collisions sans écrasement ;
• calculer le SHA-256 ;
• enregistrer la taille ;
• détecter le type MIME réel ;
• conserver le type MIME déclaré ;
• conserver le chemin MIME de la partie ;
• conserver Content-ID ;
• conserver Content-Disposition ;
• conserver Content-Transfer-Encoding ;
• distinguer les contenus inline des véritables pièces jointes ;
• relier le fichier dérivé à l’EML source.

Aucune pièce jointe ne doit être exécutée ou ouverte automatiquement.

Aucune ressource distante contenue dans un e-mail HTML ne doit être chargée automatiquement.

Des limites doivent protéger l’application contre :

• un nombre excessif de parties MIME ;
• une profondeur MIME anormale ;
• une taille décodée excessive ;
• un encodage Base64 invalide ;
• un nom de fichier malveillant ;
• une expansion excessive ;
• un contenu tronqué.

Métadonnées techniques

Les fichiers compatibles doivent être analysés avec l’intégration ExifTool existante.

Deux niveaux doivent être conservés :

Sortie brute

• JSON complet produit par ExifTool ;
• version de l’outil ;
• arguments utilisés ;
• date UTC ;
• empreinte de la sortie ;
• fichier analysé.

Métadonnées normalisées

Les métadonnées utiles doivent être représentées avec des codes métier stables, par exemple :

• file.mime_type
• file.size_bytes
• file.detected_extension
• image.width
• image.height
• image.orientation
• image.software
• image.make
• image.model
• image.datetime_original
• image.gps_latitude
• image.gps_longitude
• document.author
• document.creator
• document.producer
• document.creation_time
• document.modification_time

Les noms originaux produits par ExifTool doivent rester accessibles.

Les coordonnées GPS doivent nécessiter une confirmation explicite avant intégration.

OCR des images et PDF

L’OCR doit réutiliser l’infrastructure existante.

Il doit :

• fonctionner en tâche de fond ;
• être annulable ;
• conserver la sortie texte brute ;
• conserver l’outil, sa version, la langue et les paramètres ;
• permettre au minimum le français et l’anglais ;
• rattacher le résultat au fichier exact ;
• conserver le numéro de page pour les PDF ;
• ne jamais écraser une extraction précédente.

Pour les PDF :

• utiliser d’abord le texte natif lorsqu’il existe ;
• utiliser un rendu image et l’OCR seulement lorsque nécessaire ;
• signaler les documents chiffrés ou non lisibles ;
• ne pas lancer automatiquement de récupération de mot de passe.

L’absence de Tesseract ne doit pas empêcher l’analyse EML et l’extraction des métadonnées.

Extraction des données bancaires

L’analyse doit détecter au minimum :

• IBAN ;
• BIC/SWIFT ;
• titulaire du compte ;
• nom de la banque ;
• adresse de la banque ;
• code pays ;
• code banque ;
• code guichet ;
• numéro de compte ;
• clé RIB.

IBAN

L’IBAN doit être :

• conservé sous sa graphie OCR brute ;
• normalisé sans espaces et en majuscules ;
• contrôlé selon sa longueur nationale ;
• validé par MOD-97 ;
• marqué invalide lorsqu’il échoue ;
• accompagné de toute correction OCR proposée.

Les corrections telles que O vers 0 ou I vers 1 ne doivent jamais être appliquées silencieusement.

Pour un IBAN français valide, les composants RIB peuvent être dérivés, mais ils doivent être marqués comme :

Dérivés localement depuis l’IBAN

et non comme observés dans le document.

BIC

Le BIC doit être :

• conservé sous sa forme brute ;
• normalisé en majuscules ;
• validé sur 8 ou 11 caractères ;
• marqué invalide lorsqu’il ne respecte pas le format.

Le BIC ne doit jamais être inventé depuis le nom supposé de la banque.

Titulaire et banque

Le titulaire et la banque restent des propositions textuelles.

Le système doit :

• conserver le texte OCR brut ;
• conserver l’extrait ayant permis la détection ;
• réduire les espaces superflus ;
• préserver les accents ;
• permettre une correction humaine ;
• éviter toute transformation destructive.

Un nom indiqué comme titulaire sur un RIB ne prouve pas que cette personne est l’auteur de l’escroquerie.

Valeurs libres et vocabulaires contrôlés

Les valeurs suivantes restent des champs textuels spécialisés :

• IBAN ;
• BIC ;
• nom de titulaire ;
• nom de banque ;
• adresse ;
• adresse e-mail ;
• domaine ;
• Message-ID ;
• URI.

En revanche, les champs fermés doivent utiliser un référentiel et une liste déroulante.

Statut de vérification

• proposed — Proposé
• confirmed — Confirmé
• rejected — Rejeté
• conflicted — Contradictoire
• invalid — Invalide

Provenance

• observed — Observé directement
• ocr — Extrait par OCR
• header — Extrait d’un en-tête
• metadata — Extrait des métadonnées
• derived — Dérivé localement
• manual — Saisi manuellement

Rôle d’une adresse e-mail

• from
• sender
• reply_to
• return_path
• to
• cc
• bcc
• message_id_domain
• other

Rôle SMTP

• declared_source
• smtp_relay
• destination_server
• private_infrastructure
• unknown

Type de valeur

• text
• identifier
• email
• iban
• bic
• ip_address
• domain
• uri
• integer
• decimal
• date
• datetime
• boolean
• json

Les codes persistés doivent rester stables et indépendants des libellés français affichés.

Une API métier doit refuser les codes inconnus.

Un composant GTK4 réutilisable doit permettre de sélectionner ces valeurs sans saisie libre.

Interface de révision

Après l’analyse, une interface doit présenter :

• le résumé du message ;
• les en-têtes importants ;
• la chaîne SMTP ;
• les pièces jointes ;
• les métadonnées ;
• les résultats OCR ;
• les données bancaires proposées ;
• les avertissements ;
• les erreurs ;
• la provenance de chaque proposition.

Chaque proposition doit pouvoir être :

• sélectionnée ;
• désélectionnée ;
• corrigée si elle est textuelle ;
• marquée avec un statut contrôlé ;
• rattachée à une entité existante ;
• utilisée pour créer une entité ;
• rejetée explicitement.

Avant validation, l’interface doit afficher un bilan :

• fichiers dérivés enregistrés ;
• entités créées ;
• entités existantes enrichies ;
• relations créées ;
• propositions rejetées ;
• conflits détectés.

La validation finale doit être transactionnelle.

Une erreur SQLite doit provoquer un rollback complet des écritures associées.

Entités et relations

Après confirmation, le pivot doit pouvoir créer ou réutiliser notamment :

• une adresse e-mail ;
• un domaine ;
• une adresse IP ;
• un message électronique ou un identifiant Message-ID si le modèle le justifie ;
• une organisation bancaire ;
• un compte bancaire ou IBAN ;
• une personne nommée comme titulaire, sans l’identifier automatiquement comme suspect.

Les relations doivent utiliser le référentiel canonique des types de relations.

Exemples conceptuels :

• message envoyé depuis une adresse e-mail ;
• message envoyé vers une adresse e-mail ;
• message possédant une adresse de réponse ;
• message ayant une pièce jointe ;
• message relayé par un serveur ;
• adresse e-mail utilisant un domaine ;
• compte bancaire détenu auprès d’une banque ;
• personne nommée comme titulaire d’un compte.

La formulation doit décrire exactement ce qui est observé, sans produire d’attribution non démontrée.

Provenance et audit

Chaque traitement doit conserver :

• identifiant de l’outil ;
• version de l’outil ;
• arguments ;
• date UTC ;
• fichier d’entrée ;
• SHA-256 de l’entrée ;
• sortie brute ;
• SHA-256 de la sortie ;
• statut ;
• erreurs ;
• objets créés ou réutilisés ;
• valeurs confirmées ;
• valeurs rejetées ;
• corrections manuelles.

Une sortie brute ne doit jamais être modifiée pour correspondre à une correction humaine.

Contraintes techniques

• réutiliser les modules EML, OCR, IBAN, ExifTool et extractions existants ;
• ne pas créer une architecture concurrente ;
• aucun accès SQLite direct depuis les widgets ;
• aucun GTK dans les modèles, DAO ou services ;
• utiliser GSubprocess avec des arguments séparés ;
• ne jamais construire une commande shell dynamique ;
• aucune installation automatique d’un outil ;
• utiliser des tâches asynchrones ;
• respecter C17 et les conventions du dépôt ;
• utiliser des fixtures synthétiques ;
• ne jamais inclure les données réelles de l’enquête dans le dépôt.

Les dépendances nouvelles doivent être disponibles sous Arch Linux et Ubuntu et être documentées.

Critères d’acceptation

• Une preuve .eml peut lancer un pivot complet.
• L’intégrité de la preuve est vérifiée avant traitement.
• La preuve originale n’est jamais modifiée.
• La structure MIME est analysée.
• Les pièces jointes sont extraites de manière sécurisée.
• Chaque pièce jointe reçoit un SHA-256 et un type MIME détecté.
• Les fichiers dérivés sont reliés à l’EML source.
• Les en-têtes importants sont représentés sous forme structurée.
• La chaîne Received conserve son ordre.
• Une IP de relais n’est pas présentée comme IP du suspect.
• ExifTool conserve sa sortie brute.
• Les métadonnées importantes utilisent des codes stables.
• L’OCR conserve le texte brut et sa provenance.
• Les IBAN sont normalisés et validés.
• Les corrections OCR ne sont jamais silencieuses.
• Les BIC sont normalisés et validés.
• Les composants RIB dérivés sont distingués des composants observés.
• Le titulaire et la banque restent des propositions révisables.
• Les statuts, rôles et provenances utilisent des listes contrôlées.
• Une valeur brute ne peut pas être modifiée.
• Une correction crée une valeur révisée distincte.
• Aucune proposition n’est intégrée sans confirmation.
• L’intégration SQLite est transactionnelle.
• Les entités existantes peuvent être réutilisées.
• Les relations utilisent leurs types canoniques.
• Le graphe et la barre latérale sont rafraîchis après intégration.
• L’absence d’un outil optionnel produit un résultat partiel, pas un échec global.
• Les tests utilisent uniquement des données synthétiques.
• La documentation est mise à jour.

Tests attendus

Ajouter au minimum des tests pour :

1. en-têtes EML pliés ;
2. chaîne de plusieurs Received ;
3. dates et fuseaux différents ;
4. multipart imbriqué ;
5. pièce jointe Base64 ;
6. pièce jointe quoted-printable ;
7. contenu inline ;
8. noms RFC 2047 ou RFC 2231 ;
9. traversée de chemin ;
10. collision de noms ;
11. MIME malformé ;
12. limite de taille et profondeur ;
13. annulation ;
14. IBAN français valide ;
15. IBAN invalide ;
16. correction OCR proposée mais non appliquée automatiquement ;
17. BIC valide de 8 caractères ;
18. BIC valide de 11 caractères ;
19. BIC invalide ;
20. titulaire avec accents ;
21. banque sur plusieurs lignes ;
22. composants RIB observés ;
23. composants RIB dérivés ;
24. doublon d’IBAN existant ;
25. correction manuelle conservant la valeur brute ;
26. rejet d’une proposition ;
27. rollback transactionnel ;
28. sortie ExifTool brute ;
29. codes de métadonnées déterministes ;
30. coordonnées GPS nécessitant confirmation ;
31. outil optionnel absent ;
32. refus d’un code de vocabulaire inconnu ;
33. mapping code/libellé ;
34. impossibilité de saisir un statut arbitraire ;
35. migration d’une ancienne base ;
36. création d’une base neuve ;
37. rechargement du graphe après intégration.

Hors périmètre

• interrogation d’une API bancaire externe ;
• identification automatique du titulaire réel ;
• attribution automatique d’un e-mail à un suspect ;
• reconnaissance faciale ;
• géolocalisation active ;
• chargement de ressources distantes ;
• ouverture automatique des pièces jointes ;
• installation automatique des outils ;
• récupération automatique de mots de passe PDF ;
• transformation immédiate de tous les formulaires de l’application ;
• fusion silencieuse d’entités contradictoires.

Définition de terminé

Le ticket est terminé lorsque :

• le flux complet EML vers révision fonctionne ;
• les résultats sont traçables ;
• les pièces jointes sont extraites en sécurité ;
• les métadonnées et résultats OCR sont conservés ;
• les données bancaires sont normalisées ;
• aucune donnée n’est confirmée automatiquement ;
• les vocabulaires fermés utilisent des listes contrôlées ;
• l’intégration SQLite est transactionnelle ;
• les interfaces se rafraîchissent après validation ;
• les anciennes bases sont migrées sans perte ;
• les tests ciblés et la suite complète passent ;
• make clean réussit ;
• make -j8 réussit ;
• make -j8 test ou make test réussit ;
• git diff --check réussit ;
• aucun commit ni push n’est effectué avant validation manuelle.

# Ajouter un pivot e-mail forensique avec OCR, métadonnées et normalisation des données ## Contexte Labfy Investigation permet déjà d’importer des preuves, de conserver leurs empreintes, d’analyser certains fichiers EML, d’exécuter un OCR sur des RIB et d’extraire des métadonnées avec ExifTool. Ces fonctionnalités doivent maintenant être réunies dans un flux cohérent permettant d’exploiter une preuve `.eml` et ses pièces jointes comme point de départ d’un pivot d’enquête. Un e-mail frauduleux peut contenir ou transporter : * des adresses e-mail ; * des noms de domaine ; * des adresses IP et relais SMTP ; * un identifiant `Message-ID` ; * des images ; * un RIB ; * un IBAN ; * un BIC ; * un nom de titulaire ; * un nom de banque ; * des documents PDF ; * des métadonnées techniques ; * des liens avec d’autres preuves, entités ou relations. Ces informations ne doivent pas être intégrées automatiquement comme des faits établis. Elles doivent être extraites, normalisées, présentées à l’utilisateur, corrigées si nécessaire, puis confirmées explicitement. ## Problème Les analyses existantes sont encore trop séparées : * l’analyse EML produit des informations techniques ; * l’OCR bancaire analyse un fichier isolé ; * ExifTool produit des métadonnées ; * les extractions ne sont pas toujours présentées dans un parcours unique ; * certaines valeurs peuvent encore être enregistrées sous des formulations incohérentes ; * la différence entre valeur brute, valeur normalisée, valeur dérivée et valeur confirmée n’est pas toujours clairement représentée ; * les pièces jointes ne sont pas encore exploitées automatiquement comme fichiers dérivés de l’e-mail source. Le projet doit éviter deux erreurs opposées : 1. enregistrer automatiquement des résultats OCR potentiellement faux ; 2. transformer toutes les valeurs en listes fermées alors que des éléments comme un IBAN, un BIC, un nom ou une adresse sont naturellement uniques. ## Objectif Créer une action complète de pivot e-mail permettant de : 1. analyser les en-têtes et la structure MIME d’un fichier `.eml` ; 2. extraire ses pièces jointes sans modifier la preuve originale ; 3. calculer les empreintes et métadonnées des fichiers extraits ; 4. exécuter l’OCR sur les images et PDF compatibles ; 5. détecter les données bancaires et autres identifiants utiles ; 6. normaliser les valeurs sans masquer leur forme originale ; 7. présenter toutes les propositions dans une interface de révision ; 8. intégrer uniquement les éléments confirmés ; 9. créer ou réutiliser les entités et relations correspondantes ; 10. conserver la provenance complète de chaque donnée. ## Principes de données Chaque donnée extraite doit pouvoir distinguer : * la valeur brute observée ; * la valeur normalisée ; * la valeur dérivée localement ; * la correction apportée par l’utilisateur ; * le statut de vérification ; * la confiance ; * la preuve source ; * l’extraction source ; * la date d’extraction ; * l’outil et sa version. Une valeur brute ne doit jamais être modifiée. Une correction utilisateur doit être conservée séparément de la valeur brute. Un résultat OCR ne doit jamais être automatiquement considéré comme confirmé. ## Analyse du message EML L’analyse doit extraire et présenter au minimum : * `From` ; * `Sender` ; * `Reply-To` ; * `Return-Path` ; * `To` ; * `Cc` ; * `Bcc` lorsqu’il est présent ; * `Subject` ; * `Date` ; * `Message-ID` ; * `In-Reply-To` ; * `References` ; * `MIME-Version` ; * `Content-Type` ; * `Authentication-Results` ; * SPF ; * DKIM ; * DMARC ; * l’ensemble des en-têtes `Received`, dans leur ordre réel. Les dates doivent être conservées sous leur forme brute et normalisées en UTC lorsque leur analyse est possible. Les adresses IP ou noms d’hôtes présents dans la chaîne SMTP doivent recevoir un rôle proposé parmi un vocabulaire contrôlé : * source déclarée ; * relais SMTP ; * serveur destinataire ; * infrastructure privée ; * rôle indéterminé. Une adresse IP observée dans un en-tête `Received` ne doit jamais être automatiquement présentée comme l’adresse IP personnelle du suspect. ## Extraction des pièces jointes Chaque pièce jointe doit devenir un fichier dérivé de la preuve EML. L’extraction doit : * préserver la preuve originale ; * assainir les noms de fichiers ; * neutraliser les chemins absolus et les traversées `../` ; * gérer les collisions sans écrasement ; * calculer le SHA-256 ; * enregistrer la taille ; * détecter le type MIME réel ; * conserver le type MIME déclaré ; * conserver le chemin MIME de la partie ; * conserver `Content-ID` ; * conserver `Content-Disposition` ; * conserver `Content-Transfer-Encoding` ; * distinguer les contenus inline des véritables pièces jointes ; * relier le fichier dérivé à l’EML source. Aucune pièce jointe ne doit être exécutée ou ouverte automatiquement. Aucune ressource distante contenue dans un e-mail HTML ne doit être chargée automatiquement. Des limites doivent protéger l’application contre : * un nombre excessif de parties MIME ; * une profondeur MIME anormale ; * une taille décodée excessive ; * un encodage Base64 invalide ; * un nom de fichier malveillant ; * une expansion excessive ; * un contenu tronqué. ## Métadonnées techniques Les fichiers compatibles doivent être analysés avec l’intégration ExifTool existante. Deux niveaux doivent être conservés : ### Sortie brute * JSON complet produit par ExifTool ; * version de l’outil ; * arguments utilisés ; * date UTC ; * empreinte de la sortie ; * fichier analysé. ### Métadonnées normalisées Les métadonnées utiles doivent être représentées avec des codes métier stables, par exemple : * `file.mime_type` * `file.size_bytes` * `file.detected_extension` * `image.width` * `image.height` * `image.orientation` * `image.software` * `image.make` * `image.model` * `image.datetime_original` * `image.gps_latitude` * `image.gps_longitude` * `document.author` * `document.creator` * `document.producer` * `document.creation_time` * `document.modification_time` Les noms originaux produits par ExifTool doivent rester accessibles. Les coordonnées GPS doivent nécessiter une confirmation explicite avant intégration. ## OCR des images et PDF L’OCR doit réutiliser l’infrastructure existante. Il doit : * fonctionner en tâche de fond ; * être annulable ; * conserver la sortie texte brute ; * conserver l’outil, sa version, la langue et les paramètres ; * permettre au minimum le français et l’anglais ; * rattacher le résultat au fichier exact ; * conserver le numéro de page pour les PDF ; * ne jamais écraser une extraction précédente. Pour les PDF : * utiliser d’abord le texte natif lorsqu’il existe ; * utiliser un rendu image et l’OCR seulement lorsque nécessaire ; * signaler les documents chiffrés ou non lisibles ; * ne pas lancer automatiquement de récupération de mot de passe. L’absence de Tesseract ne doit pas empêcher l’analyse EML et l’extraction des métadonnées. ## Extraction des données bancaires L’analyse doit détecter au minimum : * IBAN ; * BIC/SWIFT ; * titulaire du compte ; * nom de la banque ; * adresse de la banque ; * code pays ; * code banque ; * code guichet ; * numéro de compte ; * clé RIB. ### IBAN L’IBAN doit être : * conservé sous sa graphie OCR brute ; * normalisé sans espaces et en majuscules ; * contrôlé selon sa longueur nationale ; * validé par MOD-97 ; * marqué invalide lorsqu’il échoue ; * accompagné de toute correction OCR proposée. Les corrections telles que `O` vers `0` ou `I` vers `1` ne doivent jamais être appliquées silencieusement. Pour un IBAN français valide, les composants RIB peuvent être dérivés, mais ils doivent être marqués comme : ```text Dérivés localement depuis l’IBAN ``` et non comme observés dans le document. ### BIC Le BIC doit être : * conservé sous sa forme brute ; * normalisé en majuscules ; * validé sur 8 ou 11 caractères ; * marqué invalide lorsqu’il ne respecte pas le format. Le BIC ne doit jamais être inventé depuis le nom supposé de la banque. ### Titulaire et banque Le titulaire et la banque restent des propositions textuelles. Le système doit : * conserver le texte OCR brut ; * conserver l’extrait ayant permis la détection ; * réduire les espaces superflus ; * préserver les accents ; * permettre une correction humaine ; * éviter toute transformation destructive. Un nom indiqué comme titulaire sur un RIB ne prouve pas que cette personne est l’auteur de l’escroquerie. ## Valeurs libres et vocabulaires contrôlés Les valeurs suivantes restent des champs textuels spécialisés : * IBAN ; * BIC ; * nom de titulaire ; * nom de banque ; * adresse ; * adresse e-mail ; * domaine ; * Message-ID ; * URI. En revanche, les champs fermés doivent utiliser un référentiel et une liste déroulante. ### Statut de vérification * `proposed` — Proposé * `confirmed` — Confirmé * `rejected` — Rejeté * `conflicted` — Contradictoire * `invalid` — Invalide ### Provenance * `observed` — Observé directement * `ocr` — Extrait par OCR * `header` — Extrait d’un en-tête * `metadata` — Extrait des métadonnées * `derived` — Dérivé localement * `manual` — Saisi manuellement ### Rôle d’une adresse e-mail * `from` * `sender` * `reply_to` * `return_path` * `to` * `cc` * `bcc` * `message_id_domain` * `other` ### Rôle SMTP * `declared_source` * `smtp_relay` * `destination_server` * `private_infrastructure` * `unknown` ### Type de valeur * `text` * `identifier` * `email` * `iban` * `bic` * `ip_address` * `domain` * `uri` * `integer` * `decimal` * `date` * `datetime` * `boolean` * `json` Les codes persistés doivent rester stables et indépendants des libellés français affichés. Une API métier doit refuser les codes inconnus. Un composant GTK4 réutilisable doit permettre de sélectionner ces valeurs sans saisie libre. ## Interface de révision Après l’analyse, une interface doit présenter : * le résumé du message ; * les en-têtes importants ; * la chaîne SMTP ; * les pièces jointes ; * les métadonnées ; * les résultats OCR ; * les données bancaires proposées ; * les avertissements ; * les erreurs ; * la provenance de chaque proposition. Chaque proposition doit pouvoir être : * sélectionnée ; * désélectionnée ; * corrigée si elle est textuelle ; * marquée avec un statut contrôlé ; * rattachée à une entité existante ; * utilisée pour créer une entité ; * rejetée explicitement. Avant validation, l’interface doit afficher un bilan : * fichiers dérivés enregistrés ; * entités créées ; * entités existantes enrichies ; * relations créées ; * propositions rejetées ; * conflits détectés. La validation finale doit être transactionnelle. Une erreur SQLite doit provoquer un rollback complet des écritures associées. ## Entités et relations Après confirmation, le pivot doit pouvoir créer ou réutiliser notamment : * une adresse e-mail ; * un domaine ; * une adresse IP ; * un message électronique ou un identifiant `Message-ID` si le modèle le justifie ; * une organisation bancaire ; * un compte bancaire ou IBAN ; * une personne nommée comme titulaire, sans l’identifier automatiquement comme suspect. Les relations doivent utiliser le référentiel canonique des types de relations. Exemples conceptuels : * message envoyé depuis une adresse e-mail ; * message envoyé vers une adresse e-mail ; * message possédant une adresse de réponse ; * message ayant une pièce jointe ; * message relayé par un serveur ; * adresse e-mail utilisant un domaine ; * compte bancaire détenu auprès d’une banque ; * personne nommée comme titulaire d’un compte. La formulation doit décrire exactement ce qui est observé, sans produire d’attribution non démontrée. ## Provenance et audit Chaque traitement doit conserver : * identifiant de l’outil ; * version de l’outil ; * arguments ; * date UTC ; * fichier d’entrée ; * SHA-256 de l’entrée ; * sortie brute ; * SHA-256 de la sortie ; * statut ; * erreurs ; * objets créés ou réutilisés ; * valeurs confirmées ; * valeurs rejetées ; * corrections manuelles. Une sortie brute ne doit jamais être modifiée pour correspondre à une correction humaine. ## Contraintes techniques * réutiliser les modules EML, OCR, IBAN, ExifTool et extractions existants ; * ne pas créer une architecture concurrente ; * aucun accès SQLite direct depuis les widgets ; * aucun GTK dans les modèles, DAO ou services ; * utiliser `GSubprocess` avec des arguments séparés ; * ne jamais construire une commande shell dynamique ; * aucune installation automatique d’un outil ; * utiliser des tâches asynchrones ; * respecter C17 et les conventions du dépôt ; * utiliser des fixtures synthétiques ; * ne jamais inclure les données réelles de l’enquête dans le dépôt. Les dépendances nouvelles doivent être disponibles sous Arch Linux et Ubuntu et être documentées. ## Critères d’acceptation * [ ] Une preuve `.eml` peut lancer un pivot complet. * [ ] L’intégrité de la preuve est vérifiée avant traitement. * [ ] La preuve originale n’est jamais modifiée. * [ ] La structure MIME est analysée. * [ ] Les pièces jointes sont extraites de manière sécurisée. * [ ] Chaque pièce jointe reçoit un SHA-256 et un type MIME détecté. * [ ] Les fichiers dérivés sont reliés à l’EML source. * [ ] Les en-têtes importants sont représentés sous forme structurée. * [ ] La chaîne `Received` conserve son ordre. * [ ] Une IP de relais n’est pas présentée comme IP du suspect. * [ ] ExifTool conserve sa sortie brute. * [ ] Les métadonnées importantes utilisent des codes stables. * [ ] L’OCR conserve le texte brut et sa provenance. * [ ] Les IBAN sont normalisés et validés. * [ ] Les corrections OCR ne sont jamais silencieuses. * [ ] Les BIC sont normalisés et validés. * [ ] Les composants RIB dérivés sont distingués des composants observés. * [ ] Le titulaire et la banque restent des propositions révisables. * [ ] Les statuts, rôles et provenances utilisent des listes contrôlées. * [ ] Une valeur brute ne peut pas être modifiée. * [ ] Une correction crée une valeur révisée distincte. * [ ] Aucune proposition n’est intégrée sans confirmation. * [ ] L’intégration SQLite est transactionnelle. * [ ] Les entités existantes peuvent être réutilisées. * [ ] Les relations utilisent leurs types canoniques. * [ ] Le graphe et la barre latérale sont rafraîchis après intégration. * [ ] L’absence d’un outil optionnel produit un résultat partiel, pas un échec global. * [ ] Les tests utilisent uniquement des données synthétiques. * [ ] La documentation est mise à jour. ## Tests attendus Ajouter au minimum des tests pour : 1. en-têtes EML pliés ; 2. chaîne de plusieurs `Received` ; 3. dates et fuseaux différents ; 4. multipart imbriqué ; 5. pièce jointe Base64 ; 6. pièce jointe quoted-printable ; 7. contenu inline ; 8. noms RFC 2047 ou RFC 2231 ; 9. traversée de chemin ; 10. collision de noms ; 11. MIME malformé ; 12. limite de taille et profondeur ; 13. annulation ; 14. IBAN français valide ; 15. IBAN invalide ; 16. correction OCR proposée mais non appliquée automatiquement ; 17. BIC valide de 8 caractères ; 18. BIC valide de 11 caractères ; 19. BIC invalide ; 20. titulaire avec accents ; 21. banque sur plusieurs lignes ; 22. composants RIB observés ; 23. composants RIB dérivés ; 24. doublon d’IBAN existant ; 25. correction manuelle conservant la valeur brute ; 26. rejet d’une proposition ; 27. rollback transactionnel ; 28. sortie ExifTool brute ; 29. codes de métadonnées déterministes ; 30. coordonnées GPS nécessitant confirmation ; 31. outil optionnel absent ; 32. refus d’un code de vocabulaire inconnu ; 33. mapping code/libellé ; 34. impossibilité de saisir un statut arbitraire ; 35. migration d’une ancienne base ; 36. création d’une base neuve ; 37. rechargement du graphe après intégration. ## Hors périmètre * interrogation d’une API bancaire externe ; * identification automatique du titulaire réel ; * attribution automatique d’un e-mail à un suspect ; * reconnaissance faciale ; * géolocalisation active ; * chargement de ressources distantes ; * ouverture automatique des pièces jointes ; * installation automatique des outils ; * récupération automatique de mots de passe PDF ; * transformation immédiate de tous les formulaires de l’application ; * fusion silencieuse d’entités contradictoires. ## Définition de terminé Le ticket est terminé lorsque : * le flux complet EML vers révision fonctionne ; * les résultats sont traçables ; * les pièces jointes sont extraites en sécurité ; * les métadonnées et résultats OCR sont conservés ; * les données bancaires sont normalisées ; * aucune donnée n’est confirmée automatiquement ; * les vocabulaires fermés utilisent des listes contrôlées ; * l’intégration SQLite est transactionnelle ; * les interfaces se rafraîchissent après validation ; * les anciennes bases sont migrées sans perte ; * les tests ciblés et la suite complète passent ; * `make clean` réussit ; * `make -j8` réussit ; * `make -j8 test` ou `make test` réussit ; * `git diff --check` réussit ; * aucun commit ni push n’est effectué avant validation manuelle.

fy59 commented 2026-07-28 09:23:40 +02:00

Author

Owner

Copy link

Le pivot EML forensique est terminé.

Fonctionnalités livrées :

• vérification de l’intégrité SHA-256 de la preuve avant analyse ;
• analyse qualifiée des en-têtes EML ;
• extraction MIME récursive et sécurisée ;
• prise en charge des pièces jointes et contenus inline ;
• analyse PDF native avec repli OCR ;
• OCR français/anglais ;
• métadonnées ExifTool avec provenance ;
• extraction et validation des propositions bancaires ;
• distinction entre proposition, observation persistante et entité du graphe ;
• conservation des observations dans la fiche sans création automatique de nœud ;
• promotion facultative et explicite vers le graphe ;
• retrait réversible du graphe sans suppression de l’observation ;
• protection des entités partagées, manuelles et historiques ;
• rafraîchissement et restauration de la preuve sélectionnée ;
• déduplication et transactions atomiques.

Migrations ajoutées :

• V11 : observations sémantiques liées aux entités ;
• V12 : observations indépendantes avec promotion facultative ;
• V13 : traçabilité des sources des liens preuve-entité et protection des rattachements manuels ou historiques.

Validation :

• compilation complète avec make -j8 ;
• suite complète avec make -j8 test ;
• tous les tests sont valides ;
• git diff --check sans erreur ;
• parcours GTK validé manuellement sur une enquête synthétique ;
• retrait d’une promotion EML sans suppression d’un rattachement manuel validé.

Limitation non bloquante :

• la promotion est disponible depuis le dialogue d’analyse, mais pas encore directement depuis la fiche de détails.

Le pivot EML forensique est terminé. Fonctionnalités livrées : - vérification de l’intégrité SHA-256 de la preuve avant analyse ; - analyse qualifiée des en-têtes EML ; - extraction MIME récursive et sécurisée ; - prise en charge des pièces jointes et contenus inline ; - analyse PDF native avec repli OCR ; - OCR français/anglais ; - métadonnées ExifTool avec provenance ; - extraction et validation des propositions bancaires ; - distinction entre proposition, observation persistante et entité du graphe ; - conservation des observations dans la fiche sans création automatique de nœud ; - promotion facultative et explicite vers le graphe ; - retrait réversible du graphe sans suppression de l’observation ; - protection des entités partagées, manuelles et historiques ; - rafraîchissement et restauration de la preuve sélectionnée ; - déduplication et transactions atomiques. Migrations ajoutées : - V11 : observations sémantiques liées aux entités ; - V12 : observations indépendantes avec promotion facultative ; - V13 : traçabilité des sources des liens preuve-entité et protection des rattachements manuels ou historiques. Validation : - compilation complète avec make -j8 ; - suite complète avec make -j8 test ; - tous les tests sont valides ; - git diff --check sans erreur ; - parcours GTK validé manuellement sur une enquête synthétique ; - retrait d’une promotion EML sans suppression d’un rattachement manuel validé. Limitation non bloquante : - la promotion est disponible depuis le dialogue d’analyse, mais pas encore directement depuis la fiche de détails.

fy59 closed this issue 2026-07-28 09:23:44 +02:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fy59/labfy-investigation#107

No description provided.