Metadati, EXIF, XMP, C2PA e provenienza dei file

Introduzione

I metadati sono informazioni che descrivono un file, il suo contenuto, il dispositivo che può averlo prodotto, il software che può averlo elaborato, le date associate, le coordinate geografiche eventualmente registrate e, in alcuni casi, la successione delle modifiche.

Una fotografia può contenere il modello della fotocamera, la data indicata dal dispositivo, i parametri di esposizione e le coordinate GPS. Un video può registrare informazioni sul contenitore, sui flussi audio e video, sul software di codifica e sugli orari memorizzati negli atomi QuickTime. Un documento può contenere il nome del programma che lo ha creato, un identificatore interno, una cronologia XMP o riferimenti a versioni precedenti.

Queste informazioni possono essere molto utili in una perizia informatica, ma non devono essere interpretate in modo automatico.

Un campo denominato DateTimeOriginal non dimostra, da solo, che il contenuto sia stato realmente acquisito in quel preciso momento. Una coordinata GPS non dimostra necessariamente che il dispositivo si trovasse davvero in quel luogo. La presenza del nome di un programma non identifica automaticamente la persona che lo ha utilizzato. L’assenza di metadati non dimostra che il file sia falso o manipolato.

La corretta analisi deve quindi distinguere:

1. ciò che il file dichiara;
2. ciò che la struttura tecnica del file conferma;
3. ciò che può essere verificato crittograficamente;
4. ciò che può essere correlato con dispositivi, account, email, cloud, messaggi, log e altri reperti;
5. ciò che rimane soltanto un’ipotesi.

Nel contesto di una perizia informatica a Roma, la domanda utile non è semplicemente:

La domanda corretta è:

Alla data di aggiornamento del capitolo, CIPA indica Exif 3.1 come revisione corrente dello standard Exchangeable Image File Format e ha pubblicato nel giugno 2026 una revisione specifica per la rappresentazione dei metadati Exif in XMP. La documentazione Adobe continua a descrivere XMP come modello estensibile, serializzazione e insieme di proprietà incorporabili o conservabili in file sidecar. La specifica C2PA vigente è la versione 2.4, pubblicata nell’aprile 2026.

Sintesi operativa

L’analisi forense dei metadati deve seguire questa sequenza:

1. acquisire il file nella forma più vicina possibile all’originale;
2. documentare fonte, modalità di consegna e contesto;
3. calcolare l’hash prima dell’analisi;
4. identificare il formato reale, senza fidarsi dell’estensione;
5. estrarre tutti i metadati senza modificare il reperto;
6. distinguere metadati di file system, incorporati, sidecar e di provenienza;
7. analizzare EXIF, XMP, IPTC, QuickTime, PDF, JUMBF e C2PA;
8. verificare date, fusi orari, GPS, dispositivi e software;
9. cercare duplicati, conflitti e valori anomali;
10. confrontare eventuali versioni del file;
11. correlare i risultati con dispositivo, chat, email, PEC, cloud e log;
12. descrivere sempre limiti e ipotesi alternative;
13. conservare output, versioni degli strumenti e parametri usati;
14. formulare conclusioni proporzionate agli elementi disponibili.

1. Avvertenza preliminare

Le procedure descritte in questo capitolo devono essere utilizzate esclusivamente:

• su file propri;
• su materiale consegnato dal legittimo titolare;
• nell’ambito di un incarico professionale autorizzato;
• in attività difensive, aziendali o peritali lecite;
• su copie di lavoro, conservando separatamente il reperto originale;
• nel rispetto della riservatezza e della minimizzazione dei dati.

L’analisi di metadati può far emergere:

• coordinate geografiche;
• nominativi;
• numeri seriali;
• identificativi di dispositivi;
• percorsi locali;
• nomi utente;
• indirizzi email;
• informazioni sanitarie o professionali;
• dettagli su minori o soggetti terzi;
• informazioni su luoghi privati;
• riferimenti a infrastrutture aziendali.

Il perito deve quindi evitare la diffusione non necessaria di tali informazioni e valutare quali dati inserire nella relazione, quali oscurare e quali conservare soltanto negli allegati tecnici riservati.

Il capitolo descrive accertamenti tecnici. Non sostituisce la valutazione dell’avvocato sulla rilevanza processuale, sull’ammissibilità o sulle modalità di produzione del documento.

2. Perché i metadati sono importanti in informatica forense

I metadati possono contribuire a rispondere a domande come:

• quale dispositivo può aver prodotto il file;
• quale software può averlo elaborato;
• quale data era configurata sul dispositivo;
• se il file contiene coordinate geografiche;
• se esistono miniature o anteprime incorporate;
• se il file è stato esportato o ricodificato;
• se più file derivano dallo stesso documento;
• se una versione è successiva a un’altra;
• se un’immagine presenta una cronologia XMP;
• se esiste un manifesto C2PA;
• se il contenuto dichiara un’origine fotografica o algoritmica;
• se il file consegnato è compatibile con l’originale o con una derivazione;
• se la struttura interna è coerente con il formato dichiarato;
• se sono presenti valori tra loro incompatibili.

In una causa civile a Roma, ad esempio, una fotografia può essere prodotta per dimostrare lo stato di un immobile. L’altra parte può contestare la data. L’analisi non deve limitarsi a leggere DateTimeOriginal, ma deve verificare almeno:

- hash e catena di custodia;
- formato reale;
- EXIF e MakerNotes;
- eventuale XMP;
- data del file system;
- GPS e fuso orario;
- software indicato;
- presenza di miniature;
- modalità di esportazione;
- messaggio, email o cloud da cui proviene;
- eventuali copie dello stesso contenuto;
- coerenza con altri documenti o eventi.

Un singolo dato debole può diventare più significativo quando converge con numerosi elementi indipendenti.

3. Che cosa sono i metadati

Il termine “metadati” indica dati che descrivono altri dati.

In ambito forense è opportuno evitare una definizione troppo generica e classificare i metadati in base al luogo e al processo che li ha generati.

3.1 Metadati del file system

Sono gestiti dal sistema operativo o dal supporto di memorizzazione:

• nome del file;
• percorso;
• dimensione;
• data di creazione nel file system;
• data di modifica;
• data di accesso;
• attributi;
• proprietario;
• permessi;
• identificatori del file system;
• informazioni della directory;
• eventuali record di journaling.

Questi dati appartengono al contesto del supporto o del sistema da cui il file è stato acquisito. Possono cambiare quando il file viene copiato, scaricato, estratto da un archivio o trasferito su un altro volume.

3.2 Metadati incorporati

Sono memorizzati all’interno del file:

• EXIF;
• XMP;
• IPTC-IIM;
• dati QuickTime;
• tag ID3;
• proprietà PDF;
• informazioni Office;
• profili colore;
• MakerNotes;
• commenti;
• miniature;
• identificatori;
• dati C2PA/JUMBF.

Tendono a viaggiare con il file, ma possono essere rimossi, riscritti o non supportati durante una conversione.

3.3 Metadati sidecar

Sono conservati in un file separato, ad esempio:

foto.raw
foto.xmp

Il sidecar può contenere regolazioni, valutazioni, parole chiave, coordinate, diritti e cronologia. La sua separazione crea un problema operativo: il file principale e il sidecar devono essere acquisiti e correlati insieme.

3.4 Metadati applicativi

Sono registrati da software specifici:

• Adobe Photoshop;
• Lightroom;
• Capture One;
• software di scanner;
• editor video;
• applicazioni mobili;
• sistemi documentali;
• software di firma;
• piattaforme cloud;
• gestionali aziendali.

Possono descrivere operazioni, strumenti, profili, versioni o identificatori.

3.5 Metadati di trasporto e contesto

Non si trovano necessariamente dentro il file, ma nel sistema che lo ha veicolato:

• header email;
• ricevute PEC;
• record di chat;
• database delle applicazioni;
• log cloud;
• URL;
• cronologia di download;
• messaggi di accompagnamento;
• record di sincronizzazione;
• audit log aziendali.

Spesso sono decisivi per ricostruire la provenienza.

3.6 Metadati di provenienza crittografica

Sono informazioni firmate o legate crittograficamente al contenuto, come i manifesti C2PA.

Non sono equivalenti ai normali campi EXIF o XMP: introducono meccanismi di firma, hash, convalida e fiducia del certificato.

4. Che cosa significa “provenienza del file”

La provenienza non coincide con un singolo campo.

Può comprendere:

• origine tecnica;
• origine documentale;
• dispositivo di acquisizione;
• software di creazione;
• successione delle elaborazioni;
• sistema da cui è stato esportato;
• canale attraverso cui è stato trasmesso;
• soggetto che lo ha consegnato;
• relazione con versioni precedenti;
• eventuali attestazioni crittografiche.

È utile distinguere almeno quattro concetti.

4.1 Provenienza tecnica

Risponde a domande come:

• il file presenta una struttura tipica di una fotografia da smartphone?
• è stato esportato da un editor?
• è un’immagine ricodificata?
• contiene riferimenti a un’applicazione?
• deriva da un PDF, da uno scanner o da una schermata?

4.2 Provenienza logica

Riguarda la relazione tra file:

originale → modifica → esportazione → invio → download

Può essere ricostruita attraverso hash, nomi, dimensioni, XMP, C2PA, timestamp e contesto applicativo.

4.3 Provenienza soggettiva

Riguarda l’attribuzione a una persona.

È il livello più delicato. Il fatto che un campo contenga il nome “Mario Rossi” non prova che Mario Rossi abbia creato il file.

L’attribuzione personale può richiedere:

