Relazione tecnica, CTP informatico e contestazione delle prove digitali

Introduzione

Una perizia informatica non termina quando il software conclude l’estrazione, quando viene calcolato un hash o quando il tecnico individua un messaggio ritenuto rilevante.

L’accertamento diventa realmente utilizzabile quando il perito è in grado di spiegare:

• quale incarico abbia ricevuto;
• quali materiali abbia esaminato;
• con quale autorizzazione;
• come siano stati acquisiti;
• quali strumenti siano stati utilizzati;
• quali trasformazioni siano state prodotte;
• quali risultati siano direttamente osservabili;
• quali collegamenti siano dedotti;
• quali ipotesi alternative siano state considerate;
• quali limiti impediscano conclusioni più forti;
• dove siano reperibili i dati che consentono una verifica indipendente.

Una relazione può essere tecnicamente debole anche quando contiene molte pagine, numerosi screenshot e centinaia di allegati.

Può essere debole perché:

• non identifica gli originali;
• non contiene gli hash;
• non distingue il file sorgente dalla copia di lavoro;
• non indica le versioni degli strumenti;
• non documenta le query;
• utilizza soltanto report automatici;
• attribuisce un account a una persona;
• trasforma un’assenza di log in prova negativa;
• confonde compatibilità e certezza;
• omette i dati contrari alla tesi del committente;
• non consente la ripetizione delle operazioni.

Una relazione breve può invece essere tecnicamente solida quando:

• risponde esattamente al quesito;
• descrive il metodo;
• mantiene il collegamento con le fonti;
• separa fatti e interpretazioni;
• indica l’incertezza;
• utilizza formule proporzionate;
• rende disponibili gli allegati essenziali.

Le linee guida SWGDE sul reporting richiedono che il rapporto identifichi il caso e il richiedente, chiarisca lo scopo, descriva procedure e risultati, indichi la base delle eventuali opinioni, documenti la destinazione dei reperti e sia autorizzato o sottoscritto. La documentazione deve permettere a un altro tecnico competente di comprendere e valutare il processo seguito; il report automatico prodotto da uno strumento costituisce normalmente un allegato e non sostituisce la relazione dell’esaminatore. (SWGDE — Requirements for Report Writing in Digital and Multimedia Forensics)

Il CTP informatico non ha il compito di “difendere a ogni costo” una conclusione tecnicamente insostenibile.

Il suo ruolo è:

• assistere tecnicamente la parte;
• comprendere il quesito processuale;
• verificare il metodo adottato;
• partecipare alle operazioni;
• formulare richieste e osservazioni;
• individuare omissioni o sovrainterpretazioni;
• proporre accertamenti riproducibili;
• spiegare al difensore il significato e i limiti dei risultati;
• redigere una relazione tecnicamente sostenibile.

La contestazione efficace di una prova digitale non consiste nel dichiarare genericamente:

“Il file potrebbe essere stato modificato.”

Occorre invece spiegare:

- quale passaggio non è documentato;
- quale fonte manca;
- quale alterazione è tecnicamente possibile;
- quale controllo non è stato eseguito;
- quale conclusione supera i dati;
- quale accertamento potrebbe risolvere il dubbio.

Regola fondamentale: una contestazione tecnica è efficace quando identifica un difetto verificabile, ne descrive l’impatto sul quesito e propone un controllo capace di confermarlo o smentirlo.

Sintesi operativa

1. formalizzare l’incarico e l’autorità all’esame;
2. acquisire il quesito nella sua formulazione esatta;
3. distinguere ruolo giudiziario, di parte e stragiudiziale;
4. tradurre il quesito giuridico in domande tecniche verificabili;
5. definire perimetro, periodo, dispositivi, account e fonti;
6. dichiarare esplicitamente ciò che resta escluso;
7. identificare ogni reperto mediante codice univoco;
8. documentare consegna, acquisizione, hash e custodia;
9. mantenere separati originali, copie forensi e output derivati;
10. registrare strumenti, versioni, licenze e configurazioni;
11. conservare comandi, query, log ed errori;
12. verificare manualmente i risultati decisivi;
13. distinguere dati grezzi, artefatti e interpretazioni;
14. formulare almeno un’ipotesi alternativa plausibile;
15. indicare precisione, incertezza e limiti;
16. evitare di attribuire account, IP o dispositivo a una persona senza riscontri;
17. preparare una relazione comprensibile anche al lettore non tecnico;
18. inserire definizioni per acronimi e termini specialistici;
19. rispondere separatamente a ogni quesito;
20. collegare ogni conclusione alle evidenze che la sostengono;
21. includere gli elementi contrari o non coerenti;
22. predisporre un indice degli allegati;
23. calcolare l’hash degli allegati e degli output finali;
24. proteggere dati personali e contenuti non pertinenti;
25. oscurare soltanto copie derivate, mai gli originali;
26. conservare una versione firmata e non modificabile della relazione;
27. documentare ogni correzione mediante relazione integrativa;
28. preparare osservazioni alla CTU specifiche e tempestive;
29. distinguere difetto metodologico, limite e semplice divergenza interpretativa;
30. proporre verifiche riproducibili;
31. preparare domande tecniche concise per chiarimenti o udienza;
32. conservare la possibilità di esibire i record originari;
33. verificare le regole telematiche applicabili al deposito;
34. non allegare indiscriminatamente interi dataset riservati;
35. predisporre una matrice quesito-evidenza-conclusione;
36. sottoporre il rapporto a revisione tecnica indipendente;
37. correggere refusi, riferimenti e numerazione;
38. consegnare al difensore una legenda dei limiti;
39. mantenere una copia del fascicolo secondo le regole applicabili;
40. formulare conclusioni proporzionate e tecnicamente difendibili.

1. Avvertenza preliminare

Il presente capitolo descrive metodologie tecniche e organizzative.

Non costituisce consulenza legale.

Le decisioni relative a:

• ammissibilità;
• utilizzabilità;
• strategia processuale;
• termini;
• deposito;
• produzione documentale;
• eccezioni;
• nullità;
• qualificazione giuridica;
• formulazione delle conclusioni difensive;

competono all’avvocato e, nei rispettivi ambiti, al giudice o al pubblico ministero.

Le attività tecniche devono essere svolte esclusivamente:

• sui reperti consegnati o legittimamente acquisiti;
• secondo il provvedimento giudiziario;
• nei limiti dell’incarico;
• con autorizzazione del titolare o dell’autorità;
• su copie controllate;
• nel rispetto del contraddittorio;
• senza accedere a sistemi o account di terzi;
• senza ampliare autonomamente il perimetro.

Non è lecito:

• utilizzare credenziali non autorizzate;
• accedere a cloud personali;
• superare protezioni;
• modificare reperti;
• alterare timestamp;
• cancellare log;
• creare prove;
• presentare risultati ottenuti su un file diverso da quello dichiarato;
• omettere consapevolmente dati contrari alla conclusione;
• attribuire un’attività digitale a una persona senza fondamento.

2. Che cos’è una relazione tecnica informatico-forense

Una relazione tecnica informatico-forense è il documento attraverso il quale l’esaminatore descrive:

incarico
→ materiale
→ metodo
→ operazioni
→ risultati
→ interpretazione
→ limiti
→ conclusioni

Deve consentire a un lettore competente di comprendere:

• che cosa sia stato fatto;
• perché sia stato fatto;
• su quale reperto;
• con quali strumenti;
• con quale esito;
• con quali possibilità di errore;
• con quale collegamento al quesito.

Il reporting costituisce una delle fasi fondamentali della digital forensics, insieme a raccolta, esame e analisi. NIST descrive il processo forense attraverso le fasi di collection, examination, analysis e reporting; SWGDE richiede una documentazione sufficientemente chiara da rendere valutabili e riproducibili le attività. (NIST SP 800-86)

3. Relazione, perizia, consulenza e memoria tecnica

I termini vengono spesso utilizzati in modo intercambiabile, ma il contesto può essere differente.

3.1 Relazione tecnica stragiudiziale

È redatta su incarico di:

• privato;
• azienda;
• studio legale;
• assicurazione;
• professionista.

Può essere utilizzata per:

• valutare preliminarmente il caso;
• orientare una strategia;
• preservare prove;
• supportare una diffida;
• preparare un giudizio;
• rispondere a una contestazione.

3.2 Relazione del CTP

È redatta dal consulente della parte nell’ambito o in vista di un procedimento.

Può:

• documentare accertamenti autonomi;
• formulare osservazioni alla CTU;
• rispondere alla bozza;
• proporre quesiti o approfondimenti;
• contestare metodo e conclusioni.

3.3 Relazione del CTU

È redatta dall’ausiliario nominato dal giudice secondo il quesito e le disposizioni ricevute.

3.4 Perizia penale

È l’accertamento disposto dal giudice nel procedimento penale.

3.5 Consulenza tecnica del pubblico ministero

È svolta dal consulente nominato dal pubblico ministero per accertamenti o operazioni che richiedono competenze specifiche.

3.6 Memoria tecnica

È un documento più circoscritto, diretto a:

• chiarire un aspetto;
• contestare un risultato;
• rispondere a una relazione;
• proporre un controllo;
• integrare una precedente analisi.

4. CTU, CTP, perito e consulente stragiudiziale

Presso ogni tribunale sono istituiti gli albi dei consulenti tecnici per l’ambito civile e dei periti per quello penale, destinati a individuare professionisti dei quali l’ufficio può avvalersi. (Ministero della giustizia — Albi dei consulenti tecnici e dei periti)

5. Il CTU nel processo civile

L’articolo 61 c.p.c. prevede che il giudice possa farsi assistere da uno o più consulenti dotati di particolare competenza tecnica; l’articolo 191 disciplina l’ordinanza di nomina, la formulazione dei quesiti e la comparizione del consulente. (Gazzetta Ufficiale — art. 61 c.p.c.)

Il CTU informatico può essere chiamato, ad esempio, a:

• esaminare un computer;
• acquisire uno smartphone;
• verificare una chat;
• ricostruire una timeline;
• analizzare accessi a un account;
• confrontare documenti digitali;
• verificare una firma;
• analizzare registrazioni;
• valutare una perdita di dati;
• esaminare un sistema aziendale.

Il CTU deve rimanere nel perimetro del quesito e delle autorizzazioni ricevute.

Non dovrebbe:

• sostituirsi al giudice;
• formulare qualificazioni giuridiche;
• ampliare autonomamente la controversia;
• cercare indiscriminatamente dati;
• eseguire accessi non autorizzati;
• utilizzare fonti non comunicate alle parti;
• omettere le osservazioni tecniche ricevute.

6. Il giuramento del CTU

