Verifica forense di screenshot e schermate

Introduzione

Uno screenshot è un’immagine di ciò che un sistema visualizzava in un determinato momento. Può rappresentare una conversazione, una pagina web, un’email, un pagamento, una notifica, un registro chiamate, un profilo social o una schermata di sistema. È un reperto molto comune nelle consulenze informatiche e nelle controversie trattate da avvocati, aziende e privati a Roma.

La semplicità con cui una schermata può essere creata, ritagliata, annotata, ricomposta o inserita in un documento rende però necessario distinguere tra contenuto visibile e provenienza tecnicamente verificata. Lo screenshot può documentare l’aspetto di un’interfaccia, ma normalmente non conserva l’intero database dell’applicazione, i messaggi precedenti e successivi, gli header di rete, i log del server, l’identità effettiva dell’account o il processo con cui l’immagine è stata prodotta.

Una schermata apparentemente completa può inoltre essere una cattura nativa, una fotografia del display, un’immagine ricostruita, una composizione grafica, un ritaglio, una pagina lunga assemblata automaticamente, un fotogramma estratto da una registrazione o una copia ricodificata da una chat. Questi oggetti possono apparire simili, ma hanno caratteristiche tecniche e limiti probatori differenti.

Nel contesto di una perizia informatica forense a Roma, la domanda corretta non è soltanto “lo screenshot sembra vero?”, ma:

La verifica deve quindi combinare catena di custodia e hash, analisi del formato, metadati, dimensioni, struttura dei pixel, interfaccia grafica, cronologia del dispositivo, dati dell’applicazione, comunicazioni originali, log, cloud e timeline forense.

Le indicazioni operative di questo capitolo seguono un criterio prudente: una compatibilità grafica o tecnica è un elemento da correlare, non una certificazione automatica di autenticità. Le linee guida SWGDE sull’autenticazione delle immagini raccomandano infatti di esaminare materiale ricevuto, formato, metadati, contenuto, possibili elaborazioni e basi della conclusione, mentre le best practice per i contenuti online considerano le catture dello schermo utili per il contesto ma non sostitutive della conservazione del contenuto sottostante.

Sintesi operativa

La verifica forense di uno screenshot dovrebbe seguire questa sequenza:

1. acquisire il file nella forma più vicina possibile a quella originaria;
2. documentare chi lo ha consegnato, quando, come e da quale dispositivo;
3. calcolare l’hash prima di ogni esame;
4. distinguere screenshot nativo, fotografia del display, ritaglio, schermata lunga e screen recording;
5. identificare il formato reale e analizzarne la struttura;
6. estrarre metadati, dimensioni, profilo colore e informazioni temporali;
7. verificare crop, ridimensionamento, ricompressione, annotazioni e composizioni;
8. esaminare barre di stato, area sicura, font, icone, layout, risoluzione e versione dell’interfaccia;
9. confrontare il reperto con eventuali copie, sequenze e file di riferimento;
10. correlare il contenuto con dispositivo, database dell’app, chat, email, PEC, cloud e log;
11. preservare output, versioni degli strumenti, parametri e immagini derivate;
12. distinguere sempre osservazioni, interpretazioni, ipotesi alternative e limiti;
13. evitare conclusioni di autenticità o falsità basate su un solo indicatore;
14. formulare una risposta proporzionata al materiale effettivamente disponibile.

1. Avvertenza preliminare

Le procedure descritte devono essere applicate esclusivamente a materiale proprio, consegnato dal titolare, acquisito con consenso o esaminato nell’ambito di un incarico difensivo, aziendale, giudiziario o professionale legittimo.

• non accedere ad account, dispositivi o caselle di terzi senza autorizzazione;
• non tentare di superare password, cifrature o controlli di accesso;
• non modificare il file originale per “migliorarne” la leggibilità;
• non ricreare una conversazione fingendo che sia una cattura originaria;
• non pubblicare schermate contenenti dati di minori, credenziali, dati sanitari o informazioni riservate;
• non usare servizi online di analisi senza valutare riservatezza, localizzazione dei dati e condizioni d’uso;
• eseguire filtri, crop, ingrandimenti e annotazioni soltanto su copie, conservando sempre il reperto non elaborato.

Il capitolo riguarda accertamenti tecnici e non sostituisce la valutazione dell’avvocato sull’ammissibilità, sulla rilevanza o sulle modalità di produzione del documento nel procedimento.

2. Che cos’è uno screenshot

Uno screenshot, o schermata, è un’immagine generata da un sistema operativo, da un’applicazione, da un browser, da un ambiente virtuale o da uno strumento di cattura per rappresentare una porzione del framebuffer o del contenuto visualizzato.

La definizione deve essere mantenuta distinta da quella di fotografia del monitor. Nello screenshot nativo i pixel sono normalmente prodotti dal sistema di cattura; nella fotografia del monitor intervengono fotocamera, prospettiva, riflessi, luminosità, refresh del display, messa a fuoco e compressione fotografica.

È inoltre necessario distinguere lo screenshot dal contenuto sorgente. Una schermata di WhatsApp non coincide con il database dei messaggi; una schermata di una pagina web non coincide con HTML, CSS, script, risorse, header HTTP e risposte di rete; una schermata di un bonifico non coincide con il record dell’istituto di pagamento.

3. Tipologie di reperto visivo

4. Che cosa può documentare uno screenshot

Se acquisito e contestualizzato correttamente, uno screenshot può contribuire a documentare:

• l’aspetto di una schermata in un determinato momento;
• testi, icone, nomi visualizzati, URL, notifiche o indicatori;
• la presenza di un messaggio o di un contenuto nel dispositivo esaminato;
• l’ordine visibile di alcuni elementi;
• la configurazione grafica di un’app o di un sistema;
• un errore, un avviso o uno stato applicativo;
• l’esistenza di un contenuto online al momento della cattura, se la sessione è documentata;
• la corrispondenza visiva con dati estratti da una fonte più completa;
• le operazioni mostrate in una registrazione di schermo continua.

Il suo valore aumenta quando sono disponibili il file originario, il dispositivo sorgente, una acquisizione Android o iPhone/iPad, i dati dell’applicazione, la comunicazione originale e una catena di custodia verificabile.

5. Che cosa non dimostra da solo

Uno screenshot isolato normalmente non consente da solo di dimostrare:

• chi abbia materialmente creato l’immagine;
• chi controllasse il dispositivo o l’account;
• che il nome visualizzato corrisponda alla persona reale;
• che data e ora mostrate coincidano con un riferimento temporale affidabile;
• che non esistano messaggi precedenti, successivi o cancellati;
• che la schermata non sia stata ritagliata, annotata o ricomposta;
• che la pagina o l’app mostrata sia collegata a un server autentico;
• che un pagamento sia stato eseguito, contabilizzato o non revocato;
• che un contenuto online sia rimasto invariato dopo la cattura;
• che il file non sia stato ricodificato o inserito in un altro documento;
• che l’interfaccia rappresentata provenga realmente dal sistema dichiarato.

6. Le principali domande del cliente

Un avvocato, un’azienda o un privato di Roma può chiedere:

• “Questa chat è autentica?”
• “La schermata è stata modificata o ritagliata?”
• “È davvero uno screenshot di iPhone o Android?”
• “Il post social esisteva in quella data?”
• “Il bonifico mostrato è stato realmente disposto?”
• “Il nome del contatto è stato cambiato?”
• “La data visibile è attendibile?”
• “La pagina lunga è un’unica cattura?”
• “Il file proviene dal telefono del cliente?”
• “Le notifiche e la barra di stato sono coerenti?”
• “È un’immagine creata con un editor o con intelligenza artificiale?”
• “Lo screenshot depositato è identico a quello ricevuto?”

La risposta professionale deve iniziare dalla disponibilità del reperto e della fonte, non dall’impressione visiva.

7. Gradi di robustezza tecnica

8. Che cosa deve consegnare il cliente

8.1 File e dispositivi