• disponibilità del dispositivo;
• credenziali;
• account;
• log di autenticazione;
• testimonianze;
• email;
• chat;
• accessi cloud;
• elementi biometrici o contestuali;
• ulteriori accertamenti.

4.4 Provenienza crittograficamente attestata

Riguarda informazioni firmate e collegate al contenuto, come un manifesto C2PA.

Anche in questo caso occorre distinguere:

• validità strutturale;
• integrità del contenuto;
• validità della firma;
• fiducia nella catena del certificato;
• identità del firmatario;
• significato delle singole dichiarazioni;
• completezza della storia.

C2PA descrive le Content Credentials come strutture crittograficamente legate al contenuto che possono contenere dichiarazioni su origine, modifiche e impiego dell’intelligenza artificiale. La specifica chiarisce però che la convalida non attribuisce automaticamente un giudizio di verità al contenuto dichiarato.

5. Una scala tecnica di attendibilità

La seguente è una scala operativa, non una gerarchia giuridica.

Livello 1 — Dichiarazione isolata

Esempi:

• nome del file;
• descrizione inserita dall’utente;
• campo autore;
• data EXIF non correlata;
• commento;
• nome della cartella.

Valore orientativo: basso se isolato.

Livello 2 — Coerenza interna

Più campi indipendenti risultano coerenti:

• EXIF;
• MakerNotes;
• XMP;
• profilo fotocamera;
• dimensioni;
• miniatura;
• dati ottici;
• codifica.

Valore orientativo: maggiore, ma non conclusivo.

Livello 3 — Correlazione esterna

Il contenuto è coerente con:

• database del dispositivo;
• messaggio originale;
• email;
• PEC;
• cloud;
• log;
• backup;
• cronologia del sistema;
• altre fotografie della stessa sequenza.

Valore orientativo: significativo, se le fonti sono acquisite correttamente.

Livello 4 — Integrità verificabile

Il file è collegato a:

• hash documentato;
• catena di custodia;
• firma digitale;
• marca temporale;
• manifesto C2PA valido;
• audit log affidabile.

Valore orientativo: elevato per gli aspetti effettivamente coperti dal meccanismo.

Livello 5 — Convergenza complessiva

Molteplici fonti tecniche e contestuali indipendenti conducono alla stessa ricostruzione.

La conclusione resta formulata nei limiti del materiale disponibile, ma la robustezza dell’ipotesi aumenta.

6. Le principali domande del cliente

Un cliente di Roma può formulare domande apparentemente semplici:

• “Quando è stata scattata questa foto?”
• “Dove è stata scattata?”
• “Con quale telefono?”
• “Il file è stato modificato?”
• “È stato creato con Photoshop?”
• “È stato generato con l’intelligenza artificiale?”
• “Chi ha creato il documento?”
• “Questa è la fotografia originale?”
• “Questo video proviene davvero da quell’iPhone?”
• “I metadati sono stati cancellati?”
• “La data è stata alterata?”
• “Il file che mi hanno inviato è lo stesso depositato in giudizio?”

La risposta professionale non deve precedere l’analisi.

7. Che cosa deve consegnare il cliente

7.1 Materiale principale

Richiedere, quando disponibile:

[ ] file originale;
[ ] eventuale file sidecar XMP;
[ ] versione ricevuta;
[ ] versione pubblicata;
[ ] versione depositata;
[ ] archivio ZIP originale;
[ ] email o PEC contenente il file;
[ ] chat contenente il file;
[ ] link cloud;
[ ] supporto fisico;
[ ] smartphone o computer sorgente;
[ ] backup;
[ ] report o esportazioni precedenti;
[ ] eventuale manifesto .c2pa esterno.

7.2 Informazioni di contesto

Annotare:

• chi ha consegnato il materiale;
• quando;
• con quale mezzo;
• da quale dispositivo;
• se il file è stato aperto;
• se è stato rinominato;
• se è stato inoltrato;
• se è stato convertito;
• se è stato salvato da una chat;
• se è stato scaricato da un social;
• se è stato stampato e poi scansionato;
• se esistono copie alternative;
• quale fatto si intende verificare.

7.3 Domande da porre

1. Il file è quello direttamente prodotto dal dispositivo?
2. È stato inviato tramite WhatsApp, Telegram, email o cloud?
3. È stato modificato con un’applicazione?
4. È stato salvato da una pagina web?
5. È stato ricevuto da terzi?
6. Esiste ancora il dispositivo di origine?
7. Esistono foto o video precedenti e successivi?
8. È disponibile il messaggio originale?
9. È disponibile l’account cloud?
10. Quale data, luogo o autore viene contestato?

8. Che cosa non basta

Non sono normalmente sufficienti, se isolati:

• una fotografia mostrata sullo schermo;
• uno screenshot dei metadati;
• la finestra “Proprietà” di Windows;
• la finestra “Informazioni” di macOS;
• una stampa;
• una fotografia della stampa;
• il solo nome del file;
• la data visibile in una galleria;
• una coordinata copiata manualmente;
• un report privo del file esaminato;
• una pagina web che visualizza EXIF;
• la presenza o assenza di un campo “Software”;
• l’icona Content Credentials senza il report di validazione;
• una dichiarazione verbale sull’origine.

Lo screenshot può documentare ciò che era visualizzato, ma non sostituisce l’acquisizione del file. La sua analisi specifica sarà trattata nel Capitolo 15 — Verifica forense di screenshot e schermate.

9. Triage iniziale del file

Il triage deve essere rapido ma documentato.

9.1 Verifiche iniziali

[ ] assegnare un codice caso;
[ ] acquisire l’autorizzazione;
[ ] registrare la fonte;
[ ] fotografare o documentare il supporto;
[ ] copiare il file con modalità controllata;
[ ] calcolare SHA-256;
[ ] registrare dimensione e nome;
[ ] identificare il formato reale;
[ ] verificare la presenza di sidecar;
[ ] estrarre i metadati in sola lettura;
[ ] registrare strumenti e versioni;
[ ] proteggere l’originale da scritture.

9.2 Formula di triage

Il triage generale della prova digitale è trattato nel Capitolo 1 — Triage iniziale della prova digitale a Roma.

10. Cartella di caso

Una struttura ordinata può essere:

CASO_RM_2026_014/
├── 00_incarico/
├── 01_verbali/
├── 02_originali/
├── 03_hash/
├── 04_copie_lavoro/
├── 05_exiftool/
├── 06_xmp/
├── 07_c2pa/
├── 08_mediainfo_ffprobe/
├── 09_confronti/
├── 10_timeline/
├── 11_immagini_estratte/
├── 12_report/
└── 13_relazione/

I file originali non devono essere utilizzati come destinazione degli output.

Esempio:

02_originali/IMG_4821.HEIC
03_hash/IMG_4821.HEIC.sha256.txt
05_exiftool/IMG_4821_exiftool.json
05_exiftool/IMG_4821_exiftool.txt
07_c2pa/IMG_4821_c2pa_info.txt
08_mediainfo_ffprobe/IMG_4821_mediainfo.json

11. Catena di custodia

L’analisi dei metadati non sostituisce la catena di custodia.

Il verbale dovrebbe indicare:

• identificativo del reperto;
• descrizione;
• nome originario;
• dimensione;
• fonte;
• data e ora di ricezione;
• soggetto consegnante;
• supporto;
• modalità di trasferimento;
• hash;
• posizione di conservazione;
• operatore;
• strumenti utilizzati;
• copie prodotte;
• eventuali anomalie.

12. Calcolo dell’hash

Windows PowerShell

Get-FileHash -Algorithm SHA256 -LiteralPath ".\IMG_4821.HEIC"

Linux

sha256sum -- IMG_4821.HEIC

macOS

shasum -a 256 -- IMG_4821.HEIC

Registrare:

Nome file:
Dimensione:
Algoritmo:
Hash SHA-256:
Data operazione:
Strumento:
Versione:
Operatore:

L’hash prova l’identità bit per bit tra file confrontati. Non prova, da solo, chi abbia creato il file, quando sia stato creato o se il contenuto rappresenti un fatto reale.

13. Identificare il formato reale

L’estensione può essere:

• errata;
• modificata;
• mancante;
• attribuita automaticamente;
• non coerente con la struttura interna.

Esempio:

documento.jpg

potrebbe essere:

• un JPEG;
• un PNG rinominato;
• un file WebP;
• un PDF;
• un archivio;
• un contenitore non valido.

Linux e macOS

file --brief --mime-type -- documento.jpg
file --brief -- documento.jpg
xxd -l 64 -- documento.jpg

PowerShell

Format-Hex -LiteralPath ".\documento.jpg" -Count 64

ExifTool

exiftool -FileType -FileTypeExtension -MIMEType -FileSize documento.jpg

14. Strumenti principali

14.1 ExifTool

Consente di leggere numerosi formati e famiglie di metadati, tra cui:

• EXIF;
• GPS;
• IPTC;
• XMP;
• MakerNotes;
• QuickTime;
• PDF;
• ICC;
• ID3;
• JUMBF e C2PA;
• dati incorporati.

Supporta output testuale, JSON, XML, CSV, visualizzazione dei gruppi, estrazione dei tag duplicati e analisi strutturale. La documentazione avverte inoltre che le operazioni di scrittura possono cambiare i file e che la rimozione dei metadati non è completa in ogni formato: in ambito forense lo strumento deve quindi essere utilizzato sul reperto in modalità di lettura e ogni eventuale esperimento di scrittura deve avvenire esclusivamente su copie dedicate.

14.2 Exiv2

Utile per una seconda lettura di EXIF, IPTC e XMP:

exiv2 -pa IMG_4821.jpg