L’articolo 193 c.p.c. prevede il giuramento del consulente nominato dal giudice, chiamato ad adempiere bene e fedelmente le funzioni affidate allo scopo di far conoscere al giudice la verità. (Gazzetta Ufficiale — art. 193 c.p.c.)

Sul piano tecnico, ciò richiede:

• autonomia di valutazione;
• completezza;
• trasparenza;
• neutralità rispetto agli interessi delle parti;
• corretta rappresentazione delle incertezze;
• considerazione delle osservazioni;
• documentazione delle limitazioni.

7. L’attività del CTU e il contraddittorio

L’articolo 194 c.p.c. disciplina le attività del consulente e consente alle parti di intervenire alle operazioni attraverso i difensori e i consulenti tecnici, formulando osservazioni e richieste. (Gazzetta Ufficiale — art. 194 c.p.c.)

In ambito informatico, il contraddittorio dovrebbe riguardare almeno:

- identificazione dei reperti;
- condizioni di acquisizione;
- strumenti;
- hash;
- procedure;
- filtri;
- query;
- intervalli;
- interpretazioni;
- output;
- anomalie;
- fonti mancanti.

Il contraddittorio non consiste nel consentire ai CTP di osservare passivamente lo schermo del CTU.

Richiede che possano comprendere:

• quale sorgente venga esaminata;
• quale operazione venga eseguita;
• quale modifica possa essere prodotta;
• quale output venga generato;
• dove sia conservato;
• come possa essere verificato.

8. La relazione del CTU e le osservazioni delle parti

L’articolo 195 c.p.c. prevede la trasmissione della relazione alle parti nel termine stabilito, il successivo invio delle osservazioni e il deposito della relazione finale con le osservazioni e una sintetica valutazione delle stesse. (Gazzetta Ufficiale — art. 195 c.p.c.)

La risposta del CTU alle osservazioni non dovrebbe limitarsi a formule come:

“Si conferma quanto già esposto.”

Dovrebbe indicare:

• quale rilievo è stato esaminato;
• se è fondato;
• quale verifica è stata effettuata;
• quale dato lo conferma o lo smentisce;
• se la conclusione è stata modificata;
• perché l’osservazione non incide sul quesito.

9. Il CTP nel processo civile

L’articolo 201 c.p.c. consente alle parti di depositare la dichiarazione di nomina del proprio consulente tecnico nel termine assegnato dal giudice; il CTP può assistere alle operazioni, partecipare quando interviene il consulente del giudice e formulare osservazioni sui risultati delle indagini. (Gazzetta Ufficiale — art. 201 c.p.c.)

Il CTP informatico deve:

• leggere integralmente il provvedimento;
• comprendere il quesito;
• coordinarsi col difensore;
• studiare gli atti;
• verificare il perimetro;
• partecipare alle operazioni;
• verbalizzare le richieste;
• controllare copie e hash;
• verificare output e conclusioni;
• formulare osservazioni comprensibili.

Il CTP assiste una parte.

Ciò non significa che possa:

• omettere dati sfavorevoli;
• alterare la semantica degli artefatti;
• formulare certezze inesistenti;
• attaccare personalmente il CTU;
• presentare ipotesi non verificabili;
• confondere strategia difensiva e dato tecnico.

10. Il consulente nel procedimento penale

Quando è disposta una perizia, i consulenti tecnici delle parti possono assistere al conferimento dell’incarico, presentare richieste, osservazioni e riserve e partecipare alle operazioni proponendo specifiche indagini. L’articolo 230 c.p.p. richiede che le osservazioni e le riserve trovino riscontro nel verbale o nella relazione; la loro attività non può ritardare la perizia. (Gazzetta Ufficiale — art. 230 c.p.p.)

Fuori dai casi di perizia, l’articolo 233 c.p.p. consente a ciascuna parte di nominare fino a due consulenti tecnici, i quali possono esporre il proprio parere anche mediante memoria; l’esame di cose sequestrate o l’intervento alle ispezioni richiedono le autorizzazioni previste. (Gazzetta Ufficiale — art. 233 c.p.p.)

Il pubblico ministero può nominare propri consulenti quando sono necessarie specifiche competenze tecniche, ai sensi dell’articolo 359 c.p.p. (Gazzetta Ufficiale — art. 359 c.p.p.)

11. Accertamenti tecnici ripetibili e non ripetibili

Dal punto di vista informatico, la ripetibilità non dipende soltanto dalla possibilità teorica di rieseguire un software.

Occorre considerare:

• stato del dispositivo;
• volatilità dei dati;
• cifratura;
• sessioni attive;
• cloud;
• retention;
• aggiornamenti;
• contenuti online;
• possibilità che l’operazione modifichi la sorgente.

Esempi potenzialmente non ripetibili o fortemente deperibili:

- acquisizione di memoria RAM;
- accesso a una sessione cloud in scadenza;
- export di log prossimi alla rotazione;
- acquisizione di una pagina destinata alla rimozione;
- analisi di un dispositivo acceso e cifrato;
- acquisizione di un messaggio effimero;
- raccolta di traffico di rete in corso.

La qualificazione processuale della ripetibilità compete al legale e all’autorità.

Il tecnico deve descrivere concretamente:

• quale dato rischia di scomparire;
• quale operazione lo modifica;
• quale alternativa esiste;
• quali parti possono partecipare;
• quale documentazione verrà prodotta.

12. Il consulente stragiudiziale

Il consulente stragiudiziale opera sulla base dell’incarico ricevuto dal cliente o dal difensore.

Può essere incaricato di:

• valutare il materiale;
• preservare prove;
• individuare fonti mancanti;
• formulare un quesito;
• stimare la fattibilità;
• predisporre una relazione;
• assistere una negoziazione;
• preparare una futura consulenza di parte.

Il mandato dovrebbe indicare:

- committente;
- finalità;
- sistemi;
- periodo;
- fonti;
- autorizzazioni;
- esclusioni;
- destinatari;
- riservatezza;
- conservazione;
- compenso.

13. Relazione tecnica e strategia legale

Il perito non deve decidere:

• quale domanda proporre;
• quale eccezione sollevare;
• quale atto depositare;
• quale qualificazione giuridica applicare;
• se produrre integralmente un documento;
• se chiedere un sequestro;
• se rinunciare a una contestazione.

Deve però fornire al difensore informazioni tecniche sufficienti per prendere tali decisioni.

Esempio:

dato tecnico:
il file disponibile è un JPEG WhatsApp privo dei metadati originari;

implicazione tecnica:
non è possibile verificare integralmente la pipeline fotografica;

valutazione processuale:
competenza del difensore.

14. Definire l’incarico

Un incarico generico:

“Analizzare il telefono.”

è insufficiente.

Un incarico tecnico può indicare:

- acquisire il dispositivo;
- preservare i dati;
- esaminare WhatsApp;
- periodo 1–15 giugno 2026;
- interlocutori specifici;
- verificare messaggi e allegati;
- ricostruire cancellazioni;
- indicare limiti;
- produrre relazione e allegati.

15. Autorità all’esame

La relazione dovrebbe documentare la base tecnica e organizzativa dell’accesso:

• proprietà;
• consenso;
• incarico aziendale;
• provvedimento;
• nomina;
• autorizzazione del giudice;
• autorizzazione del pubblico ministero;
• consegna del titolare;
• accesso amministrativo legittimo.

SWGDE raccomanda di confermare preventivamente l’autorità legale all’esame, osservando che essa può essere granulare e limitare periodi, artefatti o termini di ricerca. (SWGDE — Best Practices for Computer Forensic Examinations)

“L’analisi è stata eseguita nei limiti dell’autorizzazione e del perimetro indicati nell’incarico.”

16. Tradurre il quesito in domande tecniche

Quesito improprio:

“Il convenuto ha falsificato la chat?”

Domande tecniche:

1. quale materiale è disponibile;
2. proviene dal dispositivo originario;
3. esiste il database dell’app;
4. quali identificativi contiene;
5. i timestamp sono coerenti;
6. esistono modifiche o cancellazioni;
7. gli screenshot coincidono col database;
8. quali limiti impediscono l’attribuzione personale.

Quesito improprio:

“L’azienda ha subito un furto di dati?”

Domande tecniche:

1. quali dati erano accessibili;
2. quali account li hanno consultati;
3. esistono download;
4. esistono archivi;
5. sono stati collegati supporti;
6. esistono upload esterni;
7. il file è presente sulla destinazione;
8. chi controllava tecnicamente la sessione.

17. Matrice quesito–fonte–risultato

18. Perimetro e limitazioni

La relazione deve indicare espressamente ciò che non è stato esaminato.

Esempio:

Incluso:
- laptop PC01;
- account Microsoft 365 A;
- periodo 1–10 luglio 2026;
- OneDrive;
- posta inviata.

Escluso:
- telefono personale;
- account Gmail privato;
- periodo anteriore;
- server non consegnato;
- dati del provider non disponibili.

“Le conclusioni non possono essere estese alle fonti escluse o non disponibili.”

19. Cartella del caso

CASO_RM_2026_030/
├── 00_incarico/
├── 01_provvedimenti/
├── 02_verbali/
├── 03_corrispondenza/
├── 04_registro_reperti/
├── 05_originali/
├── 06_immagini_forensi/
├── 07_hash/
├── 08_copie_lavoro/
├── 09_output_strumenti/
├── 10_query_comandi/
├── 11_timeline/
├── 12_osservazioni_ctu/
├── 13_allegati/
├── 14_oscurati/
├── 15_report_revisioni/
├── 16_deposito/
└── 17_conservazione/

20. Registro dei reperti

21. Catena di custodia

Per ogni reperto registrare:

- identificativo;
- descrizione;
- proprietario o custode;
- soggetto consegnante;
- data e ora;
- fuso;
- stato;
- seriale;
- modalità di acquisizione;
- strumento;
- versione;
- destinazione;
- hash;
- trasferimenti;
- accessi;
- restituzione o conservazione.

La procedura completa è descritta nel Capitolo 2 — Catena di custodia, hash e verbale tecnico.

22. Originali, copie forensi e output derivati

Originale

Il reperto o file consegnato.

Copia forense

La copia acquisita con metodo documentato.

Copia di lavoro

La copia utilizzata dagli strumenti.

Output derivato

Esempi:

• CSV;
• PDF;
• screenshot;
• timeline;
• WAV PCM;
• frame PNG;
• file decifrato;
• database normalizzato.

La relazione deve evitare di chiamare “originale” ogni file utilizzato durante l’analisi.

23. Protezione degli originali

Quando possibile:

• evitare l’esame diretto;
• utilizzare write blocker;
• montare in sola lettura;
• conservare la prima immagine;
• lavorare su copia;
• verificare gli hash.

SWGDE raccomanda di evitare l’esame diretto dell’originale quando possibile, proteggere la fonte con write blocker e svolgere l’analisi su copia per ridurre il rischio di alterazione. (SWGDE — Best Practices for Computer Forensic Examinations)