[ ] file screenshot nella forma ricevuta o generata;
[ ] eventuale screen recording;
[ ] dispositivo su cui la schermata è stata creata o ricevuta;
[ ] dispositivo da cui proviene il contenuto mostrato;
[ ] archivio ZIP o cartella originale;
[ ] backup locale o cloud;
[ ] file inserito in PDF, Word, email o presentazione;
[ ] versioni precedenti e successive;
[ ] eventuale esportazione della conversazione o del servizio.

8.2 Informazioni di contesto

• chi ha prodotto la schermata;
• quale combinazione di tasti o funzione è stata utilizzata;
• data e ora dichiarate;
• modello del dispositivo e versione del sistema;
• applicazione e versione, se note;
• eventuali ritagli, annotazioni, oscuramenti o inoltri;
• canale di trasmissione;
• presenza del contenuto originale ancora accessibile;
• quesito tecnico preciso.

8.3 Fonti correlate

[ ] chat originale;
[ ] email EML/MSG;
[ ] PEC e ricevute;
[ ] pagina web o URL;
[ ] log dell’account;
[ ] estratto bancario o ricevuta ufficiale;
[ ] database applicativo;
[ ] log di sistema;
[ ] contenuto della controparte;
[ ] verbale o dichiarazione di chi ha effettuato la cattura.

9. Che cosa non fare prima della valutazione

• non ritagliare la schermata per “renderla più chiara”;
• non aggiungere frecce o evidenziazioni sul file originario;
• non convertirla ripetutamente tra PNG, JPEG, PDF e messaggistica;
• non rinominarla cancellando il nome iniziale;
• non usare funzioni di pulizia, miglioramento o upscaling sul reperto;
• non eliminare copie apparentemente duplicate;
• non aprire contenuti effimeri senza documentare l’operazione;
• non effettuare logout, aggiornamenti o reinstallazioni dell’app;
• non inoltrare il file attraverso canali che possano ricomprimerlo;
• non affidarsi a un semplice controllo visivo o a un rilevatore online.

10. Triage iniziale dello screenshot

Il triage generale segue il metodo descritto nel Capitolo 1. Per le schermate occorre aggiungere controlli specifici:

[ ] assegnare un codice al reperto;
[ ] registrare fonte, canale e dispositivo;
[ ] conservare il file senza aprirlo in editor;
[ ] calcolare SHA-256;
[ ] identificare il formato reale;
[ ] registrare dimensioni in pixel e orientamento;
[ ] estrarre metadati e chunk;
[ ] verificare presenza di alpha, profilo colore e testo incorporato;
[ ] classificare screenshot, fotografia, ritaglio o frame video;
[ ] cercare versioni e sequenze correlate;
[ ] verificare se il contenuto sorgente è ancora disponibile;
[ ] pianificare l’eventuale acquisizione del dispositivo.

11. Cartella di caso

CASO_RM_2026_015/
├── 00_incarico/
├── 01_verbali/
├── 02_originali/
├── 03_hash/
├── 04_copie_lavoro/
├── 05_metadati/
├── 06_struttura_file/
├── 07_ocr/
├── 08_confronti_pixel/
├── 09_dispositivo_sorgente/
├── 10_dati_applicativi/
├── 11_timeline/
├── 12_figure_relazione/
├── 13_report/
└── 14_relazione/

Le immagini elaborate devono avere nomi che descrivano l’operazione, ad esempio SC01_ingrandimento_400x.png o SC01_diff_riferimento.png, senza sovrascrivere il reperto.

12. Catena di custodia

Uno screenshot deve essere trattato come qualsiasi altra prova digitale. La catena di custodia dovrebbe documentare:

• identificativo del reperto;
• nome originario;
• dimensione;
• formato;
• hash;
• fonte;
• modalità di consegna;
• data e ora;
• operatore;
• supporto;
• copie prodotte;
• strumenti e versioni;
• trasformazioni effettuate sulle copie;
• accessi al dispositivo sorgente.

13. Calcolo dell’hash

13.1 Windows PowerShell

Get-FileHash -Algorithm SHA256 -LiteralPath ".\Screenshot_2026-05-18.png"

13.2 Linux

sha256sum -- Screenshot_2026-05-18.png

13.3 macOS

shasum -a 256 -- Screenshot_2026-05-18.png

L’hash consente di verificare che due file siano identici bit per bit. Due schermate visivamente uguali possono avere hash differenti per metadati, profili colore o codifica; due file con lo stesso hash sono invece identici, ma ciò non dimostra come sia stato creato il contenuto.

14. Identificare il formato reale

L’estensione può essere modificata o attribuita dal canale di trasmissione. Un file denominato screenshot.jpg può essere un PNG rinominato, un WebP o un’immagine incorporata estratta da un documento.

14.1 File e magic bytes

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

14.2 PowerShell

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

14.3 ExifTool

exiftool -FileType -FileTypeExtension -MIMEType -ImageWidth -ImageHeight screenshot.jpg

15. Strumenti principali

15.1 ExifTool

Legge formato, dimensioni, date, profili, chunk testuali, XMP, EXIF, C2PA/JUMBF e numerose proprietà. Deve essere usato in lettura sul reperto.

15.2 ImageMagick

Consente di descrivere l’immagine, estrarre proprietà, creare ingrandimenti controllati e confrontare matematicamente immagini allineate. Ogni output derivato deve essere separato dall’originale.

15.3 pngcheck

Verifica firma, integrità, CRC e struttura dei chunk PNG e può mostrare informazioni testuali incorporate. Un esito strutturalmente valido non equivale ad autenticità del contenuto.

15.4 FFprobe e MediaInfo

Sono utili per screen recording, fotogrammi e video dello schermo, per descrivere contenitore, codec, frame rate, durata, tracce e metadati.

15.5 Tesseract OCR

Estrae testo e coordinate da una schermata. L’OCR è uno strumento di ricerca e trascrizione: errori di caratteri, emoji, nomi, date e punteggiatura devono essere verificati manualmente.

15.6 Suite forensi

Cellebrite, Magnet AXIOM, Oxygen Forensic Detective, X-Ways, Autopsy e altri strumenti possono correlare il file con cartelle, database, backup, messaggi e artefatti del dispositivo. Le capacità dipendono da versione, sistema, cifratura e modalità di acquisizione.

16. Registrare le versioni degli strumenti

exiftool -ver
magick -version
pngcheck 2>&1 | head -n 1
ffprobe -version
mediainfo --Version
tesseract --version

Conservare l’output in un allegato. Parser, algoritmi, modelli OCR e supporto ai formati cambiano nel tempo; la riproducibilità richiede versione, sistema operativo, parametri e data dell’esame.

17. Prima estrazione tecnica

17.1 Output completo ExifTool

exiftool -G0:1:2 -a -s -u -struct screenshot.png > screenshot_exiftool.txt

17.2 Output JSON

exiftool -G0:1:2 -a -s -u -struct -json screenshot.png > screenshot_exiftool.json

17.3 Caratteristiche immagine

magick identify -verbose screenshot.png > screenshot_identify.txt

17.4 Verifica strutturale PNG

pngcheck -v screenshot.png > screenshot_pngcheck_verbose.txt
pngcheck -t screenshot.png > screenshot_png_text.txt

Gli output devono essere calcolati su una copia verificata o in sola lettura e poi sottoposti ad hash. Eventuali warning vanno interpretati: possono dipendere da software non standard, metadati proprietari o file danneggiati, non necessariamente da manipolazione intenzionale.

18. Analisi strutturale del file

L’analisi strutturale risponde a domande diverse dall’analisi visiva:

• il file è formalmente valido?
• quali segmenti o chunk contiene?
• sono presenti profili colore, alpha, commenti o pacchetti XMP?
• esistono dati dopo la fine logica dell’immagine?
• il file contiene più immagini o frame?
• sono presenti firme C2PA/JUMBF?
• il formato è compatibile con il processo dichiarato?

Una struttura anomala è un indicatore da spiegare. Una struttura regolare non esclude una modifica, perché un editor può riscrivere un file perfettamente conforme.

19. Screenshot in formato PNG

PNG è frequente per le schermate perché conserva grafica, testo e bordi senza la perdita tipica della compressione JPEG. La specifica PNG prevede chunk critici e accessori; tra questi, tEXt, iTXt e zTXt possono contenere informazioni testuali.