Non sostituisce ExifTool, ma può contribuire alla verifica incrociata.

14.3 MediaInfo

Particolarmente utile per audio e video:

mediainfo FILE.mp4
mediainfo --Output=JSON FILE.mp4 > mediainfo.json

14.4 FFprobe

Per contenitori e flussi multimediali:

ffprobe -v error \
  -show_format \
  -show_streams \
  -show_chapters \
  -show_programs \
  -print_format json \
  FILE.mp4 > ffprobe.json

14.5 ImageMagick

Per una seconda lettura tecnica delle immagini:

magick identify -verbose IMG_4821.jpg > identify.txt

14.6 c2patool

Serve per leggere, validare ed esaminare manifesti C2PA. La documentazione ufficiale indica che può produrre report sintetici, report dettagliati, alberi dei manifesti, certificati e output di validazione.

14.7 Strumenti di analisi forense

A seconda del caso:

• X-Ways Forensics;
• Autopsy;
• Magnet AXIOM;
• FTK Imager;
• EnCase;
• Cellebrite;
• Oxygen Forensic Detective;
• strumenti specifici per immagini RAW;
• strumenti di analisi del file system;
• strumenti di timeline.

L’estrazione da computer è trattata nei capitoli dedicati all’analisi Windows e all’analisi macOS e Linux.

15. Registrare le versioni degli strumenti

Prima di ogni analisi:

exiftool -ver
c2patool -V
ffprobe -version
mediainfo --Version
magick -version
exiv2 --version

Salvare l’output:

strumento_versione_data.txt

Motivazione:

• il supporto ai formati cambia;
• nuovi tag vengono aggiunti;
• alcuni errori vengono corretti;
• il parser può produrre risultati diversi tra versioni;
• il report deve essere riproducibile.

16. Prima estrazione con ExifTool

16.1 Output leggibile completo

exiftool -G0:1:2 -a -s -u -ee -struct FILE > exiftool_full.txt

Significato delle opzioni:

• -G0:1:2: mostra più livelli di gruppo;
• -a: mostra anche tag duplicati;
• -s: usa i nomi tecnici dei tag;
• -u: include tag sconosciuti supportati;
• -ee: estrae dati incorporati;
• -struct: conserva strutture complesse.

ExifTool sopprime normalmente alcuni tag duplicati; l’opzione -a consente di visualizzarli. La documentazione consiglia l’uso dei gruppi per distinguere campi con lo stesso nome memorizzati in posizioni differenti.

16.2 Output JSON

exiftool -G0:1:2 -a -s -u -ee -struct -json FILE > exiftool_full.json

16.3 Valori numerici non convertiti

exiftool -G0:1:2 -a -s -u -ee -n FILE > exiftool_numeric.txt

L’output leggibile e quello numerico devono essere conservati entrambi.

16.4 Solo metadati temporali

exiftool -time:all -G0:1:2 -a -s FILE > exiftool_times.txt

16.5 Solo coordinate

exiftool -gps:all -G0:1:2 -a -s -n FILE > exiftool_gps.txt

16.6 EXIF, XMP e IPTC

exiftool \
  -EXIF:all \
  -XMP:all \
  -IPTC:all \
  -G0:1:2 \
  -a -s -struct \
  FILE > exif_xmp_iptc.txt

17. Validazione e analisi strutturale

17.1 Segnalazioni di struttura

exiftool -validate -warning -error -a FILE > validate.txt

Un warning non equivale automaticamente a manipolazione. Può derivare da:

• implementazione non standard;
• software del produttore;
• tag proprietari;
• file parzialmente danneggiato;
• ricodifica;
• parser non aggiornato;
• struttura tollerata da altri programmi.

17.2 Output verboso

exiftool -v3 FILE > verbose_v3.txt

Per casi complessi:

exiftool -v5 FILE > verbose_v5.txt

17.3 Mappa esadecimale HTML

exiftool -htmlDump FILE > structure_dump.html

L’output può aiutare a localizzare:

• segmenti JPEG;
• pacchetti XMP;
• blocchi EXIF;
• miniature;
• JUMBF;
• dati aggiunti;
• trailer;
• aree non decodificate.

18. EXIF: che cos’è

EXIF è un insieme di strutture e tag utilizzato soprattutto per immagini prodotte da fotocamere digitali e smartphone.

Può contenere:

• marca e modello;
• data e ora;
• tempi di esposizione;
• apertura;
• sensibilità;
• lunghezza focale;
• orientamento;
• dimensioni;
• coordinate;
• software;
• identificativi;
• miniature;
• informazioni del produttore.

La revisione corrente pubblicata da CIPA nel gennaio 2026 è Exif 3.1. Ciò non significa che tutti i dispositivi utilizzino tale revisione né che implementino gli stessi tag. Molti file continuano a contenere strutture e campi appartenenti a versioni precedenti.

18.1 Principali gruppi EXIF

IFD0
ExifIFD
GPS
InteropIFD
IFD1
MakerNotes
SubIFD

Lo stesso nome di tag può comparire in gruppi diversi. Per questo è importante non estrarre soltanto una vista semplificata.

19. Tag EXIF principali

20. Date e orari EXIF

20.1 Date da non confondere

Un’immagine può presentare:

FileCreateDate
FileModifyDate
DateTimeOriginal
CreateDate
ModifyDate
SubSecTimeOriginal
OffsetTimeOriginal
GPSDateTime
XMP:CreateDate
XMP:ModifyDate
XMP:MetadataDate

Questi campi non sono sinonimi.

20.2 Date del file system

FileCreateDate e FileModifyDate dipendono dal supporto e dal sistema operativo esaminato.

Una copia può:

• conservare la data di modifica;
• assegnare una nuova data di creazione;
• perdere parte della precisione;
• cambiare fuso;
• modificare gli attributi.

20.3 Date incorporate

DateTimeOriginal può rappresentare l’ora configurata sulla fotocamera o sul telefono.

Può essere errata a causa di:

• orologio non sincronizzato;
• fuso sbagliato;
• ora legale;
• batteria rimossa;
• ripristino;
• modifica manuale;
• software di gestione;
• conversione;
• importazione.

20.4 Fuso orario

Quando manca l’offset, non si deve attribuire automaticamente un fuso.

Esempio:

DateTimeOriginal: 2026:05:14 18:42:16
OffsetTimeOriginal: assente

La data può essere compatibile con l’ora locale di Roma, ma il solo valore non lo dimostra.

20.5 QuickTime e UTC

Nei contenitori QuickTime alcuni timestamp interi dovrebbero essere memorizzati in UTC, ma diversi dispositivi registrano valori locali. ExifTool, proprio per questa difformità pratica, non applica automaticamente l’ipotesi UTC salvo specifica opzione.

20.6 Regola operativa

Conservare sempre:

- valore originale;
- gruppo;
- formato;
- precisione;
- offset;
- interpretazione;
- eventuale conversione in UTC;
- motivazione della conversione.

Non sostituire nel report il valore originario con quello normalizzato.

21. Coordinate GPS

21.1 Campi principali

GPSLatitude
GPSLatitudeRef
GPSLongitude
GPSLongitudeRef
GPSAltitude
GPSAltitudeRef
GPSDateStamp
GPSTimeStamp
GPSHPositioningError
GPSImgDirection
GPSProcessingMethod

21.2 Estrazione numerica

exiftool \
  -GPSLatitude \
  -GPSLongitude \
  -GPSAltitude \
  -GPSDateTime \
  -GPSHPositioningError \
  -n FILE

21.3 Che cosa può indicare una coordinata

Una coordinata può essere compatibile con:

• luogo di acquisizione;
• posizione del dispositivo;
• posizione assegnata successivamente;
• coordinate importate;
• geotag manuale;
• localizzazione approssimativa;
• posizione di un punto di interesse;
• dato errato.

21.4 Che cosa non dimostra

Non dimostra automaticamente:

• che l’autore fosse presente;
• che il file non sia stato modificato;
• che il GPS fosse accurato;
• che il dispositivo fosse nelle mani del proprietario;
• che il contenuto visibile rappresenti proprio quel luogo;
• che la coordinata non sia stata inserita successivamente.

21.5 Verifica contestuale

Correlare, quando possibile, con:

• altre foto della sequenza;
• database fotografico del telefono;
• cronologia localizzazioni autorizzata;
• log;
• rete Wi-Fi;
• celle telefoniche, se legittimamente disponibili;
• percorso;
• ombre e condizioni ambientali;
• dati meteorologici;
• messaggi;
• eventi documentati;
• coordinate nei video;
• cloud.

21.6 Privacy

Le coordinate di abitazioni, minori, luoghi di cura o sedi riservate non devono essere pubblicate integralmente nella versione non riservata della relazione, salvo necessità.

22. Marca, modello e seriali

22.1 Modello dichiarato

Make: Apple
Model: iPhone ...

può essere compatibile con un determinato dispositivo, ma non identifica l’esemplare.

22.2 Numero seriale

La presenza di:

BodySerialNumber
CameraSerialNumber
InternalSerialNumber
LensSerialNumber

può consentire un confronto con un dispositivo acquisito.

Tuttavia:

• non tutti i produttori lo registrano;
• alcuni software lo rimuovono;
• può essere rappresentato in forme diverse;
• può essere modificabile;
• può riferirsi alla fotocamera, non all’autore;
• può sollevare problemi di riservatezza.

22.3 Formula tecnica

23. MakerNotes

I MakerNotes sono aree proprietarie create dai produttori.

Possono contenere:

• seriali;
• impostazioni;
• modalità di scatto;
• informazioni sull’obiettivo;
• firmware;
• dati di stabilizzazione;
• contatori;
• parametri computazionali;
• riferimenti a elaborazioni HDR;
• dati specifici di smartphone.