24. Calcolo degli hash

PowerShell

Get-FileHash -Algorithm SHA256 `
  -LiteralPath ".\reperto.E01"

Linux

sha256sum -- reperto.E01

macOS

shasum -a 256 -- reperto.E01

Manifesto degli allegati

find allegati -type f -print0 \
  | sort -z \
  | xargs -0 sha256sum \
  > manifest_sha256.txt

L’hash dimostra l’identità binaria tra i file confrontati.

Non dimostra:

• autenticità precedente;
• completezza;
• provenienza personale;
• correttezza dell’acquisizione;
• assenza di manipolazioni anteriori.

25. Diario delle operazioni

Registrare anche:

• errori;
• interruzioni;
• tentativi falliti;
• modifiche;
• aggiornamenti;
• eccezioni;
• deviazioni dalla procedura.

26. Case notes e relazione

Le note tecniche possono contenere:

• ipotesi provvisorie;
• prove non confermate;
• comandi;
• percorsi;
• errori;
• ragionamenti;
• attività da completare;
• osservazioni.

La relazione contiene invece:

• metodo consolidato;
• risultati verificati;
• conclusioni;
• limiti;
• riferimenti agli allegati.

Il rapporto non dovrebbe essere scritto soltanto ricopiando l’output del software.

27. Strumenti e versioni

Per ogni strumento indicare:

- nome;
- produttore o progetto;
- versione;
- modulo;
- plugin;
- sistema operativo;
- licenza;
- configurazione;
- data di esecuzione.

Esempio:

ExifTool:
versione 13.xx;

FFmpeg:
versione n.x;

Plaso:
versione x.x;

Tool mobile:
versione e build;

Parser:
nome, commit e hash.

28. Report automatici

Un report prodotto dal software può contenere:

• artefatti;
• percorsi;
• timestamp;
• preview;
• categorie;
• filtri.

Non documenta necessariamente:

• quesito;
• autorizzazione;
• metodo complessivo;
• errori;
• significato;
• limiti;
• ragionamento;
• conclusioni.

SWGDE considera i report automatici documentazione di supporto e non sostitutiva della relazione dell’esaminatore. (SWGDE — Requirements for Report Writing)

29. Validazione degli strumenti

La relazione dovrebbe indicare come sia stata verificata l’affidabilità del metodo.

Possibili controlli:

• test su dataset noti;
• confronto tra strumenti;
• verifica manuale;
• controllo del record raw;
• documentazione ufficiale;
• confronto con una seconda implementazione;
• ripetizione dell’operazione;
• hash degli output.

“Il risultato decisivo è stato verificato sul dato originario e mediante il controllo indipendente descritto.”

30. Tool disagreement

Due strumenti possono restituire risultati differenti.

Possibili cause:

• parser;
• timezone;
• versione;
• campo interpretato;
• record eliminato;
• gestione della corruzione;
• supporto parziale;
• filtro.

La relazione deve indicare:

- risultato A;
- risultato B;
- verifica manuale;
- decisione;
- motivo.

31. Comandi, query e script

Conservare:

• comando completo;
• working directory;
• input;
• output;
• errori;
• versione;
• variabili;
• script;
• hash dello script.

Esempio:

sha256sum \
  -- "reperto.E01" \
  > "reperto.E01.sha256.txt"

Esempio SQLite:

SELECT
    message_id,
    sender,
    timestamp,
    body
FROM messages
WHERE timestamp BETWEEN ? AND ?
ORDER BY timestamp;

32. Script custom

Uno script utilizzato nel caso dovrebbe contenere:

• autore;
• versione;
• descrizione;
• parametri;
• gestione errori;
• input;
• output;
• dipendenze;
• test.

Conservare:

sha256sum \
  "timeline_converter.py" \
  > "timeline_converter.py.sha256.txt"

La relazione dovrebbe distinguere:

• output del tool;
• output dello script;
• interpretazione umana.

33. Metodo scientifico e ipotesi

Una struttura utile è:

1. formulare il quesito;
2. acquisire le fonti;
3. formulare ipotesi;
4. definire test;
5. eseguire controlli;
6. valutare risultati favorevoli e contrari;
7. indicare limiti;
8. formulare conclusione.

Esempio:

H1:
il messaggio proviene dal database del dispositivo;

H2:
il messaggio esiste soltanto nello screenshot;

test:
database, ID, allegato, backup, dispositivo.

34. Fatti, osservazioni e deduzioni

Fatto osservato

“Nel database è presente il record con ID 8452.”

Interpretazione

“Il record è compatibile con un messaggio inviato.”

Deduzione ulteriore

“L’account era utilizzato dalla persona.”

La terza affermazione richiede ulteriori elementi.

La relazione dovrebbe utilizzare etichette o formule che rendano visibile il passaggio interpretativo.

35. Livelli di conclusione

Una scala orientativa:

Evitare percentuali non validate.

36. Elementi favorevoli e contrari

Per ogni ipotesi:

Una relazione che espone soltanto gli elementi favorevoli perde credibilità.

37. Alternative tecniche

Esempio:

“Il file è stato creato dall’utente.”

Alternative:

• processo automatico;
• sincronizzazione;
• antivirus;
• backup;
• amministratore;
• malware;
• altra persona;
• ripristino;
• importazione.

La relazione non deve elencare alternative astratte prive di rapporto col caso.

Deve spiegare:

• quali sono plausibili;
• quali sono smentite;
• quali non possono essere valutate.

38. Incertezza

Possibili fonti di incertezza:

• clock drift;
• arrotondamento;
• record mancante;
• compressione;
• campione breve;
• file derivato;
• database parziale;
• parser;
• account condiviso;
• geolocalizzazione IP.

“L’intervallo è stimato con un’incertezza di ±5 secondi.”

oppure:

“Le fonti non consentono di quantificare numericamente l’incertezza.”

39. Scrivere per il lettore non tecnico

La relazione deve spiegare termini come:

• hash;
• immagine forense;
• metadato;
• timestamp;
• database;
• codec;
• token;
• sessione;
• log;
• C2PA.

Esempio:

“L’hash SHA-256 è un valore calcolato sul contenuto binario del file e utilizzato per verificare se due copie siano identiche.”

Non:

“È stato calcolato lo SHA senza anomalie.”

40. Chiarezza e sinteticità

Il codice di procedura civile richiede che gli atti del processo siano redatti in modo chiaro e sintetico; il regolamento ministeriale del 2023 disciplina criteri di redazione, limiti e schemi informatici degli atti giudiziari. (Decreto ministeriale n. 110/2023)

Sinteticità non significa:

• omettere il metodo;
• nascondere i limiti;
• eliminare gli allegati;
• ridurre tutto a una conclusione.

Significa:

• evitare ripetizioni;
• strutturare il testo;
• separare dettagli e allegati;
• usare tabelle;
• rispondere ai quesiti.

41. Struttura editoriale consigliata

1. frontespizio;
2. indice;
3. incarico;
4. quesito;
5. autorizzazione;
6. materiale;
7. cronologia;
8. metodo;
9. strumenti;
10. risultati;
11. discussione;
12. limiti;
13. risposte ai quesiti;
14. conclusioni;
15. allegati;
16. firma.

42. Frontespizio

Dovrebbe contenere:

- autorità o committente;
- procedimento;
- numero RG o codice caso;
- parti;
- titolo;
- autore;
- ruolo;
- data;
- versione;
- livello di riservatezza.

Evitare di inserire dati personali non necessari nel titolo del file.

43. Identificativo e versione

Esempio:

Relazione tecnica informatico-forense
Caso RM-2026-030
Versione 1.0
14 luglio 2026

Per integrazioni:

Relazione integrativa
Versione 1.1
Riferimento alla versione 1.0
Modifiche descritte nella sezione 2

SWGDE raccomanda che una relazione modificata venga ripubblicata come nuova versione, identificando e spiegando le correzioni e richiamando il rapporto originario. (SWGDE — Requirements for Report Writing)

44. Sommario esecutivo

Dovrebbe rispondere, in poche righe:

• che cosa è stato esaminato;
• perché;
• quale risultato principale;
• quali limiti essenziali.

Esempio:

“È stato esaminato il database WhatsApp acquisito dal dispositivo RM30-002. I record indicati risultano presenti nella fonte e coerenti con gli allegati locali. L’attività è associata all’account e al dispositivo; il materiale non consente di identificare autonomamente la persona che utilizzava la sessione.”

45. Incarico e quesito

Riportare il quesito nella formulazione ricevuta.

Successivamente indicare la traduzione tecnica.

Esempio:

Quesito ricevuto:
verificare l’autenticità della conversazione.

Domande tecniche:
- origine del materiale;
- presenza nel database;
- identificativi;
- timestamp;
- allegati;
- cancellazioni;
- coerenza con screenshot.

46. Materiale esaminato

Per ogni reperto:

ID:
Descrizione:
Fonte:
Stato:
Data consegna:
Dimensione:
Hash:
Tipo di acquisizione:
Limitazioni:

Indicare anche il materiale ricevuto ma non esaminato.

47. Cronologia delle operazioni

48. Metodo

Descrivere:

• preparazione;
• acquisizione;
• verifica;
• parsing;
• analisi;
• correlazione;
• reporting.

Non è necessario trasformare la relazione in un manuale del software.

Occorre però consentire la comprensione e la ripetizione delle operazioni decisive.

49. Risultati

I risultati dovrebbero essere organizzati secondo il quesito.

Esempio:

9.1 Presenza del messaggio
9.2 Identificativo
9.3 Allegato
9.4 Timestamp
9.5 Account
9.6 Cancellazioni
9.7 Confronto con screenshot

50. Discussione

La discussione collega i risultati alle ipotesi.

Esempio:

“La presenza del record e dell’allegato supporta la provenienza della conversazione dal database acquisito. L’assenza del secondo dispositivo non consente di verificare la ricezione sul terminale dell’interlocutore.”

51. Limiti

Possibili limiti:

• dispositivo non disponibile;
• acquisizione logica;
• cifratura;
• file derivato;
• retention;
• account condiviso;
• clock non verificato;
• supporto sovrascritto;
• app non supportata;
• report incompleto;
• file corrotto;
• campione breve;
• detector fuori dominio.

I limiti devono essere collegati alla conclusione.

52. Risposte ai quesiti

Rispondere separatamente.

Esempio:

Quesito 1:
Il messaggio è presente?

Risposta:
Il record è presente nel database acquisito.

Quesito 2:
È stato inviato personalmente dal soggetto?

Risposta:
Il record è associato all’account indicato. Le fonti non consentono
di identificare autonomamente la persona che controllava il dispositivo.

53. Conclusioni

Le conclusioni devono:

• derivare dai risultati;
• rispettare i limiti;
• evitare nuove informazioni;
• non introdurre qualificazioni giuridiche;
• non ampliare il quesito.

54. Allegati

Possibili allegati:

• verbali;
• registro reperti;
• hash;
• fotografie;
• report tool;
• CSV;
• database;
• screenshot;
• timeline;
• log;
• query;
• script;
• manuali;
• manifesti.

Non allegare indiscriminatamente interi contenuti personali quando non necessari.

55. Indice degli allegati

56. File naming

Preferire nomi come:

A01_registro-reperti.pdf
A02_manifest-sha256.txt
A03_timeline-utc.csv
A04_output-exiftool.json
A05_query-messaggi.sql

Evitare:

nuovo.pdf
finale2.pdf
prova_definitiva_ultima.pdf
screenshot1.png

57. PDF della relazione

Il PDF dovrebbe essere:

• testuale;
• ricercabile;
• privo di elementi attivi non necessari;
• con indice;
• con numerazione;
• con riferimenti agli allegati;
• accessibile;
• firmato secondo le modalità applicabili.

Le specifiche tecniche pubblicate dal Portale dei Servizi Telematici richiedono, per l’atto processuale informatico, un PDF privo di elementi attivi, ottenuto dalla trasformazione di un documento testuale e sottoscritto con firma digitale o qualificata nei formati previsti; prima del deposito devono essere verificate le specifiche e le istruzioni correnti del sistema e dell’ufficio competente. (PST — Specifiche tecniche del processo telematico)

58. Firma digitale

La firma digitale della relazione documenta:

• sottoscrizione;
• integrità dopo la firma;
• certificato;
• momento della verifica, secondo le informazioni disponibili.

Non dimostra:

• correttezza tecnica del contenuto;
• autenticità dei reperti;
• completezza;
• validità giuridica garantita.

Conservare:

• PDF firmato;
• firma;
• report di verifica;
• certificati;
• eventuali marche temporali;
• hash.

59. Allegati di grandi dimensioni

Possibili strategie:

• suddivisione numerata;
• manifesti hash;
• supporto cifrato;
• deposito secondo autorizzazione;
• repository controllato;
• selezione degli elementi pertinenti;
• copia integrale a disposizione.

Il consulente deve coordinarsi col difensore e verificare le modalità ammesse dal procedimento e dall’ufficio.

60. Deposito telematico

Prima del deposito verificare:

- ruolo del depositante;
- tipo di atto;
- firma;
- formati;
- dimensioni;
- nomi file;
- allegati;
- ricevute;
- esito controlli;
- consultabilità.

Il Portale dei Servizi Telematici fornisce le schede operative e le specifiche correnti per i depositi; gli adempimenti concreti devono essere verificati al momento del deposito. (Portale dei Servizi Telematici)

61. Protezione dei dati nella relazione

Il Garante richiede che consulenti e periti utilizzino soltanto informazioni effettivamente necessarie e non inseriscano nelle relazioni dati delicati non pertinenti o relativi a soggetti estranei. (Garante privacy — Linee guida per consulenti tecnici e periti)

Applicazioni pratiche:

• non riportare intere chat;
• non allegare fotografie estranee;
• oscurare numeri non pertinenti;
• pseudonimizzare minori;
• separare allegati riservati;
• evitare password e token;
• rimuovere dati sanitari non necessari.

62. Sicurezza dei dati peritali

Predisporre:

- cifratura dei supporti;
- controllo accessi;
- autenticazione forte;
- backup cifrati;
- registro accessi;
- canali sicuri;
- workstation dedicata;
- distruzione controllata.

Il Garante richiede accorgimenti adeguati contro divulgazione indebita, perdita e distruzione, attribuendo al consulente responsabilità concrete sulla sicurezza dei dati trattati durante l’incarico. (Garante privacy — Linee guida)

63. Conservazione

Per gli ausiliari nominati dall’autorità, le linee guida del Garante prevedono, salvo diversa disposizione o autorizzazione, la consegna della documentazione agli atti del procedimento e l’assenza di una conservazione ulteriore di copie personali non necessarie. (Garante privacy — Linee guida)

Per il consulente della parte e il difensore, la conservazione può proseguire quando risulti necessaria per ipotizzabili esigenze difensive, tenendo conto della tipologia dei dati e limitando quanto conservato a ciò che resta effettivamente necessario. (Garante privacy — Regole deontologiche per investigazioni difensive)

Definire:

• responsabile;
• durata;
• finalità;
• accessi;
• restituzione;
• distruzione;
• eccezioni.

64. Revisione tecnica

Prima della consegna, un secondo tecnico competente dovrebbe verificare:

- quesito;
- corrispondenza dei reperti;
- hash;
- comandi;
- query;
- interpretazione;
- riferimenti;
- limiti;
- conclusioni.

La revisione non consiste nel correggere soltanto ortografia e impaginazione.

Deve verificare la sostenibilità tecnica.

65. Revisione amministrativa

Controllare:

• intestazioni;
• nomi;
• numero procedimento;
• date;
• versioni;
• allegati;
• pagine;
• firme;
• riferimenti incrociati;
• manifesti.

66. Relazione integrativa

Può essere necessaria quando:

• emerge un nuovo reperto;
• viene rilevato un errore;
• il giudice chiede chiarimenti;
• arriva un nuovo log;
• una parte produce osservazioni;
• cambia il quesito;
• viene svolto un nuovo test.

La relazione integrativa deve indicare:

- documento originario;
- motivo;
- sezioni interessate;
- nuovi materiali;
- modifiche;
- conclusioni aggiornate.

67. Il contraddittorio tecnico

Il contraddittorio non è uno scontro personale.

È un processo attraverso il quale:

• metodo;
• fonti;
• operazioni;
• risultati;
• interpretazioni;

vengono sottoposti alla verifica delle parti.

Una richiesta tecnica efficace è:

“Si chiede di conservare ed esportare l’EVTX originario del canale Security e non soltanto il CSV normalizzato.”

Una richiesta inefficace è:

“Si contesta tutto il lavoro del CTU.”

68. Preparazione alle operazioni peritali

Il CTP dovrebbe predisporre:

- copia del quesito;
- elenco dei reperti;
- domande preliminari;
- rischi di alterazione;
- strumenti;
- supporti;
- richieste;
- checklist;
- nominativi;
- recapiti.

69. Prima riunione peritale

Verificare:

• identità dei presenti;
• reperti;
• sigilli;
• seriali;
• stato;
• account;
• strumenti;
• luogo;
• data e ora;
• fuso;
• operazioni previste;
• output;
• calendario.

Richiedere che il verbale indichi:

• osservazioni;
• riserve;
• anomalie;
• decisioni;
• richieste non accolte;
• motivazioni.

70. Quesito informatico ben formulato

Esempio:

“Accerti il consulente, previa acquisizione forense del dispositivo, se nel database WhatsApp siano presenti i messaggi indicati, ne verifichi identificativi, timestamp, allegati e coerenza con gli screenshot prodotti, indicando i limiti dell’attribuzione personale.”

Meglio di:

“Accerti se la chat è vera.”

71. Richieste del CTP

Possibili richieste:

- immagine forense completa;
- hash;
- copia dei log;
- acquisizione di un canale;
- conservazione del file raw;
- verifica dell’orologio;
- export delle query;
- campioni di riferimento;
- analisi di una fonte alternativa;
- verbale di un errore;
- duplicazione degli output.

La richiesta deve spiegare:

• pertinenza;
• necessità;
• impatto sul quesito;
• metodo proposto.

72. Osservazioni durante le operazioni

Esempio:

“Si osserva che il dispositivo viene montato in modalità lettura-scrittura e si chiede di documentare le modifiche prodotte.”

Esempio:

“Si chiede di acquisire anche il file WAL del database SQLite, potenzialmente contenente transazioni non ancora consolidate.”

Esempio:

“Si chiede di preservare l’output JSON originario prima della conversione in foglio elettronico.”

73. Riserva tecnica

Una riserva dovrebbe indicare:

- operazione;
- ragione;
- rischio;
- richiesta;
- conseguenza.

Esempio:

“Il CTP formula riserva sulla completezza dell’acquisizione logica, poiché il quesito comprende dati cancellati non normalmente disponibili in tale tipologia di estrazione.”

74. Osservazioni alla bozza di CTU

Le osservazioni dovrebbero essere strutturate:

1. punto della bozza;
2. affermazione contestata;
3. fonte;
4. rilievo;
5. impatto;
6. verifica proposta;
7. conclusione richiesta.

75. Modello di osservazione

Titolo

Osservazione n. 4 — Attribuzione dell’account alla persona

Testo

“A pagina 37 la bozza conclude che il sig. X ha effettuato il login. Il record identifica l’utenza x@example e il dispositivo indicato, ma non documenta chi controllasse le credenziali nel momento dell’accesso. Si chiede pertanto di sostituire l’affermazione personale con la formulazione: ‘L’accesso risulta associato all’account x@example’.”

76. Contestazione metodologica

Una contestazione metodologica riguarda:

• acquisizione;
• preservazione;
• tool;
• query;
• campionamento;
• normalizzazione;
• validazione;
• interpretazione;
• limiti.

Non riguarda semplicemente il fatto che il CTP preferisca una conclusione differente.

77. Contestazione dell’acquisizione

Domande:

- è stato identificato il reperto;
- esiste verbale;
- è stato fotografato;
- è stato usato write blocker;
- il dispositivo era acceso;
- quale acquisizione;
- esistono errori;
- esiste hash;
- il file è completo;
- l’originale è conservato.

La copia forense deve essere contestata indicando il difetto concreto.

78. Immagine fisica, file system e acquisizione logica

Non sono equivalenti.

Immagine fisica

Può includere:

• partizioni;
• spazio non allocato;
• dati cancellati;
• strutture file system.

File system extraction

Espone dati accessibili attraverso il file system.

Acquisizione logica

Espone dati resi disponibili dall’API, dal backup o dall’applicazione.

La relazione deve evitare di chiamare “copia completa” un’acquisizione che non comprende spazio non allocato o dati non esposti.

79. Contestazione della catena di custodia

Possibili criticità:

• passaggio non documentato;
• sigillo mancante;
• seriale assente;
• tempi incoerenti;
• supporto non identificato;
• hash non calcolato;
• copia utilizzata non riconducibile;
• file rinominato senza tracciamento.

Non ogni irregolarità documentale dimostra un’alterazione.

Occorre indicare l’impatto:

“La lacuna impedisce di stabilire se il file esaminato coincida con quello originariamente consegnato.”

80. Contestazione dell’hash

Possibili errori:

• algoritmo non indicato;
• hash riferito alla cartella;
• hash di una copia diversa;
• valore incompleto;
• confronto tra oggetti differenti;
• hash calcolato dopo la modifica;
• hash non verificato.

“La discordanza degli hash documenta che i due file non sono identici a livello binario; non identifica quale sia stato modificato.”

81. Contestazione del tool

Domande:

- versione;
- supporto dell’artefatto;
- parser;
- errori;
- licenza;
- configurazione;
- aggiornamenti;
- raw data;
- verifica indipendente;
- falsi positivi.

Una contestazione generica:

“Il software non è affidabile.”

è debole.

Meglio:

“La versione utilizzata non supporta il formato introdotto dalla versione dell’app presente sul dispositivo; il campo timestamp viene interpretato come secondi anziché millisecondi.”

82. Contestazione del report automatico

Verificare:

• filtri;
• timezone;
• elementi esclusi;
• errori;
• categorie;
• righe mancanti;
• esportazione;
• trasformazioni.

“Il report PDF non consente di verificare il record originario; si chiede la produzione del database e della query.”

83. Contestazione della completezza

L’assenza di un dato può dipendere da:

• acquisizione incompleta;
• app non supportata;
• retention;
• cancellazione;
• cifratura;
• filtro;
• query;
• errore;
• sincronizzazione.

“L’assenza del messaggio nell’export non consente di affermare che non sia mai esistito, poiché la fonte acquisita non comprende i dati cancellati.”

84. Contestazione della timeline

Verificare:

- timestamp grezzo;
- epoch;
- fuso;
- ora legale;
- clock drift;
- precisione;
- semantica;
- event time;
- ingest time;
- normalizzazione.

Il Capitolo 29 — Timeline forense approfondisce tali aspetti.

85. Contestazione dell’attribuzione personale

Un’attività può essere associata a:

• account;
• indirizzo IP;
• dispositivo;
• sessione;
• token;
• certificato;
• numero telefonico.

Non automaticamente a una persona.

Possibili alternative:

• credenziali sottratte;
• account condiviso;
• dispositivo lasciato sbloccato;
• accesso remoto;
• amministratore;
• malware;
• sessione rubata;
• sincronizzazione automatica.

86. Contestazione della causalità

Esempio:

A:
pendrive collegata;

B:
file cancellato.

La successione non dimostra che A abbia causato B.

Occorre verificare:

• processo;
• utente;
• file;
• destinazione;
• audit;
• attività del sistema.

87. Contestazione di screenshot e schermate

Uno screenshot documenta la schermata acquisita.

Non documenta automaticamente:

• database;
• file originario;
• URL;
• account;
• cronologia;
• integrità della conversazione;
• contenuti esclusi dal crop.

Richieste:

- file PNG originale;
- dispositivo;
- database;
- contesto;
- video dello scorrimento;
- URL;
- account;
- timestamp.

88. Contestazione di WhatsApp

Per una perizia WhatsApp verificare:

• dispositivo;
• database;
• chiavi;
• ID messaggio;
• mittente;
• destinatario;
• server timestamp;
• allegato;
• stato;
• cancellazione;
• backup.

Un export testuale non è equivalente al database.

Uno screenshot non è equivalente all’allegato.

89. Contestazione di Telegram e Signal

Per Telegram e Signal verificare:

• cloud o database locale;
• chat segreta;
• messaggi effimeri;
• dispositivi collegati;
• account;
• ID;
• sincronizzazione;
• allegati;
• versione dell’app.

90. Contestazione di email

Per email e header richiedere:

• EML;
• MSG;
• header completi;
• Message-ID;
• DKIM;
• Received;
• allegati;
• mailbox;
• audit;
• regole.

Un PDF stampato dell’email perde informazioni tecniche essenziali.

Una firma DKIM valida supporta l’integrità del messaggio rispetto al dominio firmatario, non l’identità fisica del mittente.

91. Contestazione della PEC

Per la PEC verificare:

• messaggio originario;
• ricevuta di accettazione;
• ricevuta di consegna;
• busta;
• gestore;
• firma;
• allegato;
• hash;
• conservazione.

La sola stampa della ricevuta non sostituisce i file PEC originari.

92. Contestazione di PDF e firme digitali

Per PDF, firme digitali e marche temporali verificare:

• struttura;
• aggiornamenti incrementali;
• firma;
• certificato;
• revoca;
• tempo;
• marca;
• trasformazioni;
• oggetti incorporati.

Una firma valida non dimostra la verità del contenuto sottoscritto.

93. Contestazione dei metadati

I metadati possono essere:

• modificati;
• rimossi;
• ereditati;
• riscritti;
• riferiti all’export.

“Il metadato è coerente con la dichiarazione, ma non costituisce una firma o una certificazione autonoma.”

94. Contestazione del recupero dati

Nel recupero di dati cancellati verificare:

• file system;
• stato allocato;
• frammentazione;
• header;
• footer;
• metadata;
• contenuto;
• carving;
• sovrascrittura;
• provenienza.

Un file carved può essere privo di:

• nome;
• percorso;
• data;
• autore;
• struttura completa.

95. Contestazione dell’analisi Windows

Per Windows verificare:

• hive;
• control set;
• EVTX;
• MFT;
• USN;
• Prefetch;
• Amcache;
• SRUM;
• profilo;
• timezone.

Un singolo artefatto non dimostra normalmente l’intera attività.

96. Contestazione di macOS e Linux

Per macOS e Linux verificare:

• APFS/ext;
• Unified Log/journal;
• FSEvents/auditd;
• shell;
• utenti;
• timezone;
• snapshot;
• container;
• file system.

97. Contestazione di smartphone Android

Per Android verificare:

• modello;
• versione;
• patch;
• tipo di estrazione;
• bootloader;
• root;
• app;
• keystore;
• file system;
• database;
• errori.

Un’acquisizione logica può non comprendere:

• dati cancellati;
• cartelle protette;
• chiavi;
• cache;
• spazio non allocato.

98. Contestazione di iPhone e iPad

Per iOS verificare:

• modello;
• versione;
• stato;
• backup;
• full file system;
• escrow;
• keychain;
• cloud;
• app;
• cifratura.

Un backup non equivale a un’acquisizione del file system completo.

99. Contestazione del cloud

Per la cloud forensics verificare:

• tenant;
• account;
• ruolo;
• query;
• API;
• paginazione;
• retention;
• licenza;
• export;
• errori;
• identificativi.

Un CSV cloud rappresenta ciò che la funzione ha restituito secondo configurazione e periodo, non necessariamente ogni evento mai esistito.

100. Contestazione dei log aziendali

Per firewall, VPN e sistemi cloud verificare:

• raw event;
• normalizzazione;
• timezone;
• clock;
• sessione;
• NAT;
• DHCP;
• porte;
• retention;
• collector.

Un indirizzo IP non identifica automaticamente la persona.

101. Contestazione del ransomware

Nel ransomware verificare:

• priorità di contenimento;
• memoria;
• EDR;
• account;
• backup;
• initial access;
• persistenze;
• esfiltrazione;
• gap.

Il primo host osservato non è necessariamente il patient zero assoluto.

102. Contestazione della sottrazione dati

Nel caso di dipendente infedele e USB distinguere:

USB presente
≠
volume montato
≠
file aperto
≠
file copiato
≠
file trasferito
≠
utilizzo esterno
≠
persona responsabile.

103. Contestazione di audio

Per l’autenticità audio verificare:

• generazione del file;
• codec;
• ricodifica;
• waveform;
• spettrogramma;
• rumore;
• continuità;
• app;
• dispositivo;
• riferimenti.

Un click non dimostra automaticamente un taglio.

Una ricodifica non dimostra un montaggio.

104. Contestazione del voice cloning

Per il voice cloning verificare:

• file sorgente;
• replay;
• codec;
• C2PA;
• watermark;
• detector;
• pesi;
• soglia;
• lingua;
• domain shift;
• campioni autentici.

Uno score non rappresenta automaticamente una probabilità.

105. Contestazione di video

Per l’autenticità video verificare:

• contenitore;
• codec;
• frame;
• PTS;
• DTS;
• VFR;
• GOP;
• audio;
• edit list;
• ricodifica.

Un keyframe non dimostra un taglio.

Un frame duplicato non dimostra una falsificazione.

106. Contestazione dei deepfake

Per l’analisi video deepfake verificare:

• file originario;
• face track;
• detector;
• modello;
• dataset;
• preprocessing;
• segmentazione;
• audio-video;
• C2PA;
• watermark.

Il volto rappresentato non identifica l’autore della manipolazione.

107. Contestazione di immagini AI

Per immagini manipolate e generate con AI verificare:

• file camera-original;
• EXIF;
• XMP;
• PRNU;
• CFA;
• JPEG;
• copy-move;
• inpainting;
• detector;
• C2PA.

L’ELA non costituisce una prova autonoma.

108. Tipologie di difetto

109. Impatto del difetto

Critico

Impedisce di collegare l’analisi al reperto.

Esempio:

• file non identificato;
• nessuna catena;
• fonte diversa.

Rilevante

Riduce significativamente la conclusione.

Esempio:

• originale assente;
• acquisizione incompleta;
• clock ignoto.

Limitato

Incide sulla documentazione ma non necessariamente sul risultato.

Esempio:

• refuso;
• nome file errato con hash corretto.

Irrilevante rispetto al quesito

Difetto reale ma senza impatto sulla conclusione specifica.

110. Matrice di contestazione

111. Osservazioni tecniche efficaci

Una buona osservazione è:

• specifica;
• documentata;
• pertinente;
• verificabile;
• proporzionata;
• priva di attacchi personali.

Esempio:

“La conclusione si basa sulla geolocalizzazione dell’indirizzo IP. Tale dato individua in modo approssimativo un’infrastruttura di rete e non la posizione fisica della persona. Si chiede di riformulare la conclusione e di correlare l’evento con dispositivo, sessione e dati del provider.”

112. Osservazioni tecniche inefficaci

Esempi:

“Il CTU è incompetente.”

“Tutti i file digitali possono essere falsificati.”

“Il software può sbagliare.”

“Non siamo d’accordo.”

Queste formule non spiegano:

• l’errore;
• il dato;
• l’impatto;
• la verifica.

113. Preparazione dei chiarimenti

Predisporre una tabella:

114. Domande al CTU o al perito

Esempi:

- Quale file è stato esaminato?
- Quale hash lo identifica?
- La fonte è camera-original o derivata?
- Quale versione del software?
- Sono stati registrati errori?
- Il timestamp è event time o ingest time?
- Come è stato verificato il clock?
- La query è riproducibile?
- Quale dato collega l’account alla persona?
- Quali ipotesi alternative sono state considerate?

115. Preparazione all’udienza

Il consulente dovrebbe conoscere:

• quesito;
• reperti;
• hash;
• strumenti;
• risultati;
• limiti;
• osservazioni;
• risposte alle alternative;
• allegati.

Predisporre:

- relazione;
- indice;
- cronologia;
- glossario;
- tabella quesiti;
- esempi;
- immagini essenziali;
- record originari.

Le best practice SWGDE sulla presentazione delle prove digitali sottolineano la necessità di preparazione tecnica, conoscenza dei metodi e capacità di spiegare i risultati in un procedimento formale. (SWGDE — Best Practices for Personnel Presenting Digital Evidence)

116. Esposizione orale

Rispondere:

• alla domanda posta;
• in modo comprensibile;
• distinguendo fatti e opinioni;
• senza eccedere il proprio ambito;
• dichiarando quando non si sa;
• evitando termini assoluti.

Formule utili:

“Il dato identifica l’account, non la persona fisica.”

“Non dispongo della fonte necessaria per rispondere.”

“La conclusione è compatibile, ma non univoca.”

117. Gestione delle domande ipotetiche

Esempio:

“È possibile modificare un PDF?”

Risposta corretta:

“Sì, in astratto. Per valutare il file del caso occorre verificare struttura, firme, aggiornamenti e provenienza.”

Non:

“Sì, quindi il PDF è falso.”

118. Dimostrazioni in udienza

Una dimostrazione dovrebbe essere:

• preparata;
• ripetibile;
• non invasiva;
• eseguita su copia;
• documentata;
• limitata al quesito.

Evitare:

• demo dal vivo su account reali;
• connessioni a cloud;
• esecuzione di malware;
• apertura di dati estranei;
• dipendenza dalla rete.

119. Tabelle e figure

Le figure devono:

• avere titolo;
• indicare la fonte;
• mostrare il timestamp;
• indicare se derivate;
• evitare crop ingannevoli;
• essere leggibili.

Esempio:

Figura 12 — Record Security.evtx n. 14502
Fonte: reperto RM30-001
Vista derivata mediante tool X
Timestamp originario: ...

120. Oscuramento

Produrre:

• originale;
• copia completa protetta;
• copia oscurata;
• registro degli oscuramenti.

Non oscurare l’unica copia.

Indicare:

- area oscurata;
- motivo;
- strumento;
- data;
- hash della copia.

121. Subconsulenti e collaboratori

Se vengono utilizzati:

• malware analyst;
• fonico;
• linguista;
• esperto video;
• traduttore;
• sviluppatore;

la relazione deve indicare:

• nominativo;
• ruolo;
• attività;
• output;
• responsabilità;
• limiti.

SWGDE richiede di identificare risultati o analisi prodotti da subappaltatori o soggetti esterni. (SWGDE — Requirements for Report Writing)

122. Casi anonimizzati

Un caso precedente può essere citato soltanto:

• in forma anonima;
• quando pertinente;
• senza divulgare dati;
• senza presentarlo come risultato garantito;
• distinguendolo dal caso corrente.

123. Caso pratico 1 — Screenshot WhatsApp in una causa civile

Scenario

Un avvocato di Roma riceve dieci screenshot prodotti dalla controparte.

Contestazione

- nessun dispositivo;
- nessun database;
- immagini ritagliate;
- nessun ID;
- orologio non verificato;
- interlocutore salvato con nome modificabile.

Relazione

“Gli screenshot documentano le schermate rappresentate, ma non consentono di verificare integralmente origine, completezza, identificativi, cancellazioni e corrispondenza col database dell’applicazione.”

Verifica proposta

• acquisizione dei dispositivi;
• database;
• allegati;
• backup;
• confronto.

124. Caso pratico 2 — CTU su computer aziendale

Scenario

Il CTU acquisisce soltanto le cartelle dell’utente.

Il quesito comprende la copia su USB.

Criticità

L’acquisizione non include:

• SYSTEM hive;
• SetupAPI;
• EVTX;
• MFT;
• USN;
• MountPoints2.

Osservazione

“La raccolta non comprende le principali fonti necessarie alla correlazione dei dispositivi USB. La conclusione sull’assenza di collegamenti non può essere sostenuta sulla base del solo profilo documentale.”

125. Caso pratico 3 — Email stampata in PDF

Scenario

Una società romana produce un PDF della casella webmail.

Criticità

Mancano:

• EML;
• header;
• Message-ID;
• DKIM;
• Received;
• mailbox.

Conclusione

“Il PDF documenta la visualizzazione del messaggio nella webmail, ma non consente di ricostruire integralmente il transito o verificare gli header originari.”

126. Caso pratico 4 — Timeline ransomware

Scenario

La relazione attribuisce il primo accesso a un host perché contiene il primo alert EDR.

Criticità

• retention VPN più ampia;
• log email non acquisiti;
• controller di dominio non analizzato;
• alert successivo alla compromissione.

Osservazione

“L’host rappresenta il primo endpoint con alert disponibile, non necessariamente il primo sistema compromesso.”

127. Caso pratico 5 — Dipendente e SharePoint

Scenario

La CTU conclude che il dipendente ha sottratto 5.000 file perché risultano eventi di sincronizzazione.

Criticità

• nuovo laptop aziendale;
• ticket di provisioning;
• sync automatica;
• nessun upload esterno;
• nessun USB.

Conclusione

“Gli eventi sono compatibili con la sincronizzazione autorizzata del dispositivo e non dimostrano autonomamente la fuoriuscita dei dati.”

128. Caso pratico 6 — Audio dichiarato tagliato

Scenario

Un consulente considera un cambio di rumore prova di montaggio.

Verifica

• chiamata VoIP;
• noise suppression;
• packet loss;
• file ricodificato;
• nessun originale.

Osservazione

“La variazione costituisce un indicatore da correlare; la catena telefonica offre spiegazioni tecniche alternative non valutate.”

129. Caso pratico 7 — Detector deepfake

Scenario

Una relazione conclude:

“Video falso al 96%.”

Criticità

• detector online;
• modello ignoto;
• soglia ignota;
• file social;
• nessun originale;
• nessuna analisi per frame.

Osservazione

“Il valore non è interpretabile come probabilità peritale e non consente una conclusione autonoma sull’origine sintetica.”

130. Caso pratico 8 — Clock drift

Scenario

Due log sembrano contraddirsi di quattro minuti.

Verifica

• DVR avanti;
• server NTP corretto;
• misure dello scarto;
• correzione lineare.

Conclusione

“Dopo la normalizzazione, gli eventi risultano temporalmente compatibili.”

131. Caso pratico 9 — Immagine forense incompleta

Scenario

Il consulente analizza un file E01 ma non dispone del secondo segmento.

Criticità

• set segmentato;
• errore di lettura;
• hash incompleto;
• partizione finale assente.

Conclusione

“L’immagine non è completa e non consente di formulare conclusioni sull’intero supporto.”

132. Caso pratico 10 — Hash discordanti

Scenario

La relazione indica un hash differente da quello del file depositato.

Possibili cause

• ricompressione;
• rinomina con modifica;
• versione diversa;
• firma aggiunta;
• errore di trascrizione.

Procedura

1. ricalcolo;
2. identificazione file;
3. confronto dimensione;
4. verifica della versione;
5. relazione integrativa.

133. Caso pratico 11 — Smartphone acquisito dopo settimane

Scenario

Il dispositivo viene acquisito un mese dopo i fatti.

Limiti

• utilizzo successivo;
• aggiornamenti;
• backup;
• cancellazioni;
• sovrascritture;
• sincronizzazioni.

Formula

“Gli artefatti riflettono anche l’utilizzo successivo al periodo di interesse; non è possibile assumere che lo stato acquisito coincida con quello esistente alla data dei fatti.”

134. Caso pratico 12 — Account condiviso

Scenario

L’attività è associata a admin.

Tre persone conoscono la password.

Conclusione

“La fonte documenta l’utilizzo dell’utenza amministrativa condivisa e non consente di individualizzare l’operatore.”

135. Errori da evitare

1. Iniziare senza incarico scritto. Il perimetro resta ambiguo.
2. Accettare un quesito accusatorio. Il tecnico deve tradurlo in domande verificabili.
3. Confondere CTU e CTP. Hanno funzioni differenti.
4. Scrivere come un avvocato. La relazione deve restare tecnica.
5. Formulare qualificazioni giuridiche. Non competono al perito.
6. Esaminare materiali non autorizzati. Si supera il perimetro.
7. Accedere a un account personale. Può essere illecito.
8. Analizzare direttamente l’originale. Si rischia l’alterazione.
9. Non calcolare l’hash. Manca l’identificazione binaria.
10. Calcolare l’hash soltanto alla fine. Non si documenta lo stato iniziale.
11. Non distinguere originali e copie. La catena diventa ambigua.
12. Non registrare i comandi. L’analisi non è riproducibile.
13. Non conservare i log dello strumento. Si perdono errori e parametri.
14. Affidarsi al solo report automatico. Manca il ragionamento.
15. Non indicare la versione del tool. Il risultato può cambiare.
16. Non validare il parser. Può interpretare male il dato.
17. Non verificare manualmente il record decisivo. Il software può sbagliare.
18. Omettere risultati contrari. La relazione diventa parziale.
19. Confondere fatto e deduzione. Si presenta l’interpretazione come record.
20. Usare “prova certa”. La conclusione deve essere proporzionata.
21. Scrivere “autentico” senza definizione. Il termine è ambiguo.
22. Attribuire un account alla persona. Servono elementi ulteriori.
23. Attribuire un IP alla persona. Può essere NAT, VPN o proxy.
24. Attribuire il dispositivo all’utilizzatore. Può essere controllato da terzi.
25. Confondere successione e causalità. A prima di B non prova causa.
26. Considerare l’assenza di log prova negativa. Il logging può essere incompleto.
27. Ignorare il fuso orario. La timeline può essere errata.
28. Aggiungere precisione inesistente. Si crea falsa certezza.
29. Non dichiarare il clock drift. Gli eventi risultano fuori ordine.
30. Non indicare l’acquisizione logica. Si induce a credere che sia completa.
31. Confondere screenshot e database. Sono fonti diverse.
32. Confondere export e sorgente. L’export può perdere dati.
33. Confondere file derivato e originale. La generazione deve essere indicata.
34. Considerare metadati una firma. Sono modificabili.
35. Considerare firma digitale prova della verità. Garantisce altri aspetti.
36. Considerare score detector probabilità. Può non essere calibrato.
37. Usare un solo detector. Può non generalizzare.
38. Non conservare pesi e commit. L’esito non è riproducibile.
39. Caricare dati riservati su servizi pubblici. Si perde il controllo.
40. Allegare interi dataset personali. Viola la minimizzazione.
41. Oscurare l’originale. Si altera il reperto.
42. Non documentare l’oscuramento. La copia non è tracciata.
43. Non numerare gli allegati. Il rapporto diventa difficile da verificare.
44. Non indicare gli hash degli allegati. Non si identificano le versioni.
45. Rinominare file senza registro. Si perde il collegamento.
46. Usare fogli Excel come unica fonte. Possono convertire dati.
47. Non conservare JSON o CSV originari. Si perde la struttura.
48. Ignorare errori e warning. Possono incidere sui risultati.
49. Non dichiarare deviazioni dalla procedura. La relazione appare falsamente standard.
50. Criticare genericamente il CTU. La contestazione deve essere specifica.
51. Attaccare personalmente il consulente. Non aggiunge valore tecnico.
52. Presentare ipotesi astratte. Occorre collegarle al caso.
53. Non proporre verifiche. La critica resta retorica.
54. Presentare troppe osservazioni irrilevanti. Si indeboliscono i punti decisivi.
55. Non rispettare i termini processuali. La valutazione compete al difensore.
56. Inviare osservazioni soltanto al cliente. Devono seguire il canale indicato dal difensore e dal procedimento.
57. Non conservare la bozza ricevuta. Si perde la versione contestata.
58. Non confrontare bozza e finale. Non si verificano le risposte.
59. Non numerare le osservazioni. Il contraddittorio diventa confuso.
60. Non indicare pagina e paragrafo contestati. La critica è difficilmente gestibile.
61. Formulare nuove conclusioni negli allegati. Devono essere nel corpo della relazione.
62. Nascondere i limiti in nota. Devono essere chiari.
63. Confondere impossibilità e assenza. “Non rilevato” non significa “non avvenuto”.
64. Confondere compatibilità ed esclusività. Più ipotesi possono spiegare il dato.
65. Non considerare l’automazione. Un evento può non essere interattivo.
66. Non considerare account condivisi. L’attribuzione personale si indebolisce.
67. Non considerare accessi amministrativi. Il dispositivo può essere stato usato da tecnici.
68. Non distinguere data del file e data dell’evento. Sono concetti diversi.
69. Non distinguere contenuto e contenitore. Vale per audio, video e documenti.
70. Citare standard senza applicarli. Il riferimento non sostituisce il metodo.
71. Dichiarare certificazioni inesistenti. Non inventare qualifiche.
72. Indicare un tool come “riconosciuto dai tribunali”. L’affermazione è impropria e non necessaria.
73. Considerare software commerciale infallibile. Ogni tool ha limiti.
74. Considerare open source inaffidabile per definizione. Conta la validazione del metodo.
75. Non sottoporre il rapporto a revisione. Refusi e incongruenze restano.
76. Correggere silenziosamente una relazione firmata. Serve versione integrativa.
77. Non conservare le versioni. Si perde la storia documentale.
78. Inserire collegamenti esterni non archiviati. La risorsa può cambiare.
79. Non citare la versione del documento tecnico. Le linee guida vengono aggiornate.
80. Conservare dati oltre il necessario. Aumenta il rischio.
81. Distruggere dati prima della chiusura concordata. Può compromettere ulteriori attività.
82. Non definire chi custodisce gli originali. La catena resta incerta.
83. Non indicare la destinazione dei reperti. Il report è incompleto.
84. Scrivere per soli tecnici. Il giudice e il cliente devono comprendere.
85. Semplificare al punto da omettere la base. La conclusione diventa apodittica.
86. Usare screenshot illeggibili. Gli allegati devono essere verificabili.
87. Non associare le figure alla fonte. La provenienza è incerta.
88. Utilizzare demo su sistemi reali. Si creano rischi.
89. Rispondere oltre la propria competenza. Occorre dichiarare il limite.
90. Promettere un esito processuale. La perizia non garantisce la decisione.

136. Procedura operativa completa

Fase 1 — Incarico

[ ] committente;
[ ] difensore;
[ ] ruolo;
[ ] quesito;
[ ] autorizzazione;
[ ] periodo;
[ ] fonti;
[ ] esclusioni.

Fase 2 — Preparazione

[ ] conflitti;
[ ] competenze;
[ ] strumenti;
[ ] laboratorio;
[ ] sicurezza;
[ ] tempi;
[ ] collaboratori;
[ ] privacy.

Fase 3 — Reperti

[ ] ID;
[ ] fotografie;
[ ] seriali;
[ ] verbale;
[ ] sigilli;
[ ] consegna;
[ ] hash;
[ ] custodia.

Fase 4 — Acquisizione

[ ] tipo;
[ ] strumento;
[ ] versione;
[ ] write blocker;
[ ] errori;
[ ] output;
[ ] verifica;
[ ] copia.

Fase 5 — Analisi

[ ] quesiti tecnici;
[ ] fonti;
[ ] parser;
[ ] query;
[ ] timeline;
[ ] correlazioni;
[ ] alternative;
[ ] limiti.

Fase 6 — Documentazione

[ ] case notes;
[ ] comandi;
[ ] log;
[ ] script;
[ ] screenshot;
[ ] output raw;
[ ] manifesti;
[ ] versioni.

Fase 7 — Contraddittorio

[ ] verbali;
[ ] richieste;
[ ] osservazioni;
[ ] riserve;
[ ] risposte;
[ ] output condivisi;
[ ] scadenze;
[ ] corrispondenza.

Fase 8 — Redazione

[ ] frontespizio;
[ ] indice;
[ ] incarico;
[ ] materiali;
[ ] metodo;
[ ] risultati;
[ ] limiti;
[ ] conclusioni.

Fase 9 — Allegati

[ ] indice;
[ ] nomi;
[ ] descrizione;
[ ] SHA-256;
[ ] oscuramenti;
[ ] formati;
[ ] dimensioni;
[ ] supporto.

Fase 10 — Revisione

[ ] tecnica;
[ ] amministrativa;
[ ] riferimenti;
[ ] numerazione;
[ ] allegati;
[ ] privacy;
[ ] conclusioni;
[ ] firma.

Fase 11 — Deposito o consegna

[ ] formato;
[ ] firma;
[ ] busta;
[ ] ricevute;
[ ] esito;
[ ] copia;
[ ] hash;
[ ] comunicazione.

Fase 12 — Conservazione

[ ] custode;
[ ] durata;
[ ] restituzione;
[ ] copia difensiva;
[ ] obblighi;
[ ] distruzione;
[ ] registro;
[ ] chiusura.

137. Checklist finale dell’intero manuale

Incarico

[ ] quesito chiaro;
[ ] autorizzazione;
[ ] perimetro;
[ ] periodo;
[ ] fonti;
[ ] esclusioni;
[ ] ruolo definito.

Reperti

[ ] identificazione;
[ ] verbale;
[ ] fotografie;
[ ] seriali;
[ ] sigilli;
[ ] hash;
[ ] custodia.

Acquisizione

[ ] metodo proporzionato;
[ ] copie;
[ ] write blocker;
[ ] log;
[ ] errori;
[ ] strumenti;
[ ] verifica.

Analisi

[ ] domande tecniche;
[ ] record originari;
[ ] parser validati;
[ ] controllo manuale;
[ ] timeline;
[ ] alternative;
[ ] limiti.

Attribuzione

[ ] account distinto dalla persona;
[ ] IP distinto dalla persona;
[ ] dispositivo distinto dall’utilizzatore;
[ ] automazioni considerate;
[ ] credenziali condivise considerate.

Relazione

[ ] chiara;
[ ] strutturata;
[ ] riproducibile;
[ ] formule prudenti;
[ ] conclusioni collegate;
[ ] limiti visibili;
[ ] allegati indicizzati.

Privacy

[ ] minimizzazione;
[ ] oscuramenti;
[ ] dati di terzi;
[ ] minori;
[ ] contenuti intimi;
[ ] cifratura;
[ ] accessi;
[ ] conservazione.

Deposito

[ ] specifiche correnti;
[ ] firma digitale;
[ ] PDF testuale;
[ ] allegati;
[ ] dimensioni;
[ ] ricevute;
[ ] esito.

138. Output minimo dell’accertamento

1. incarico;
2. provvedimento o autorizzazione;
3. quesito;
4. dichiarazione del ruolo;
5. registro dei reperti;
6. verbale di consegna;
7. fotografie;
8. catena di custodia;
9. hash degli originali;
10. immagini forensi;
11. log di acquisizione;
12. report degli errori;
13. copie di lavoro;
14. inventario delle fonti;
15. strumenti e versioni;
16. comandi;
17. query;
18. script;
19. hash degli script;
20. output originari;
21. output normalizzati;
22. database;
23. report tool;
24. timeline;
25. tabella di clock e timezone;
26. matrice quesito-fonte;
27. matrice delle evidenze;
28. ipotesi alternative;
29. tabella dei limiti;
30. diario delle operazioni;
31. verbali peritali;
32. richieste del CTP;
33. riserve;
34. bozza CTU;
35. osservazioni alla bozza;
36. risposte del CTU;
37. relazione definitiva;
38. relazione integrativa;
39. indice allegati;
40. manifesti SHA-256;
41. versioni oscurate;
42. report firma digitale;
43. ricevute di deposito;
44. registro della conservazione;
45. verbale di restituzione o distruzione.

139. Modello completo di struttura della relazione

139.1 Frontespizio

TRIBUNALE / COMMISSIONE / COMMITTENTE
Procedimento
Parti
Titolo
Autore
Ruolo
Data
Versione
Riservatezza

139.2 Indice

Generato automaticamente e aggiornato.

139.3 Premessa

• incarico;
• nomina;
• finalità;
• ruolo.

139.4 Quesito

• testo integrale;
• traduzione tecnica.

139.5 Autorità e perimetro

• autorizzazione;
• periodo;
• sistemi;
• esclusioni.

139.6 Materiale

• reperti;
• fonti;
• hash;
• stato.

139.7 Cronologia

• consegna;
• operazioni;
• analisi;
• comunicazioni.

139.8 Metodo

• acquisizione;
• strumenti;
• versioni;
• procedure;
• validazioni.

139.9 Risultati

Separati per quesito.

139.10 Discussione

• interpretazione;
• correlazioni;
• alternative;
• elementi contrari.

139.11 Limiti

• tecnici;
• documentali;
• temporali;
• acquisitivi;
• interpretativi.

139.12 Risposte

Una per ogni quesito.

139.13 Conclusioni

Sintetiche e proporzionate.

139.14 Allegati

• indice;
• descrizione;
• hash.

139.15 Firma

• autore;
• data;
• firma digitale.

140. Modelli di frasi tecniche

140.1 Materiale

“L’analisi è stata svolta esclusivamente sui reperti elencati nella sezione 4.”

140.2 Perimetro

“Le conclusioni non possono essere estese alle fonti non acquisite.”

140.3 Hash

“L’impronta SHA-256 documenta l’identità binaria del file esaminato.”

140.4 Limite dell’hash

“L’hash non dimostra l’assenza di modifiche anteriori alla sua acquisizione.”

140.5 Copia forense

“Le operazioni sono state eseguite sulla copia verificata mediante hash.”

140.6 Acquisizione logica

“L’estrazione comprende i dati resi disponibili dalla modalità logica utilizzata e non l’intero contenuto fisico del supporto.”

140.7 Tool

“Il risultato è stato verificato sul record originario e non utilizzato esclusivamente nella rappresentazione automatica del software.”

140.8 Errore

“Lo strumento ha prodotto l’errore indicato, che limita l’analisi della fonte.”

140.9 Compatibilità

“Il dato è compatibile con l’ipotesi descritta, ma non la dimostra in modo esclusivo.”

140.10 Assenza

“L’assenza del record nelle fonti disponibili non dimostra necessariamente che l’attività non sia avvenuta.”

140.11 Account

“L’evento è associato all’utenza informatica e non identifica autonomamente la persona che ne controllava le credenziali.”

140.12 IP

“L’indirizzo IP identifica una connessione nel momento indicato e non automaticamente una persona fisica.”

140.13 Dispositivo

“La presenza dell’artefatto documenta il dispositivo, non l’identità del soggetto che lo utilizzava.”

140.14 Timeline

“La successione temporale non dimostra autonomamente un rapporto causale.”

140.15 Clock

“La timeline conserva il timestamp originario e il valore corretto secondo lo scarto documentato.”

140.16 Screenshot

“Lo screenshot documenta la schermata rappresentata e non sostituisce l’acquisizione della fonte applicativa.”

140.17 Chat

“Il record è presente nel database acquisito e risulta associato all’account indicato.”

140.18 Email

“Il contenuto è stato esaminato nel formato EML con header completi.”

140.19 PEC

“La sequenza è documentata dalle ricevute e dalla busta di trasporto acquisite.”

140.20 Metadati

“Il valore del metadato è coerente con la dichiarazione, ma resta tecnicamente modificabile.”

140.21 File cancellato

“Il contenuto è stato recuperato mediante carving e non conserva un collegamento completo a nome, percorso e timestamp.”

140.22 Cloud

“L’export rappresenta i dati restituiti dal servizio secondo la query, la licenza e la retention applicabili.”

140.23 Audio

“La discontinuità rilevata è compatibile con più processi tecnici e non costituisce una prova autonoma di montaggio.”

140.24 Video

“La presenza del keyframe non dimostra, da sola, un punto di taglio.”

140.25 Detector AI

“Lo score non è stato interpretato come probabilità automatica del singolo reperto.”

140.26 C2PA

“Il manifesto documenta le asserzioni di provenienza firmate nei limiti della relativa catena.”

140.27 Osservazione CTU

“Si chiede di riformulare la conclusione distinguendo l’account dalla persona fisica.”

140.28 Limite

“La mancata disponibilità del dispositivo sorgente riduce la capacità di verificare la provenienza.”

140.29 Primo evento

“Il record rappresenta il primo evento osservato e non necessariamente il primo evento assoluto.”

140.30 Conclusione prudente

“Nei limiti del materiale disponibile, la convergenza degli elementi sostiene maggiormente l’ipotesi indicata, senza escludere le alternative tecnicamente plausibili descritte.”

141. Immagini e figure suggerite

142. Riferimenti tecnici e normativi esterni

1. Codice di procedura civile, articolo 61 — Consulente tecnico.
2. Codice di procedura civile, articolo 191 — Nomina e formulazione dei quesiti.
3. Codice di procedura civile, articolo 193 — Giuramento del CTU.
4. Codice di procedura civile, articolo 194 — Attività del consulente e partecipazione delle parti.
5. Codice di procedura civile, articolo 195 — Relazione, osservazioni e valutazione finale.
6. Codice di procedura civile, articolo 201 — Consulente tecnico di parte.
7. Codice di procedura penale, articolo 230 — Attività dei consulenti tecnici.
8. Codice di procedura penale, articolo 233 — Consulenza fuori dai casi di perizia.
9. Codice di procedura penale, articolo 359 — Consulenti del pubblico ministero.
10. Ministero della giustizia — Albi dei consulenti tecnici e dei periti.
11. SWGDE — Requirements for Report Writing in Digital and Multimedia Forensics.
12. SWGDE — Best Practices for Computer Forensic Examinations, versione 2.0 del 2025.
13. SWGDE — Best Practices for Digital Evidence Collection, versione 2.0.
14. SWGDE — Best Practices for Personnel Presenting Digital Evidence in Legal Proceedings.
15. NIST SP 800-86 — Collection, examination, analysis e reporting.
16. NIST — Definizione di digital forensics e metodi ripetibili.
17. Garante privacy — Linee guida per consulenti tecnici e periti.
18. Garante privacy — Conservazione e sicurezza dei dati peritali.
19. Garante privacy — Regole deontologiche per investigazioni difensive e tutela giudiziaria.
20. Ministero della giustizia — Portale dei Servizi Telematici e deposito degli atti.
21. Specifiche tecniche del processo telematico pubblicate dal PST.
22. Decreto ministeriale n. 110/2023 — Criteri di redazione degli atti giudiziari.

143. Collegamenti interni consigliati

Capitolo precedente

• Timeline forense e ricostruzione cronologica degli eventi

Indice del manuale

• Manuale operativo di informatica forense a Roma

Capitoli correlati

• 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
• Metadati, EXIF, XMP, C2PA e provenienza dei file
• Verifica forense di screenshot e schermate
• Acquisizione di pagine web, social e contenuti online
• Diffamazione online, cyberbullismo, stalking digitale e revenge porn
• Accessi abusivi ad account email, social e cloud
• Truffe online, bonifici fraudolenti e financial cybercrime
• Analisi di log aziendali, firewall, VPN e sistemi cloud
• Incident response forense e ransomware
• Dipendente infedele, sottrazione dati e uso di USB
• Cloud forensics: Google, Microsoft, Dropbox e backup
• Autenticità audio: tagli, montaggi e ricodifiche
• Voice cloning e audio generati con intelligenza artificiale
• Autenticità video: frame, codec, tagli e montaggi
• Analisi video deepfake e face swapping
• Immagini, fotografie manipolate e contenuti generati con AI

144. Pagine servizio consigliate

/servizi/perizia-informatica-forense-roma/
/servizi/consulente-tecnico-parte-informatico-roma/
/servizi/analisi-smartphone-computer/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/incident-response-forense/
/servizi/acquisizione-pagine-web-social/
/contatti/

Anchor text consigliati

CTP informatico a Roma
relazione tecnica informatico-forense
consulente tecnico di parte informatico
osservazioni alla CTU informatica
contestazione delle prove digitali
perizia informatica di parte
analisi critica di una consulenza tecnica
contraddittorio tecnico informatico
verifica di una copia forense
contestazione di screenshot e chat
contestazione di email e file digitali
supporto tecnico al difensore
consulente informatico forense per cause civili e penali a Roma

[ ] consulenza tecnica di parte;
[ ] analisi preliminare del fascicolo;
[ ] formulazione del quesito tecnico;
[ ] partecipazione alle operazioni di CTU;
[ ] verifica delle acquisizioni;
[ ] controllo di copie forensi e hash;
[ ] osservazioni alla bozza del CTU;
[ ] note critiche;
[ ] relazione tecnica stragiudiziale;
[ ] relazione informatico-forense;
[ ] contestazione di screenshot;
[ ] contestazione di chat e WhatsApp;
[ ] contestazione di email e PEC;
[ ] contestazione di log e timeline;
[ ] contestazione di audio e video;
[ ] contestazione di deepfake e contenuti AI;
[ ] preparazione di chiarimenti tecnici;
[ ] assistenza al difensore;
[ ] supporto in udienza.

146. Conclusione del capitolo

Una relazione tecnica informatico-forense non è una raccolta di screenshot.

Non è il PDF prodotto automaticamente dal software.

Non è una dichiarazione di certezza.

Non è una memoria legale scritta da un tecnico.

È il risultato documentato di una catena:

incarico
→ autorizzazione
→ reperto
→ acquisizione
→ integrità
→ esame
→ analisi
→ interpretazione
→ limiti
→ conclusione

Il CTP informatico deve comprendere gli interessi della parte, ma non può modificare il significato dei dati.

Il CTU deve rispondere al giudice, ma deve permettere alle parti di comprendere e verificare le operazioni.

Il perito deve usare strumenti adeguati, ma non può delegare al software il ragionamento.

La contestazione deve essere ferma, ma non generica.

La conclusione deve essere utile, ma non più forte delle fonti.

Formula da ricordare: una buona relazione consente di distinguere ciò che è stato osservato, ciò che è stato dedotto, ciò che resta possibile e ciò che non può essere determinato.

Una relazione tecnicamente corretta deve indicare:

- chi ha conferito l’incarico;
- quale autorità consente l’esame;
- quale quesito è stato posto;
- quali reperti sono stati acquisiti;
- quali hash li identificano;
- quali strumenti sono stati utilizzati;
- quali operazioni sono state eseguite;
- quali risultati sono verificabili;
- quali ipotesi sono state considerate;
- quali limiti incidono;
- quali allegati consentono il controllo;
- quale conclusione è proporzionata.

Una contestazione tecnicamente corretta deve indicare:

- l’affermazione contestata;
- il dato sul quale si basa;
- il difetto;
- l’impatto;
- la fonte alternativa;
- il controllo proposto;
- la formulazione corretta.

Il compito del consulente non è trasformare ogni dubbio in una certezza.

È rendere il dubbio:

• definito;
• verificabile;
• tecnicamente spiegato;
• proporzionato;
• utile alla decisione.

147. Conclusione del Manuale operativo di informatica forense a Roma

I trenta capitoli del manuale descrivono un percorso unitario:

triage
→ catena di custodia
→ acquisizione
→ analisi dei sistemi
→ smartphone
→ messaggistica
→ dati cancellati
→ email e documenti
→ web e cloud
→ incident response
→ audio, video e AI
→ timeline
→ relazione tecnica

Nessun capitolo dovrebbe essere applicato isolatamente.

Una chat può richiedere:

• acquisizione dello smartphone;
• verifica del database;
• analisi degli allegati;
• controllo del cloud;
• timeline;
• relazione.

Un ransomware può richiedere:

• memoria;
• endpoint;
• log;
• account;
• backup;
• cloud;
• data breach;
• rapporto tecnico.

Un deepfake può richiedere:

• acquisizione web;
• file originario;
• audio;
• video;
• C2PA;
• account;
• timeline;
• contestazione tecnica.

Metodo comune dell’intero manuale: preservare prima di interpretare, documentare prima di concludere e dichiarare sempre i limiti dell’accertamento.