Controllare almeno:

Signature
IHDR
PLTE, se presente
IDAT
IEND
sRGB / iCCP / cHRM / gAMA
pHYs
tEXt / iTXt / zTXt
eXIf
XMP
caBX / JUMBF, se presente
chunk sconosciuti o duplicati

L’assenza di EXIF in un PNG non è anomala. Le date possono essere presenti nel file system, in XMP, in chunk testuali oppure soltanto nel database del dispositivo.

20. Screenshot in formato JPEG

Un JPEG può derivare da una cattura, da una fotografia del display, da una condivisione o da una conversione. La compressione introduce artefatti soprattutto attorno a testo, icone e bordi ad alto contrasto.

• verificare segmenti APP, EXIF, XMP, ICC e commenti;
• controllare dimensioni e sottocampionamento cromatico;
• cercare tracce di ridimensionamento o ricodifica;
• distinguere artefatti di compressione da presunti segni di montaggio;
• confrontare eventuale versione PNG o originaria.

Una doppia compressione può essere compatibile con modifica, inoltro o salvataggio successivo; non identifica da sola l’operazione compiuta né la sua finalità.

21. HEIC, WebP, PDF e altri contenitori

Una schermata può essere convertita in HEIC, WebP, AVIF, TIFF o PDF dal sistema, da un’app, da un browser o dal canale di invio. Un PDF può contenere l’immagine come oggetto incorporato, ridimensionato o ricomprimibile; un documento Office può conservarne una copia interna distinta da quella visualizzata.

Per questi casi occorre:

• identificare il contenitore;
• estrarre l’immagine incorporata senza ricodifica, quando possibile;
• calcolare hash del contenitore e degli oggetti estratti;
• documentare trasformazioni e strumenti;
• analizzare anche proprietà del documento e revisioni.

Per i PDF vedere il Capitolo 13 — PDF, firme digitali e marche temporali.

22. Dimensioni, rapporto e orientamento

Le dimensioni in pixel sono uno dei primi elementi da confrontare con il dispositivo e con la modalità di cattura dichiarata.

magick identify -format "%f %wx%h %[orientation] %[colorspace] %[channels]\n" screenshot.png

Valutare:

• larghezza e altezza;
• orientamento verticale o orizzontale;
• rapporto d’aspetto;
• presenza di aree trasparenti;
• dimensioni compatibili con cattura intera o parziale;
• ridimensionamento non intero;
• bordi aggiunti;
• spaziature anomale.

La compatibilità con la risoluzione di un modello non identifica univocamente il dispositivo: immagini della stessa misura possono essere generate, ridimensionate o ricreate su altri sistemi.

23. Densità pixel e device pixel ratio

Nel web e nelle interfacce moderne esiste una differenza tra pixel CSS, punti logici e pixel fisici. Il device pixel ratio può far sì che un viewport di una certa misura logica produca un file con dimensioni multiple.

Una cattura di browser automatizzata può riferirsi al viewport visuale, a un singolo elemento o a una pagina completa. Lo standard WebDriver definisce comandi distinti per la cattura del contesto di navigazione e dell’area di un elemento. Questo conferma che “screenshot della pagina” non è una categoria unica: metodo e area devono essere documentati.

Nella relazione registrare, quando disponibili:

dimensioni fisiche del file;
dimensioni logiche del viewport;
device pixel ratio;
zoom del browser;
scala del sistema;
orientamento;
modalità full-page o area selezionata;
strumento e versione.

24. Viewport e schermata intera

Una cattura del viewport comprende ciò che il browser o l’app mostrano in quel momento. Una cattura dello schermo intero può includere barra di sistema, dock, taskbar, finestre laterali e notifiche. Una cattura di finestra può escludere il resto del desktop.

25. Barre di stato, notch e aree sicure

Barra di stato, notch, Dynamic Island, indicatori di rete, batteria, ora, barra di navigazione e gesture area possono fornire elementi di compatibilità con una famiglia di dispositivi o con una versione dell’interfaccia.

Questi elementi non devono essere trattati come “impronte” definitive perché:

• possono essere ritagliati;
• possono essere sovrapposti o ricreati;
• cambiano con tema, lingua, accessibilità e versione;
• app e video possono entrare in modalità immersiva;
• le registrazioni remote o gli emulatori possono riprodurli;
• alcuni sistemi nascondono o ridisegnano gli indicatori.

26. Ritagli e contesto mancante

Il ritaglio è una delle trasformazioni più comuni. Può avere finalità lecite, come oscurare dati non pertinenti, ma può anche eliminare URL, ora, nome dell’app, messaggi precedenti, pulsanti, indicatori di modifica o elementi che cambiano l’interpretazione.

Indicatori possibili:

• dimensioni non compatibili con la cattura intera;
• taglio netto di elementi dell’interfaccia;
• assenza delle barre normalmente visibili;
• margini asimmetrici;
• messaggi che iniziano o terminano a metà;
• versione più ampia disponibile in altra fonte;
• nome del file o metadati compatibili con un editor.

L’assenza di un bordo o di una barra non dimostra necessariamente un ritaglio: la modalità di cattura può essere stata selettiva fin dall’origine.

27. Schermate lunghe e catture con scorrimento

Le catture lunghe possono essere prodotte dal sistema operativo, dal browser, da un’app o da strumenti che assemblano più porzioni durante lo scorrimento. Non rappresentano necessariamente un singolo istante: contenuti dinamici, annunci, intestazioni fisse e messaggi possono cambiare tra una porzione e l’altra.

Controllare:

[ ] altezza eccezionalmente elevata;
[ ] ripetizione di header, barre o elementi sticky;
[ ] discontinuità verticali;
[ ] sovrapposizioni o salti;
[ ] elementi caricati in momenti diversi;
[ ] timestamp ripetuti o mancanti;
[ ] metadati del metodo full-page;
[ ] disponibilità del contenuto sorgente.

Su iPhone alcune funzioni consentono catture a pagina intera di contenuti scorrevoli, ad esempio pagine web, mentre browser e strumenti di automazione possono produrre file full-page mediante meccanismi differenti. Il metodo effettivo deve essere registrato.

28. Interfaccia, versione dell’app e lingua

Icone, menu, colori, spaziature e testi dipendono da:

• versione dell’app;
• sistema operativo;
• lingua;
• tema chiaro o scuro;
• dimensione del testo;
• accessibilità;
• regione;
• tipo di account;
• funzioni sperimentali;
• configurazioni aziendali;
• modello del dispositivo.

Un confronto deve quindi usare, quando possibile, lo stesso modello, la stessa versione del sistema, la stessa versione dell’app e impostazioni comparabili. Confrontare una schermata del 2022 con l’interfaccia corrente può produrre falsi sospetti.

Versioni archiviate, manuali, changelog, video dell’epoca e screenshot di riferimento possono aiutare, ma devono essere documentati e valutati per attendibilità.

29. Font, rendering e scaling

Il testo visualizzato dipende da font, hinting, antialiasing, subpixel rendering, scala del sistema, densità del display, zoom, motore grafico e ricompressione. Differenze minime nei bordi dei caratteri non dimostrano necessariamente un inserimento.

Per un confronto corretto occorre:

1. allineare le immagini senza deformarle;
2. verificare che risoluzione e scala siano comparabili;
3. considerare tema e accessibilità;
4. distinguere rendering originario da ricompressione;
5. esaminare più caratteri e non un singolo glifo;
6. conservare il riferimento utilizzato.

L’uso di un font apparentemente “sbagliato” è un indizio da approfondire, non una conclusione automatica.

30. Colore, compressione e ricampionamento

Profili colore, gamma, gestione HDR, trasparenza e conversioni tra spazi colore possono cambiare l’aspetto di una schermata. Una piattaforma di messaggistica può inoltre ricodificare, ridimensionare o rimuovere il profilo.

Registrare:

ColorSpace
ICCProfile
Gamma
BitDepth
Alpha
Compression
Quality stimata, se applicabile
SamplingFactor
ImageWidth / ImageHeight

La differenza cromatica tra due copie non implica necessariamente modifica del testo o del contenuto. Può dipendere dalla gestione del colore, dal visualizzatore o dalla conversione.