23.1 Utilità

Una combinazione coerente di MakerNotes può essere più significativa di un semplice campo Model.

23.2 Limiti

• formato proprietario;
• decodifica incompleta;
• differenze tra firmware;
• possibile perdita in esportazione;
• possibile danneggiamento;
• possibile reinterpretazione errata;
• tag sconosciuti;
• assenza non significativa.

23.3 Formula

24. Miniature e anteprime incorporate

Alcuni file contengono:

• ThumbnailImage;
• PreviewImage;
• anteprime RAW;
• immagini ridotte;
• immagini di guadagno HDR;
• fotogrammi di copertina.

24.1 Estrazione

exiftool -b -ThumbnailImage FILE > thumbnail.jpg
exiftool -b -PreviewImage FILE > preview.jpg

Calcolare l’hash anche delle immagini estratte.

24.2 Perché sono utili

Una miniatura può:

• mostrare una versione precedente;
• conservare un ritaglio differente;
• rivelare un contenuto non più visibile;
• aiutare a ricostruire il workflow;
• risultare incoerente con l’immagine principale.

24.3 Prudenza

Una differenza non dimostra automaticamente frode. Può derivare da:

• anteprima non aggiornata;
• comportamento del software;
• sviluppo RAW;
• modifica dell’orientamento;
• elaborazione HDR;
• esportazione;
• errore dell’applicazione.

25. Orientamento e rotazione

Una fotografia può apparire verticale senza che i pixel siano fisicamente ruotati.

Il tag Orientation indica al visualizzatore come rappresentare l’immagine.

Esempio:

Orientation: Rotate 90 CW

Un software può:

1. mantenere i pixel e cambiare il tag;
2. ruotare i pixel e impostare orientamento normale;
3. rimuovere il tag;
4. produrre un’anteprima differente.

L’orientamento non deve essere confuso con un ritocco sostanziale.

26. XMP: che cos’è

XMP è un modello estensibile per la definizione e il trattamento dei metadati.

Può essere:

• incorporato nel file;
• conservato in un sidecar;
• distribuito in più segmenti;
• utilizzato insieme a EXIF e IPTC;
• esteso con namespace applicativi.

Adobe descrive XMP come un modello dati, una serializzazione e un insieme di proprietà incorporabili in immagini, video e documenti; la documentazione sottolinea inoltre la necessità di riconciliare le informazioni XMP con i metadati non XMP presenti nello stesso file.

26.1 Esempi di namespace

XMP-xmp
XMP-xmpMM
XMP-dc
XMP-photoshop
XMP-crs
XMP-exif
XMP-tiff
XMP-iptcCore
XMP-iptcExt
XMP-xmpRights

26.2 Estrazione

exiftool -XMP:all -G0:1:2 -a -s -struct FILE > xmp.txt

27. EXIF e XMP possono contenere valori diversi

Esempio:

EXIF:DateTimeOriginal = 2026:05:14 18:42:16
XMP-exif:DateTimeOriginal = 2026:05:14 18:42:16+02:00
XMP-xmp:ModifyDate = 2026:05:15 09:12:44+02:00

Questa configurazione può essere coerente con:

• scatto il 14 maggio;
• apertura o modifica il 15 maggio;
• aggiunta dell’offset in XMP.

Ma può anche derivare da:

• sincronizzazione;
• importazione;
• correzione dei metadati;
• esportazione;
• copia tra cataloghi.

L’analisi deve indicare:

- namespace;
- valore;
- formato;
- ordine logico;
- eventuale conflitto;
- possibile processo generatore;
- limiti.

28. Principali tag XMP

29. DocumentID, InstanceID e OriginalDocumentID

29.1 DocumentID

Può identificare logicamente un documento attraverso più salvataggi.

29.2 InstanceID

Può identificare una specifica istanza o versione.

29.3 OriginalDocumentID

Può collegare una derivazione all’origine documentale.

29.4 Utilità forense

Se più file presentano:

• stesso DocumentID;
• InstanceID diversi;
• stesso OriginalDocumentID;
• cronologia coerente;

può emergere una relazione tecnica tra le versioni.

La documentazione dei tag XMP mostra che DocumentID, InstanceID, OriginalDocumentID, History, DerivedFrom e Ingredients possono essere rappresentati nello spazio XMP Media Management.

29.5 Limite

Gli identificatori:

• possono essere rimossi;
• possono non essere generati;
• possono essere duplicati;
• possono essere copiati;
• possono essere riscritti;
• non provano da soli la successione temporale.

30. Cronologia XMP

xmpMM:History può registrare:

• azione;
• data;
• software;
• modifiche;
• identificativo dell’istanza;
• parametri.

Esempio concettuale:

Action: created
When: 2026-05-14T18:42:16+02:00
SoftwareAgent: Camera

Action: saved
When: 2026-05-15T09:12:44+02:00
SoftwareAgent: Adobe Photoshop ...

Action: exported
When: 2026-05-15T09:14:03+02:00
SoftwareAgent: Adobe Photoshop ...

30.1 Valore

Può contribuire a ricostruire un workflow.

30.2 Limiti

La cronologia può essere:

• incompleta;
• rimossa;
• non aggiornata;
• copiata;
• generata da un’applicazione;
• non supportata;
• alterabile.

Non deve essere trattata come un log immodificabile.

31. IPTC

IPTC Photo Metadata è utilizzato soprattutto in ambito:

• giornalistico;
• fotografico;
• editoriale;
• archivistico;
• agenzie;
• gestione dei diritti.

Comprende IPTC Core e IPTC Extension e può rappresentare:

• autore;
• credito;
• fonte;
• didascalia;
• data;
• luogo;
• soggetti;
• diritti;
• persone rappresentate;
• informazioni editoriali.

IPTC indica la versione 2025.1 come revisione corrente del Photo Metadata Standard e vi ha introdotto campi per informazioni su contenuti generati con sistemi di intelligenza artificiale, inclusi sistema e versione utilizzati e informazioni sul prompt.

31.1 Prudenza

Un campo Creator è una dichiarazione.

Un campo Source può indicare un’agenzia, ma non prova che il file esaminato sia identico al file originariamente distribuito.

31.2 Conflitti IPTC-XMP

Confrontare:

• IPTC-IIM;
• XMP-IPTC Core;
• XMP-IPTC Extension;
• Photoshop;
• Dublin Core.

Esempio:

IPTC:By-line = Agenzia A
XMP-dc:Creator = Agenzia B

Il conflitto deve essere descritto, non risolto arbitrariamente.

32. C2PA e Content Credentials

C2PA è uno standard di provenienza digitale.

Le Content Credentials possono contenere dichiarazioni su:

• creazione;
• strumenti;
• modifiche;
• ingredienti;
• fonte digitale;
• uso dell’intelligenza artificiale;
• identità o organizzazioni, attraverso meccanismi o estensioni dedicate;
• relazioni tra versioni;
• hash;
• firma;
• certificato.

La versione 2.4 ha introdotto, tra le altre novità, nuovi formati e asserzioni, una rappresentazione JSON-LD derivata denominata crJSON, un’asserzione di disclosure AI e supporto ulteriore per diversi tipi di risorse. La specifica precisa che crJSON è una vista derivata e non costituisce autonomamente un oggetto verificabile.

33. Componenti fondamentali C2PA

33.1 Asset

Il file o flusso esaminato.

33.2 Manifest Store

Il contenitore dei manifesti associati.

33.3 Manifesto attivo

Il manifesto corrente da considerare nel processo di validazione.

33.4 Claim

La dichiarazione firmata che collega asserzioni e contenuto.

33.5 Assertion

Un’informazione dichiarata sul file:

• azioni;
• ingredienti;
• metadati;
• origine digitale;
• miniature;
• informazioni AI;
• dati personalizzati.

33.6 Claim Generator

Il software o hardware che genera il claim.

33.7 Signer

Il titolare della credenziale utilizzata per firmare.

33.8 Ingredient

Un file o componente utilizzato per produrre l’asset corrente.

33.9 Action

Un’azione dichiarata:

• creazione;
• apertura;
• modifica;
• ridimensionamento;
• ritaglio;
• conversione;
• uso di un modello algoritmico.

33.10 Content binding

Il collegamento tra manifesto e contenuto.

34. Hard binding e soft binding

34.1 Hard binding

Utilizza meccanismi crittografici, come hash su dati o parti del file, per rilevare alterazioni.

La specifica C2PA indica che i metadati esterni al manifesto, come EXIF e XMP, possono essere inclusi nell’hard binding. Precisa però che l’inclusione nel collegamento crittografico non attribuisce automaticamente al firmatario la responsabilità per l’accuratezza di quei valori.

34.2 Soft binding

Può utilizzare:

• impronte percettive;
• watermark;
• sistemi di recupero remoto.

Serve a ritrovare il manifesto quando non è più incorporato direttamente.

34.3 Differenza operativa

Hard binding:
rileva la corrispondenza crittografica tra manifesto e asset.

Soft binding:
aiuta a riconnettere un asset trasformato o privo del manifesto
alla relativa provenienza.

35. Firma, validità e fiducia

Un report C2PA deve distinguere:

1. il manifesto è presente;
2. il manifesto è strutturalmente leggibile;
3. gli hash sono coerenti;
4. la firma è valida;
5. il certificato è temporalmente valido;
6. la catena è verificabile;
7. il certificato è considerato affidabile rispetto alla trust list utilizzata;
8. le asserzioni sono presenti;
9. il contenuto delle asserzioni è pertinente;
10. l’identità dichiarata è effettivamente verificabile.

35.1 “Firma valida” non equivale a “contenuto vero”

Un soggetto può firmare una dichiarazione tecnicamente valida ma inesatta.

C2PA fornisce integrità, provenienza dichiarata e verificabilità della firma. Non sostituisce:

• analisi del contenuto;
• fact-checking;
• attribuzione personale;
• accertamento dei fatti;
• verifica del contesto.

La documentazione C2PA chiarisce che le Content Credentials non stabiliscono autonomamente se un’immagine o un video rappresenti la verità e che la provenienza può essere incompleta.

36. Analisi C2PA con ExifTool

ExifTool può leggere dati C2PA/JUMBF in diversi formati, tra cui JPEG, PNG, TIFF, DNG, MP4, MOV, HEIF, AVIF, WebP, WAV, PDF, SVG e GIF.

La documentazione propone:

exiftool -jumbf:all -G3 -b -j -u -struct FILE > exiftool_jumbf.json

ExifTool è utile per:

• individuare JUMBF;
• vedere strutture;
• estrarre tag;
• individuare manifesti;
• documentare il contenitore.

Non sostituisce la validazione completa con uno strumento C2PA.

37. Analisi C2PA con c2patool

37.1 Informazioni sintetiche

c2patool FILE --info > c2pa_info.txt

37.2 Report JSON

c2patool FILE > c2pa_manifest.json

37.3 Report dettagliato

c2patool FILE -d > c2pa_detailed.json

37.4 Albero dei manifesti

c2patool FILE --tree > c2pa_tree.txt

37.5 Estrazione dei certificati

c2patool FILE --certs > c2pa_certificates.pem

37.6 Manifesto esterno

c2patool FILE \
  --external-manifest FILE.c2pa \
  > c2pa_external_validation.json

37.7 Validazione con trust anchor locale

c2patool FILE trust \
  --trust_anchors "./C2PA-TRUST-LIST.pem" \
  > c2pa_trust_validation.json

Documentare:

- versione c2patool;
- trust list utilizzata;
- data di acquisizione della trust list;
- hash della trust list;
- disponibilità della rete;
- manifesto incorporato, remoto o sidecar;
- errori;
- warning;
- codici informativi;
- certificati;
- timestamp.

La documentazione ufficiale specifica che --info mostra lo stato generale, -d produce il report dettagliato, --tree rappresenta la struttura dei manifesti e --certs estrae la catena dei certificati.

38. Uso di servizi online di verifica

Un servizio web può essere utile per:

• prima verifica;
• dimostrazione;
• confronto dell’interfaccia;
• contenuti pubblici;
• campioni non riservati.

Non dovrebbe essere utilizzato senza valutazione per:

• documenti riservati;
• materiale aziendale;
• contenuti giudiziari;
• fotografie private;
• dati sanitari;
• immagini di minori;
• segreti commerciali;
• file soggetti a obblighi di riservatezza.

Per materiale sensibile è preferibile:

• strumento offline;
• ambiente isolato;
• trust list documentata;
• conservazione locale degli output;
• registrazione delle richieste remote eventualmente necessarie.

Il servizio ufficiale Content Credentials Verify consente di caricare o indicare un contenuto per esaminarne le credenziali, ma l’impiego professionale deve essere preceduto dalla valutazione di privacy, riservatezza e autorizzazione.

39. C2PA e intelligenza artificiale

Un manifesto può dichiarare una fonte digitale come:

digitalCapture
algorithmicMedia
trainedAlgorithmicMedia
compositeWithTrainedAlgorithmicMedia

39.1 Cosa può significare

• digitalCapture: acquisizione dichiarata da sensore;
• trainedAlgorithmicMedia: output dichiarato di un modello addestrato;
• compositeWithTrainedAlgorithmicMedia: composizione con componenti generati o modificati mediante AI.

39.2 Cosa non significa

La presenza di digitalCapture non dimostra automaticamente che la scena sia genuina.

La presenza di trainedAlgorithmicMedia può costituire una dichiarazione tecnicamente significativa, ma deve essere verificata rispetto:

• al manifesto;
• alla firma;
• al firmatario;
• alla trust list;
• all’integrità;
• alla specifica asserzione;
• alla storia degli ingredienti.

L’assenza di C2PA non dimostra che il contenuto non sia stato generato con AI.

La specifica C2PA 2.4 include meccanismi per rappresentare l’impiego di AI e una specifica AI disclosure, mentre IPTC 2025.1 ha aggiunto proprietà descrittive dedicate a sistema, versione e prompt.

L’analisi visiva e tecnica dei contenuti sintetici sarà approfondita nel Capitolo 28 — Immagini, fotografie manipolate e contenuti generati con AI.

40. L’assenza di C2PA

Un file senza manifesto C2PA può essere:

• genuino;
• precedente all’adozione;
• prodotto da dispositivo non compatibile;
• esportato da software non compatibile;
• transitato attraverso un sistema che ha rimosso il manifesto;
• ricodificato;
• acquisito mediante screenshot;
• alterato;
• generato con AI senza dichiarazione.

C2PA stessa chiarisce che l’adozione è facoltativa e che non si deve presumere l’inaffidabilità di un contenuto soltanto perché privo di Content Credentials. La documentazione riconosce inoltre che i metadati di provenienza possono essere rimossi.

41. La presenza di C2PA non basta

Un manifesto presente può risultare:

• valido;
• non valido;
• non attendibile rispetto alla trust list;
• danneggiato;
• riferito a un asset diverso;
• privo di alcune asserzioni;
• collegato a una storia incompleta;
• firmato da un soggetto non identificabile;
• prodotto con certificato di test;
• contenente dichiarazioni generiche.

La relazione deve evitare:

Meglio:

42. Ingredienti e catena di derivazione

Un’immagine finale può derivare da:

• fotografia;
• logo;
• sfondo;
• ritaglio;
• livello;
• modello generativo;
• grafica;
• documento;
• fotogramma.

C2PA può rappresentare tali componenti come ingredienti.

La specifica prevede relazioni e dati di validazione degli ingredienti. Quando un ingrediente contiene a sua volta un manifesto, il sistema può conservarne la provenienza e il risultato della verifica eseguita al momento dell’inserimento.

43. Metadati nei file JPEG

Un JPEG può contenere:

• APP0 JFIF;
• APP1 EXIF;
• APP1 XMP;
• XMP esteso;
• APP2 ICC;
• APP13 Photoshop/IPTC;
• APP11 JUMBF;
• commenti;
• miniature;
• dati successivi all’End of Image.

43.1 Controlli

exiftool -G0:1:2 -a -s -u -struct FILE.jpg
exiftool -v3 FILE.jpg
exiftool -htmlDump FILE.jpg > jpeg_structure.html

43.2 Anomalie da valutare

• più segmenti EXIF;
• più pacchetti XMP;
• tag duplicati;
• dimensioni incoerenti;
• miniatura differente;
• dati dopo EOI;
• profilo colore anomalo;
• software incompatibile con il workflow dichiarato.

Nessuna di queste condizioni deve essere trasformata automaticamente in conclusione di falsificazione.

44. HEIC, HEIF e AVIF

Questi formati sono contenitori complessi, spesso basati su ISO Base Media File Format.

Possono includere:

• immagini principali;
• miniature;
• sequenze;
• depth map;
• HDR gain map;
• Live Photo;
• EXIF;
• XMP;
• JUMBF;
• relazioni tra elementi;
• dati di orientamento;
• codec e profili.

44.1 Problema frequente

Un iPhone può produrre HEIC, mentre una condivisione può generare JPEG.

Il JPEG derivato può perdere:

• MakerNotes;
• coordinate;
• identificatori;
• profondità;
• informazioni HDR;
• C2PA;
• dati Live Photo.

L’acquisizione forense di iPhone e iPad deve quindi privilegiare, quando possibile, il file nel contesto del dispositivo o del backup.

45. PNG

Un PNG può contenere:

• chunk testuali;
• XMP;
• EXIF;
• profilo colore;
• informazioni temporali;
• JUMBF;
• dati applicativi.

Molti screenshot sono PNG e non contengono EXIF fotografico.

Un PNG senza EXIF non è anomalo.

La data del file system o un campo testuale non dimostrano la data della schermata rappresentata.

46. WebP

WebP può contenere:

• EXIF;
• XMP;
• ICC;
• animazione;
• alpha;
• JUMBF/C2PA in implementazioni compatibili.

Può derivare da:

• pagina web;
• social;
• conversione automatica;
• sistema di ottimizzazione;
• applicazione.

Un file WebP non deve essere considerato automaticamente l’originale fotografico.

47. File RAW

Esempi:

DNG
CR2
CR3
NEF
ARW
RAF
ORF
RW2

Possono contenere:

• dati sensore;
• anteprime;
• miniature;
• MakerNotes;
• profili;
• parametri di sviluppo;
• XMP incorporato o sidecar;
• informazioni proprietarie.

47.1 Perché sono importanti

Il RAW può essere più vicino alla fase di acquisizione rispetto a un JPEG esportato.

47.2 Perché non è automaticamente incontestabile

• può essere copiato;
• può contenere metadati modificati;
• può essere DNG convertito;
• può essere danneggiato;
• può provenire da workflow software;
• può essere incompleto;
• può avere sidecar separati.

47.3 Regola

Non modificare il RAW. Le operazioni di sviluppo devono essere eseguite su copie e documentate.

48. Video MOV e MP4

Un video può contenere:

• timestamp del contenitore;
• timestamp delle tracce;
• data di creazione;
• data di modifica;
• software;
• marca e modello;
• coordinate;
• telemetria;
• orientamento;
• timecode;
• metadati temporizzati;
• miniature;
• JUMBF/C2PA.