31. Metadati e timestamp

Uno screenshot può contenere date del file system, XMP, EXIF, chunk testuali o proprietà del contenitore. Deve essere applicato il metodo del Capitolo 14 — Metadati, EXIF, XMP, C2PA e provenienza dei file.

Distinguere almeno:

FileCreateDate
FileModifyDate
DateTimeOriginal, se presente
CreateDate
ModifyDate
MetadataDate
PNG textual chunks
XMP CreatorTool
C2PA actions e timestamp
record del database Photos/Gallery
record del file system
orario visibile nella schermata

L’orario visibile può essere modificato graficamente o dipendere dall’orologio del dispositivo. La data del file system può cambiare durante copia, download o estrazione. La convergenza tra fonti indipendenti è più significativa del singolo valore.

32. Nome del file e percorso

Nomi come Screenshot_20260518-143205.png, Screenshot 2026-05-18 at 14.32.05.png o IMG_1234.PNG possono essere generati automaticamente, ma possono anche essere rinominati.

Il percorso può contribuire a identificare il contesto: cartella Screenshots, allegato di messaggistica, download, cache, desktop o directory temporanea. Tuttavia una copia manuale può spostare il file e preservare soltanto una parte dei timestamp.

33. Screenshot su iPhone e iPad

La procedura Apple varia in base alla presenza di Face ID o del tasto Home; la documentazione ufficiale indica combinazioni di tasti dedicate e raggruppa le schermate nella categoria Screenshots dell’app Foto. Sono inoltre disponibili catture a pagina intera per alcuni contenuti scorrevoli.

Nell’analisi forense verificare, quando possibile:

• file nel dispositivo e nel backup;
• record della libreria Foto;
• album o media type Screenshots;
• nome e identificatori dell’asset;
• date di creazione, importazione e modifica;
• eventuali regolazioni o annotazioni;
• versione condivisa e versione locale;
• iCloud Photos e sincronizzazione;
• dimensioni compatibili con dispositivo, orientamento e modalità.

Una semplice immagine ricevuta via chat non permette di concludere che sia stata generata sull’iPhone indicato. L’acquisizione forense iOS/iPadOS può fornire il contesto necessario, nei limiti del tipo di acquisizione e della versione del sistema.

34. Screenshot su Android

Android prevede funzioni di cattura e registrazione dello schermo, ma procedure, cartelle, nomi e metadati possono variare tra produttori, versioni, launcher e app. La guida ufficiale Android indica comunemente la combinazione accensione più volume giù, rinviando al produttore quando il comportamento differisce.

Controllare:

• directory e record MediaStore;
• nome generato dal produttore;
• dimensioni e area di navigazione;
• cattura lunga o scroll capture;
• editor integrato e annotazioni;
• backup Google Photos o del produttore;
• record della galleria;
• ricezione tramite app;
• eventuali file temporanei e thumbnail.

La mobile forensics Android deve tenere conto di cifratura, profilo di lavoro, spazio privato, scheda SD, app sandbox e limiti della modalità di acquisizione.

35. Screenshot su Windows

Windows può produrre catture mediante Snipping Tool, Print Screen, combinazioni di tasti, Game Bar, software aziendali, browser, desktop remoto o strumenti di terzi. Le versioni recenti di Snipping Tool supportano anche registrazioni video dello schermo.

Elementi da verificare:

• cartella Screenshots o destinazione scelta;
• clipboard e incollaggio in altre applicazioni;
• salvataggio automatico o manuale;
• cattura intera, finestra o area;
• numero di monitor;
• scaling DPI;
• taskbar, tray, notifiche e orologio;
• cronologia file, OneDrive o backup;
• eventuali modifiche in Paint o editor.

Nella analisi forense Windows il file può essere correlato con Jump Lists, Recent Files, timeline, log applicativi, cloud sync e artefatti del programma utilizzato.

36. Screenshot su macOS

Apple documenta scorciatoie per cattura dell’intero schermo, di una porzione, di una finestra e per l’app Screenshot, che può anche registrare lo schermo. Destinazione, timer, puntatore e miniatura possono dipendere dalle opzioni selezionate.

Verificare:

• nome convenzionale e lingua del sistema;
• destinazione configurata;
• formato effettivo;
• dimensioni per monitor Retina e scaling;
• ombra della finestra;
• più monitor;
• iCloud Drive o Desktop sincronizzato;
• Finder metadata, extended attributes e log;
• eventuali annotazioni con Anteprima.

L’analisi macOS può correlare il file con APFS, Spotlight, FSEvents, backup e dati applicativi, nei limiti dell’acquisizione disponibile.

37. Screenshot di browser e pagine web

Una schermata web dovrebbe includere, quando possibile, URL, data e ora, scheda, titolo, porzione completa rilevante e indicatori del browser. Le best practice SWGDE per l’acquisizione di contenuti online considerano le catture statiche e video utili per documentare l’interfaccia, ma raccomandano la conservazione del contenuto acquisito e della documentazione della sessione.

Uno screenshot non conserva necessariamente:

• HTML, CSS e JavaScript;
• risposte HTTP e header;
• certificato TLS;
• indirizzo IP e DNS;
• risorse caricate;
• contenuti nascosti o fuori viewport;
• stato autenticato;
• reindirizzamenti;
• dati dinamici;
• tempo del server.

Per contenuti online il metodo completo è trattato nel Capitolo 16 — Acquisizione di pagine web, social e contenuti online.

38. Screenshot di WhatsApp

Una schermata WhatsApp può mostrare nome del contatto, fotografia, orari, spunte, messaggi, allegati e indicazioni di inoltro o modifica. Tuttavia il nome può essere associato localmente a un numero e non identifica automaticamente l’interlocutore.

Verificare, quando disponibile:

[ ] numero o JID del contatto;
[ ] database dei messaggi;
[ ] allegati e hash;
[ ] timestamp interni;
[ ] stato inviato/ricevuto/letto;
[ ] messaggi citati o modificati;
[ ] backup;
[ ] file screenshot nel dispositivo;
[ ] versione dell’app e interfaccia;
[ ] contenuto sul dispositivo della controparte.

La perizia WhatsApp non dovrebbe basarsi esclusivamente su una successione di schermate quando il dispositivo o un’esportazione tecnica sono ancora disponibili.

39. Screenshot di Telegram, Signal e altre app

Telegram, Signal e altre app possono presentare chat cloud, chat segrete, messaggi effimeri, username, numeri nascosti, modifica dei messaggi, reazioni e differenti modalità di sincronizzazione.

L’interfaccia può variare tra Android, iOS, desktop e web. Una schermata mobile non documenta necessariamente ciò che era presente sul server o sugli altri dispositivi.

Occorre correlare, nei limiti autorizzati, con dati locali, sessioni, esportazioni, allegati, notifiche, backup e informazioni dell’account. Vedere il Capitolo 9 — Telegram, Signal e app di messaggistica forensics.

40. Screenshot di email e PEC

Uno screenshot di un’email può omettere mittente tecnico, Reply-To, Message-ID, Received, autenticazioni, MIME, allegati, firme e percorso di consegna. Il nome visualizzato può essere liberamente configurato e non coincide necessariamente con l’indirizzo effettivo.

Per email ordinaria acquisire il messaggio EML/MSG e gli header completi. Per PEC conservare busta, ricevute, postacert.eml, daticert.xml e allegati, come descritto nel Capitolo 12.

41. Screenshot di social network

Post, storie, messaggi diretti, commenti e profili possono essere modificati, eliminati, resi privati o presentati diversamente in base ad account, regione, app e algoritmo.

Una schermata dovrebbe essere correlata con:

• URL o identificativo del contenuto;
• nome utente e ID account;
• data e ora della sessione;
• pagina o profilo completo;
• video di navigazione;
• download delle risorse;
• HTML e dati di rete, quando acquisibili;
• notifica o email correlata;
• eventuale richiesta alla piattaforma tramite canali legittimi.

In casi di diffamazione o condotte lesive, evitare interazioni che possano avvertire l’autore o alterare il contenuto prima della strategia concordata con il legale. Il tema sarà approfondito nel Capitolo 17.

42. Screenshot bancari, bonifici e pagamenti

Una schermata di conferma può essere simulata, modificata, riferita a un’operazione programmata, annullata, rifiutata o non contabilizzata. Non sostituisce estratto conto, CRO/TRN verificabile, ricevuta ufficiale, log dell’istituto o conferma del beneficiario.

Controllare:

• stato dell’operazione;
• data valuta e data disposizione;
• importo e valuta;
• IBAN parzialmente visibile;
• identificativo transazione;
• app o sito dichiarato;
• versione e layout;
• record nel conto;
• email o notifica ufficiale;
• contabilizzazione sul beneficiario.

Le frodi di pagamento saranno trattate nel Capitolo 19.

43. Registri chiamate e notifiche

Uno screenshot del registro chiamate o del centro notifiche può mostrare un evento, ma non documenta automaticamente l’origine tecnica, la durata effettiva, la rete, il numero reale o la persistenza dell’evento nei database.

Correlare con:

• database chiamate;
• log del sistema;
• notifiche memorizzate;
• dati dell’operatore se legittimamente disponibili;
• registrazioni dell’app;
• timestamp e fuso;
• backup;
• schermate precedenti e successive.

Le notifiche possono essere simulate da applicazioni, cambiare testo o essere raggruppate. L’interfaccia è un dato descrittivo, non una garanzia della fonte.

44. Contenuti effimeri e visualizzazione unica

Storie, messaggi a scomparsa e media “visualizza una volta” presentano rischi particolari: l’apertura può modificare lo stato o rendere il contenuto non più accessibile. Alcune app limitano o segnalano la cattura; tali comportamenti variano nel tempo e tra sistemi.

Prima di aprire:

1. documentare dispositivo e stato;
2. concordare la strategia con il legale o il responsabile;
3. predisporre una registrazione esterna o di schermo lecita, se appropriata;
4. sincronizzare e documentare l’orario;
5. acquisire notifiche e dati applicativi disponibili;
6. evitare tentativi ripetuti;
7. verbalizzare ogni interazione e il relativo effetto.

Non sono descritte tecniche per eludere protezioni o controlli dell’applicazione.

45. Screen recording come fonte complementare

Una registrazione continua può mostrare apertura dell’app, navigazione, scorrimento, dettagli del profilo, passaggio tra schermate e data di sistema. SWGDE indica la registrazione video dello schermo come utile complemento alle catture statiche per i contenuti online.

Il video deve comunque essere analizzato per:

• tagli;
• pause;
• cambi di velocità;
• ricodifiche;
• frame mancanti;
• overlay;
• audio;
• orientamento;
• timestamp;
• inizio e fine della sessione.

45.1 Analisi con FFprobe

ffprobe -v error   -show_format   -show_streams   -print_format json   registrazione-schermo.mp4 > ffprobe.json

45.2 Estrazione controllata di fotogrammi

ffmpeg -i registrazione-schermo.mp4 -vf fps=1 frames/frame_%06d.png

L’estrazione genera materiale derivato: conservare video originario, comando, versione e hash degli output.

46. Fotografia del display

Una fotografia del display può essere utile quando la cattura nativa è impossibile o rischia di modificare lo stato. Deve essere riconosciuta come fotografia, non come screenshot.

Può presentare:

• prospettiva;
• riflessi;
• moiré;
• linee di refresh;
• aberrazione;
• profondità di campo;
• distorsione ottica;
• EXIF della fotocamera;
• contesto fisico attorno al dispositivo.

In alcuni casi il contesto fisico aumenta la documentazione perché mostra dispositivo, ora esterna, sigilli o operatore. In altri riduce la leggibilità. È opportuno effettuare più riprese documentate senza cancellare o sostituire le precedenti.

47. Screenshot incorporato in documenti

Quando una schermata è inserita in DOCX, PPTX, PDF o email, il contenitore può:

• ridimensionarla;
• ricomprimerla;
• convertirla;
• ritagliarla senza eliminare i pixel nascosti;
• aggiungere trasparenza o bordi;
• conservare una copia interna a risoluzione maggiore;
• rimuovere metadati;
• duplicarla in anteprime o risorse.

Occorre acquisire sia il contenitore sia l’immagine estratta. Per Office, l’analisi del pacchetto ZIP può recuperare gli oggetti media; per PDF si devono esaminare oggetti, filtri e revisioni incrementali. L’immagine estratta non deve essere ricodificata se l’obiettivo è confrontarla bit per bit.

48. OCR e trascrizione

L’OCR facilita ricerca, indicizzazione e confronto di schermate lunghe, ma non sostituisce la lettura visiva né il file originale.

48.1 Comando base Tesseract

tesseract screenshot.png ocr_output -l ita+eng --psm 6

48.2 Output con coordinate e confidenza

tesseract screenshot.png ocr_output -l ita+eng --psm 6 tsv

Verificare manualmente:

• zero e lettera O;
• uno, I e l;
• accenti;
• emoji;
• nomi utente;
• orari;
• link;
• punteggiatura;
• testo chiaro su sfondo scuro;
• caratteri parzialmente tagliati.

49. Analisi visiva di possibili manipolazioni

L’esame visivo dovrebbe procedere dal generale al particolare:

1. classificare il tipo di cattura;
2. valutare completezza e crop;
3. controllare geometria dell’interfaccia;
4. confrontare font, icone e allineamenti;
5. esaminare bordi, trasparenze e ombre;
6. cercare ripetizioni, discontinuità e aree uniformi;
7. verificare compressione e ridimensionamento;
8. confrontare con riferimenti corretti;
9. correlare con dati sorgente.

Ingrandire non crea informazione. Un’area poco definita resta limitata; l’interpolazione può rendere più leggibile l’aspetto ma non ricostruisce i pixel originari.

50. Analisi a livello di pixel

L’analisi può considerare valori RGB/RGBA, bordi, gradienti, alpha, pattern di compressione, frequenze e continuità. Per schermate native, aree testuali e grafiche tendono ad avere caratteristiche diverse dalle fotografie naturali.

Le osservazioni devono tenere conto di:

• ricampionamento globale;
• compressione della piattaforma;
• subpixel e antialiasing;
• tema scuro;
• trasparenze;
• blur intenzionali;
• screenshot di video o immagini già compresse;
• riduzione della risoluzione.

Una differenza locale può derivare da un elemento dinamico, da un’emoji, da una bitmap incorporata o da rendering differente, non necessariamente da un montaggio.

51. Confronto con ImageMagick

Il confronto matematico è utile quando esistono due versioni allineate della stessa schermata.

51.1 Numero di pixel differenti

magick compare -metric AE riferimento.png reperto.png differenze.png

51.2 Metrica RMSE

magick compare -metric RMSE riferimento.png reperto.png differenze-rmse.png

51.3 Avvertenze

• le immagini devono avere dimensioni e allineamento comparabili;
• piccoli spostamenti producono grandi differenze;
• profili colore e alpha possono alterare il risultato;
• la metrica non è una percentuale di autenticità;
• il file differenze è un output derivato;
• parametri e versione devono essere conservati.

52. Error level analysis e limiti della compressione

L’Error Level Analysis è spesso presentata online come rilevatore automatico di ritocchi. In realtà l’interpretazione dipende da qualità JPEG, salvataggi precedenti, contenuto, rumore, bordi, ricampionamento e impostazioni del software.

Per le schermate, caratterizzate da testo e grafica netta, l’ELA può produrre aree molto evidenti anche senza manipolazione. Non dovrebbe essere usata come prova autonoma di autenticità o falsità.

Una procedura seria deve confrontare ipotesi alternative, usare file di riferimento, analizzare la struttura e cercare conferme nel dispositivo o nei dati applicativi.

53. Clone detection e copy-move

Gli algoritmi di copy-move cercano aree simili ripetute nella stessa immagine. Possono essere utili per individuare duplicazioni, ma le interfacce contengono naturalmente elementi ripetuti: bolle di chat, avatar, icone, sfondi, separatori e caratteri.

Un risultato deve essere filtrato per:

• pattern dell’interfaccia;
• tile di sfondo;
• emoji identiche;
• componenti riutilizzati;
• compressione;
• scala;
• rotazione;
• sovrapposizione;
• dimensione minima dell’area.

Il rilevamento è un indicatore per l’esame manuale, non una conclusione.

54. Mockup, contenuti generati e intelligenza artificiale

Oggi è possibile ricreare interfacce con editor grafici, HTML/CSS, emulatori, strumenti di prototipazione e modelli generativi. Un’immagine sintetica può imitare molto bene una chat o un’app bancaria.

Possibili indizi visivi includono incongruenze di font, icone, spaziature, prospettiva, simboli, testi e dettagli di sistema. Tuttavia i modelli migliorano rapidamente e gli errori apparenti possono dipendere da versioni reali dell’interfaccia.

L’assenza di artefatti visivi non dimostra che la schermata sia genuina. La verifica più robusta resta la correlazione con file, dispositivo, app, server, account e log. Il tema sarà approfondito nel Capitolo 28.

55. C2PA e Content Credentials

Un file può contenere un manifesto C2PA con informazioni firmate su creazione, azioni, software e provenienza. Una cattura dello schermo o una ricodifica può però rimuovere il manifesto; C2PA prevede anche meccanismi di soft binding per tentare di recuperare credenziali associate dopo trasformazioni.

Verificare, quando presente:

[ ] manifesto attivo;
[ ] hard binding;
[ ] firma;
[ ] certificato e trust list;
[ ] azioni dichiarate;
[ ] digitalSourceType;
[ ] ingredienti;
[ ] eventuali redazioni;
[ ] warning ed errori;
[ ] versione dello strumento.

L’assenza di Content Credentials non dimostra che lo screenshot sia falso o generato. La presenza di un manifesto valido documenta gli aspetti firmati, non la verità fattuale di tutto ciò che l’interfaccia rappresenta. Vedere il Capitolo 14.

56. Correlazione con il dispositivo sorgente

La disponibilità del dispositivo può trasformare una verifica puramente visiva in un accertamento contestuale. L’obiettivo non è soltanto trovare un file uguale, ma ricostruire dove si trovava, come era indicizzato e quali eventi lo collegano alla cattura.

Elementi utili:

• percorso e identificatore del file;
• record della libreria foto o MediaStore;
• thumbnail e cache;
• date del file system;
• database dell’app di cattura;
• backup;
• cloud sync;
• recenti e cronologia;
• log di accesso;
• eventuali copie modificate;
• screen recording correlati.

L’acquisizione deve rispettare il principio di minimizzazione e il perimetro dell’incarico. Il dispositivo può contenere dati di terzi non pertinenti.

57. Correlazione con database applicativi

Per chat, email, social e altre app, i dati strutturati possono mostrare identificatori, timestamp, mittente, destinatario, stato, allegati, modifica e cancellazione. La schermata dovrebbe essere confrontata con questi record.

Una matrice può includere:

La mancata presenza nel database può dipendere da cancellazione, acquisizione parziale, sincronizzazione, retention o versione dell’app. Non dimostra automaticamente che la schermata sia costruita.

58. Cloud, backup e copie sincronizzate

Una schermata può essere presente in iCloud Photos, Google Photos, OneDrive, Dropbox o backup del dispositivo. Queste fonti possono conservare date di upload, modifica, sincronizzazione, versioni e identificatori.

Distinguere:

data visibile nella schermata;
data di creazione del file;
data del record locale;
data di upload;
data di sincronizzazione;
data di modifica cloud;
data di download;
data di acquisizione forense.

L’analisi cloud deve usare accessi autorizzati, esportazioni ufficiali o procedure concordate. La semplice presenza nel cloud prova la memorizzazione, non necessariamente l’origine iniziale.

59. Timeline della schermata

La timeline dovrebbe mantenere separati valori visibili e valori tecnici.

18/05/2026 14:31:58  evento applicativo nel database
18/05/2026 14:32:05  ora visibile nella barra di stato
18/05/2026 14:32:08  creazione record screenshot nella libreria
18/05/2026 14:32:09  creazione file nel volume
18/05/2026 14:33:12  annotazione o modifica
18/05/2026 14:35:40  invio tramite messaggistica
18/05/2026 14:35:44  ricezione sul secondo dispositivo
13/07/2026 11:10:00  acquisizione forense

La vicinanza temporale può essere compatibile con la sequenza dichiarata. Occorre comunque valutare fuso orario, clock drift, copie, precisione dei timestamp e semantica di ogni campo.

60. Sequenze, omissioni e continuità

Una serie di schermate può documentare più contesto di una sola immagine, ma può contenere salti. Numerazione dei file, orari, posizione di scorrimento, messaggi sovrapposti e screen recording possono aiutare a ricostruire la continuità.

Controllare:

• ordine dei nomi;
• timestamp di creazione;
• sovrapposizione tra una schermata e la successiva;
• messaggi visibili in entrambe;
• salti di data;
• cambi di tema o orientamento;
• variazioni di batteria e ora;
• cambi di account o contatto;
• assenza di file intermedi.

L’assenza di una schermata intermedia non dimostra necessariamente occultamento: la cattura può essere stata selettiva. Deve però essere dichiarata come limite.

61. Riproduzione su dispositivo di riferimento

In alcuni casi è utile ricreare in laboratorio una schermata con lo stesso modello, sistema e versione dell’app per confrontare layout, font, icone e dimensioni.

La prova deve essere documentata:

modello e seriale del dispositivo di riferimento;
versione sistema operativo;
versione applicazione;
lingua e regione;
tema;
scala testo e accessibilità;
risoluzione e orientamento;
dati fittizi usati;
procedura di cattura;
hash dei file di riferimento.

La riproduzione dimostra compatibilità o incompatibilità con una configurazione testata, non esclude tutte le altre configurazioni possibili.

62. Annotazioni, oscuramenti e redazioni

Frecce, evidenziazioni, rettangoli e oscuramenti devono essere trattati come elaborazioni. La relazione dovrebbe mostrare il reperto originario, se disponibile, e una copia annotata chiaramente identificata.

Un oscuramento non è sicuro se consiste soltanto in:

• trasparenza parziale;
• sfocatura reversibile o insufficiente;
• livello sovrapposto in un documento editabile;
• crop non applicato ai dati sottostanti;
• rettangolo che lascia testo nei metadati o nell’OCR del PDF.

La redazione destinata alla diffusione deve essere verificata sul file finale. In ambito peritale, la copia integrale può essere conservata in allegato riservato e la versione pubblica limitata ai dati pertinenti.

63. Privacy e dati sensibili

Le schermate possono contenere numeri telefonici, email, fotografie, minori, dati sanitari, credenziali, codici OTP, indirizzi, coordinate, dati bancari e conversazioni di terzi.

Applicare:

• minimizzazione;
• controllo degli accessi;
• cifratura degli archivi;
• separazione degli allegati riservati;
• redazione delle copie divulgabili;
• tracciamento delle consegne;
• eliminazione secondo incarico e obblighi applicabili;
• divieto di caricamento su servizi non autorizzati.

Non inserire nella relazione dati non necessari al quesito. Il fatto che un’informazione sia visibile nello screenshot non ne rende automaticamente lecita la diffusione.

64. Procedura di acquisizione dal vivo

Quando il contenuto è ancora visibile sul dispositivo, una procedura prudente può prevedere:

1. identificare operatore, dispositivo, stato e autorizzazione;
2. fotografare il dispositivo e l’ambiente di lavoro;
3. documentare data, ora, fuso, rete e livello batteria;
4. valutare modalità aereo, isolamento o mantenimento della connettività in base al rischio;
5. avviare una registrazione esterna o di schermo quando appropriato;
6. mostrare l’app o il browser, l’account e il percorso di navigazione;
7. acquisire schermate intere e dettagli senza cancellare le prime;
8. registrare URL, identificativi, messaggi e contenuti correlati;
9. esportare o acquisire i dati sottostanti quando consentito;
10. calcolare hash e redigere verbale;
11. conservare copia di lavoro e originale separatamente.

65. Matrice di valutazione