48.1 ExifTool

exiftool -G0:1:2 -a -s -u -ee -struct VIDEO.mp4 > video_exiftool.txt

48.2 MediaInfo

mediainfo --Output=JSON VIDEO.mp4 > video_mediainfo.json

48.3 FFprobe

ffprobe -v error \
  -show_format \
  -show_streams \
  -print_format json \
  VIDEO.mp4 > video_ffprobe.json

48.4 Criticità temporali

• valori UTC interpretati come locali;
• valori locali memorizzati in campi teoricamente UTC;
• epoche QuickTime;
• ricodifica;
• esportazione;
• tracce con timestamp diversi;
• metadati GPS temporizzati;
• data del file system successiva.

L’autenticità del contenuto video sarà approfondita nel Capitolo 26 — Autenticità video: frame, codec, tagli e montaggi.

49. Audio

Un audio può contenere:

• ID3;
• BWF/BEXT;
• INFO RIFF;
• iXML;
• XMP;
• data;
• software;
• dispositivo;
• time reference;
• codifica;
• JUMBF/C2PA.

L’assenza di metadati è frequente.

Il capitolo dedicato all’autenticità audio tratterà spettro, codec, discontinuità, montaggi e ricodifiche.

50. PDF e documenti

I PDF possono contenere:

• dizionario Info;
• XMP;
• identificatori;
• software produttore;
• date;
• firme;
• aggiornamenti incrementali;
• allegati;
• metadati incorporati;
• C2PA.

Le modifiche ai metadati PDF possono lasciare versioni precedenti nella struttura incrementale.

L’analisi specifica è trattata nel Capitolo 13 — PDF, firme digitali e marche temporali.

Per un PDF non basta confrontare i campi visualizzati da Acrobat: occorre valutare struttura, revisioni, firme, allegati e provenienza da email o PEC.

51. Documenti Office

DOCX, XLSX e PPTX sono normalmente contenitori ZIP con file XML e proprietà.

Possono contenere:

• autore;
• ultimo autore;
• data di creazione;
• data di modifica;
• applicazione;
• versione;
• numero revisioni;
• template;
• relazioni;
• commenti;
• contenuti incorporati;
• proprietà personalizzate.

Le date interne del documento, le date dei record ZIP e le date del file system possono non coincidere.

Non attribuire il documento all’autore indicato senza ulteriori riscontri.

52. Nome del file

Esempi:

IMG_4821.JPG
Screenshot_2026-05-14-18-42-16.png
Contratto_firmato_definitivo.pdf
Foto_Roma_10maggio.jpg

Il nome può derivare da:

• dispositivo;
• utente;
• software;
• download;
• browser;
• esportazione;
• piattaforma;
• rinomina;
• archivio.

Può essere utile, ma ha valore descrittivo.

53. Dimensione e caratteristiche tecniche

Confrontare:

• larghezza;
• altezza;
• orientamento;
• profondità colore;
• profilo ICC;
• fattore di compressione;
• sottocampionamento;
• codec;
• bitrate;
• durata;
• frame rate;
• numero di tracce;
• audio;
• miniatura;
• spazio colore.

Una condivisione può produrre:

• ridimensionamento;
• nuova compressione;
• rimozione EXIF;
• cambio profilo;
• ricodifica;
• modifica del nome.

Questo può aiutare a distinguere un originale da una copia derivata, senza implicare necessariamente alterazione fraudolenta.

54. File ricevuti tramite WhatsApp

Un’immagine inviata come fotografia può essere:

• ridimensionata;
• ricodificata;
• privata di parte dei metadati;
• rinominata;
• inserita nel database dell’app.

Un file inviato come documento può conservare più caratteristiche originarie.

Non si deve generalizzare: il comportamento può dipendere da:

• sistema operativo;
• versione dell’app;
• modalità di invio;
• formato;
• impostazioni;
• percorso di salvataggio.

Per ricostruire la provenienza è preferibile acquisire:

• dispositivo;
• database;
• allegato;
• record del messaggio;
• file locale;
• backup;
• eventuale originale.

La procedura completa è descritta nel Capitolo 8 — Perizia WhatsApp: messaggi, vocali e allegati.

55. Telegram, Signal e altre app

Anche in questo caso occorre distinguere:

• file inviato come media;
• file inviato come documento;
• anteprima;
• cache;
• download;
• inoltro;
• contenuto effimero;
• file cloud;
• copia locale.

Il file isolato non contiene necessariamente la storia del messaggio.

La relazione deve evitare:

Meglio:

Vedere il Capitolo 9 — Telegram, Signal e app di messaggistica forensics.

56. Email e PEC

Un allegato può essere correlato a:

• MIME part;
• nome;
• Content-Type;
• Content-Disposition;
• Content-ID;
• hash;
• messaggio EML;
• casella;
• header;
• ricevuta;
• busta PEC;
• postacert.eml;
• daticert.xml.

La prova più solida non è il file estratto da solo, ma il file nel contesto del messaggio originale.

Confrontare:

hash allegato estratto
hash file consegnato
nome MIME
dimensione
Content-Type
date del messaggio
date incorporate
firma o PEC

Approfondimenti:

• Analisi forense di email e header
• PEC, ricevute, allegati e prova digitale

57. Cloud e sistemi di sincronizzazione

Un file cloud può avere:

• data di creazione del contenuto;
• data di caricamento;
• data di modifica cloud;
• data di sincronizzazione;
• versione;
• autore account;
• proprietario;
• log di condivisione;
• cestino;
• ID interno;
• audit event.

Queste date devono essere mantenute distinte.

Esempio:

DateTimeOriginal: 10 maggio
Cloud upload: 12 maggio
Cloud modification: 14 maggio
Download locale: 16 maggio

La sequenza può essere coerente.

L’analisi è trattata nel Capitolo 23 — Cloud forensics: Google, Microsoft, Dropbox e backup.

58. Social network e pagine web

Una fotografia scaricata da una pagina può essere:

• ridimensionata;
• convertita;
• ricompressa;
• priva dei metadati originari;
• servita da CDN;
• diversa dall’upload originale;
• accompagnata da parametri URL;
• sostituita successivamente.

Per la provenienza online occorre acquisire:

• URL;
• data e ora;
• contenuto HTML;
• header HTTP;
• file;
• hash;
• screenshot di supporto;
• certificato;
• DNS;
• eventuale archivio;
• profilo;
• ID del post;
• contenuto incorporato.

Vedere il Capitolo 16 — Acquisizione di pagine web, social e contenuti online.

59. Confrontare due versioni

59.1 Hash

sha256sum FILE_A FILE_B

Hash diversi significano che almeno un byte differisce.

Non indicano quale differenza sia presente.

59.2 Metadati

exiftool -G0:1:2 -a -s -u -struct FILE_A > A_metadata.txt
exiftool -G0:1:2 -a -s -u -struct FILE_B > B_metadata.txt
diff -u A_metadata.txt B_metadata.txt > metadata_diff.txt

59.3 Pixel

Per immagini:

• dimensioni;
• pixel hash;
• confronto visivo;
• differenza;
• istogramma;
• allineamento;
• crop;
• compressione.

59.4 Struttura

Confrontare:

• segmenti;
• pacchetti XMP;
• quantization table;
• codec;
• profilo;
• struttura contenitore;
• anteprime;
• C2PA;
• trailer.

59.5 Formula

60. Costruire una matrice di provenienza

La matrice obbliga il perito a separare dati e interpretazioni.

61. Timeline dei metadati

La timeline deve includere:

- data EXIF;
- offset;
- data GPS;
- data XMP;
- data del file system;
- data di importazione;
- data di modifica;
- data di invio;
- data email o PEC;
- data cloud;
- data C2PA;
- data firma;
- data di acquisizione forense.

Esempio:

10/05/2026 18:42:16  DateTimeOriginal, offset assente
10/05/2026 16:42:17Z GPSDateTime
10/05/2026 18:43:02  database fotografico
10/05/2026 18:47:10  messaggio WhatsApp
10/05/2026 18:47:12  file ricevuto
13/07/2026 10:15:30  acquisizione forense

Se l’ora GPS è UTC e l’ora EXIF è locale, la differenza può essere coerente con l’ora legale di Roma. La conclusione deve comunque esplicitare il criterio di conversione.

La ricostruzione completa sarà trattata nel Capitolo 29 — Timeline forense e ricostruzione cronologica degli eventi.

62. Indizi di modifica dei metadati

Possibili indicatori:

• MetadataDate successiva;
• nome di editor;
• cronologia XMP;
• valori duplicati in conflitto;
• tag mancanti rispetto alla serie;
• MakerNotes danneggiati;
• identificatori non coerenti;
• miniatura differente;
• struttura riscritta;
• ordine dei segmenti anomalo;
• offset assente o incompatibile;
• date impossibili;
• software successivo alla data dichiarata;
• C2PA non valido;
• hard binding non corrispondente.

62.1 Nessun indicatore è assoluto

Un software fotografico può aggiungere XMP senza cambiare i pixel.

Un sistema di gestione documentale può riscrivere le proprietà.

Un antivirus o un indicizzatore può accedere al file senza modificarlo.

Una piattaforma può rimuovere EXIF.

Un software può correggere l’orientamento.

63. L’assenza di metadati

Può dipendere da:

• formato privo di quei campi;
• impostazioni privacy;
• software;
• condivisione;
• conversione;
• social;
• screenshot;
• scanner;
• rimozione intenzionale;
• processo automatico;
• errore;
• acquisizione incompleta.

64. Metadati modificabili e limiti probatori