66. Caso pratico 1 — Chat WhatsApp consegnata a un avvocato di Roma

Scenario

Un avvocato di Roma riceve cinque schermate di una conversazione. Il cliente sostiene che documentino una minaccia, ma i file sono stati inoltrati via email e non è disponibile subito il telefono sorgente.

Risultati

- cinque JPEG ricompressi;
- nomi generici attribuiti dal client email;
- assenza di metadati utili;
- dimensioni identiche;
- sovrapposizione parziale tra quattro schermate;
- salto temporale tra seconda e terza schermata;
- nome del contatto visibile, numero non visibile;
- nessun database o esportazione disponibile.

Conclusione prudente

67. Caso pratico 2 — Storia social diffamatoria

Scenario

Una professionista romana fotografa con un secondo telefono una storia social destinata a scomparire.

Riscontri

• fotografia del display con EXIF della fotocamera;
• profilo e contenuto leggibili;
• orario del telefono visibile;
• nessun URL diretto;
• notifica dell’app presente;
• messaggi di terzi che riferiscono di aver visto la stessa storia;
• profilo non più accessibile al momento dell’esame.

Valutazione

68. Caso pratico 3 — Schermata di bonifico contestata

Scenario

Un’azienda di Roma riceve via messaggistica una schermata che mostra un bonifico “eseguito” e consegna la merce. Il pagamento non compare sul conto.

Analisi

- PNG senza metadati utili;
- dimensioni compatibili con uno smartphone, non identificative;
- interfaccia simile a quella bancaria ma con testo non perfettamente allineato;
- identificativo operazione non verificabile;
- nessuna ricevuta PDF firmata o messaggio ufficiale;
- nessun accredito o movimento pendente;
- file ricevuto da account di messaggistica non attribuito tecnicamente.

Conclusione

69. Caso pratico 4 — Screenshot di email con mittente contestato

Scenario

Un cliente di Roma produce la schermata di un’email in cui compare il nome di un dirigente.

Risultati

• il client mostra soltanto il display name;
• indirizzo completo non visibile;
• header assenti;
• messaggio originario ancora nella casella;
• esportazione EML acquisita con autorizzazione;
• header indicano un indirizzo differente e Reply-To anomalo.

Conclusione

70. Caso pratico 5 — Barra Android apparentemente incoerente

Scenario

Una controparte sostiene che una schermata sia falsa perché l’icona della batteria non corrisponde al modello dichiarato.

Verifiche

• stesso produttore con tema personalizzato;
• versione del sistema differente dal riferimento iniziale;
• modalità risparmio energetico;
• scala display modificata;
• screenshot presente nel dispositivo e nel backup;
• record MediaStore coerente con la data;
• contenuto correlato al database dell’app.

Conclusione

71. Caso pratico 6 — Cattura full-page di un sito

Scenario

Uno studio legale romano riceve un PNG molto alto che dovrebbe rappresentare una pagina web completa.

Risultati

- altezza superiore a 18.000 pixel;
- intestazione fissa ripetuta in due punti;
- banner caricato solo nella parte inferiore;
- URL non incorporato nell’immagine;
- file prodotto da estensione browser;
- sessione non registrata;
- HTML e risorse non conservati;
- pagina successivamente modificata.

Conclusione

72. Procedura operativa completa

Fase 1 — Incarico e quesito

[ ] autorizzazione;
[ ] soggetti e dispositivi;
[ ] finalità;
[ ] quesito tecnico;
[ ] limiti;
[ ] dati sensibili;
[ ] urgenza e volatilità.

Fase 2 — Ricezione

[ ] file originario;
[ ] contenitore;
[ ] dispositivo;
[ ] canale;
[ ] versioni;
[ ] verbale;
[ ] hash.

Fase 3 — Classificazione

[ ] screenshot nativo;
[ ] area selezionata;
[ ] full-page;
[ ] fotografia display;
[ ] screen recording;
[ ] frame video;
[ ] immagine incorporata;
[ ] possibile ricostruzione.

Fase 4 — Analisi del file

[ ] formato reale;
[ ] struttura;
[ ] dimensioni;
[ ] profilo colore;
[ ] alpha;
[ ] metadati;
[ ] timestamp;
[ ] C2PA;
[ ] warning.

Fase 5 — Analisi visiva

[ ] completezza;
[ ] crop;
[ ] barre di sistema;
[ ] font;
[ ] icone;
[ ] geometria;
[ ] compressione;
[ ] ripetizioni;
[ ] annotazioni;
[ ] elementi dinamici.

Fase 6 — Confronti

[ ] copie;
[ ] sequenze;
[ ] riferimenti di interfaccia;
[ ] pixel diff;
[ ] OCR;
[ ] file incorporati;
[ ] dispositivo di riferimento.

Fase 7 — Correlazione

[ ] dispositivo sorgente;
[ ] database app;
[ ] chat;
[ ] email/PEC;
[ ] cloud;
[ ] log;
[ ] server;
[ ] controparte;
[ ] timeline.

Fase 8 — Reporting

[ ] osservazioni;
[ ] dati tecnici;
[ ] interpretazioni;
[ ] ipotesi alternative;
[ ] limiti;
[ ] conclusioni;
[ ] allegati;
[ ] hash degli output.

73. Errori da evitare

Errore 1 — Considerare lo screenshot equivalente al dato sorgente

Una schermata di chat non sostituisce il database o l’esportazione.

Errore 2 — Valutare soltanto l’aspetto

La grafica può essere imitata e le versioni reali possono differire.

Errore 3 — Ignorare il file originario

Una copia incollata o ricodificata perde struttura e metadati.

Errore 4 — Ritagliare prima dell’hash

Si altera il reperto e si perde il contesto.

Errore 5 — Attribuire il contatto dal nome

Il nome può essere configurato localmente.

Errore 6 — Usare l’ora visibile come data certa

Può dipendere dall’orologio o da una modifica grafica.

Errore 7 — Confondere compatibilità con identificazione

La risoluzione può essere condivisa da molti dispositivi.

Errore 8 — Usare ELA come verdetto

È sensibile a compressione e contenuto.

Errore 9 — Interpretare ogni differenza di font come montaggio

Rendering, scala e versione possono cambiare.

Errore 10 — Ignorare le schermate lunghe

Possono essere composizioni temporali.

Errore 11 — Non acquisire il dispositivo

Si rinuncia a database, cartelle, backup e timeline.

Errore 12 — Non documentare la versione dell’app

Il confronto grafico può essere anacronistico.

Errore 13 — Caricare materiale riservato su strumenti web

Si espongono dati personali e strategia difensiva.

Errore 14 — Sovrascrivere il file con annotazioni

Si perde il reperto non elaborato.

Errore 15 — Confondere screenshot e fotografia del display

I due processi hanno artefatti differenti.

Errore 16 — Affidarsi solo all’OCR

L’OCR può sbagliare caratteri e date.

Errore 17 — Dimenticare fuso e clock drift

Le fonti temporali possono essere non direttamente confrontabili.

Errore 18 — Concludere che assenza di metadati significhi falso

Molte catture non conservano metadati ricchi.

Errore 19 — Concludere che presenza di C2PA significhi verità

La firma copre dichiarazioni e integrità, non ogni fatto.

Errore 20 — Omettere ipotesi alternative

La relazione deve spiegare cosa è verificato e cosa resta indeterminato.

74. Checklist operativa finale

Ricezione

[ ] file originale;
[ ] fonte;
[ ] canale;
[ ] dispositivo;
[ ] contesto;
[ ] autorizzazione;
[ ] quesito.

Conservazione

[ ] SHA-256;
[ ] copia di lavoro;
[ ] originale protetto;
[ ] verbale;
[ ] accessi controllati;
[ ] backup del caso.

File

[ ] formato reale;
[ ] struttura valida;
[ ] dimensioni;
[ ] colore e alpha;
[ ] metadati;
[ ] timestamp;
[ ] C2PA;
[ ] warning.

Contenuto

[ ] crop;
[ ] barre;
[ ] interfaccia;
[ ] font;
[ ] icone;
[ ] allineamenti;
[ ] compressione;
[ ] annotazioni;
[ ] continuità.