Molti campi EXIF, XMP e IPTC possono essere scritti o cancellati con software comune.

Questo non rende i metadati inutili.

Significa che devono essere valutati attraverso:

• coerenza;
• struttura;
• provenienza;
• dispositivo;
• hash;
• cronologia;
• log;
• versione;
• C2PA;
• fonti esterne.

64.1 Analogia corretta

Un metadato è simile a un’annotazione presente su un documento:

• può essere autentica;
• può essere prodotta automaticamente;
• può essere errata;
• può essere modificata;
• può essere confermata da altri elementi.

64.2 Formula generale

65. Attribuzione a una persona

Non scrivere:

Scrivere:

L’attribuzione può richiedere:

[ ] dispositivo;
[ ] account;
[ ] credenziali;
[ ] log;
[ ] disponibilità materiale;
[ ] testimonianza;
[ ] sequenza fotografica;
[ ] messaggi;
[ ] cloud;
[ ] elementi contestuali;
[ ] identità C2PA verificabile;
[ ] ulteriori accertamenti.

66. Caso pratico 1 — Fotografia di un immobile a Roma

Scenario

Un avvocato di Roma consegna una fotografia che dovrebbe documentare infiltrazioni in un appartamento nel quartiere Prati.

Il file è:

foto_infiltrazione.jpg

Risultati

- JPEG 1600×1200;
- nessun EXIF fotografico;
- data file system successiva di tre mesi;
- nome generico;
- file ricevuto tramite messaggistica;
- disponibile anche un HEIC sul telefono del cliente;
- HEIC 4032×3024;
- EXIF con modello del telefono;
- DateTimeOriginal;
- coordinate compatibili con l’immobile;
- MakerNotes coerenti;
- contenuto visivamente corrispondente;
- JPEG compatibile con ridimensionamento e ricodifica.

Conclusione prudente

67. Caso pratico 2 — Fotografia ricevuta su WhatsApp

Scenario

Un cliente di Roma riceve un’immagine e chiede se sia stata scattata il giorno indicato dal mittente.

Materiale

Solo JPEG salvato da WhatsApp.

Risultati

- nessun DateTimeOriginal;
- nessun GPS;
- dimensioni ridotte;
- data file system coincidente col salvataggio;
- messaggio originale ancora presente;
- database dell’app disponibile;
- timestamp del messaggio acquisito;
- nessun dispositivo sorgente.

Conclusione

68. Caso pratico 3 — Documento con autore contestato

Scenario

Un’azienda romana produce un documento DOCX attribuito a un ex dipendente.

Metadati

Creator: nome del dipendente
LastModifiedBy: nome diverso
Created: data A
Modified: data B
Template: percorso aziendale
Revision: 17

Ulteriori elementi

• file rinvenuto su cartella condivisa;
• audit log incompleto;
• account condiviso;
• computer utilizzato da più persone.

Conclusione

69. Caso pratico 4 — Immagine con C2PA e AI

Scenario

Uno studio legale di Roma riceve un’immagine pubblicitaria sospettata di essere stata generata con AI.

Risultati

- manifesto C2PA presente;
- hard binding valido;
- firma valida;
- catena considerata affidabile rispetto alla trust list documentata;
- digitalSourceType: trainedAlgorithmicMedia;
- software generatore indicato;
- nessun ingrediente fotografico dichiarato.

Conclusione

70. Caso pratico 5 — Video con orari incoerenti

Scenario

Un cliente di Roma consegna un video MOV che dovrebbe essere stato registrato alle ore 21:30.

Risultati

FileModifyDate: 23:32 +02:00
QuickTime:CreateDate: 21:30:15
QuickTime:ModifyDate: 21:31:02
GPS timestamp: 19:30:16Z
messaggio di invio: 21:35 +02:00

Interpretazione

La differenza di due ore tra GPS UTC e ora locale può essere compatibile con l’ora legale.

La data di modifica del file system può riferirsi a una copia successiva.

Conclusione

71. Caso pratico 6 — Metadati apparentemente alterati

Scenario

Una fotografia presenta:

DateTimeOriginal: 2018
Software: editor pubblicato nel 2025
MetadataDate: 2026
pixel compatibili con fotografia del 2018

Ipotesi

1. fotografia del 2018 modificata nel 2026;
2. metadati corretti nel 2026;
3. esportazione recente;
4. data originaria errata;
5. campo software aggiunto senza modifica sostanziale;
6. manipolazione intenzionale.

Conclusione

72. Procedura operativa completa

Fase 1 — Autorizzazione

[ ] incarico;
[ ] oggetto;
[ ] quesito;
[ ] legittimazione;
[ ] limiti;
[ ] dati personali;
[ ] riservatezza.

Fase 2 — Acquisizione

[ ] fonte;
[ ] file originale;
[ ] sidecar;
[ ] dispositivo;
[ ] canale;
[ ] copia controllata;
[ ] hash;
[ ] verbale.

Fase 3 — Identificazione

[ ] estensione;
[ ] firma binaria;
[ ] MIME;
[ ] formato;
[ ] dimensione;
[ ] struttura;
[ ] eventuale cifratura.

Fase 4 — Estrazione iniziale

[ ] ExifTool TXT;
[ ] ExifTool JSON;
[ ] gruppi;
[ ] duplicati;
[ ] tag sconosciuti;
[ ] dati incorporati;
[ ] output numerico.

Fase 5 — Famiglie di metadati

[ ] file system;
[ ] EXIF;
[ ] GPS;
[ ] MakerNotes;
[ ] XMP;
[ ] IPTC;
[ ] QuickTime;
[ ] PDF;
[ ] Office;
[ ] ID3;
[ ] C2PA/JUMBF.

Fase 6 — Date

[ ] valore;
[ ] fonte;
[ ] gruppo;
[ ] offset;
[ ] precisione;
[ ] UTC;
[ ] ora locale;
[ ] clock drift;
[ ] coerenza.

Fase 7 — Dispositivo

[ ] marca;
[ ] modello;
[ ] seriali;
[ ] firmware;
[ ] lente;
[ ] MakerNotes;
[ ] confronto col dispositivo.

Fase 8 — GPS

[ ] coordinate;
[ ] formato;
[ ] data GPS;
[ ] altitudine;
[ ] accuratezza;
[ ] mappa offline o documentata;
[ ] correlazione esterna;
[ ] privacy.

Fase 9 — XMP e workflow

[ ] CreatorTool;
[ ] CreateDate;
[ ] ModifyDate;
[ ] MetadataDate;
[ ] DocumentID;
[ ] InstanceID;
[ ] OriginalDocumentID;
[ ] History;
[ ] DerivedFrom;
[ ] Ingredients.

Fase 10 — C2PA

[ ] presenza;
[ ] manifesto attivo;
[ ] hard binding;
[ ] firma;
[ ] certificato;
[ ] trust list;
[ ] timestamp;
[ ] asserzioni;
[ ] azioni;
[ ] ingredienti;
[ ] digitalSourceType;
[ ] errori;
[ ] warning.

Fase 11 — Confronto

[ ] hash;
[ ] dimensioni;
[ ] contenuto;
[ ] metadati;
[ ] struttura;
[ ] miniatura;
[ ] profilo;
[ ] codec;
[ ] C2PA.

Fase 12 — Correlazione

[ ] dispositivo;
[ ] chat;
[ ] email;
[ ] PEC;
[ ] cloud;
[ ] log;
[ ] backup;
[ ] pagina web;
[ ] altri file;
[ ] timeline.

Fase 13 — Relazione

[ ] materiale;
[ ] metodo;
[ ] strumenti;
[ ] risultati;
[ ] tabelle;
[ ] anomalie;
[ ] ipotesi;
[ ] limiti;
[ ] conclusioni;
[ ] allegati;
[ ] hash output.

73. Errori da evitare

Errore 1 — Fidarsi della finestra Proprietà

Mostra soltanto una selezione.

Errore 2 — Non usare i gruppi

Tag uguali possono provenire da aree differenti.

Errore 3 — Ignorare i duplicati

ExifTool può sopprimerli se non si usa -a.

Errore 4 — Considerare la data EXIF come certificata

Dipende dall’orologio e può essere modificata.

Errore 5 — Confondere ora locale e UTC

Particolarmente critico per video e GPS.

Errore 6 — Attribuire il file dal campo autore

Il campo può essere preconfigurato o copiato.

Errore 7 — Concludere che il file è falso perché non ha EXIF

Molti processi rimuovono i metadati.

Errore 8 — Concludere che il file è originale perché ha EXIF

EXIF può sopravvivere a modifiche o essere riscritto.

Errore 9 — Usare l’originale per prove di scrittura

Ogni modifica deve avvenire su copie separate.

Errore 10 — Caricare file riservati su siti online

Può violare riservatezza e minimizzazione.

Errore 11 — Non acquisire il sidecar XMP

Si perde parte del workflow.

Errore 12 — Ignorare anteprime e miniature

Possono contenere informazioni utili.

Errore 13 — Confondere C2PA con verità fattuale

C2PA documenta provenienza e integrità dichiarate.

Errore 14 — Concludere che l’assenza di C2PA esclude l’AI

L’adozione non è universale.

Errore 15 — Non documentare trust list e versione

La valutazione di fiducia dipende dalla configurazione.

Errore 16 — Non acquisire il contesto

Il file isolato può essere insufficiente.

Errore 17 — Normalizzare le date senza conservare l’originale

Si perde la trasparenza della conversione.

Errore 18 — Confondere metadata modification con pixel modification

Un’applicazione può riscrivere soltanto i metadati.

Errore 19 — Omettere ipotesi alternative

Le conclusioni devono essere falsificabili e proporzionate.

Errore 20 — Scrivere “prova certa”

È preferibile indicare il grado di compatibilità e i limiti.

74. Checklist operativa finale

Ricezione

[ ] incarico;
[ ] fonte;
[ ] quesito;
[ ] file;
[ ] sidecar;
[ ] dispositivo;
[ ] canale;
[ ] verbale.

Conservazione

[ ] originale protetto;
[ ] copia lavoro;
[ ] SHA-256;
[ ] cartella caso;
[ ] accessi controllati.

Identificazione

[ ] estensione;
[ ] MIME;
[ ] magic bytes;
[ ] dimensione;
[ ] struttura.

Metadati

[ ] file system;
[ ] EXIF;
[ ] MakerNotes;
[ ] GPS;
[ ] XMP;
[ ] IPTC;
[ ] QuickTime;
[ ] documenti;
[ ] C2PA.

Date

[ ] tutte le date;
[ ] fusi;
[ ] offset;
[ ] precisione;
[ ] conversioni;
[ ] clock drift;
[ ] conflitti.

Provenienza

[ ] dispositivo;
[ ] software;
[ ] account;
[ ] chat;
[ ] email;
[ ] PEC;
[ ] cloud;
[ ] web;
[ ] versioni;
[ ] ingredienti.

Validazione

[ ] ExifTool validate;
[ ] output verboso;
[ ] secondo strumento;
[ ] c2patool;
[ ] certificati;
[ ] trust list;
[ ] errori.

Relazione

[ ] risultati;
[ ] interpretazioni separate;
[ ] formule prudenti;
[ ] limiti;
[ ] allegati;
[ ] hash degli output.

75. Output minimo

Alla conclusione dovrebbero esistere:

1. verbale di ricezione;
2. file originale;
3. hash SHA-256;
4. copia di lavoro;
5. identificazione del formato;
6. output ExifTool completo TXT;
7. output ExifTool JSON;
8. output numerico;
9. output temporale;
10. output GPS;
11. output di validazione;
12. output verboso, quando necessario;
13. miniature e anteprime estratte;
14. report MediaInfo o FFprobe per contenuti multimediali;
15. report c2patool;
16. certificati C2PA, se presenti;
17. copia e hash della trust list utilizzata;
18. confronto tra versioni;
19. matrice di provenienza;
20. timeline;
21. screenshot tecnici di supporto;
22. relazione;
23. hash degli allegati prodotti.

76. Struttura della relazione tecnica

76.1 Incarico

• committente;
• quesito;
• autorizzazione;
• limiti.

76.2 Materiale

• nome;
• formato;
• dimensione;
• hash;
• fonte;
• data ricezione.

76.3 Metodo

• conservazione;
• strumenti;
• versioni;
• parametri;
• ambiente.

76.4 Risultati

• formato reale;
• EXIF;
• XMP;
• IPTC;
• GPS;
• dispositivo;
• software;
• date;
• C2PA;
• confronto;
• contesto.

76.5 Valutazione

• elementi coerenti;
• conflitti;
• ipotesi;
• alternative;
• attendibilità;
• limiti.

76.6 Conclusioni

Devono rispondere al quesito senza oltrepassare i dati.

77. Modelli di frasi tecniche

77.1 Data senza fuso

77.2 Data coerente

77.3 GPS

77.4 Dispositivo

77.5 Software

77.6 Metadati assenti

77.7 File derivato

77.8 C2PA valido

77.9 C2PA assente

77.10 Attribuzione personale

77.11 Conclusione limitata

78. Immagini e figure suggerite

79. Riferimenti tecnici esterni

1. CIPA — Exif Version 3.1 — revisione pubblicata il 30 gennaio 2026.
2. CIPA — Exif metadata for XMP — revisione pubblicata il 1° giugno 2026.
3. Adobe — XMP Specifications — modello dati, serializzazione, proprietà e incorporamento nei file.
4. ExifTool — XMP Tags — proprietà e strutture XMP Media Management.
5. IPTC Photo Metadata Standard 2025.1 — inclusi i campi per contenuti AI.
6. ExifTool — documentazione ufficiale — formati, opzioni, gruppi, duplicati e output.
7. ExifTool — QuickTime Tags — timestamp, metadati temporizzati e criticità UTC.
8. ExifTool — JUMBF/C2PA Tags — lettura dei manifesti in diversi formati.
9. C2PA Technical Specification 2.4 — manifesti, asserzioni, binding, validazione e trust.
10. C2PA Explainer 2.4 — finalità, limiti, completezza e rimozione della provenienza.
11. C2PA Security Considerations 2.4 — modello di sicurezza, firme, binding e validazione.
12. C2PA AI/ML Guidance 2.4 — provenienza di modelli, dataset e output algoritmici.
13. CAI Open Source SDK — c2patool — installazione, lettura, report e validazione.
14. Content Credentials Verify — strumento di ispezione dei manifesti.

80. Collegamenti interni consigliati

Capitoli precedenti

• Triage iniziale della prova digitale a Roma
• Catena di custodia, hash e verbale tecnico
• Copia forense di hard disk, SSD, pendrive e NAS
• Analisi forense di computer Windows
• Analisi forense di macOS e Linux
• Acquisizione forense di smartphone Android
• Acquisizione forense di iPhone e iPad iOS
• Perizia WhatsApp: messaggi, vocali e allegati
• Telegram, Signal e app di messaggistica forensics
• Recupero dati cancellati per fini probatori
• Analisi forense di email e header
• PEC, ricevute, allegati e prova digitale
• PDF, firme digitali e marche temporali

Capitolo successivo

• Verifica forense di screenshot e schermate

Capitoli correlati successivi

• Acquisizione di pagine web, social e contenuti online
• Cloud forensics: Google, Microsoft, Dropbox e backup
• Autenticità audio: tagli, montaggi e ricodifiche
• Autenticità video: frame, codec, tagli e montaggi
• Analisi video deepfake e face swapping
• Immagini, fotografie manipolate e contenuti generati con AI
• Timeline forense e ricostruzione cronologica degli eventi
• Relazione tecnica, CTP informatico e contestazione delle prove digitali

Pagine servizio

• Perizia informatica forense a Roma
• Analisi email, PEC e documenti digitali
• Verifica screenshot, pagine web e social
• Analisi smartphone e computer
• Consulente tecnico di parte informatico a Roma
• Contatti

Anchor text consigliati

analisi forense dei metadati a Roma
verifica EXIF di una fotografia
analisi della provenienza di un file
controllo delle coordinate GPS
verifica dei metadati XMP
analisi Content Credentials C2PA
ricostruzione della data di creazione
confronto tra originale e copia
perizia su fotografie digitali
verifica di file generati con AI

81. Box commerciale finale

Devi verificare data, luogo o provenienza di un file a Roma?

Se possiedi una fotografia, un video, un documento o un allegato digitale e devi comprendere:

[ ] quando può essere stato creato;
[ ] quale dispositivo può averlo prodotto;
[ ] se contiene coordinate GPS;
[ ] se è passato attraverso un software;
[ ] se esistono versioni precedenti;
[ ] se deriva da un altro file;
[ ] se i metadati sono coerenti;
[ ] se è presente un manifesto C2PA;
[ ] se dichiara un’origine algoritmica;
[ ] se il file ricevuto coincide con quello prodotto;
[ ] quali limiti tecnici devono essere considerati;

è opportuno evitare di aprire, modificare, rinominare o convertire ripetutamente il file prima della valutazione.

Conserva, quando possibile:

• il file nella forma ricevuta;
• il messaggio, l’email o la PEC;
• l’archivio originale;
• il dispositivo;
• il link cloud;
• il file sidecar;
• le versioni alternative.

Lo Studio Quaranta Digital Forensics a Roma può eseguire:

• acquisizione tecnica;
• calcolo hash;
• analisi EXIF;
• analisi XMP e IPTC;
• verifica GPS;
• confronto tra versioni;
• ricostruzione temporale;
• analisi della provenienza;
• verifica C2PA;
• relazione tecnica;
• supporto al consulente legale;
• attività di CTP informatico.

82. Conclusione del capitolo

I metadati sono una delle fonti più utili e, allo stesso tempo, più facilmente fraintese dell’informatica forense.

EXIF può descrivere fotocamera, data, GPS e parametri di scatto.

XMP può documentare identificatori, workflow, software, versioni e cronologie.

IPTC può contenere attribuzioni editoriali, descrizioni, diritti e informazioni sull’impiego di sistemi AI.

QuickTime e altri contenitori possono conservare timestamp, tracce, telemetria e dati applicativi.

C2PA introduce un livello ulteriore: manifesti, firme, hash, asserzioni, ingredienti e provenienza crittograficamente verificabile.

Nessuna di queste famiglie deve essere interpretata isolatamente.

Una conclusione tecnica corretta deve sempre distinguere:

- dato presente;
- significato tecnico;
- possibile origine;
- coerenza;
- possibilità di modifica;
- correlazioni;
- ipotesi alternative;
- limiti.

Nel prossimo capitolo il manuale affronterà un reperto molto comune, ma spesso prodotto in modo tecnicamente debole:

Capitolo 15 — Verifica forense di screenshot e schermate

Il capitolo spiegherà come distinguere una semplice immagine dello schermo da un’acquisizione tecnicamente documentata, come analizzare ritagli, barre di stato, risoluzione, interfaccia, font, notifiche, metadati, contesto applicativo e file sorgente, e perché uno screenshot isolato non dimostra necessariamente origine, completezza o autenticità della conversazione rappresentata.

Continua con il Capitolo 15 — Verifica forense di screenshot e schermate →