Correlazioni

[ ] dispositivo;
[ ] database app;
[ ] backup;
[ ] cloud;
[ ] email/PEC;
[ ] log;
[ ] server;
[ ] riferimenti;
[ ] timeline.

Relazione

[ ] metodo;
[ ] strumenti e versioni;
[ ] risultati;
[ ] figure derivate identificate;
[ ] ipotesi alternative;
[ ] limiti;
[ ] conclusioni proporzionate;
[ ] hash allegati.

75. Output minimo

1. verbale di ricezione e incarico;
2. file originario e relativo hash SHA-256;
3. copia di lavoro verificata;
4. identificazione del formato;
5. output ExifTool testuale e JSON;
6. output strutturale PNG/JPEG o del contenitore;
7. report ImageMagick identify;
8. report FFprobe/MediaInfo per screen recording;
9. trascrizione OCR verificata, se usata;
10. immagini di confronto e comandi;
11. matrice tra contenuto visibile e dati sorgente;
12. timeline;
13. documentazione del dispositivo e dell’app;
14. versioni degli strumenti;
15. relazione tecnica;
16. hash degli allegati e degli output.

76. Struttura della relazione tecnica

76.1 Incarico e quesito

Indicare committente, titolo autorizzativo, finalità, perimetro e domanda tecnica.

76.2 Materiale esaminato

Elencare file, contenitori, dispositivi, copie, nomi, dimensioni, hash e modalità di ricezione.

76.3 Metodo

Descrivere conservazione, strumenti, versioni, parametri, confronti e fonti di riferimento.

76.4 Risultati

Separare formato, metadati, dimensioni, struttura, elementi grafici, confronti, dati del dispositivo e correlazioni applicative.

76.5 Valutazione

Esporre compatibilità, divergenze, possibili cause, ipotesi alternative e peso dei singoli indicatori.

76.6 Limiti

Dichiarare file mancanti, assenza del dispositivo, versioni non riproducibili, ricodifiche, incompletezza della sequenza e limiti degli strumenti.

76.7 Conclusioni

Rispondere al quesito con formulazioni proporzionate, senza sostituire la valutazione giuridica.

77. Modelli di frasi tecniche

77.1 File originario non disponibile

77.2 Compatibilità grafica

77.3 Ritaglio

77.4 Data visibile

77.5 Nome del contatto

77.6 Metadati assenti

77.7 Differenze tra pixel

77.8 Dispositivo sorgente

77.9 Chat incompleta

77.10 C2PA assente

77.11 Conclusione limitata

78. Immagini e figure suggerite

79. Riferimenti tecnici esterni

1. SWGDE — Best Practices for Image Authentication, versione 2.0 — formato, metadati, contenuto, elaborazioni, confronti e reporting.
2. SWGDE — Best Practices for Acquiring Online Content — catture statiche e video, contesto, URL, data, ora e conservazione.
3. SWGDE — Imaging documents — integrità, autenticazione, analisi e confronto di immagini.
4. NIST IR 8387 — Digital Evidence Preservation — principi di conservazione delle prove digitali.
5. ExifTool — documentazione ufficiale — lettura di metadati e proprietà in numerosi formati.
6. W3C — Portable Network Graphics, Third Edition — struttura PNG, chunk e informazioni testuali.
7. pngcheck — documentazione — verifica di integrità, CRC e chunk PNG.
8. ImageMagick Identify — descrizione tecnica dei file immagine.
9. ImageMagick Compare — confronto matematico e visualizzazione delle differenze.
10. Tesseract OCR — manuale ufficiale — riconoscimento del testo e uso da riga di comando.
11. FFprobe — documentazione ufficiale — analisi di contenitori e flussi multimediali.
12. W3C WebDriver — comandi di cattura del viewport e degli elementi.
13. Apple — Come acquisire uno screenshot su iPhone — procedure e gestione delle schermate.
14. Apple — Come acquisire uno screenshot su Mac — intero schermo, area, finestra e app Screenshot.
15. Microsoft — Snipping Tool — catture statiche e registrazione dello schermo.
16. Google Android Help — Screenshot e screen recording — procedure generali e varianti del produttore.
17. C2PA Technical Specification 2.4 — manifesti, azioni, provenienza e validazione.
18. C2PA Soft Binding API 2.4 — recupero della provenienza dopo screenshot e trasformazioni.

80. Collegamenti interni consigliati

Capitoli precedenti

• Triage iniziale della prova digitale a Roma
• Catena di custodia, hash e verbale tecnico
• 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
• Analisi forense di email e header
• PEC, ricevute, allegati e prova digitale
• PDF, firme digitali e marche temporali
• Metadati, EXIF, XMP, C2PA e provenienza dei file

Capitolo successivo

• Acquisizione di pagine web, social e contenuti online

Capitoli correlati successivi

• Diffamazione online, cyberbullismo, stalking digitale e revenge porn
• Accessi abusivi ad account email, social e cloud
• Truffe online, bonifici fraudolenti e financial cybercrime
• Cloud forensics: Google, Microsoft, Dropbox e backup
• Autenticità video: frame, codec, tagli e montaggi
• 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
• Verifica screenshot, pagine web e social
• Analisi smartphone e computer
• Analisi email, PEC e documenti digitali
• Consulente tecnico di parte informatico a Roma
• Contatti

Anchor text consigliati

verifica forense di screenshot a Roma
analisi autenticità schermata digitale
perizia screenshot WhatsApp
verifica schermata bonifico
analisi ritagli e manipolazioni
acquisizione tecnica di una schermata
correlazione screenshot e dispositivo
analisi forense di screen recording
verifica screenshot social e pagine web
consulente informatico forense Roma

81. Box commerciale finale

Devi verificare uno screenshot o una schermata a Roma?

Una valutazione tecnica può essere utile quando devi comprendere:

[ ] se il file è una cattura nativa, un ritaglio o una fotografia del display;
[ ] quali metadati e timestamp contiene;
[ ] se dimensioni e interfaccia sono compatibili con il dispositivo dichiarato;
[ ] se esistono segni di annotazione, ricompressione o composizione;
[ ] se una chat è correlabile ai dati dell’app;
[ ] se una schermata email è verificabile tramite header;
[ ] se un post social può essere acquisito con maggiore completezza;
[ ] se una schermata bancaria trova riscontro in documenti ufficiali;
[ ] se il file è presente nel dispositivo o nel backup;
[ ] quali limiti devono essere dichiarati nella relazione.

Conserva il file nella forma ricevuta, evita di ritagliarlo o convertirlo e, quando possibile, non modificare il dispositivo sorgente prima della valutazione.

Lo Studio Quaranta Digital Forensics a Roma può svolgere acquisizione tecnica, analisi del file, verifica di metadati e struttura, confronto tra versioni, correlazione con dispositivi e applicazioni, ricostruzione temporale e redazione di relazione tecnica.

82. Conclusione del capitolo

Lo screenshot è utile perché rende visibile un’informazione in modo immediato. La stessa immediatezza può però nascondere ciò che manca: origine, database, sequenza, account, log, URL, contenuto fuori schermo e trasformazioni successive.

La verifica forense non consiste nel cercare un singolo “errore grafico”. Deve partire dal file, conservarne l’identità, comprenderne il formato e ricostruire il rapporto con dispositivo, applicazione, comunicazione e fonti indipendenti.

La relazione deve distinguere:

- ciò che è direttamente visibile;
- ciò che è rilevato nella struttura del file;
- ciò che è compatibile con un sistema o un’app;
- ciò che è confermato dal dispositivo o dal database;
- ciò che trova riscontro in server, cloud o fonti esterne;
- ciò che rimane indeterminato.

Nel prossimo capitolo il manuale affronterà la conservazione di contenuti online, per i quali uno screenshot costituisce soltanto una delle possibili componenti dell’acquisizione:

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

Saranno trattati URL, HTML, risorse, header HTTP, certificati, DNS, video di navigazione, archivi web, contenuti dinamici, profili social, timestamp, hash, volatilità e limiti delle acquisizioni da piattaforme remote.

Continua con il Capitolo 16 — Acquisizione di pagine web, social e contenuti online →