DIGITAL FORENSICS

Gabriele Faggioli
Andrea Ghirardini
© Apogeo - IF - Idee editoriali Feltrinelli s.r.l.
Socio Unico Giangiacomo Feltrinelli Editore s.r.l.

ISBN edizione cartacea: 9788850331994

IF - Idee editoriali Feltrinelli srl, gli autori e qualunque persona o società coinvolta nella scrittura,
nell’editing o nella produzione (chiamati collettivamente “Realizzatori”) di questo libro (“l’Opera”)
non offrono alcuna garanzia sui risultati ottenuti da quest’Opera. Non viene fornita garanzia di
qualsivoglia genere, espressa o implicita, in relazione all’Opera e al suo contenuto. L’Opera viene
commercializzata COSÌ COM’È e SENZA GARANZIA. In nessun caso i Realizzatori saranno
ritenuti responsabili per danni, compresi perdite di profitti, risparmi perduti o altri danni accidentali
o consequenziali derivanti dall’Opera o dal suo contenuto.

Il presente file può essere usato esclusivamente per finalità di carattere personale. Tutti i contenuti
sono protetti dalla Legge sul diritto d'autore.

Nomi e marchi citati nel testo sono generalmente depositati o registrati dalle rispettive case
produttrici.

L'edizione cartacea è in vendita nelle migliori librerie.

Sito web: www.apogeonline.com

Seguici su Twitter @apogeonline

 Prefazione

Sì, il mondo sta cambiando. Questo è vero in generale, ovviamente, ma lo si nota anche nel
piccolo e speciale ecosistema costituito dalle discipline forensi. Certo non lo si sente nella terra
e nell’acqua, come memorabilmente diceva Fangorn (no, non Galadriel: andate a rileggervi il
libro!) ma basta accendere la televisione dopo cena per accorgersene.
Infatti, scemato ormai il successo dei Grandi Fratelli e delle Isole dei Famosi, e cavalcando
invece l’onda dei vari CSI d’oltreoceano e relativi surrogati nostrani, i morbosi interessi
catodici del grande pubblico sono adesso sempre più appagati da innumerevoli trasmissioni che
fanno delle pagine di cronaca, soprattutto quella nera, il più attraente dei reality. Proliferano
così non solo fiction incentrate su poco credibili investigatori scientifici di questa o quella forza
di polizia, ma soprattutto programmi di scarso approfondimento basati sulla presenza in studio
di improbabili esperti e avvocati showmen che, con l’accondiscendente complicità di conduttori
spesso più imbarazzanti che imbarazzati, discettano tuttologicamente sull’ultimo caso di efferato
omicidio o sequestro di persona in una sorta di tribunale virtuale, parallelo a quello reale ma
mediaticamente assai più accattivante.
Sembra dunque che gli italiani, oltre a essere da sempre valenti commissari tecnici della
nazionale e perfetti presidenti del Consiglio, da qualche tempo a questa parte si siano anche
scoperti tutti esperti criminologi. E così discipline in precedenza oscure ed emarginate come
l’anatomopatologia o la balistica sono divenute da un giorno all’altro conoscenze di uso
quotidiano, mentre le tecniche di profiling sono ormai oggetto di discussione da bar e il codice
di procedura penale è assurto ad amena lettura da comodino delle casalinghe non solo di
Voghera.
Un effetto positivo di questa piccola grande rivoluzione nei costumi televisivi nazionali è
stato quello di aver contribuito a diffondere estesamente la conoscenza dei principi e delle
tecniche di investigazione scientifica, che oggigiorno costituiscono un supporto sempre più
importante agli inquirenti soprattutto nelle indagini complesse. E, manco a farlo apposta, a
godere di questa improvvisa e inaspettata notorietà è stata soprattutto la Digital Forensics
(traducibile solo approssimativamente con “informatica forense”): proprio la più giovane fra le
discipline di indagine tecnica che, assolutamente sconosciuta ai più fino a solo pochissimi anni
fa, è oggi nota a tutti almeno nei suoi principi generali di applicazione riguardanti, con grande
semplificazione concettuale, gli accertamenti tecnici fatti su computer, memorie, cellulari e reti
di comunicazione.
Sono tuttavia da addebitare a questa moda anche diversi aspetti negativi, che a detta di molti
superano di gran lunga quelli positivi. In primo luogo si è avuto il fenomeno della mitizzazione
del ruolo del tecnico, il quale viene percepito come quantomeno cruciale se non addiritura unico
responsabile della corretta soluzione del caso, in contrapposizione e soprattutto a scapito dei
ruoli e dei metodi investigativi tradizionali. In secondo luogo si è invece banalizzata la
disciplina stessa, diffondendo la convinzione che tutto sia ormai facile e alla portata di
chiunque: basta avere un po’ di software idoneo (che tanto si trova su Internet...) e qualche
conoscenza informatica di base per poter fare il forensic examiner come e meglio dei poliziotti
dei telefilm. La realtà è che le indagini tecniche sono solo un supporto al processo di
accertamento della verità, utile e importante ma quasi mai esclusivo; e che i metodi e le tecniche
tradizionali di investigazione, ivi compreso un sano buon senso, sono sempre preponderanti
rispetto ai meri risultati degli accertamenti tecnici. Ma l’equivoco purtroppo permane, e anzi si
acuisce ogni giorno di più.
A fare le spese di tali errate concenzioni è soprattutto la nostra amata Digital Forensics,
disciplina che viene vista da molti come più “facile” rispetto alle sue cugine anziane in quanto
apparentemente non richiede conoscenze troppo specialistiche (basta “capire un po’ di
computer” e il gioco è fatto!). Ciò a sua volta ha dato origine a due fenomeni estremamente
negativi, che stanno purtroppo generando pericolose ripercussioni pratiche nel funzionamento
già precario del nostro sistema giudiziario.
In primo luogo si nota una crescente e preoccupante tendenza nei magistrati inquirenti a
sopravvalutare sempre più l’importanza a fini investigativi degli accertamenti informatici, anche
a scapito dell’analisi di altre prove “tradizionali”; un po’ come fanno taluni medici moderni che
tendono purtroppo a visitare meno i pazienti preferendo far loro effettuare una serie di
accertamenti clinici strumentali. (Esempio tratto dall’esperienza personale: qualche anno fa fui
chiamato da un P.M. che indagava su una reciproca denuncia per lite violenta tra due coniugi,
ciascuno dei quali sosteneva di essere stato provocato dall’altro; siccome durante l’alterco lui
aveva lanciato contro di lei il suo computer portatile, che oltretutto si era danneggiato nell’urto,
il P.M. intendeva disporre una perizia informatica sul computer pensando così di poter
ricostruire il reale andamento dei fatti e stabilire chi avesse ragione! Ovviamente rifiutai
l’incarico...)
In secondo luogo, come diretta conseguenza di ciò, la crescente richiesta di perizie d’ufficio
ha fatto espandere troppo rapidamente il mercato dei consulenti tecnici del giudice, che ha così
inevitabilmente finito per popolarsi anche di operatori improvvisati e talvolta poco seri, che si
sono buttati a pesce nel nuovo business senza tuttavia possedere le reali capacità e l’esperienza
che sarebbero necessarie per poter espletare a dovere un impiego così delicato. E purtroppo la
non-cultura informatica così diffusa nel nostro Paese presso chi ha una formazione umanistica fa
sì che spesso i giudici e i pubblici ministeri non siano in grado di distinguere tra i consulenti
davvero preparati e quelli semplicemente opportunisti, i quali tuttavia con il loro maldestro
operato rischiano di orientare in modo errato e a volte tragico l’esito delle indagini. (Esperienza
personale: quante volte capita che in udienza il giudice o il P.M. esordiscano dicendo al perito
“cerchi di spiegarsi bene perché di computer non ci capisco niente!” o addirittura si vantino di
non saperlo neppure accendere...)
La realtà è che la nostra povera Digital Forensics, la più giovane e incompresa tra le
discipline forensi, è anche forse la più complessa e delicata: essa infatti unisce le difficoltà
dell’investigazione a quelle tipiche dell’informatica, con tutte le complicazioni e incertezze che
ben conosciamo. Il tutto, ricordiamolo bene, in un ambito di attività che in più fa ricadere sulla
testa del consulente anche importanti profili di responsabilità, sia legale sia morale, relativi al
proprio operato.
Perdipiù il panorama è confuso per via della giovane età della disciplina, che è tutt’ora priva
di un rigoroso inquadramento tecnico-giuridico e soffre della mancanza di protocolli e linee
guida unanimemente condivisi dalla comunità internazionale di esperti. Non aiuta il fatto che
l’informatica stessa abbia percorso passi da gigante negli ultimi anni, trasformandosi in una
sorta di bersaglio mobile impossibile da ingabbiare in regole e procedure fisse. Tanto per dire:
gli accertamenti sulle impronte digitali esistono da oltre un secolo, nel corso del quale le
tecniche si sono evolute e affinate ma i concetti di base non sono mutati; a paragone, invece, nei
soli ultimi dieci anni l’informatica e le TLC hanno subìto tante di quelle rivoluzioni,
nell’hardware e nel software, da rendere obsolete diverse generazioni di sistemi. È chiaro che
in queste condizioni è difficile riuscire a mantenere il diritto e la prassi allineati all’evoluzione
della tecnica.
Tanti anni fa, agli albori della Digital Forensics, non c’era tanta esperienza e non c’erano tool
sofisticati ma, in fondo, non servivano nemmeno: il mondo era più semplice, i sistemi più facili
da analizzare e le esigenze meno complesse. Con un buon debugger e un compilatore C si poteva
fare tutto ciò che serviva, a patto di essere bravi, esperti e, d’accordo, molto pazienti! Oggi
invece è tutto dannatamente più complicato: le quantità di dati a disposizione di chiunque sono
strabilianti, mentre i sistemi sono talmente complessi da sfuggire all’analisi dei loro stessi
creatori (provate a risalire al vero motivo di un crash di Windows...).
Ecco dunque perché oggigiorno è necessario, in questa più che nelle altre discipline forensi,
disporre di una guida di riferimento che sia completa, esaustiva e soprattutto aggiornata. Nel
mondo moderno chi si ferma è perduto, perché la tecnica va avanti a passi veloci. Se, tanto per
fare un esempio terra terra, il massimo che poteva capitare a un perito cinque anni fa era dover
acquisire e analizzare un hard disk IDE da 80 GB, oggi molto verosimilmente egli si troverà di
fronte a uno storage di rete da qualche TB in RAID: una storia completamente diversa. Per non
parlare di cose come cloud, virtualizzazione e via dicendo, che stanno ormai diventando la
norma più che l’eccezione.
Era dunque attesa una nuova edizione di questo ormai classico lavoro di Andrea “Pila”
Ghirardini e Gabriele Faggioli, il primo testo sulla Digital Forensics pubblicato in Italia da
italiani, divenuto ben presto un riferimento per gli addetti ai lavori. Dalla sua prima uscita a
oggi sono passati sei anni, un’era geologica in termini informatici. I contenuti sono dunque stati
aggiornati e ampliati ma l’impostazione è rimasta quella originale, utilmente caratterizzata da
diverse chiavi di lettura: da quella strettamente tecnica a quella giuridica e legale, senza
tralasciare una divertente e istruttiva carrellata di casi curiosi tratti dalla pluriennale esperienza
sul campo di Andrea, che è effettivamente stato uno dei primi forensic analyst professionisti del
nostro Paese.
Personalmente tengo molto alla divulgazione culturale dell’informatica, sia nella sua
accezione generale sia nelle sue applicazioni verticali, e credo che questo libro ne sia un ottimo
esempio per quanto riguarda la disciplina di cui tratta. Secondo me sbaglia chi ritiene che
l’informatica sia una disciplina solo tecnica, priva di risvolti umanistici: ma sbaglia ancor di
più chi ritiene tale la Digital Forensics. In essa infatti l’analista non è solo un tecnico di
laboratorio o, ancor peggio, un semplice strumento nelle mani del magistrato: è invece (o
dovrebbe essere) un supporto al giudice il quale, pur essendo per definizione il peritus
peritorum, non può (e neppure deve) essere esperto in ogni branca della scienza. Il consulente o
perito deve quindi supportare il magistrato nel processo di accertamento della verità sin dal
momento della formulazione dei quesiti, agendo sempre in modo neutro e asettico ma non
acritico, discutendo eventualmente le linee di indagine, e stilando infine una relazione che sia
non solo completa, onesta, oggettiva e veritiera, ma anche chiara e comprensibile soprattutto ai
profani. Il tutto mantenendo sempre il proprio ruolo senza travalicarne i confini, perché compito
del perito non è quello scrivere al giudice la sentenza ma solo quello di fornirgli con la massima
chiarezza tutte le informazioni necessarie affinché egli possa giungere alle giuste conclusioni
secondo il proprio libero convincimento.
Ma soprattutto l’analista dovrebbe tenere sempre presente che la sua attività, per quanto
esoterica e interessante, non è un bel gioco per geek ma un compito delicato e gravato di
responsabilità, nel quale un errore o una leggerezza possono, nei casi più gravi, significare il
rilascio di un colpevole o, peggio, la condanna di un innocente. Bit e byte sono oggetti virtuali e
impalpabili, ma non per questo meno “pesanti” di una traccia di DNA o di un’impronta sul luogo
del delitto quando costituiscono un’evidenza a supporto di un capo d’accusa: solo, sono molto
meno “leggibili” dal giudice, che quindi si affida totalmente alle conclusioni del perito.
Purtroppo mi è capitato troppe volte di vedere innocenti rischiare condanne etremamente severe
a causa di una perizia d’ufficio fatta male. La corretta formazione di un analista non può
prescindere anche da questo ordine di considerazioni.
Corrado Giustozzi
Roma, ottobre 2013
 Introduzione

I dati non sono più dove ci si aspettava

che fossero

... Quando qualche anno fa parlai per la prima volta di Digital Forensics a una conferenza italiana, notai delle espressioni di
compatimento, tipo quelle che di solito si riservano a un parente noto per non essere troppo sano di mente e che, nel mezzo
di un matrimonio, si lancia in una delle sue filippiche. Un magistrato mi disse che se mi interessava questo campo avrei
dovuto “andarmene in America”. Inutile dire che quella conferenza non va annoverata tra i miei successi...

Quando l’editore mi ha chiesto di pensare alla terza edizione del libro, per prima cosa ho
riletto l’edizione precedente da zero. Pur contenendo principi e metodologie che rimangono
tutt’ora validi (per fortuna!), il testo sembra scritto in un’altra era.
Solo dopo questa analisi mi sono reso conto di quanto sia cambiato il mondo dell’informatica
in così pochi anni.
L’uomo della strada ha sentito più volte il termine cloud, e probabilmente non ha il concetto
così chiaro nella propria mente. Il tecnico magari ha pensato all’inizio che “cloud” fosse solo
una ripacchettizzazione di molte tecnologie sotto un nuovo nome più attrattivo a livello di
marketing.
Invece è stata davvero una rivoluzione culturale. Ed è stata così silenziosa e pervasiva che in
poco tempo tutti noi ci siamo trovati a usare paradigmi nuovi senza nemmeno accorgercene.
E così il mondo è cambiato e noi ci siamo sorpresi nel duplice ruolo di spettatori e
consumatori a vedere tramontare un’era, quella dell’informatica personale.
Questo libro è stato scritto per intero tramite un PC in cloud (Iaas), una suite OpenOffice
installata sotto EyeOS (Iaas), ascoltando musica in streaming tramite Google Music (Saas) e
sfruttando come device di data entry una decina di sistemi diversi tra cui notebook, sistemi
desktop, workstation Unix, tablet e cellulari.
Apple con iPhone e iPad ha lanciato su scala mondiale una rivoluzione. Chi ha potuto ha
inseguito e cercato di giocarsela ad armi pari (Google con Android), altri sono arrivati
tardivamente (Microsoft con Windows RT e Windows Phone) pur con prodotti apprezzabili;
altri sono collassati pur essendo stati i leader precedenti (RIM, Palm e Nokia).
La profezia di Gates, che sostiene che nessun leader di un’era informatica ha mai dominato
anche la successiva, si è dimostrata ancora una volta drammaticamente vera.
Se questo incipit può sembrare fuori tema rispetto a una pubblicazione che parla di Digital
Forensics, si rifletta sulle implicazioni di questa rivoluzione.
 I sistemi personali e aziendali stanno subendo una notevole trasformazione, trasferendosi su
fronti totalmente opposti.
Vi è chi ha deciso di esternalizzare tutto, spostando quanto possibile in cloud decentrati, e chi
invece ha seguito l’idea di accorpare tutto il possibile in sistemi cloud privati dove client e
server sono virtualizzati e dove i dati risiedono tutti su SAN o NAS che servono centinaia di
sistemi.
Qualunque sia la strada intrapresa il risultato è sempre lo stesso: i dati non sono più dove ci
si aspettava che fossero.
Senza entrare in un ambito enterprise facciamo un esempio banale. Tutta la musica che avevo
in casa è passata dal supporto fisico (CD) al file (MP3), per poi essere stata trasferita nella sua
interezza su Google Music (circa 30 GB). Tutta la mail è passata da un account tradizionale
gestito tramite POP3 su un MacBook, a un servizio cloud (Gmail). Le fotografie sono state
caricate su un server privato virtuale con ownCloud.
I documenti sono gestiti tramite Google Drive e Google Docs, o al limite tramite OpenOffice
su EyeOS su un server privato.
Certo, ho ancora a casa un piccolo datacenter (è indispensabile per fare analisi forense) ma la
maggior parte dei miei dati non è più né su un server né su un NAS all’interno della mia rete.
L’accesso a tutte queste informazioni avviene tramite dispositivi leggeri (tablet e
smartphone), apposite app o attraverso servizi web.
Anche la parte di analisi forense è passata da una serie di file/application server fisici a un
cluster di due workstation HP e di uno storage Synology che mi esporta i volumi condivisi via
iSCSI. Programmi, tool, macchine specializzate, sono tutti installati su una serie di Virtual
Machine KVM gestite da due nodi Proxmox VE.
A dispetto di quanto qualcuno possa pensare io, pur essendo un appassionato di tecnologia,
non sono certo un early adopter, anzi tendo a essere piuttosto conservativo, almeno con le mie
cose.
Per quanto riguarda le organizzazioni che seguo nel mio lavoro di tutti i giorni, posso
affermare che ormai nessuno mi chiede più un deploy su server fisico. I vantaggi di una struttura
virtuale sono tali e tanti che è del tutto normale virtualizzare tutto il back-end, e molti sono i
progetti in cantiere per fornire servizi terminal e VDI al fine di eliminare i PC dalle scrivanie.
Tutto questo ha un fortissimo impatto nel mondo della Digital Forensics. Ho la netta
sensazione di essere tornato ai primi anni dopo il 2000, quando il campo era pionieristico e non
vi erano tool adatti ad affrontare le situazioni che si ponevano di fronte all’investigatore che si
accingeva ad affrontare la materia.
Certo, ora ci sono molto ottimi pacchetti commerciali, come X-Ways Forensics, FTK, Encase
(continuo a mal sopportarlo ma è uno standard de facto), ma al momento sono tutti fermi al
concetto di fonte di prova che risiede, perlomeno, su supporto fisico.
 Molti di questi pacchetti ora supportano l’analisi di macchine virtuali gestite dagli hypervisor
più comuni ma difettano totalmente nella gestione di un’indagine che includa elementi forniti
tramite un servizio di tipo cloud.
Anche il fronte mobile presenta seri problemi. In questi anni ho avuto modo di apprezzare
strumenti quali UFED di Cellbrite o Oxygen Forensics Suite. Ma per quanto dotati di un ottimo
supporto e di funzioni molto potenti questi strumenti esaminano i terminali mobili a livello di
supporto. Permettono di estrarre immagini, SMS, MMS, e-mail, contatti, artifact nella cache del
brower, dati e file cancellati, ma peccano miseramente sia nell’analisi dei dati delle varie app
presenti sul dispositivo (e non può essere altrimenti, visto che esistono centinaia di migliaia di
app per ognuno dei top player del mercato) sia nell’analisi dell’iterazione delle app con i server
di back-end presenti in cloud.
Per rendere il quadro più veritiero non si può non parlare di quanto sta accadendo lato back-
end o a livello di datacenter. Il deployment massivo di macchine virtuali (che si tratti di
macchine private o di servizi di public cloud) ha di fatto ridisegnato tutta la logica dei servizi
server. Non si trovano più decine e decine di server specializzati. Troviamo piuttosto macchine
con due o quattro processori multicore, con capacità di memoria RAM nell’ordine (per gli
ultimi modelli presenti sul mercato all’atto della scrittura di questo libro) di 768 GB o di 1,5
TB.
Un sistema blade può contenere in 10 U fino a 18 server, con 288 core totali e 13,5 TB di
RAM. Presupponendo di infilare due sistemi blade e uno storage in un singolo Rack 42U, si può
ben immaginare come si possa disporre della potenza di calcolo necessaria per gestire un paio
di migliaia di server virtuali.
Infrastrutture di questo genere non si possono affrontare con i comuni strumenti di analisi
forense. Le normali metodologie di acquisizione e analisi non si possono applicare in ambienti
di questo genere. Si può tranquillamente dire addio alle tradizionali acquisizioni effettuate
tramite il boot di una Live distro come DEFT o CAINE. Vi sono problemi legali (il datacenter si
può trovare all’estero, l’infrastruttura può essere contenuta all’interno di un tenant in un cloud
pubblico, i dati possono risiedere all’interno di un servizio PaaS o SaaS condiviso con migliaia
di altri utenti non oggetto di indagine, il contenuto può essere a sua volta fornito da una CDN che
risponde in maniera diversa a seconda del paese di origine del fruitore del servizio),
procedurali (affrontare uno storage da 2 PB richiede metodi mai esaminati finora) e
metodologici (estrarre i dati da un database condiviso tra migliaia di utenze, recuperare i dati da
uno snapshot e sfruttare un datacenter in disaster recovery geografico richiedono nel contempo
fantasia, adattabilità ma anche un rigore ferreo per rispettare tutte le normative).
Normalmente quando inizio a trattare queste problematiche nei corsi tenuti da IISFA, vedo
facce sempre più sgomente. Purtroppo non si parla di fantascienza, quanto piuttosto di una realtà
presente e pervasiva.
 Nel prossimo futuro aleggia già lo “spettro del Big Data”. Ho avuto modo di ascoltare il
dottor Joseph Reger, CTO di Fujitsu, al Fujitsu Forum 2012 a Monaco. È il secondo anno che
seguo con molta attenzione il suo intervento. Non sarà tra i più noti guru dell’informatica ma ho
già avuto modo di apprezzare il suo acume e le sue doti di preveggenza in relazione ai trend
dell’informatica attuale e futura. Parlando della sicurezza dei dati nel prossimo Big Cloud ha
espresso questo concetto:
Qualcuno potrebbe pensare che depositare petabyte e petabyte di dati in un unico punto renda più facile gestire la loro
sicurezza. Obiettivamente solo il tempo di trasferimento in un’altra locazione da parte di un attacker rende un furto
tradizionale praticamente impossibile. Ma è bene considerare un fattore. Possedere miliardi di informazioni provenienti da
fonti diverse ma ricercabili tramite un sistema strutturato quale potrebbe essere un database a oggetti, hash table, object file
system o altro, può permettere una cosa del tutto nuova, ovvero il furto di informazioni che nemmeno si sa di possedere.
Perché ciò che importa in questi ambiti non è tanto il dato grezzo ma la capacità di correlare tra loro le diverse informazioni.

(A questo punto deve essermi sfuggita un’imprecazione ad alta voce dato che le persone a me
vicine si sono girate a guardarmi con aria torva.)
Alla luce di questa rivelazione non ho potuto non pensare al fatto che in Italia la legge
48/2008 sia arrivata con sette anni di ritardo rispetto alla conferenza di Budapest del 2001 che
ne aveva fissato i principi, che ancora i giudici fatichino a capire il concetto di furto di un file
se non legato a un supporto fisico, e al fatto che la nostra professione come specialisti di quella
che è una disciplina (per quanto bistrattata) della polizia scientifica non sia ancora riconosciuta
a livello di codice penale (e che quindi ci costringe a essere pagati meno di una donna delle
pulizie e per di più con tempi biblici). In questa situazione l’idea di entrare in un’aula di
tribunale e dover spiegare che l’attacker ha sottratto della conoscenza che il possessore dei dati
neanche sapeva di avere è cosa degna di un romanzo di fantascienza.
Ci avviamo verso un mondo dove le informazioni sono distribuite, universalmente accessibili
e salvate nel back-end in grandi datacenter dove, nel contempo, sono riversate informazioni
provenienti da migliaia di utenti e fonti diverse. La fine dell’informatica personale e l’inizio di
quella pervasiva e accentrata.
Andrea Ghirardini
CTO BE.iT
 Struttura del libro

Oltre al solito compendio su come muoversi nel panorama della Digital Forensics
tradizionale, troverete molte riflessioni, dubbi e stimoli per ricercare nuove soluzioni ai
problemi che via via ci verranno posti nel corso del prossimo futuro.
Per molte cose ammetto che non ho una risposta definitiva. Siamo, di nuovo, in un periodo in
cui la Digital Forensics torna a essere una scienza di frontiera. Un periodo dove molto è lasciato
alla conoscenza approfondita e alla capacità di adattamento del singolo. Sicuramente ci si
porranno delle sfide stimolanti dove sarà necessario ripensare a nuovi tool e metodi per poter
gestire situazioni completamente nuove e, per certi versi, contrarie a quelle trovate finora sul
campo.
Il volume si compone di 18 capitoli. La lettura sequenziale è consigliata ma non obbligatoria:
essendo il volume pensato non tanto come la “Bibbia della Digital Forensics” quanto come uno
strumento per valorizzare le proprie competenze informatiche nella prassi investigativa, ogni
lettore è libero di focalizzarsi sulle parti più attinenti alle proprie necessità che, come ogni
Digital Forensics expert sa bene, variano da caso a caso.
Dopo il Capitolo 1, scritto per fare luce su alcuni concetti base, con il Capitolo 2 si presenta
una panoramica sulla situazione giuridica italiana inerente la materia.
I Capitoli 3 e 4 sono quindi dedicati all’importante fase dell’acquisizione del dato, mentre il
Capitolo 5 apre le porte del laboratorio del Digital Forensics expert.
Nei Capitoli 6 e 7 si apre invece un’ampia parentesi sull’analisi dei file system, su cui si
concentra buona parte della prassi investigativa.
Con i Capitoli 8, 9 e 10 si ritorna invece all’illustrazione di importanti strumenti di lavoro.
Giunti a questo punto, il Capitolo 11 propone una metodologia di analisi generale.
I Capitoli 12, 13 e 14 sono rispettivamente dedicati all’analisi dei sistemi Windows, OS X e
Linux.
Il Capitolo 15 tratta la gestione e l’analisi dei file di log.
In conclusione, i Capitoli 16, 17 e 18 affrontano le parti più avanzate, ivi comprese la
virtualizzazione e il cloud, l’hardware di tipo enterprise e il mondo mobile.

Requisiti per la lettura

 Questo volume è stato pensato per chi si avvicina alla pratica investigativa sui sistemi
informatici e informativi. Nozioni di programmazione e robuste esperienze di navigazione in
Rete sono pertanto assolutamente necessarie, così come una buona confidenza con i principali
protocolli di comunicazione e una solida conoscenza delle architetture dei più diffusi sistemi
operativi (specialmente Unix). A monte di tutto questo vi è, imprescindibile, la curiosità e un
reale interesse verso la scienza nota come Digital Forensics.

Convenzioni utilizzate nel testo

Leggendo questo volume vi capiterà di incontrare due particolari box di approfondimento.
DIARIO DI UN DIGITAL FORENSICS EXPERT
Qui Andrea Ghirardini apre le porte dei suoi archivi, integrando quanto in discussione con esempi tratti dai casi di
cui si compone la sua esperienza investigativa.

COSA DICE LA LEGGE

Qui Gabriele Faggioli fissa l’attenzione su quanto previsto dalla normativa in merito al tema trattato, perché la
giurisprudenza gioca sempre un ruolo importante.

Contatti
È possibile contattare gli autori presso i seguenti indirizzi di posta elettronica:
ghirardini@beitsa.ch (Andrea Ghirardini)

gf@gabrielefaggioli.it (Gabriele Faggioli)

 Ringraziamenti

Come sempre nella stesura di un volume, vi è una numerosa serie di persone cui sono dovuti i
più sentiti ringraziamenti.
Il gruppo BIG e in particolare Massimiliano Marchese. Potrei dilungarmi a dire tantissime
cose su di lui, tutte positive. Alla fine mi limito a un ringraziamento per tutto quello che ha fatto
per mettere in piedi BE.iT. Un grazie anche Claudio Cesare Secchi. Mi auguro di poter fare
molta strada assieme.
Alessandro Caviglione. Di buono posso dire che se qualcosa ha a che fare con il mondo
virtuale, lui lo sa. Punto e senza esclusione alcuna. Di meno buono posso dire che mi ha fatto
rivalutare i prodotti Microsoft. Non gliela perdonerò mai.
Fabio Brivio. Doveva essere un aggiornamento. Non lo è stato. Doveva essere un lavoro di
pochi mesi. Non lo è stato. Doveva chiudersi eoni fa. Non è successo. Nonostante tutto non ha
perso pazienza e speranza. Ultimamente però le nostre conversazioni sono prevedibili. Mi dice
sempre: “Andrea, chiudi!”. Grazie per tutto.
Corrado Giustozzi. No, dico, si è offerto lui di scrivere la Prefazione! Quando avevo pochi
anni leggevo MCmicrocomputer e lo idolatravo. Poi mi sono connesso a McLink e nella
settimana successiva al mio primo collegamento mi ha fatto una lavata di capo sulla netiquette
per un mio cross post un po’ invasivo. Ma aveva ragione. Poi mi ha chiesto di scrivere per Byte
Italia (mai troppo compianta). E me ne sono vantato per anni. Ora il fatto che il sommo
NightGaunt si sia offerto di scrivere la Prefazione mi farà diventare ossessivo con tutti i miei
amici. Anzi, lo racconterò ai miei nipoti.
Luigi Ranzato. Secondo i giapponesi un allievo supera il maestro dopo quarant’anni di
apprendistato. Non è il suo caso, ci ha messo molto ma molto meno. Difatti ho dovuto ricorrere
ai suoi consigli e al suo sapere per lo studio delle shell bag. Grazie.
Stefano Fratepietro e Nanni Bassetti. Per aver reinventato il “made in Italy”. Nella pratica
della Digital Forensics semplicemente hanno dimostrato che “Italians do it better”.
Davide Gabrini. Un hacker. Ma così hacker che anche nei peggiori raduni underground lo
accettano di buon grado anche se è un poliziotto. Beh, gioca molto a suo favore anche la
simpatia e la propensione per tutto ciò che è buono e/o alcolico. Mi ha fatto scoprire Prezi e
tante altre cose. Lo scambio di battute “Rebus tu quante slide hai fatto”, “Una, però grande”
rimarrà nella storia.
 Matteo LK Flora. La dimostrazione più palese che genio e follia possono andare
assolutamente d’accordo in una stessa persona. Non solo è bravo nel suo lavoro, non solo sa
fare bene le fotografie, ma nei raduni hacker europei lui non è una primadonna, è una vera diva.
Ah, giusto per precauzione, la prossima volta guido io.
Litiano Piccin. Chapeau. Le sue conoscenze sul mobile sono semplicemente troppo avanti. Il
resto è superfluo.
“Il Lo”. L’entusiasmo fatta persona. L’unica persona che pur essendo un nerd allucinante ha il
coraggio di dirmi che io lo sono più di lui. Ogni tanto ci sentiamo e mi tira fuori qualche
argomento di cui non so nulla, ma con tale entusiasmo che mi costringe a studiarlo. A cosa mi
servirà non lo saprò mai, ma intanto è fatta. Ah, ti serve una sedia?
Federica Bertoni. Discutiamo animatamente su tutto. Però ha il suo perché. O no?
Discutiamone, però ho ragione io. Grazie per avermi fatto usare (e abusare) del tuo laboratorio
e il contributo con le bozze e la parte sul mobile.

Infine, un “grazie” particolare e personale.

A Elga. Dopo quasi 20 anni di matrimonio continua a sopportarmi. E lo fa con amore,
suscitando reazioni perplesse in tutti i miei amici nerd. La via per la santità passa anche per
questo. E io intanto sono una persona migliore grazie a lei.
L’incontro più fortunato della mia vita e la mia luce del mattino.
A Sirio per allietarmi la vita con le sue molte chitarre e semplicemente per la sua presenza, il
che non è poca cosa. Perché ogni volta che fai sentire il tuo humor sagace tua madre si gira e mi
dice “Me lo stai rovinando!”?
A Fiamma per essere una ragazzina dolce ma determinata ma soprattutto unica. All’inizio
saliva su e mi chiedeva “Papà tutto bene con il libro?”, poi “Papà continui a scrivere, posso
fare qualcosa?”, successivamente “Papà ancora a scrivere?” e ora “Papà ma ancora con ’sto
libro???”. Si l’ho tirata molto per le lunghe. Scusa se ti ho trascurata.
Ad Alessia. Sei veramente una bella persona (ti convincerai mai di questo?). La prova
vivente che l’amicizia esiste, trascende anche la distanza, e che quando c’è è destinata a durare
per anni. Mi auguro ancora moltissimi.
A Lina e Antonio. Grazie di tutto. Lina, posso chiamarti “mamma”, vero?

Di nuovo a Fabio Brivio per non aver ingaggiato un killer per uccidermi.
 Capitolo 1

Panoramica generale

Che cos’è la Digital Forensics?

Possiamo dire che è l’evoluzione naturale di quella che fino a poco tempo fa chiamavamo
comunemente Computer Forensics e la cui definizione potrebbe essere:
La disciplina che si occupa della preservazione, dell’identificazione e dello studio delle informazioni contenute nei computer,
o nei sistemi informativi in generale, al fine di evidenziare l’esistenza di prove utili allo svolgimento dell’attività investigativa.

Perché, quindi, parlare di Digital Forensics?

Come già trattato nell’Introduzione, ormai il numero di dispositivi digitali che utilizziamo
comunemente nella nostra vita è lievitato notevolmente. Le macchine fotografiche sono
pressoché tutte digitali, gli smartphone hanno praticamente sostituito i cellulari tradizionali con
sistema operativo proprietario, i lettori di e-book stanno diffondendosi, i tablet sono diventati lo
strumento principe per la fruizione dei contenuti.
Da un punto di vista meramente tecnico sono tutti computer, solo più o meno specializzati.
Uno smartphone è un computer con spiccate doti comunicative, un server è un computer
specializzato nella gestione di uno o più servizi di back-end, una centralina di un moderno
motore a scoppio è un sistema embedded specializzato, un navigatore satellitare un computer
per i viaggi e così via.
Esistono poi degli ibridi notevoli: pensiamo alle ultime fotocamere di Samsung e Polaroid
con Android a bordo. Cosa sono fotocamere, tablet, GPS o altro?
È indubbio che una tale diversificazione nella forma e nell’uso di tali apparecchi richieda
approcci significativamente differenti. Non solo, ma ora ciò che fa la differenza rispetto all’era
dell’informatica dei personal computer tradizionali è il collegamento tra tutti i sistemi di cui si
dispone.
Molte automobili possono essere controllate da app specializzate che permettono di
trasformare il proprio smartphone in un vero e proprio computer di bordo. Lo stesso smartphone
può essere utilizzato per effettuare pagamenti via NFC, leggere la e-mail, giocare, identificarsi
sul sito web della banca tramite un software token, collegarsi a un computer virtuale in remoto e
così via.
Inoltre cosa ben più interessante, i nostri dati sono di colpo diventati indipendenti dal
dispositivo. Devono essere raggiungibili dovunque e indipendentemente da cosa stiamo usando
come medium digitale. Quindi non sono più legati a uno specifico apparecchio, ma stanno in
cloud, in un servizio pubblico (Dropbox, Google Drive, Skydrive, Gmail, Flickr e così via), in
un cloud privato (un server Owncloud o AFS) o in uno storage connesso a Internet (i vari Qnap,
Synology e così via).
Quindi parlare di Computer Forensics è limitante in quanto ciò che sta emergendo non è tanto
la necessità di una scienza che permetta di esaminare tutti i singoli sistemi come entità a sé
stanti, quanto piuttosto come questi interagiscano tra loro e con la rete in generale.
Questo richiede quindi una fusione tra la Computer Forensics che potremmo definire
“classica” (fa strano solo a dirlo) e quella che fino a poco fa abbiamo definito come Network
Forensics, ovvero l’analisi dei flussi di dati in transito. Come è facile riuscire a intuire, nessuna
delle due branche da sola ci può dare, al momento attuale, un quadro completo della situazione.
La Computer Forensics non ci può dire molto se il dispositivo ha lavorato su dati su un server
remoto; la Network Forensics non ci può aiutare se non abbiamo idea di quale sia
l’applicazione che ha generato il traffico e quale sia il protocollo usato (oppure se la
connessione è protetta da un protocollo di crittografia).
Inoltre entrambe le discipline sono inutili senza una parte investigativa che può legare i vari
elementi tra loro.
Sembra tutto molto complicato? Beh in effetti lo è. Ma non tanto dal punto di vista tecnico,
quanto piuttosto perché sembra che la distribuzione massiva dei dati sia diventata una nuova
moda.
Poco tempo fa quando si esaminava un portatile si cercavano archivi locali e file cancellati.
Ora ci si trova tra le mani un iPad o un tablet Android e la prima cosa che ci si chiede è dove
diavolo saranno i dati dell’utente e come si potrà fare per recuperarli.
NOTA
In questo capitolo non stiamo volutamente trattando le problematiche legali dovute al possesso dei dati da parte
di una multinazionale come Google (e magari da tutta una serie di altre entità a essa collegate) e la loro
dislocazione in vari datacenter sparsi nel mondo.

Anche per i cellulari il discorso si fa più complesso. Per esaminare i cellulari tradizionali si
cercava di evitare in ogni modo che la fonte di prova potesse essere compromessa, e quindi si
lavorava con SIM dummy, jammer o gabbie di Faraday. Lo stesso principio vale per gli
smartphone attuali con la differenza che, se per il cellulare l’analisi iniziava e finiva con quanto
contenuto nel supporto, lo smartphone spesso non è altro che un mero strumento per riuscire a
lavorare su dati presenti su vari servizi pubblicati su Internet, e quindi è necessario affrontare il
problema di come muoversi in tal senso.
Il volume che state sfogliando vuole quindi offrire un compendio che permetta non solo a
chiunque abbia una buona conoscenza della materia informatica di capire i principi alla base
della Computer Forensics, ma si vuole addentrare anche nei meandri della più moderna Digital
Forensics, affrontando sia elementi tipici del network, sia della parte prettamente investigativa,
mostrando come elementi vari possano essere combinati in un quadro generale più ampio che
permetta di ricostruire quanto effettuato dall’utente all’interno di un contesto digitale più
articolato.
Si cercherà quindi di non focalizzarsi solamente sui personal computer (nella più ampia
accezione possibile, includendo quindi anche computer virtualizzati) ma anche su tutto
quell’insieme di nuovi device che sono comunemente utilizzati nella vita di tutti i giorni, ovvero
tablet, chromebook e smartphone. Per la parte relativa all’analisi di sistemi di back-end, si
vedrà come analizzare server fisici e virtuali ma anche come operare in un ambiente cloud
oppure con sistemi SAN per la gestione di grandi quantità di dati.
La scelta non è fatta solamente per rimanere “sulla cresta dell’onda” ma anche perché è
indubbio che quanto è stato descritto sopra sta diventando uno scenario comune.
È una questione di numeri. Google attiva alla fine del 2012 500.000 terminali Android al
giorno, Samsung ha venduto 50 smartphone al minuto nell’ultimo trimestre del 2012, le SmartTV
sono la nuova moda e Apple vende iPhone e iPad ormai a peso (d’oro potrebbe dire qualcuno,
non troppo a torto). Sul lato datacenter basta prendere solo Google come esempio. Gmail offre
10 GB di spazio mail e 5 GB di spazio per i dati, e Music 22.000 brani, il tutto gratuitamente.
Siamo tutti d’accordo che si tratta di dati di massima e sicuramente in overprovisioning, ma
danno l’idea delle dimensioni dei datacenter che vi sono dietro per poter gestire la mole di dati
di cui si sta parlando.
Anche i progetti open source fanno chiaramente capire il trend che si sta portando avanti. Vi
sono svariati software per la gestione di cloud pubblici e privati (OpenStack, Open Nebula,
CloudStack), file system sempre più grandi e complessi (btrfs, GlusterFS, Lustre).
Apache Hadoop sta ridefinendo il concetto di distributed computing mettendo a disposizione
non solo un file system, framework e librerie ma anche database (Cassandra, Hbase), sistemi di
datamining e data warehouse (Hive, Mahout).
Nonostante questa notevole escalation tecnologica complichi notevolmente il lavoro
dell’investigatore digitale rimane, per fortuna, valido il discorso che si faceva nella precedente
edizione del libro.
L’utente medio usa molti più dispositivi e servizi informatici e, nel contempo, li conosce
sempre meno. È incredibile come la sicurezza di uno smartphone o di un tablet sia percepita
quasi solamente in relazione al possesso dell’apparecchio senza minimamente pensare né al
fatto che lo stesso possa essere compromesso da remoto né che, essendo un computer (e quindi
un sistema complesso), è suscettibile a molte delle operazioni di recupero dati che si eseguono
sui normali PC.
Quindi, se sui PC capita di trovare software di cancellazione definitiva, su qualunque
smartphone è difficile trovare lo stesso livello di attenzione. Questo nonostante i principali top
player del mercato (Apple con iOS e Google con Android) facciano ora un uso molto pesante di
tecnologie di database per gestire i dati all’interno dei loro sistemi operativi.
Molto spesso le applicazioni sfruttano tali tecnologie per organizzare i propri dati ma non
gestiscono correttamente la cancellazione (o pospongono il processo di “sanitizzazione dei dati”
per non affliggere l’utente con momenti di attesa). Ergo, spesso messaggi e altre informazioni
sono marcati come cancellati mediante un flag e rimangono sul telefono per mesi o per anni
all’insaputa dell’utente.
Prendendo ispirazione dal ciclo di Asimov, chi si prende il tempo di imparare ad
approfondire la tecnologia si trova a essere davvero simile ai “sacerdoti” della Seconda
Fondazione. “Knowledge is power” deve diventare sempre più il motto del moderno
investigatore digitale.
Visto come il tutto si sta enormemente complicando, questa mancanza di attenzione verso la
sicurezza è certamente una consolazione.
Tutto questo ci mostra come la scena crimis urbana sia destinata a pullulare di dispositivi
tecnologici, probabilmente ricchi di informazioni relativamente a quanto accaduto.
Non solo ma, rispetto a quanto si diceva nella precedente edizione, tali dispositivi spesso
incorporano sistemi di tracciamento (via rete 3G o GPS) oppure sono sempre online e quindi
possono davvero fare la differenza all’interno di un caso. Viene quindi naturale pensare al fatto
che qualunque dispositivo tecnologico rinvenuto debba essere analizzato come tutto il resto del
materiale presente, indipendentemente dal tipo di crimine che è stato perpetrato.
I legami tra un qualsiasi dispositivo hardware e un crimine possono sfuggire nell’immediato,
ma possono rivelarsi evidenti al momento dell’analisi. Nasce quindi il problema di una corretta
gestione delle informazioni che questi oggetti possono contenere.
E qui il divario tra quanto normalmente accade con gli oggetti di uso comune continua a
essere tragicamente enorme. Negli ultimi anni, note serie televisive aventi come protagonista la
polizia scientifica, quali C.S.I. o l’italianissima R.I.S., hanno tenuto milioni di telespettatori
incollati agli schermi. Per la prima volta i “topi di laboratorio” sono stati presentati come
personaggi accattivanti e dinamici e non solo come scienziati chini a esaminare cose
incomprensibili. Ebbene, tutti avranno notato la cura con la quale le prove vengono raccolte,
preservate e ispezionate. Il granellino di sabbia, l’impronta digitale, la scritta a matita su un
foglietto, il liquido organico sono gelosamente custoditi per evitare la benché minima
alterazione, nella speranza che portino a una svolta determinante nelle indagini.
Eppure, anche in queste serie, perlopiù precise in campi come genetica, fisica o entomologia,
si vedono i protagonisti accendere con consumata leggerezza i computer e gli altri apparecchi
digitali degli indagati o delle vittime alla ricerca di prove. Tutto ciò non è per nulla strano: ogni
giorno molti appartenenti alle forze di polizia, in diversi paesi, si comportano in maniera
analoga nei confronti delle apparecchiature tecnologiche rinvenute sulla scena di un crimine.
Questo comportamento è errato e deleterio, e spesso ha causato un arresto o una
compromissione dell’indagine.

Applicazioni della Digital Forensics

Qualunque dispositivo tecnologico va gestito e controllato come se intersecasse due realtà
ben distinte. In effetti, esso è costituito da una parte fisica e una parte logica, che sono ambedue
importanti (spesso la seconda più della prima) e necessitano della dovuta attenzione.
La parte fisica è semplice da comprendere. La si può vedere, toccare con mano, percepire
con i sensi. È facile, quindi, comprendere come vi si possano trovare impronte digitali, residui
organici (una ricerca ha dimostrato che in una comune tastiera usata in ufficio si possono trovare
più batteri e particelle di sporco che in un bagno pubblico).
La parte logica, digitale è la ragione di vita di un Digital Forensics expert. Si pensi a una
prova fisica aleatoria, come un’impronta. Rovinarla esaminandola è estremamente semplice
nonché disastroso. Richiede una cautela quasi maniacale.
Ora si pensi a un file. Un file non è un concetto materiale. È una semplice astrazione logica.
Non ha una sua natura fisica. Un file può essere copiato, esistendo quindi su più supporti fisici
diversi. Un file non può essere rubato, almeno non nel senso classico del termine: se ne prendo
la copia e lascio l’originale al suo posto non ho sottratto nulla al suo legittimo proprietario. Un
file può essere alterato, ma come si può dimostrare l’alterazione di qualcosa che esiste solo a
livello logico? Anche riportandosi alla sua rappresentazione su un supporto magnetico, è
impossibile riuscire ad arrivare a un livello così dettagliato da dimostrare che, per esempio, una
particella di materiale magnetico ha cambiato il suo orientamento. Questo diventa ancora più
aleatorio nel momento in cui il file risiede su un supporto come un chip di memoria RAM. Esso
viene continuamente modificato dal refresh della memoria, dal fatto che il sistema operativo
decide di spostarlo in un’altra locazione di memoria o sul file di swap. Un calo di tensione lo
può irrimediabilmente distruggere o alterare.
NOTA
Un file di swap, detto anche file di scambio, è una porzione di disco fisso utilizzata come memoria quando il
sistema operativo esaurisce la memoria di lavoro fisica; il file può essere permanente, nel qual caso viene
utilizzato uno spazio contiguo dell’hard disk, o temporaneo, cioè viene utilizzato lo spazio su disco solo se
questo è disponibile.

Si potrebbe continuare all’infinito con esempi sulla stessa falsariga, ma una cosa dovrebbe
apparire lampante. Un dispositivo elettronico non può essere acceso e gestito con leggerezza da
parte del Digital Forensics expert. Vista l’immaterialità della prova, la sua distruzione o
alterazione può avvenire per una miriade di motivazioni diverse.
Inoltre, come si è chiarito precedentemente, i confini della parte logica del dispositivo sono
destinati a trascendere quelli dell’apparato fisico, vista la costante connessione con la rete che
quasi tutti ora hanno.
 La nostra società si basa quasi esclusivamente su informazioni digitali. Il nostro mondo reale
ha fortissimi legami con quello digitale. Banalmente, si provi a effettuare un’operazione
bancaria nel momento in cui il sistema informativo ha deciso di non funzionare: i nostri soldi
reali non risultano disponibili, perché la loro rappresentazione digitale non è utilizzabile.
Per tale motivo è quindi evidente che molte prove riguardanti crimini del tutto reali, compresi
omicidi, attentati terroristici, frodi o rapimenti, possono risiedere su apparati digitali. Si pensi a
titolo di esempio alle webcam o alle telecamere di sorveglianza che registrano dati su hard disk.
Smartphone, tablet, console per videogiochi, macchine fotografiche, sistemi di navigazione
come di car entertainment dispongono quantomeno di connessioni Wi-Fi, se non GPS o 3G. Gli
operatori telefonici stanno notando un trend in continua crescita delle connessioni dati rispetto a
qualunque altro utilizzo classico dei telefoni, come le comunicazioni vocali o l’invio di
messaggi.
I geek più hardcore penseranno anche al fatto che dal 2014 Google tenterà di cambiare il
costume delle persone tramite i Google Glass. Immaginate quanto potrebbe essere importante
rivedere gli ultimi fotogrammi ripresi da un dispositivo sempre online e indossato in modo da
avere lo stesso punto di vista dell’osservatore.
Stiamo per arrivare ai concetti espressi dai film di fantascienza come The Final Cut o
Strange Days.
Purtroppo la gestione di tali connessioni ora come ora ha dei limiti legali semplicemente
insormontabili. Esaminare i dati contenuti in un datacenter estero, pur con delle credenziali in
cache di uno di questi dispositivi, è molto pericoloso in quanto, può esporre il nostro
investigatore informatico a ben più di una violazione del codice di procedura penale di molti
paesi.
E questo è destinato a diventare il principale scoglio contro cui si scontreranno le indagini
presenti e future, ovvero l’impossibilità di legare gli elementi digitali locali e remoti per
comporre un quadro d’insieme che possa risolvere i casi.
Riprendendo quanto scritto poche righe sopra, i Google Glass disporranno di uno storage
locale davvero minimo, che sarà utilizzato perlopiù come cache. Tutto il resto si troverà
costantemente in un datacenter distribuito magari su più siti geografici in stati differenti.
Tecnicamente riuscire ad avere l’informazione a disposizione potrebbe essere relativamente
semplice e veloce, ma potrebbe rivelarsi del tutto inutile dal punto di vista investigativo,
considerati i limiti che attualmente la legislazione di quasi tutti gli stati pone su questo tipo di
azioni.

Una metodologia forense

Come dichiarato in precedenza, la Digital Forensics è una nuova branca della polizia
scientifica. Il suo fascino e il suo limite massimo risiedono nel fatto di essere, appunto, “nuova”.
È interessante sicuramente per il fatto che a ogni nuovo caso si scoprono nuovi metodi di analisi
e di approccio alla situazione; è un limite perché la stessa evidenza, affidata a periti diversi o
addirittura allo stesso forensics expert in due tempi diversi, potrebbe produrre risultati
totalmente opposti.
Tutto questo è ovvio. L’esperienza aiuta a migliorare e a progredire nella materia specifica.
Chi scrive è assolutamente convinto che se potesse ritornare ora su alcuni dei casi affrontati
qualche anno fa otterrebbe risultati di gran lunga migliori.
Sfortunatamente, non è un problema solo di efficienza o di efficacia. In molti casi si
evidenziano dei comportamenti palesemente sbagliati che inevitabilmente si traducono, in fase
di dibattimento, nell’invalidazione della fonte di prova. Si immagini il danno che questo può
arrecare, specialmente se l’errore è avvenuto già nella fase di acquisizione della prova stessa.
Ciò che è assolutamente necessario è un metodo di lavoro che permetta di evitare a ogni
forensics expert di passare il tempo a reinventare le stesse cose o di rifare gli stessi errori che
altri suoi colleghi hanno già compiuto. In questo modo si potrebbe ottenere una serie di vantaggi.
Normalizzazione dei risultati. Applicando la stessa metodologia sarebbe possibile ottenere
risultati molto simili pur rivolgendosi a periti diversi, almeno per le fasi più di routine,
come l’acquisizione delle prove.
Minore dispersione di energie. La mancanza di comunicazione e una legislazione
assolutamente carente e in arretrato rispetto all’evoluzione tecnologica fanno sì che ogni
singolo forensics expert debba affrontare gli stessi problemi già affrontati da altri e debba
trovarvi soluzione. Ciò, inevitabilmente, complica il lavoro e ruba tempo ed energie
all’unica fase in cui la personalità del perito può davvero esprimersi, ovvero quella
dell’analisi delle prove. Questo è tanto più vero ora visti i trend appena descritti.
Minori possibilità alla controparte. Applicare un metodo che abbia già superato più volte
le forche caudine del dibattimento eviterebbe di dare agio agli avvocati di parte avversa di
trovare un vizio di forma o un cavillo legale che possa invalidare tutto il lavoro svolto.
Verificabilità dei risultati. Come si avrà più volte modo di sottolineare, l’uso di un metodo
comune permetterebbe inoltre ai periti di parte avversa di controllare in maniera più
semplice e incontrovertibile i risultati ottenuti dagli investigatori.
In questo testo si cercherà, per quanto possibile, di fornire un metodo di lavoro che si possa
applicare a ogni singolo caso e che risulti indipendente sia dagli strumenti (tool) di analisi
utilizzati, sia dalla tipologia di prova in esame.
Fissare un metodo non deve essere interpretato come un tentativo di “industrializzare” il
lavoro. La variabilità delle situazioni è tale che ogni forensics expert potrà trovare spazio per
esprimersi e dimostrare la sua competenza a ogni nuovo caso. Il metodo permette semplicemente
di sveltire le fasi più noiose e ripetitive e di porre una base comune su cui cominciare l’analisi.

Una filosofia di lavoro

Che tool usare? La risposta non è né ovvia né scontata. Sicuramente è più semplice
rispondere al contrario. Innanzitutto non esiste lo strumento universale. Fossilizzarsi su un unico
strumento è controproducente, indipendentemente dalla bontà dello strumento stesso.
Il motivo è presto detto. Il numero di dispositivi che si possono affrontare è enorme, così
come lo stesso dispositivo necessita di analisi diverse a seconda del tipo di indagine si sta
compiendo.
Per esempio un cellulare utilizzato per riprendere lo svolgersi di un crimine potrà contenere
al proprio interno un file video che potrà essere estratto, mentre lo stesso apparecchio utilizzato
per un reato di stalking attraverso un social network necessiterà di essere esaminato in un modo
completamente differente in quanto i dati non sono locali ma sono stati generati localmente e
mandati su cloud.
Inoltre analizzare un dispositivo mobile è diverso da analizzare un computer fisico e, nel
contempo, è diverso dall’analisi di una macchina virtuale.
Inutile dire che nessun tool può anche solo pensare di affrontare un così ampio ventaglio di
casistiche.
Il primo requisito per effettuare un’analisi è quindi quello di essere di mente aperta, cercando
di adattarsi alla combinazione di fattori che via via si presentano nel corso delle varie indagini.
Talvolta sarà necessario utilizzare uno strumento di analisi forense specializzato, a volte si
dovrà usare un programma open source, talvolta il caso potrà essere risolto con un programma
free o shareware e a volte bisognerà dotarsi un linguaggio di programmazione e scriversi il tool
in maniera autonoma.
Non si vuole parteggiare per software open o commerciale. Tutto dipende dall’insieme degli
elementi che compongono la specifica indagine. Spesso il software commerciale permette di
ridurre drasticamente i tempi nelle analisi più comuni.
Nel campo mobile è impossibile trovare un buon software open source che permetta di
lavorare su un ampio numero di modelli. Troppo spesso gli SDK e la documentazione
necessaria per agire a basso livello su questi apparecchi è rilasciata sotto Non Discolure
Agreement, e quindi il software ricavato non può essere necessariamente a sorgente aperto.
Di contro capita troppo spesso di trovarsi di fronte a un problema per cui non c’è uno
strumento adatto. Disporre di una macchina Linux e del relativi strumenti di sviluppo open
permette di lavorare in modi che sarebbero impossibili con dei pacchetti commerciali basati su
Windows.
Inoltre è necessario ricordare tassativamente di non essere ossessionati dalla parola
“forensics”. Non è l’etichetta sul tool che fa la differenza. Anzi, spesso le software house se ne
approfittano applicando l’etichetta “forensics” su un programma precedente, dotandolo di un
paio di sicurezze in più e di una funzione di reportistica un po’ più avanzata, giusto per farlo
pagare il triplo rispetto alla versione “normale”.
In nessun caso deve essere il tool che guida il Digital Forensics expert. È la metodologia che
gli permetterà di evitare errori e di compromettere la fonte di prova. Affidarsi esclusivamente
alle sicurezze di un tool è un modo di procedere eccessivamente fiducioso e dilettantistico. Di
contro, più si è rigorosi con il modo di procedere maggiori saranno la chance di trovare quanto
occorre per estrarre i dati necessari.
Non si porrà mai troppo l’accento sul fatto che al momento attuale si è tornati, per certi versi,
agli anni 2000. I tool, le leggi e, a volte, la tecnologia non sono assolutamente al passo con i
tempi. Quindi moltissimo sarà basato esclusivamente sul metodo, la conoscenza e il buon senso.
 Capitolo 2

Il panorama giuridico italiano

“Con la legge n. 48/2008 sono state introdotte nel Codice di Procedura Penale importanti novità che sostanzialmente
prescrivono l’utilizzo di metodologie di Digital Forensics nell’acquisizione delle fonti di prova informatica da parte
dell’autorità giudiziaria, che in sede di ispezioni e perquisizioni dovrà adottare ‘misure tecniche dirette ad assicurare la
conservazione dei dati originali e ad impedirne l’alterazione’. L’auspicio è che le novità introdotte accelerino l’utilizzo di
corrette metodologie per l’acquisizione, conservazione ed analisi delle evidenze informatiche, per evitare la commissione di
errori più volte rilevati in passato dalla dottrina.”

Normative applicabili in Italia

L’essenza della Digital Forensics consiste nell’acquisizione, conservazione e analisi di
evidenze informatiche secondo modalità tali da garantire che le stesse possano essere
validamente utilizzate in sede processuale. Molteplici sono i soggetti che potrebbero essere
interessati all’utilizzo processuale di un’evidenza informatica: si pensi, per esempio, al
pubblico ministero che debba provare la colpevolezza di un imputato di un reato in cui l’utilizzo
della strumentazione informatica è mezzo o fine dell’attività criminale, all’imputato che voglia
fornire prove a proprio favore o al privato (persona fisica o giuridica) che intenda far valere in
giudizio la lesione di un proprio diritto da parte di un terzo, con la conseguente richiesta di un
risarcimento del danno in sede civilistica (per esempio il danneggiamento di un server a seguito
di un attacco informatico).
Appare, quindi, opportuno chiarire sin da subito che le normative riguardanti la formazione e
l’utilizzo (nonché l’intrinseco valore probatorio) delle prove sono differenti a seconda della
tipologia di giudizio nella quale le stesse si inseriscono. La distinzione fondamentale, per
enucleare le fonti normative applicabili concernenti le prove, è tra il processo civile e il
processo penale. Va comunque tenuto presente che in ambito civilistico è necessario altresì
considerare le peculiarità in materia di prova previste per il processo del lavoro.
In via preliminare, è bene chiarire che il processo civile è regolato essenzialmente dalle
norme contenute nel Codice di Procedura Civile (c.p.c.), e che il giudice civile è chiamato a
decidere sulla domanda proposta da un soggetto privato (persona fisica o giuridica) per la tutela
di un proprio diritto soggettivo che assume essere stato leso da un terzo. La possibilità di
attivazione della tutela giurisdizionale in sede civilistica è garantita dall’articolo 24 comma 1
della Costituzione della Repubblica Italiana, in base al quale “tutti possono agire in giudizio per
la tutela dei propri diritti e interessi legittimi”.
Ai fini della proposizione di una domanda il soggetto agente (attore) deve innanzitutto avere
un interesse ad agire (l’art. 100 c.p.c. prevede infatti che “per proporre una domanda o per
contraddire alla stessa è necessario avervi interesse”) ed essere legittimato all’azione stessa (in
base all’art. 81 c.p.c., infatti, “fuori dei casi espressamente previsti dalla legge nessuno può far
valere nel processo in nome proprio un diritto altrui”). Il buon esito di un’azione in sede
civilistica dipende dalla dimostrazione da parte dell’attore dei fatti costitutivi dei diritti vantati
e della loro lesione da parte di un terzo, posto che il giudice non ha, di regola e salvo talune
eccezioni, poteri investigativi autonomi. Le prove prodotte dalle parti del procedimento, quindi,
assumono un’importanza fondamentale in quanto costituiscono gli unici elementi sui quali di
regola, e salvo talune eccezioni, il giudice dovrà basarsi per emettere la propria sentenza. In
considerazione del ruolo che le prove rivestono all’interno del processo civile, il Codice di
Procedura Civile contempla talune norme specifiche che riguardano la loro acquisizione nel
processo e la loro valutazione da parte del giudice.
Nel processo penale, regolato dalle disposizioni contenute nel Codice di Procedura Penale
(c.p.p.), il giudice ha il compito di valutare se la condotta tenuta da un soggetto integri o meno
una fattispecie di reato espressamente prevista dalla legge ai fini dell’applicazione delle
sanzioni dalla stessa comminate (trattasi del principio di legalità di cui all’art. 3 c.p.p., per il
quale “nessuno può essere assoggettato a sanzioni se non in forza di una legge entrata in vigore
prima della commissione della violazione”). Parti necessarie di un processo penale sono il
pubblico ministero (il quale ha l’obbligo di esercitare l’azione penale in base all’art. 112 della
Costituzione) e l’imputato, ovvero il soggetto accusato di aver posto in essere una condotta
costituente reato.
NOTA
La Corte di Cassazione Penale ha confermato che “nell’attuale sistema processuale penale il pubblico
ministero ha la qualità di parte, sia pure pubblica, con il compito di sostenere l’accusa e adottare una strategia
processuale tesa a un’efficace e sollecita raccolta degli elementi utili e a evitare il pericolo di inquinamento delle
fonti di prova” (Cass. Pen. 23 febbraio 1998, n. 1125).

Le prove utilizzabili dal giudice nel processo penale ai fini della propria decisione, come
sarà approfondito in seguito, devono essere acquisite in contraddittorio tra le parti nella
cosiddetta “fase dibattimentale”. Tuttavia, prima dell’avvio vero e proprio del processo penale,
esiste la cosiddetta fase delle “indagini preliminari” (artt. 326 sgg. c.p.p.), durante la quale il
pubblico ministero e la polizia giudiziaria, ricevuta una notizia di reato, svolgono nell’ambito
delle rispettive attribuzioni le indagini per le determinazioni inerenti l’esercizio dell’azione
penale (art. 326 c.p.p.).
NOTA
La Corte di Cassazione Penale ha escluso che possano essere promosse indagini preliminari non basate su di
una notizia di reato ma al fine di eventualmente acquisirla, come indagini a tappeto e in forma indiscriminata,
 dirette ad accertare se ipotetici reati siano stati commessi (cfr. Cass. Pen. 26 gennaio 1999, n. 3261).

Ai sensi dell’art. 327 bis introdotto nel Codice di Procedura Penale dall’art. 7 della legge 7
dicembre 2000, n. 397 (Disposizioni in materia di indagini difensive), durante le indagini
preliminari il difensore dell’indagato “ha facoltà di svolgere investigazioni per ricercare e
individuare elementi di prova a favore del proprio assistito”. L’attività di indagine del difensore
può essere svolta personalmente dallo stesso oppure avvalendosi di sostituti, investigatori
privati autorizzati e, quando sono necessarie specifiche competenze, da consulenti tecnici. Al
termine della fase delle indagini preliminari il pubblico ministero potrà richiedere al giudice
dell’udienza preliminare il rinvio a giudizio (se gli elementi raccolti risultano sufficienti a
sostenere l’accusa nei confronti del soggetto sottoposto alle indagini) o l’archiviazione della
notizia di reato e degli atti delle indagini preliminari.
In conclusione, è chiaro il motivo per il quale la disciplina delle prove è sostanzialmente
differente nel processo civile e in quello penale: mentre il processo civile (e quello del lavoro)
svolge una funzione privatistica attraverso la tutela dei diritti dei soggetti che la richiedono, il
processo penale ha un rilievo pubblicistico attraverso la repressione delle condotte di reato
stabilite dal nostro ordinamento giuridico.
Oltre alle norme procedurali che regolano il processo civile e penale, vi sono una serie di
ulteriori normative che hanno un impatto rilevante sull’attività di Digital Forensics. A titolo
esemplificativo, si considerino:
la legge 23 aprile 2009 n. 38 (in Gazz. Uff., 24 aprile, n. 95). Conversione in legge, con
modificazioni, del decreto legge 23 febbraio 2009, n. 11, recante misure urgenti in materia
di sicurezza pubblica e di contrasto alla violenza sessuale, nonché in tema di atti
persecutori; il decreto legislativo 30 maggio 2008 n. 109 (Attuazione della direttiva
2006/24/CE riguardante la conservazione dei dati generati o trattati nell’ambito della
fornitura di servizi di comunicazione elettronica accessibili al pubblico o di reti
pubbliche di comunicazione e che modifica la direttiva 2002/58/CE);
la legge 18 marzo 2008, n. 48 (Ratifica ed esecuzione della Convenzione del Consiglio
d’Europa sulla criminalità informatica, fatta a Budapest il 23 novembre 2001, e norme di
adeguamento dell’ordinamento interno);
la legge 6 febbraio 2006, n. 38 (Disposizioni in materia di lotta contro lo sfruttamento
sessuale dei bambini e la pedopornografia anche a mezzo Internet);
il decreto legislativo 7 marzo 2005, n. 82 (Codice dell’Amministrazione digitale);
il decreto legislativo 30 giugno 2003, n. 196 (Codice in materia di protezione dei dati
personali);
il decreto legislativo 8 giugno 2001, n. 231 (Disciplina della responsabilità
amministrativa delle persone giuridiche, delle società e delle associazioni anche prive
di personalità giuridica, a norma dell’articolo 11 della legge 29 settembre 2000, n. 300);
 la legge 3 agosto 1998, n. 269 (Norme contro lo sfruttamento della prostituzione, della
pornografia, del turismo sessuale in danno di minori, quali nuove forme di riduzione in
schiavitù);
la legge 23 dicembre 1993, n. 547 (Modificazioni ed integrazioni alle norme del codice
penale e del Codice di Procedura Penale in tema di criminalità informatica);
la legge 20 maggio 1970, n. 300 (Norme sulla tutela della libertà e dignità dei lavoratori,
della libertà sindacale e dell’attività sindacale nei luoghi di lavoro e norme sul
collocamento).
In particolare, la legge n. 48/2008 riveste una grande importanza per la tematica della Digital
Forensics. In estrema sintesi la suddetta legge prevede:
alcune modifiche al Codice Penale concernenti la criminalità informatica (inserimento di
nuove fattispecie di reato e aggiornamento di alcuni articoli già presenti);
l’inclusione di “delitti informatici e trattamento illecito di dati” nel catalogo dei reati per i
quali è prevista la responsabilità amministrativa degli enti ai sensi del decreto legislativo
8 giugno 2001, n. 231;
alcune modifiche al Codice di Procedura Penale volte rendere obbligatorio per le forze di
polizia l’utilizzo di specifiche metodologie nel corso delle indagini informatiche (per
esempio modifiche in materia di ispezione e perquisizione);
la modifica di parte della disciplina sulla data retention contenuta nell’art. 132 del d.lgs
196/2003.

La nozione di prova
Durante il processo, sia in sede civile sia in sede penale, il giudice deve ricostruire, sulla
base delle prove raccolte, la verità dei fatti ai fini della propria decisione. La funzione
principale della prova è, dunque, quella di permettere al giudice la corretta ricostruzione e
dimostrazione dei fatti affermati dalle parti nel corso del processo.
La prova informatica (cioè un insieme di informazioni tradotte nel linguaggio utilizzato dalle
strumentazioni informatiche non immediatamente intelligibili dall’uomo) assolve alla medesima
funzione di tutte le altre prove anche se, per le sue caratteristiche intrinseche, presenta
problematiche particolarmente delicate e complesse. In particolare, la facilità con cui tali
informazioni possono essere manipolate, alterate o distrutte rende necessarie specifiche
procedure per la loro acquisizione, analisi e conservazione.
NOTA
Francesca Maria Molinari (“Questioni in tema di perquisizione e sequestro di materiale informatico” in Cass.
Pen. 2012, 02, 696) rileva come l’immaterialità del documento informatico vada intesa nel senso di “assoluta
assenza di concrete determinazioni spaziali, essendo ‘immateriale’ tutto ciò che è ‘esente dai limiti e dalle
 condizioni che determinano e caratterizzano la materia concreta’. Ora, se nel caso del documento tradizionale il
contenuto rappresentativo è un tutt’uno con il supporto materiale sul quale si trova impresso: ne posso fare delle
copie, ma si tratterà sempre di un quid novi rispetto all’originale (per questo si dice che il contenuto
rappresentativo è incorporato nel supporto materiale); la caratteristica fondamentale di un file, e in generale
dell’informazione digitalizzata, sta invece proprio in questo: la scorporabilità del contenuto rappresentativo dal
supporto su cui è stato originariamente registrato e, quindi, l’esistenza dell’uno indipendentemente dall’altro. Ma
non solo: poiché una stringa di bit non è altro che un’astrazione logico/matematica, essa è riproducibile un
numero indeterminato di volte: non ‘sbiadisce, non si altera, non invecchia’. Inoltre, poiché un bit è sempre
uguale a se stesso (a differenza dei segnali analogici), ‘la stessa differenza qualitativa tra originale e copia,
inevitabile nel caso di un documento tradizionale, qui scompare’; l’importante, semmai, è che, durante il
processo di trasferimento dei dati, che avviene pressoché in ‘tempo reale’, ne sia garantita l’integrità: cosa
‘molto delicata, dal momento che presenta un ampio tasso di vulnerabilità agli errori’”.

Prima di entrare nel merito del tema, è bene considerare che negli ultimi decenni, a seguito
dello sviluppo e dell’impetuosa diffusione dell’informatica e della telematica, che ha
determinato la nascita di nuovi diritti da garantire (domicilio informatico, tutela della
riservatezza e così via) e di nuove forme di aggressione (virus, spamming, frodi informatiche e
così via), il legislatore si è trovato nella necessità di intervenire in diversi settori
dell’ordinamento giuridico prevedendo norme specifiche che trovano in questi anni la loro
prima applicazione. La prova informatica si è quindi sviluppata, sempre più spesso, come
elemento, a volte decisivo, per garantire la sanzionabilità di coloro che abbiano tenuto
comportamenti illeciti qualora non sia possibile utilizzare o non siano sufficienti altri elementi
probatori.
Anche se non esiste nel nostro ordinamento giuridico una precisa definizione di prova, molte
sono le disposizioni normative che si occupano dei singoli mezzi di prova a disposizione, a
seconda dei casi, delle parti o del giudice. Nei paragrafi che seguono si prenderanno in esame
le principali norme che regolano l’ammissione, la formazione e la valutazione delle prove in
sede civile, penale e lavoristica. Si precisa sin da ora che la materia delle prove è molto vasta e
la trattazione che segue non ha pretese di esaustività e completezza, ma solo di fornire una serie
di elementi utili al fine di valutare poi quali siano i migliori procedimenti di acquisizione e
conservazione della prova informatica. Trattasi, inoltre, di elementi che a un lettore avvezzo alle
tematiche legali potranno risultare banali; si rivolgono perciò a coloro i quali non abbiano mai
studiato o approfondito gli aspetti giuridici degli elementi probatori.

La prova in sede civile

L’articolo 115 del Codice di Procedura Civile prevede che, salvi i casi previsti dalla legge,
il giudice deve porre a fondamento della decisione le prove proposte dalle parti, o dal Pubblico
Ministero, nonché i fatti non specificatamente contestati dalla parte costituita.
NOTA
La Corte di Cassazione ha precisato che “il principio consacrato nell’art. 115 c.p.c., secondo cui il giudice ha
 l’obbligo di decidere iuxta alligata et probata, importa, tra l’altro, che la decisione sia tratta unicamente dalle
allegazioni delle parti, cioè dalle circostanze di fatto dedotte a fondamento della domanda o dell’eccezione, e
dalle prove offerte dalle parti medesime. Detta norma è intesa ad assicurare il rispetto dei principi fondamentali
della difesa e del contraddittorio, impedendo che una parte possa subire una decisione basata su fatti a essa
sconosciuti e in relazione ai quali non si sia potuta difendere” (Cass. Civ. 6 settembre 2002, n. 12980).

Può tuttavia, senza bisogno di prova, porre a fondamento della decisione le nozioni di fatto
che rientrano nella comune esperienza (fatti notori). A titolo esemplificativo, in un’ordinanza del
Tribunale di Mantova (18 maggio 2006) il giudice ha però escluso che i fatti acquisiti tramite
Internet possano definirsi nozioni di comune esperienza ai sensi dell’articolo 115 c.p.c. Si legge
nella motivazione che la norma deve
essere intesa in senso rigoroso, comportando la stessa una deroga al principio dispositivo, per cui ‘notorio’ deve intendersi
solo il fatto che una persona di media cultura conosce in un dato tempo e in un dato luogo, mentre le informazioni pervenute
da Internet, quand’anche di facile diffusione ed accesso per la generalità dei cittadini, non costituiscono dati incontestabili
nelle conoscenze della collettività.

NOTA
Paolo Mazzotta (“Valenza processuale delle notizie acquisite tramite Internet”, in Diritto dell’Internet, 2007, 1, pp.
30 sgg.), in disaccordo con la motivazione del giudice, ha evidenziato che “non possiamo condividere l’opinione
del giudice che, per le informazioni acquisite tramite Internet, esclude a priori la possibilità di considerarle come
fatto notorio ai sensi e per gli effetti dell’art. 115 c.p.c. Data la peculiare natura di Internet, si ritiene che esso
contribuisca, quale nuovo strumento di comunicazione di massa, a incrementare il patrimonio di conoscenze
collettive sotto il profilo dei fatti suscettibili di assumere la valenza delle nozioni di comune esperienza per le
quali non è richiesto alcuno specifico provvedimento di verifica probatoria”.

Principio fondamentale del processo civile, quindi, è che chiunque voglia far valere in
giudizio un diritto deve provare i fatti che ne costituiscono il fondamento (principio dell’onere
della prova). Parimenti, incombe sul soggetto che intenda eccepire l’inefficacia di tali fatti, o
sostenere che il diritto invocato si è modificato o estinto, provare a sua volta i fatti su cui si
fonda la sua eccezione (principio dell’onere della prova di cui all’art. 2697 c.c.).
Nel processo civile, dunque, le prove a fondamento dei diritti e delle eccezioni sono
ricercate e prodotte direttamente dalle parti coinvolte, non avendo il giudice, salvo casi
particolari, il potere di ricercare direttamente mezzi che possano portare alla conoscenza dei
fatti. La prova è quindi sostanzialmente la dimostrazione della veridicità dei fatti che ciascuna
parte chiede al giudice di accertare ai fini dell’ottenimento di un provvedimento a essa
favorevole. La mancata dimostrazione di un fatto sul quale la parte ha l’onere della prova
comporta necessariamente la soccombenza su quel punto.
Essendo allora onere di ciascuna parte la produzione delle prove a proprio favore, assume
particolare rilievo la loro corretta acquisizione e conservazione al fine di non pregiudicare il
buon esito del procedimento all’interno del quale dovranno essere prodotte. Quanto sopra è
ancor più vero quando le prove sono costituite da informazioni contenute o scambiate dai
sistemi informatici o telematici, posto che la poca conoscenza sia delle nuove tecnologie, che
può portare alla sottovalutazione della facilità di compromissione delle prove informatiche, sia
delle norme che regolano il processo civile sono spesso la causa di insuccessi nella produzione
di prove di grande importanza per l’esito processuale.
Venendo alla trattazione delle norme che regolano nello specifico le prove nel processo
civile, occorre innanzitutto premettere che costituiscono mezzi di prova, ammissibili nel
processo civile, solamente quelli espressamente configurati come tali dalla legge (principio
della tipicità dei mezzi di prova), la quale stabilisce, tra l’altro, la loro efficacia probatoria.
Proprio in ordine all’efficacia dei mezzi di prova si suole solitamente distinguere tra:
prove piene, che sono idonee a dimostrare con certezza la veridicità dei fatti cui si
riferiscono;
prove di verosimiglianza, che favoriscono il convincimento del giudice circa
l’attendibilità del fatto invocato dalla parte pur non fornendo dimostrazione assoluta (e che
sono ritenute sufficienti solo in alcuni casi come, per esempio, il cosiddetto fumus boni
iuris in sede cautelare);
NOTA
Il giudice per l’emissione di un provvedimento cautelare (per esempio un sequestro conservativo) deve
accertare se i fatti invocati dall’attore siano verosimili con conseguente apparente sussistenza di un diritto in
capo all’attore stesso, non richiedendosi invece una prova piena che sarà oggetto del successivo giudizio (si
ricorda che per l’emissione di un provvedimento cautelare è necessaria altresì la sussistenza del cosiddetto
periculum in mora).

argomenti di prova, che pur non possedendo pieno valore probatorio offrono al giudice
elementi per la valutazione di altre prove o, più in generale, dell’intero procedimento
giudiziario. In base all’articolo 116 comma 2 c.p.c. può, per esempio, costituire argomenti
di prova il comportamento tenuto dalle parti nel corso del giudizio o il rifiuto ingiustificato
delle stesse di consentire alle ispezioni.
In sede di valutazione delle prove l’articolo 116 c.p.c. stabilisce che “il giudice deve
valutare le prove secondo il suo prudente apprezzamento, salvo che la legge disponga
altrimenti”. Questa disposizione devolve quindi al giudice l’individuazione delle fonti del
proprio convincimento e pertanto, come sancito dalla Corte di Cassazione (Cass. Civ. 23 aprile
2001, n. 5964), anche “la valutazione delle prove, il controllo della loro attendibilità e
concludenza, nonché la scelta, fra le risultanze istruttorie, di quelle ritenute idonee ad acclarare
i fatti oggetto della controversia, privilegiando in via logica taluni mezzi di prova e
disattendendone altri, in ragione del loro diverso spessore probatorio, con l’unico limite della
adeguata e congrua motivazione del criterio adottato”.
Esistono, tuttavia, delle prove (definite prove legali) che, in deroga al principio della libera
valutazione sopra enunciato, hanno un’efficacia vincolante per il giudice, il quale non può in
alcun caso disattenderle (per esempio la confessione giudiziale).
Occorre, infine, accennare alle prove cosiddette atipiche alle quali, seppur non previste da
nessuna norma di legge, viene riconosciuta una valenza probatoria in forma meramente
indiziaria (per esempio prove raccolte in un altro procedimento civile, scritture e dichiarazioni
provenienti da terzi, verbali della Pubblica Amministrazione e così via). Si consideri in
particolare la funzione delle presunzioni (agli argomenti di prova si è già accennato): le
presunzioni sono definite dall’articolo 2727 c.c. come “le conseguenze che la legge o il giudice
trae da un fatto noto per risalire a un fatto ignorato”. La Corte di Cassazione ha chiarito che “in
tema di presunzioni semplici vige il criterio secondo cui le circostanze sulle quali la
presunzione si fonda devono essere tali da lasciare apparire l’esistenza del fatto ignoto come
una conseguenza ragionevolmente probabile del fatto noto, dovendosi ravvisare una connessione
tra i fatti accertati e quelli ignoti secondo regole di esperienza che convincano a ciò, sia pure
con qualche margine di opinabilità” (Cass. Civ. 23 marzo 2005, n. 6220). Le presunzioni non
stabilite dalla legge (presunzioni semplici) sono lasciate alla prudenza del giudice, il quale non
deve ammetterle nel caso non siano gravi, precise e concordanti.
NOTA
Oltre alle presunzioni semplici vi sono anche quelle legali, stabilite dalla legge, che non abbisognano della prova
di un fatto sul quale possano fondarsi e giustificarsi.
La stessa Corte di Cassazione ha affermato che “nella prova per presunzioni non occorre che tra il fatto noto e
il fatto ignoto sussista un legame di assoluta ed esclusiva necessità causale, ma è sufficiente che il fatto da
provare sia desumibile dal fatto noto come conseguenza ragionevolmente possibile secondo un criterio di
normalità” (Cass. Civ. 8 aprile 2004, n. 6899).
Il secondo comma dell’art. 2729 c.c. stabilisce inoltre che “le presunzioni non si possono ammettere nei casi in
cui la legge esclude la prova per testimoni”.

Cenni sui singoli mezzi di prova nel processo civile

All’interno del processo civile assumono grande rilevanza le prove precostituite, così
definite perché hanno la caratteristica di essere state formate al di fuori del processo e di
entrarvi per effetto della loro produzione a opera delle parti (per esempio le prove
documentali).
Le principali prove precostituite sono le seguenti.
Atto pubblico. In base all’articolo 2699 c.c., è il documento redatto, con le richieste
formalità, da un notaio o da altro pubblico ufficiale autorizzato ad attribuirgli pubblica fede
nel luogo dove l’atto è formato. Sul piano dell’efficacia, l’atto pubblico fa piena prova,
sino a querela di falso, della provenienza del documento dal pubblico ufficiale che lo ha
formato, nonché delle dichiarazioni delle parti e degli altri fatti che il pubblico ufficiale
attesta essere avvenuti alla sua presenza.
NOTA
La querela di falso introduce un procedimento, disciplinato dagli artt. 221-227 c.p.c., che “consiste nell’accertare
 la genuinità di un documento, la sua effettiva provenienza o attribuzione alla persona che se ne dichiara autore,
al fine di predisporre uno strumento probatorio irrefutabile” (Cass. Civ. 28 luglio 1972, n. 2591).

Scrittura privata. È il documento munito di sottoscrizione autografa che, ai sensi

dell’articolo 2702 c.c., fa piena prova, fino a querela di falso, della provenienza delle
dichiarazioni da chi l’ha sottoscritta se colui contro il quale la scrittura è prodotta ne
riconosce la sottoscrizione ovvero se questa è legalmente considerata come riconosciuta. È
opportuno precisare che l’efficacia di prova legale della scrittura privata della quale non
sia stata disconosciuta la sottoscrizione è limitata alla provenienza delle dichiarazioni di
chi l’ha sottoscritta, non estendendosi alla verità intrinseca di dette dichiarazioni (Cass.
Civ. 14 luglio 1988, n. 4611). L’articolo 2703 c.c. stabilisce, inoltre, che deve considerarsi
riconosciuta la sottoscrizione autenticata dal notaio o da altro pubblico ufficiale a ciò
autorizzato.
Riproduzioni meccaniche. Sono definite dall’articolo 2712 c.c. come le riproduzioni
fotografiche, informatiche o cinematografiche, le registrazioni fonografiche e, in genere,
ogni altra rappresentazione meccanica di fatti e di cose. Formano piena prova dei fatti e
delle cose rappresentate se colui contro il quale sono prodotte non ne disconosce la
conformità ai fatti o alle cose medesime. Importante al proposito è una recente sentenza
della Corte di Cassazione in materia di riproduzioni informatiche, nella quale la Suprema
Corte ha affermato che “in ordine all’assunta contestazione dei dati del sistema
informatico, è da osservare preliminarmente che, per l’art. 2712, la contestazione esclude
il pieno valore probatorio della riproduzione meccanica, ove abbia per oggetto il rapporto
di corrispondenza tra la realtà e la riproduzione meccanica. Ove la contestazione vi sia
stata, la riproduzione, pur perdendo il suo pieno valore probatorio, conserva tuttavia il
minor valore di un semplice elemento di prova che può essere integrato da ulteriori
elementi” (Cass. Civ. 11 maggio 2005, n. 9884).
In materia di prove precostituite è necessario fare un breve cenno alla disciplina del
documento informatico attualmente contenuta nel Codice dell’Amministrazione Digitale (decreto
legislativo 7 marzo 2005, n. 82 e successive modificazioni). Il Codice è entrato in vigore il 1°
gennaio 2006 con lo scopo di assicurare e regolare la disponibilità, la gestione, l’accesso, la
trasmissione, la conservazione e la fruibilità dell’informazione in modalità digitale utilizzando
con le modalità più appropriate le tecnologie dell’informazione e della comunicazione
all’interno della Pubblica Amministrazione, nei rapporti tra amministrazione e privati e in alcuni
limitati casi, disciplina anche l’uso del documento informatico nei documenti tra privati.
L’articolo 1 di detto codice definisce innanzitutto il documento informatico come “la
rappresentazione informatica di atti, fatti o dati giuridicamente rilevanti”. Sul piano probatorio
il documento informatico da chiunque formato, la registrazione su supporto informatico e la
trasmissione con strumenti telematici (se conformi alle regole tecniche di cui all’art. 71 del
Codice) sono validi e rilevanti agli effetti di legge. Quindi, il documento informatico, cui è stato
chiaramente riconosciuto dalla legge un valore probatorio, può essere validamente prodotto in
giudizio come prova ed essere valutato dal giudice. L’articolo 20 comma 1 bis del Codice
stabilisce inoltre che l’idoneità del documento informatico a soddisfare il requisito della forma
scritta e il suo valore probatorio sono liberamente valutabili in giudizio, tenuto conto delle sue
caratteristiche oggettive di qualità, sicurezza, integrità e immodificabilità.
Particolare valore probatorio assume il documento informatico qualora lo stesso venga
sottoscritto con firma elettronica, ovvero con uno strumento in grado di permettere
l’identificazione informatica del soggetto che lo ha formato.
Il Codice dell’Amministrazione Digitale disciplina quattro differenti tipologie di firma
elettronica che sono così definite (art. 1).
Firma elettronica: l’insieme dei dati in forma elettronica, allegati oppure connessi tramite
associazione logica ad altri dati elettronici, utilizzati come metodo di identificazione
informatica.
Firma elettronica avanzata: insieme di dati in forma elettronica allegati oppure connessi a
un documento informatico che consentono l’identificazione del firmatario del documento e
garantiscono la connessione univoca al firmatario, creati con mezzi sui quali il firmatario
può conservare un controllo esclusivo, collegati ai dati ai quali detta firma si riferisce in
modo da consentire di rilevare se i dati stessi siano stati successivamente modificati.
Firma elettronica qualificata: un particolare tipo di firma elettronica avanzata che sia
basata su un certificato qualificato e realizzata mediante un dispositivo sicuro per la
creazione della firma.
Firma digitale: un particolare tipo di firma elettronica avanzata basata su un certificato
qualificato e su un sistema di chiavi crittografiche, una pubblica e una privata, correlate tra
loro, che consente al titolare tramite la chiave privata e al destinatario tramite la chiave
pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l’integrità
di un documento informatico o di un insieme di documenti informatici.
Sotto il profilo probatorio il Codice dell’Amministrazione Digitale (art. 21) prevede che:
il documento informatico, cui è apposta una firma elettronica, sul piano probatorio è
liberamente valutabile in giudizio, tenuto conto delle sue caratteristiche oggettive di
qualità, sicurezza, integrità e immodificabilità;
il documento informatico sottoscritto con firma elettronica avanzata, qualificata o digitale
(formato nel rispetto delle regole tecniche previste dall’art. 71 del Codice), che
garantiscano l’identificabilità dell’autore, l’integrità e l’immodificabilità del documento,
ha l’efficacia prevista dall’articolo 2702 del Codice Civile (ovvero l’efficacia di una
scrittura privata). L’utilizzo del dispositivo di firma si presume riconducibile al titolare,
 salvo che questi dia prova contraria;
le scritture private di cui all’articolo 1350, primo comma, numeri da 1 a 12, del Codice
Civile (ovvero gli atti che devono farsi per iscritto sotto pena di nullità), se fatte con
documento informatico, sono sottoscritte, a pena di nullità, con firma elettronica qualificata
o con firma digitale, fatto salvo quanto previsto dall’art. 25 del Codice in materia di “firma
autenticata”. Sotto questo profilo il richiamato art. 25 del Codice prevede che si ha per
riconosciuta (ai sensi dell’articolo 2703 del Codice Civile), “la firma elettronica o
qualsiasi altro tipo di firma avanzata autenticata dal notaio o da altro pubblico ufficiale a
ciò autorizzato” (comma 1); “L’autenticazione della firma elettronica, anche mediante
l’acquisizione digitale della sottoscrizione autografa, o di qualsiasi altro tipo di firma
elettronica avanzata consiste nell’attestazione, da parte del pubblico ufficiale, che la firma
è stata apposta in sua presenza dal titolare, previo accertamento della sua identità
personale, della validità dell’eventuale certificato elettronico utilizzato e del fatto che il
documento sottoscritto non è in contrasto con l’ordinamento giuridico” (comma 2).
Il valore giuridico del documento informatico è quindi modulato sulla tipologia delle firme
che (e se) vi sono applicate. A ogni tipologia di firma è applicabile una funzione composta da
due variabili, La prima è inerente il grado di sicurezza del documento informatico, la seconda fa
riferimento al grado di efficacia sostanziale e probatoria del documento informatico.
Il documento privo di firma elettronica è da ritenersi quello con il grado di sicurezza più
basso; questi documenti non consentono di verificare l’identità dell’autore e, al contempo, non
permettono di constatare se i dati riportati abbiano subìto successive modifiche, cancellazioni o
integrazioni, cioè manca di tracciabilità. Viste le limitazioni del documento privo di firma
elettronica, il legislatore ha attribuito a questa tipologia una circoscritta efficacia probatoria
comparabile a quella attribuita alle riproduzioni meccaniche. Questo documento forma quindi
piena prova dei fatti e rappresenta prova legale relativa; il suo valore legale è condizionato,
infatti, alla condotta processuale della parte nei cui confronti viene fatta valere. La rilevanza di
tale tipologia viene appresa solo se si tiene in considerazione che, a oggi, la maggior parte dei
documenti informatici è priva di firma elettronica.
NOTA
Dopo una lunga attesa, è definitivamente entrato in vigore il DPCM 22 febbraio 2013 recante le “Regole tecniche
in materia di generazione, apposizione e verifica delle firme elettroniche avanzate, qualificate e digitali, ai sensi
degli articoli 20, comma 3, 24, comma 4, 28, comma 3, 32, comma 3, lettera b), 35, comma 2, 36, comma 2, e
71”. Con tale decreto, sono state definite le caratteristiche specifiche delle soluzioni di firma elettronica
avanzata. L’articolo 56 prevede che “Le soluzioni di firma elettronica avanzata garantiscono:
a) l’identificazione del firmatario del documento;
b) la connessione univoca della firma al firmatario;
c) il controllo esclusivo del firmatario del sistema di generazione della firma, ivi inclusi i dati biometrici
eventualmente utilizzati per la generazione della firma medesima;
 d) la possibilità di verificare che il documento informatico sottoscritto non abbia subìto modifiche dopo
l’apposizione della firma;
e) la possibilità per il firmatario di ottenere evidenza di quanto sottoscritto;
f) l’individuazione del soggetto di cui all’articolo 55, comma 2, lettera a);
g) l’assenza di qualunque elemento nell’oggetto della sottoscrizione atto a modificarne gli atti, fatti o dati nello
stesso rappresentati;
h) la connessione univoca della firma al documento sottoscritto.
La firma elettronica avanzata generata in violazione di quanto disposto da una o più disposizioni di cui alle
lettere a), b), c), d), e), g), h) del comma 1, non soddisfa i requisiti previsti dagli articoli 20, comma 1-bis, e 21,
comma 2, del Codice.”
Il legislatore ha introdotto una restrizione degli effetti giuridici delle soluzioni di FEA, ai soli soggetti che risultano
direttamente coinvolti in tale processo (soggetto erogatore della soluzione di firma e soggetto firmatario), L’art.
60 prevede infatti che “la firma elettronica avanzata realizzata in conformità con le disposizioni delle presenti
regole tecniche, è utilizzabile limitatamente ai rapporti giuridici intercorrenti tra il sottoscrittore e il soggetto di cui
all’articolo 55, comma 2, lettera a)”. (ovvero i soggetti che erogano soluzioni di firma elettronica avanzata al fine
di utilizzarle nei rapporti intrattenuti con soggetti terzi per motivi istituzionali, societari o commerciali).

Esaurita la breve elencazione delle principali prove precostituite, occorre fare un breve
cenno alle prove che si formano all’interno del processo e che, per tale ragione, vengono
definite prove costituende.
Le prove costituende entrano nel processo solitamente su istanza di parte e, se ammesse dal
giudice, vengono assunte durante la fase istruttoria del processo. Fermo restando che il giudice
non ha di regola il diritto/potere di ricercare direttamente mezzi di prova al fine di conoscere i
fatti oggetto di giudizio, in alcuni casi espressamente stabiliti dalla legge ha però il potere di
richiedere che vengano esperite alcune attività probatorie ulteriori rispetto a quelle richieste
dalle parti (per esempio l’ispezione di persone o cose o la richiesta di informazioni alla
Pubblica Amministrazione). Le principali prove costituende sono elencate di seguito.
La confessione, ovvero la dichiarazione fatta da una parte della verità dei fatti a essa
sfavorevoli e favorevoli all’altra parte (artt. 2730 sgg. c.c.). La confessione, se resa in giudizio,
forma piena prova contro colui che l’ha fatta purché non verta su fatti relativi a diritti non
disponibili (art. 2733 c.c.). La confessione, tuttavia, non è efficace se non proviene da persona
capace di disporre del diritto cui i fatti confessati si riferiscono (art. 2371 c.c.).
Il giuramento, ovvero la dichiarazione sulla verità dei fatti che formano oggetto del giudizio
favorevoli alla parte che lo presta (esattamente il contrario della confessione). Il giuramento è
di due specie:
è decisorio: il giuramento che una parte deferisce all’altra per farne dipendere la decisione
totale o parziale della causa (art. 2736 comma 1 c.c.). L’articolo 234 c.p.c. prevede inoltre
che finché non abbia dichiarato di essere pronta a giurare, la parte alla quale il giuramento
decisorio è stato deferito può riferirlo all’avversario nei limiti fissati dal Codice Civile;
è suppletorio: il giuramento che è deferito d’ufficio dal giudice a una delle parti al fine di
 decidere la causa quando la domanda o le eccezioni non sono pienamente provate, ma non
sono del tutto sfornite di prova, ovvero quello che è deferito al fine di stabilire il valore
della cosa domandata, se non si può accertarlo altrimenti (art. 2736 comma 2 c.c.).
Se è stato prestato il giuramento, deferito o riferito, l’altra parte non è ammessa a provare il
contrario, né può chiedere la revocazione della sentenza qualora il giuramento sia stato
dichiarato falso.
NOTA
“Il giuramento decisorio è una solenne dichiarazione di verità o di scienza resa al giudice da una parte, su
istanza dell’altra, circa l’esistenza o meno di un determinato fatto. Con esso il deferente affida alla lealtà della
controparte l’accertamento di quanto è oggetto della formula all’uopo articolata, onde la prova raggiunta con
l’espletamento di tale mezzo istruttorio deve ritenersi sovrana ed indipendente da ogni altro elemento
processuale contrario” (Cass. Civ. 18 febbraio 1960, n. 272).

L’interrogatorio formale, ossia l’interrogatorio rivolto a provocare la confessione giudiziale

la quale, come visto, forma piena prova contro il confidente. L’articolo 232 c.p.c. stabilisce che
se la parte non si presenta o si rifiuta di rispondere, il giudice, valutato ogni altro elemento di
prova, può ritenere come ammessi i fatti dedotti nell’interrogatorio. La Corte di Cassazione ha
tuttavia stabilito che “nel caso in cui la parte si presenti a rendere l’interrogatorio formale e
neghi, non ammetta o smentisca le circostanze di fatto su cui è chiamato a rispondere, il risultato
negativo dell’interrogatorio costituisce un elemento acquisito al processo che può essere
utilizzato come indizio ai fini della valutazione della prova delle stesse circostanze di fatto
indicate nei capitoli dell’interrogatorio, in concorso con altri elementi istruttori che devono
essere specificamente indicati” (Cass. Civ. 14 ottobre 2005, n. 19964).
La prova testimoniale, che consiste nella narrazione di uno o più fatti della causa fatta al
giudice da un soggetto che non è parte del processo. Non possono essere assunte come testimoni
le persone nella causa aventi un interesse che potrebbe legittimare una loro partecipazione al
giudizio. La prova per testimoni deve essere dedotta dalla parte mediante indicazione specifica
delle persone da interrogare e dei fatti, formulati in capitoli separati, sui quali ciascuna di esse
deve essere interrogata (art. 244 c.p.c.). Gli articoli 2721, 2722 e 2723 c.c. stabiliscono alcune
limitazioni alla possibilità di esperimento della prova testimoniale, con riferimento in
particolare ai contratti, che comunque, in base all’articolo 2724 c.c., è ammessa in ogni caso
quando:
vi è un principio di prova per iscritto (cioè qualsiasi scritto, proveniente dalla persona
contro la quale è diretta la domanda o dal suo rappresentante, che faccia apparire
verosimile il fatto allegato);
il contraente è stato nell’impossibilità morale o materiale di procurarsi una prova scritta o
ha senza sua colpa perduto il documento che gli forniva la prova.
L’ispezione, prevista dall’articolo 118 c.p.c., che fornisce al giudice il potere di ordinare alle
parti e ai terzi di consentire sulla loro persona o sulle cose in loro possesso le ispezioni che
appaiono indispensabili per conoscere i fatti della causa, purché ciò possa compiersi senza
grave danno per la parte o per il terzo e senza costringerli a violare uno dei segreti previsti
negli articoli 351 e 352 del c.p.p. (con la riforma del Codice di Procedura Penale il riferimento
deve essere inteso agli articoli 201 e 202 c.p.p. relativi al segreto professionale e al segreto
d’ufficio). Ai sensi dell’articolo 261 comma 2 c.p.c., per verificare se un fatto possa essersi
verificato in un dato modo il giudice può ordinare di procedere alla riproduzione del fatto
stesso; in tal caso l’ispezione è definita esperimento giudiziale.
L’esibizione. In base all’articolo 210 c.p.c., negli stessi limiti entro i quali può essere
ordinata a norma dell’articolo 118 l’ispezione di cose in possesso di una parte o di un terzo, il
giudice istruttore, su istanza di parte, può ordinare all’altra parte o a un terzo di esibire in
giudizio un documento o altra cosa di cui ritenga necessaria l’acquisizione al processo.
Pur non essendo annoverabile tra i mezzi di prova, occorre fare un breve cenno alla
consulenza tecnica, strumento che seppur non teso a determinare il convincimento del giudice
circa la verità o meno dei fatti, ha la funzione di fornire allo stesso le conoscenze tecniche
specifiche del caso. In base all’articolo 61 c.p.c., quando è necessario il giudice può farsi
assistere, per il compimento di singoli atti o per tutto il processo, da uno o più consulenti di
particolare competenza tecnica; in tal caso la scelta dei consulenti tecnici deve essere
normalmente fatta tra le persone iscritte in albi speciali (formati a norma delle disposizioni di
attuazione al Codice di Procedura Civile). Il consulente compie le indagini che gli sono
richieste dal giudice e fornisce, in udienza e in camera di consiglio, i chiarimenti che il giudice
gli richiede (art. 62 c.p.c.).
NOTA
L’articolo 197 c.p.c. prevede per esempio che, quando lo ritiene opportuno, il presidente inviti il consulente
tecnico ad assistere alla discussione davanti al collegio e a esprimere il suo parere in camera di consiglio in
presenza delle parti, le quali possono chiarire e svolgere le loro ragioni per mezzo dei difensori.

Il consulente tecnico, in particolare, svolge le attività elencate nell’articolo 194 c.p.c.,

ovvero assiste alle udienze alle quali è invitato dal giudice istruttore e compie, anche fuori della
circoscrizione giudiziaria, le indagini che gli sono assegnate da solo o insieme al giudice,
secondo quanto disposto da quest’ultimo. Può, inoltre, essere autorizzato a domandare
chiarimenti alle parti, ad assumere informazioni da terzi e a eseguire piante, calchi e rilievi. Nei
casi in cui interviene il consulente tecnico, le parti possono decidere di nominare propri
consulenti tecnici (consulenti tecnici di parte). Il secondo comma dell’articolo 194 c.p.c.
prevede, infatti, che anche quando il giudice dispone che il consulente compia indagini da solo,
le parti possono intervenire alle operazioni in persona e a mezzo dei propri consulenti tecnici (e
dei difensori), oltre a poter presentare al consulente, per iscritto o a voce, osservazioni e
istanze. Il consulente della parte, oltre ad assistere alle operazioni del consulente del giudice,
partecipa all’udienza e alla camera di consiglio ogni volta che vi interviene il consulente del
giudice, per chiarire e svolgere, con l’autorizzazione del presidente, le sue osservazioni sui
risultati delle indagini tecniche (art. 201 c.p.c.).

La prova in sede penale

L’articolo 111 della Costituzione contiene le disposizioni fondamentali del processo penale
ed è quindi il punto di partenza per poterne comprendere le caratteristiche. In particolare, detto
articolo prevede che:
nel processo penale la legge assicuri che la persona accusata di un reato:
– sia, nel più breve tempo possibile, informata riservatamente della natura e dei motivi
dell’accusa elevata a suo carico;
– disponga del tempo e delle condizioni necessari per preparare la sua difesa;
– abbia la facoltà, davanti al giudice, di interrogare o di far interrogare le persone che
rendono dichiarazioni a suo carico, di ottenere la convocazione e l’interrogatorio di
persone a sua difesa nelle stesse condizioni dell’accusa e l’acquisizione di ogni altro
mezzo di prova a suo favore;
il processo penale venga regolato dal principio del contraddittorio nella formazione della
prova;
la colpevolezza dell’imputato non possa essere provata sulla base di dichiarazioni rese da
chi, per libera scelta, si è sempre volontariamente sottratto all’interrogatorio da parte
dell’imputato o del suo difensore;
la legge regoli i casi in cui la formazione della prova non ha luogo in contraddittorio per
consenso dell’imputato o per accertata impossibilità di natura oggettiva o per effetto di
provata condotta illecita.
Ciò che rileva, in particolare, è il principio del contraddittorio nella formazione della prova,
in base al quale la stessa deve formarsi dialetticamente con l’altra parte nei cui confronti può
essere fatta valere. Da questo principio discende che la prova nel processo penale è
sostanzialmente orale e si forma in giudizio nella fase denominata “dibattimento”, disciplinata
dagli articoli 465 sgg. del Codice di Procedura Penale.
Passando all’esame delle norme generali in materia di prove contenute nel libro terzo del
Codice di Procedura Penale (artt. 187 sgg. c.p.p.), occorre preliminarmente definire quale sia
l’oggetto della prova in sede penale. In base all’articolo 187 c.p.p. possono essere oggetto di
prova i fatti che si riferiscono all’imputazione, alla punibilità e alla determinazione della pena o
della misura di sicurezza. Il giudice, quando è richiesto, può assumere prove non disciplinate
dalla legge nel caso risultino idonee ad assicurare l’accertamento dei fatti e non pregiudichino
la libertà morale della persona (art. 189 c.p.p.). Il Codice di Procedura Penale, quindi, non
prevede un principio di tassatività dei mezzi di prova, consentendo invece al giudice di
ammettere prove che non siano direttamente disciplinate dalla legge, purché le stesse siano
idonee a risalire alla verità dei fatti e non siano lesive della libertà morale della persona.
NOTA
L’articolo 188 c.p.p. prevede espressamente che “non possono essere utilizzati, neppure con il consenso della
persona interessata, metodi o tecniche idonei a influire sulla libertà di autodeterminazione o ad alterare la
capacità di ricordare e di valutare i fatti”.

La Corte di Cassazione Penale, in punto, ha precisato che il giudice, nell’assumere prove non
disciplinate dalla legge a norma dell’articolo 189 c.p.p., è tenuto ad applicare i criteri legali
stabiliti per gli analoghi mezzi di prova tipici, ovvero a ricorrere a consolidate massime di
esperienza o regole di inferenza secondo una disciplina scientifica (Cass. Pen. 12 dicembre
1999, n. 1858).
In relazione ai criteri di ammissione delle prove, l’articolo 190 c.p.p. prevede che le stesse
sono ammesse a richiesta delle parti alle quali è riconosciuto esplicitamente un diritto alla
prova. La legge, tuttavia, stabilisce i casi nei quali le prove possono essere ammesse d’ufficio
dal giudice. Fondamentale in tal senso è la disposizione di cui all’articolo 191 c.p.p., in base al
quale “le prove acquisite in violazione dei divieti stabiliti dalla legge non possono essere
utilizzate”. Il rispetto delle norme in materia di ammissione o di acquisizione probatoria assume
una fondamentale importanza per scongiurare che una prova venga dichiarata inutilizzabile. Lo
stesso articolo prevede, d’altra parte, che “l’inutilizzabilità è rilevabile anche di ufficio in ogni
stato e grado del procedimento”, impedendo quindi che il vizio possa essere in qualche modo
successivamente sanato.
In merito alla valutazione delle prove, principio fondamentale è quello del libero
convincimento del giudice di cui all’articolo 192 c.p.p., il quale stabilisce che lo stesso debba
valutare la prova dando conto nella motivazione dei risultati acquisiti e dei criteri adottati. Il
giudice deve dunque esporre nelle motivazioni le ragioni del proprio convincimento ovvero
l’iter logico seguito per trarre determinate conclusioni dalle prove a sua disposizione. Questa
norma ha la funzione di non rendere assolutamente discrezionale la valutazione del giudice,
permettendo invece una verifica del ragionamento dallo stesso effettuato nella valutazione delle
prove. Il secondo comma del medesimo articolo 192 c.p.p. precisa, inoltre, che il giudice possa
desumere l’esistenza di un fatto da indizi, fermo restando che gli stessi devono essere gravi,
precisi e concordanti (la previsione ricalca la disciplina civilistica delle presunzioni cui si è
fatto cenno nel paragrafo precedente). La Corte di Cassazione Penale ha nel tempo interpretato
la portata dell’articolo 192 c.p.p.; a titolo esemplificativo si ricordano le seguenti pronunce.
Il principio di libera valutazione della prova concerne anche la prova tecnica e, pertanto, il
giudice, quale peritus peritorum, può esprimere il proprio giudizio in motivato contrario
avviso rispetto a quello del perito. (Cass. Pen. 19 febbraio 2013 n. 12991).
 “Nella valutazione probatoria giudiziaria – così come, secondo la più moderna
epistemologia, in ogni procedimento di accertamento (scientifico, storico e così via) – è
corretto e legittimo fare ricorso alla verosimiglianza ed alle massime di esperienza, ma,
affinché il giudizio di verosimiglianza conferisca al dato preso in esame valore di prova, è
necessario che si possa escludere plausibilmente ogni alternativa spiegazione che invalidi
l’ipotesi all’apparenza più verosimile. Ove così non sia, il suddetto dato si pone
semplicemente come indizio da valutare insieme a tutti gli altri elementi risultanti dagli
atti” (Cass. Pen. 21 ottobre 2004, n. 4652).
“In sede di motivazione della sentenza di condanna la prospettazione di ipotesi deve
certamente ritenersi vietata quando il giudice intenda trarre da esse, e non da fatti
obiettivamente accertati, la prova della colpevolezza dell’imputato. Un tale divieto, però,
non sussiste né potrebbe logicamente sussistere quando, in presenza di altri elementi non
ipotetici atti a dimostrare la detta colpevolezza, il giudice debba affrontare l’esame delle
risultanze che si assumono idonee a vanificare la loro valenza. In tal caso, infatti, altro non
potrà né dovrà fare se non verificare, ricorrendo necessariamente a delle ipotesi, se le
dette risultanze siano in effetti compatibili o meno con la ricostruzione dei fatti in chiave
accusatoria, la quale, peraltro, anche in caso di esito positivo di detta verifica, rimarrà
comunque esclusivamente basata sulle prove acquisite e non sulle ipotesi formulate in
funzione della verifica stessa” (Cass. Pen. 27 marzo 1992, n. 3754).
“Il giudice di merito è libero di valutare le prove raccolte, organizzandole e dando a
ciascuna di esse, come pure al loro complesso, il peso ed il significato ritenuti più
opportuni. La relativa motivazione in cui si estrinseca tale operazione intellettuale è
insindacabile in sede di legittimità se rispetta le regole della logica ed è frutto di
valutazione esatta ed aderente alle risultanze processuali ed ai principi generali che
regolano la valutazione della prova” (Cass. Pen. 14 febbraio 1992, n. 8040).
Esaurita la trattazione dei principi generali in materia di ammissione, formazione e
valutazione della prova in sede penale, è opportuno prendere in esame, come fatto nella parte
avente a oggetto il processo civile, i principali mezzi di prova disciplinati dal Codice di
Procedura Penale, al fine di evidenziarne le caratteristiche peculiari. Anche in questo caso
l’esposizione non ha una pretesa di esaustività e saranno prese in considerazione, tra le prove
disciplinate dal codice di procedura, solo quelle strettamente utili a comprendere i profili
giuridici della Digital Forensics.
In primo luogo, il Codice di Procedura Penale distingue tra mezzi di prova e mezzi di ricerca
della prova. I mezzi di prova sono gli elementi direttamente utilizzabili dal giudice ai fini della
formazione del suo libero convincimento. I mezzi di ricerca della prova, invece, sono strumenti
di indagine che consentono di acquisire la prova. Ne consegue che le norme sui mezzi di prova
si rivolgono prevalentemente al giudice, mentre quelle sui mezzi di ricerca della prova si
rivolgono al pubblico ministero (e per quanto di competenza alla polizia giudiziaria). La Corte
di Cassazione ha, infatti, chiarito che “le nozioni di mezzo di prova e mezzo di ricerca della
prova sono tra loro nettamente differenziate anche sotto il profilo normativo, come è dato
evincere dal fatto che tutti i mezzi di prova – ossia le fonti di prova, personali o reali – sono
ricompresi nel titolo secondo del libro terzo del Codice di Procedura Penale, i mezzi di ricerca
della prova trovano una loro specifica ed autonoma disciplina nel libro terzo. Il ruolo che il
nuovo codice di rito assegna al giudice gli impedisce di svolgere, di regola, attività di ricerca
della prova, essendo ciò demandato alle parti”. L’attività di ricerca della prova è dunque tipica
della fase delle indagini preliminari durante la quale, come visto, l’autorità giudiziaria,
acquisita una notizia di reato, ricerca gli elementi utili ai fini del successivo ed eventuale
esercizio dell’azione penale.
Tra i mezzi di prova mezzi di prova disciplinati dal codice si evidenziano i seguenti.
Testimonianza: il testimone è esaminato sui fatti che costituiscono oggetto di prova. Non
può deporre sulla moralità dell’imputato, salvo che si tratti di fatti specifici, idonei a
qualificarne la personalità in relazione al reato e alla pericolosità sociale (art. 194 c.p.p.).
In sede di valutazione della prova testimoniale, la Corte di Cassazione ha evidenziato che
“le dichiarazioni di un testimone, per essere positivamente utilizzate da un giudice, devono
risultare credibili, oltre che avere ad oggetto fatti di diretta cognizione e specificamente
indicati” (Cass. Pen. 28 maggio 1997, n. 4946). Norme particolari sono dettate per la
testimonianza indiretta: ai sensi dell’articolo 195 c.p.p., quando il testimone si riferisce,
per la conoscenza dei fatti, ad altre persone, il giudice, a richiesta di parte o di ufficio,
dispone che queste siano chiamate a deporre. La mancata osservanza di questa
disposizione rende inutilizzabili le dichiarazioni relative ai fatti di cui il testimone abbia
avuto conoscenza da altre persone, salvo che l’esame di queste per morte, infermità o
irreperibilità.
Esperimenti giudiziali: consistono nella riproduzione, per quanto possibile, della
situazione in cui il fatto si afferma o si ritiene essere avvenuto (art. 218 c.p.p.). Si
consideri che la Corte di Cassazione Penale ha precisato che “l’esperimento giudiziale di
cui all’art. 218 c.p.p. può essere disposto solo quando sia possibile riprodurre il fatto,
oggetto della prova, nelle condizioni in cui si afferma o si ritiene essere avvenuto;
l’impossibilità di una sua ricostruzione in termini di sostanziale identità rispetto ai dati di
riferimento, infatti, rende del tutto inutile, se non addirittura fuorviante ai fini del giudizio,
la verifica attuata mediante controllo sperimentale, con la conseguenza che non può
disporsi un’operazione di cui si conosca l’inutilizzabilità del risultato come mezzo di
prova” (Cass. Pen. 9 marzo 1995, n. 2380).
Perizia: è ammessa ai sensi dell’articolo 220 c.p.p. quando occorre svolgere indagini o
 acquisire dati o valutazioni che richiedono specifiche competenze tecniche, scientifiche o
artistiche. La perizia può essere disposta anche d’ufficio dal giudice con ordinanza
motivata, contenente la nomina del perito, la sommaria enunciazione dell’oggetto delle
indagini e l’indicazione del giorno, dell’ora e del luogo fissati per la comparizione del
perito. Il giudice dispone la citazione del perito, dà gli opportuni provvedimenti per la
comparizione delle persone sottoposte all’esame del perito e adotta tutti gli altri
provvedimenti che si rendono necessari per l’esecuzione delle operazioni peritali (art. 224
c.p.p.). Disposta la perizia, il pubblico ministero e le parti private hanno facoltà di
nominare propri consulenti tecnici in numero non superiore, per ciascuna parte, a quello
dei periti (art. 225 c.p.p.). La Corte di Cassazione Penale ha più volte stabilito che “in
tema di controllo sulla motivazione, il giudice che ritenga di aderire alle conclusioni del
perito d’ufficio, in difformità da quelle del consulente di parte, non può essere gravato
dell’obbligo di fornire autonoma dimostrazione dell’esattezza scientifica delle prime e
dell’erroneità, per converso, delle altre, dovendosi al contrario considerare sufficiente che
egli dimostri di avere comunque valutato le conclusioni del perito d’ufficio, senza ignorare
le argomentazioni del consulente; ne consegue che può ravvisarsi vizio di motivazione solo
se queste ultime siano tali da dimostrare in modo assolutamente lampante e inconfutabile la
fallacità delle conclusioni peritali” (Cass. Pen. 11 agosto 2004, n. 34379). Anche quando
non è disposta la perizia, l’articolo 233 c.p.p. consente alle parti di nominare, in numero
non superiore a due, propri consulenti tecnici, i quali possono esporre al giudice il proprio
parere, anche presentando memorie a norma dell’articolo 121. Il giudice, inoltre, a
richiesta del difensore, può autorizzare il consulente tecnico di una parte privata a
esaminare le cose sequestrate nel luogo in cui esse si trovano, a intervenire alle ispezioni,
ovvero a esaminare l’oggetto delle ispezioni alle quali il consulente non è intervenuto.

NOTA
L’articolo 121 c.p.p. stabilisce che “in ogni stato e grado del procedimento le parti e i difensori possono
presentare al giudice memorie o richieste scritte, mediante deposito nella cancelleria”.

Il giudice, inoltre, a richiesta del difensore, può autorizzare il consulente tecnico di una parte
privata a esaminare le cose sequestrate nel luogo in cui esse si trovano, a intervenire alle
ispezioni, ovvero a esaminare l’oggetto delle ispezioni alle quali il consulente non è
intervenuto.
Prova documentale: in base all’articolo 234 c.p.p. “è consentita l’acquisizione di scritti o
di altri documenti che rappresentano fatti, persone o cose mediante la fotografia, la
cinematografia, la fonografia o qualsiasi altro mezzo”.
I mezzi di ricerca della prova disciplinati dal codice sono invece i seguenti.
Ispezioni: l’articolo 244 c.p.p. prevede che:
 – l’ispezione delle persone, dei luoghi e delle cose sia disposta con decreto motivato del
pubblico ministero quando occorre accertare le tracce e gli altri effetti materiali del reato;
– se il reato non ha lasciato tracce o effetti materiali, o se questi sono scomparsi o sono
stati cancellati o dispersi, alterati o rimossi, l’autorità giudiziaria descrive lo stato attuale
e, in quanto possibile, verifica quello preesistente curando anche di individuare modo,
tempo e cause delle eventuali modificazioni.
L’autorità giudiziaria in sede di ispezione può disporre rilievi segnaletici, descrittivi e
fotografici e ogni altra operazione tecnica “anche in relazione a sistemi informatici o telematici,
adottando misure tecniche dirette ad assicurare la conservazione dei dati originali e ad
impedirne l’alterazione” (le parole tra virgolette sono state aggiunte dalla sopra menzionata
legge 18 marzo 2008, n. 48 recante Ratifica ed esecuzione della Convenzione del Consiglio
d’Europa sulla criminalità informatica, fatta a Budapest il 23 novembre 2001, e norme di
adeguamento dell’ordinamento interno).
Perquisizioni (art. 247 c.p.p.): sono disposte con decreto motivato del pubblico ministero
(comma 2) e possono essere personali o locali. In particolare:
– quando vi è fondato motivo di ritenere che taluno occulti sulla persona il corpo del reato
o cose pertinenti al reato è disposta perquisizione personale. Quando, invece, vi è fondato
motivo di ritenere che tali cose si trovino in un determinato luogo ovvero che in esso possa
eseguirsi l’arresto dell’imputato o dell’evaso, è disposta perquisizione locale (comma 1);
– quando vi è fondato motivo di ritenere che dati, informazioni, programmi informatici o
tracce comunque pertinenti al reato si trovino in un sistema informatico o telematico,
ancorché protetto da misure di sicurezza, ne è disposta la perquisizione, adottando misure
tecniche dirette ad assicurare la conservazione dei dati originali e ad impedirne
l’alterazione (comma 1 bis, anch’esso inserito dalla legge 18 marzo 2008, n. 48);
l’autorità giudiziaria può procedere personalmente ovvero disporre che l’atto sia compiuto da
ufficiali di polizia giudiziaria delegati con lo stesso decreto (comma 3).
Sequestri: l’articolo 253 c.p.p. prevede che:
– l’autorità giudiziaria dispone con decreto motivato il sequestro del corpo del reato e
delle cose pertinenti al reato necessarie per l’accertamento dei fatti (comma 1);
– il corpo del reato sono le cose sulle quali o mediante le quali il reato è stato commesso,
nonché le cose che ne costituiscono il prodotto, il profitto o il prezzo (comma 2);
– al sequestro procede personalmente l’autorità giudiziaria ovvero un ufficiale di polizia
giudiziaria delegato con lo stesso decreto (comma 3).
NOTA
La locuzione “che costituiscono il prodotto del reato, il profitto o il prezzo” comprende sia le cose acquisite
direttamente con il reato, o da queste create, sia qualsiasi vantaggio, patrimoniale e non patrimoniale, tratto dal
 reato, sia i beni valutabili economicamente dati o promessi al colpevole per la consumazione del reato (Cass.
Pen. 17 dicembre 1990, n. 6331).

Ancora una volta la Corte di Cassazione Penale ha contribuito a chiarire la fondamentale

distinzione contenuta nell’articolo 253 c.p.p. sopra menzionato tra corpo del reato e cose
pertinenti al reato. In base alla stessa (Cass. Pen. 22 gennaio 1997, n. 4421), il corpo del reato
comprende le cose che sono in rapporto diretto e immediato con l’azione delittuosa. La nozione
di cose pertinenti al reato comprende invece le cose che sono in rapporto indiretto con la
fattispecie concreta e sono strumentali, secondo i principi generali della libera prova e del
libero convincimento del giudice, all’accertamento dei fatti.
NOTA
Sempre in base alla sentenza citata, nella dizione di cose pertinenti al reato vanno ricomprese “le cose
necessarie sia alla dimostrazione del reato e delle modalità di preparazione ed esecuzione, sia alla
conservazione delle tracce, all’identificazione del colpevole, all’accertamento del movente e alla determinazione
dell’ante factum e del post factum, comunque ricollegabili al reato, pur se esterni all’iter criminis, purché
funzionali alla finalità perseguita, cioè all’accertamento del fatto ed all’individuazione dell’autore”.

Sempre in tema di sequestro è importante soffermarsi brevemente sull’articolo 254 c.p.p. che
si riferisce al sequestro di corrispondenza. Questo articolo è stato anch’esso modificato dalla
legge 48/2008 e nell’attuale formulazione prevede che:
presso coloro che forniscono servizi postali, telegrafici, telematici o di telecomunicazioni
è consentito procedere al sequestro di lettere, pieghi, pacchi, valori, telegrammi e altri
oggetti di corrispondenza, anche se inoltrati per via telematica, che l’autorità giudiziaria
abbia fondato motivo di ritenere spediti dall’imputato o a lui diretti, anche sotto nome
diverso o per mezzo di persona diversa, o che comunque possono avere relazione con il
reato (comma 1);
quando al sequestro procede un ufficiale di polizia giudiziaria, questi deve consegnare
all’autorità giudiziaria gli oggetti di corrispondenza sequestrati, senza aprirli o alterarli e
senza prendere altrimenti conoscenza del loro contenuto (comma 2);
le carte e gli altri documenti sequestrati che non rientrano fra la corrispondenza
sequestrabile sono immediatamente restituiti all’avente diritto e non possono comunque
essere utilizzati (comma 3).
NOTA
Armando Macrillò (“Le nuove disposizioni in tema di sequestro probatorio e di custodia ed assicurazione dei dati
informatici”, in Diritto dell’Internet n. 5/2008, ha rilevato tuttavia come “le modifiche apportate all’art. 254 comma
1 c.p.p. presentano una valenza alquanto limitata, in quanto, a rigore, risulta suscettibile d’essere sequestrata
solo la corrispondenza elettronica immessa nel sistema di comunicazione e che si trovi temporaneamente
allocata presso il gestore o fornitore del servizio telematico e non ancora trasmessa al destinatario. Nulla
impedisce che la e-mail registrata nel computer del service provider (ossia del server di posta elettronica) in
attesa di essere comunicata al provider del destinatario, diverso da quello del mittente, possa essere sottoposta
a sequestro con le modalità di cui all’art. 254 c.p.p.; si tratta peraltro com’è evidente di un’eventualità del tutto
remota, in considerazione dei tempi rapidissimi, e quindi della breve latenza, con cui il messaggio
 immagazzinato dal server viene smistato” .

L’articolo 366 comma 1 c.p.p., così come modificato dalla legge 397/2000, prevede la
facoltà per il difensore di esaminare le cose sequestrate nel luogo in cui esse si trovano, e, se si
tratta di documenti, di estrarne copia.
Intercettazioni di conversazioni o comunicazioni: ai sensi dell’articolo 266 c.p.p.,
l’intercettazione di conversazioni o comunicazioni telefoniche e di altre forme di
telecomunicazione è consentita nei procedimenti relativi ai seguenti reati:
– delitti non colposi per i quali è prevista la pena dell’ergastolo o della reclusione
superiore nel massimo a cinque anni determinata a norma dell’articolo 4;
– delitti contro la pubblica amministrazione per i quali è prevista la pena della reclusione
non inferiore nel massimo a cinque anni determinata a norma dell’articolo 4;
– delitti concernenti sostanze stupefacenti o psicotrope;
– delitti concernenti le armi e le sostanze esplosive;
– delitti di contrabbando;
– reati di ingiuria, minaccia, usura, abusiva attività finanziaria, abuso di informazioni
privilegiate, manipolazioni del mercato, molestia o disturbo alle persone con il mezzo del
telefono;
– delitti previsti dall’articolo 600 ter, terzo comma, del c.p. (pornografia minorile) anche
se relativi al materiale pornografico di cui all’articolo 600 quater.1 del medesimo codice;
– delitti previsti dagli articoli 444 (Commercio di sostanze alimentari nocive), 473
(Contraffazione, alterazione o uso di marchi o segni distintivi ovvero di brevetti, modelli,
disegni), 474 (introduzione nello Stato e commercio di prodotti con segni falsi), 515
(Frode nell’esercizio del commercio), 516 (Vendita di sostanze alimentari non genuine) e
517 quater (Contraffazione di indicazioni geografiche o denominazioni di origine dei
prodotti agroalimentari) del Codice Penale.
NOTA
Ai sensi dell’articolo 4 c.p.p. non si deve tener conto della continuazione, della recidiva e delle circostanze del
reato, fatta eccezione delle circostanze aggravanti per le quali la legge stabilisce una pena di specie diversa da
quella ordinaria del reato e di quelle a effetto speciale.

Negli stessi casi è consentita l’intercettazione di comunicazioni tra presenti. Tuttavia, qualora
queste avvengano nei luoghi indicati dall’articolo 614 c.p.p. (abitazioni, altri luoghi di privata
dimora e loro appartenenze), l’intercettazione è consentita solo se vi è fondato motivo di
ritenere che ivi si stia svolgendo l’attività criminosa. In relazione all’intercettazione di
comunicazioni informatiche o telematiche, l’articolo 266 bis c.p.p. prevede che “nei
procedimenti relativi ai reati indicati nell’art. 266, nonché a quelli commessi mediante
l’impiego di tecnologie informatiche o telematiche, è consentita l’intercettazione del flusso di
comunicazioni relativo a sistemi informatici o telematici ovvero intercorrente tra più sistemi”.
Salvo i casi di urgenza, il pubblico ministero deve richiedere al giudice per le indagini
preliminari l’autorizzazione a disporre le intercettazioni. L’autorizzazione è data con decreto
motivato quando vi sono gravi indizi di reato e l’intercettazione è assolutamente indispensabile
ai fini della prosecuzione delle indagini (art. 267 c.p.p.).
Nella trattazione dei mezzi di ricerca della prova è opportuno dare atto in questa sede di
alcune ulteriori innovazioni apportate della legge n. 48/2008. Ci si riferisce, in primo luogo,
alle modifiche introdotte all’art. 352 c.p.p. relativo alle perquisizioni personali o locali che in
talune circostanze durante le indagini preliminari possono essere poste in essere su iniziativa
degli ufficiali di polizia giudiziaria. Il primo comma di tale articolo prevede che “nella
flagranza del reato o nel caso di evasione, gli ufficiali di polizia giudiziaria procedono a
perquisizione personale o locale quando hanno fondato motivo di ritenere che sulla persona si
trovino occultate cose o tracce pertinenti al reato che possono essere cancellate o disperse
ovvero che tali cose o tracce si trovino in un determinato luogo o che ivi si trovi la persona
sottoposta alle indagini o l’evaso”, mentre il secondo comma prevede che “quando si deve
procedere alla esecuzione di un’ordinanza che dispone la custodia cautelare o di un ordine che
dispone la carcerazione nei confronti di persona imputata o condannata per uno dei delitti
previsti dall’articolo 380 (delitti per i quali è previsto l’arresto in flagranza) ovvero al fermo di
una persona indiziata di delitto, gli ufficiali di polizia giudiziaria possono altresì procedere a
perquisizione personale o locale se ricorrono i presupposti indicati nel comma 1 e sussistono
particolari motivi di urgenza che non consentono la emissione di un tempestivo decreto di
perquisizione”. La legge 48/2008 ha introdotto nell’articolo in questione il comma 1 bis in base
al quale “nella flagranza del reato, ovvero nei casi di cui al comma 2 quando sussistono i
presupposti e le altre condizioni ivi previsti, gli ufficiali di polizia giudiziaria, adottando misure
tecniche dirette ad assicurare la conservazione dei dati originali e ad impedirne l’alterazione,
procedono altresì alla perquisizione di sistemi informatici o telematici, ancorché protetti da
misure di sicurezza, quando hanno fondato motivo di ritenere che in questi si trovino occultati
dati, informazioni, programmi informatici o tracce comunque pertinenti al reato che possono
essere cancellati o dispersi”.
In secondo luogo si evidenzia inoltre che è stato oggetto di modifiche anche l’art. 354 c.p.p.
(Accertamenti urgenti sui luoghi, sulle cose e sulle persone. Sequestro) in base al quale,
nell’attuale versione:
gli ufficiali e gli agenti di polizia giudiziaria curano che le tracce e le cose pertinenti al
reato siano conservate e che lo stato dei luoghi e delle cose non venga mutato prima
dell’intervento del pubblico ministero (comma 1);
se vi è pericolo che le cose, le tracce e i luoghi indicati nel comma 1 si alterino o si
disperdano o comunque si modifichino e il pubblico ministero non può intervenire
tempestivamente, ovvero non ha ancora assunto la direzione delle indagini, gli ufficiali di
 polizia giudiziaria compiono i necessari accertamenti e rilievi sullo stato dei luoghi e delle
cose. In relazione ai dati, alle informazioni e ai programmi informatici o ai sistemi
informatici o telematici, gli ufficiali della polizia giudiziaria adottano, altresì, le misure
tecniche o impartiscono le prescrizioni necessarie ad assicurarne la conservazione e ad
impedirne l’alterazione e l’accesso e provvedono, ove possibile, alla loro immediata
duplicazione su adeguati supporti, mediante una procedura che assicuri la conformità
della copia all’originale e la sua immodificabilità. Se del caso, sequestrano il corpo del
reato e le cose a questo pertinenti (comma 2, con in corsivo le parti oggetto di modifica).
In terzo luogo si evidenziano le seguenti ulteriori modifiche apportate dalla legge n. 48/2008
in materia di custodia delle cose sequestrate e di apposizione dei sigilli sulle stesse. L’art. 259
c.p.p. prevede al primo comma che “le cose sequestrate sono affidate in custodia alla
cancelleria o alla segreteria. Quando ciò non è possibile o non è opportuno, l’autorità
giudiziaria dispone che la custodia avvenga in luogo diverso, determinandone il modo e
nominando un altro custode idoneo a norma dell’articolo 120”. Al secondo comma di questo
articolo è stato aggiunto un paragrafo in base al quale “quando la custodia riguarda dati,
informazioni o programmi informatici, il custode è altresì avvertito dell’obbligo di impedirne
l’alterazione o l’accesso da parte di terzi, salva, in quest’ultimo caso, diversa disposizione
dell’autorità giudiziaria”. L’articolo 260 c.p.p. stabilisce ora in via generale che “le cose
sequestrate si assicurano con il sigillo dell’ufficio giudiziario e con le sottoscrizioni
dell’autorità giudiziaria e dell’ausiliario che la assiste ovvero, in relazione alla natura delle
cose, con altro mezzo, anche di carattere elettronico o informatico [le parole in corsivo sono
state inserite dalla legge n. 48/2008], idoneo a indicare il vincolo imposto a fini di giustizia”. Il
secondo comma prevede inoltre che “l’autorità giudiziaria fa estrarre copia dei documenti e fa
eseguire fotografie o altre riproduzioni delle cose sequestrate che possono alterarsi o che sono
di difficile custodia, le unisce agli atti e fa custodire in cancelleria o segreteria gli originali dei
documenti, disponendo, quanto alle cose, in conformità dell’articolo 259”. A quest’ultimo
comma è stato aggiunto un ulteriore paragrafo in base al quale “quando si tratta di dati, di
informazioni o di programmi informatici, la copia deve essere realizzata su adeguati supporti,
mediante procedura che assicuri la conformità della copia all’originale e la sua
immodificabilità; in tali casi, la custodia degli originali può essere disposta anche in luoghi
diversi dalla cancelleria o dalla segreteria”.
NOTA
Armando Macrillò (op. cit.), in merito a quest’ultima modifica, pur apprezzandone la precisazione effettuata, ha
rilevato che “il legislatore nel prescrivere la realizzazione di copie ‘su adeguati supporti, mediante procedura che
assicuri la conformità della copia all’originale e la sua immodificabilità’ avrebbe potuto dettare, magari anche con
un intervento ‘mirato’ sulle norme di attuazione del c.p.p., una traccia di protocollo generale per la duplicazione e
la conservazione dei dati, delle informazioni e dei programmi informatici sottoposti a sequestro”.

Esaurita la descrizione dei principali mezzi di prova e mezzi di ricerca della prova, si ritiene
opportuno fare ancora qualche considerazione sull’attività di indagine del pubblico ministero e
in particolare sugli accertamenti tecnici, che assumono grande rilevanza nel contesto della
Digital Forensics. L’articolo 359 c.p.p. prevede che il pubblico ministero, quando procede ad
accertamenti per cui sono necessarie specifiche competenze, possa nominare e avvalersi di
consulenti che non possono rifiutare la loro opera. Per comprendere la portata di questa norma
occorre chiarire il concetto di accertamento, che non è costituito dalla constatazione o dalla
raccolta di dati materiali pertinenti al reato e alla sua prova, dal loro studio e dalla relativa
elaborazione critica. Tipico caso di accertamento è l’esame dei supporti informatici posti sotto
sequestro probatorio durante le indagini preliminari. In merito a tale tipologia di accertamenti si
discute in dottrina se gli stessi abbiano o meno natura irripetibile ai fini dell’applicazione
dell’articolo 360 c.p.p. (accertamenti tecnici non ripetibili), per il quale quando gli
accertamenti riguardano persone, cose o luoghi il cui stato è soggetto a modificazione, il
pubblico ministero deve avvisare senza ritardo la persona sottoposta alle indagini, la persona
offesa dal reato e i difensori del giorno, dell’ora e del luogo fissati per il conferimento
dell’incarico ai propri consulenti e della facoltà di nominare a loro volta consulenti tecnici. I
difensori, nonché i consulenti tecnici eventualmente nominati, hanno la facoltà di assistere al
conferimento dell’incarico, di partecipare agli accertamenti e di formulare osservazioni e
riserve. L’effettuazione di un accertamento tecnico irripetibile senza il rispetto degli
adempimenti di cui sopra comporta la sanzione dell’inutilizzabilità dei risultati dello stesso in
sede dibattimentale.
Prima di passare all’analisi delle prove in sede di processo lavoristico, occorre fare un
breve cenno alle cosiddette “indagini difensive”. Il nuovo Codice di Procedura Penale entrato in
vigore nel 1988 ha infatti valorizzato il principio di parità tra accusa e difesa, attribuendo ai
difensori la facoltà di svolgere attività investigative al fine di ricercare elementi di prova in
favore dei propri assistiti. Tuttavia, solo con l’approvazione della legge 7 dicembre 2000, n.
397 (Disposizioni in materia di indagini difensive) l’attività investigativa del difensore è stata
dettagliatamente procedimentalizzata e ha quindi ottenuto un riconoscimento che è oggi possibile
definire completo (le norme che riguardano le investigazioni difensive introdotte dalla legge
397/2000 sono contenute nel titolo VII del libro quinto del Codice di Procedura Penale agli
articoli da 391 bis a 391 decies). Al difensore (ma anche al sostituto, agli investigatori privati
autorizzati e ai consulenti tecnici) è quindi consentito di:
conferire, ricevere dichiarazioni o assumere informazioni dalle persone in grado di riferire
circostanze utili ai fini dell’attività investigativa (art. 391 bis c.p.p.);
richiedere documentazione alla Pubblica Amministrazione (art. 391 quater c.p.p.);
effettuare accessi per prendere visione dello stato dei luoghi e delle cose ovvero per
procedere alla loro descrizione o per eseguire rilievi tecnici, grafici, planimetrici,
fotografici o audiovisivi (art. 391 sexies c.p.p.);
 accedere a luoghi privati o non aperti al pubblico. Se non vi è il consenso di chi ne ha la
disponibilità, l’accesso deve essere autorizzato con decreto motivato che ne specifichi le
concrete modalità. Non è consentito l’accesso ai luoghi di abitazione e loro pertinenze,
salvo che sia necessario ricercare le tracce e gli altri effetti materiali del reato (art. 391
septies c.p.p.).

NOTA
La Corte di Cassazione Penale ha specificato che “in tema di indagini difensive, la possibilità di accesso ai
luoghi privati o non aperti al pubblico ai sensi dell’articolo 391 septies c.p.p. prevede per il difensore
esclusivamente la possibilità di ispezione dei luoghi, ma non i poteri di perquisizione al fine di acquisire
documentazione” (Cass. Pen. 24 novembre 2005, n. 42588).

La legge 397/2000 non solo, come osservato, ha previsto la possibilità per il difensore di
compiere specifici atti di indagine, ma ha anche sancito il potere per il difensore di documentare
l’attività investigativa svolta e la conseguente parificazione degli atti redatti dal difensore a
quelli giudiziari.
Di particolare rilevanza è l’attività investigativa preventiva prevista dall’articolo 391 nonies
c.p.p. introdotto anch’esso dalla legge 397/2000. Ai sensi di quest’ultimo articolo il difensore, o
su incarico di quest’ultimo il sostituto, l’investigatore privato autorizzato e il consulente,
possono svolgere investigazioni per ricercare elementi di prova a favore del proprio assistito,
per l’eventualità che si instauri un procedimento penale. La medesima norma prevede due
limitazioni:
1. che il difensore abbia precedentemente ricevuto apposito mandato rilasciato con
sottoscrizione autenticata e contenente l’indicazione dei fatti ai quali si riferisce;
2. che l’attività investigativa preventiva non riguardi atti che richiedono l’autorizzazione o
l’intervento dell’autorità giudiziaria.
La norma in commento consente, da una parte, al soggetto che non ha avuto ancora conoscenza
della sua sottoposizione alle indagini da parte dell’autorità giudiziaria di conferire mandato al
difensore per eseguire investigazioni preventive; dall’altra, alla persona offesa dal reato di
raccogliere elementi utili per la presentazione di una eventuale denuncia o querela o per fornire
successivamente all’autorità giudiziaria un apporto alle indagini svolte dalla medesima.
Il diritto di compiere indagini difensive preventive è sovente valutato dalle aziende come
strumento utile di tutela. In particolare, le aziende di grandi dimensioni utilizzano sempre più
spesso questo strumento per raccogliere elementi utili per individuare il responsabile di un
illecito subìto, sia esso compiuto da un collaboratore o da un terzo. Con particolare riferimento
agli illeciti compiuti mediante lo strumento informatico e telematico, lo svolgimento di indagini
difensive appare particolarmente importante stante la necessità di acquisire velocemente
informazioni rilevanti al fine di procedere contro un determinato soggetto. Naturalmente tali
indagini, che hanno la finalità di verificare la sussistenza di elementi che potrebbero giustificare
una denuncia o querela (e/o un’azione civile), postulano che le stesse vengano effettuate da
soggetti dotati di elevate competenze sia informatiche sia legali, per evitare un’alterazione degli
elementi raccolti (o una loro non valenza in assenza di valide procedure di acquisizione) che
finirebbe per danneggiare ulteriormente la posizione del soggetto leso dall’illecito. Risulta
quindi opportuno analizzare quali siano le azioni esperibili nel corso delle attività di indagine
difensiva preventiva. Sotto questo profilo occorre considerare che, restando esclusi gli atti che
richiedono l’intervento dell’autorità giudiziaria (dal momento che in questa fase non è stato
ancora avviato un procedimento penale), risultano per esempio esperibili dai soggetti sopra
menzionati accessi a luoghi aperti al pubblico o luoghi privati, con il consenso di chi ne ha la
disponibilità, al fine di “prendere visione dello stato dei luoghi e delle cose, ovvero per
procedere alla loro descrizione o per eseguire rilievi tecnici, grafici, planimetrici, fotografici o
audiovisivi” (art. 391 sexies c.p.p.). In considerazione quindi della delicatezza di questo genere
di accertamenti, il terzo comma dell’art. 391 decies prevede che nel corso di indagini difensive,
“quando si tratta di accertamenti tecnici non ripetibili, il difensore deve darne avviso, senza
ritardo, al pubblico ministero per l’esercizio delle facoltà previste, in quanto compatibili,
dall’articolo 360”.
Nel corso di indagini difensive preventive, è evidente come l’attività investigativa non possa
che arrestarsi di fronte alla necessità di effettuare accertamenti tecnici irripetibili, in attesa
dell’eventuale iscrizione di una notizia di reato. Si ritiene invece che in questa fase possano
essere validamente effettuati accertamenti di natura ripetibile.

La prova in sede lavoristica

Un breve cenno merita anche la disciplina della prova in sede lavoristica, che presenta alcune
peculiarità rispetto al procedimento civile. Il Codice di Procedura Civile, agli articoli 409
c.p.c., si occupa di disciplinare le norme procedurali da applicare alle controversie individuali
di lavoro. Pur rientrando tali controversie in ambito civilistico, le norme che regolano il
cosiddetto rito del lavoro presentano alcune differenze rispetto al rito civile ordinario. In
particolare, ciò che più interessa in questa sede sono le norme che regolano le prove nel
processo del lavoro.
È opportuno precisare che le disposizioni concernenti le controversie individuali di lavoro,
in base all’articolo 409 c.p.c., si applicano:
ai rapporti di lavoro subordinato privato, anche se non inerenti l’esercizio di un’impresa;
ai rapporti di mezzadria, di colonia parziaria, di compartecipazione agraria, di affitto a
coltivatore diretto, nonché rapporti derivanti da altri contratti agrari, salva la competenza
delle sezioni specializzate agrarie;
 ai rapporti di agenzia, di rappresentanza commerciale e agli altri rapporti di
collaborazione che si concretizzino in una prestazione di opera continuativa e coordinata,
prevalentemente personale, anche se non a carattere subordinato;
ai rapporti di lavoro dei dipendenti di enti pubblici che svolgono esclusivamente o
prevalentemente attività economica;
ai rapporti di lavoro dei dipendenti di enti pubblici e altri rapporti di lavoro pubblico,
sempre che non siano devoluti dalla legge ad altro giudice.
Tipiche controversie di competenza del giudice del lavoro sono quelle che hanno a oggetto i
licenziamenti, i demansionamenti, l’irrogazione di sanzioni disciplinari e il mobbing. Di grande
attualità sono le controversie in merito ai provvedimenti del datore di lavoro presi nei confronti
dei dipendenti in seguito ai controlli effettuati dallo stesso sull’utilizzo delle strumentazioni
informatiche e telematiche, di cui si tratterà più approfonditamente nel prossimo paragrafo.
Si è evidenziato in precedenza come nel processo civile viga il principio della
corrispondenza tra il chiesto e il pronunciato (art. 112 c.p.c.) e come l’articolo 115 c.p.c.
preveda che il giudice (salvo i casi disciplinati dalla legge) debba porre a fondamento della sua
decisione le prove proposte dalle parti (principio dell’onere della prova). Come visto, in
applicazione di tali principi, qualora le risultanze istruttorie non siano sufficienti alla prova
della sussistenza del diritto in contestazione, si determina la soccombenza della parte onerata
della dimostrazione dei relativi fatti costitutivi.
I medesimi principi non possono dirsi operanti in modo assoluto nel rito del lavoro, posto che
l’articolo 421 c.p.c. attribuisce allo stesso alcune facoltà ulteriori, ovvero:
indicare alle parti in ogni momento le irregolarità degli atti e dei documenti che possono
essere sanate assegnando un termine per provvedervi, salvo gli eventuali diritti quesiti;
disporre d’ufficio in qualsiasi momento l’ammissione di ogni mezzo di prova, anche fuori
dei limiti stabiliti dal Codice Civile, a eccezione del giuramento decisorio;
richiedere informazioni e osservazioni, sia scritte sia orali, alle associazioni sindacali
indicate dalle parti;
disporre, su istanza di parte, l’accesso sul luogo di lavoro, perché necessario al fine
dell’accertamento dei fatti, e disporre altresì, se ne ravvisa l’utilità, l’esame dei testimoni
sul luogo stesso;
ordinare, qualora lo ritenga necessario, la comparizione, per interrogarle liberamente sui
fatti della causa, anche di quelle persone che siano incapaci di testimoniare (a norma
dell’articolo 246 c.p.c.).
NOTA
L’articolo 246 c.p.c. afferma che “non possono essere assunte come testimoni le persone aventi nella causa un
interesse che potrebbe legittimare la loro partecipazione al giudizio”.
 Secondo un orientamento della Corte di Cassazione, “il rito del lavoro, pur non attuando un
sistema inquisitorio puro, tende a superare, in considerazione della particolare natura dei
rapporti controversi, il principio dispositivo – che obbedisce alla regola formale di giudizio
fondata sull’onere della prova – con quello della ricerca della verità materiale, mediante una
rilevante ed efficace azione del giudice nel processo. Ne consegue che, quando le risultanze di
causa offrono significativi dati di indagine, il giudice non può limitarsi a fare meccanica
applicazione della suddetta regola formale di giudizio, ove reputi insufficienti le prove già
acquisite, ma ha il potere-dovere di provvedere di ufficio agli atti istruttori sollecitati da tale
materiale ed idonei a superare l’incertezza sui fatti costitutivi dei diritti in contestazione, senza
che a ciò sia di ostacolo il verificarsi di preclusioni o decadenze in danno delle parti” (Cass.
Civ. 12 marzo 2004, n. 5152).
NOTA
Non mancano pronunce della Corte di Cassazione che limitano maggiormente l’ambito entro il quale i poteri
istruttori d’ufficio del giudice possono essere esercitati. La Corte in diverse sentenze ha affermato che “nelle
controversie soggette al rito del lavoro (nella specie, controversie agrarie) la facoltà del giudice del merito di
avvalersi dei poteri istruttori conferitigli dalla legge (artt. 421 e 437 c.p.c.) costituisce espressione di una
discrezionalità il cui omesso esercizio fa ritenere che lo stesso giudice abbia, per implicito, considerato
sufficienti le risultanze probatorie già acquisite” (Cass. Civ. 11 marzo 2002, n. 3505), che “il giudice non può
sopperire alle carenze probatorie imputabili alle parti, in quanto il suo potere di ammettere d’ufficio mezzi di
prova a norma dell’art. 421 c.p.c. è finalizzato a sopperire a difficoltà oggettive nell’acquisizione delle prove
ovvero a chiarire o eliminare incertezze” (Cass. Civ. 1 ottobre 1997, n. 9596), che “nel rito del lavoro non incorre
nella violazione del principio dell’onere della prova, fissato dall’art. 2697 c.c., il giudice che disponga d’ufficio, a
norma dell’art. 421 comma 2 c.p.c., una prova testimoniale finalizzata a sopperire all’incompletezza di una
prova documentale, sempre che egli, in osservanza del principio dispositivo (art. 112 c.p.c.), si mantenga nei
limiti dei fatti costitutivi delle pretese o delle eccezioni dedotte o sollevate dalle parti”.

Con riferimento alla previsione del medesimo articolo 421 c.p.c., in base alla quale al
giudice del lavoro è consentito disporre prove anche al di fuori dei limiti imposti dal Codice
Civile, la dottrina e la giurisprudenza prevalenti ritengono che tale possibilità vada limitata alla
prova testimoniale che può essere disposta anche al di fuori dei limiti di valore previsti o in
contrasto con un atto scritto.
In conclusione, in materia di prove il rito del lavoro si differenzia da quello civile ordinario
per l’attribuzione al giudice del lavoro di poteri istruttori d’ufficio che in talune circostanze gli
consentono di intervenire quando le prove acquisite sono insufficienti a consentire
l’accertamento dei diritti controversi.

Focus: aspetti specifici del controllo sui

lavoratori
La questione della liceità dei controlli effettuati dal datore di lavoro è attualmente molto
dibattuta, sia in considerazione dei sempre nuovi servizi a disposizione degli utenti, con i
conseguenti rischi, sia per le innumerevoli tipologie di illeciti civili e penali sia attraverso
l’utilizzo delle strumentazioni informatiche, e in particolare di Internet e della posta elettronica,
è possibile integrare (per esempio violazione del dovere di diligenza dei lavoratori,
pedopornografia, ingiuria, diffamazione, violazioni del diritto d’autore, reati informatici in
generale e così via).
Sotto un profilo giuridico si deve considerare che a oggi non esiste una normativa specifica
che disciplini la possibilità o meno di navigare in Internet da parte del dipendente, né che fissi
chiaramente quali sono i poteri di controllo e repressione da parte del datore di lavoro dei
comportamenti illeciti; occorre quindi valutare quali normative si possono considerare
applicabili e in quali limiti.
Da un punto di vista generale, come si chiarirà in seguito, le due normative che occorre tenere
in considerazione quando si analizzano le tematiche dei controlli sono: il d.lgs. 196/03, che
disciplina il trattamento dei dati e quindi in linea generale i diritti di riservatezza in capo
(anche) ai lavoratori; la legge 300 del 1970, meglio nota come Statuto dei Lavoratori e in
particolare l’articolo 4. Più specificatamente, la normativa in materia di trattamento dei dati
incide nella tematica in commento in quanto le informazioni relative alla navigazione (ora di
collegamento, tempo di collegamento, siti visitati e così via) sono dati personali sottoposti alla
regolamentazione di cui al d.lgs. 196/03. L’articolo 4 dello Statuto dei Lavoratori, invece,
stabilisce che:
“è vietato l’uso di impianti audiovisivi e di altre apparecchiature per finalità di controllo a
distanza dell’attività dei lavoratori” (comma 1);
“gli impianti e le apparecchiature di controllo che siano richiesti da esigenze organizzative
e produttive ovvero dalla sicurezza del lavoro, ma dai quali derivi anche la possibilità di
controllo a distanza dell’attività dei lavoratori, possono essere installati soltanto previo
accordo con le rappresentanze sindacali aziendali, oppure, in mancanza di queste, con la
commissione interna ... (omissis)” (comma 2).
NOTA
La Corte di Cassazione, in merito al divieto di controllo a distanza dell’attività dei lavoratori, ha recentemente
ribadito che “la vigilanza sul lavoro, ancorché necessaria nell’organizzazione produttiva, vada mantenuta in una
dimensione “umana”, e cioè non esasperata dall’uso di tecnologie che possono rendere la vigilanza stessa
continua e anelastica, eliminando ogni zona di riservatezza e di autonomia nello svolgimento del lavoro” (sent.
n. 4375 del 23 febbraio 2010).

A titolo esemplificativo, la Corte di Cassazione (Cass., sez. lav., 23 febbraio 2010, n. 4375)
ha rilevato come “i programmi informatici che consentono il monitoraggio della posta
elettronica e degli accessi Internet sono necessariamente apparecchiature di controllo nel
momento in cui, in ragione delle loro caratteristiche, consentono al datore di lavoro di
controllare a distanza e in via continuativa durante la prestazione, l’attività lavorativa e se
la stessa sia svolta in termini di diligenza e di corretto adempimento”.
Il problema da risolvere all’interno delle organizzazioni è dunque stabilire quali siano i
controlli che rientrano nell’applicazione dell’art. 4 comma 2 dello Statuto dei Lavoratori. Parte
della dottrina ha rilevato come rimarrebbero esclusi dall’applicazione di questa norma
l’accertamento di condotte illegittime posto in essere attraverso l’analisi dei log dei sistemi
operativi, ovvero quei log che sono generati automaticamente per il funzionamento dei sistemi
medesimi.
NOTA
A. Stanchi (“Navigazione in Internet: no ai controlli difensivi senza accordo sindacale”, in Guida al Lavoro del
Sole 24 Ore, n. 11 del 12 marzo 2010) nel commentare la sentenza della Corte di Cassazione n. 4375 del 23
febbraio 2010, sottolinea come “l’accertamento di condotte attraverso l’analisi dei dati dei sistemi operativi (log
di sistema) da cui risulti il comportamento illecito del lavoratore è certamente estranea al sistema. Perché non
si tratta di software applicativi che abbiano come propria funzione l’estrazione dell’aggregazione significante di
dati che trasformi l’elaboratore (strumento di lavoro) e lo concreti in una “apparecchiatura di controllo”
nell’accezione considerata dalla legge ed intesa dai giudici milanesi. Diversamente ragionando, sarebbe come
dire che non è possibile il controllo di conformità dell’esecuzione della prestazione, come risultato implicante
anche il controllo sull’utilizzo proprio dello strumento di lavoro affidato”.

Parimenti rimarrebbero esclusi i controlli posti in essere dal datore di lavoro come reazione
a illeciti di natura penale posti in essere a danno dell’azienda, anche finalizzate alla raccolta di
evidenze informatiche per la corretta ricostruzione dei fatti.
NOTA
La Cassazione Civile (Sezione Lavoro 23 febbraio 2012 n. 2722) ha evidenziato come sia “estranea
all’applicazione dell’art. 4 dello Statuto dei Lavoratori la condotta del datore di lavoro che pone in essere una
attività di controllo sulle strutture informatiche aziendali (nella specie, controllo della mail del dipendente) che
prescinde dalla pura e semplice sorveglianza sull’esecuzione della prestazione lavorativa degli addetti ed è,
invece, diretta ad accertare la perpetrazione di eventuali comportamenti illeciti dagli stessi posti in essere”.
La fattispecie aveva ad oggetto l’impugnazione di un licenziamento per giusta causa adottato nei confronti di un
quadro direttivo di banca, accusato di aver fornito a soggetti terzi estranei informazioni di carattere riservato
riguardanti un cliente della banca stessa, tramite posta elettronica, e di aver così attuato, grazie a tali
informazioni, operazioni finanziarie da cui aveva tratto vantaggi personali. La Corte ha ritenuto corretta la
condotta ispettiva del datore, atteso che nella specie entrava in gioco il diritto del datore di lavoro di tutelare il
proprio patrimonio, che era costituito non solo dal complesso dei beni aziendali, ma anche dalla propria
immagine esterna, così come accreditata presso il pubblico.
Nel caso di specie, la Corte he evidenziato come il datore di lavoro abbia posto in essere un’attività di controllo
sulle strutture informatiche aziendali che prescindeva dalla pura e semplice sorveglianza sull’esecuzione della
prestazione lavorativa degli addetti ed era, invece, diretta ad accertare la perpetrazione di eventuali
comportamenti illeciti dagli stessi posti in essere. Il cosiddetto controllo difensivo, in altre parole, non riguardava
l’esatto adempimento delle obbligazioni discendenti dal rapporto di lavoro, ma era destinato ad accertare un
comportamento che poneva in pericolo la stessa immagine dell’istituto bancario presso i terzi.

Diverso è invece il caso di utilizzo di applicativi che, attraverso l’estrazione di alcune

informazioni dai sistemi informativi aziendali, consentono di monitorare indirettamente l’attività
lavorativa (per esempio strumenti di analisi e tracciamento della navigazione web). In questi
casi, è evidente come il controllo sia di natura preventiva, prescindendo dal compimento di
un’attività illecita da parte del lavoratore. In questi casi, quindi, prima dell’installazione
dell’apparecchiatura di controllo è necessario raggiungere un accordo con le rappresentanze
sindacali interne o rivolgersi, in assenza di queste o di accordo, alla Direzione Regionale del
Lavoro.
Diverse pronunzie dei magistrati italiani, quindi, hanno sancito possibilità da parte del datore
di lavoro di implementare forme di controllo sull’utilizzo di Internet da parte dei propri
dipendenti, se finalizzate alla protezione del patrimonio aziendale o all’accertamento di
condotte illecite da parte dei lavoratori.
Tuttavia, nonostante quanto sancito in via generale da una parte della giurisprudenza, occorre
considerare una serie di principi che tendono ad attenuare il potere di controllo in capo al
datore di lavoro. Alcune indicazioni in tal senso sono state fornite dal Data Protection Working
Party, organo dell’Unione Europea, istituito per monitorare e fornire alcuni pareri riguardo
all’applicazione della direttiva europea sulla privacy, che ha dato un contributo rilevante per
l’interpretazione della normativa in materia di protezione dei dati personali e in particolare in
tema di controllo sui lavoratori. Il Data Protection Working Party ha in particolare riconosciuto
che in questa materia entrano in gioco sia i diritti dei lavoratori che “possono legittimamente
attendersi di usufruire di un certo grado di riservatezza sul posto di lavoro, visto che una parte
significativa delle loro relazioni con altri esseri umani si sviluppa nell’ambiente di lavoro”, sia
quelli del datore di lavoro che “ha in particolare il diritto di gestire la sua azienda con una certa
efficienza, ma soprattutto il diritto di tutelarsi contro le responsabilità od i danni cui possono
dare origine gli atti dei lavoratori”. Proprio in considerazione dei diritti del datore di lavoro
sopra menzionati si deve ritenere giustificabile l’adozione di misure di controllo anche se
queste avranno ovviamente come naturale conseguenza quella di limitare il diritto del
dipendente alla riservatezza (il caso più evidente è quando il datore di lavoro è la vittima di un
atto avente rilevanza penale commesso dal dipendente). Nonostante questo, è evidente che il
potere di controllo del datore di lavoro non è illimitato, e non è da ritenersi legittima ogni forma
di intrusione nella sfera privata del lavoratore. Secondo il Data Protection Working Party, ai fini
della legittimità delle attività di controllo sull’utilizzo di Internet e della posta elettronica
occorre che il datore di lavoro rispetti i seguenti principi, peraltro ripresi e ribaditi altresì da
una serie di sentenze giurisprudenziali:
necessità (il controllo deve risultare necessario ovvero indispensabile rispetto a uno scopo
determinato precedentemente e avere il carattere dell’eccezionalità);
finalità (il controllo deve tendenzialmente essere finalizzato a garantire la sicurezza o a
garantire la continuità aziendale o a prevenire e reprimere illeciti);
trasparenza (il datore di lavoro ha l’onere di informare preventivamente i propri
dipendenti sui limiti di utilizzo delle strumentazioni informatiche nonché sulle sanzioni
eventualmente previste in caso di violazione di tali limiti e sulle tipologie e modalità di
 controllo implementati);
proporzionalità (il datore di lavoro deve adottare quelle forme di controllo strettamente
necessarie in relazione alla finalità perseguita e che non risultino sproporzionate);
sicurezza (i dati raccolti devono essere protetti in modo assolutamente adeguato).
Successivamente alle suddette indicazioni fornite dal Data Protection Working Party il
Garante per la protezione dei dati personali, il primo marzo 2007, ha emanato un provvedimento
generale contenente le linee guida in materia di controllo da parte del datore di lavoro
sull’utilizzo di Internet e della posta elettronica da parte dei dipendenti.
La ragione principale dell’emanazione di un tale provvedimento è stata la ricezione da parte
dell’autorità garante di numerosi reclami, segnalazioni e quesiti riguardanti il trattamento dei
dati personali effettuati dai datori di lavoro in relazione all’utilizzo di Internet e della posta
elettronica aziendali e i conseguenti poteri di controllo sui dati e più in generale le informazioni
raccolte dal sistema informativo aziendale.
Si tratta di un provvedimento di grande rilevanza, che consente di comprendere quali siano i
principi e le regole che il datore di lavoro deve rispettare nell’attività di controllo facendo
chiarezza sugli aspetti prima maggiormente controversi. A differenza di quello del Data
Protection Working Party, il provvedimento del Garante è interamente calato nel panorama
giuridico italiano e tiene quindi in considerazione le normative vigenti che impattano sul potere
di controllo del datore di lavoro sull’attività dei dipendenti, e in particolare su quelle contenute
nello Statuto dei Lavoratori (legge 300 del 1970).
Occorre in primis notare come il Garante abbia riconosciuto che compete ai datori di lavoro
assicurare la funzionalità e il corretto impiego di Internet e della posta elettronica da parte dei
lavoratori definendone le modalità d’uso nell’organizzazione dell’attività lavorativa tenendo
conto della disciplina in tema di diritti e relazioni sindacali. Nel perseguimento di tali scopi,
tuttavia, il datore di lavoro deve adottare idonee misure di sicurezza per assicurare la
disponibilità e l’integrità dei sistemi informativi e dei dati personali aziendali anche al fine di
prevenire utilizzi indebiti che possono risultare illeciti ed essere quindi fonte di responsabilità.
In secondo luogo il Garante ha preso atto che, fissando l’attenzione sugli assunti che seguono
la massima attenzione:
l’utilizzo di Internet da parte dei lavoratori può formare oggetto di analisi, profilazione e
integrale ricostruzione mediante elaborazione di log file della navigazione web;
i servizi di posta elettronica sono parimenti suscettibili di controlli, che possono giungere
fino alla conoscenza da parte del datore di lavoro del contenuto della corrispondenza.
Da tali presupposti il Garante ha quindi fatto discendere l’esigenza di tutelare i lavoratori
interessati da eventuali trattamenti illeciti di dati da parte del datore di lavoro e ciò anche
perché, sempre secondo il Garante, “l’utilizzazione di Internet e della posta elettronica, già
ampiamente diffusi nel contesto lavorativo, è destinata ad un rapido incremento in numerose
attività svolte anche fuori della sede lavorativa”.
In relazione ai principi da osservare in materia di controllo sull’utilizzo di Internet e della
posta elettronica da parte dei lavoratori, il Garante, ai fini della elaborazione delle Linee
Guida, ha evidenziato la necessità di tenere in considerazione:
il diritto alla protezione dei dati personali e l’esigenza che il trattamento sia disciplinato
assicurando un elevato livello di tutela delle persone;
alcune discipline di settore, fatte salve dal Codice in materia di protezione dei dati
personali (d.lgs 196/03), che prevedono specifici divieti o limiti, come quelli posti dallo
Statuto dei Lavoratori sul controllo a distanza, essendo necessario che la disciplina di
protezione dei dati si coordini con le regole di settore riguardanti il rapporto di lavoro e il
connesso utilizzo delle tecnologie, qualunque esse siano;
i principi generali del Codice in materia di protezione dei dati personali applicabili al
controllo su Internet e posta elettronica (Tabella 2.1).
Tabella 2.1 I principi generali del Codice in materia di protezione dei dati personali
I sistemi informativi e i programmi informatici devono essere configurati riducendo al minimo
Principio di
l’utilizzazione di dati personali e di dati identificativi in relazione alle finalità perseguite (art. 3 del
necessità
Codice).
Le caratteristiche essenziali dei trattamenti devono essere rese note ai lavoratori (art. 11, comma 1,
lett. a) del Codice). Le tecnologie dell’informazione (in modo più marcato rispetto ad apparecchiature
Principio di
tradizionali) permettono di svolgere trattamenti ulteriori rispetto a quelli connessi ordinariamente
correttezza
all’attività lavorativa. Ciò all’insaputa o senza la piena consapevolezza dei lavoratori, considerate
anche le potenziali applicazioni di regole non adeguatamente conosciute dagli interessati.
I trattamenti devono essere effettuati per finalità determinate, esplicite e legittime (art. 11, comma 1,
Principio di
lett. b), del Codice). Il datore di lavoro deve trattare i dati “nella misura meno invasiva possibile”. Le
pertinenza
attività di monitoraggio devono essere svolte solo da soggetti preposti ed essere “mirate sull’area di
e non
rischio, tenendo conto della normativa sulla protezione dei dati e, se pertinente, del principio di
eccedenza
segretezza della corrispondenza”.

Il Garante ha inoltre rilevato che, ai fini del rispetto del principio di correttezza, l’eventuale
trattamento da parte del datore di lavoro di dati personali relativi all’attività di controllo su
Internet e posta elettronica deve essere ispirato a un canone di trasparenza, come tra l’altro
previsto dall’articolo 4 dello Statuto dei Lavoratori.
In questo quadro, viene ribadita l’importanza delle policy aziendali. Le Linee Guida, infatti,
evidenziano l’opportunità che il datore di lavoro adotti un disciplinare interno redatto in modo
chiaro e senza formule generiche, da pubblicizzare adeguatamente (verso i singoli lavoratori,
nella rete interna, mediante affissioni sui luoghi di lavoro con modalità analoghe a quelle
previste dall’art. 7 dello Statuto dei Lavoratori e così via) e da sottoporre ad aggiornamento
periodico.
SUGGERIMENTI DEL GARANTE PER LA COSTRUZIONE DELLE POLICY
Indicare se determinati comportamenti non sono tollerati rispetto alla “navigazione” in Internet (per esempio il
 download di software o di file musicali), oppure alla tenuta di file nella rete interna.
Indicare in quale misura è consentito utilizzare anche per ragioni personali servizi di posta elettronica o di
rete, anche solo da determinate postazioni di lavoro o caselle oppure ricorrendo a sistemi di webmail,
indicandone le modalità e l’arco temporale di utilizzo (per esempio fuori dall’orario di lavoro o durante le
pause, o consentendone un uso moderato anche nel tempo di lavoro).
Specificare quali informazioni sono memorizzate temporaneamente (per esempio le componenti di file di log
eventualmente registrati) e chi (anche all’esterno) vi può accedere legittimamente.
Indicare se e quali informazioni sono eventualmente conservate per un periodo più lungo, in forma
centralizzata o meno (anche per effetto di copie di backup, della gestione tecnica della rete o di file di log).
Specificare se, e in quale misura, il datore di lavoro si riserva di effettuare controlli in conformità alla legge,
anche saltuari o occasionali, indicando le ragioni legittime, specifiche e non generiche per cui verrebbero
effettuati (anche per verifiche sulla funzionalità e sicurezza del sistema) e le relative modalità (precisando
se, in caso di abusi singoli o reiterati, vengono inoltrati preventivi avvisi collettivi o individuali ed effettuati
controlli nominativi o su singoli dispositivi e postazioni).

Il Garante ha inoltre specificato che all’onere per il datore di lavoro di predisporre e

pubblicizzare una policy interna rispetto agli usi e agli eventuali controlli si affianca il dovere
di informare comunque gli interessati (lavoratori) ai sensi dell’articolo 13 del Codice in materia
di protezione dei dati personali. In particolare, con riferimento alle finalità perseguite, occorre
indicare nell’informativa che i dati personali verranno raccolti e trattati per ragioni connesse a
specifiche esigenze organizzative, produttive e di sicurezza sul lavoro quando comportano un
trattamento lecito di dati, e possono anche riguardare l’esercizio di un diritto in sede giudiziaria.
Con riferimento ai programmi che consentono controlli indiretti, si consideri che in base al
primo comma dell’articolo 4 dello Statuto dei Lavoratori, come accennato, “è vietato l’uso di
impianti audiovisivi e di altre apparecchiature per finalità di controllo a distanza dell’attività
dei lavoratori”. Sotto questo profilo il Garante ha confermato l’illiceità del trattamento dei dati
e la conseguente installazione di sistemi hardware e software preordinati al controllo a distanza
dei lavoratori grazie ai quali è possibile ricostruire, anche minuziosamente, l’attività degli
stessi. Si ricorda, sotto questo profilo, che le informazioni raccolte in violazione dell’art. 4
dello Statuto dei Lavoratori non sono utilizzabili in sede giudiziaria.
DIVIETI DI CUI ALL’ART. 4 DELLO STATUTO DEI LAVORATORI
Apparecchiature che consentono la lettura e la registrazione sistematica dei messaggi di posta elettronica
ovvero dei relativi dati esteriori, al di là di quanto tecnicamente necessario per svolgere il servizio e-mail.
Apparecchiature che consentono la riproduzione ed eventuale memorizzazione sistematica delle pagine
web visualizzate dal lavoratore.
Apparecchiature che consentono la lettura e la registrazione dei caratteri inseriti tramite la tastiera o analogo
dispositivo.
Apparecchiature che consentono l’analisi occulta di computer portatili affidati in uso.

Fermo quanto sopra, il Garante ha tuttavia confermato l’applicabilità in via generale del
secondo comma dell’articolo 4 dello Statuto dei Lavoratori in base al quale “gli impianti e le
apparecchiature di controllo che siano richiesti da esigenze organizzative e produttive ovvero
dalla sicurezza del lavoro, ma dai quali derivi anche la possibilità di controllo a distanza
dell’attività dei lavoratori, possono essere installati soltanto previo accordo con le
rappresentanze sindacali aziendali, oppure, in mancanza di queste, con la commissione interna.
In difetto di accordo, su istanza del datore di lavoro provvede la Direzione Regionale del
Lavoro (omissis)”. In altri termini, fermo restando il dovere di rispettare le procedure di
informazione e consultazione dei lavoratori e dei sindacati, il datore di lavoro, utilizzando
sistemi informativi per esigenze produttive od organizzative (o necessari per la sicurezza sul
lavoro), può avvalersi legittimamente di sistemi che consentono indirettamente un controllo a
distanza e determinano un trattamento di dati riferibili al lavoratore. In relazione all’utilizzo di
programmi che consentono controlli indiretti il datore di lavoro deve comunque adottare ogni
opportuna misura, organizzativa e tecnologica volta a prevenire il rischio di utilizzi impropri
(principio di necessità) e comunque a minimizzare l’uso di dati riferibili ai lavoratori. Il datore
medesimo ha inoltre l’obbligo di adottare l’uso di misure tecnologiche volte a minimizzare l’uso
di dati identificativi.
Dopo aver fissato le regole generali per la costruzione delle policy aziendali, le Linee Guida
procedono indicando suggerimenti in relazione a come prevenire e gestire utilizzi abusivi di
Internet da parte dei lavoratori. Il Garante, in primis, ha evidenziato che il datore di lavoro, ai
fini di ridurre il rischio di usi impropri della navigazione in Internet posta in essere dai
lavoratori, deve preferire l’adozione di misure che prevengano controlli successivi sul
lavoratore. Questi controlli, da considerarsi in certe circostanze illeciti, infatti, possono
determinare il trattamento di informazioni personali, anche non pertinenti o idonei a rilevare
convinzioni religiose, filosofiche o di altro genere, opinioni politiche, lo stato di salute o la vita
sessuale. Sotto questo profilo ha quindi indicato una serie di suggerimenti da tenere in
considerazione da parte delle aziende.
SUGGERIMENTI DEL GARANTE RELATIVAMENTE A INTERNET
Individuazione di categorie di siti considerati correlati o meno con la prestazione lavorativa.
Configurazione dei sistemi o utilizzo di filtri che prevengano determinate operazioni – reputate inconferenti
con l’attività lavorativa – quali l’upload o l’accesso a determinati siti (inseriti in una sorta di black list) e/o il
download di file o software aventi particolari caratteristiche (dimensionali o di tipologia di dato).
Trattamento di dati in forma anonima o tale da precludere l’immediata identificazione di utenti mediante loro
opportune aggregazioni (per esempio con riguardo ai file di log riferiti al traffico web, su base collettiva o per
gruppi sufficientemente ampi di lavoratori).
Eventuale conservazione nel tempo dei dati strettamente limitata al perseguimento di finalità organizzative,
produttive e di sicurezza.

Successivamente al tema di Internet, il Garante si è concentrato su quello della posta

elettronica.
Sotto questo profilo il Garante ha innanzitutto riconosciuto che nel contesto lavorativo e in
ragione della veste esteriore attribuita all’indirizzo di posta elettronica nei singoli casi, può
risultare dubbio se il lavoratore, in qualità di destinatario o mittente, utilizzi la posta elettronica
operando quale espressione dell’organizzazione datoriale o ne faccia invece un uso personale
pur operando in una struttura lavorativa.
Il Garante, quindi, dopo aver ribadito che la policy aziendale deve esplicitare i limiti
nell’utilizzo della posta elettronica da parte dei lavoratori, anche al fine di evitare la
determinazione negli stessi o nei terzi di una legittima aspettativa di confidenzialità della posta
elettronica, ha evidenziato la necessità dell’adozione di idonei accorgimenti, anche al fine di
prevenire eventuali violazioni dei principi di pertinenza e non eccedenza.
SUGGERIMENTI DEL GARANTE RELATIVAMENTE ALLA POSTA ELETTRONICA
Rendere disponibili indirizzi di posta elettronica condivisi tra più lavoratori (per esempio info@ente.it,
ufficiovendite@ente.it, ufficioreclami@società.com, urp@ente.it e così via), eventualmente affiancandoli a
quelli individuali.
Valutare la possibilità di attribuire al lavoratore un diverso indirizzo destinato a uso privato del lavoratore.
Mettere a disposizione di ciascun lavoratore apposite funzionalità di sistema, di agevole utilizzo, che
consentano di inviare automaticamente, in caso di assenze (per esempio per ferie o attività di lavoro fuori
sede), messaggi di risposta contenenti le “coordinate” (anche elettroniche o telefoniche) di un altro soggetto
o altre utili modalità di contatto della struttura. È opportuno inoltre prescrivere ai lavoratori di avvalersi di tali
modalità, prevenendo così l’apertura della posta elettronica. In caso di eventuali assenze non programmate
(per esempio per malattia), qualora il lavoratore non possa attivare la procedura descritta (anche
avvalendosi di servizi webmail), il titolare del trattamento, perdurando l’assenza oltre un determinato limite
temporale, potrebbe disporre lecitamente, sempre che sia necessario e mediante personale appositamente
incaricato (per esempio l’amministratore di sistema oppure, se presente, un incaricato aziendale per la
protezione dei dati), l’attivazione di un analogo accorgimento, avvertendo gli interessati.
In previsione della possibilità che, in caso di assenza improvvisa o prolungata e per improrogabili necessità
legate all’attività lavorativa, si debba conoscere il contenuto dei messaggi di posta elettronica, fare in modo
che l’interessato sia messo in grado di delegare un altro lavoratore (fiduciario) a verificare il contenuto di
messaggi e a inoltrare al titolare del trattamento quelli ritenuti rilevanti per lo svolgimento dell’attività
lavorativa. A cura del titolare del trattamento, di tale attività dovrebbe essere redatto apposito verbale e
informato il lavoratore interessato alla prima occasione utile.
Fare in modo che i messaggi di posta elettronica contengano un avvertimento ai destinatari nel quale sia
dichiarata l’eventuale natura non personale dei messaggi stessi, precisando se le risposte potranno essere
conosciute nell’organizzazione di appartenenza del mittente e con eventuale rinvio alla predetta policy
datoriale.

Infine, le Linee Guida prevedono che, nell’effettuare i controlli sull’uso delle strumentazioni
informatiche, debbano essere evitate interferenze ingiustificate sui diritti e sulle libertà
fondamentali sia dei lavoratori sia di soggetti esterni che ricevono o inviano comunicazioni
elettroniche di natura personale o privata. In particolare, per il Garante, deve essere per quanto
possibile preferito un controllo preliminare su dati aggregati riferiti all’intera struttura
organizzativa o a sue aree. I controlli su base individuale, di regola, non sono quindi ammessi
quando le misure preventive di cui sopra hanno raggiunto lo scopo di evitare il verificarsi di
successive anomalie analoghe a quelle riscontrate.
I sistemi software, inoltre, sempre in base alle Linee Guida, devono essere programmati e
configurati in modo da cancellare periodicamente e automaticamente i dati personali relativi
agli accessi a Internet e al traffico telematico la cui conservazione non serva. In assenza di
particolari esigenze tecniche o di sicurezza, la conservazione temporanea dei dati relativi
all’uso degli strumenti elettronici deve essere giustificata da una finalità specifica e comprovata
e limitata al tempo necessario (e predeterminato) a raggiungerla. Un eventuale prolungamento
dei tempi di conservazione, in base alle Linee Guida, deve essere invece valutato come
eccezionale e può avere luogo solo in relazione a:
esigenze tecniche o di sicurezza del tutto particolari;
indispensabilità del dato rispetto all’esercizio o alla difesa di un diritto in sede giudiziaria;
obbligo di custodire o consegnare i dati per ottemperare a una specifica richiesta
dell’autorità giudiziaria o della polizia giudiziaria.
In questi casi, sostiene il Garante, “il trattamento dei dati personali deve essere limitato alle
sole informazioni indispensabili per perseguire finalità preventivamente determinate ed essere
effettuato con logiche e forme di organizzazione strettamente correlate agli obblighi, compiti e
finalità già esplicitati”.
Prima dell’emanazione delle linee guida il Garante per la protezione dei dati personali, con il
provvedimento del 2 febbraio 2006, aveva già sostanzialmente confermato la legittimità dei
controlli del datore di lavoro sulla navigazione in Internet dei dipendenti nel rispetto dei
principi sopra esaminati. Nel caso sottoposto al suo esame, il Garante ha ritenuto infatti
illegittimo il controllo posto in essere dal datore di lavoro sulla navigazione in Internet di un
dipendente in assenza di un’adeguata e preventiva informativa nei suoi confronti sulla tipologia
dei controlli posti in essere e sul tipo di trattamento di dati personali che sarebbe stato
effettuato. In quella circostanza, inoltre, il datore di lavoro, per accertare l’illecita navigazione
in Internet del dipendente durante l’orario di lavoro, aveva conservato non solo i dati relativi
agli accessi alla Rete e alla loro durata, ma altresì il dettaglio dei siti visitati, raccogliendo in
questo modo anche dati di natura sensibile idonei a rivelare convinzioni religiose, opinioni
sindacali, nonché gusti attinenti alla vita sessuale del dipendente medesimo.
NOTA
In particolare, nel citato provvedimento del Garante si legge: “Per ciò che concerne il merito va rilevato che la
società, per dimostrare un comportamento illecito nel quadro del rapporto di lavoro, ha esperito dettagliati
accertamenti in assenza di una previa informativa all’interessato relativa al trattamento dei dati personali,
nonché in difformità dall’art. 11 del Codice nella parte in cui prevede che i dati siano trattati in modo lecito e
secondo correttezza, nel rispetto dei principi di pertinenza e non eccedenza rispetto alle finalità perseguite [...] A
parte la circostanza che l’interessato non era stato, quindi, informato previamente dell’eventualità di tali controlli
e del tipo di trattamento che sarebbe stato effettuato, va rilevato sotto altro profilo che non risulta che il ricorrente
avesse necessità di accedere a Internet per svolgere le proprie prestazioni. La resistente avrebbe potuto quindi
dimostrare l’illiceità del suo comportamento in rapporto al corretto uso degli strumenti affidati sul luogo di lavoro
limitandosi a provare in altro modo l’esistenza di accessi indebiti alla rete e i relativi tempi di collegamento. La
società ha invece operato un trattamento diffuso di numerose altre informazioni indicative anche degli specifici
 ‘contenuti’ degli accessi dei singoli siti web visitati nel corso delle varie navigazioni, operando – in modo peraltro
non trasparente – un trattamento di dati eccedente rispetto alle finalità perseguite [...] Va, infatti, tenuto conto
che, sebbene i dati personali siano stati raccolti nell’ambito di controlli informatici volti a verificare l’esistenza di
un comportamento illecito (che hanno condotto a sporgere una querela, ad una contestazione disciplinare e al
licenziamento), le informazioni di natura sensibile possono essere trattate dal datore di lavoro senza il
consenso quando il trattamento necessario per far valere o difendere un diritto in sede giudiziaria sia
‘indispensabile’ (art. 26, comma 4, lett. c), del Codice; autorizzazione n. 1/2004 del Garante). Tale
indispensabilità, anche alla luce di quanto precedentemente osservato, non ricorre nel caso di specie [...] Alla
luce delle considerazioni sopra esposte e considerato l’art. 11, comma 2, del Codice secondo cui i dati trattati in
violazione della disciplina rilevante in materia di trattamento dei dati personali non possono essere utilizzati,
l’Autorità dispone quindi, ai sensi dell’art. 150, comma 2, del Codice, quale misura a tutela dei diritti
dell’interessato, il divieto per la società resistente di trattare ulteriormente i dati personali raccolti nei modi
contestati con il ricorso”.

Secondo il Garante, l’estensione dei controlli ai contenuti dei siti visitati è, nel caso di
specie, in netta violazione del principio di proporzionalità, in quanto per accertare la condotta
illecita del dipendente, che per l’esercizio delle proprie mansioni non aveva la necessità di
accedere a Internet, sarebbe stato sufficiente effettuare un controllo teso esclusivamente a
dimostrare gli indebiti accessi alla Rete.

Valenza della Digital Forensics a livello

processuale
Nei paragrafi precedenti sono state prese in considerazione le principali norme che regolano
le prove in sede civile, penale e lavoristica. A conclusione di questa trattazione, teorica ma
propedeutica, è ora possibile capire, con riferimento alla acquisizione, analisi e conservazione
delle evidenze informatiche, quanto sia importante l’adozione di appropriate metodologie e
quindi, in definitiva, quali siano i problemi, le opportunità e le difficoltà della Digital
Forensics.
Come visto, essenziale perché una prova sia ammessa nel processo, civile o penale, e venga
successivamente valutata dal giudice in favore della parte che l’ha prodotta o richiesta, è la sua
idoneità a dimostrare i fatti ai quali si riferisce. In un contesto informatico caratterizzato
dall’elevato rischio di alterazione delle informazioni o dei dati conservati o scambiati dai
sistemi informatici e telematici, le precauzioni che le parti sono tenute ad adottare ai fini di
conservare il valore probatorio degli elementi raccolti sono di gran lunga superiori rispetto ad
altri contesti. Alcuni autorevoli autori hanno suggerito, per capire la cautela da adottare nella
loro manipolazione, un’equivalenza tra le tracce informatiche (o digital evidence) e le impronte
digitali o le analisi del DNA (G. Costabile, “Scena criminis, documento informatico e
formazione della prova penale”, in Il diritto dell’informazione e dell’informatica, 2005, 3).
Altri ancora, invece, consigliano di applicare alle tracce informatiche gli stessi principi di
assunzione delle prove legate ai processi sull’inquinamento e alla sofisticazione alimentare (B.
Fiammella, Problematiche giuridiche legate alla Digital Forensics, 2003,
http://www.diritto.it/materiali/tecnologie/fiammella1.html).

La prova informatica dunque, ai fini della sua utile utilizzazione in sede processuale, dovrà
necessariamente possedere alcuni requisiti, in particolare l’integrità e non ripudiabilità
dell’elemento raccolto (A. Monti, “Attendibilità dei sistemi di Digital Forensics”, in ICT-
Security, 2003, 9).
In particolare, l’integrità può essere definita come “quella proprietà per effetto della quale si
escludono alterazioni indebite delle tracce informatiche intervenute in epoca successiva alla
creazione, trasmissione o allocazione in un supporto autorizzato” (G. Costabile, D. Rasetti,
“Scena criminis, tracce informatiche e formazione della prova”, in Cyberspazio e diritto, 2003,
3/4).
Nel processo civile è onere delle parti produrre al giudice le prove che confermano
l’esistenza del diritto che si vuole riconosciuto dal giudice. La mancata prova di un diritto
comporta la soccombenza. Nel caso di prove informatiche, quindi, è onere della parte
raccoglierle e conservarle in modo tale che non vi sia il rischio che le stesse vengano
considerate inidonee a dimostrare il fatto invocato. Si aggiunga che molto spesso le prove
informatiche, prima della loro individuazione, sono conservate su supporti di proprietà del
soggetto che agisce in giudizio per far valere un proprio diritto. A titolo esemplificativo, si
considerino le fonti di prova prodotte da un datore di lavoro per dimostrare l’attività illecita del
dipendente attraverso l’utilizzo delle strumentazioni informatiche aziendali e giustificative del
suo licenziamento o dell’erogazione di una sanzione disciplinare. In un caso come questo, le
fonti di prova digitale saranno probabilmente da rinvenirsi su supporti di proprietà dell’azienda
stessa. Ai fini dell’attendibilità di tali fonti di prova appare evidente che dovranno essere state
adottate dall’azienda sia specifiche precauzioni nella conservazione delle informazioni prodotte
dai sistemi informatici (per esempio file di log), sia specifiche metodologie nell’acquisizione e
conservazione delle fonti di prova. La prova informatica entrerà nel processo civile
essenzialmente come una prova documentale, ma il suo valore probatorio è conseguenza delle
modalità con le quali è stata acquisita e della sua idoneità a provare i fatti ai quali si riferisce.
Le prove informatiche prodotte in giudizio, seppur raccolte con le metodologie proprie della
Digital Forensics, sono comunque il frutto di un’attività di parte e sono liberamente valutabili
dal giudice. Le evidenze digitali sono generalmente riproduzioni informatiche della realtà che
acquisiscono valore di piena prova dei fatti e delle cose rappresentate solo nel caso in cui colui
contro il quale sono prodotte non ne disconosca la conformità ai fatti o alle cose medesime.
Anche il disconoscimento di tale idoneità, tuttavia, non impedisce alle riproduzioni informatiche
di essere valutate come elementi di prova utili ai fini della decisione. In considerazione di
quanto sopra, più il processo di acquisizione, esame e conservazione della fonte di prova è
improntato a criteri di scientificità e rigore, maggiori saranno le probabilità che il giudice la
consideri idonea a provare i fatti oggetto della causa. Si consideri inoltre che, con tutta
probabilità, stanti la delicatezza e la tecnicità delle metodologie di acquisizione e valutazione
della prova informatica, il giudice, solitamente non in possesso delle debite competenze, farà
ricorso a consulenze tecniche, anche d’ufficio, per acquisire le conoscenze scientifiche
necessarie alla sua decisione in merito. Se dunque la parte ha acquisito, analizzato e conservato
la prova informatica seguendo idonee e adeguate procedure, con maggiore difficoltà la
consulenza tecnica disposta dal giudice potrà contestarne la validità e la sua idoneità a
dimostrare un fatto. Parimenti, con maggiori difficoltà le consulenze tecniche della controparte
avranno la possibilità di invalidare i risultati raggiunti (si ricorda comunque che la consulenza
tecnica non è un mezzo di prova e il giudice non è pertanto vincolato ai risultati dalla stessa
espressi). Il giudice civile, d’altro canto, pur potendo scegliere le fonti del proprio
convincimento ai fini della decisione, deve dare idonea motivazione dei criteri adottati e,
pertanto, nel disattendere i risultati di un’analisi forense deve motivare le ragioni della sua
decisione in modo da rendere possibile la ricostruzione dell’iter logico seguito.
Nel contesto penale, attualmente quello maggiormente interessato alle tematiche della Digital
Forensics, occorre innanzitutto rilevare come troppo spesso si sia parlato di queste metodologie
con riferimento esclusivo alla ricerca degli elementi di prova concernenti i reati informatici,
senza invece tener conto che il campo in cui tale disciplina può essere applicata è molto più
vasto. In particolare, le strumentazioni informatiche possono essere l’oggetto su cui ricade
l’attività criminosa dell’agente (reati informatici puri, quali l’accesso abusivo a sistema
informatico, la diffusione di programmi diretti a danneggiare o interrompere un sistema
informatico, la frode informatica) oppure mezzi per la commissione di altri reati. La
sottovalutazione di tale aspetto ha comportato un sostanziale ritardo nella comprensione
dell’importanza di adottare metodologie di Digital Forensics nelle attività di ricerca delle
evidenze informatiche.
NOTA
Giovanni Ziccardi (L. Luparia, G. Ziccardi, Investigazione penale e tecnologia informatica, Giuffrè Editore, 2008)
ha rilevato come “non appare pertanto peregrina l’affermazione o, meglio, la previsione, che nel prossimo futuro
qualsiasi tipo di fonte di prova sarà ‘digitale’ in quanto il processo di informatizzazione e digitalizzazione della
nostra società condizionerà direttamente il mondo giuridico, e soprattutto, il suo aspetto processuale”.

Nel processo penale, si pongono ora i problemi della sorte processuale delle evidenze
informatiche raccolte senza adottare idonee metodologie riconosciute a livello internazionale
per la conservazione e la salvaguardia dei dati, soprattutto in seguito alle sopra menzionate
modifiche apportate dalla legge n. 48/2008 al Codice di Procedura Penale in relazione agli
articoli riguardanti i mezzi di ricerca della prova e in particolare le ispezioni, le perquisizioni e
i sequestri. Prima dell’introduzione di tali modifiche vi erano due tesi contrastanti. Secondo la
prima, la conseguenza di tale mancata adozione delle metodologie proprie della Digital
Forensics era l’inutilizzabilità delle evidenze informatiche raccolte. Secondo una diversa tesi,
avvalorata da alcune sentenze giurisprudenziali, invece, i dati raccolti non sarebbero stati
inutilizzabili (mancando una specifica norma che prescrivesse l’adozione di misure di
conservazione dei dati originali) ma, seppur possedendo un ridotto valore probatorio,
liberamente valutabili dal giudice secondo il suo prudente apprezzamento.
NOTA
Il Tribunale di Bologna (sentenza del 22 dicembre 2005) aveva per esempio stabilito che “dal compimento di
investigazioni informatiche che si discostano dalla migliore pratica scientifica non discende un’automatica
inutilizzabilità del materiale raccolto. Spetta infatti alla difesa l’onere di dimostrare in che modo la metodologia
utilizzata ha concretamente alterato i dati ottenuti”. I risultati cui conduce un metodo non conforme alla migliore
pratica scientifica utilizzato dalla polizia giudiziaria, secondo la citata sentenza, sarebbero liberamente valutabili
dal giudice (in applicazione del principio di cui all’articolo 192 c.p.p.) alla luce del contesto probatorio
complessivo.
Pur ritenendo più aderente al quadro normativo previgente quest’ultima interpretazione, Alessandro Vitale (“La
nuova disciplina delle ispezioni e delle perquisizioni in ambiente informatico o telematico”, in Il diritto
dell’informazione e dell’informatica, 2008, 5) ha rilevato come “quest’indirizzo, tuttavia, rischiava, in concreto, di
riesumare, in subiecta materia, quell’accezione del libero convincimento inteso come abusiva cognizione
onnivora, espressione di ‘paternalismo giudiziario’ in forza del quale il giudice ‘si fa esso stesso perito’ e
dimostra di ritenere inutile la funzione della difesa; nonché d’incentivare investigazioni svolte con
approssimazione, delle quali, in ultima istanza, a subire gli effetti negativi sarebbe stata la difesa, in quanto
obiettivamente impossibilitata a contestare, nel prosieguo del procedimento, la correttezza d’acquisizione delle
electronic evidences”.

La situazione è parzialmente mutata in seguito alle modifiche introdotte dalla legge 48/2008,
che modificando svariati articoli del Codice di Procedura Penale (per esempio l’art. 244
relativo alle ispezione e il 247 relativo alle perquisizioni) ha previsto “l’adozione di misure
tecniche dirette ad assicurare la conservazione dei dati originali e ad impedirne l’alterazione”.
L’adozione di tali misure tecniche è ora prevista direttamente dalle norme menzionate e la loro
mancata attuazione (ovvero senza utilizzare le metodologie proprie della Digital Forensics)
“dovrebbe” comportare l’inutilizzabilità delle prove digitali raccolte non correttamente. L’uso
del condizionale è reso necessario dal fatto che nella realtà il legislatore non ha previsto
sanzioni specifiche di inutilizzabilità per la violazione di tali norme.
NOTA
Luca Manfrioti (“Digital evidence e processo penale” in Cass. Pen. 2011, 12, 4509) ha evidenziato come “si
delinea una scarsa sensibilità dei giudici nel riconoscere eventuali profili di invalidità della digital evidence.
Secondo un percorso comune anche ad altri campi della scientific evidence, il libero convincimento diventa il
viatico per legittimare un approccio antiformalistico in tema di prova. In quest’ottica, seppur considerato difforme
dalle best practices, il metodo utilizzato dalla polizia giudiziaria può condurre a risultati ‘liberamente valutabili’
dall’organo giurisdizionale ‘alla luce del contesto probatorio’, in difetto di prova concreta di un alterazione del
dato, da fornire per giunta ad opera della difesa. Ebbene, tale ricostruzione va senz’altro contrastata. Unica
risposta possibile dell’ordinamento processuale ad una prova formata senza il rispetto dell’integrità della stessa
è una declaratoria di inutilizzabilità ai sensi dell’art. 191 c.p.c. E ciò vale a fortiori e in particolare, a seguito
dell’introduzione nel tessuto codicistico, da parte della l. n. 48 del 2008, dei fondamentali principi relativi alla
salvaguardia dell’integrità della prova digitale”.

Altra parte della dottrina rileva come già prima dell’introduzione della l. 48/2008 esistevano
delle norme che sancivano l’inutilizzabilità processuale degli accertamenti tecnici irripetibili
compiuti in violazione delle cautele previste dal Codice di Procedura Penale e dalle
disposizioni di attuazione del medesimo (si veda la precedente trattazione di questo tema).
NOTA
In particolare Marcello Bergonzi Perrone (“Il mancato rispetto delle disposizioni della Legge n. 48 del 2008 in
tema di acquisizione probatoria informatica: per una ipotesi sanzionatoria non prevista esplicitamente dal dato
normativo”, in Ciberspazio e diritto, vol. 14, n. 47, 1-2013) rileva come le norme sopra citate “tutelano il principio
di difesa e quelli del giusto processo, costituzionalmente garantiti (artt. 24 e 111 Cost.). Si vuole che questi diritti
di rango costituzionale abbiano una prevalenza tale che, quand’anche le prove acquisite fossero vere, ebbene
esse sarebbero comunque inutilizzabili (omissis). La legge di ratifica della convenzione di Budapest, infatti, ora
ci spiega in modo compiuto quando ‘l’atto non è ripetibile’ in ipotesi di trattamento del dato informatico dal punto
di vista probatorio. E ce lo spiega con quelle numerose norme (omissis) che impongono di copiare i dati in un
certo modo, su determinati supporti e con una conservazione dei dati che deve essere eseguita con specifiche
modalità (omissis). Ne deriva che, senza timore di errori logici, la violazione delle regole di condotta indicate
dalla legge conduce a ipotesi di inutilizzabilità pur non espressamente descritte ed individuate da specifiche e
dedicate disposizioni di legge”.

Si consideri inoltre che l’obbligo di preservazione dei dati originali in sede di ispezione e
perquisizione dovrebbe consentire l’effettiva possibilità (in precedenza molte volte frustrata)
della difesa della persona imputata o indagata (ma anche in sede peritale) di verificarne
successivamente la genuinità.
NOTA
Andrea Monti (Come cambia la legge sui reati informatici, http://www.ictlex.net/?p=605) ha quindi rilevato
come “queste modifiche pongono fine a un dibattito che da anni si trascinava nelle aule di giustizia e che vedeva
contrapposto chi – tipicamente, le forze di polizia – riteneva di poter sequestrare e analizzare computer senza
adottare particolari cautele tecniche a chi – gli avvocati – chiedeva il rispetto dei principi fissati dalla Computer
Forensics”.

Nel campo della Digital Forensics, un ulteriore problema da affrontare è quello dell’assenza
di uno standard o di metodologie condivise, di un insieme di tecniche di indagine più o meno
consolidate e verificate dall’esperienza. Tale assenza comporta sempre un esito incerto circa la
validità dei risultati delle attività di indagine compiute, indipendentemente da come siano state
nel concreto effettuate. In particolare, nel processo penale il giudice, secondo la dottrina e la
giurisprudenza prevalenti, svolge infatti la funzione di peritus peritorum che deve verificare la
validità scientifica dei criteri e dei metodi d’indagine per stabilire la loro affidabilità in sede
processuale. Al giudice spetta, quindi, verificare nel caso concreto il valore probatorio delle
prove informatiche presentate dalle parti che discende, come visto, dalla possibilità di accertare
l’utilizzo di metodi di indagine, in ottemperanza a regole tecniche riconosciute che diano la
garanzia dell’integrità e genuinità degli elementi raccolti.
NOTA
“Nel valutare i risultati di una perizia, il giudice deve verificare la stessa validità scientifica dei criteri e dei metodi
di indagine utilizzati dal perito, allorché essi si presentino come nuovi e sperimentali e perciò non sottoposti al
vaglio di una pluralità di casi e al confronto critico tra gli esperti del settore, sì da non potersi considerare ancora
acquisiti al patrimonio della comunità scientifica. Quando, invece, la perizia si fonda su cognizioni di comune
 dominio degli esperti e su tecniche d’indagine ormai consolidate, il giudice deve verificare unicamente la corretta
applicazione delle suddette cognizioni e tecniche” (Cass. Pen. 9 luglio 1993).

In conclusione, è auspicabile che le modifiche introdotte dalla legge 48/2008 costituiscano il

presupposto per la nascita di metodologie condivise per l’effettuazione delle operazioni di
acquisizione, conservazione e analisi delle evidenze informatiche, così come avviene per altre
tecniche di indagine di carattere scientifico.

Profili giuridici dell’acquisizione, conservazione

e analisi della prova informatica
I soggetti interessati all’acquisizione di elementi probatori ricavati dai sistemi informatici e
telematici sono molteplici: il pubblico ministero durante le indagini preliminari ai fini
dell’esercizio dell’azione penale; la persona sottoposta alle indagini per raccogliere elementi
probatori a sostegno dell’attività difensiva; la persona offesa dal reato ai fini della decisione
della presentazione di una querela o di una denuncia. Attività di ricerca di elementi probatori
possono essere necessarie anche a supporti di cause civili e in materia di lavoro.
In ogni caso, indipendentemente da chi stia agendo, l’acquisizione degli elementi di prova
deve avvenire in modo tale da non compromettere la genuinità degli elementi raccolti per non
compromettere il loro futuro ed eventuale utilizzo in sede processuale.
Al fine di acquisire elementi probatori che risultino, nei limiti del possibile, utilizzabili dal
magistrato in ogni sede, dovendo garantire l’integrità e la non ripudiabilità, è bene quindi che
nell’acquisizione degli elementi di prova vengano utilizzate metodologie di Digital Forensics
che si fondino sulle più avanzate procedure riconosciute a livello internazionale e che le stesse
siano formalizzate, così come ogni passaggio di un’attività di Digital Forensics, e
pedissequamente rispettate.
Profilo fondamentale dell’idonea acquisizione e successiva conservazione e analisi delle
tracce informatiche è costituito inoltre dalla corretta documentazione (la cosiddetta chain of
custody o catena di custodia) di tutte le attività poste in essere nel corso delle attività di Digital
Forensics. Trattasi di un presupposto necessario per permettere al giudice sia la verifica nel
dettaglio della metodologia utilizzata dall’esperto di Digital Forensics nel compimento delle
diverse operazioni, sia la decisione in merito all’utilizzabilità della prova in giudizio e, in caso
affermativo, la sua idoneità o meno a provare i fatti ai quali si riferisce.
NOTA
Luca Luparia (“Processo penale e tecnologia informatica”, in Diritto dell’Internet, 2008, 3) ha rilevato come “la
natura ontologicamente volatile, alterabile e falsificabile del dato digitale richiede un bagaglio più vasto ed
incisivo di standard operative procedures capaci di garantire attendibilità all’accertamento penale. Per ottenere
questo risultato, per esempio, occorre assicurare la cosiddetta ‘continuità probatoria’, ossia la possibilità di
tenere traccia del procedimento di repertamento e analisi in ogni suo punto per escludere alterazioni indebite
delle tracce informatiche intervenute in epoca successiva alla allocazione in un supporto autorizzato”.
 La via preferibile, in materia di ricerca degli elementi di prova contenuti su supporti
informatici, è la loro acquisizione in modalità ripetibile. In sintesi, sia le attività di acquisizione
dei dati digitali sia le successive fasi di elaborazione e analisi degli stessi non devono alterare i
dati originali.
Questo comporta il compimento di tali attività sulle tracce informatiche non sul supporto
originale, ma su immagini dello stesso create mediante appositi strumenti hardware e software
che garantiscono l’esatta corrispondenza con l’originale (G. Costabile, “Scena criminis,
documento informatico e formazione della prova penale”, in Il diritto dell’informazione e
dell’informatica, 2005, 3). Vantaggio di questo sistema è la preservazione del supporto
originale, che deve essere conservato adottando tutte le idonee contromisure per evitarne
l’alterazione (apposizione di sigilli, conservazione in luogo sicuro e così via), e il compimento
di tutte le attività di analisi su una “bit stream image” dello stesso, senza compromissione dei
diritti della difesa, che potrà in ogni momento effettuare proprie controanalisi.
NOTA
“La bit stream image, a differenza della mera copia, consentirà di operare su un hard disk praticamente identico
all’originale, in maniera sia logica sia fisica, quindi anche su eventuali parti presumibilmente vuote dello stesso,
che potrebbero contenere file o frammenti di file cancellati non sempre visibili con i normali strumenti di
Windows” (G. Costabile, op cit.).

In campo penalistico la problematica della ripetibilità delle operazioni di Digital Forensics

nelle fasi successive del procedimento è di estrema rilevanza. Si ricorda in questa sede quanto
stabilito dall’articolo 360 c.p.p. in materia di accertamenti tecnici non ripetibili, e cioè che è in
capo al pubblico ministero l’onere di avvisare la persona sottoposta alle indagini, la persona
offesa dal reato e i difensori del giorno, del luogo e dell’ora fissati per il conferimento
dell’incarico ai consulenti del pubblico ministero. I difensori e gli eventuali consulenti tecnici
nominati hanno il diritto di assistere al conferimento dell’incarico, di partecipare agli
accertamenti e di formulare riserve. Come visto, l’esecuzione degli accertamenti non ripetibili
senza il rispetto degli adempimenti previsti comporta l’inutilizzabilità in sede dibattimentale dei
risultati degli stessi. È evidente infatti che i difensori e i consulenti di parte non avrebbero più
modo di esaminare i reperti corrispondenti a quelli originali, con la conseguente
compromissione del proprio diritto di difesa. Come rilevato in dottrina (Luparia, op. cit.), “le
criticità possono collocarsi a monte, ossia al momento della stessa fotografia digitale del
contenuto del dispositivo elettronico. È in questa fase, infatti, che può sussistere un ipotetico
rischio di modificazione che obbligherebbe gli organi inquirenti ad attivare le garanzie previste
dal codice di rito, pena l’esclusione del processo della prova”. Viene posta in sostanza la
problematica relativa all’idoneità delle strumentazioni utilizzate per ottenere la bit stream image
di avere una piena corrispondenza tra la copia e l’originale senza alterazione di quest’ultimo.
Viene altresì correttamente rilevato che il frequente utilizzo di software coperti da licenza
proprietaria rende pressoché impossibile (sia al giudice sia alle altre parti), non essendo
consentito accedere ai codici sorgenti per studiarne il funzionamento, verificare l’effettiva
identità tra la copia e l’originale, favorendo quindi eventuali eccezioni difensive. Ancora una
volta si rinnova l’auspicio che le modifiche cui si è fatto cenno apportate al Codice di
Procedura Penale dalla legge 48/2008 accrescano il dibattito intorno a queste tematiche
favorendo la nascita di procedure condivise, corrette da un punto di vista metodologico e che si
consolidino nella prassi operativa degli organi inquirenti, favorendo nel tempo le valutazioni
della magistratura giudicante. Nel frattempo la soluzione consigliabile è la valutazione, da
effettuarsi in relazione alle specifiche metodologie e strumenti utilizzati, della ripetibilità o
meno degli accertamenti che si stanno per compiere, ai fini di decidere se attivare o meno le
garanzie previste dall’art. 360 c.p.p. e scongiurare l’inutilizzabilità in sede processuale degli
elementi raccolti.
In conclusione, alcune considerazioni relative al sequestro a oggetto informatico, dal
momento che – si pensi alle realtà aziendali – occorre prendere in considerazione il fatto che le
strumentazioni informatiche e telematiche solitamente non sono solo uno strumento utilizzato per
commettere un reato (o l’oggetto del reato), ma hanno spesso un’importanza fondamentale per il
soggetto che ne ha la disponibilità. Appare quindi opportuno che in sede di sequestro si
definisca puntualmente che cosa è necessario sequestrare ai fini dell’accertamento dei fatti di
reato e cosa invece sia superfluo. Non si deve infatti dimenticare che una lettura attenta
dell’articolo 253 c.p.p. rivela che non è consentito un sequestro delle cose che non costituiscono
il corpo del reato o che non sono pertinenti al reato.
NOTA
La Corte di Cassazione ha stabilito che “è legittima la decisione con cui il tribunale del riesame annulli il
provvedimento di perquisizione e sequestro delle credenziali di accesso al sistema informatico di prenotazione
dei voli on line di una compagnia aerea onde identificare per tempo - in base ad una serie di parametri
sintomatici desumibili dalle modalità di prenotazione dei voli – i passeggeri sospettabili di fungere da corrieri
internazionali di stupefacenti (c.d. ovulatori), trattandosi di provvedimento preordinato non tanto ad acquisire
elementi di conoscenza in ordine ad una o più notitiae criminis determinate quanto a monitorare in modo
illimitato, preventivo e permanente il contenuto di un sistema informatico onde pervenire all’accertamento di reati
non ancora commessi, ma dei quali si ipotizzi la futura commissione da parte di soggetti da individuarsi; né al
riguardo può essere invocato l’art. 248, comma 2, c.p.p., novellato dalla legge n. 48 del 2008 - per il quale
l’autorità giudiziaria e gli ufficiali di polizia giudiziaria da questa delegati, per rintracciare le cose da sottoporre a
sequestro o accertare altre circostanze utili ai fini delle indagini, possono esaminare presso banche atti,
documenti e corrispondenza nonché dati, informazioni e programmi informatici – il quale laddove richiama le
banche non può che riferirsi agli istituti di credito e non già alle banche dati, per giunta in continuo
aggiornamento automatico, presso qualsiasi altro ente o struttura privata o pubblica, tanto più che il termine
banca-dati non risulta mai adoperato dall’ordinamento giuridico italiano che utilizza la diversa dizione di sistema
informatico o telematico” (Cass. Pen. 17 aprile 2012 n. 19618).
Gaetano Bono (“Il divieto di indagini ad explorandum include i mezzi informatici di ricerca della prova” in Cass.
pen. 2013, 4, 1525) ha sottolineato che “la notizia di reato rappresenta il punto di partenza della fase
procedimentale, secondo quanto sancito dall’art. 335 c.p.p., ma pur a fronte di tale centralità sistemica,
l’ordinamento non ne offre alcuna definizione normativa. Argomentando dal combinato disposto degli artt. 335 e
 347 c.p.p., si ricava una nozione alquanto elastica tendente a ricomprendere qualunque informazione relativa a
fatti specifici astrattamente sussumibili entro una norma incriminatrice, ma senza che occorrano né una piena
coincidenza con la fattispecie né l’indicazione dei presunti autori (omissis). Più nel dettaglio, sulla scorta del
divieto di condurre indagini esplorative, l’operatività dei mezzi (anche informatici) di ricerca della prova finisce
per essere legata a doppio filo all’esistenza di indizi di reità. La verifica della legittimità dei relativi provvedimenti
(aventi la forma di decreto motivato) viene compiuta attraverso la motivazione che può ben considerarsi la
cartina tornasole della legittimità del provvedimento coercitivo. Per giurisprudenza costante essa deve
individuare – almeno nelle linee essenziali e con riferimento a specifiche ipotesi di reato – gli oggetti da
acquisire”.

Non esiste una regola predefinita, ma la valutazione è dipendente dai singoli casi concreti,
dall’oggetto delle indagini e dei fatti da accertare. Troppo spesso accade invece che, per
imperizia o superficialità nella valutazione, vengano poste sotto sequestro anche strumentazioni
che non contengono elementi utili all’indagine, con grave pregiudizio del soggetto destinatario
dell’attività di sequestro. È frequente, per esempio, il sequestro dell’intero computer e di tutte le
sue periferiche (monitor, stampanti, mouse e così via) nel caso siano rinvenute sull’hard disk
“cose pertinenti al reato”. È il caso di rilevare che non tutte le strumentazioni informatiche
hanno la funzionalità di poter conservare informazioni, e il loro sequestro si rivela inutile ai fini
dell’attività d’indagine ma dannoso dal punto di vista economico per il destinatario, che
potrebbe anche essere un soggetto terzo estraneo alla commissione del reato. Come
correttamente rilevato da Andrea Monti (“No ai sequestri indiscriminati di computer”, in Diritto
dell’Internet, 2007, 3), mentre il sequestro dell’elaboratore si rivela nella maggioranza dei casi
inutile, quello delle periferiche potrebbe trovare la propria giustificazione per l’effettuazione di
rilievi dattiloscopici o per ricercare campioni biologici per tentare di individuare l’identità
dell’utilizzatore del computer. Il sequestro delle periferiche, dunque, lungi dall’essere sempre
indispensabile per le indagini, potrebbe diventarlo solo nei casi in cui fosse necessario
compiere, per esempio, le suddette analisi.
NOTA
A. Manchia (Cass. Pen. 2005, 5, 1636) in materia di sequestro osserva: “In primis, infatti, è da ricordare che
solo l’hard disk o alcuni altri supporti (CD-ROM, DVD-ROM, floppy disk o memorie rimovibili) conservano la
memoria dei dati: mai l’intero computer. Ciò impone, dunque, di verificare se la definizione degli elementi che
devono essere assoggettati a sequestro ex art. 253 comma 1 c.p.p. – ovvero quella di corpo del reato,
codificata dal comma 2 dello stesso articolo, e quella non codificata di cose pertinenti al reato – sia conciliabile
con l’immanente concetto di immaterialità dei dati informatici. Difficile appare, infatti, estendere, per analogia, il
termine ‘cose’ ai dati informatici, cioè a tutti quegli elementi che devono essere considerati ‘prove digitali’: ‘cosa’,
infatti, potrebbe ben essere considerato un computer, il quale, peraltro, è solamente il contenitore di tali prove.
Ma, pur su tali logiche premesse, ciò che si verifica in materia è privo di logicità: sequestrare, infatti, tutto un
computer allorché nella memoria di questo sono rinvenute immagini pedopornografiche equivale a sequestrare
una cassetta di sicurezza nel momento in cui all’interno della stessa vengono rinvenute immagini dello stesso
tipo stampate su carta fotografica; ugualmente, sequestrare il monitor od il mouse ha lo stesso senso e tende al
medesimo fine cui può indirizzarsi il sequestro del tavolo sul quale il computer era sistemato od il tappetino sul
quale veniva utilizzato lo strumento di puntamento: nessuno. Il fine del provvedimento dell’autorità è, infatti,
quello di assicurare che gli elementi probatori possano essere raccolti ancora genuini, senza limitare
eccessivamente, nel primo esempio, la libertà ed i diritti dell’istituto bancario; nel secondo quelli, per esempio,
 della famiglia del soggetto sottoposto a indagine. Il sequestro di un intero hard disk, inoltre, consente certamente
l’acquisizione di elementi probatori, ma implica anche l’acquisizione di dati che esulano dal contesto per il quale
l’atto è disposto: in tal modo il sequestro assume uno spropositato carattere afflittivo.”

Sempre in materia di sequestro probatorio la Corte di Cassazione penale (Cass. Pen. 31

maggio 2007 n. 40380) ha ritenuto illegittimo il sequestro del computer in uso a una giornalista
e dell’area del server dalla stessa gestita, con la conseguente acquisizione dell’intero contenuto
dell’hard disk e di un’intera cartella personale presente nell’area del sistema operativo sul
presupposto che “il sequestro probatorio disposto nei confronti di un giornalista professionista
deve rispettare con particolare rigore il criterio di proporzionalità tra il contenuto del
provvedimento ablativo di cui egli è destinatario e le esigenze di accertamento dei fatti oggetto
delle indagini, evitando quanto più è possibile indiscriminati interventi invasivi nella sua sfera
professionale”. Il Tribunale di Milano (sentenza dell’11 marzo 2005) ha invece stabilito che “è
legittima la convalida del sequestro dell’hard disk che contiene dati rilevanti in ordine alla
gestione di un database, in quanto il provvedimento è finalizzato ad assicurare i mezzi di prova
in ordine ai reati per cui si procede anche se ciò avviene in sede di indagini sollecitate dalla
difesa dopo la conclusione delle indagini preliminari. Il vincolo reale sull’HD è necessario e
finalizzato a preservare il bene e consentire un utile esame dei dati ivi contenuti”. Su questo
tema la giurisprudenza dominante ritiene legittimo il sequestro dell’intero elaboratore anche nel
caso di ricerca di soli file (per esempio si vedano Ord. n. 7033/2006 del Trib. del riesame di
Perugia e Ord. n. 2082/2005 Trib. del riesame di Venezia). La Corte di Cassazione penale (n.
12107 del 18 novembre 2008) ha invece stabilito che “in un’inchiesta per concorrenza sleale è
illegittimo il sequestro dell’intero server aziendale e di altri documenti cartacei che non abbiano
attinenza con i progetti, il know-how o comunque con i reati contestati, in quanto non sussiste
nella specie il vincolo per pertinenzialità tra tutti i beni sequestrati e le ipotesi di reato
configurate”.
I principi sopra esaminati che regolano la gestione dell’acquisizione e gestione della prova e
dei mezzi di prova sono applicabili con opportuni accorgimenti anche alla Digital Forensics in
ambito aziendale. Per questo motivo è buona norma non eseguire le attività di analisi sui
supporti originali e documentare con grande livello di dettaglio le attività peritali poste in
essere, meglio se in presenza di testimoni. I supporti copiati devono essere sempre
successivamente sigillati e depositati in un luogo sicuro (nei casi più rilevanti si può ricorrere
all’apposizione di un sigillo sul supporto originale da parte di un notaio con conseguente
deposito del supporto presso quest’ultimo).

Profili giuridici dei file di log

I file di log rivestono un’importanza fondamentale sia nel processo civile sia nel processo
penale. Sotto un profilo penalistico, trattasi di elementi che possono risultare utili sia ai fini
delle indagini del pubblico ministero sia in relazione alla posizione delle altre parti coinvolte
nel processo (difensori della persona sottoposta alle indagini, della persona offesa dal reato e
così via), posto che dagli stessi si possono ricavare fondamentali informazioni (in particolare
per risalire al soggetto che ha usufruito di un dato servizio o che ha compiuto determinate
operazioni con l’utilizzo delle strumentazioni informatiche e telematiche a sua disposizione). La
conservazione dei file di log, inoltre, è sentita come un’esigenza all’interno delle aziende sia
per analizzare e perseguire attacchi informatici provenienti dall’esterno, sia per individuare
condotte illecite dei collaboratori, sia sul piano civilistico e penalistico (in punto si ricorda che
la conservazione dei file di log è lecita nel rispetto dei principi sopra esaminati concernenti il
controllo sui lavoratori).
È bene considerare che nel nostro ordinamento giuridico non esiste un obbligo generalizzato
di conservazione dei file di log prodotti dai sistemi informatici e telematici, salvo specifici casi
di seguito descritti. Gli unici obblighi di conservazione dei dati del traffico telematico sono stati
originariamente previsti in capo ai fornitori di servizi comunicazione elettronica dal decreto
legge 27 luglio 2005, n. 144 convertito in legge 31 luglio 2005, n. 155, attraverso il quale sono
state adottate nel nostro ordinamento alcune misure urgenti per il contrasto del terrorismo
internazionale che hanno un’incidenza diretta sulla fornitura di servizi di comunicazione. Si
ricorda che, in base al decreto legislativo 30 giugno 2003, n. 196, prima dell’adozione delle
misure urgenti antiterrorismo dovevano essere conservati obbligatoriamente dai fornitori per
finalità di accertamento e repressione dei reati solo i dati del traffico telefonico. Ai fornitori di
servizi di comunicazione elettronica era comunque lasciata la possibilità di conservare per un
periodo non superiore a sei mesi i dati strettamente necessari alla fatturazione dei servizi
erogati ai clienti, a fini di documentazione in caso di contestazione della fattura o per la pretesa
del pagamento e salva l’ulteriore specifica conservazione richiesta per effetto di contestazione
anche in sede giudiziale (art. 123 d.lgs 196/03).
L’articolo 132 del d.lgs 196/2003 come modificato dalla legge 31 luglio 2005, n. 155 aveva
previsto nuove regole in materia di conservazione dei dati per il traffico telefonico e telematico,
e in particolare:
i dati relativi al traffico telefonico inclusi quelli concernenti le chiamate senza risposta
dovevano essere conservati dal fornitore per ventiquattro mesi, per finalità di accertamento
e repressione dei reati, mentre, per le medesime finalità, i dati relativi al traffico
telematico, esclusi comunque i contenuti delle comunicazioni, dovevano essere conservati
dal fornitore per sei mesi (art. 132 comma 1);
decorso il termine di cui al punto precedente, i dati relativi al traffico telefonico, inclusi
quelli concernenti le chiamate senza risposta, dovevano essere conservati dal fornitore per
ulteriori ventiquattro mesi e quelli relativi al traffico telematico, esclusi comunque i
contenuti delle comunicazioni, devono conservati per ulteriori sei mesi in riferimento a
 particolari tipologie di reato (delitti di cui all’articolo 407, comma 2, lettera a, ossia i
delitti contraddistinti da un’elevata gravità quali devastazione, saccheggio, strage, guerra
civile, associazione di tipo mafioso e così via) del Codice di Procedura Penale, nonché dei
delitti in danno di sistemi informatici o telematici.
La previsione di un obbligo di conservazione dei dati relativi al traffico telematico, seppur
accolta positivamente, non aveva comunque mancato di suscitare qualche perplessità in
relazione ad alcuni aspetti. In particolare, si era rilevato come il termine di sei mesi previsto
per la conservazione per i reati generici fosse troppo breve in quanto non prendeva in
considerazione la possibilità di accertamenti complessi relativi a reati commessi attraverso la
rete (F. Cajani, “Alla ricerca del log (perduto)”, in Diritto dell’Internet, 6, 2006, pp. 572 e
segg.). Inoltre non erano state disciplinate le modalità di conservazione dei dati di traffico
telematico da parte dei fornitori di servizi di comunicazione e di acquisizione dei file di log da
parte della polizia giudiziaria. Il problema, infatti, è la garanzia circa l’integrità dei dati
conservati dai fornitori di servizi di comunicazione elettronica nonché le modalità di
estrapolazione dei dati che si riferiscono all’indagine (spesso demandati al fornitore medesimo
senza intervento della polizia giudiziaria).
Come si è accennato in precedenza, sul tema relativo agli obblighi di conservazione dei dati
di traffico telefonico e telematico sono avvenute importanti modifiche nel corso del 2008,
dapprima con la legge n. 48/2008 e poi con il d.lgs. 109/2008. La norma di riferimento rimane
l’art. 132 del d.lgs. 196/2003, come modificato dalle norme sopra elencate, il quale prescrive,
come visto, alcuni obblighi di conservazione dei dati di traffico telefonico e telematico in capo
ai fornitori di servizi di comunicazione elettronica. È importante fare chiarezza sui soggetti
tenuti ad adempiere a tali prescrizioni. Il Garante per la protezione dei dati personali, nel
provvedimento generale del 17 gennaio 2008 (così come modificato in data 24 luglio 2008),
avente a oggetto la “sicurezza dei dati di traffico telefonico e telematico”, ha definito il termine
“fornitore” utilizzato dall’art. 132 del d.lgs 196/2003 per indicare il destinatario degli obblighi
di conservazione dei dati di traffico, individuandolo nel soggetto che mette a disposizione del
pubblico servizi di comunicazione elettronica (ovvero quelli “consistenti, esclusivamente o
prevalentemente, nella trasmissione di segnali su reti di comunicazioni elettroniche”) su reti
pubbliche di comunicazione. Sono quindi tenuti alla conservazione dei dati ai sensi del
medesimo art. 132 solo i soggetti che “realizzano esclusivamente, o prevalentemente, una
trasmissione di segnali su reti di comunicazioni elettroniche, a prescindere dall’assetto
proprietario della rete, e che offrono servizi a utenti finali secondo il principio di non
discriminazione”. Il medesimo provvedimento del Garante specifica ulteriormente che non sono
soggetti agli obblighi di data retention:
i soggetti che offrono direttamente servizi di comunicazione elettronica a gruppi delimitati
 di persone (come, a titolo esemplificativo, i soggetti pubblici o privati che consentono
soltanto a propri dipendenti e collaboratori di effettuare comunicazioni telefoniche o
telematiche);
i soggetti che, pur offrendo servizi di comunicazione elettronica accessibili al pubblico,
non generano o trattano direttamente i relativi dati di traffico;
i titolari e i gestori di esercizi pubblici o di circoli privati di qualsiasi specie che si
limitino a porre a disposizione del pubblico, di clienti o soci apparecchi terminali
utilizzabili per le comunicazioni, anche telematiche, ovvero punti di accesso a Internet
utilizzando tecnologia senza fili, esclusi i telefoni pubblici a pagamento abilitati
esclusivamente alla telefonia vocale;
i gestori dei siti Internet che diffondono contenuti sulla Rete (i cosiddetti content
provider);
i gestori di motori di ricerca.
Gli attuali obblighi di data retention disciplinati dall’art. 132 del d.lgs. 196/2003 sono i
seguenti.
I dati relativi al traffico telefonico (diversi da quelli trattati a fini di fatturazione) devono
essere conservati dal fornitore per ventiquattro mesi dalla data della comunicazione, per
finalità di accertamento e repressione dei reati; per le medesime finalità, i dati relativi al
traffico telematico, esclusi i contenuti delle comunicazioni, devono essere conservati dal
fornitore per dodici mesi dalla data della comunicazione (art. 132 comma 1 d.lgs
196/2003).
I dati relativi alle chiamate senza risposta (prima assoggettati alla medesima disciplina di
cui al punto 1), che siano trattati temporaneamente da parte dei fornitori di servizi di
comunicazione elettronica accessibili al pubblico oppure di una rete pubblica di
comunicazione, devono essere conservati per trenta giorni (art. 132 comma 1 bis d.lgs
196/2003).
Entro il termine di cui al comma 1, i dati sono acquisiti presso il fornitore con decreto
motivato del pubblico ministero anche su istanza del difensore dell’imputato, della persona
sottoposta alle indagini, della persona offesa e delle altre parti private. Il difensore
dell’imputato o della persona sottoposta alle indagini può richiedere direttamente al
fornitore i dati relativi alle utenze intestate al proprio assistito con le modalità indicate
dall’ articolo 391 quater del Codice di Procedura Penale, ferme restando le condizioni di
cui all’ articolo 8, comma 2, lettera f) per il traffico entrante (art. 132 comma 3 d.lgs
196/2003).
In questa sede è opportuno segnalare come la legge n. 48/2008 abbia introdotto nel Codice di
Procedura Penale l’art. 254 bis relativo al Sequestro di dati informatici presso fornitori di
servizi informatici, telematici e di telecomunicazioni. Tale articolo stabilisce che “l’autorità
giudiziaria, quando dispone il sequestro, presso i fornitori di servizi informatici, telematici o di
telecomunicazioni, dei dati da questi detenuti, compresi quelli di traffico o di ubicazione, può
stabilire, per esigenze legate alla regolare fornitura dei medesimi servizi, che la loro
acquisizione avvenga mediante copia di essi su adeguato supporto, con una procedura che
assicuri la conformità dei dati acquisiti a quelli originali e la loro immodificabilità. In questo
caso è, comunque, ordinato al fornitore dei servizi di conservare e proteggere adeguatamente i
dati originali”.
NOTA
Prima della richiamata modifica legislativa il Tribunale di Chieti (30 maggio 2006) aveva affermato che “le attività
di apprensione dei ‘file di log’ da parte della polizia giudiziaria devono essere accompagnate da un attento
controllo circa le modalità di conservazione dei dati informatici, allo scopo di verificare l’assenza di
manipolazioni e la conseguente genuinità delle evidenze digitali. In mancanza di tali adempimenti i ‘file di log’,
specie ove provengano dalla stessa persona offesa, costituiscono materiale del tutto insufficiente a fondare
qualsivoglia affermazione di responsabilità al di là del ragionevole dubbio”. Tale orientamento ha trovato
conferma nell’appena sopra richiamato nuovo articolo 254 bis c.p.p.

Atra importante novità introdotta dal d.lgs 109/2008 riguarda specificamente la tipologia dei
dati soggetti agli obblighi di data retention. Mentre in precedenza la normativa di riferimento
indicava genericamente tutti i dati relativi al traffico telefonico e telematico, esclusi i contenuti
delle comunicazioni, ora l’articolo 3 del d.lgs citato contiene la specifica indicazione di quali
dati devono essere conservati dagli operatori di telefonia e di comunicazione. La norma prevede
che debbano essere conservati:
1. Dati necessari per rintracciare e identificare la fonte di una comunicazione
per la telefonia di rete fissa e la telefonia mobile:
– numero telefonico chiamante;
– nome e indirizzo dell’abbonato o dell’utente registrato.
per l’accesso Internet:
– nome e indirizzo dell’abbonato o dell’utente registrato a cui al momento della
comunicazione sono stati univocamente assegnati l’indirizzo di protocollo internet (IP), un
identificativo di utente o un numero telefonico;
per la posta elettronica:
– indirizzo IP utilizzato e indirizzo di posta elettronica ed eventuale ulteriore identificativo
del mittente;
– indirizzo IP e nome di dominio pienamente qualificato del mail exchanger host, nel caso
della tecnologia SMTP ovvero di qualsiasi tipologia di host relativa a una diversa
tecnologia utilizzata per la trasmissione della comunicazione.
per la telefonia, invio di fax, SMS e MMS via Internet:
– indirizzo IP, numero telefonico ed eventuale altro identificativo dell’utente chiamante;
 – dati anagrafici dell’utente registrato che ha effettuato la comunicazione.
2. Dati necessari per rintracciare e identificare la destinazione di una comunicazione
per la telefonia di rete fissa e la telefonia mobile:
– numero composto, ovvero il numero o i numeri chiamati e, nei casi che comportano
servizi supplementari come l’inoltro o il trasferimento di chiamata, il numero o i numeri a
cui la chiamata è trasmessa;
– nome e indirizzo dell’abbonato o dell’utente registrato;
per la posta elettronica:
– indirizzo di posta elettronica ed eventuale ulteriore identificativo del destinatario della
comunicazione;
– indirizzo IP e nome di dominio pienamente qualificato del mail exchanger host (nel caso
della tecnologia SMTP), ovvero di qualsiasi tipologia di host (relativamente a una diversa
tecnologia utilizzata), che ha provveduto alla consegna del messaggio;
– indirizzo IP utilizzato per la ricezione ovvero la consultazione dei messaggi di posta
elettronica da parte del destinatario indipendentemente dalla tecnologia o dal protocollo
utilizzato.
per la telefonia, invio di fax, SMS e MMS via Internet:
– indirizzo IP, numero telefonico ed eventuale altro identificativo dell’utente chiamato;
– dati anagrafici dell’utente registrato che ha ricevuto la comunicazione;
– numero o numeri a cui la chiamata è trasmessa, nei casi di servizi supplementari come
l’inoltro o il trasferimento di chiamata.
3. Dati necessari per determinare la data, l’ora e la durata di una comunicazione
per la telefonia di rete fissa e la telefonia mobile:
data e ora dell’inizio e della fine della comunicazione.
per l’accesso Internet:
– data e ora (GMT) della connessione e della disconnessione dell’utente del servizio di
accesso Internet, unitamente all’indirizzo IP, dinamico o statico, univocamente assegnato
dal fornitore di accesso Internet a una comunicazione e l’identificativo dell’abbonato o
dell’utente registrato.
per la posta elettronica:
– data e ora (GMT) della connessione e della disconnessione dell’utente del servizio di
posta elettronica su Internet e indirizzo IP utilizzato, indipendentemente dalla tecnologia e
dal protocollo impiegato.
per la telefonia, invio di fax, SMS e MMS via Internet:
– data e ora (GMT) della connessione e della disconnessione dell’utente del servizio
utilizzato su Internet e indirizzo IP impiegato, indipendentemente dalla tecnologia e dal
 protocollo usato.
4. Dati necessari per determinare il tipo di comunicazione
per la telefonia di rete fissa e la telefonia mobile:
– il servizio telefonico utilizzato.
per la posta elettronica Internet e la telefonia Internet:
– il servizio Internet utilizzato.
5. Dati necessari per determinare le attrezzature di comunicazione degli utenti o quelle che
si presumono essere le loro attrezzature
per la telefonia di rete fissa:
– numeri telefonici chiamanti e chiamati.
per la telefonia mobile:
– numeri telefonici chiamanti e chiamati;
– International Mobile Subscriber Identity (IMSI) del chiamante;
– International Mobile Equipment Identity (IMEI) del chiamante;
– l’IMSI del chiamato;
– l’IMEI del chiamato;
– nel caso dei servizi prepagati anonimi, la data e l’ora dell’attivazione iniziale della carta
e l’etichetta di ubicazione (Cell ID) dalla quale è stata effettuata l’attivazione.
per l’accesso Internet e telefonia, invio di fax, SMS e MMS via Internet:
– numero telefonico chiamante per l’accesso commutato (dial-up access);
– Digital Subscriber Line number (DSL) o un altro identificatore finale di chi è all’origine
della comunicazione.
6. Dati necessari per determinare l’ubicazione delle apparecchiature di comunicazione
mobile
etichetta di ubicazione (Cell ID) all’inizio della comunicazione;
dati per identificare l’ubicazione geografica della cella facendo riferimento alle sue
etichette di ubicazione (Cell ID) nel periodo in cui vengono conservati i dati sulle
comunicazioni.
Accanto a queste norme, il Garante, con il provvedimento del 17 gennaio 2008 (come
modificato in data 24 luglio 2008) citato, ha prescritto, inoltre, ai fornitori di servizi di
comunicazione elettronica accessibili al pubblico specifiche misure e accorgimenti da adottare
a garanzia dei soggetti cui appartengono i dati di traffico oggetto del trattamento, nell’ambito
della conservazione dei dati di traffico telefonico e telematico per finalità di accertamento e
repressione di reati.
 La ragione di tali prescrizioni risiede nel fatto che il trattamento dei dati di traffico da parte
dei fornitori può avere gravi ripercussioni sulla sfera privata dei soggetti interessati ed è
pertanto fondamentale affiancare delle misure di tutela della privacy dei soggetti interessati alle
norme indispensabili per la prevenzione e la repressione dei reati.
La legge n. 48/2008 ha poi introdotto il comma 4 ter all’art. 132 d.lgs. 196/2003, il quale ha
previsto che il Ministro dell’Interno o, su sua delega, i responsabili di alcuni uffici specialistici
in materia informatica o telematica della Polizia di Stato, dell’Arma dei carabinieri e del Corpo
della guardia di finanza, possano ordinare ai fornitori e agli operatori di servizi informatici o
telematici di conservare e proteggere, secondo le modalità indicate e per un periodo non
superiore a novanta giorni, i dati relativi al traffico telematico, con esclusione dei contenuti
delle comunicazioni, ai fini dello svolgimento delle investigazioni preventive, o per finalità di
accertamento e repressione di specifici reati. Il provvedimento, prorogabile per motivate
esigenze per una durata complessiva non superiore a sei mesi, può prevedere particolari
modalità di custodia dei dati e l’eventuale indisponibilità dei dati stessi da parte dei fornitori e
degli operatori di servizi informatici o telematici ovvero di terzi.
NOTA
Elisabetta Forlani (“La conservazione preventiva dei dati informatici per l’accertamento dei reati”, in Diritto
dell’Internet, 2008, 5) ha rilevato che “risulta pacifico che, mentre l’art. 132 comma 1 è riferito ai soli fornitori di
una rete pubblica di comunicazione o di un servizio di comunicazione elettronica accessibile al pubblico, il
comma 4 ter estende l’obbligo di conservazione anche agli operatori di servizi informatici o telematici”. Sono
pertanto destinatari della nuova disposizione, oltre che i fornitori suddetti, anche tutti i soggetti che offrono
direttamente o indirettamente i servizi di comunicazione elettronica, i gestori di siti Internet che diffondono
contenuti sulla Rete (cosiddetti content provider) e i gestori di motori di ricerca.

I successivi commi 4 quater e quinquies del riformato art. 132 del d.lgs. 196/2003
specificano inoltre che:
il fornitore o l’operatore di servizi informatici o telematici cui è rivolto l’ordine previsto
dal comma 4 ter deve ottemperarvi senza ritardo, fornendo immediatamente all’autorità
richiedente l’assicurazione dell’adempimento. Il fornitore o l’operatore di servizi
informatici o telematici è tenuto a mantenere il segreto relativamente all’ordine ricevuto e
alle attività conseguentemente svolte per il periodo indicato dall’autorità. In caso di
violazione dell’obbligo si applicano, salvo che il fatto costituisca più grave reato, le
disposizioni dell’articolo 326 del Codice Penale (relativo alla Rivelazione ed
utilizzazione di segreti di ufficio);
i provvedimenti adottati ai sensi del comma 4 ter sono comunicati per iscritto, senza
ritardo e comunque entro quarantotto ore dalla notifica al destinatario, al pubblico
ministero del luogo di esecuzione il quale, se ne ricorrono i presupposti, li convalida. In
caso di mancata convalida, i provvedimenti assunti perdono efficacia.
In aggiunta ai suddetti obblighi di data retention, limitati ad alcune categorie di soggetti, con il
provvedimento del 27 novembre 2008 il Garante per la protezione dei dati personali ha
prescritto specifiche misure e accorgimenti applicabili ai titolari dei trattamenti “effettuati con
strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema”,
prevedendo in particolare l’obbligo di conservazione di alcune tipologie di file di log.
Il provvedimento, applicabile quindi a tutti i titolari del trattamento (a esclusione dei
trattamenti effettuati in ambito pubblico e privato a fini amministrativo-contabili, in
considerazione del fatto che pongono minori rischi per gli interessati e sono stati oggetto delle
misure di semplificazione introdotte di recente per legge), non riguarda esclusivamente l’attività
degli amministratori di sistema intesi tradizionalmente, quali soggetti che svolgono funzioni di
gestione e manutenzione dei sistemi informatici, ma anche altre categorie di figure professionali
quali gli amministratori di banche dati, di reti e apparati di sicurezza e di sistemi di software
complessi, le cui attività possono comunque comportare in determinati casi dei rischi per la
protezione dei dati personali.
In merito agli accorgimenti previsti, il provvedimento ha in particolare introdotto uno
specifico obbligo di conservazione dei file di log degli accessi degli amministratori di sistema
alle banche dati aziendali che contengono dati personali.
Viene in particolare specificato che:
devono essere adottati sistemi idonei alla registrazione degli accessi logici (autenticazione
informatica) ai sistemi di elaborazione e agli archivi elettronici da parte degli
amministratori di sistema;
le registrazioni (access log) devono avere caratteristiche di completezza, inalterabilità e
possibilità di verifica della loro integrità adeguate al raggiungimento dello scopo per cui
sono richieste;
le registrazioni devono comprendere i riferimenti temporali e la descrizione dell’evento
che le ha generate e devono essere conservate per un congruo periodo, non inferiore a sei
mesi.
Un ulteriore obbligo di data retention è stato introdotto dal Garante per la protezione dei dati
personali con il provvedimento generale del 12 maggio 2011 recante “Prescrizioni in materia
di circolazione delle informazioni in ambito bancario e di tracciamento delle operazioni
bancarie” .Il provvedimento si applica alle banche, incluse quelle facenti parte di gruppi
(disciplinati, in generale, dall’art. 2359 c.c. e, in particolare, dagli artt. 60 e segg. del d.lgs. n.
385/1993); alle società, anche diverse dalle banche purché siano parte di tali gruppi (di seguito
anch’esse denominate “banche”), nell’ambito dei trattamenti dalle stesse effettuati sui dati
personali della clientela; a Poste Italiane S.p.A. (relativamente all’attività che gli operatori
postali possono svolgere nell’ambito dei servizi bancari e finanziari).
Obiettivo del provvedimento è fornire prescrizioni in relazione al trattamento di dati
personali della clientela effettuato al fine di garantire il rispetto dei princìpi in materia di
protezione dei dai personali ai sensi del d.lgs. 30 giugno 2003, n. 196 in ordine alla
“tracciabilità” delle operazioni bancarie effettuate dai dipendenti di istituti di credito (sia quelle
che comportano movimentazione di denaro, sia quelle di sola consultazione, cosiddetta inquiry).
Al riguardo, nel prendere atto dell’assenza di disposizioni normative in tale ambito, il Garante
ha prescritto alcune misure in ordine a:
“tracciamento” degli accessi ai dati bancari dei clienti;
tempi di conservazione dei relativi file di log;
implementazione di alert volti a rilevare intrusioni o accessi anomali ai dati bancari, tali
da configurare eventuali trattamenti illeciti.
Tali soluzioni devono comprendere la registrazione dettagliata, in un apposito log, delle
informazioni riferite alle operazioni bancarie effettuate sui dati bancari, quando consistono o
derivano dall’uso interattivo dei sistemi operato dagli incaricati, sempre che non si tratti di
consultazioni di dati in forma aggregata non riconducibili al singolo cliente.In particolare, i file
di log devono tracciare per ogni operazione di accesso ai dati bancari effettuata da un
incaricato, almeno le seguenti informazioni:
il codice identificativo del soggetto incaricato che ha posto in essere l’operazione di
accesso;
la data e l’ora di esecuzione;
il codice della postazione di lavoro utilizzata;
il codice del cliente interessato dall’operazione di accesso ai dati bancari da parte
dell’incaricato;
la tipologia di rapporto contrattuale del cliente a cui si riferisce l’operazione effettuata
(per esempio numero del conto corrente, fido/mutuo, deposito titoli).
Le misure di cui al presente paragrafo devono essere adottate dai destinatari nel rispetto della
vigente disciplina in materia di controllo a distanza dei lavoratori (art. 4, l. 20 maggio 1970, n.
300), tenendo altresì conto dei princìpi affermati dal Garante in tema di informativa agli
interessati nelle linee guida sull’utilizzo della posta elettronica e di Internet. Il provvedimento
stabilisce inoltre che i log di tracciamento delle operazioni di inquiry siano conservati per un
periodo non inferiore a 24 mesi dalla data di registrazione dell’operazione. Ciò in quanto un
periodo di tempo inferiore non consentirebbe agli interessati di venire a conoscenza
dell’avvenuto accesso ai propri dati personali e delle motivazioni che lo hanno determinato.
Come anticipato, il Garante ha altresì prescritto l’implementazione di alert volti a rilevare
intrusioni o accessi anomali e abusivi ai sistemi informativi; anche a tal fine, negli strumenti di
business intelligence utilizzati dalle banche per monitorare gli accessi alle banche dati
contenenti dati bancari devono confluire i log relativi a tutti gli applicativi utilizzati per gli
accessi da parte degli incaricati del trattamento.
NOTA
Il Garante, con il provvedimento “ Chiarimenti in ordine alla delibera n. 192/2011 in tema di circolazione delle
informazioni riferite a clienti all’interno dei gruppi bancari e ‘tracciabilità’ delle operazioni bancarie; proroga del
termine per completare l’attuazione delle misure originariamente prescritte” del 18 luglio 2013 “nel prendere atto
delle riferite circostanze e, segnatamente, delle rappresentate, obiettive difficoltà degli operatori ad ultimare
l’implementazione delle complesse misure imposte, si ritiene di poter accogliere la richiesta di proroga avanzata
da ABI, differendo al 3 giugno 2014 il termine precedentemente fissato al 3 dicembre 2013. L’entità di tale
differimento, del resto, non pregiudica il raggiungimento in tempi brevi della piena tutela dei diritti degli interessati
e, al contempo, la realizzazione del livello di sicurezza delle informazioni bancarie che l’implementazione del
sistema è volta a garantire”.

Se gli unici obblighi di conservazione dei file di log sono quelli sopra analizzati, si deve
considerare che non esiste un divieto alla loro raccolta e conservazione. Purtuttavia, in tal caso
l’azienda che intenda raccoglierli e conservarli dovrà rispettare, oltre al generale principio del
mantenimento per il tempo strettamente necessario alle finalità della raccolta stessa, i principi e
le regole fissati dal Garante per la protezione dei dati personali, nonché lo Statuto dei
Lavoratori.

Profili giuridici della Network Forensics

Come anticipato all’inizio del Capitolo 1, uno degli strumenti per l’acquisizione dei dati è la
loro intercettazione durante il passaggio da un sistema a un altro.
NOTA
Gianluca Braghò (“Le indagini informatiche fra esigenze di accertamento e garanzie di difesa”, in Il diritto
dell’informazione e dell’informatica, 2005, 3) ha scritto che “le esigenze investigative che vengono soddisfatte
dalle indagini tecniche sono varie. Può accadere di dover monitorare tutto il traffico informatico generato da un
singolo utente, intercettando tutte le informazioni da qualsiasi tipo di connessione (analogica, ISDN, ADSL, WAP,
servizio di posta elettronica), come si può rendere opportuno effettuare una selezione di un particolare flusso di
dati provenienti da una specifica area o da un determinato server provider, ovvero da un intero dominio, allo
scopo di acquisire informazioni utili da porre in relazione a singole utenze che si connettono alla sorgente
intercettata, nonché al fine di accertare le finalità delittuose per cui la sorgente stessa è stata creata ed
utilizzata”.

In virtù della garanzia dei diritti fondamentali dell’individuo, le operazioni di intercettazione

costituiscono un mezzo eccezionale esperibile solo in determinate situazioni. Si consideri che
l’art. 617 quater c.p. (Intercettazione, impedimento o interruzione illecita di comunicazioni
informatiche o telematiche) prevede come reato (punito con la reclusione da sei mesi a quattro
anni) la condotta di “chiunque fraudolentemente intercetta comunicazioni relative ad un sistema
informatico o telematico o intercorrenti tra più sistemi, ovvero le impedisce o le interrompe”.
Nel contesto penale, come visto, l’intercettazione di comunicazioni informatiche o
telematiche è uno dei mezzi di ricerca della prova disciplinata dagli articoli 266 sgg. del
Codice di Procedura Penale. Rimandando a quanto già rilevato in questo capitolo circa i limiti
di ammissibilità delle intercettazioni, in questa sede giova ricordare come le stesse debbano
essere autorizzate dal giudice per le indagini preliminari mediante decreto motivato quando vi
sono gravi indizi di reato e l’intercettazione è assolutamente indispensabile ai fini della
prosecuzione delle indagini.
NOTA
Una sentenza della Corte di Cassazione Penale ha evidenziato che “l’intercettazione di flussi telematici
riconducibili ad un determinato utente mediante la procedura di monitoraggio del percorso, disposta dal gip,
comporta la legittima captazione dei flussi informatici gestiti dal soggetto titolare di un determinato nome utente
che contraddistingue sia l’account di posta elettronica che quello di connessione. Conseguentemente non è
causa di invalidità o di inutilizzabilità dei provvedimenti autorizzativi l’improprio riferimento informatico al solo
‘account’ di posta elettronica e non a quello di connessione, trattandosi di due aspetti della stessa realtà
giuridica, indicativa della facoltà di accesso di un determinato utente alla trasmissione e alla ricezione dei flussi
telematici” (Cass. Pen. 14 febbraio 2005, n. 12901).

Nello stesso senso altra Cassazione ha evidenziato come “la localizzazione di una persona o
di un oggetto in movimento, anche se realizzata con modalità e tecnologie similari a quelle con
cui vengono eseguite le intercettazioni di conversazioni o comunicazioni, non può essere
considerata alla stregua di una vera e propria attività di intercettazione, il cui concetto è relativo
ad una attività di ascolto, lettura o captazione di comunicazioni tra due o più persone, laddove
l’indagine rivolta a seguire i movimenti sul territorio di un soggetto (o di un oggetto), a
localizzarlo o a controllare la sua presenza in un determinato luogo va interpretato quale una
sorta di pedinamento tecnologicamente evoluto e come tale rientrante nella categoria dei mezzi
di ricerca della prova cosiddetti atipici o innominati. In siffatti casi, pertanto, non necessita
l’osservanza delle disposizioni contenute negli art. 266 s. c.p.p., né appare necessario il decreto
motivato del P.M.” (cfr. Cass. Pen. 27 febbraio 2002, n. 16130).
Fuori da questi casi non è consentita alcuna forma di intercettazione, la cui effettuazione può
comportare come visto la sanzione di carattere penale sopra esaminata. Si aggiunga che
l’articolo 240 del Codice di Procedura Penale così come sostituito dal d.l. 22 settembre 2006,
n. 259, convertito, con modificazioni, in legge 20 novembre 2006, n. 281, prevede che “il
pubblico ministero dispone l’immediata secretazione e la custodia in luogo protetto dei
documenti, dei supporti e degli atti concernenti dati e contenuti di conversazioni o
comunicazioni, relativi a traffico telefonico e telematico, illegalmente formati o acquisiti. Allo
stesso modo provvede per i documenti formati attraverso la raccolta illegale di informazioni. Di
essi è vietato effettuare copia in qualunque forma e in qualunque fase del procedimento ed il
loro contenuto non può essere utilizzato”. Il terzo comma dell’articolo 240 c.p.p. stabilisce
inoltre che “il pubblico ministero, acquisiti i documenti, i supporti e gli atti di cui al comma 2,
entro quarantotto ore, chiede al giudice per le indagini preliminari di disporne la distruzione”. I
risultati delle intercettazioni fuori dei casi consentiti dalla legge o qualora non siano state
osservate le disposizioni sopra esaminate non possono essere utilizzati in sede processuale (art.
271 c.p.p.).
 NOTA
Una sentenza della Corte di Cassazione Penale ha evidenziato che “è legittimo il decreto del pubblico ministero
di acquisizione in copia, attraverso l’installazione di un captatore informatico, della documentazione informatica
memorizzata nel “personal computer” in uso all’imputato e installato presso un ufficio pubblico, qualora il
provvedimento abbia riguardato l’estrapolazione di dati, non aventi ad oggetto un flusso di comunicazioni, già
formati e contenuti nella memoria del “personal computer” o che in futuro sarebbero stati memorizzati. (Nel
caso di specie, l’attività autorizzata dal P.M. consistente nel prelevare e copiare documenti memorizzati
sull’”hard disk” del computer in uso all’imputato, aveva avuto ad oggetto non un “flusso di comunicazioni”,
richiedente un dialogo con altri soggetti, ma “una relazione operativa tra microprocessore e video del sistema
elettronico”, ossia “un flusso unidirezionale di dati” confinati all’interno dei circuiti del computer; la S.C. ha
ritenuto corretta la qualificazione dell’attività di captazione in questione quale prova atipica, sottratta alla
disciplina prescritta dagli artt. 266 ss. cod. proc. pen.”; Cass. Pen. 14 ottobre 2009).

In merito alle modalità di esecuzione delle operazioni di intercettazione di comunicazioni

informatiche o telematiche, l’articolo 268 comma 3 bis c.p.p. prevede che “il pubblico
ministero può disporre che le operazioni siano compiute anche mediante impianti appartenenti a
privati”. Questa disposizione rende molto più agevole il compimento delle intercettazioni
rispetto a quelle telefoniche, che invece possono essere compiute esclusivamente, salvo
eccezioni, per mezzo degli impianti installati nella Procura della Repubblica (art. 268 comma 3
c.p.p.).

Problematiche aperte
Terminata la trattazione dei principali aspetti riguardanti gli aspetti legali della Digital
Forensics, in sede conclusiva è il caso di esaminare quali sono le principali problematiche
rimaste aperte.
Innanzitutto la Digital Forensics è una disciplina che, seppur già sviluppata e utilizzata in altri
Paesi e soprattutto negli Stati Uniti, solo da pochi anni si sta affermando in Italia. Si deve
purtroppo ancora rilevare una generale impreparazione, da intendersi come assenza della
cultura informatica necessaria per affrontare tematiche quali l’acquisizione delle prove
informatiche, sia da parte dei magistrati e della polizia giudiziaria, sia da parte dei difensori
delle altre parti coinvolte nel processo.
Il problema è da prendere in considerazione, in quanto finché sull’acquisizione della prova
informatica, e in generale sulle metodologie di indagine informatica, si permarrà in uno stato di
incertezza, sarà alta la probabilità che alcuni processi finiscano per avere un esito diverso da
quello sperato dalle parti a causa o per l’incapacità di trovare le prove informatiche tra i bit e i
file di un supporto o per l’utilizzo di tecniche che non consentono di garantire la genuinità degli
elementi raccolti, con la conseguente inutilizzabilità o inattendibilità delle prove in sede
processuale. Anche i giudici, d’altro canto, sono sovente impreparati a valutare nel processo le
prove informatiche ritenendo attendibili anche quelle che (a nostro avviso) sarebbero dovute
essere dichiarate inutilizzabili, in quanto raccolte con metodologie approssimative e comunque
inidonee a garantire la genuinità dei dati e delle informazioni originali. I magistrati giudicanti
sembrano infatti a volte applicare principi differenti in materia di prova informatica rispetto a
quelli stabiliti in via generale dal nostro ordinamento e che impongono il mantenimento
dell’integrità della prova al momento della sua acquisizione e successiva conservazione. Le
caratteristiche peculiari delle prove informatiche non devono comportare invece una
diminuzione delle garanzie necessarie alla loro utilizzabilità in giudizio.
NOTA
Andrea Monti scriveva nel 2003 (“Attendibilità dei sistemi di Computer Forensics”, in ICT-Security, 2003, 9), ma
le sue valutazioni sono ancora oggi di grande attualità: “Attualmente nei processi è molto frequente che il
pubblico ministero chieda che vengano considerate ‘prove’: log di server inviati via fax dal provider, stampe di
home page, stampe di e-mail (nemmeno firmate digitalmente), stampe di sessioni di chat, contenuti di supporti
memorizzazione utilizzati dagli accertatori prima di apporre i sigilli, contenuti di supporti sequestrati ma non
sigillati, reportistiche generate da tool proprietari di Computer Forensics, per di più utilizzati su supporti acquisiti
in modo non rigoroso, ‘perizie’ d’ufficio predisposte da ‘consulenti’ privi di formazione specifica nel settore della
digital evidence e, in qualche caso, nemmeno laureati in materie tecniche, relazioni di servizio sui contenuti di
un sito remoto predisposte da agenti e ufficiali di polizia giudiziaria privi di competenze specifiche,
identificazione di un soggetto solo tramite userid e intestazione eventuale di utenza telefonica impiegata per il
collegamento in rete. Capita con altrettanta frequenza che i magistrati giudicanti (che probabilmente non
vogliono ‘sprecare’ il ‘lavoro’ fatto durante le indagini) ritengano attendibili queste ‘prove’ e su di esse basino le
loro decisioni. Superando con il principio del libero convincimento del giudice i dati tecnici, che pure dovrebbero
condurre all’inutilizzabilità di informazioni così malamente raccolte”.

Le problematiche sopra riscontrate erano in parte dovute all’assenza di una legislazione che
definisse le regole da osservare per l’acquisizione e conservazione delle prove informatiche,
regole che consentissero agli operatori di affrontare le attività di indagine all’interno di un
preciso contesto normativo e che fornissero ai giudici gli strumenti per valutare con maggiore
sicurezza la validità delle metodologie utilizzate. Nel contesto penale, le modifiche e
integrazioni apportate dalla legge 48/2008 al Codice di Procedura Penale dovrebbero
consentire nel tempo la risoluzione delle problematiche sopra evidenziate, dal momento che
stabiliscono, come visto, in relazione, per esempio, alle attività di ispezione e perquisizione l’
obbligo per la polizia giudiziaria di adottare “misure tecniche dirette ad assicurare la
conservazione dei dati originali e ad impedirne l’alterazione”. Tale obbligo avrà come diretta
conseguenza la necessità di stabilire quali siano i sistemi idonei a raggiungere il risultato voluto
da tali norme nonché di creare regole tecniche chiare per l’esecuzione delle operazioni (Monti,
2008, op. cit.).
Un’ultima considerazione va fatta in merito alla Digital Forensics a livello aziendale, che sta
suscitando un grande interesse tra gli operatori economici.
Dotarsi degli strumenti per reagire agli attacchi informatici, sia provenienti dall’esterno sia
dall’interno e per reperire e preservare eventuali fonti di prova utili per supportare un eventuale
azione in sede giudiziaria sta diventando un’esigenza sempre più avvertita. Nonostante questo,
le competenze necessarie all’applicazione delle metodologie di Digital Forensics all’interno
delle aziende richiedono un grosso sforzo economico e organizzativo, forse al momento
affrontabile solo dalle aziende di grandi dimensioni.
NOTA
Giovanni Ziccardi (op. cit.) ha rilevato che accanto a una definizione pura di Computer Forensics che
“comprende solo, ed esclusivamente, l’ambito legale, o processuale, dell’acquisizione, analisi e esposizione del
dato” esiste “una consolidata tradizione di Forensics aziendale, una categoria concettuale che può risultare
difficile da comprendere se si intende il termine Forensics correlato esclusivamente all’ambito giuridico. La
Computer Forensics in ambito aziendale altro non è che una simulazione di attività che potrebbero essere
finalizzate alla produzione della prova in giudizio; l’attività è effettuata, però, in ambito interno aziendale,
seguendo eventualmente identiche metodologie”.

Tuttavia, la creazione di procedure sia pur non a livello avanzato da adottare in caso di
attacco ai fini del reperimento e preservazione le fonti di prova informatica possono essere di
sicuro supporto alle indagini dell’autorità giudiziaria ed evitano che l’attività di indagine sia
vanificata dall’inquinamento delle prove proprio a opera del soggetto leso dall’attività
criminosa.
 Capitolo 3

Acquisizione del dato: sequestro e

duplicazione

“... Era lì, dopo due ore di minuziosa ricerca, in quella stanzetta coperta di carabattole da geek: un drive USB a forma di
Lego, posto in cima a un modellino della Morte Nera. Neanche Sheldon in The Big Bang Theory...”

Modalità di acquisizione
Il dato è il fine ultimo della ricerca del Digital Forensics expert. Vista la sua immaterialità,
può trovarsi praticamente ovunque e assumere molteplici forme. Può essere un’immagine in un
telefono, un file di testo in una memory card, un record in un database dipartimentale,
un’immagine celata in un file mp3, una mail su un server su Internet, una foto su Flickr, un file su
DropBox o su Google Drive... È la fonte di prova che può dare una svolta alle indagini o
addirittura chiudere il caso.
Il problema primario è riuscire ad acquisirlo; la conservazione sarà una questione da
affrontare in seguito.
Le modalità di acquisizione del dato possono essere ricondotte alle seguenti.
Sequestrarlo. Non è nient’altro che prendere fisicamente il supporto su cui il dato stesso
risiede.
Copiarlo. Il supporto originale viene acquisito sotto forma di copia delle informazioni
contenute nello stesso e riversato su un altro supporto.
Intercettarlo. Il dato viene acquisito nel suo passaggio da un sistema a un altro. La lettura
non avviene dal supporto di memorizzazione dove il dato risiede, ma dal medium usato per
la sua trasmissione tra due sistemi.
Ognuno di questi modi richiede specifiche accortezze per una gestione corretta della prova.
Si ricordi a questo proposito che un qualunque sistema di memorizzazione deve essere trattato
secondo due livelli di esistenza: quello fisico e quello digitale. In questo capitolo verranno
discussi il sequestro e la copia del dato, mentre nel prossimo tratteremo il tema delicato
dell’intercettazione.
 Ricerca
Sembra banale, ma qualunque sia il sistema che si voglia o si debba utilizzare per acquisire il
dato che si sta cercando, per prima cosa bisogna sapere dove si trova il dato stesso. La prima
fase della ricerca è quindi volta a individuare dove un dato è conservato. Una delle maggiori
difficoltà di tutta l’indagine è proprio questa.
Per esempio, nella casa dell’indagato dove si è deciso di effettuare una perquisizione si
possono trovare decine di supporti o apparecchiature candidate a contenere le informazioni
ricercate. Non è difficile rendersene conto. Siamo letteralmente circondati da oggetti che
possono memorizzare (e celare) informazioni. Pensare che queste debbano risiedere solamente
su un computer è quantomeno riduttivo. Chi scrive ha più volte cercato di ribadire efficacemente
il concetto presentandosi a svariate conferenze sull’argomento con un cerottino in faccia (quindi
sotto gli occhi di tutti) sotto al quale era celata una minuscola memoria Transflash da 16 GB.
Sarebbe sfuggita a molti inquirenti.
Le memory card, infatti, oltre a esistere in una serie infinita di formati, hanno dimensioni
fisiche tali da permetterne un occultamento facilissimo e dimensioni logiche ormai pari a decine
di gigabyte.
Ma esistono molti altri luoghi dove nascondere dei dati. Di seguito sono citati alcuni esempi
reali di dove sono state trovate informazioni vitali ai fini di indagine.
Lettori multimediali. Tutti i lettori mp3/mp4 sono anche delle memorie di massa
generiche, quindi possono contenere dati di diverso tipo (non solo musicali o video).
Inoltre, la loro dimensione logica è in crescita continua. Spesso sono espandibili tramite
memory card e quindi dispongono di ampie capacità di memorizzazione.
Hard disk esterni. In più di un’occasione i dati ricercati si trovavano in un hard disk
esterno, opportunamente occultato in luogo lontano da quello di utilizzo del computer di
casa.
Drive USB. Un buon esempio dell’impiego di questa tipologia di apparecchiature come
nascondiglio per informazioni è dato dai mouse USB, in grado di celare al loro interno un
hub USB e un flash disk USB. Nel momento in cui si collega il mouse, appare
“magicamente” anche un flash disk.
Smartphone. Sempre più spesso gli smartphone e le memorie in essi inserite si prestano a
celare informazioni vitali ai fini dell’indagine. Anzi, vista la loro diffusione sempre più
capillare e la disponibilità di offerte assolutamente competitive da parte dei carrier, molti
di questi apparecchi sono utilizzati molto più spesso dei computer per raccogliere e
distribuire informazioni personali. Un adolescente di oggi potrebbe anche farvi curiosare
sul suo PC (se siete in confidenza), ma potrebbe rifiutarsi categoricamente di mostrarvi il
suo smartphone. Le nuove generazioni sono sempre un ottimo spunto relativamente ai trend
 attuali e futuri.
NAS. Negli ultimi anni la diffusione dei sistemi di storage personale è salita notevolmente.
Con il proliferare di apparecchi tecnologici, se si vuole evitare una frammentazione
eccessiva dei propri dati è necessario consolidare. Questi apparecchi sono a tutti gli effetti
dei microserver dotati di un sistema operativo avanzato (spesso di derivazione Linux o
*BSD), molteplici funzioni (dal mero file server a un sistema di stream multimediale
compatibile con lo standard DLNA, per non contare funzioni di web, mail e RDBMS
server), e hanno il vantaggio di consumare infinitamente meno di un PC. Possono essere
comandati da remoto, hanno delle applicazioni che consentono loro di essere interfacciati
con smartphone e tablet e, non ultimo, dispongono di sistemi RAID che permettono di
tenere i propri dati al sicuro da guasti hardware.
Tablet. Anche se il tablet è da sempre principalmente un dispositivo di fruizione dei dati,
esso dispone di quantità di memoria che possono raggiungere i 64 GB. Ergo, è possibile
trovarci sopra ben più che semplici file di configurazione dell’app di turno.
Cloud. Si sa, vuol dire tutto e il contrario di tutto, ma nel nostro caso significa che i dati
non stanno semplicemente sul dispositivo utilizzato per fruirli (o in prossimità di esso). Un
esempio banale aiuta a chiarire. Al momento attuale chi scrive sta usando un personal
computer di tipo notebook collegato via NX Server a una macchina virtuale openSUSE
residente in un datacenter in Svizzera. Nel contempo sta ascoltando la musica spedita in
streaming da Google Music. Le copie di backup del libro sono su un server virtuale con
OwnCloud in un datacenter a Singapore. Quindi un’analisi del computer laptop non farebbe
altro che dare risultati negativi. Al massimo evidenzierebbe l’installazione di un client NX
per Windows e la presenza di una macchina raggiungibile su Internet. Se invece di usare
NX si fosse utilizzato un portale Ulteo o Citrix, non si sarebbe trovato alcunché.
Social network. Inutile ignorarlo: ormai le persone pubblicano la propria vita su Internet.
Che sia un social network generalista come Facebook o Google+, specifico per il lavoro
(LinkedIn), usato per brevi comunicazioni (Twitter) o specialistico (come i vari social
network che lavorano in background per permettere ai giocatori di tutto il mondo di
interagire tra loro con le varie console per videogiochi), queste reti contengono ormai
petabyte di dati che potrebbero essere utili in svariati casi.
L’elenco precedente non ha la pretesa di essere esaustivo. Vuole solamente evidenziare,
prima di passare all’illustrazione delle modalità di acquisizione di questo tipo di prove, un
punto fondamentale, ovvero che i dati non si trovano necessariamente dove ci si può aspettare
che siano.
DIARIO DI UN DIGITAL FORENSICS EXPERT
È esemplare il caso di una persona accusata di distribuzione di foto di carattere pedo-pornografico. Si lavorò per
oltre un mese sul computer sequestrato. Si poté solamente capire che la macchina era troppo pulita: cache dei
 browser svuotate, cronologia cancellata, script per azzerare lo slack space inserito nello scheduler di Windows,
wiper a 7 passaggi installato al posto di un normale deleter. Uniche due note stonate erano un pagefile contenente
decine di URL riferiti a siti pedofili e un registry contenente informazioni riguardanti un hard disk esterno USB. Il
caso fu archiviato ma fu palese che il disco fisso esterno, non rinvenuto in fase di perquisizione, probabilmente
sarebbe stato determinante per il corso dell’indagine.

TREND PRESENTI E FUTURI

Ben più di un’amica mi ha chiesto se vale più la pena di comprarsi un computer o un tablet. Se il computer è da
sempre lo strumento principale per lavorare e produrre contenuti, un tablet abbinato a una connessione veloce, a
un paio di servizi utili (per esempio Google Drive e Google Apps, oppure SkyDrive e Office 365) e a una tastiera
permette di sopperire a molte delle esigenze di un utente comune.
Ovviamente un sistema di questo genere è implicitamente “antiforensics”, se non nel senso tecnico del termine,
certamente in quello legale.

Sequestro
È la forma di acquisizione solitamente preferita dalle forze dell’ordine, perché rispetto agli
altri sistemi presenta i seguenti vantaggi.
Semplicità. Sequestrando il supporto fisico non si va incontro a tutte le complicazioni
derivanti dalla duplicazione del dato (copia bit-a-bit e validazione tramite hash). È
sufficiente acquisire l’oggetto e preoccuparsi solamente di due cose: una corretta gestione
del supporto fisico per poter dimostrare che non è stato alterato nell’analisi e l’attenzione
nella catena di custodia.
Velocità. Una volta identificato il sistema o il supporto dove risiedono i dati, basta
prepararlo per il trasporto.
Riguardo per le evidenze fisiche. Potrebbe essere necessario rilevare delle prove anche
dalla parte fisica del computer, per esempio ricercando impronte digitali o esaminando
quanto contenuto all’interno (polveri comprese).
Di contro, non sempre è possibile riuscire a sequestrare i dati. Esiste una serie di casi e
situazioni nei quali questa tecnica non è applicabile.
I dati risiedono su sistemi dipartimentali. Si immagini un AS/400 midsize, un cluster di
computer che forniscono servizi via grid computing, sistemi distribuiti come Hadoop,
oppure nodi di un cloud gestiti da un unico orchestrator. Oppure si pensi a un
supercomputer come un Cray, un IBM o un Fujitsu. In questo caso si parla di sistemi che
possono essere distribuiti su decine di rack diversi. Un sequestro è impossibile proprio per
questioni logistiche.
I dati risiedono su sistemi che non possono essere spenti. Si parla di sistemi di supporto
vitale, sistemi di gestione dell’infrastruttura (computer per il controllo di semafori o
centrali elettriche) o semplicemente sistemi di gestione della produzione.
 I dati sono in transito. Nel luogo fisico in cui si procede al sequestro i dati possono essere
solo in transito (si pensi per esempio a un ufficio collegato a delle sedi remote, a una
centrale telefonica o a un nodo di collegamento tra più reti).
I dati risiedono in datacenter. Il trend attuale all’interno dei datacenter è quello di
centralizzare le risorse, sia a livello di potenza computazionale (CPU e RAM) sia a livello
di spazio (storage). “Consolidare” è la parola d’ordine. Si concentra tutto su pochi server
fisici e su grandi storage, per poi creare decine o centinaia di macchine virtuali. Nel
momento in cui si utilizzano file system distribuiti e storage nell’ordine di vari petabyte,
dove risiedono sistemi di centinaia di soggetti diversi, è impensabile poter procedere a un
sequestro.
Il sistema è virtuale. Nel momento in cui il sistema è virtualizzato, e quindi disgiunto
dall’hardware su cui gira, un sequestro, nel senso appena esposto, non ha ragione di
esistere.
Il sequestro, quindi, non è la soluzione definitiva a ogni problema riguardante l’acquisizione
dei dati, anche se è indubbio che sia comunque il metodo più veloce e pratico.
È bene considerare, allora, le accortezze da adottare per effettuare un sequestro di materiale
informatico nella maniera più corretta possibile, così da evitare quegli errori che possono
inficiare l’indagine già al suo inizio.
COSA DICE LA LEGGE
Il sequestro probatorio è un mezzo di ricerca della prova disciplinato dagli articoli 253 e sgg. del c.p.p. Attraverso il
sequestro, come visto, l’autorità giudiziaria acquisisce il corpo del reato o le cose pertinenti necessarie per
l’accertamento dei fatti. Occorre comunque considerare che l’autorità giudiziaria non ha la facoltà di disporre un
sequestro indiscriminato anche di materiale che non ha alcuna attinenza con la fattispecie per cui si sta
procedendo. Questo assume ancora maggior rilevanza in relazione alle indagini informatiche, dal momento che
spesso le strumentazioni informatiche e telematiche non sono esclusivamente il mezzo utilizzato per compiere un
reato, ma, soprattutto in ambito aziendale, rivestono un ruolo fondamentale per il soggetto che ne ha la
disponibilità. L’art. 254 bis c.p.p. prevede ora particolari modalità per procedere al sequestro di dati informatici
presso fornitori di servizi informatici telematici e di telecomunicazioni per evitare che tale attività possa comportare
l’interruzione nella prestazione di servizi di elevata rilevanza e criticità.

Alcune considerazioni
In un sequestro occorre tenere conto, come si è detto, anche della parte fisica del supporto di
memorizzazione (dalla memoria USB al grande server dipartimentale), non solo di quella
logica. Per esempio, su una tastiera è possibile trovare moltissime impronte digitali, che
potrebbero rivelarsi utili per svariati motivi.
DIARIO DI UN DIGITAL FORENSICS EXPERT
Una grossa multinazionale possedeva in Francia un laboratorio di ricerca e sviluppo. A un certo punto si cominciò
a sospettare che ci fosse all’interno del laboratorio una spia industriale. Furono avviate le ricerche e si individuò, in
 particolare, un computer che poteva essere stato utilizzato per scaricare alcune informazioni riservate dalla LAN
interna. Il computer fu preso in custodia da una persona di fiducia, che lo portò in treno fino a Parigi e da qui in
aereo in Italia, dove fu consegnato ai nostri laboratori. Aperto il computer fu lampante che qualcosa non quadrava.
Tutta la macchina era ricoperta di polvere tranne il disco fisso, un Maxtor la cui data di produzione risaliva a non
più di un mese prima. Inutile dire che il disco era nuovissimo e non presentava un solo bit che non fosse a zero. Si
noti che il computer era stato aperto e fotografato al momento della presa in custodia, e il disco montato risultava
essere quello originale. Ricostruendo la vicenda emerse che l’unico lasso temporale in cui il computer era rimasto
incustodito era stato quello durante il quale la persona che lo aveva in carico si era spostata al vagone ristorante,
sul treno. La sostituzione del disco fu chiaramente fatta in quel momento.

L’episodio ricordato nel riquadro precedente, seppur limite, evidenzia due fatti inopinabili:
con un’analisi tradizionale delle tracce fisiche si sarebbero potuti evidenziare elementi in
grado di indirizzare l’indagine, giungendo magari all’individuazione del responsabile della
sostituzione del disco fisso;
una corretta procedura di trasporto (che avrebbe dovuto includere anche l’apposizione di
sigilli non rimovibili) avrebbe evitato la sostituzione del disco fisso.

Preservare lo stato della prova

Anni di telefilm polizieschi hanno insegnato a chiunque come sia vitale conservare lo stato
della prova per evitare che venga compromessa. Per un sistema informatico, come si è detto più
volte, tale accortezza deve essere usata su due livelli diversi.
Per quanto riguarda la parte digitale è bene ricordare una distinzione fondamentale, ovvero
quella tra supporti (senza ulteriori distinzioni, quindi dischi fissi, memorie USB, memory card
nelle macchine fotografiche e così via) modificabili e supporti non modificabili. I primi
dovrebbero essere trattati con tutta l’attenzione possibile, dato che il mezzo stesso è stato
progettato per far sì che le informazioni al loro interno possano variare con l’uso e il tempo. Nel
secondo caso il trattamento può essere semplificato. In ogni modo, è evidente che trattare ogni
supporto come modificabile riduce i rischi di errore.
Effettuata questa distinzione, occorre capire qual è la tecnologia usata sul dispositivo. È
indubbio che i fattori che possono modificare un supporto magnetico possono essere diversi da
quelli in grado di agire su un sistema ottico.
COSA DICE LA LEGGE
La preservazione dello stato della prova assume una rilevanza fondamentale ai fini dell’utilizzabilità della stessa in
giudizio. Come visto, a titolo esemplificativo, in seguito alle modifiche introdotte dalla l. 48/2008 agli artt. 244 c.p.p.
(relativo alle ispezioni) e 247 c.p.p. (relativo alle perquisizioni), nel porre in essere tali attività dovranno essere
adottate dall’autorità giudiziaria “misure tecniche dirette ad assicurare la conservazione dei dati originali e a
impedirne l’alterazione”. Grande importanza riveste dunque la fase di acquisizione della fonte di prova informatica,
posto che la commissione di errori in questo momento potrebbe vanificare le successive attività di analisi.
Particolare attenzione, quindi, deve essere prestata nell’utilizzo di adeguate metodologie per la creazione della
prima copia su cui effettuare le indagini al fine di evitare qualsiasi alterazione dei dati originari. Prima di iniziare
 questa attività, pertanto, è necessario valutare se la metodologia e gli strumenti utilizzati consentano
effettivamente di preservare i dati originali, soprattutto nel caso si stia compiendo un accertamento tecnico
ripetibile (art. 359 c.p.p.).

Supporti magnetici
Quando si ha a che fare con supporti magnetici, va ricordato che non esistono soluzioni
definitive, o modalità a prova di danno, per il loro trattamento. Per quante precauzioni si
possano prendere, un campo magnetico sufficientemente forte sarà in grado di modificare le
informazioni contenute nel supporto. I rischi possono essere ridotti utilizzando apposite cassette
metalliche (ignifughe) trasportabili. Si noti però che uno schermo metallico permette di ridurre
l’azione di un campo magnetico esterno ma non di eliminarne del tutto gli effetti.
I sacchetti antistatici sono utili solamente per supporti che contengono anche parti
elettroniche, per esempio gli hard disk. Questi ultimi dovrebbero essere opportunamente protetti
sia dall’elettricità statica sia da eventuali urti che possano danneggiarne le componenti interne.
NOTA
Per le cassette metalliche ignifughe si può prendere a esempio la produzione di Technomax,
http://www.technomax.it/it/scheda_serie/p/technofire_2000, mentre per i sacchetti antistatici si veda il sito
http://it.rs-online.com/web/p/buste-per-sicurezza-esd/2877874/.

I nastri magnetici richiedono una speciale attenzione. È buona norma prendere un nastro e
riporlo sempre nella sua custodia plastica originale per evitare che sia contaminato da polvere o
da agenti esterni. Sarebbe inoltre preferibile custodirli in posizione verticale e a temperatura
costante così da non introdurre ulteriori tensioni all’interno delle spire.
Infine, bisogna sempre ricordare di imbustare singolarmente ogni supporto. Non si deve, per
ragioni giuridiche prima che tecniche, prendere svariati supporti rimovibili e imbustarli assieme
con una descrizione sommaria (per esempio “100 floppy neri marca 3M senza etichetta”): il
rischio è di non fornire sufficienti garanzie e di vedersi quindi contestare le prove acquisite.
Con l’uscita del formato LTO-6 un nastro può arrivare ad avere una capacità di archiviazione
nativa di ben 2,5 TB. Non va quindi trascurata la quantità di informazioni che vi si possono
trovare. Il vecchio detto “Non sottovalutare la banda passante di una station wagon piena di
nastri” rimane sempre attuale.

Supporti ottici
I principali nemici dei moderni supporti ottici sono luce e calore. È sufficiente lasciare un
CD-R/RW, DVD+-R/RW o un Blu-ray RW alla diretta luce del sole per qualche ora per
danneggiare irrimediabilmente il contenuto. Sarebbe perciò buona cosa imbustarli in un
sacchetto a prova di luce (per esempio di carta o plastica opaca) per la raccolta di prove,
possibilmente nella loro custodia originale.
I supporti ottici dovrebbero essere sempre trattati come supporti alterabili. Un CD-R,DVD+/-
R o un Blue-ray può essere considerato inalterabile solamente quando il disco ha subìto il
processo di finalizzazione. Prima di allora è possibile intervenire aggiungendo sessioni sul
disco o perfino eliminando dei file (in realtà non è possibile eliminarli fisicamente ma solo
dereferenziarli dal file system, come si potrà constatare nel capitolo riguardante i supporti
ottici). Dato che non si può stabilire a priori se un CD-R o un DVD+/-R sia stato finalizzato o
meno, occorre porsi nella condizione più cautelativa possibile.
I supporti CD-RW, DVD+/-RW e DVD-RAM sono modificabili e il loro stato può essere
alterato in qualsiasi momento, siano essi finalizzati oppure no. Inoltre, una cancellazione totale
può portare all’eliminazione definitiva delle informazioni dal supporto. Per questo motivo
devono essere applicate tutte le precauzioni necessarie, operando una rigida gestione della
catena di custodia e avendo l’accortezza di sigillare i supporti in maniera che si possa
dimostrare una loro eventuale successiva apertura.

Memory card e flash disk

I supporti tipo memory card e flash disk (USB o SSD interni che siano) devono essere trattati
alla stregua di un supporto magnetico, come un hard disk. Rispetto ai dischi fissi, hanno però il
vantaggio di non possedere delle parti in movimento e di non essere quindi soggetti a problemi
dovuti a vibrazioni e urti. Tuttavia, molti supporti di questo genere sono sensibili a flessione e
schiacciamento, visto il loro limitato spessore.
Nel caso di memorie o flash disk USB dotati di switch per la protezione hardware da
scrittura è bene che questo sia posto in posizione di sola lettura prima di imbustare e sigillare il
supporto.
È infine necessario impacchettare questo tipo di memorie in un sacchetto antistatico (la quasi
totalità di esse ha i contatti a vista, quindi potrebbero essere danneggiate in maniera irreparabile
da una scarica elettrostatica).

Personal computer
Molto spesso i computer non vengono gestiti correttamente durante la fase di sequestro. Un
elaboratore elettronico, nel suo insieme, deve invece essere trattato come un supporto di
memorizzazione alterabile. A questo si aggiunge il fatto che anche tutti gli altri dispositivi di
contorno devono essere gestiti opportunamente.

Spegnimento (shutdown)
Se il computer viene rinvenuto acceso, come si dovrebbe procedere? La domanda potrebbe
apparire banale, ma fornire una risposta corretta non è semplice. È indispensabile fare alcune
considerazioni.
 In primis è necessario capire qual è la prova che si sta cercando e il reato che si sta tentando
di provare. Si ponga, per esempio, che l’indagine verta sul soggetto della pedofilia online. La
legge condanna, con diversi livelli di severità, la detenzione e la diffusione di materiale di
questo genere. Se si rinviene acceso il computer dell’indiziato, potrebbe essere vitale
determinare che cosa stia facendo la macchina in quel momento. Nel caso fosse presente in
memoria un programma di P2P sharing sarebbe utile investigare se questo sia programmato per
condividere i file connessi con questo tipo di reato, così da dimostrare un’attività di diffusione.
In questo caso, quindi, sarebbe molto utile effettuare un dump, cioè la copia, della memoria
RAM, così da poter in seguito accertare quali programmi erano caricati e quale era il loro stato
di funzionamento.
Lo stesso ragionamento sarebbe valido nel caso di un reato informatico, quale l’accesso
abusivo a un sistema informativo. Nel caso si rinvenga un computer che sta cercando di forzare
la protezione di un sistema con un attacco di forza bruta sarebbe opportuno riuscire a
“congelare” il suo stato di funzionamento, così da poter dimostrare la flagranza di reato.
Esistono almeno un paio di società che vendono dei gruppi di continuità per analisi forense.
In pratica si tratta di UPS piuttosto capaci uniti a una serie di cavi che permettono di spostare il
computer in altro luogo (leggi “sequestrare”) pur mantenendolo acceso.
Troviamo che tale pratica sia piuttosto discutibile e rischiosa, e che il suo impiego debba
essere limitato veramente a un pugno di possibili situazioni, con tutte le precauzioni del caso. È
comunque da tenere presente che vi sono apparecchiature di questo genere e che, seppur
raramente, può essere utile riuscire a mantenere il più possibile lo stato della macchina, anche
se ritrovata accesa.
NOTA
Si vuole, a questo punto, attirare l’attenzione del lettore sul fenomeno delle distribuzioni del sistema operativo
Linux di tipo Live. Tali distribuzioni (come Knoppix, Baktrak, Helix, Ubuntu e così via) sono pensate per
funzionare unicamente in memoria RAM appoggiandosi, occasionalmente, su supporti rimovibili come flash disk
USB per la memorizzazione dei dati. La comodità di questi sistemi è stata dimostrata in più occasioni, quindi la
loro diffusione è andata via via aumentando. È implicito che tali sistemi lascino, nel migliore dei casi, ben poche
tracce sugli hard disk dei sistemi sui quali stanno girando. Nel caso si accerti che il computer sul quale si sta
operando utilizzi una “distro-live”, è vitale effettuare un dump della RAM. In caso contrario uno spegnimento
distruggerebbe invariabilmente qualunque prova si stia cercando.

Il dump della memoria RAM è un’operazione che non può essere considerata ripetibile,
quindi dovrebbe essere eseguita fornendo le necessarie garanzie di difesa previste dalla legge
(si veda al proposito il Capitolo 2). Questo perché per caricare il programma per il dump si
finisce inevitabilmente per modificare la RAM stessa.
Terminata tale operazione, o qualora non si ritenga che un dump della memoria sia
determinante nel caso trattato, si deve spegnere il computer per poter procedere alle operazioni
di sequestro. La principale preoccupazione del Digital Forensics expert deve essere quella di
preservare lo stato della prova e ridurre al minimo l’influenza del proprio operato. Tranne in
rari casi, l’unico modo di procedere consiste nel privare il computer dell’alimentazione
elettrica, evitando uno spegnimento corretto da parte del sistema operativo.
Uno shutdown regolare è sconsigliabile per i seguenti motivi.
Uno shutdown implica, in un moderno sistema operativo, svariate decine (se non centinaia)
di operazioni. Tali operazioni si traducono, nel migliore dei casi, in altrettante operazioni
di scrittura su disco che potrebbero sovrascrivere cluster vitali per l’indagine in corso.
Il danno procurato da un mancato spegnimento regolare non è minimamente paragonabile a
quello che potrebbe derivare dalla sovrascrittura delle evidenze eventualmente presenti
sull’hard disk in seguito a uno shutdown regolare.
Esiste comunque una serie di casistiche che potrebbero portare il Digital Forensics expert a
decidere di intervenire al fine di minimizzare i danni derivanti da un mancato spegnimento
regolare della macchina.
Cache in scrittura. I moderni file system utilizzano spesso algoritmi che rimandano le
operazioni di scrittura per tempi anche rilevanti. Sia i sistemi Unix sia i sistemi Windows
utilizzano file system di tipo journaled e riservano ampie porzioni di memoria come cache
per le operazioni di lettura (ma soprattutto scrittura) su disco. Lo spegnimento improvviso
potrebbe portare alla perdita totale delle scritture pendenti presenti in cache. Per ovviare a
tale inconveniente si può ricorrere a un’operazione di flush della cache. È indubbio che
un’operazione simile effettuerebbe delle modifiche sul disco fisso (sebbene molto inferiori
a quanto potrebbe fare uno shutdown regolare), ma potrebbe risultare utile nel caso si
ritenessero importanti i dati presenti in memoria. I moderni sistemi Unix (ivi compresi tutti
i Mac con OS X) utilizzano il comando sync per forzare il flush della cache. I sistemi
Windows non hanno un comando nativo per effettuare questa operazione; il Digital
Forensics expert potrebbe utilizzare il programma Sync di Sysinternals
(http://www.sysinternals.com/Utilities/Sync.html) per ottenere lo stesso risultato.
Presenza di programmi fortemente dipendenti dalla scrittura su disco. Si immagini che sul
computer sia presente un DB server come MySQL, PostgreSQL, Oracle, SQL Server,
Informix, DB/2 o altri. Tali programmi utilizzano sistemi di indicizzazione dei dati che
dipendono strettamente da una corretta sequenza di operazioni di scrittura su disco. Se i
dati fossero all’interno di un database, il Digital Forensics expert potrebbe decidere di
effettuare uno spegnimento regolare del solo servizio di database server al fine di evitare
lunghe e incerte operazioni di ricostruzione degli indici in laboratorio. Tali operazioni
potrebbero alterare le evidenze più di quanto non faccia la terminazione regolare del
servizio.
NOTA
Nel caso si effettui una terminazione regolare di un servizio di DB server è consigliabile operare
 successivamente anche un flush della cache di scrittura del file system prima di togliere energia al sistema.
Altrimenti si potrebbe finire nella situazione paradossale di aver effettuato uno shutdown regolare del servizio
ma, a causa della mancata scrittura su disco delle ultime operazioni, di ritrovarsi comunque con gli indici dei
database che necessitano una ricostruzione.

File system crittografici aperti. L’utente del computer oggetto di indagine potrebbe
utilizzare dischi virtuali cifrati come quelli forniti da Linux tramite i loop device, da OS X
con FileVault o le immagini disco cifrate in AES-128, da PGPDisk o BitLocker sotto
Windows. Nel caso il computer sia rinvenuto con uno di questi dischi collegato e operante
è vitale estrarne il contenuto prima di spegnere la macchina. Come avremo modo di
spiegare, la crittografia è uno dei peggiori nemici dell’analisi forense dei sistemi
informativi, perciò è bene cautelarsi tutte le volte che è possibile. Si immaginino i
problemi, qualora il soggetto non collaborasse e non volesse fornire la chiave necessaria
per decifrare il file system cifrato rinchiuso dallo stesso Digital Forensics expert nel
momento in cui ha spento il sistema.
Computer molto datati o con hardware malfunzionante. Per un disco fisso le operazioni di
spin-up (accensione e raggiungimento della velocità normale di rotazione) sono
meccanicamente stressanti. Alcuni sistemi datati o con hardware malfunzionante potrebbero
non riaccendersi correttamente nel caso siano spenti brutalmente, mentre potrebbero non
avere difficoltà a mantenere la corretta velocità di rotazione. Nel caso si sospetti di essere
in una situazione di questo genere è buona norma effettuare una copia del supporto, a
livello cautelativo, prima di spegnere la macchina.
Presenza di macchine virtuali accese. La diffusione delle macchine virtuali deve essere
considerata come capillare. Si deve quindi stabilire che non via sia alcuna sorta di
hypervisor di livello 1 (Citrix Xen Server, VMware ESX, Linux KVM) o di livello 2
(Oracle VirtualBox, VMware Workstation o Fusion, Parallels Desktop). In tal caso
occorrerà proteggere anche i computer virtuali presenti. Piuttosto che spegnere il computer
virtuale sarebbe il caso di usare la funzione di pausa (o blocco) presente in molti sistemi di
virtualizzazione in modo da salvare anche lo stato della RAM senza dover ricorrere a
tecniche astruse come con i PC fisici.
L’ultima operazione da fare prima di togliere l’alimentazione è quella di rilevare la data e
l’ora del computer e il loro scostamento rispetto all’ora esatta. Questo perché il computer,
specialmente se esaminato molto tempo dopo il sequestro, potrebbe perdere l’impostazione
corretta dell’orologio interno.
NOTA
Abbiate sempre con voi un sistema in grado di connettersi a un server NTP su Internet o a un sistema GPS per
rilevare l’ora esatta.

Il Digital Forensics expert procederà quindi a togliere energia al computer. Nel caso di
sistemi notebook provvederà, oltre a privare il computer dell’alimentazione, a rimuovere la
batteria onde evitare che questa funga da UPS, continuando cioè a fornire energia al dispositivo
in mancanza di un’alimentazione diretta.

Conservazione
A questo punto il computer è pronto per essere imballato correttamente. Un corretto imballo
dovrebbe:
proteggere il computer da scariche elettrostatiche: il computer dovrebbe essere avvolto in
un materiale tale da evitare i danni derivanti da cariche elettrostatiche che potrebbero
danneggiarlo;
proteggere i componenti da urti meccanici: si dovrebbe utilizzare un materiale che assorba
gli urti dovuti al trasporto preservando quindi lo stato dei componenti interni, specialmente
gli hard disk;
rilevare manomissioni: l’imballo dovrebbe essere dotato di sigilli che ne impediscano la
manomissione e permettano di verificare il corretto stato di conservazione e l’aderenza a
quanto riportato sulla catena di custodia.
Qualunque imballo fornisca tutte e tre le caratteristiche di cui sopra è da considerarsi idoneo
per la conservazione della prova.
NOTA
Un buon modo per imballare un personal computer rimane quello di utilizzare la scatola originale alla quale
applicare dei sigilli antimanomissione o in ceralacca. Nel caso non si disponga degli imballi originali, si può
avvolgere il computer in una pellicola di plastica antistatica, imballarlo usando del cartone ondulato di un certo
spessore e infine applicare i sigilli antimanomissione.

Sistemi mobili
I sistemi mobili (si parla nello specifico di smartphone e tablet) hanno subìto una drastica
trasformazione nel giro di pochi anni.
I vari nomi “storici” come Palm (crollata miseramente dopo l’ultimo tentativo di rimanere a
galla con WebOS), Nokia (in profondo rosso dopo aver sfornato centinaia di terminali fotocopia
basati su S40 o Symbian in varie salse, sta tentando il tutto e per tutto con l’allenza con
Microsoft) e BlackBerry (che sta cercando di mantenere l’hype con il sistema v. 10, dopo un
biennio disastroso) hanno ceduto il passo a due big (Apple con iOS e Google con Android) e a
un terzo incomodo (Microsoft con Windows RT e Windows Phone).
Inoltre i cellulari con sistema operativo proprietario stanno man mano lasciando il mercato
agli smartphone. Perfino la produzione cinese (interna o per l’estremo oriente) ha abbandonato
progressivamente i vari sistemi basati su nucleus per abbracciare Android.
 La prima cosa da tenere a mente riguardo tutti questi apparecchi è che gli attuali sistemi
operativi sono molto più vicini a quelli per computer che a quelli mobili che li hanno preceduti.
Gestiscono svariate applicazioni, funzionano in multitasking preemptive e permettono di gestire
servizi in background per scaricare file o informazioni o per rimanere in contatto con i vari
social network.
Questi nuovi apparecchi non hanno i problemi che affliggevano le precedenti generazioni,
come quella di perdere tutti i dati in caso di esaurimento della batteria.
Però è altresì corretto rimarcare quanto appena esposto. Lasciare che la batteria si esaurisca
comporta che tutte le applicazioni in RAM perdano il loro stato (esattamente come accade in un
PC), quindi si dovrebbero prendere le opportune precauzioni qualora tali informazioni siano
ritenute rilevanti.
I nuovi sistemi operativi a ogni modo danno il meglio di sé quando sono perennemente
collegati a Internet. È quindi normale trovare quantomeno una connessione di tipo Wi-FI, spesso
accompagnata da Bluetooth o da sistemi 3G o 4G.
Come già accennato, i carrier hanno più volte annunciato come il traffico dati sia diventato
prevalente rispetto a tutti gli altri usi di questo tipo di apparecchi (leggasi messaggi e voce). È
quindi da ritenersi della massima importanza una corretta gestione dell’apparato. Nel caso non
venga spento è assolutamente necessario che sia posto almeno in modalità aereo (cioè con tutti i
sistemi radio disattivati). Come ulteriore fattore di protezione sarebbe utile usare degli specifici
sacchetti schermati, come quelli che forniscono i principali produttori di apparecchi per
l’analisi di cellulari e smartphone, come Cellebrite o Paraben.
SUGGERIMENTO
È bene evitare di lasciare trascorrere troppo tempo tra il sequestro e l’analisi effettiva del dispositivo. Questo per
cercare di prevenire l’eventualità di una perdita di dati dovuta a una prolungata interruzione di corrente, un
inserimento non corretto del connettore nel palmare o una rottura dell’alimentatore.

SUGGERIMENTO
Sono dispositivi completamente touch. Quindi sono una ricca fonte di impronte digitali. Ergo, prima di pulire lo
schermo è meglio pensarci due volte.

Chromebook
I netbook, che per qualche tempo hanno tenuto il mercato, stanno sparendo molto
velocemente. L’idea iniziale non era certo malvagia, ma alla fine gli utenti hanno cominciato ad
associare l’idea di netbook con quella di “PC con una batteria che dura molto ma che è lento
come la fame”. A questo punto i tablet sono strumenti molto più gestibili, anche da chi è
notoriamente allergico per i computer.
Unica eccezione a questa regola rimane Google con i suoi Chromebook. Si tratta di una serie
di computer superleggeri, che montano CPU Intel o ARM, e che utilizzano ChromeOS come
sistema operativo. Nati come computer con il browser Chrome come unico programma a
schermo intero, si sono arricchiti di una semplice GUI nelle ultime versioni. Rimane però la
logica di base. I Chromebook sono da intendersi come macchine per un uso online costante
(molti modelli incorporano nativamente il 3G) e con i servizi cloud di Google.
Questo significa che, nonostante sia possibile trovare nelle ultime versioni anche dei dati
residenti sulle memoria di massa interne (rigorosamente di tipo flash/SSD), nella maggior parte
dei casi non saranno altro che dei semplici terminali wireless. Trovare un Chromebook significa
tassativamente che l’indagine dovrà comprendere anche l’esame di risorse presenti su Internet,
senza esclusioni di sorta.

Tastiera e mouse
Il problema principale per la giurisprudenza attuale è come collegare un account a una
persona fisica. Dato che username e password potrebbero non essere sufficienti per garantire
una precisa correlazione e i moderni sistemi biometrici sono, in molti casi, ingannabili con una
certa facilità, è determinante trovare dei modi per dare una risposta a questo importante quesito.
La tastiera e il mouse, pur non contenendo, di norma, dati immateriali, sono sicuramente un
veicolo per trovare numerose impronte digitali e per risalire, quantomeno, all’ultima persona
che ha usato il computer in questione.
In taluni casi sarebbe quindi d’obbligo raccogliere questi dispositivi per un successivo esame
tramite tecniche di investigazione tradizionali.

Duplicazione
Non sempre è necessario o possibile sequestrare il supporto originale delle informazioni
ricercate. Questo potrebbe accadere, per esempio, nel caso di computer che siano vitali per il
funzionamento di un’azienda, come il controllo di produzione, della gestione degli accessi o
della sorveglianza. Oppure ci si potrebbe trovare in uno dei casi precedentemente elencati nel
paragrafo riguardante il sequestro. Diventa allora cruciale operare per duplicare il dato.
La duplicazione del dato è una valida alternativa al sequestro dell’intero apparato nel caso di
reati ove non sia necessario accertare l’identità della persona fisica che ha agito: si pensi a un
reato ascritto a una persona giuridica (per esempio di carattere fiscale) o a qualcuno colto in
flagranza di reato a lavorare su un computer (caso in cui l’evidenza rende superfluo il
sequestro).
In effetti sono molte le circostanze nelle quali si potrebbe scegliere di duplicare il dato
piuttosto che rilevare l’intero apparato. A volte la copia può essere utilizzata contestualmente al
sequestro. Questo potrebbe accadere nel caso, precedentemente citato, nel quale si trovi un file
system crittografato collegato alla macchina. In tal caso si procederà alla copia del file system
prima di spegnere la macchina (e rendere così di nuovo inintelligibili le informazioni in esso
contenute) e poi si potrà effettuare il sequestro della stessa.
COSA DICE LA LEGGE
Con l’introduzione dell’articolo 254 bis c.p.p. per mezzo della legge n. 48/2008 il legislatore ha disciplinato il
sequestro di dati informatici presso fornitori di servizi informatici telematici e di telecomunicazioni prescrivendo
che lo stesso debba avvenire mediante copia di essi su adeguato supporto, con una procedura che assicuri la
conformità dei dati acquisiti a quelli originali e la loro immodificabilità (al fornitore in questi casi deve essere
ordinato di conservare e proteggere adeguatamente i dati originali). Questa modalità di sequestro, che favorisce la
continuità aziendale in settori considerati maggiormente delicati, è tuttavia espressamente prevista solo in
relazione ai sequestri di dati presso fornitori di servizi informatici, telematici e di telecomunicazioni. Negli altri casi,
quindi, dovrà essere opportunamente valutata la scelta tra il sequestro del supporto/apparato e la duplicazione del
dato sulla base delle singole circostanze del caso.

Alcune considerazioni
Anche quando si opta per la duplicazione del dato si deve operare in modo che il dato
ricavato non sia contestabile. Come nel caso del sequestro, ci sono diversi aspetti da
considerare.

Requisiti di una copia forense

La copia forense ha lo scopo di effettuare una duplicazione 1:1 del supporto incriminato.
Dall’immagine, utilizzando un supporto equivalente, deve essere possibile ricreare un supporto
perfettamente identico, a livello logico, all’originale.
Questo impone di copiare non solo i dati ma qualunque informazione sia presente sul
supporto (comprese le strutture di gestione, come master boot record, tabella delle partizioni,
metadati del file system, “spazio libero”). Da qui si evince un principio fondamentale, ovvero
che la copia deve essere sempre della stessa grandezza (in termini logici) del supporto,
indipendentemente dalla quantità di informazioni effettivamente contenute nel supporto stesso.
Il metodo migliore per effettuare tale copia è considerare qualunque supporto come un
supporto ad accesso sequenziale, esattamente come un nastro. In tal modo sarà possibile leggere
il disco bit-a-bit partendo dal primo blocco e procedendo sino all’ultimo.

Problematiche relative alla copia forense

Neanche abbiamo fatto in tempo a esultare per la legge 48/2008 che già essa mostra pesanti
limiti. In questi anni si è affermata una serie di trend tecnologici.
Grandezza dei dischi: attualmente il disco più capiente acquistabile è pari a 4 TB, con
progetti prossi venturi che annunciano dischi fino a 7 TB di capacità.
Velocità delle interfacce: per molto tempo si è rimasti ancorati a USB 2.0 e FireWire 800.
Da poco l’interfaccia eSATA è diventata abbastanza comune. È storia recentissima l’inizio
 della diffusione dell’USB 3.0 e del Thunderbolt (seppur afflitto da royalty e licenze che
sembrano già scoraggiarne l’adozione di massa). Copiare un disco da qualche TB diventa
quindi un’impresa decisamente molto lunga.
Utilizzo di NAS e storage: negli scorsi anni il prezzo di queste apparecchiature è calato
drasticamente, al punto che si trovano non solo ottimi prodotti di classe enterprise a prezzi
da SMB, ma ormai prodotti validi anche a livello consumer. Questi apparecchi, per certi
versi, sono la morte della Digital Forensics tradizionale. Se è vero infatti che una LUN
esportata da uno di questi sistemi può essere copiata come un disco, è anche vero che
esistono decine di modi per fare information hiding. La loro gestione allontana a tal punto
dall’hardware (si vedranno i dettagli in un capitolo specifico) che riuscire a effettuare
correttamente una copia può essere un’impresa. In primis perché non è assolutamente
chiaro cosa fare, ovvero se copiare i dischi uno per uno (finendo poi necessariamente per
impazzire nella ricostruzione del RAID), copiare le LUN e le share esportate via rete
(perdendosi sicuramente una buona parte dei dati), oppure se sfruttare il sistema operativo
interno per capire la gestione dei file system ed esportarli di conseguenza (quindi
scordandosi di tutte le precauzioni che si dovrebbero prendere dal punto di vista forense e
aprendosi alla possibilità che i dati vengano alterati durante il processo di copia).
Sistemi che non possono essere spenti: talvolta capita di trovare uno di questi seccanti
sistemi. A chi scrive è accaduto di dover copiare i dati di un sistema Windows 2000
Server facente parte di una centralina telefonica IP. Spegnere la centralina avrebbe
comportato un disservizio per oltre 10.000 utenti e quindi l’opzione non era assolutamente
praticabile.
Alla luce di tutto ciò appare quindi evidente che la procedura di copia bit-a-bit non è sempre
una soluzione praticabile, pur essendo sempre quella ottimale dal punto di vista dell’integrità
dei dati. Come agire quindi nel caso si trovi una situazione come quelle appena elencate?
In primis bisogna tornare al quesito posto dal cliente o dall’A.G. Se il quesito comprende
l’analisi di file e dati che possono essere stati cancellati (o si vi è un fondato sospetto di essere
di fronte a una situazione dove il recupero dati è vitale), non vi è alcun modo per sottrarsi alla
copia binaria completa.
In caso contrario potrebbe essere utile verificare i file system con uno strumento che possa
garantire la non modificabilità degli stessi (oppure, in caso di un sistema live che non può
essere spento, effettuando una serie di azioni, documentate e in numero quanto minimo
possibile) e identificare i dati e copiarli su un altro supporto calcolando nel contempo l’hash di
ogni file.
Access Data produce un ottimo tool di copia gratuito per la piattaforma Windows, FTK
Imager (ora in beta anche per Mac), che permette non solo di effettuare copie bit-a-bit ma anche
di intere gerarchie di file system (o intere share di rete nel caso si lavori su sistemi NAS). In
questo caso il software copierà la cartella e tutto il suo contenuto e poi calcolerà un hash file
per file.
Vi sono casi nei quali è l’unica modalità di agire. Ovviamente molte informazioni saranno
irrimediabilmente perse e quindi è necessario essere assolutamente convinti che non vi sia altro
modo di agire e che i dati catturati siano utili per le indagini in corso.
Non si finirà mai di ripetere che tale modo di muoversi è da considerarsi una strada
alternativa da percorrere quando non c’è un altro modo di gestire la situazione.
Altra cosa da prendere in considerazione sono i sistemi di storage block. Si stanno
diffondendo molto velocemente, spinti soprattutto da un uso sempre più pervasivo della
virtualizzazione.
Da un punto di vista dell’investigatore forense la copia delle LUN esportate da questi sistemi
non è diversa da quella di un normale disco virtualizzato da una RAID card hardware. Ciò che
invece va sottolineato è che questi sistemi dispongono di funzioni avanzate che permettono, per
esempio, di creare di snapshot sia on demand sia a intervalli regolari. Ergo, è bene controllare
sempre con quale storage si ha a che fare dato che con tali funzioni potrebbe essere possibile
avere più copie del disco esportato in lassi temporali distinti, risparmiando così grandi quantità
di tempo in caso occorra recuperare file cancellati.
Se poi se si ha a che fare con un sistema che non può essere spento, si potrebbe prendere uno
snapshot dallo storage e copiare lo stesso con tutta calma mediante il metodo della copia bit-a-
bit ed evitando di dover sacrificare parte dei dati acquisibili.

Validazione di una copia

La copia ottenuta dovrà essere necessariamente validata, ovvero confrontata con l’originale
per sincerarsi della sua perfetta corrispondenza. Per far questo si utilizzano solitamente dei
programmi di hash o message digest.
NOTA
Una funzione di hash è una funzione matematica non invertibile in grado di processare un dato arbitrariamente
grande e di calcolare, da questo, un valore di grandezza fissa. È implicito in questa definizione che qualunque
funzione di hash al mondo ha un problema evidente: essendo il numero di dati possibili infinito ed essendo, nel
contempo, il numero risultante di grandezza fissa (quindi invariabilmente un numero finito di valori), esiste la
probabilità che più dati diversi generino uno stesso valore di hash. Tale problema è noto come collisione.

Il compito della matematica e della crittoanalisi moderne è di generare funzioni di hash per le
quali è impossibile predeterminare una condizione di collisione. Nel caso in cui tale collisione
fosse predeterminabile, infatti, la validazione non avrebbe più alcun senso, dato che sarebbe
possibile variare ad hoc il dato validato e calcolare poi la condizione necessaria per generare
la collisione con il valore calcolato sul dato originale. Si avrebbe quindi un dato modificato che
però risulta identico all’originale all’applicazione della validazione.
Al momento gli algoritmi più utilizzati per la validazione delle evidenze digitali sono MD5 e
SHA-1.
Entrambi questi algoritmi sono stati oggetti negli ultimi anni di attacchi matematici atti a
creare collision ad hoc, per cui non sono più da considerare affidabili per la validazione a
meno di non essere usati assieme. A questo punto diventa molto più conveniente passare a
sistemi di hash più sofisticati e, per ora, immuni da attacchi. La precisazione “per ora” rende
evidente come, con il crescere della potenza di calcolo fornita dai moderni computer, sia
sempre più semplice riuscire a trovare dei sistemi per generare collisioni e sia sempre più
complesso riuscire a sviluppare algoritmi che possano fornire una validazione per lungo tempo.
Gli algoritmi MD5 e SHA-1 non sono comunque gli unici disponibili al momento, come
indicato nella Tabella 3.1.
Tabella 3.1 Algoritmi di hash attualmente disponibili
Algoritmo Grandezza del dato finale computato Trovati modi di generare collisioni
HAVAL 256/224/192/160/128 Sì
MD2 128 Sì
MD4 128 Sì
MD5 128 Sì
PANAMA 256 Sì
RIPEMD 128 Sì
RIPEMD-128/256 128/256 No
RIPEMD-160/320 160/320 No
SHA-0 160 Sì
SHA-1 160 Sì
SHA-256/224 256/224 No
SHA-512/384 512/384 No
Tiger(2)-192/160/128 192/160/128 No
VEST-4/8 (hash mode) 160/256 No
VEST-16/32 (hash mode) 320/512 No
WHIRLPOOL 512 No

I modi per ovviare al problema delle collisioni sono essenzialmente due.

Utilizzare algoritmi sempre più sofisticati: questo metodo non sempre può essere applicato,
dato che spesso la legge considera validi solo alcuni algoritmi, tra i quali quasi mai vi
sono i più recenti.
Validare i risultati con due diversi algoritmi: validare un dato contemporaneamente con i
due algoritmi più usati (SHA-1 e MD5) rende praticamente impossibile calcolare una
collisione che sia valida al contempo per entrambi gli hash.
Computazionalmente parlando è molto più semplice optare per la prima ipotesi. Al momento
attuale si consiglia uno degli algoritmi della famiglia genericamente definita come SHA-2,
ovvero SHA-224, SHA-256, SHA-384 o SHA-512.

Software da utilizzare
Esistono in commercio molti software che si occupano di duplicare hard disk e sistemi di
memorizzazione di massa. Sfortunatamente, la quasi totalità di questi sono pensati per facilitare
il lavoro di un amministratore di sistema, non per essere utilizzati in ambito forense. Il loro
comportamento è quindi orientato alla facilità d’uso, alla velocità di copia e a minimizzare la
quantità di informazioni duplicate. Per esempio, il comportamento usuale di Norton Ghost è
orientato alla duplicazione degli hard disk ignorando le informazioni non ritenute essenziali,
ovvero tutto lo spazio non allocato. Esaminando un’immagine di un disco duplicata con Norton
Ghost si potranno osservare frammenti di metadati che indicano la presenza di file cancellati,
ma ci si troverà nella totale impossibilità di recuperare gli stessi, dato che i settori
precedentemente occupati non sono copiati dal programma perché considerati liberi. Per questi
motivi, utilizzare uno strumento di questo genere per effettuare una copia forense è un errore
madornale.
Sul mercato sono disponibili vari prodotti per effettuare una copia bit-a-bit di un supporto.
Alcuni di questi sono dispositivi hardware in grado di operare in piena autonomia senza essere
legati all’uso di un computer. Altri sono software specializzati per questo genere di funzioni.
Unica eccezione a questa regola è il comando Unix dd. Si tratta di un tool (su cui torneremo tra
qualche pagina) di copia sequenziale utilizzato per scopi di vario genere. Il vantaggio di dd è
quello di funzionare su Unix, il cui paradigma progettuale è quello secondo cui “ogni cosa è un
file”. In ambiente Unix ogni singolo componente del computer (inclusi, per esempio, scheda
audio, porte seriali, mouse, tastiera e tutti i dispositivi di memorizzazione) è rappresentato come
un file posto nella directory /dev.
dd utilizza questa astrazione fornita dal sistema operativo per operare sui singoli dispositivi

come se fossero dei sistemi ad accesso sequenziale: la condizione ideale per una copia forense.
Un altro enorme vantaggio di questo semplice tool rispetto a qualunque sistema commerciale è
quello di essere disponibile, assieme ad alcuni interi sistemi operativi Unix-like (come
GNU/Linux, Darwin e i vari *BSD), in formato sorgente. Ciò implica che a qualunque eccezione
posta in fase di dibattimento sull’effettivo funzionamento del software è possibile rispondere sia
mostrando il codice sorgente sia ricompilandone una nuova versione per dimostrarne l’identico
funzionamento.
In linea di massima si sconsiglia, invece, l’uso di duplicatori hardware. Oltre che per il
motivo di cui sopra, è evidente che tali dispositivi sono limitati solamente al tipo di tecnologia
prevista dal duplicatore.
Si pensi ai moderni personal computer. Le connessioni predominanti ora sono SATA 3 e SAS,
ma non è infrequente imbattersi ancora in dischi di tipo ATA (o PATA) di cui esistono numerose
revisioni (Tabella 3.2).
Tabella 3.2 Versioni del bus ATA
Tecnologia Tipo di connettore
ATA-1 (noto come IDE) 40 contatti
ATA-2 (noto come EIDE) 40 contatti
ATA-3 40 contatti
ATA-4 (noto come ATA/33) 40 contatti
ATA-5 (noto come ATA/66) 40 contatti con cavo a 80 fili
ATA-6 (noto come ATA/100) 40 contatti con cavo a 80 fili
ATA-7 (noto come ATA/133) 40 contatti con cavo a 80 fili

Per il SATA esistono al momento tre versioni differenti che però usano lo stesso tipo di cavo
(Tabella 3.3).
Infine, è possibile trovare computer (specie di marca nota o server) che usano ancora la
tecnologia SCSI (Tabella 3.4).
Tabella 3.3 Versioni del bus SATA
Tecnologia Tipo di connettore
SATA 7 contatti
SATA/2 7 contatti
SATA/3 7 contatti

Tabella 3.4 Tipologie di tecnologia SCSI

Tecnologia Tipo di connettore
SCSI-1 Centronics 50 contatti
Centronics 50 contatti esterno
SCSI-2
68 contatti interno
50 poli per SE e FAST
68 poli per WIDE e FAST WIDE
SCSI-3 68 poli a coppie intrecciate per LVD e HVD
Almeno tre tipi diversi di connettori per i cavi esterni per SE e FAST e altri tre tipi per WIDE e FAST
WIDE
SCSI-4 68 poli a coppie intrecciate
SCSI-5 Cavo VHDCI a 68 contatti

Altri tipi di interfacce note sono il Fibre channel o il nuovo SAS, che ormai ha soppiantato
tutte le connessioni high end.
Gli storage moderni utilizzano perlopiù connessioni SAS sia per il collegamento dei dischi al
backplane sia per il collegamento degli shelf ai controller. Il SAS è un sistema di
interconnessione che lavora fino a una velocità massima di 6 Gbit/sec (ma sta per uscire il 12
Gbit/sec), ed è di tipo punto-punto (come il SATA), a meno che non sia utilizzato un expander
(struttura tipica all’interno dei moderni storage).
 I cavi sono molto simili al SATA con una fondamentale differenza, ovvero che se un SATA
può essere collegato a un controller SAS non è possibile il contrario per via di una specifica
serie di contatti in più che caratterizzano questo bus.
Gli attacchi tipici del SAS sono SFF-8482 (lo stesso del SATA), SFF-8484 (cavo interno ad
alta densità per collegare fino a quattro dispositivi, usato di solito per il collegamento del
controller ai backplane hot swap dei server), SFF-8470 (cavo esterno di tipo infiniband usato in
molti storage per il collegamento in modalità direct attach) e SFF-8088 (chiamato anche Mini-
SAS esterno, molto usato specialmente per il collegamento dei loop di back-end degli storage).
I dischi SAS sono tendenzialmente dischi ad alte prestazioni (15.000 giri di rotazione), bassa
capacità (massimo 900 GB al momento della stesura di questo testo) e alto costo. Sono
solitamente usati per sistemi che richiedano alte performance, specialmente in termini di IOPS.
Un nuovo tipo di disco che è stato recentemente introdotto è quello noto come NL-SAS (Near
Line SAS). Si tratta essenzialmente di un disco con meccanica SATA (bassa velocità di rotazione
– 7200 giri –, alta capacità – 4 TB, in arrivo i 7 TB –, basso costo) e l’elettronica di un SAS.
Tale tipo di disco è usato nei server e negli storage per la creazione di tier di archiviazione a
basso costo. Questi dischi sono da considerarsi a tutti gli effetti dei SAS e non possono essere
acquisiti tramite interfacce SATA.
È evidente che acquistare un duplicatore hardware per ciascuna di queste tecnologie è
quantomeno dispendioso oltre che poco pratico, a meno di non usare una valigia dedicata solo
per questi apparecchi.
Esiste un altro notevole limite all’uso di sistemi di duplicazione hardware. Essi permettono
di duplicare solo i singoli dischi. Di fronte a sistemi basati su RAID (si veda il prossimo
paragrafo), o peggio ancora in caso di dischi facenti parte di NAS o storage, ciò potrebbe
tradursi in un grave problema, dato che le informazioni sono distribuite sui vari dischi con
logiche così diverse da impedirne di fatto la ricostruzione. In tal caso sarebbe utile duplicare il
disco virtuale astratto dai controller (LUN) piuttosto che i singoli supporti, e con un duplicatore
hardware questo non è possibile.
Nella maggior parte dei casi, quindi, è buona norma avvalersi di un sistema software
abbinato a una workstation forense dotata di controller per le più comuni tecnologie (SATA e
SAS al momento).

Il problema dei RAID (vale anche per gli storage)

Le memorie di massa costano sempre meno e contengono sempre più informazioni. Purtroppo
con il calo dei costi si è potuto notare anche un decrescere della qualità costruttiva dei supporti.
La possibilità che un hard disk si guasti, o anche solamente presenti comportamenti anomali
sullo strato magnetico, non è più così remota. È implicito che quanto maggiore sarà la capacità
di memorizzazione del supporto, tanto più grave sarà il problema in caso di una sua rottura.
Per ovviare a tale problema, da anni sono disponibili tecnologie che permettono di distribuire
i dati su diversi supporti al fine di migliorare la velocità di accesso, la sicurezza dei dati o
entrambe le cose.
La più diffusa di queste tecnologie prende il nome di RAID (Redundant Array of Inexpensive
Disks). La tecnologia RAID si estende su più livelli e permette una notevole varietà di
configurazioni. Queste tecnologie possono essere implementate in hardware oppure in software.
Nel primo caso il computer avrà a bordo un sottosistema hardware che si occuperà di
mascherare la reale struttura fisica dei supporti di memorizzazione esportando verso il sistema
operativo un disco logico rappresentante il tipo di RAID scelto dall’utente. Il sistema operativo,
in questo caso, non avrà quindi visione dei singoli dischi presenti ma solo dell’astrazione creata
dal controller. Un sistema RAID hardware ha inoltre il vantaggio di gestire in autonomia sia le
operazioni di I/O sia il calcolo della parità (ove presente), scaricando quindi la CPU da queste
attività.
I RAID software sono invece gestiti direttamente dal sistema operativo. In tal caso il sistema
avrà piena visione di ogni singolo disco collegato ai controller e provvederà a creare un nuovo
disco virtuale che rappresenterà il livello di RAID scelto. Se per un verso tale soluzione carica
il sistema e la CPU di un ulteriore compito, per un altro ha il vantaggio di non richiedere
hardware dedicato (Tabella 3.5).
Oltre a questi livelli di RAID “canonici” ne esistono altri. Alcuni sono proprietari, ovvero
sono definiti da alcuni specifici produttori per le loro piattaforme (per esempio il RAID DP di
NetApp, il RAID 7 di Storage Computer Corporation o il RAID S di EMC), altri sono la somma
di più livelli di RAID (Tabella 3.6).
Tutto questo illustra la complessità della gestione dei sistemi di memorizzazione dei sistemi
moderni. Questo non è riservato solamente al mondo enterprise. È prassi comune trovare
desktop personali che implementano qualche forma di RAID.
Tabella 3.5 Le più comuni configurazioni di RAID
Livello
di Nome Descrizione
RAID
Le informazioni sono distribuite, a blocchi, su tutti i supporti dell’array senza alcun sistema di
0 Stripe gestione della ridondanza delle informazioni. Si aumentano le performance ma la rottura di un
disco provoca la perdita totale delle informazioni contenute sull’intero array.
Le informazioni sono scritte su tutti i dischi facenti parte dell’array. Ogni disco conterrà quindi
1 Mirror una copia completa di tutte le informazioni. Tutti i membri dell’array, tranne uno, possono
fallire senza che ciò si traduca in una perdita di informazioni.
Funziona come il RAID 0, memorizzando però le informazioni a livello di bit e non di blocco. È
Stripe a perciò necessario un numero di dischi pari alla massima grandezza gestibile dai registri della
2 livello di CPU (quindi 32 per un 32 bit) più un certo numero di dischi per la correzione di errore (7 nel
bit caso di un sistema a 32 bit usando l’algoritmo di Hamming). Permette di raggiungere alte
velocità. Non sono note implementazioni di tale livello.
 Stripe a
livello di È un sistema di stripe (come i livelli 0 e 2). Lavorando a livello di byte necessita un numero di
3 byte con dischi decisamente inferiore al livello 2. La correzione d’errore è garantita da un disco
disco di dedicato al controllo di parità. Poco usato.
parità
Stripe a
livello di
blocco
4 Come il livello 3, solo con una distribuzione a livello di blocco (512 byte).
con
disco di
parità
Stripe a
livello di È il sistema di stripe attualmente più diffuso. Il dato viene distribuito su tutti i dischi
blocco appartenenti allo stripe. Contemporaneamente viene calcolata la parità che, al contrario del
5
con RAID 4, non è scritta su un disco dedicato ma è distribuita anch’essa su tutti i dischi.
parità Permette di supplire alla perdita di un disco dell’array.
distribuita
Stripe a
livello di
Non è uno dei RAID level originali ma una recente estensione del RAID 5. Rispetto a
blocco
6 quest’ultimo utilizza un blocco di parità aggiuntivo che gli permette di supplire alla perdita di
con due
due dischi nell’array.
blocchi di
parità

Tabella 3.6 Configurazioni RAID non comuni

Livello di
Nome Descrizione
RAID
Mirror di
0+1 Due RAID 0 di uguali dimensioni sono utilizzati per creare un RAID 1.
stripe
Stripe di Simile al precedente, utilizza i livelli di RAID in maniera inversa, ovvero effettuando uno
10
mirror stripe di due o più mirror.
Stripe di Il funzionamento è simile a quello del RAID 10, con la differenza che i singoli
50
RAID 5 componenti sono array RAID di livello 5.
Stripe di
100 Come il 50, solo che i membri dell’array sono RAID di livello 10.
RAID 10

Come dovrebbe agire il Digital Forensics expert in questi casi? Si potrebbe ritenere che la
risposta più corretta sia quella di acquisire ogni singolo disco facente parte dell’array così da
avere una copia al più basso livello possibile.
Se ciò è corretto in generale, purtroppo non tiene conto di alcuni fattori determinanti. Il
primo, e più importante, di questi è la complessità della gestione dei sistemi RAID a livello di
controller. In pratica, se il funzionamento di un sistema RAID è codificato a livello teorico, ogni
produttore di schede RAID compie delle scelte in autonomia mirate all’ottimizzazione del
funzionamento del sistema. È quindi praticamente impossibile riuscire a spostare dei dischi
facenti parte di un RAID 5 da una scheda RAID di un produttore a quella di un altro e sperare di
rivedere il proprio disco virtualizzato dal RAID. Talvolta questa operazione è impossibile
anche tra modelli diversi di schede dello stesso produttore.
Per la cronaca, alcuni software commerciali (come X-Ways Forensics) permettono di
ricostruire RAID creati da alcune delle schede più note (HP e IBM sopra tutte). È utile nel caso
che l’acquisizione sia stata fatta da terzi copiando i dischi fisici.
Il problema per il Digital Forensics expert appare quindi evidente. A meno di non possedere
lo stesso controller RAID in laboratorio (con, per sicurezza, la stessa release di firmware), egli
sarà costretto ad accollarsi una ricostruzione dell’array tramite software con tempi che possono
dilatarsi notevolmente e con il rischio di non riuscire a estrarre i dati.
Il problema riguardante i RAID è ulteriormente esasperato sugli storage di classe enterprise.
In questi casi decine, se non centinaia di dischi possono essere configurati non solo con sistemi
RAID di livello differente, ma poi essere riuniti e gestiti tramire sistemi partizionamento e file
system proprietari da cui ricavare le singole LUN. In questi casi è palese che ogni cosa debba
passare dal RAID controller dello storage. Non c’è modo di aggirare la logica interna perché
mascherata da svariati strati hardware e software. In questo caso si può solo agire copiando le
singole LUN oppure entrando nell’interfaccia di management per vedere se vi siano repliche
delle LUN stesse o snapshot.
In caso di RAID software la questione diventa più spinosa. Se, infatti, in presenza di un RAID
hardware, il sistema operativo non ha visibilità dei dischi appartenenti all’array, nel caso di un
RAID software il sistema è in grado di accedere anche a questo livello. Un abile sistemista
potrebbe quindi nascondere efficacemente dei dati in zone specifiche dei singoli dischi non
utilizzate per la generazione del RAID. È allora d’obbligo effettuare una copia dei singoli dischi
non potendo predeterminare, a priori, che non vi siano dati al di fuori del RAID.
Si noti che se il RAID software nei PC sembra aver ceduto il passo a RAID hardware (il cui
costo è calato drasticamente), nei sistemi NAS di classe SOHO o SMB essi sono molto diffusi.
Spesso sono ottenuti con un misto di tecnologie open source (tipo il modulo RAID di Linux)
abbinato a sistemi di partizionamento/file system proprietari.
Da un lato potrebbe quindi diventare impossibile ricostruire il file system partendo dalla
copia dei singoli dischi, e dall’altra, dovendo mediare attraverso il firmware della macchina, è
necessario avere cieca fiducia del produttore dell’hardware.
NOTA
Anche se la maggior parte dei NAS SOHO o SMB dispone di un’interfaccia web per la loro configurazione,
spesso è disponibile (o è possibile attivare) una connessione SSH attraverso la quale si arriva al sistema
operativo sottostante (spesso Linux o un *BSD). In tal caso, disponendo dei diritti di root, sarà possibile copiare i
dischi virtualizzati dall’ASICS usando direttamente il sistema operativo del NAS. Si ricorda che questi dispositivi
non permettono il boot da USB o da CD e quindi una qualunque Live è inutile (oltre a questo molti dispongono di
una CPU ARM e quindi non compatibile Intel).

Il write blocker
Molti sistemi operativi moderni sono orientati all’uso da parte di un utente medio, non di un
esperto di tecnologie informatiche. Per facilitare la vita agli utenti, tali sistemi operativi
incorporano una serie di automatismi per le operazioni più comuni, nonché veri e propri wizard
che si incaricano di svolgere le funzioni usuali più complesse.
Un esempio di questi automatismi è quanto svolge Windows quando al computer viene
collegato un nuovo supporto. Il sistema operativo effettua una “marcatura” del supporto per
poterlo riconoscere la prossima volta che tale supporto sarà ricollegato. Tale “marcatura” si
traduce in una serie di operazioni di scrittura sul supporto collegato. Si immagini che cosa
questo potrebbe significare nel caso si collegasse un drive contenente delle evidenze digitali:
Windows lo marcherebbe invariabilmente modificandolo, invalidando di fatto la prova.
È bene tenere presente che tale comportamento è ora adottato dalla stragrande maggioranza
dei sistemi orientati all’uso come desktop personali o aziendali. L’assioma “non uso Windows
quindi non corro pericoli” non è assolutamente vero. OS X, così come la maggioranza delle
distribuzioni Linux desktop, utilizzano daemon di automounting (o sfruttando direttamente dbus)
per effettuare operazioni analoghe anche se decisamente meno invasive.
Per ovviare a tale comportamento i Digital Forensics expert che scelgono Windows come
sistema di lavoro utilizzano degli apparecchi specifici noti come blocker. Questi apparecchi
(hardware) altro non fanno che impedire qualunque scrittura sul disco collegato evitando, di
fatto, che Windows vada a pasticciare sul supporto. Vale purtroppo lo stesso discorso dei
duplicatori hardware, ovvero si deve avere un blocker diverso per ogni tipo di tecnologia
utilizzata dal supporto di memorizzazione. Tradotto in termini pratici, un’altra valigia di
ferraglia.
Va osservato che se un duplicatore hardware, di qualunque tipo, è egregiamente sostituibile
con appositi programmi e una macchina dedicata allo scopo, lo stesso non si può dire di un
write blocker. I motivi sono riassumibili come segue.
È standard. Con il diffondersi della cultura informatica nelle aule di tribunale si sente
spesso chiedere se, in fase di acquisizione si siano usati strumenti atti a non modificare la
prova. Talvolta usare un blocker può essere del tutto ridondante ma permette di dare una
risposta affermativa a quella che, forse, sta diventando l’obiezione più popolare nei casi
che coinvolgono l’uso di prove informatiche.
Permette più flessibilità e fa risparmiare tempo. Spesso capita di esaminare copie di
lavoro con macchine Windows, per trasformarle in macchine virtuali o per analizzarle con
appositi software. Ciò accade sovente anche in un laboratorio orientato all’uso di prodotti
open source. In tutti questi casi, usare un blocker permette di evitare di continuare a creare
nuove copie dopo che quelle in uso sono state modificate.
Per evitare questo inconveniente, alcune software house che sviluppano programmi di
duplicazione e analisi sulla piattaforma Windows (come Guidance Software, produttrice di
Encase Forensics) hanno sviluppato dei programmi detti blocker software. In pratica, essi sono
composti da una GUI di gestione e da moduli che girano a Ring 0 e che intercettano le
operazioni di scrittura verso i dispositivi scelti.
La situazione è piuttosto paradossale, dato che esistono diverse distribuzioni di Linux
orientate all’utilizzo da parte di Digital Forensics expert che non necessitano di alcun blocker
software. Il tutto a costo zero e nel pratico formato di un live CD.
Che fare, quindi? Anche in questo caso è bene essere flessibili. L’uso di un write blocker è
sicuramente utile non solo per evitare che il sistema operativo alteri le prove ma, soprattutto,
per evitare errori umani (si pensi banalmente a scambiare if e of in un dd). Detto questo, è
preferibile non sviluppare una dipendenza da questo strumento, ovvero usarlo quando possibile
ma comportarsi sempre come se non fosse presente. Si eviterà di prendere le cose con eccessiva
leggerezza sapendo di avere una sorta di “rete di protezione”, finendo con il non sapere come
comportarsi nel momento in cui non lo si potesse usare.
Torniamo di nuovo sul discorso NAS e storage. In tutti questi casi un write blocker è del tutto
inutile in quanto, come già più volte accennato, è una follia effettuare un’acquisizione a livello
del singolo disco.
Prendiamo per esempio il NAS Synology DS413 che utilizzo in casa assieme ai due nodi
Proxmox VE. Pur essendo un banale NAS a 4 dischi, usa un sistema RAID proprietario, e quindi
i dati al suo interno possono essere copiati solo attraverso il suo sistema operativo (è uno Unix,
per cui si possono prendere le precauzioni del caso per evitare di alterare le informazioni al suo
interno). Lo stesso dicasi nel caso di un datacenter che sfrutta la virtualizzazione. Recentemente
ho avuto modo di visitare un moderno datacenter della sezione EMEA di una multinazionale
americana. Si tratta di un sistema con 25 server fisici connessi a uno storage EMC2. Tali server
virtualizzano oltre 200 server e 400 VDI. Inutile dire che in un caso del genere un write blocker
non ha alcun senso. Vi sono troppi livelli di astrazione tra il disco fisico e le singole macchine
virtuali che vi girano sopra.
Il write blocker, insomma, è uno strumento utile per il forensics expert a patto che ne faccia
un uso sensato e non lo prenda come “un fattore fondamentale”. Un buon forensics expert deve
sapere non solo fronteggiare quelle situazioni in cui non è possibile usare il write blocker, ma
anche essere in grado di giustificare la cosa in dibattimento, magari di fronte a un avvocato che
gli rivolga un’obiezione in merito, sensata o meno che sia.
Quale write blocker acquistare, dunque? Rispondendo sinceramente si può solo dire “il più
economico che si trova sul mercato e che disponga delle caratteristiche volute”. Vi sono write
blocker dal costo di svariate centinaia di euro. Il prezzo è assolutamente sproporzionato. Si
pensi che un adattatore SATA/IDE USB 3.0 costa poche decine di euro; se la connessione è di
tipo FireWire, il prezzo rimane abbondantemente sotto i 100 euro. Ora, per bloccare le scritture
non può essere richiesta chissà quale logica di controllo. Si tratta di pochi componenti
elettronici il cui costo non dovrebbe influenzare il prezzo finale dell’adattatore se non per una
parte marginale. Tutto il resto sono chiacchiere da marketing.
Quello che molte ditte si fanno pagare sono le procedure di certificazione del funzionamento
del write blocker. Se avete denaro e volete risparmiare tempo può valere la pena acquisitare un
prodotto di marca con tanto di test di funzionamento già effettuati presso laboratori indipendenti.
In caso contrario, facendo qualche accurata ricerca su Internet si riescono a trovare blocker a
costi inferiori ai 200 euro che nulla hanno da invidiare alle controparti marcate con nomi
altisonanti. In tal caso sarà poi buona norma crearsi una procedurea di verifica ed effettuare
delle prove in laboratorio al fine di convalidare il funzionamento dell’apparecchio. Si scelga
perciò con oculatezza.

dd & Linux
Il tool dd è probabilmente uno dei programmi più vecchi disponibili su piattaforma Unix. La
stessa origine del nome è incerta. Se infatti molti sysadmin Unix ritengono “dd” l’abbreviazione
di disk dumper, in realtà il nome deriva dalla frase “dataset definition”. dd è infatti il porting (lo
si capisce dalla sintassi assolutamente non Unix) di un comando del JCL del sistema OS/360.
Come il suo antenato in OS/360, dd si occupa di copiare qualunque supporto utilizzando un
metodo a blocchi. Tale metodo è solitamente utilizzato dai sistemisti Unix per effettuare copie di
vari tipi di supporti, siano essi ad accesso casuale o sequenziale.
dd è quindi uno strumento ideale per un Digital Forensics expert. Sfrutta l’astrazione fornita da

Unix per riuscire a vedere qualunque dispositivo come fosse un nastro e ne copia ogni singolo
byte su un altro file. dd; al contrario di tool pensati per effettuare copie di backup, non esegue
alcun tipo di ottimizzazione né compressione nella gestione delle informazioni.
Necessariamente, tale comportamento si traduce in tempi di copia più elevati, ma anche in
un’assoluta fedeltà tra la copia e l’originale.

Utilizzo di dd
La sintassi di dd differisce da quella degli altri comandi Unix. Come già detto, in realtà è un
porting di un comando di un diverso sistema operativo. La sintassi base è:
dd [operandi]

I principali operandi sono i seguenti.

bs=n determina la grandezza del blocco che viene copiato dal programma. La grandezza
minima è di 512 byte. Il valore ideale per raggiungere la massima velocità di copia non è
facilmente determinabile. Si è notato che con i moderni hard disk un valore superiore a
1024 byte incrementa la velocità di copia di diversi ordini di grandezza rispetto al blocco
minimo. Si ricorda che nel momento in cui dd non riuscisse a copiare un blocco lo
sostituirebbe con un blocco di zeri binari. Quindi è meglio non usare valori troppo elevati
 in modo da evitare, in caso di un errore di lettura, di sacrificare un numero elevato di
blocchi da 512 byte.
count=n copia solo un numero n di blocchi.

if= specifica il file di input (sorgente) da utilizzare per la copia. In piena logica Unix,

questo può essere un file reale o un device presente nella directory /dev/.
of= specifica il file di output (destinazione). Valgono le stesse considerazioni fatte per

l’operando if=.
skip=n salta un numero n di blocchi dall’inizio del file.

conv=valore,[valore,] permette di specificare dei filtri di conversione durante la copia.

Tra i possibili valori di conv=valore,[valore,], i più usati sono due:

noerror, che altera il tradizionale comportamento di dd, ovvero quello di fermarsi nel caso si
incontri un errore. Specificando tale parametro viene prodotto un log con una riga per ogni
errore. Il comportamento di tale parametro dipende dal valore sync;
sync, se utilizzato assieme al parametro noerror, ne altera il comportamento. Se non è

presente, in caso di errore il blocco che contiene tale errore non sarà inserito nel file di
output. Nel caso sia specificato il parametro sync nel file di output sarà inserito un blocco
contenente byte NUL.

Uso di dd in ambito forense

Il Digital Forensics expert può utilizzare dd per effettuare una copia che sia del tutto identica
al dispositivo originario. Ove questo non sia possibile, il suo compito è di riuscire ad
avvicinarsi al massimo a questo risultato finale. Si fissa quindi una serie di punti cardine.
La copia sarà effettuata utilizzando il file che rappresenta il device nella sua interezza. Si
prenda, per esempio, un disco con due partizioni primarie, identificato da Unix come /dev/hda
con le partizioni /dev/hda1 e /dev/hda2. La copia dovrà sempre essere effettuata sull’intero
dispositivo, ovvero, in questo caso, /dev/hda. Diversamente, non esisterà alcuna garanzia di non
aver tralasciato delle informazioni vitali, scritte per esempio nello spazio allocato per l’MBR e
la tabella delle partizioni, tra le partizioni o in coda al disco stesso.
Non si deve utilizzare alcun sistema di controllo degli errori. Il comportamento comune di dd
è di bloccarsi qualora si presenti un errore di lettura o di scrittura. Questo è un aiuto per il
Digital Forensics expert in quanto, se da un lato è sicuramente seccante visto che costringe il
tecnico a ricominciare daccapo l’operazione, dall’altro evita di sprecare del tempo nel portare
a termine l’intera operazione per poi trovarsi con i due hash non coincidenti. Capita purtroppo
relativamente spesso di trovare supporti (compresi degli hard disk) che presentano dei problemi
di lettura o scrittura. In una situazione di questo genere è possibile agire in due modi diversi:
 si utilizza una variante di dd in grado di lavorare su supporti danneggiati dd_rescue
(http://www.garloff.de/kurt/linux/ddrescue) è una di queste. Al contrario di dd, dd_rescue non salta
semplicemente il blocco danneggiato ma tenta di leggerlo ricorrendo a tecniche diverse.
Con dd_rescue è possibile, per esempio, leggere il supporto partendo dalla fine oppure
leggerlo variando dinamicamente la grandezza dei blocchi. In molti casi copie che
falliscono miseramente con dd vanno a buon fine utilizzando dd_rescue;
si usa dd con le opzioni conv=noerror,sync. In questo caso dd produrrà una riga di log per ogni
errore incontrato ed effettuerà un padding di NUL byte per i blocchi che non è riuscito a
leggere.
È il caso di ricordare che se si dimentica l’opzione sync, dd produrrà ancora una riga di log
per ogni errore incontrato ma ometterà i blocchi illeggibili dall’output finale. In tal modo la
geometria del disco subirà un’alterazione e tutti i riferimenti ai cluster posti nelle tabelle di
indice punteranno a dei blocchi errati.
Una delle migliori varianti di dd per l’uso in ambito forense è sicuramente dcfldd.
In primo luogo permette di generare un log delle operazioni, utile nel caso si presentino errori
nella copia del dispositivo. Si attiva con l’opzione errorlog= seguita dal percorso del file dove si
vuole riversare il log.
Assolutamente indispensabile è la funzione per il calcolo dell’hash. Si attiva con il parametro
hash= seguito dal tipo di hash che si vuole calcolare (si consiglia di usare uno degli hash della

famiglia SHA2 o più avanzato). È possibile, in un solo passaggio, calcolare anche più hash
diversi, semplicemente specificandone più di uno separandoli con una virgola (per esempio
hash=md5,sha1). L’hash di norma viene visualizzato a video. È possibile scriverlo anche in un log

con l’opzione hashlog= seguita dal percorso del file.

Quest’ultima funzione già da sola sarebbe più che sufficiente per consigliare sempre l’uso di
dcfldd al posto del più classico dd; vista la grandezza dei dischi moderni, infatti, saltare un

passaggio per il calcolo dell’hash significa risparmiare molto tempo prezioso.

Usi alternativi di dd
L’esperienza suggerisce alcuni usi “creativi” di dd che possono essere estremamente utili sul
campo (quanto descritto nei paragrafi che seguono è adattabile anche a dcfldd).

Divisione in blocchi dell’immagine

Anche se il suo uso va sparendo, è possibile che il Digital Forensics expert debba salvare i
dati copiati su supporti rimovibili o su file system che accettino file di grandezza relativamente
modesta (vedi FAT). Per ovviare a tale inconveniente è possibile utilizzare le opzioni di dd skip e
 .
count

Si supponga di voler copiare un disco (/dev/hda) da 10 GB. I comandi da utilizzare sarebbero i

seguenti.
dd if=/dev/hda of=hda_p1.dd bs=2048 count=1000000: si dice a dd di copiare il disco /dev/hda e di
riversare l’immagine nel file hda_p1.dd. Inoltre gli si dice di usare blocchi da 2048 byte e di
copiarne 1 000 000, arrivando quindi alla grandezza massima di 2 GB.
dd if=/dev/hda of=hda_p2.dd bs=2048 count=1000000 skip=1000000: la differenza rispetto al comando

precedente è che si ordina al programma di cominciare la copia saltando i primi 2 GB del

file sorgente.
dd if=/dev/hda of=hda_p3.dd bs=2048 count=1000000 skip=2000000: questo comando e quelli che

seguono continuano la copia saltando rispettivamente i secondi, i terzi e i quarti 2 GB del

file sorgente.
dd if=/dev/hda of=hda_p4.dd bs=2048 count=1000000 skip=3000000.

dd if=/dev/hda of=hda_p5.dd bs=2048 count=1000000 skip=4000000.

dd (e varianti) e netcat per copia via rete

Il programma netcat è considerato da anni l’equivalente di un coltellino svizzero per le
connessioni di rete. È utilizzato in svariati ambiti, dalle semplici connessioni a server e daemon
al pen testing.
netcat è anche molto usato per effettuare trasferimenti di file via rete, visto il bassissimo

overhead. Quest’ultima caratteristica lo rende uno strumento di indubbio valore per il Digital
Forensics expert, sempre attento a usare l’hardware al limite per velocizzare il proprio lavoro.
netcat può quindi essere usato assieme a dd per effettuare velocemente delle copie di hard disk

attraverso una connessione LAN. Di seguito sono riportati i comandi necessari, commentati.
Lato server (ovvero la macchina dove si andrà a registrare l’immagine, che ha, per
esempio, l’indirizzo IP 192.168.1.1): netcat -l -p 5959 > nome_del_file_di_copia_dell_hard_disk. In
questo modo il programma si mette in ascolto (-l) su una specifica porta (-p 5959) e gli si
dice di copiare quanto ricevuto nel path che segue il segno di maggiore (>).
Lato client (la macchina che si desidera copiare bit-a-bit): dd if=/dev/hda bs=2048 | netcat
192.168.1.1 5959. La macchina copierà il disco puntato dal device /dev/hda e, attraverso il

carattere pipe (|), spedirà i dati a netcat, che provvederà a mandarli alla sua controparte in
ascolto sul server.
NOTA
Nel caso si debba sospendere temporaneamente l’operazione di copia (per esempio perché lo spazio libero
sulla macchina server sta diminuendo), è possibile farlo premendo i tasti Ctrl+Z sul client. In questo modo il
 processo client (ovvero quello che spedisce i dati) viene temporaneamente “congelato”. Il netcat lato server
starà in attesa di ulteriori dati senza terminare. Sarà quindi possibile risolvere il problema (per esempio liberare
spazio sul disco del server) e poi continuare la copia digitando, sul client, il comando fg.

NOTA
Dovendo copiare dei dati attraverso un network ritenuto non affidabile, è possibile utilizzare un sostituto di
netcat che sia dotato delle funzioni di strong authentication e che permetta di crittografare i dati in transito. Tale
programma prende il nome di sbd (http://tigerteam.se/dl/sbd).

Ripresa di una copia interrotta

Esistono varie circostanze nelle quali è possibile che la copia venga interrotta (l’agente che
si appoggia sul tasto di reset del server, quello che inciampa nel cavo di collegamento al server,
un calo di tensione e così via). In questi casi si può riprendere la copia da dove è stata
interrotta.
dd invia i dati a blocchi, perciò, in caso di interruzione della copia, il file presente sul server

conterrà sempre una quantità di byte multipla del valore specificato nell’operando bs=.
Alla luce di questo fatto, è possibile riprendere una copia usando opportunamente l’operando
skip. Ecco la prassi da seguire.

Lato server (ovvero la macchina dove si andrà a registrare l’immagine, che ha, per
esempio, l’indirizzo IP 192.168.1.1). Con un ls-l si vede la grandezza del file di immagine
registrato sull’hard disk. Si divide il risultato per il valore di bs specificato nel client (in
questo caso 2048). Si digita il comando netcat -l -p 5959 >>
[nome_del_file_di_copia_dell_hard_disk]. Si noti il doppio segno di maggiore (>>) che permette di

accodare quanto ricevuto al file già presente sull’hard disk.

Lato client (la macchina che si desidera copiare bit-a-bit). Il comando da digitare è dd
if=/dev/hda bs=2048 skip=[numero_di_blocchi_ottenuto_dalla_divisione_della_grandezza_del

. La macchina copierà quindi il file /dev/hda

file_con_il_valore_di_bs] | netcat 192.168.1.1 5959

saltando quanto già copiato prima dell’interruzione e, attraverso il pipe, spedirà i dati a
netcat, che provvederà a mandarli alla sua controparte, in ascolto sul server, la quale li

accoderà a quanto già inviato.

Copie di sistemi complessi

In questa categoria rientrano tutti quei sistemi che non possono essere ricondotti al normale
paradigma computer + memorie di massa. Si tratta di sistemi cluster, grid e sistemi virtuali,
sistemi che non possono essere spenti, come centrali telefoniche o sistemi SCADA.
In tutti questi casi spesso non si potrà agire utilizzando un Live CD o spegnendo la macchina,
quindi sarà impossibile bloccare l’accesso ai dischi per il tempo necessario per riuscire a
effettuare una copia forense delle memorie di massa.
 In tal caso ci si dovrà adattare alla situazione tenendo bene presente un punto fondamentale,
che tutte le operazioni effettuate introdurranno necessariamente una modifica nello stato del
sistema che si sta esaminando.
Inoltre si dovrà effettuare in situ una cernita delle informazioni necessarie tralasciando quindi
parte del contenuto (per esempio il free space del disco e con questo la possibilità di recuperare
i file cancellati).
Sarà quindi responsabilità di chi conduce l’indagine:
documentare in maniera esatta e precisa ogni singolo passo effettuato, possibilmente con
fotografie e filmati;
effettuare una copia delle informazioni minimizzando il numero di operazioni da compiere,
specificando che tipo di alterazioni si stanno compiendo sul sistema (tipicamente, copiando
i dati con il sistema operativo “live” le date di ultimo accesso di ogni file saranno
modificate) e mettendo in atto tutte le opportune azioni per cristallizzare i dati raccolti
(leggi calcolo di hash e/o firma digitale delle evidenze);
capire se il proprio mandato è legalmente compatibile con il tipo di operazione che si sta
effettuando o se è necessario richiedere ulteriori autorizzazioni.
NOTA
Tale lavoro non può dunque essere effettuato con una nomina ex art. 359 c.p.p. Se ci si dovesse trovare in
questa situazione, l’unica soluzione sarebbe quella di richiedere al P.M. l’autorizzazione a effettuare un
accertamento tecnico non ripetibile (ex art. 360 c.p.p.).

Nonostante non faccia riferimento in maniera specifica alla normativa italiana, può essere
molto utile applicare alla lettera la specifica ISO 27037 che standardizza la raccolta delle fonti
di prova digitali e specifica una metodologia corretta per il loro trattamento.
La procedura in se stessa presenta qualche rilevante lacuna, soprattutto trattando di sistemi
che non siano PC o server tradizionali, ma fissa alcuni punti chiave che è sempre bene tenere a
mente.
Senza riscrivere qui l’intero documento si vogliono evidenziare alcuni dei punti fondamentali.

Mettere in sicurezza la scena

Non alterare lo stato di alcun dispositivo. Le macchine accese vanno lasciate accese,
quelle spente, spente.
Ridurre al minimo il numero di persone presenti in modo da non contaminare nulla. In
particolare prestare attenzione qualora siano presenti i possessori dei sistemi digitali che
si stanno esaminando, ed evitare che si possano avvicinare a questi ultimi, dato che
potrebbero alterarli o distruggerli (il documento ISO invita anche a controllare la presenza
di armi o corpi contundenti; senza fare inutili allarmismi il suggerimento non è da
 considerarsi privo di fondamento). Tutti i presenti dovrebbero essere correttamente
identificati e segnalati nel report, ivi compresi tutti coloro che per qualche motivo sono
coinvolti nelle operazioni.
Usare sistemi audio/video per documentare lo stato della scena.
Controllare se vi sono fogli con PIN e password annotate.

Identificare le fonti di prova digitali presenti

Effettuare un inventario completo dei sistemi presenti, comprensivo di descrizione e
numero di serie dei singoli apparati.
Documentare lo stato dei sistemi accessi usando sistemi audio/video
Verificare il tipo di sistemi presenti, controllando con particolare cura se vi siano: sistemi
critici che non possono essere spenti; fonti di prova di dimensioni troppo ingombranti per
essere asportate; fonti di prova digitale di dimensioni logiche troppo elevate per essere
copiate; sistemi il cui spegnimento possa essere pericoloso per le persone (sistemi di
supporto vitale, controllo semaforico, controllo ascensori/sensori/allarmi e così via).

Preparare una checklist per ogni singolo sistema

presente
Definire una procedura di acquisizione basata su:
tipo di apparecchio;
possibilità di asportarlo;
stato dell’apparecchio (per esempio, quelli accesi potrebbero dover essere isolati oppure
dovrebbe essere effettuato il dump della RAM o verificate le connessioni di rete in
essere);
tipo di connessioni (un telefono 3G potrebbe essere modificato da remoto).

Definire una lista di priorità

Stabilire quali sistemi debbano essere acquisiti per primi in base a:
stato della macchine: quelli accesi dovrebbero essere gestiti per primi;
rischio di modificabilità: più è alta la possibilità che questi possano essere modificati
prima dovrebbero essere correttamente gestiti;
tipo di apparecchio: qui la procedura ISO definisce una scala gerarchica (la scala viene
riportata, ma per chi scrive l’ordine indicato è estremamente opinabile; in particolare
 lasciare per ultimi i telefoni non sembra assolutamente corretto visti i rischi connessi ai
punti sopra descritti). I tipi di apparecchio possono essere: computer; external storage
media; smart card, dongle, scanner biometrici; segreterie telefoniche; macchine
fotografiche digitali; dispositivi handheld (PDA, organizer); sistemi dotati di scheda di
rete; router, hub, switch; pager; stampanti; scanner; telefoni.

NOTA
La lista appare piuttosto datata. Inoltre è bene ricordare che acquisire tutto in maniera indiscriminata potrebbe
essere controproducente. Come specifica anche la procedura, ciò che dovrebbe guidare lo specialista
dovrebbe essere soprattutto il requisito iniziale, inteso come il crimine su cui si sta investigando o la richiesta
dell’autorità giudiziaria o del mandante dell’indagine. Per esempio, in un caso di indagine sullo scambio di
materiale pedopornografico in ambito aziendale, l’acquisizione dei server SAP avrebbe ben poco senso.

La procedura entra poi nel dettaglio su come acquisire le singole tipologie di apparecchi. Si
nota immediatamente che se per i computer la procedura è perfettamente consolidata, per
apparecchi e sistemi complessi le linee guida diventano più fumose.
Sembra quindi poco utile riportare in questa sede le singole parti. Piuttosto si rimanda ai
capitoli specifici del libro sugli ambiti specifici per trovare delle linee guida ragionate.
 Capitolo 4

Intercettazione del dato

“... Sì, sto lavorando sul mio PC. O meglio, questo è un semplice Chromebook. In realtà sto tenendo tutti i dati in un
datacenter. E quando non bastano le Google Apps, beh, c’è sempre la VDI raggiungibile via Citrix direttamente da dentro il
browser. Qui non c’è nulla di nulla...”

Premessa
Fino a tempo fa la Network Forensics era una branca molto peculiare della più usata Digital
Forensics. Ora, nel moderno mondo interconnesso (specialmente sul mobile) è impossibile
esimersi dall’affrontare l’argomento, in quanto non è più relegato ad ambiti specifici.
Come già accennato, fare una perizia su un tablet o uno smartphone come strumento a sé stante
ha davvero un’utilità limitata. Spesso il device è un mero tramite usato per sfruttare vari servizi
posti in remoto su Internet.
Lo stesso dicasi per quanto riguarda i social network o la pletora di servizi offerti da Google
o da iCloud, per non parlare di c Amazon S3, Citrix Xen Desktop, VMware View, NoMachine
NX Server, Ulteo OVD o altro.
A una recente conferenza tenutasi a Dubai, uno dei principali player europei dei sistemi di
intercettazione governativi mostrava come il numero di protocolli applicativi basati su TCP/IP
sia drammaticamente aumentato, sia per numero sia per complessità.
Al momento in cui parlava il loro sistema di dissector era in grado di decodificare oltre 5000
protocolli e altri erano in sviluppo.
Questo fa certamente capire come la cattura del dato sulla Rete possa essere un’enorme fonte
di prova all’interno di una moderna indagine. Tale cattura ovviamente cambia di molto in
relazione a dove essa debba essere fatta e da chi siano le parti in causa. È bene quindi fare una
piccola anticipazione sull’argomento, anche se sarà trattato estesamente in un capitolo dedicato.

Network Forensics: tipi e problematiche

Possiamo distinguere la Network Forensics in almeno quattro sottocategorie principali.
Governativa: in questa branca troviamo tutti i sistemi riservati a forze dell’ordine e servizi.
Si tratta di sistemi di fascia molto alta utilizzati per intercettare, monitorare e deviare il
 traffico IP direttamente sulle PDN (Public Data Network) gestite dalle varie Telco
mondiali. Comprende la capacità di monitorare vari protocolli WAN su cavo (SDH, ATM,
Frame Relay, MPLS tra i principali) o via etere (VAST, DVB-S e DVB-S2), con velocità
nell’ordine di decine di Gbit.
Privata: in questa fascia rientra tutto quello che è possibile utilizzare per intercettare un
flusso di dati in una rete privata, LAN o WAN che sia. La differenza rispetto al punto
precedente è che l’intercettazione WAN avviene non sul flusso pubblico nel trasporto della
Telco ma sulle apparecchiature di collegamento tra la propria rete e la rete pubblica e si
limita ai propri dati in arrivo o in partenza verso la rete WAN (tipicamente sui firewall
perimetrali o sui terminatori di VPN). L’intercettazione di dati privati su proprie
apparecchiature è subordinato a poche leggi che perlopiù riguardano la privacy o i diritti
dei lavoratori, al contrario di quanto accade per le PDN, dove le legislazioni sono molto
più stringenti e gli organismi preposti a effettuare tali operazioni sono un numero molto
limitato.
Locale sugli end point: la diffusione della crittografia, in particolare via SSL e TLS, spesso
rende problematico (se non impossibile) effettuare alcun tipo di intercettazione.
Considerato che molti servizi popolari sono ora protetti di default da sistemi di crittografia
dei dati su network (Facebook, tutti i servizi di Google, Dropbox, l’home banking, la quasi
totalità delle webmail), si deve procedere diversamente. In questo caso la strategia più
usata è quella di installare un trojan su uno dei due endpoint della comunicazione per poter
intercettare i dati prima che essi siano cifrati. Esistono sia trojan utilizzati a livello
governativo, sia disponibili nel mercato mainstream e acquistabili anche con cifre modeste.
Si parlerà di questi sistemi nel capitolo di Network Forensics.
Ricerca di artifact: non si tratta di una Nework Forensics vera e propria ma di
un’applicazione della Digital Forensics alla ricerca di artifact creati dall’uso di servizi di
rete. Un esempio possono essere quelli creati dall’uso della messaggistica di Facebook.
Qualora non si sia potuto intercettare il flusso attraverso uno dei metodi sopradescritti e gli
stessi siano stati rimossi dal server, l’unica soluzione potrebbe essere quella di ricercare
sul disco l’entry text, tipica del formato record dei messaggi Facebook. Spesso nel pagefile
di sistema si possono recuperare decine di messaggi di questo tipo. Si parlerà di questi
sistemi nel capitolo di Network Forensics.

Governativa
L’intercettazione governativa viene effettuata utilizzando sistemi di alto livello e con la piena
collaborazione da parte delle Telco, che spesso forniscono il servizio necessario per
l’interfacciamento alla rete.
 Un sistema di intercettazione IP è composto principalmente da tre parti che lavorano in
concerto.
La prima è la sonda. Si tratta di macchine specializzate composte da sistemi di elaborazione
high-end (spesso sistemi multiprocessore ad architettura NUMA o Blade server) collegati alla
rete tramite schede di rete dotate di processori dedicati (molti modelli mettono a disposizione
anche speciali SDK per Linux per poter interfacciare direttamente il kernel con la scheda,
permettendo così la cattura di pacchetti direttamente e senza passare per le più comuni, e lente,
librerie PCAP).
La scheda è collegata alla rete della Telco attraverso una span port sul core switch (soluzione
adottata fino a velocità di 1 Gbit, dato che a velocità superiori tende sia a sovraccaricare lo
switch sia a perdere pacchetti) oppure direttamente sulla fibra di trasporto attraverso un TAP
ottico.
Un TAP è un apparecchio passivo che permette di effettuare uno split del segnale ottico
presente in una fibra permettendo quindi un’intercettazione non rilevabile (se non facendo delle
accurate misurazioni sulla perdita di potenza del segnale prima e dopo l’inserimento del TAP
ottico stesso). Tali TAP lavorano ovviamente a Layer 1 e quindi dipendono solamente dal
protocollo usato per la gestione del segnale ottico ma, nel contempo, sono totalmente
indipendenti da tutto lo stack superiore. A uno o più TAP passivi possono essere collegati dei
TAP attivi che permettono sia di migliorare il segnale splittato sia di effettuare in hardware
alcune operazioni come, per esempio, l’aggregazione di flussi che in origine erano stati
multiplexati su un certo numero di canali a 10 Gbit/sec. I maggiori fornitori di sistemi di TAP
sono Netoptics (http://www.netoptics.com) e VSS (http://www.vssmonitoring.com).
La sonda è un sistema DPI (Deep Packet Inspection) in grado di effettuare un’analisi in
tempo reale del traffico catturato su tutti i sette livelli dello stack ISO/OSI. In base alle regole di
configurazione ricevute analizza se tale traffico risponde alle caratteristiche rilevate e ne invia
una copia al sistema di mediation. I principali fornitori di sonde DPI ad alta velocità sono la
francese Qosmos (http://www.qosmos.com/) e la tedesca Ipoque (http://www.ipoque.com).
Il secondo componente della soluzione è il mediation. Tale sistema si pone tra la sonda è il
monitoring center. Il suo scopo è sia quello di nascondere la complessità della configurazione
dei singoli apparati che controlla (esponendo al monitoring center un framework di
configurazione comune a tutte le sonde agli altri apparati controlati dalla soluzione), sia quello
si raccogliere i dati filtrati dalle sonde e di presentarli al monitoring center con un formato
comune (solitamente a standard ETSI). Il mediation gioca quindi un ruolo fondamentale nella
creazione di soluzioni complesse che permettano di interfacciarsi con reti di diversa natura (IP,
PSTN, Mobile) potendo scegliere liberamente le apparecchiature (sonde) più adatte per ogni
singola tipologia. Le tedesche Utimaco (http://www.utimaco.com) e Trovicor (http://www.trovicor.com)
sono due fornitrici di sistemi di Mediation.
 In ultimo, il monitoring center, è il sistema che si occupa di ricevere i flussi di dati,
decodificarli e mostrarli in una forma comprensibile agli operatori LEA (Law Enforcemente
Agencies) così che possano svolgere le loro indagini. Il monitoring center si occupa inoltre
dello storing dei dati, dell’accounting degli operatori, della sicurezza di accesso ai dati, della
messa in opera di tutti quei sistemi atti a garantire la non modificabilità dei dati ricevuti e infine
della possibilità di presentare le fonti di prova digitali (e il loro contenuto opportunamente
decodificato) in aula.
Il monitoring center permette anche agli operatori di decidere quali siano i criteri di cattura
dei dati per ogni singola indagine. Tali criteri saranno trasformati dal mediation in file di
configurazione compatibili con le singole soluzioni di prova installate presso le varie Telco.
Le italiane Area ( http://www.area.it), Innova (http://www.innovatrieste.it), RCS
(http://www.rcslab.it), Resi Group (http://www.resi-group.com) e la tedesca ATIS ( http://www.atis-
systems.com) sono tutte compagnie che sviluppano e vendono monitoring center.

Privata
Intercettare i dati in un contesto privato richiede solitamente sistemi meno sofisticati di quelli
in uso a livello governativo. Ovviamente ci sono delle eccezioni. Grandi multinazionali con reti
ramificate ovunque nel mondo hanno invece esigenze (e budget) pari ai sistemi governativi e
quindi devono rifarsi a quel tipo di sistemi.
Per il mercato privato esistono soluzioni estremamente interessanti. Andando su piattaforme
commerciali, le appliance basate su Linux la fanno piuttosto da padrone, in particolare perché il
sistema operativo è sia estremamente adattabile sia ottimamente ben supportato dai produttori di
hardware high-end, in particolare nelle schede di rete.
Riverbed (http://www.riverbed.com), la società che sta dietro al potentissimo dissector open
source Wireshark (http://www.wireshark.org/) fornisce dei sistemi piuttosto interessanti con una
serie di funzioni accessorie non incorporate nel dissector open. Riverbed si è conformata alla
moda più attuale e quindi fornisce sia appliance fisiche già configurate, sia sistemi virtuali utili
per catturare traffico all’interno delle reti aleatorie degli hypervisor, sia per evitare l’acquisto
di hardware specializzato. Un altro vendor che opera con sistemi di questo genere è ipcopper
(http://www.ipcopper.com/), con la sua serie IPCopper USC xxxx.
Nel campo invece della Network Forensics Analisys si trovano sistemi molto interessanti
come quelli di SessionVista (http://www.sessionvista.com).
Certamente si può sempre pensare di costruire da sé il proprio sistema di network capture &
dissector, ma è bene ricordare che ogni volta che ci si sposta di un ordine di grandezza in
relazione alla velocità di rete è necessario aumentare drasticamente la spesa.
Se qualunque notebook discreto è in grado di intercettare e controllare un flusso da 100 Mbit,
solo i più performanti riescono a fare la stessa cosa con reti da 1 Gbit, mentre servono sistemi
professionali di fascia high-end per gestire in scioltezza un DPI su reti di maggiore velocità. Per
capire il punto, le sonde DPI di QOSMOS (che girano con un sistema Linux modificato di
derivazione RedHat) utilizzano per l’intercettazione di flussi a 10 Gbit sistemi IBM X5 3850 o,
in caso di connessioni multiple fino a 2 sistemi IBM X5 3950 in stack, con schede Napatech
(http://www.napatech.com) dotate di propria logica a bordo.
Ancora più complicata appare la realizzazione di una sonda ad alta velocità da collegare
come sistema a un virtual switch di un hypervisor. In questo caso il Digital Forensics expert
dovrà ben tenere a mente quante risorse dovranno essere dedicate alla macchina virtuale in
questione e quanto queste andranno a impattare all’interno dell’infrastruttura da analizzare.
Spesso si rischia di dover aggiungere un nodo al cluster per dedicare risorse alla sonda.
Ad ogni modo, per costruire un sistema che permetta di copiare i flussi di dati saranno
necessari:
un sistema low-end con almeno 2 GB di RAM e disco SATA per l’intercettazione di flussi
fino a 100 Mbit;
un sistema middle/high-end con più CPU multicore, 4/8 Gb di RAM, scheda di rete PCI
Express (meglio di tipo server) per sistemi fino a 1 Gbit/sec, con sistema di storage veloce
composto da dischi SAS.
Nella pratica non è ancora fattibile riuscire a creare un sistema che possa intercettare flussi a
10 Gbit/sec a un costo che sia concorrenziale rispetto a un sistema commerciale, non fosse altro
per il costo dell’hardware necessario e il tempo speso a ottimizzare il sistema operativo per
poter lavorare alla massima velocità possibile.
Per creare il proprio sistema la cosa migliore rimane utilizzare un hardware basato su
piattaforme server. Se si opta per sistemi industriali e/o embedded è meglio verificare con un
occhio attento le performance che si possano ottenere, in particolare sull’I/O verso le memorie
di massa, che possono essere un collo di bottiglia tale da rischiare di perdere pacchetti. Di
solito si consiglia di lavorare con sistemi embedded nel momento in cui servono dei sistemi che
possano essere facilmente camuffati in un ufficio. In caso contrario è meglio optare per un
server o una workstation.
Servirà un numero di schede di rete pari a 2 × il numero di collegamenti da intercettare, più
una per la gestione e il download dei file. Quindi, per esempio, per intercettare due
collegamenti a 1 Gb, serviranno almeno 5 schede ethernet.
A tal fine è meglio ricordare che più schede di rete saranno collegate al sistema più interrupt
si dovranno gestire. La differenza tra una scheda di tipo economico e una di livello più elevato
risiede anche nel fatto di riuscire a lavorare in DMA evitando di sommergere di interrupt il
processore.
 NOTA
Su Linux la CPU0 gestisce tendenzialmente tutti gli interrupt. Per questo, qualora si debbano usare molte porte
ethernet, si consiglia di scegliere sistemi multisocket (attenzione non vale la stessa cosa per i multicore) con il
programma irqbalancer al fine di distribuire il carico della gestione degli IRQ su tutti i processori fisici presenti.

Linux rimane il sistema principe per la creazione di sonde in grado di catturare il traffico di
rete. Non solo è ottimamente supportato, ma tutto l’hype che si è creato attorno al mondo della
virtualizzazione e del cloud ha avuto, nel corso degli anni, il risultato di permettere un notevole
affinamento dei suoi bridge device, rendendoli molto più veloci e stabili.
Esistono varie distribuzioni che si possono utilizzare per questi sistemi. In generale è meglio
tenere le installazioni molto leggere, e quindi evitare processi inutili e orpelli vari come GUI,
daemon di automounter e server non necessari. Se si vuole lavorare di cesello, uno dei migliori
servizi (guarda caso cloud) disponibili è Novell SuSE Studio (http://susestudio.com/). Tramite
questo sito si può partire da una base OpenSuSE o SLES (SuSE Enterprise Server) per ottenere
una nuova distribuzione che incorpori solo i pacchetti necessari e possa essere arricchita con
driver e programmi non originalmente inclusi nella distribuzione. Una specie di “make your own
distro in box”.
Tendenzialmente ciò che è richiesto è:
un sistema Linux minimale (CLI);
un daemon SSH;
un supporto ai bridge device + bridgeutil;
un supporto alle VLAN 802.1Q e relative utility;
un programma per il dump di rete (tcpdump va bene, tshark va decisamente meglio).
Si supponga di lavorare in una LAN. Per le LAN i protocolli sono più semplici, più
conosciuti e le apparecchiature sono più vicine a quelle utilizzate quotidianamente. Inoltre,
spesso, intercettando dei flussi su WAN, il carrier fornisce una porta monitor su uno switch
posto in una centrale o in un nodo di interscambio, riportando virtualmente la situazione a quella
di una LAN.
Come è possibile intercettare i dati in LAN? Innanzitutto occorre definire quali sono i target.
Intercettare indiscriminatamente significa infatti:
violare la legge: nella quasi totalità dei casi esistono questioni di privacy, limitazioni poste
dal GIP nell’autorizzazione del decreto, problemi con lo Statuto dei Lavoratori e un
milione di altri problemi che impediscono di usare questa tecnica senza le dovute garanzie;
sprecare tempo e risorse: per motivi ovvi, intercettare tutto il traffico di una LAN impone
l’uso di sonde multiple, di macchine estremamente performanti e di salvare su disco una
notevolissima quantità di dati (che qualcuno poi dovrà analizzare):
andare incontro a problemi tecnici: come si ha già avuto modo di accennare, intercettare
 una singola macchina richiede l’installazione di un trojan o di una apparecchiatura
specifica tra il target e lo switch o collegata a una span port.
Alla luce di tutto questo è quindi vitale riuscire a definire il target con estrema precisione.
Ciò non solo per avere una delle prime indicazioni su dove porre la sonda, ma anche perché dal
target dipende la scelta del modo in cui si farà l’intercettazione.
Uno dei metodi più semplici è l’utilizzo di una span port o “porta monitor”. La quasi totalità
degli switch programmabili (praticamente quasi tutti quelli posti in una fascia di prezzo sopra i
200 euro) dispone di questa funzionalità. Tramite il software di gestione si può intercettare il
traffico proveniente da (e diretto verso) una porta dello switch e duplicarlo su una seconda.
NOTA
Si ricorda che spesso non è possibile utilizzare più di un limitato numero di span port, dato che gli ASICS dello
switch sono messi sotto stress.

L’utilizzo di una span port richiede sia che lo switch supporti tale funzione (deve essere uno
switch programmabile) sia che venga creata una configurazione ad hoc. L’amministratore dello
switch deve quindi sapere che si sta piazzando una sonda sulla rete.
Esistono altri metodi alternativi alla span port. Si supponga di voler intercettare tutto il
traffico uscente verso Internet (o verso un determinato host su Internet) di una qualsiasi realtà.
La tecnica dell’utilizzo di una span port potrebbe rimanere valida, ma si potrebbe voler
scegliere delle alternative (per la mancanza di uno switch programmabile, per l’impossibilità di
raggiungere l’armadio ove questo è posto e così via). Un’idea potrebbe essere quella di deviare
il flusso tramite un attacco di tipo man in the middle.

Attacchi man in the middle

Gli attacchi man in the middle (noti anche come monkey in the middle) sono una serie di
attacchi su LAN e WAN mirati a portare l’attacker in mezzo al flusso. Siano A e B i due
interlocutori di una conversazione digitale, e sia C l’attacker, posto in altra locazione, che vuole
spiare la conversazione. Per far questo, C deve per prima cosa deviare il flusso dei dati tra A e
B in modo da trovarvisi in mezzo. A questo punto l’intercettazione diventerà una banalità. È
deviare il flusso che può costituire, però, un compito difficoltoso.
Per attuare un attacco man in the middle attraverso una rete locale è necessario utilizzare
delle tecniche di ARP spoofing. Questo sistema, pur essendo assolutamente efficace, ha come
contropartita il fatto di essere incredibilmente “rumoroso” e di intervenire profondamente nel
funzionamento della rete, sovvertendo alcuni dei punti cardine del Digital Forensics expert,
ovvero quello di non alterare minimamente l’ambiente e i dati su cui opera.
Un attacco man in the middle non è quindi la soluzione ideale per effettuare un’intercettazione
che non causi alcun sospetto e che non alteri i dati.
Un altro metodo può essere quello di usare un TAP. Tolto che vi sono delle punte di diamante
nella produzione mondiale, quali NetOptics e VSS, è possibile acquistare un Network Tap in
rame o fibra a costi più che accettabili da vari vendor quali:
DualComm: http://www.dual-comm.com;
Datacomm Systems: http://www.datacomsystems.ca;
Network TAPS: http://www.networktaps.com/;
Gigamon: http://www.gigamon.com/.
Questi apparecchi hanno il vantaggio non solo di essere assolutamente trasparenti e
irrilevabili dalla rete, ma anche di mandare alla sonda solo i dati presenti in rete. Ergo, se si
sbaglia a configurare la scheda di rete i dati generati dalla sonda non saranno erroneamente
inviati sulla LAN. Quindi nella maggior parte dei casi si raccomanda l’uso di questa tecnica nel
maggior numero di casi possibile.
Nel caso non si abbia la possibilità di ricorrere a un Network Tap si può sempre utilizzare i
bridge device di Linux. Nati per ambiti molto limitati sono ora estesamente utilizzati nell’ambito
della virtualizzazione sotto Linux, che si usi KVM, libvirt o XEN. Non per nulla il codice
relativo è ora molto più stabile e performante rispetto a tempo fa.
Come funziona uno switch di rete? Lo switch riceve i dati su una qualsiasi delle sue porte,
legge il MAC address del destinatario dalla trama Ethernet, consulta la propria tabella di
correlazione per capire se il destinatario è connesso a una delle proprie altre porte e, se la
risposta è positiva, inoltra il pacchetto su quella determinata porta. Collegandosi a uno switch è
quindi virtualmente impossibile (senza usare una span port) spiare la conversazione tra altre due
macchine, dato che lo switch sposta i dati solo tra le porte interessate. L’unica alternativa
potrebbe sembrare l’attacco man in the middle spiegato poco sopra.
In realtà tutti i dati all’interno di uno switch viaggiano su un bus comune, noto con il nome di
backplane. Se ci fosse l’opportunità di collegarsi al backplane si potrebbe allora intercettare
qualunque conversazione passi per lo switch. Questa funzionalità non è prevista praticamente da
nessun prodotto di questo genere in commercio.
Linux, tramite la funzione di bridge device, permette di prendere un certo numero di schede di
rete della macchina e collegarle a uno switch virtuale creato ad hoc. Il vantaggio sostanziale di
questa soluzione è che il backplane di questo switch virtuale è visibile al sistema operativo
come una qualunque interfaccia di rete, per cui si può intercettare il traffico che passa su di
esso.
Inoltre, è bene tenere in considerazione il fatto che uno switch di rete è virtualmente invisibile
a qualunque controllo. Essendo un dispositivo passivo, che non altera in alcun modo il traffico
passante (al contrario di quanto, per esempio, fa un router, che manipola gli header dei livelli 2
e/o 3 della pila ISO/OSI di ogni pacchetto in transito), non è possibile stabilirne la presenza.
 Come si usano?
Per prima cosa sarà necessario creare lo switch software. Si supponga di avere una macchina
con tre schede di rete (eth0, eth1, eth2). Le prime due saranno configurate come porte di uno
switch software. Inizialmente si attiveranno le schede tramite il comando ifconfig:
ifconfig eth0 –arp up
ifconfig eth1 –arp up

Questi due comandi attivano le due schede di rete senza fornire loro un indirizzo IP e vietando
l’uso del protocollo ARP. Le schede sono ora funzionanti (se collegate a uno switch sarà
negoziato lo stato del link), ma non saranno rilevabili.
Alcune moderne distribuzioni Linux sono totalmente basate sul nuovo sistema di routing
(Linux Advanced Routing) e usano il più duttile comando ip al posto del vecchio ifconfig. In tal
caso i comandi da usare sarebbero:
ip link set eth0 up arp off
ip link set eth1 up arp off

Attivate le porte, è ora tempo di utilizzare le bridge utils per la creazione dello switch
virtuale:
brctl addbr br0

Questo comando crea un nuovo switch virtuale. br0 è un nome di fantasia che identifica il
bridge stesso. Inoltre, è il nome dell’interfaccia virtuale che il sistema operativo assocerà al
backplane dello switch di rete. Attivato lo switch e le interfacce, si può creare l’associazione:
brctl addif br0 eth0
brctl addif br0 eth1

Le schede eth0 ed eth1 sono ora connesse allo switch virtuale appena creato. Ora sono, a tutti
gli effetti, due porte dello switch br0.
Per maggiore sicurezza si disabiliterà il protocollo di spanning tree sullo switch virtuale, così
che questo non si annunci al mondo nel caso siano presenti altri switch con questo protocollo
attivo:
brctl stp br0 off

Ora l’unica azione che rimane da compiere è attivare l’interfaccia corrispondente al

backplane:
ifconfig br0 –arp up

oppure:
ip link set br0 up arp off

SUGGERIMENTO
Attenzione a un particolare. Costruendo una macchina perché faccia da sonda è necessario utilizzare schede
che supportino la funzione di autocross (per esempio tutte le schede a Gigabit). Con questa funzione la scheda
riesce a capire quando è collegata con un altro computer (dove sarebbe richiesto un cavo cross) e quando è
collegata a uno switch. In questo modo non si dovrà intervenire sui cavi per invertire le coppie. Questo problema
non si pone con l’uso di Network TAP.
 br0 è ora un’interfaccia di rete come tutte le altre (si potrebbe tranquillamente utilizzarla
assegnandole un IP). È quindi possibile utilizzare uno sniffer per acquisire tutto il traffico
passante per il backbone.
Anche in questo caso si vuole spezzare una lancia a favore del software open source.
Praticamente ogni sistema di sniffing al mondo salva i dati in un formato proprietario. Esiste
comunque un formato riconosciuto come la “lingua franca” dei sistemi di sniffing/IDS, ovvero
pcap. Tale formato si basa su una serie di librerie multipiattaforma note come libpcap. Tutti i
sistemi open source sono dotati di libpcap, quindi la maggior parte dei programmi di sniffing
che gira su di essi è in grado di usare questo formato. Salvare i dati raccolti in formato pcap
permette agli stessi di essere letti e utilizzati da un enorme numero di programmi commerciali e
open source. È quindi un modo di raccogliere la prova valido per non vincolare la controparte
all’utilizzo di uno specifico tool.
Esistono diversi candidati per questo compito. Vediamoli.

tcpdump
tcpdump è un classico. Usato dai sysadmin di mezzo mondo per fare debugging delle proprie

reti, tcpdump è un programma noto e di semplice utilizzo. Suo punto di forza è il fatto di utilizzare
un potente sistema di filtri che, pur limitato, permette di intercettare facilmente solo il traffico
interessato.
Per utilizzare tcpdump come sniffer di rete al fine di salvare il traffico su disco si devono
utilizzare i seguenti switch.
-w nomefile: notifica a tcpdump di salvare i dati (in formato pcap) sul file specificato dopo lo
switch. I pacchetti vengono salvati in formato RAW, senza alcuna elaborazione.
-s0: di norma tcpdump salva solamente i primi 68 elementi di un pacchetto. Tale

comportamento è giustificato dal fatto che tcpdump è principalmente uno strumento

diagnostico e i sysadmin sono interessati più agli header dei pacchetti che al loro
contenuto. Specificando questo parametro tutto il pacchetto (header e body) verrà catturato.
-C dimensione_in_milioni_di byte: permette di gestire una rotazione dei file ove vengono

salvati i dati. In questo modo si evita di dover gestire un file da svariati Gigabyte in fase di
analisi. Quando tcpdump nota il superamento della soglia specificata con –C crea un nuovo
file con lo stesso nome indicato nel parametro -w e un numero progressivo a seguire.
-n: indica al programma di non effettuare alcuna conversione riguardante nomi host, nome

delle porte e MAC address. Tutto viene salvato in formato numerico.

-i nome_interfaccia: specifica il nome dell’interfaccia dove effettuare lo sniffing.

SUGGERIMENTO
 Le singole interfacce di uno switch software possono essere comunque utilizzate per effettuare lo sniffing di
una parte del traffico. Si sceglierà, a seconda dei casi e di cosa sia effettivamente necessario, se effettuare lo
sniffing su una singola porta o sul backplane.

Se si volesse usare tcpdump come sniffer sul backplane dello switch software creato nel
paragrafo precedente il comando sarebbe quindi:
tcpdump –n –w /var/spool/sniffer/intercettazione.pcap –s0 –C 100 –i br0

tshark
Wireshark possiede un ottimo sistema di cattura dei pacchetti. L’unico limite è quello di
operare in un ambiente grafico. Esiste però una versione per l’utilizzo su terminale a carattere
(nota come tshark) che è ottima per la realizzazione di sonde da porre all’interno di un sistema di
intercettazione LAN. I vantaggi dell’uso di Wireshark rispetto a tcpdump sono la possibilità di
salvare i dati in formati diversi da pcap (nel caso ve ne sia la reale necessità), la possibilità di
utilizzare i filtri nativi (molto più complessi e duttili di quelli di tcpdump) e il supporto ai file
compressi con zlib.
I parametri più utili per l’utilizzo di tshark per lo sniffing sono i seguenti.
-i nome_interfaccia: specifica il nome dell’interfaccia dove effettuare lo sniffing.
-b opzioni: specifica le opzioni necessarie per l’utilizzo di file multipli. Il file può essere

ruotato non solo per quello che riguarda la grandezza, ma anche per il tempo trascorso. È
inoltre possibile settare un’opzione per far sì che i file più vecchi siano sovrascritti (da
usare con estrema prudenza). Per impostare le opzioni occorre usare: duration:valore, che
crea un nuovo file dopo un numero di secondi specificati da valore; filesize:valore, che
crea un nuovo file dopo che il precedente ha raggiunto una grandezza (in kilobyte) espressa
da valore; files:valore, che tiene al massimo un numero di file pari a valore, dopodiché
comincia a sovrascrivere i file più vecchi.
-f filtro: permette di specificare un’espressione di filtraggio secondo la sintassi di tcpdump.

-w file: definisce il file dove andranno salvati i dati. Se usato da solo, salverà dati RAW in

formato pcap. Utilizzato con il parametro –F, salverà i dati nel formato specificato.
-F tipo: specifica il formato del file di output.

-n: indica al programma di non effettuare alcuna conversione riguardante nomi host, nomi

delle porte e MAC address. Tutto viene salvato in formato numerico.

Conservazione
Sarebbe preferibile implementare all’interno della sonda uno script che si occupi di validare
con un sistema di hash (MD5, SHA1, SHA256 e così via) i file di cattura che vengono generati
dagli sniffer. In questo modo si potrebbe non solo validare i file una volta trasferiti dalla sonda
a un supporto non alterabile, ma anche prevenire una loro alterazione durante il periodo di
giacenza nelle memorie di massa della sonda stessa.
 Capitolo 5

Il laboratorio di analisi

“... Mi sento un po’ Tony Starks, un po’ un moderno dottor Frankestein. Opero a cuore aperto dispositivi elettronici per
arrivare fino ai bit più interni. Un giorno tutta questa tecnologia mi si ribellerà contro...”

Premessa
Come per altre professioni legate alla polizia scientifica, le funzionalità di un laboratorio per
la pratica della Digital Forensics possono essere vincolate a un fattore, quello economico. Non
esiste praticamente limite alla quantità di fondi necessaria per disporre di un laboratorio
veramente completo. Si pensi solo a quanto serve spendere per riuscire a rimanere al passo con
la tecnologia in continua evoluzione. La differenza sostanziale rispetto alle altre discipline,
però, è che si può comunque costruire un laboratorio anche con un investimento relativamente
modesto. Non sarà completo e si potrà intervenire solamente in un sottoinsieme di casi, ma darà
al Digital Forensics expert la possibilità di partire e diluire gli investimenti nel corso del
tempo.
Anche in questo caso non si vuole comunque andare agli eccessi. Molti sono convinti che si
possa cominciare un’attività di questo genere semplicemente prendendo un buon computer in una
grossa catena di distribuzione e infarcendolo di software. Siamo in una situazione estrema.
L’idea di un sistema “forensics in a box” è ben lontana dall’essere raggiunta sia dal punto
dell’offerta commerciale disponibile al momento, sia dal punto di vista dell’usabilità. Per
quanto si possa prendere il meglio della produzione hardware, non è semplicemente possibile
riuscire a fare tutto con un’unica macchina. Vi sono troppe necessità in contrasto l’una con
l’altra. Si pensi solo al fatto che il sistema operativo della macchina deve essere mantenuto
quanto più stabile possibile (riporto una frase fantastica di Stefano Zanero) “... il software, in
grazia di Dio, è deterministico e non caotico (con la possibile esclusione di Windows)” ma, nel
contempo, spesso occorre testare continuamente nuovi programmi utili all’indagine o importare
dati e software di dubbia provenienza che potrebbero contenere ogni malware di questa Terra.
La tecnologia, comunque, continua a fare passi da gigante e i prezzi, nonostante la crisi
imperante ormai da anni, continuano a scendere. In particolare la virtualizzazione e i sistemi di
storage hanno cambiato davvero il modo di operare. La pletora di macchine necessarie fino a
poco tempo fa si è notevolmente ridotta, almeno a livello hardware, e nel contempo ci si può
muovere con molta più scioltezza e facilità. Quindi la parola d’ordine “consolidamento” si può
applicare finalmente anche ai laboratori personali o delle piccole organizzazioni, con risultati
davvero molto simili a quelli di classe enterprise.
NOTA
Nonostante tutto anche Windows ha fatto i suoi passi avanti e quindi da Windows 7/2008 R2 abbiamo sistemi
davvero ben fatti. Hyper-V è finalmente un hypervisor che si può dire tale. Resta da vedere il successo che avrà
la nuova infrastruttura basata su Windows 8/2012, ma intanto la GUI ha dei seri problemi di usabilità. Ad ogni
modo si ritiene ancora che pagare licenze per avere un sistema di back-end non eccelso abbia poco senso.
Siete quindi liberissimi di creare un’infrastruttura full Windows anche per la parte server (e potrebbe essere
anche una scelta interessante) ma non sarà quella raccomandata in questo testo.

Concetti generali
Ridondanza e velocità sono le parole d’ordine per la costituzione di un laboratorio di analisi
forense.
La ridondanza è necessaria in quanto il Digital Forensics expert non può permettersi di
perdere nemmeno un dato in suo possesso. In qualunque situazione deve mettere in conto la
possibilità che il suo hardware subisca un guasto e prendere tutti gli accorgimenti affinché in
seguito a tale evento i dati non vadano persi o danneggiati.
La velocità è un must. I dischi stanno crescendo a un ritmo che si può definire imbarazzante.
Ormai si parla di dischi da 3 TB senza troppi patemi, e i nuovi 7 TB sono all’orizzonte. Si
profilano quindi ore e ore passate a leggere o a giocare con il tablet durante tutte le operazioni
di trasferimento. Dato che, comunque, tutti hanno purtroppo una vita sola e non è bello sprecarla
ad attendere, è bene lavorare molto accuratamente per migliorare le performance anche di pochi
punti percentuali. La riduzione del tempo necessario per compiere varie operazioni potrebbe
essere nell’ordine di ore.
Per fortuna, nel recentissimo passato c’è stata un’evoluzione anche nelle interfacce di
connessione. USB 3.0, Thunderbolt, eSATA, SAS e SATA III sono ora standard su molti sistemi.
E questo riporta un po’ di equilibrio, riducendo i tempi di trasferimento rispetto ai precedenti
sistemi.
Per quanto riguarda i laboratori, i microserver o i NAS sono davvero arrivati a livelli di
eccellenza. Quello che prima poteva essere fatto solamente con qualche decina di server
dedicati, ora è possibile farlo con uno solo di questi apparecchi. Il risparmio in termini di
acquisto di hardware e di corrente necessaria è davvero ragguardevole. I nuovi modelli dei due
maggiori produttori sul mercato, Synology e Qnap (in ordine di preferenza), scalano fino a cifre
nell’ordine dei 400 TB.
Per chi avesse esigenze maggiori, anche i block storage hanno migliorato il loro rapporto
prezzo-prestazioni. Si parte da prezzi attorno a qualche migliaio di euro per sistemi in grado di
scalare fino a 200 TB (come l’Enhance Technology ES3160 FS), fino a cifre davvero importanti
per grossi sistemi dipartimentali in grado di scalare fino a 4 PB (come il Fujitsu Eternus DX
8700 S2).
Come si può vedere c’è un’offerta interessante per tutti i laboratori di analisi forense, da
quello del professionista fino al grande laboratorio governativo.
In generale mi sento di raccomandare un’inversione di tendenza rispetto a quanto avevo
affermato nella seconda edizione del libro. Con il progredire delle tecnologie appena citate,
oggi ha poco senso un’architettura completamente distribuita basata su file server, in quanto
sarebbe sia complessa da gestire sia antieconomica, oltre che poco affine ai nuovi canoni del
green IT.
Quindi, come linea generale, preferisco suggerire un principio comune basato su una struttura
di back-end in grado di gestire un elevato numero di meccaniche e di dialogare con la rete ad
alta velocità tramite interfacce a 1 Gbit/sec o 10 Gbit/sec per i protocolli di rete, o a 8/16 Gbit
per quanto riguarda le SAN Fibre Channel.
Le macchine di analisi usate dagli investigatori potranno sia essere delle workstation
personali connesse alla rete del laboratorio ( o direttamente alla SAN) oppure un pool di
macchine virtuali residenti in un cluster di hypervisor (pur tenendo conto di alcuni limiti).
Anche la capacità di calcolo dei processori ha subito un notevole incremento e quindi,
nonostante le richieste computazionali in gioco ancora nella Digital Forensics, non si deve
scartare a priori l’ipotesi di concentrare l’infrastruttura su un minor numero di macchine più
potenti.
Per un laboratorio personale, o di dimensioni contenute, può essere interessante una soluzione
basata su un NAS in grado di operare sia con protocolli di rete CIFS e NFS, sia via iSCSI. Tale
NAS sarà collegato a una o più workstation con Windows o Linux come sistema operativo
principale e a una serie di macchine virtuali specializzate in vari compiti.
Per esigenze di livello più elevato si può integrare un cluster di hypervisor che possano
ospitare uno o più file server OpenAFS, come workstation virtuali specializzate e magari un
connection broker che possa permettere un pratico accesso alle strutture del laboratorio da sedi
remote o dai luoghi ove si è chiamati a operare.
Laboratori di livello da medio a enterprise, possono sostituire o integrare i NAS con una
SAN basata su su iSCSI o Fibre Channel collegata a uno o più block storage di capacità
adeguata.
Sistemi di backup basati su tecnologie di deduplica trovano in questi ambiti la loro naturale
collocazione.
Vediamo ora di affrontare in dettaglio le tecnologie che fungeranno da “building block” dei
nostri laboratori.
 NAS e SAN: un po’ di definizioni
Il mondo dei sistemi di memorizzazione SAN e NAS è decisamente complesso e spesso ben
al di là delle conoscenze medie di un informatico. Per riuscire a comprendere i concetti che
stanno alla base di tali sistemi si vuole quindi riportare una descrizione (sommaria, a essi sarà
dedicato un capitolo apposito) delle principali funzioni, che permetterà quindi di capirne
l’utilità.
NAS (Network Attachment Storage): si tratta di un sistema che permette di esportare i
propri dati attraverso dei protocolli di rete tipici di un file server, e, tipicamente, NFS per
il mondo Unix, CIFS per il mondo Microsoft e AFP per quello Apple.
SAN (Storage Area Network): è una rete specializzata per il collegamento di sistemi di
storage di vario genere, dai block storage alle tape library. Tipicamente una SAN è
composta da un’infrastruttura di trasporto basata su Fibre Channel. Più recentemente il
protocollo iSCSI è entrato prepotentemente sul mercato a causa dei costi meno elevati e
per il fatto che, essendo basato su IP, è indipendente dal medium trasmissivo. Il protocollo
FCOE (che unisce in un unico medium trasmissivo, CEE, Ethernet e Fibre Channel),
lanciato da qualche anno, è stato inizialmente visto come la prossima frontiera di questo
tipo di infrastrutture ma non ha riscosso il successo sperato, sia per un approccio fin troppo
cauto da parte di molti produttori, sia per problemi ancora non superati del protocollo
stesso.
Block storage: al contrario del sistemi NAS, un block storage esporta le proprie
informazioni come dischi logici (LUN). Queste LUN sono collegate ai rispettivi server
come fossero un disco locale. Al contrario di una share di rete di un NAS, una LUN dovrà
essere formattata con un file system e sarà dedicata a una sola macchina (a meno di non
usare cluster file system come OCFS2, Lustre, VMFS o altri).
Unified storage: sistema in grado di funzionare contemporaneamente da NAS e da block
storage. All’inizio appannaggio dei sistemi NetApp, è ora una funzione implementata da
vari produttori come HDS e EMC2. Con la diffusione del protocollo iSCSI molti piccoli
NAS SOHO e middle class sono divenuti unified storage.
Snapshot: funzione che permette di prendere un’istantanea dello stato di una LUN. Usata sia
per poter tornare a uno stato precedente in caso di fallimento di operazioni critiche, sia per
poter ridurre drasticamente le finestre di backup. La presa di uno snapshot richiede
solitamente pochi secondi e può essere effettuata senza influire sui servizi essenziali del
server. Il successivo backup su nastro viene effettuato dallo snapshot e non dalla LUN in
produzione, permettendo così di gestire con più tranquillità il processo di copia dei dati.
Lo storage lavora a livello di puntatori e di singoli blocchi e quindi non è una copia
pedissequa della LUN, con evidenti vantaggi di spazio utilizzato e tempo necessario al suo
 completamento. L’operazione di revert di uno snapshot (ovvero quella di riportare la LUN
allo stato dello snapshot) è altrettanto veloce. Tramite API specifiche (come le VAAI
perVMware) le funzioni di snapshot di un hypervisor possono essere demandate in
hardware allo storage.
Thin provisioning: permette sia di allocare a una o più LUN uno spazio maggiore di quello
fisicamente disponibile sullo storage, sia quello di massimizzare l’utilizzo dei dischi
utilizzando lo spazio in maniera intelligente. Solitamente il RAID group dello storage viene
suddiviso in varie LUN tramite allocazione statica. Se il server a cui tali LUN sono
connesse non sfrutta tutto lo spazio a disposizione esso rimarrà allocato e non sarà
effettivamente disponibile per gli utenti. Usando il thin provisioning si può allocare un
certo quantitativo di spazio per ogni LUN, e lo storage allocherà dinamicamente solo
quello effettivamente utilizzato per lo stoccaggio dei dati, evitando di sprecare spazio (un
tipico esempio di thin provisioning è lo spazio allocato per Gmail). Qualora si sia scelto di
andare in overprovisioning (ovvero di allocare per i server più spazio di quello
effettivamente disponibile) al superamento di determinate soglie impostate
dall’amministratore, lo storage provvederà ad avvisare di inserire nuovi dischi che
integrerà nel pool al fine di rendere lo spazio necessario effettivamente disponibile.
LUN cloning: con questa funzione è possibile duplicare quasi istantaneamente una LUN.
Utile per il deploy di ambienti di test o produzione o per creare batterie di macchine
virtuali.

NAS
I sistemi NAS attuali sono davvero dei piccoli capolavori. Si tratta perlopiù di microserver
con un sistema operativo Unix-like fortemente ottimizzato a bordo, e processori che possono
essere, per i modelli più piccoli, degli ARM mono o multicore (gli stessi che poi si ritrovano in
molti smartphone moderni), per poi passare a CPU Intel che, nei modelli di punta, vengono
direttamente dalla famiglia XEON.
La particolarità di questi sistemi è quella di avere un sistema di memorizzazione che
incorpora già al suo interno molte delle funzioni utili, da quella del mero file server, a un
directory service che possa essere usato da tutti i sistemi del laboratorio, per non parlare del
fatto che spesso dispongono di connessioni eSATA e USB 3.0 che permettono di collegare loro,
per esempio, i dischi usati sul campo per raccogliere le fonti di prova digitale e trasferire il
tutto all’interno del NAS ad alta velocità senza impegnare inutilmente una macchina esterna.
I modelli da 4/8 meccaniche (come i Synology DS413 o DS1812+) sono sufficientemente
compatti da essere portati con sé sul campo e, nel contempo, possono comunque stipare fino a
20 TB di dati.
 Sfruttando inoltre i software aggiuntivi che tali piattaforme mettono a disposizione è possibile
integrare altre interessanti funzioni quali backup remoto, repliche sincrone e asincrone, accesso
e sincronizzazione via cloud, sistemi di collaborazione e cifratura delle informazioni in
hardware.
Per esempio, un NAS può essere usato per la gestione delle macchine virtuali, uno per
contenere i dati delle indagini,e uno esposto su Internet per permettere lo scambio sicuro di
documenti con clienti e AG tramite servizi cloud sulla falsariga di Mega o Dropbox. Il tutto per
un costo che è notevolmente inferiore a quello di un server di fascia media.
I sistemi operativi dei principali produttori di NAS (compresi quelli consumer) integrano
anche funzioni di block storage (tipicamente iSCSI), che li trasformano a tutti gli effetti in
unified storage.
La disponibilità, a costi assolutamente limitati, delle funzioni di snapshot, thin provisioning e
LUN cloning (certificati per i maggiori sistemi operativi e hypervisor) sono una vera manna per
chi si occupa di informatica forense.
Si pensi, per esempio alla comodità di salvare i dati di un indagine su una LUN iSCSI e di
poter usare le funzioni di snapshot prima di effettuare qualunque operazione potenzialmente
pericolosa o che possa modificare i dati stessi. Significa risparmiare decine di ore di lavoro (e
terabyte di spazio) per la creazione di copie multiple.

Block storage
Questi sistemi sono tipicamente basati su una architettura più sofisticata dei comuni NAS (con
eccezione di NetApp, che usa per i suoi unified storage le caratteristiche tipicamente enterprise
dei block storage).
Nella quasi totalità dei casi sono formati da una coppia di controller che lavorano in cluster e
sono visti dalla SAN come un’unica entità. In caso di rottura di uno di questi il controller
rimanente continuerà il lavoro senza interruzione alcuna.
Tendenzialmente essi dialogano con il front-end (i server collegati alla SAN) via Fibre
Channel, iSCSI o FCOE. Nel back-end utilizzano collegamenti SAS per gestire numeri anche
molto elevati di hard disk (fino a 4096 per i modelli di fascia high-end). I dischi sono suddivisi
in RAID group (anche di tipo diverso a seconda degli utilizzi), e poi esportati verso la SAN
come LUN).
Integrano solitamente funzioni di snapshot, thin provisioning, autotier e di replica sincrona e
asincrona (ovvero la capacità di replicare LUN o snapshot tra coppie di storage anche
distribuite geograficamente).
Sono la scelta obbligata per chi necessiti di uno spazio condiviso per un cluster oppure per la
gestione di grandi quantità di informazioni.
 Nell’informatica enterprise sono diffusi ormai da anni, mentre in quella di medio livello sono
diventati comuni con l’introduzione delle architetture di virtualizzazione.

OpenAFS
Si cercherà ora di spiegare alcuni dei concetti generali relativi a OpenAFS e, nel contempo,
di mostrare come questi si tramutino in vantaggi per la Digital Forensics.

Un po’ di storia
AFS (Andrew File System) nasce circa a metà degli anni Ottanta come un componente
dell’Andrew Project, un sistema per creare un nuovo concetto di “distributed computing”. Il
progetto nel suo complesso ha avuto alterne vicende, ma la parte di file system distribuito ha
dimostrato fin dall’inizio delle ottime potenzialità, che hanno portato alla sua acquisizione da
parte dei laboratori Transarc (diventati poi di IBM dal 1994), che per circa dieci anni ne hanno
curato la distribuzione commerciale. Nel 2000 (per essere precisi al LinuxWorld del 15 agosto
di quell’anno), IBM annunciò di voler rilasciare l’intero prodotto sotto licenza Open.
Venne quindi fondato il progetto OpenAFS, capitanato da una serie di anziani (elder) e da
alcuni portinai (gatekeeper, al momento tutti facenti parte anche del consiglio degli anziani) con
il compito di gestire i repository di versionamento.
Il progetto da allora ha premuto sull’acceleratore e le release si sono susseguite a un ritmo
incessante, grazie anche ai notevoli finanziamenti ricevuti da enti di ricerca, governi e grandi
compagnie.
Il protocollo è stato migliorato notevolmente, e la release di sviluppo (1.5.x) promette passi
avanti da gigante in merito.
OpenAFS è ora disponibile per una enorme quantità di dialetti Unix (molte distribuzioni
Linux, Solaris, AIX, Darwin, HP-UX, Irix, FreeBSD, NetBSD e OpenBSD tra i principali), OS
X (ivi compreso Darwin e le ultimissime versioni), la famiglia dei sistemi Windows (compresi
Vista e 2008 Server e le varie versioni a 64 bit) e qualche piattaforma più esotica.

Architettura generale
OpenAFS è un file system distribuito di rete. E si potrebbe dire che qui finiscono tutti i punti
di contatto con gli altri sistemi nati per lo stesso scopo. In primis il suo sistema di
autenticazione si basa su Kerberos. Attualmente, all’interno di OpenAFS è contenuto un
authentication server (kaserver) che però è basato sulla versione 4 di Kerberos. Sulle mailing
list stesse di OpenAFS gli sviluppatori sconsigliano caldamente di usarlo essendo un protocollo
che si è già dimostrato insicuro; al suo posto si può usare sia il MIT sia l’Heimdal Kerberos. Il
secondo ha delle librerie specifiche per facilitare l’uso di OpenAFS, ma anche il MIT è
comunque facilmente integrabile con degli appositi tool.
OpenAFS, al contrario di quasi tutte le altre tecnologie simili, è un file system “location
independent” e ha uno Unified Named Space reale. Ciò significa che, una volta loggato sulla
cella (ovvero un raggruppamento di file server), ogni client, indipendentemente dalla
piattaforma, vedrà un unico albero di rete. L’utente ignora totalmente la reale posizione dei file,
che possono stare su un numero di file server variabile tra 1 e N. Solo l’amministratore potrà
decidere e conoscere l’esatta collocazione dei file.
Dal punto di vista dell’analisi forense, questo fatto è utilissimo. Gestendo grandi moli di dati,
spesso distribuite su più file server, avere uno Unified Named Space significa poter trovare
facilmente i propri dati o lanciare ricerche su casi che si trovano su macchine diverse senza
doversi loggare su ogni singolo server alla ricerca di quanto depositato.
L’albero di rete viene composto da volumi. In OpenAFS il volume è un insieme atomico di
dati, una specie di cartella contenente file di vario genere. È atomico perché il volume, per il
file system, non può essere scisso ulteriormente. I volumi, quindi, possono essere creati,
montati, spostati, cancellati o replicati, ma non possono, per esempio, essere divisi su due
differenti file server. Ogni cella AFS conterrà necessariamente due volumi principali, il root.afs
e il root.cell, che saranno montati rispettivamente sulle directory /afs e /afs/nome-della-cella.
Montati questi due, si potrà cominciare a creare l’albero, che sarà composto da semplici
directory o da mount point ai volumi presenti. I mount point possono essere innestati gli uni sugli
altri.
Tutta questa complessità viene gestita da una serie di appositi database server che si
occupano sia della localizzazione dei file, sia della gestione dei permessi. Il client possiede un
cache server che interroga i database server distribuiti nella rete richiedendo loro copia dei dati
necessari.
Si notino quindi due ulteriori vantaggi di OpenAFS. In primo luogo, dal lato client vi è un
ampio uso di cache per le operazioni di rete, il che permette di sveltire non poco le operazioni
stesse. In secondo luogo, ogni client lavora con copie in locale dei file (o loro porzioni)
piuttosto che sui file stessi. La consistenza delle cache e dei file lato client è gestita dai database
server che si incaricano di verificare se i file richiesti dai client sono cambiati sui server e di
notificare tale variazione a chi ne abbia necessità. Il meccanismo è così efficiente che si stima
che con OpenAFS si possa arrivare a un rapporto client/server di 114.000:1.

Caratteristiche peculiari
OpenAFS dispone di una serie di caratteristiche che lo rendono perfetto non solo per compiti
di file server generici ma anche, nello specifico, per la creazione di un sistema di storage per un
laboratorio di Digital Forensics.
Il primo vantaggio apportato da OpenAFS lo si è già illustrato: permette di distribuire il
carico su più server ma, nel contempo, di vedere il tutto come un’unica entità. In pratica è come
avere una SAN ma una frazione del suo costo.
Il secondo vantaggio è la replicazione. Ogni singolo volume di rete può essere replicato su un
numero N di server in maniera trasparente e del tutto automatica. Basta un singolo comando per
replicare un volume su un altro server. In lettura, i database server provvederanno a bilanciare
il carico con un meccanismo di round robin. In scrittura, un server accentrerà tutte le richieste e
le distribuirà alle copie in read/write. In caso di rottura di uno dei server sarà OpenAFS stesso
a indirizzare i client sui server restanti.
Il terzo vantaggio è la sicurezza. Un laboratorio di analisi forense ha due necessità, in antitesi
l’una con l’altra. In primo luogo, si trattano dati molto sensibili, quindi si deve essere certi che
solo chi sta lavorando sul caso possa visionare il materiale. D’altra parte, ogni singolo tecnico
deve disporre dei massimi diritti possibili sulla macchina da analisi (root o administrator level)
per poter svolgere molte delle operazioni necessarie all’analisi stessa. Molti file system di rete
hanno dei seri problemi a conciliare queste due richieste, e basta un minimo errore di
configurazione per rischiare di vedere la sicurezza del laboratorio sgretolarsi. OpenAFS non
presenta invece alcun problema. Non solo, ma spinge questo concetto all’estremo.
Per comprendere meglio questo punto, occorre capire come funziona un file server in una
cella. Un file server OpenAFS richiede tassativamente che i repository dove salvare i volumi
stiano in file system montati nelle directory che vanno da /vicepa a /vicepz e da /vicepaa a
/vicepzz. Si ribadisce che ogni singola directory deve essere un mount point per un file system.
OpenAFS richiede che tale file system (che deve essere necessariamente di tipo journaled,
essendo sconsigliato l’uso di ext3 per problemi di performance sulle operazioni di
cancellazione) sia adibito a uso esclusivo. Il contenuto di tali partizioni è semplicemente
impossibile da leggere. OpenAFS tratta tali file system a suo uso e consumo, quindi i dati sono
sparpagliati in decine (se non centinaia) di directory con nomi assurdi e del tutto
incomprensibili. Inoltre, tentare di leggere tali file potrebbe essere deleterio in quanto anche una
modifica sui metadati dei file potrebbe rendere il volume illeggibile fino alla successiva
operazione di salvataggio. Perciò, pur disponendo della password di root su un file server
OpenAFS, si potrebbe al massimo cancellare tutto (non facendo alcun danno se i volumi sono
stati correttamente replicati) ma non leggere i dati. Per far questo, anche su un server, ci si deve
loggare con un client OpenAFS con le proprie credenziali Kerberos che, a questo punto,
potrebbero essere del tutto indipendenti da quelle del sistema locale (come nel caso in cui si
disponga dei diritti di root del sistema). Si noti che l’amministratore di OpenAFS dispone di
una propria credenziale disgiunta da quella di root/administrator locale.
Il quarto vantaggio riguarda i backup. La funzione di backup, come quella di recovery dei
volumi danneggiati, è interna al file system. Non serve alcun programma esterno. OpenAFS
mette a disposizione vari tipi di backup, dai dump ai backup veri e propri su cassetta o media
esterni.
Come ultima cosa da rimarcare, OpenAFS può essere gestito da qualunque client o server
facente parte della cella. Il solo requisito è quello di possedere un account Kerberos con diritti
amministrativi.

Architettura del laboratorio di analisi

Creare un’infrastruttura scalabile è certamente un must, ma bisogna stabilire inizialmente
quale sia il target relativamente al tipo di laboratorio che si vuole costruire in maniera da capire
quale dev’essere l’investimento iniziale.

Laboratori personali o di dimensioni contenute

Un’infrastruttura costruita su livelli multipli rimane irrinunciabile per qualunque laboratorio
si voglia fregiare di questo titolo. È praticamente impossibile utilizzare una sola macchina, per
quanto potente sia. Piuttosto si punterà su una serie di macchine specializzate e su un back-end
comune sulla quale tutte possono accedere.
In questo caso la scelta migliore è quella di usare un NAS con attivi sia CIFS sia NFS. In
questo modo sarà possibile accedere da più macchine contemporaneamente senza doversi
preoccupare se siano Unix-based o Windows-based e senza quindi dover utilizzare un cluster
file system comune a entrambe le piattaforme.
Conviene orientarsi su modelli che dispongono di doppia scheda di rete. Qualora si voglia
utilizzare il NAS solamente con le share di rete sarà utile acquistare uno switch Full Giga
programmabile e creare un trunk (o etherchannel alla CISCO) LACP a due gigabit con lo switch.
In questo modo si eviterà di creare un collo di bottiglia nel momento in cui più macchine fisiche
accedono al NAS.
Se si utilizza lo stesso come unified storage, conviene invece riservare una scheda per la
parte NAS e una per il block storage iSCSI. Si ricorda che uno dei migliori sistemi per
accelerare una connessione iSCSI risiede nell’uso di jumbo frame. In questo caso sarà quindi
utile utilizzare anche sugli host due diverse schede (una per la connessione alla LAN e una per il
trasporto iSCSI), creare due VLAN distinte sullo switch e abilitare quindi i jumbo frame su tutti
gli apparati interessati (interfaccia riservata all’iSCSI sul NAS, switch e interfaccia sugli host).
Specialmente se si utilizzano NAS di Synology (dove l’operazione è al limite del banale),
conviene installare un directory server LDAP su uno di questi e collegare tutti i NAS a
quest’ultimo. In questo modo sarà possibile unificare gli account per avere una maggiore
sicurezza e una più facile gestione. Per evitare problemi è preferibile limitare il numero di
account che possano accedere ai server in SSH o con diritti amministrativi. In questo modo si
potrà lasciare che gli investigatori digitali dispongano di account di livello amministrativo (root
o administrator a seconda del sistema operativo usato) sulle workstation da lavoro e, nel
contempo, limitare il loro accesso in rete ai soli casi su cui si sta lavorando.
Per le LUN iSCSI, che solitamente si autenticano tramite il mutuo riconoscimento del relativo
IQN, conviene abilitare anche l’autenticazione CHAP in modo che ogni utente possa collegare
solo le LUN a lui riservate.
Per quanto riguarda le attrezzature per l’analisi si consiglia di disporre almeno di una
macchina dedicata alla Mobile Forensics, una all’analisi dei supporti e una alla copia degli
stessi sul campo (a ognuna di queste tipologie è dedicato un paragrafo specifico all’interno di
questo capitolo).
La virtualizzazione è sicuramente utile ma non come comunemente si utilizza. Le attuali
architetture server sono spesso basate su un pool di host fisici con uno storage condiviso e un
numero variabile di server virtuali sopra di esse.
In un laboratorio di Digital Forensics difficilmente si può pensare di lavorare con le
workstation di analisi in questi termini. Purtroppo anche il migliore degli hypervisor non
permetterà di virtualizzare completamente l’hardware e spesso occorre utilizzare controller e
connettività specifiche (si pensi per esempio alla necessità di collegare un controller SAS o un
HBA Fibre Channel, oppure un banale disco USB 3.0 o Thunderbolt).
Meglio utilizzare quindi un host con un sistema operativo non virtualizzato e, piuttosto, un
hypervisor Type-2.
Quale usare? Per virtualizzare le proprie macchine la scelta è ampia e vi sono ottimi prodotti
gratuiti e open source, quindi la scelta dipende solo dal gusto e dalle abitudini personali. Capita
spesso però di dover esaminare delle macchine virtuali anche come fonte di prova. Nonostante
molti software di analisi supportino direttamente le piattaforme virtuali, è anche vero che spesso
può essere utile lanciare una copia (o uno snapshot) di una macchina virtuale acquisita per
esaminarne il contenuto. In questo caso la capacità di VMware Workstation di utilizzare le
macchine virtuali create con ESX server senza modifica alcuna può essere un vantaggio
incalcolabile. Inoltre VMware Workstation è quello che, al momento, ha una migliore gestione
dell’hardware virtuale e dei dispositivi USB.
Nel nostro laboratorio abbiamo una serie di macchine fisiche (basate sia su Windows sia su
Linux) con VMware Workstation e una serie di macchine virtuali specializzate disponibili per
tutti sullo storage (per esempio delle macchine Linux con varie distro e SDK, quella con
l’ottimo dtSearch per indicizzare masse di file, una macchina virtuale con DEFT, una con
CAINE e così via).

Laboratori di dimensioni medio-grandi

Per laboratori di queste dimensioni la scelta direi che è quasi obbligata. Qualora si preferisca
l’utilizzo di NAS o unified storage, ci si può o orientare sui sistemi di punta dei produttori
consumer (il modello RS10613XS+ di Synology supporta fino a 106 dischi alla massima
espansione e interfacciamento via 10 Gbit/sec Ethernet) oppure ai prodotti NetApp che, a fronte
di un investimento molto più oneroso, ripagano con scalabilità fino a oltre 1 PB e una
flessibilità d’uso non paragonabile ad alcun altro prodotto sul mercato.
La scelta spesso più logica è invece quella di una SAN basata su iSCSI 10 Gbit/sec oppure
su Fibre Channel a 8 o 16 Gbit/sec.
Vi sono semplicemente una marea di prodotti di ottimo livello a cui attingere. Nella fascia
media vi sono soluzioni sia da produttori economici ma pur sempre validi (Ehnance Technology
con la sua linea Ultrastor ES, QSAN TrioNAS, iXsystems Titan SAN), sia dai leader di
mercato, come Fujitsu, EMC2, DELL o HP. Nel caso della connettività Fibre Channel la scelta
obbligata sarà basata su Brocade, dato che le soluzioni di connettività FC di Cisco sono
ridicole.
NOTA
La differenza tra le soluzioni economiche e quelle dei produttori più blasonati (oltre che per alcune funzionalità
avanzate) risiede nell’acquisto dei dischi. I primi vendono spesso lo storage vuoto e che può essere riempito a
piacere dall’utente con dischi presenti in una HCL. I secondi costringono gli utilizzatori ad acquistare anche le
meccaniche e, solitamente, a costi ben più elevati dello street price.

Conviene acquistare lo storage avendo già un’idea relativamente alla massima quantità di dati
che si dovranno trattare. Spesso i produttori di SAN permettono di scalare fino a un certo
quantitativo di meccaniche dopodiché costringono gli utenti a passare su un’altra linea di
prodotto, con un notevole aggravio di costi in quanto non si può recuperare l’investimento
precedente. Si pensi per esempio a EMC2 con VNXe e VNX, a Dell con Equalogic e
Compellent.
Eccezione a questa regola sono Fujitsu e NetApp, che permettono di scalare dal loro low-end
fino ai prodotti di classe enterprise semplicemente cambiando i moduli controller e preservando
tutto il resto della componentistica.
Creata la SAN si potranno usare una coppia di file server (fisica o virtuale a seconda delle
preferenze) OpenAFS per poter condividere i dati dello storage a tutte le macchine di analisi
poste nel front-end.

Macchina da analisi/acquisizione
La macchina da analisi/acquisizione è la prima linea del laboratorio, quella che segue il
Digital Forensics expert nel momento in cui deve effettuare un sequestro o un’acquisizione. Le
caratteristiche generali richieste per questo tipo di macchine sono descritte nei prossimi
paragrafi.
 Cabinet capiente ma facilmente trasportabile
Un notebook, nonostante quello che si potrebbe pensare, non è decisamente la macchina
adatta per effettuare delle acquisizioni perché è troppo limitato sotto una molteplicità di aspetti.
Una macchina da analisi deve essere in primo luogo molto capiente. Deve consentire l’utilizzo
di schede di tipo diverso, offrire molte bay per l’alloggiamento di dischi fissi, essere ben
raffreddata, avere un alimentatore potente e disporre di una serie di bay da 5" 1/4 libere, per
consentire l’impiego dei cassetti removibili.
I cabinet da modder sono spesso la soluzione ideale. La recente evoluzione in questo campo
ha prodotto ottimi articoli, spesso ingegnerizzati meglio di quanto si può osservare in un
computer di marca e che permettono di creare sistemi assemblati con un elevato grado di ordine
interno.
Anche in questo caso dipende da che filosofia si vuole scegliere. Se si preferisce usare un
RAID locale sarà utile orientarsi su un server tower che possa contenere almeno sei/otto dischi
fissi, così da disporre di uno storage da 10/12 TB in RAID 6 (si consiglia fortemente di non
usare RAID 5 su macchine che debbano essere spostate di continuo come quelle da
acquisizione). Qualora si preferisca utilizzare la macchina da acquisizione e uno storage esterno
(soluzione che ha i suoi vantaggi, specialmente in termini di portabilità), si opterà per una
macchina che potrà contenere un buon numero di schede di I/O, ma con un footprint (e un peso)
decisamente minori.

Elevata velocità di I/O

Per fortuna si è superata l’empasse che fino a poco tempo ha caratterizzato l’evoluzione
tecnologica. C’erano dischi nell’ordine del Terabyte e interfacce di connessione con velocità
massima di 480 Mbit/sec (USB 2.0). Ora molti sistemi dispongono di connessione eSATA (3
Gbit/sec), USB 3.0 (4,8 Gbit/sec) e Thunderbolt (10 Gbit/sec).
NOTA
Sono in arrivo sia USB 3.1 sia Thunderbolt 2. Entrambe le interfacce raddoppieranno la velocità attuale.

Le connessioni Ethernet a 10 Gbit/sec hanno raggiunto costi umani e, in concomitanza con

iSCSI, permettono una connessione ai sistemi di block storage a elevata velocità.
Finalmente si ha la possibilità di riportare un po’ di equilibrio tra le capacità di
immagazzinamento dei dischi (dischi da 3 Terabyte con i 6 Terabyte in arrivo) e la velocità di
I/O, evitando quindi di dover buttare intere giornate per copiare un disco fisso.
Al momento attuale gli standard maggiormente diffusi per i dispositivi di memorizzazione
sono i seguenti.
USB: è ormai lo standard de facto per tutti i sistemi di memorizzazione portatili.
 Nonostante USB 3.0 non sia ancora molto diffuso, moltissimi dischi fissi dispongono già di
questa interfaccia. È quindi un must adottare un sottosistema USB 3.0 nella macchina di
acquisizione.
SATA: arrivato alla terza generazione, mette a disposizione un bus seriale a basso costo e
con una velocità massima di 6 Gbit/sec. Tutti i dischi di tipo consumer adottano questa
interfaccia. Esiste una sua variante (eSATA) per il collegamento di dischi fissi esterni con
una velocità massima di 3 Gbit/sec.
SAS: è stata la rivoluzione degli ultimi anni. Nel giro di poco tempo ha letteralmente
spazzato via sia SCSI (per l’interconnessione di sistemi di memorizzazione a livello
professionale) sia Fibre Channel (limitatamente ai sistemi di interconnessione tra gli
storage e i loro shelf e ai dischi ad altissima velocità). Tutti i dischi di elevato pregio
montano ora questo tipo di bus. Inoltre, per semplificare i collegamenti elettrici, sono stati
introdotti dei dischi denominati “Near Line SAS”. Tali dischi possiedono le meccaniche
dei dischi SATA (quindi bassa velocità di rotazione, 7200 rpm, e alta densità magnetica, 3
TB), e l’elettronica dei dischi SAS di qualità. Esiste una versione SAS interna che utilizza
un connettore di tipo SFF8482 per la connessione di un singolo disco e di tipo SFF8484
per la connessione di fino a 4 dischi.
Fibre Channel: i bus di interconnessione Fibre Channel è ancora usatissimo nelle SAN di
medio e alto livello. È stato sostituito dal SAS nel back-end degli storage, essendo più
veloce e molto più semplice da installare e da gestire.
Thunderbolt: protocollo nato come standard commerciale in rame basato sulle specifiche
del ben più costoso LightPeak di Intel. Promette velocità di tutto rispetto, ed è uno standard
nei computer Mac di ultima generazione. Fa un po’ più di fatica a diffondersi nel mondo PC
per via delle royalty richieste da Apple e per la concorrenza interna con il più comune (ma
meno veloce) USB 3.0.
Per la parte relativa alle interconnessioni di rete le schede Ethernet da 1 Gb/sec con
connettore RJ45 sono ancora lo standard più diffuso. Per i server e gli storage più rapidi esiste
poi lo standard 10 Gbit/sec con connettore SFP+. I principali moduli SFP+ sono quelli ottici,
con connettore LC, e che utilizzano fibra ottica multimodale su cavi OM3. Per interconnessioni
di lunghezza limitata (massimo 7 metri) si usano anche cavi in rame di tipo Twinax con
connettori SFP+ direttamente saldati al cavo.
La macchina per l’analisi dovrebbe quindi comprendere quante più schede possibile per
poter fronteggiare la maggior parte delle configurazioni che si possono trovare sul campo.

Reparto dischi efficiente e di grande capacità

Come si è da poco evidenziato, la macchina da analisi può disporre di un sistema di
memorizzazione interno, oppure di un collegamento con un sistema NAS di back-end.
Cosa scegliere dipende da una serie di fattori. In generale usare un NAS di back-end è utile
perché la macchina da acquisizione rimane sempre libera. Ergo, disponendo di una paio di NAS
si può lasciarne uno in laboratorio a riversare i dati della precedente acquisizione e ripartire
subito con uno nuovo. Al contrario sarà necessario svuotare la macchina dai dati in essa
contenuti prima di ripartire per un’altra operazione.

NAS back-end
Si può partire da modelli da 4/6 bay per salire a NAS con 8/12 meccaniche. Ricorrere a box
di espansione in caso di sistemi che si devono spostare spesso avrebbe poco senso.
A meno di non disporre di un fly-deck, non è il caso di ripiegare su modelli rack. I NAS da
scrivania sono decisamente più pratici da gestire e trasportare.
Synology dispone dei modelli DiskStation 413+, 1512+, 1812+ e 2413+ (rispettivamente da
4, 5, 8 e 12 bay), mentre QNAP dispone dei modelli TS-469L, 569L, 669L e 869L
(rispettivamente da 4, 5, 6 e 8 bay), che in uno spazio relativamente esiguo possono arrivare a
immagazzinare fino a 18 TB in RAID 6 (su sistemi che debbano essere ripetutamente spostati è
bene non affidarsi al solo RAID 5, neanche con un hot spare in linea).
A seconda dei modelli si possono avere connessioni a partire da 1 Gbit/sec per arrivare fino
a 10 Gbit/sec con l’aggiunta di una scheda Ethernet opzionale.
Lo storage può esportare i propri dati sia in NFS/CIFS sia in iSCSI. Il file system usato sui
dischi è ext4, quindi non ci sono problemi a gestire anche file di grandi dimensioni come NAS.
In caso di LUN iSCSI si dovrà usare sia un sistema di partizionamento che permetta la gestione
di volumi di grandi capacità (GPT sia per Windows sia per Linux) sia un file system journaled
che possa gestire file di grandi dimensioni (ext4,btrfs per Linux, ZFS su BSD e NTFS su
Windows).

Sistema RAID
I dischi dovrebbero essere gestiti sempre con un sistema che permetta di avere ridondanza.
Dato che la capacità totale dei dischi è altrettanto importante, il miglior compromesso tra i due
requisiti è probabilmente un RAID di livello 5 o 6.
Se si preferisce utilizzare GNU/Linux come sistema operativo di base, si consiglia
caldamente l’uso di un RAID software fornito dal sistema operativo. Rispetto a un RAID
hardware, le prestazioni sono leggermente inferiori e la CPU viene gravata di un compito
ulteriore, ma questi problemi sono compensati da una gestione diretta dei componenti hardware
che, in talune situazioni, può essere vitale. Inoltre, con le nuove CPU multicore si rischia
davvero di non notare differenze nella velocità complessiva del sistema anche se un singolo
core è impegnato nel calcolo degli hash necessari. Per capire meglio questo punto si pensi a un
RAID 5 in cui due dischi abbiano un problema. La tolleranza introdotta dal sistema può
compensare la perdita di un singolo disco ma non di due. Se il RAID è gestito dal controller in
hardware, le opzioni fornite dal firmware del controller per recuperare la situazione potrebbero
essere molto limitate. La maggior parte dei firmware è stata progettata per gestire la normale
creazione/manutenzione di un sistema RAID, non per recuperare situazioni anomale. Al
contrario, il sistema di gestione RAID software implementato nel sistema operativo GNU/Linux
(modulo del kernel md e tool di gestione mdadm) permettono di gestire, con un minimo di impegno
da parte del sistemista, una molteplicità di casi anche rischiosi. Chi scrive ha più volte
provveduto a operare su RAID software ritenuti irrecuperabili senza perdere, infine, alcun dato.
Un RAID hardware avrebbe comportato un lavoro con un livello di complessità decisamente
maggiore per riuscire a raggiungere, se mai fosse stato possibile, lo stesso risultato. Di contro, a
vantaggio di questa soluzione si possono citare sia una maggiore velocità sia una più semplice
gestione durante il normale funzionamento.
NOTA
Le moderne schede madri dispongono spesso di almeno sei connettori SATA III che possono essere configurati
sia in RAID sia in emulazione IC9 SATA. Ciò che bisogna controllare è che il RAID sia realmente un RAID
hardware e non un’emulazione fatta dal driver proprietario. In tal caso è meglio creare un RAID software: gestirlo
sarà certamente più semplice.

Purtroppo gli hard disk moderni sembrano essere sempre più fragili di quelli prodotti sino a
qualche anno fa. Probabilmente i problemi sono legati alle tecnologie usate per accrescere la
densità magnetica. Si è comunque osservato che non solo ci sono molte più probabilità che
presentino “bad cluster” ma, di fatto, che si manifestano problemi meccanici con una frequenza
decisamente elevata. In un laboratorio di analisi forense, inoltre, molto spesso gli hard disk
sono utilizzati in modalità sequenziale (operando con tool come dd) oppure sono stressati in
maniera superiore al normale utilizzo. Tutto questo si traduce, dati alla mano, in una quantità di
rotture decisamente sopra la media. Ciò comporta la scelta di utilizzare il sistema RAID più
adattabile possibile.

Grande adattabilità nei collegamenti

Il Digital Forensics expert difficilmente sa a priori che cosa si troverà dinnanzi nel momento
in cui dovrà effettuare un’acquisizione. È quindi opportuno essere preparati. Indipendentemente
dalla tecnologia scelta per il reparto dischi della macchina, occorre essere pronti a lavorare con
dischi e memorie di massa basati su standard diversi. È bene che la macchina disponga anche di
controller aggiuntivi che permettano di collegare il maggior numero possibile di hard disk
normalmente disponibili sul mercato. Si preveda, come già accennato nel paragrafo specifico, la
presenza di un controller ATA, SATA, SAS e SCSI (se possibile) e di opportune bay rimovibili
dove alloggiare temporaneamente i dischi da acquisire. In alternativa, è preferibile portarsi
qualche scheda aggiuntiva da infilare nel cabinet nel momento in cui si rendesse necessario.
NOTA
Si ponga particolare attenzione alla configurazione del BIOS della scheda madre, affinché la sequenza di boot
sia limitata al solo disco di sistema; si eviterà che, aggiungendo un nuovo disco, il sistema tenti il boot da
quest’ultimo.

È bene, inoltre, dedicare attenzione anche alla parte di networking. La macchina ideale per
l’acquisizione deve essere dotata di più di una scheda Ethernet, in particolare di una scheda di
rete per ogni computer che si voglia acquisire simultaneamente.
Si supponga di dover acquisire un certo numero di computer attraverso la LAN, per esempio
con l’accoppiata dd + netcat. Nel caso si vogliano copiare più computer contemporaneamente,
sarebbe bene che ognuno di essi utilizzasse un canale dedicato (ossia un cavo di rete), così da
massimizzare la quantità di dati diretta verso il server di acquisizione. Se si utilizzasse una sola
scheda questa diventerebbe il collo di bottiglia che finirebbe per rallentare l’operazione.
Collegando più schede di rete allo switch e assegnando a ognuna di esse un diverso IP e usando
quindi un listener netcat differente per ogni IP si utilizzerebbe, invece, un canale Ethernet per
ogni macchina da acquisire. Una scheda quad port Gigabit su PCI Express è l’ideale per questo
compito.
Sarebbe inoltre consigliabile dotarsi di almeno una scheda di rete in fibra ottica (il massimo
è averne sia una Ethernet sia una Fibre Channel), per poter collegare il sistema di
analisi/acquisizione anche a questo tipo di cablaggio. Infine, si preveda un certo numero di porte
USB (rigorosamente 2.0 o meglio ancora USB 3.0) e FireWire (o IEEE 1394) per connettere
dischi fissi esterni, eventuali blocker o adattatori.
NOTA
I tradizionali cavi ATA/SATA to USB, si sono evoluti in alcune docking station costruite decisamente bene. Al
contrario dei cavi adattatori, queste evitano di fare errori nell’inserimento e permettono anche di gestire i dischi
in modalità hot plug. Gli ultimi modelli supportano sia dischi da 2,5" sia da 3,5", connettività USB 3.0 e uso di
dischi multipli. Il loro costo decisamente economico ne fanno uno strumento da tenere sempre a portata di
mano.

Macchine da analisi/test
Le macchine da analisi sono quelle che saranno usate stabilmente in laboratorio. Si ritiene
quindi che nella situazione ideale si dovrebbe disporre di una o due macchine basate su
piattaforma Windows, da utilizzare per i programmi commerciali di analisi forense e di Mobile
Forensics.
La configurazione di queste macchine dovrebbe essere la migliore in relazione al budget
stanziato. CPU multicore (AMD o Intel), una notevole quantità di RAM (dai 16 GB in avanti),
reparto dischi capiente e possibilmente una scheda grafica NVIDIA o AMD in grado di dare una
mano alla CPU principale (mediante le CUDA Library o OpenCL) in operazioni quali il
password cracking. Dovrebbero essere fornite di tutte le porte standard (FireWire 400 e 800,
USB 3.0, eSATA, Thunderbolt), connessioni wireless (Wi-Fi e Bluetooth) e adattatori per le
porte non più in uso al momento (iRDA, parallela e seriale).
Avere un Mac nel laboratorio è utile. Per quanto Apple sia ormai una piattaforma diffusa e OS
X non sia più un mondo a parte ma abbia delle notevoli affinità con il mondo Unix, è altresì
vero che molte utility per l’esame approfondito di un sistema Mac sono disponibili solo per
quest’ultimo. Pertanto, può essere un ottimo investimento possedere una di queste macchine.
Si iniziano a trovare in commercio anche portatili con porte di I/O veloci. Risultano essere
sempre dei compromessi rispetto a una workstation, ma hanno l’indubbio vantaggio di poter
essere trasportati molto più facilmente. Alcuni modelli (purtroppo pochi) dispongono già sia di
USB 3.0 sia di Thunderbolt, oltre che a connessioni eSATA. Di solito si tratta di modelli di
punta e quindi dispongono sia di CPU veloci sia di memoria RAM in abbondanza. Se si ha la
possibilità di affrontare la spesa si tratta certamente di un buon investimento, specialmente per
emergenze “on the field”.
Alcune società (sopra tutte l’americana diypc, http://www.mydiypcusa.com/) hanno creato delle
linee di “open case”, ovvero di supporti per assemblare dei PC completamente aperti, utili per
un gran numero di scopi. Questi sistemi risultano particolarmente indicate in alcune situazioni
dove sia necessario operare con con controller particolari e applicare gli stessi su una macchina
da analisi/acquisizione. Meritano di essere tenuti in considerazione.

File/application server
Con l’utilizzo sia di trunk (o EtherChannel alla Cisco) sia di connessioni veloci a 10 Gbit,
decade quanto si affermava nella precedente edizione, ovvero di avere un layer di
file/application server da utilizzare per evitare di dover spostare grandi quantità di dati. I nuovi
NAS consigliati all’inizio del capitolo funzionano ottimamente e quindi possono essere utilizzati
per fornire il back-end necessario alle stazioni di lavoro.
Nel caso si disponga di un laboratorio di classe più elevata (e si opti per l’utilizzo di una
SAN), si consiglia ancora di dotarsi di una coppia di file server OpenAFS da utilizzarsi come
cluster per servire le macchine di analisi. Al contrario di quanto accade con altri servizi non
occorre che le due macchine siano parte di un cluster HA. È sufficiente che entrambe permettano
l’esportazione di tutti i volumi OpenAFS. Il carico può essere suddiviso definendo qual è la
macchina master per la scrittura su ogni specifico volume. Se si dispone di un cluster di host per
la virtualizzazione (indipendentemente da quale sia l’hypervisor), si può optare per una coppia
di macchine virtuali, avendo cura di assegnare ogni macchina a uno specifico host, per questione
di bilanciamento di carico.
 Backup
Un RAID, di qualunque livello esso sia, non salva l’utilizzatore da un errore umano come la
sovrascrittura di un file o una cancellazione accidentale. È perciò necessario possedere un
sistema di backup che consenta di far fronte a qualunque problema si presenti sui sistemi di
middle layer.
Si possono scegliere numerose tecniche per effettuare il backup, dall’uso massivo di snapshot
sui NAS o storage block, alla replica su uno storage offsite, all’uso degli snapshot e backup a
livello di OpenAFS. Esistono anche ottimi server di backup open source, come Amanda
(http://amanda.zmanda.com/), BackupPC (http://www.zmanda.com/backuppc.html), Bacula
(http://www.bacula.org/en/) e Opendedup (http://opendedup.org/).
Purtroppo è davvero difficile indicare una soluzione che possa adattarsi a tutte le esigenze. Le
ultime tecnologie hanno avuto un forte impatto anche sulla parte di backup, che si è evoluta dal
“semplice” nastro. I sistemi di backup attuali sfruttano l’integrazione con gli storage (usando gli
snapshot si possono ridurre drasticamente le finestre di backup, così come effettuare delle
repliche periodiche tra storage omogenei) utilizzano sistemi di deduplica e l’integrazione con
gli ambienti virtuali.
Raccomandare un sistema di backup è virtualmente impossibile, perché tutto dipende sia
dalla configurazione hardware, sia da quella software sia dalle politiche di retention che si
vogliono definire per il proprio ambiente. L’unica cosa da ricordare è ovviamente quella di
implementare qualcosa!

Software
La scelta del software è al centro di un intenso dibattito tra i Digital Forensics expert.
Sostanzialmente si delineano due scuole di pensiero, una a favore del software commerciale,
una di quello open source. Si è già avuto modo di chiarire, in questo volume, i motivi per i quali
si ritiene che il software open source sia da preferirsi in ambito forense. Indipendentemente
dalla scelta effettuata, comunque, non è opportuno trincerarsi dietro posizioni al limite del
fanatismo. L’idea generale è quella di privilegiare l’utilizzo di software open source, ma nel
caso non vi sia un software di questo tipo che serva allo scopo richiesto si sceglieranno
programmi commerciali. Lo stesso dicasi quando l’alternativa commerciale è nettamente
migliore, per risultati, del software open source. Per esperienza maturata nel corso degli anni si
può comunque affermare quanto segue.
È sicuramente da preferirsi il software open source per tutto quanto è strutturale alla rete,
compresi application server, printer server, firewall e file server.
Non è conveniente puntare in maniera esclusiva sul software commerciale o su quello open
 source, perché vi sono semplicemente troppi casi che non potrebbero essere trattati se ci si
focalizzasse solo su uno dei due mondi.
Nel caso di un laboratorio basato su tecnologie open è buona norma avere almeno un
sistema dedicato all’uso di un pacchetto commerciale. Vi sono molte situazioni in cui una
workstation di questo tipo potrebbe tornare utile. La scelta del pacchetto è del tutto
personale. Al momento attuale il nostro laboratorio possiede alcune stazioni basate sul
software X-Ways Forensics (http://www.x-ways.net/). Abbiamo ritenuto fosse la scelta più
opportuna sia per le potenti funzioni fornite con il software stesso (vi sarà dedicato un
capitolo specifico), sia perché esso è basato su quello che probabilmente è l’editor
esadecimale migliore del mondo, sia infine perché ha un prezzo abbordabile (e non è cosa
da sottovalutare). Stiamo attualmente testando OSForensics di PassMark.
Volendo trattare in maniera seria la parte di Mobile Forensics non ci si potrà esimere
dall’acquisto di software/hardware appropriato. I patti di non disclosure imposti dalle case che
sviluppano telefoni bloccano lo sviluppo di software open source in questo campo. Vi sono una
marea di programmi/pacchetti disponibili al momento sul mercato con un rapporto costo-qualità
non sempre vantaggioso.
Al momento attuale nei nostri laboratori si continuano a usare delle postazioni basate su
Oxygen Forensics Suite 2 e sull’apparato UFED Cellbrite. Si parlerà di entrambe nel capitolo
dedicato al Mobile Forensics.

Sistema operativo
Come già ribadito, GNU/Linux al momento non ha eguali per quanto riguarda il settore
specifico dell’analisi forense. Molti sono i punti a suo favore.
Architettura Unix-like. Il paradigma progettuale di Unix (“ogni cosa è un file”) permette di
effettuare le stesse operazioni a livelli diversi (file, file system, inode, device e così via)
utilizzando sempre gli stessi identici tool. Inoltre, la possibilità di trattare un device fisico
come un file permette di avere una duttilità di gestione sconosciuta a un sistema Windows.
Effettuare, per esempio, la copia di un device richiede un tool di pochi KB (dd) al contrario
di quanto accade in Windows, dove sono necessari programmi specializzati.
Ampio supporto di file system. Il numero di file system supportati da Linux (oltre 30) rende
quest’ultimo un sistema unico nel panorama complessivo, sia commerciale sia open source.
L’onnipresente Windows permette di gestire, nella sua ultima incarnazione, ISO 9660,
NTFS e FAT (in tutte le loro varianti). OS X lavora con HFS (base, HFS+, Journaled e
Journaled case sensitive), ISO 8660, NTFS (in sola lettura), UFS e FAT (tutte le varianti).
Questi sistemi, se usati in ambito forense, necessitano di un supporto a livello applicativo
per poter esaminare file system di altre architetture. Linux non necessita invece di alcun
 tool software: tutto il supporto è fornito direttamente dal kernel.
Kernel modulare. Nonostante Linux non sia basato su microkernel, dispone di un sofisticato
sistema per il caricamento dinamico di moduli kernel a caldo. Tali moduli non provengono
solo dai sorgenti del kernel, ma anche da terze parti. Ciò permette di aggiungere nuove
funzionalità al kernel di Linux in qualunque momento. Si pensi per esempio a cdfs, un
modulo che permette di analizzare i CD-ROM/R/RW a un livello più profondo di quello
previsto dall’ISO 9660. Le funzioni di cdfs non trovano riscontro in alcun altro tool per
altri sistemi operativi e consentono di eguagliare, con un semplice masterizzatore, sistemi
di analisi basati su hardware specializzato.
Possibilità di personalizzazione. I programmi di analisi forense sotto Windows devono
spesso appoggiarsi ad hardware specializzato o utilizzare stratagemmi vari per adattare il
comportamento di Windows agli scopi voluti. Tutto il sistema GNU/Linux può essere
invece modificato ad hoc. Le distribuzioni specializzate in analisi forense spesso utilizzano
sia un kernel sia dei tool adattati. Il comportamento del sistema, quindi, viene variato dal
sorgente stesso, evitando comportamenti non conformi a quanto richiesto. Inoltre, si evitano
problemi derivanti da errori umani. Per esempio, la Live distro Helix Knoppix non utilizza
mai il file o la partizione di swap presente sul disco fisso da analizzare, anche nel
momento in cui il Digital Forensics expert tenti di forzare il sistema a comportarsi in modo
differente.
Ottimi tool di corredo. Il numero di programmi open source specializzati per il Digital
Forensics expert è in costante aumento. La distribuzione Helix Knoppix contiene al suo
interno decine di questi programmi. Indipendentemente da questo fatto, è possibile
risolvere interi casi con i normali comandi Unix di ricerca e indicizzazione oltre che
utilizzando vari linguaggi di scripting specifici. Per fare un raffronto, Guidance Software
ha sempre sostenuto che uno dei punti forza del proprio prodotto Encase Forensics fosse il
sistema di scripting Enscript. Pur non volendo contestare a priori tale affermazione, si può
comunque dire, senza tema di smentita, che Enscript non sia nemmeno paragonabile alle
potenzialità di Perl, Python o Ruby e delle migliaia di librerie disponibili per questi
linguaggi.
Costi di licenza contenuti o inesistenti. Il laboratorio potrà essere progettato al fine di
ottimizzare il risultato finale. Non dovrà essere fatto alcun compromesso a causa di elevati
costi di licenza per ottenere funzionalità avanzate. Questo sia per i programmi specifici per
l’analisi forense, sia per le funzionalità di rete di back-end, come LDAP per la gestione
degli oggetti di rete, Kerberos per l’autenticazione e OpenAFS per il file sharing.
Il principale problema che affligge il sistema GNU/Linux è la frammentazione. Non esiste un
unico sistema di riferimento, ma piuttosto centinaia di distribuzioni. Per “distribuzione” si
intende una collezione di programmi, librerie e kernel uniti a un software per l’installazione e la
gestione del sistema. Esistono distribuzioni di tutti i generi, da quelle assolutamente general
purpose (che permettono di installare diverse tipologie di macchine, siano esse server o
workstation) alle più specializzate, utili solamente in alcuni frangenti o in nicchie di mercato
peculiari. Se questa situazione altro non fa che dimostrare quanto Linux possa essere un sistema
adattabile e camaleontico, dall’altro lato crea svariati problemi.
Confusione. L’utilizzatore, occasionale o esperto che sia, si trova a dover scegliere non
solo tra centinaia di distribuzioni diverse ma anche tra decine di distribuzioni simili in uno
specifico settore.
Selezione naturale. Uno dei principali problemi che affliggono il sistema di sviluppo open
source è la coesistenza di decine di progetti del tutto sovrapponibili. Molti sviluppatori si
lanciano nella realizzazione di nuovi lavori per scoprire poi – o dopo averne volutamente
ignorato l’esistenza – progetti già in essere con caratteristiche del tutto simili. Purtroppo,
specialmente per una questione di fama, spesso si vedono questi progetti procedere a stento
in parallelo piuttosto che collaborare e unire le forze. Infine, solo i progetti che riescono a
mantenere viva l’attenzione di utenti e programmatori riescono a sopravvivere. Ciò va a
danno degli utenti, che si ritrovano in mano un prodotto non più mantenuto e presto
obsoleto. Le distribuzioni Linux (che possono essere considerate dei progetti open source)
soffrono dello stesso problema.
L’ambito forense non fa eccezione, da questo punto di vista. Nel corso del tempo alcuni ottimi
progetti sono scomparsi, altri sono diventati commerciali (leggi Helix), altri incorporano altre
funzioni (vedi Baktrack). Oggi sono attivi due progetti, peraltro entrambi italiani, che stanno
riscuotendo riconoscimenti un po’ ovunque.
DEFT (http://www.deftlinux.net). È un Live-CD basato su Ubuntu, nato da un’idea di Stefano
Fratepietro. Il prodotto si è evoluto molto rapidamente nel corso del tempo per giungere
fino alla versione 8.0. Funziona sia come una distribuzione Live sia come repository di
programmi che possono essere usati per estrarre dati da un sistema Windows acceso. Dalla
versione 8 è disponibile in più formati, compreso un mini CD con la parte di copia e una
Virtual Appliance in grado di funzionare sotto diversi hypervisor.
CAINE (http://www.caine-live.net). Nato a opera di Giancarlo Giustini, in collaborazione con
l’università di Modena e Reggio Emilia, è ora gestito e sviluppato da Nanni Bassetti e un
team internazionale. L’ultima versione è la 4.0 e si dimostra un sistema stabile e molto
semplice da utilizzare. Al pari di DEFT dispone di una serie di tool avviabili su un sistema
Windows Live (anche se in numero più limitato).
Entrambi i progetti sono molto validi, e conviene sicuramente tenerli entrambi a portata di
mano.

LiveCD
DEFT e CAINE (si veda anche il Capitolo 10) sono, come già accennato, dei sistemi per
l’analisi forense contenuti in un DVD. Il loro utilizzo differisce in base all’utilizzo. Entrambi
dispongono anche di semplici GUI Windows che permettono di utilizzare i binari sicuri
contenuti all’interno. In caso contrario si può effettuare un boot da CD-ROM per ritrovarsi in un
ambiente Linux completo con decine di programmi specializzati per l’analisi forense.
Essi introducono una serie di particolarità destinate al settore specifico.
Interfaccia. Hanno tutti una GUI per proporre un ambiente user-friendly ma che non
richieda grandi quantità di RAM. DEFT parte di default senza interfaccia grafica. Tale
particolarità è utile qualora si vogliano usare solo funzioni base come la copia.
Utilizzo. Tutte queste distribuzioni non utilizzeranno mai un file system o una partizione
come swap, anche se l’utente cerca di forzare tale comportamento. Alcune dispongono di
terminali che “loggano”, per default, ogni comando digitato.
File system. Il kernel è compilato per vedere tutti i file system supportati da Linux,
compresi quelli meno comuni e quelli ormai obsoleti.
Tool. Si è cercato di includere qualunque tool open source per analisi forense sia ora
disponibile. Incorporano anche tool gratuiti non open source come, per esempio, la parte di
acquisizione di Encase o l’ottimo FTK Imager Lite per Windows, la collezione dei tool di
Nirsoft e altri.
Media. Per ora sono disponibili solo in formato DVD. Entrambi sono installabili anche su
una pendrive USB.
Installare una di queste distribuzioni su tutta la propria infrastruttura è un’opzione possibile se
non si vuole sprecare del tempo per creare (e mantenere aggiornato) un proprio repository di
programmi per l’analisi forense. La personalizzazione spinta di queste ha però lo svantaggio di
rendere arduo il lavoro del sistemista che deve costantemente gestire le macchine del
laboratorio.

Distribuzione general purpose

Una possibile alternativa a DEFT o CAINE è una distribuzione Linux general purpose. Un
altro vantaggio considerevole di questa scelta consiste nel poter usare la distribuzione Linux
preferita. Pur derivando da una base comune, ognuna ha delle particolarità specifiche,
specialmente per quanto riguarda installazione, tool di gestione, pacchettizzazione. Passare da
una distribuzione a un’altra può essere, almeno inizialmente, piuttosto frustrante. Tutte queste,
per esempio, possono essere piuttosto pratiche per chi ha sempre utilizzato Ubuntu, ma
decisamente ostiche per utilizzatori provenienti da altre distribuzioni. Specialmente sul lato
server, i vantaggi di una soluzione basata su una distribuzione general purpose sono notevoli.
Nonostante alcune possiedano già, al loro interno, i programmi necessari per creare dei server
SMB o NFS, questi sono stati pensati soprattutto per creare delle condivisioni utili in fase di
acquisizione delle immagini forensi. Creare, per esempio, un PDC Samba con un back-end su
LDAP può essere complesso. Lo stesso dicasi per soluzioni server basate su protocolli avanzati
come OpenAFS. Un buon compromesso potrebbe essere quindi quello di utilizzare DEFT e/o
CAINE sul campo e una soluzione general purpose sulle macchine del laboratorio, creando un
repository di tool forensi basati su quanto contenuto nelle maggiori distribuzioni correnti.

Scegliere la distribuzione
La scelta della distribuzione è solamente una questione di gusto personale. Lasciando perdere
per un attimo le “guerre di religione” che regolarmente si scatenano sui vari forum, si può dire
che le distribuzioni Linux tendano a equivalersi, dato che non esiste un sistema migliore in
assoluto. La regola generale, per chi già ha utilizzato Linux, è quella di scegliere la
distribuzione con la quale si è già lavorato e con la quale si è fatta esperienza. Verrà ridotto così
il tempo di setup e si eviterà di dover reimparare concetti già noti. Chi deve avvicinarsi al
mondo Linux per la prima volta ha invece l’imbarazzo della scelta. Per orientarsi si seguano i
consigli qui elencati.
Usare una distribuzione nota. Per i meccanismi di cui si è già parlato, le distribuzioni
tendono a nascere e a morire con facilità. Se si vuole evitare di ritrovarsi con un sistema
non più aggiornato è bene usare una distribuzione che abbia una certa storia alle spalle.
Fedora, OpenSUSE, Linux Mint, Debian e Ubuntu possono essere valide scelte.
Scegliere una distribuzione facilmente aggiornabile, sia nel suo complesso sia rispetto ai
singoli pacchetti da cui è composta. Si deve poter variare la versione di ogni singolo
programma senza perdere inutilmente tempo. Vanno bene, quindi, le distribuzioni citate
sopra; meno bene, per esempio, Slackware o Gentoo.
Usare una distribuzione che abbia buoni tool di gestione. Lasciando perdere gli hardcore
user, per i quali la massima concessione è l’utilizzo di vi, ci si orienti verso un sistema
corredato di tool che permettano di variare velocemente i parametri di configurazione
senza dover editare a mano svariati file di configurazione. Bene quindi OpenSUSE (YAST
è senz’altro un riferimento per la categoria), Ubuntu, Fedora; decisamente più ostiche
Slackware e Debian.
Supporto. Scegliere una distribuzione nota e con un’ampia base utente permetterà di
ricevere l’aiuto di una nutrita comunità di utilizzatori. Può inoltre essere una valida scelta
quella di usare una distribuzione commerciale. A fronte di una spesa maggiore (sono tutte
licenziate per macchina e soggette a una maintenance), si avrà un supporto di livello
enterprise da aggiungersi a quello fornito dalla comunità degli utenti. Si potrebbe quindi
pensare di usare Red Hat Desktop (la versione commerciale di Fedora) o SUSE Enterprise
Desktop (la versione commerciale di OpenSUSE).
 Capitolo 6

Media, partizioni e volumi

“... Sono collegato via NX Client a una macchina in cloud. Da qui ho aperto una sessione di vSphere verso gli host e dentro
una console di un’altra macchina Windows. Devo piantarla di fare nesting delle connessioni...”

Premessa
Più si affrontano i problemi connessi con la disciplina della Digital Forensics, più ci si rende
conto del fatto che l’evoluzione in questo campo è incessante. Si trovano nuovi modi per
affrontare situazioni note, ma si lotta anche con problemi del tutto nuovi e inaspettati. E quando
si pensa di aver raggiunto un buon livello, ci pensa la tecnologia a piazzarti davanti un nuovo
paradigma che si trasforma nell’ennesimo rompicapo.
Tutto ciò dimostra che non esiste un tool o un metodo che possa adeguarsi a ogni situazione
incontrata. Ci sono programmi che possono adattarsi a un certo numero di casi, ma nulla che
possa essere paragonato alla “valigetta del piccolo Digital Forensics expert”.
Inoltre, come si spiegherà nelle pagine che seguono, spesso si può scoprire che un piccolo
tool da pochi kilobyte, scoperto per caso seguendo chissà quale link, si rivela fondamentale per
la risoluzione di un’indagine, molto più di un programma da svariate migliaia di euro con la
scritta “Forensics” stampigliata a caratteri cubitali su ogni lato della confezione.

Comandi e funzioni Unix

Molti dei comandi e delle funzioni del sistema operativo Unix sembrano scritti appositamente
per il lavoro del Digital Forensics expert. Permettono di gestire le immagini disco, verificarne
il contenuto, lavorarvi a vari livelli, effettuare ricerche sia su file di testo sia su file binari e
molto altro ancora.
In particolare, esamineremo ora le funzioni e i comandi necessari alla manipolazione dei file
di immagine (si parla di “file di immagine” in quanto si ritiene che si sia già fatta la copia del
device fisico secondo quanto esposto nei capitoli precedenti; molti dei concetti qui elencati si
applicano comunque anche a device fisici).

Gestione delle immagini disco

 Si è più volte ribadita l’opportunità di copiare un supporto nella sua interezza: in caso
contrario si potrebbe correre il rischio di tralasciare delle informazioni preziose. Ovviamente
questo assunto richiede che si abbia a che fare con una singola memoria di massa o con un
RAID di dimensione. Per quanto riguarda storage di grandi dimensioni si deve procedere in
maniera differente.
Se si è fatta tale operazione, si possiederà sul proprio sistema un’immagine dd di tutto il
contenuto del sistema acquisito. La prima domanda da porsi è quindi come riuscire a gestire
questo disco in maniera da visualizzarne il contenuto ed effettuare delle ricerche.
Linux ci mette a disposizione una particolare funzionalità, i loop device. In un sistema Unix,
di norma, l’operazione con cui si collega un device a un ramo dell’albero che rappresenta i file
system presenti sul computer è detta “montaggio”, dal nome del comando mount utilizzato.
Nella quasi totalità dei sistemi Unix presenti sul mercato l’operazione di montaggio può
avvenire solamente tra un device fisico e un ramo di un file system. Linux possiede, oltre a
questa funzionalità, i loop device. Con questa feature si può montare un file system presente in
un file di immagine come se fosse un device reale.
I loop device, in effetti, nascono ai tempi del boom dei masterizzatori per CD-R. Tramite
questo sistema era possibile testare un file system ISO 9660, contenuto all’interno di
un’immagine, prima che questa fosse masterizzata sul supporto ottico. L’unica reale limitazione
dei loop device è proprio quella di non consentire l’utilizzo di immagini di interi dischi ma,
piuttosto, quella delle singole partizioni contenute all’interno. Questa limitazione è comunque
facilmente aggirabile. Si noti il seguente esempio:
pila@muscariaII:/mnt/repository/forensi> ls -l
total 39116314
-rw-r--r-- 1 root root 266 2006-11-23 20:52 hda-part.txt
-rw-r--r-- 1 root root 40016019456 2006-11-23 21:17 hdc.img
-rw-r--r-- 1 root root 85 2006-11-23 21:36 hdc.md5
drwxr-xr-x 3 root root 72 2006-11-24 14:59 work
pila@muscariaII:/mnt/repository/forensi>

Il file qui rappresentato è un’immagine di un disco fisso ATA. Si verifichi il contenuto:

muscariaII:/mnt/repository/forensi # fdisk -l ./hdc.img
You must set cylinders.
You can do this from the extra functions menu.

Disk ./hdc.img: 0 MB, 0 bytes

255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

./hdc.img1 * 1 4865 39078081 7 HPFS/NTFS
Partition 1 has different physical/logical endings:
phys=(1023, 254, 63) logical=(4864, 254, 63)
muscariaII:/mnt/repository/forensi #

Tramite il comando fdisk è possibile visualizzare il contenuto del disco. Si noti però che la
geometria del disco appare non corretta. Per correggerla ci si può appoggiare temporaneamente
a un loop device. Si usa il termine “temporaneamente” dato che, come già detto, non è possibile
riuscire a montare direttamente un’immagine di un disco intero:
muscariaII:/mnt/repository/forensi/ # losetup /dev/loop0 hdc.img
muscariaII:/mnt/repository/forensi/ # fdisk -l /dev/loop0

Disk /dev/loop0: 40.0 GB, 40016019456 bytes

255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

/dev/loop0p1 * 1 4865 39078081 7 HPFS/NTFS
muscariaII:/mnt/repository/forensi/ #

Il primo comando (losetup /dev/loop0 hdc.img) collega il file hdc.img al device virtuale /dev/loop0.
Il successivo comando fdisk mostra un output della geometria più corretto rispetto a quello
precedente.
Ora la difficoltà consiste nel capire dove sia esattamente il primo settore della partizione
HPFS/NTFS mostrata sopra. Si provi a ripetere il comando fdisk con un nuovo parametro:
muscariaII:/mnt/repository/forensi # fdisk -l /dev/loop0

Disk /dev/loop0: 40.0 GB, 40016019456 bytes

255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

/dev/loop0p1 * 1 4865 39078081 7 HPFS/NTFS

muscariaII:/mnt/repository/forensi # fdisk -lu /dev/loop0

Disk /dev/loop0: 40.0 GB, 40016019456 bytes

255 heads, 63 sectors/track, 4865 cylinders, total 78156288 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System

/dev/loop0p1 * 63 78156224 39078081 7 HPFS/NTFS
muscariaII:/mnt/repository/forensi #

Si noti la differenza tra i risultati dei due comandi. Il primo esprime la grandezza in cilindri,
il secondo in blocchi fisici da 512 byte sul disco. La partizione non comincia quindi dal primo
settore, ma dal 63°. Praticamente la totalità dei sistemi operativi del pianeta segue la regola di
non utilizzare la traccia 0 del disco fisso. Il sistema provvede quindi a calcolare la lunghezza di
tale traccia e pone il primo blocco della prima partizione all’inizio della traccia 1.
NOTA
La traccia 0 non viene utilizzata perché non è ritenuta affidabile e perché molti dischi la adoperavano in passato
per le operazioni di parking e spin-up. Rimane utilizzabile, in ogni caso, e potrebbe essere utilizzata per stiparvi
dei dati. Se qualcuno dispone di circa 32 KB di materiale scottante potrebbe inserirlo all’interno della traccia 0
con il comando dd if=[nome-file-scottante] of=/dev/[device del disco fisso] skip=1 bs=512 count=61.

Il comando mount accetta la possibilità di specificare un offset da cui partire per il montaggio
del disco, purché sia espresso in byte.
La trasformazione è banale, e si può utilizzare un altro comune tool su Unix, ovvero bc, un
linguaggio completo che permette di effettuare calcoli complessi direttamente dalla riga di
comando. Il suo utilizzo, qui, è banalizzato a semplice calcolatrice_
muscariaII:/mnt/repository/forensi/ # bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type 'warranty'.
63*512
32256
quit
muscariaII:/mnt/repository/forensi/ #

Ottenuto il valore dell’offset in byte (32256) è ora possibile montare l’immagine del disco
direttamente con i loop device come se fosse un’immagine di un singolo file system. Si noti che,
in caso siano presenti più partizioni, il comando può essere ripetuto per montare le singole
partizioni contenute all’interno del file:
muscariaII:/ # mount –o ro,nodev,noexec,noatime,loop,offset=32256 hdc.img /mnt/tmp
muscariaII:/ #

Unix, sempre prodigo di messaggi informativi, non si è lamentato, quindi c’è da ritenere che
abbia compiuto correttamente l’operazione. Si può verificarlo facendo un ls nella directory
dove è stata montata l’immagine:
muscariaII:/mnt/tmp # ls -l
total 787133
dr-x------ 1 root root 12288 2006-09-07 06:44 .
drwxr-xr-x 12 root root 312 2006-09-19 16:55 ..
-r-------- 2 root root 160 2004-04-29 08:24 .espl
-r-------- 1 root root 163 2006-03-28 09:45 AUTOEXEC.BAT
-r-------- 1 root root 0 2002-11-15 09:41 AUTOEXEC.CAM
dr-x------ 1 root root 4096 2006-03-29 10:24 Autronic
-r-------- 1 root root 512 2002-11-15 09:23 BOOTSECT.DOS
dr-x------ 1 root root 0 2006-05-12 09:54 Borland
dr-x------ 1 root root 0 2004-06-03 11:21 CCase
-r-------- 1 root root 0 2002-11-15 09:41 CONFIG.SYS
dr-x------ 1 root root 4096 2005-12-01 17:17 Documents and Settings
dr-x------ 1 root root 0 2005-05-12 09:05 FILES
-r-------- 1 root root 0 2002-11-15 09:41 IO.SYS
dr-x------ 1 root root 36864 2006-05-16 15:48 Lavoro
-r-------- 1 root root 0 2002-11-15 09:41 MSDOS.SYS
dr-x------ 1 root root 0 2005-02-18 09:20 MSOCache
-r-------- 1 root root 47564 2004-08-27 08:13 NTDETECT.COM
dr-x------ 1 root root 49152 2006-09-07 06:28 OfficeScan NT
dr-x------ 1 root root 24576 2006-09-04 10:45 Program Files
dr-x------ 1 root root 4096 2005-06-17 15:23 Programmi
dr-x------ 1 root root 4096 2006-02-27 11:15 Psfonts
dr-x------ 1 root root 4096 2004-07-15 12:50 RECYCLER
dr-x------ 1 root root 4096 2004-08-27 10:38 System Volume Information
dr-x------ 1 root root 4096 2006-06-16 15:41 Temp
dr-x------ 1 root root 4096 2005-11-23 18:59 TempTivoliEpKit
-r-------- 1 root root 149504 1999-06-25 10:55 UNWISE.EXE
dr-x------ 1 root root 90112 2006-09-04 16:31 WINDOWS
-r-------- 1 root root 211 2004-08-27 08:20 boot.ini
-r-------- 1 root root 30 2004-12-23 12:45 dxerror.ini
dr-x------ 1 root root 0 2003-09-03 14:54 etc
-r-------- 2 root root 950 2006-01-13 14:17 installer.txt
dr-x------ 1 root root 4096 2006-09-04 07:44 mvfslogs
-r-------- 1 root root 250032 2004-08-27 08:13 ntldr
dr-x------ 1 root root 0 2001-01-01 19:01 oracle
-r-------- 1 root root 805306368 2006-09-04 09:57 pagefile.sys
dr-x------ 1 root root 0 2003-09-22 17:43 tivcheck
-r-------- 1 root root 21 2005-06-07 07:41 tmuninst.ini
muscariaII:/mnt/tmp #

Il comando mount è stato dato con i seguenti parametri.

ro (read only): forza il montaggio a sola lettura, inibendo le modifiche.
nodev: non interpreta eventuali character o block device presenti sul file system (è utile, in

effetti, solo montando file system Unix).

noexec: inibisce l’esecuzione di qualunque binario presente sul file system.
 noatime: non aggiorna la data di accesso ai singoli file/directory.
loop: specifica al kernel che il primo parametro non è un device ma, piuttosto, un file

immagine, che necessita quindi un loop device libero.

offset=numero: specifica l’offset (scostamento), espresso in byte, dove trovare il primo

blocco del file system che si desidera montare.

Tali parametri dovrebbero essere sempre esplicitati quando si lavora con un’immagine
forense di un disco fisso. Il loro scopo è sia di preservare l’immagine stessa, sia di evitare che
possano essere inavvertitamente lanciati programmi dannosi.
Controllando il valore md5 dell’immagine disco al termine delle operazioni si noterà che non
vi sono state modifiche al file.
Se fossero state presenti più partizioni, si sarebbe ripetuto il comando variando l’offset per le
singole partizioni e il punto di montaggio delle stesse.
NOTA
Non è sempre necessario montare l’immagine per analizzarne il contenuto. Sleuth Kit, Scalpel e Foremost sono
per esempio alcuni dei tool che possono lavorare direttamente sul file immagine senza l’intervento di astrazione
del sistema operativo. Tutto dipende dalle circostanze e da cosa si sta effettivamente cercando.

Qualora servisse, sarebbe comunque possibile spezzare l’immagine disco in varie parti per
semplificarne l’utilizzo o per effettuare l’analisi con sistemi che non possiedono una gestione
così avanzata dei loop device.
In questo caso sarebbe possibile ottenere un file immagine della sola partizione con il
seguente comando:
dd if=hdc.img of=hdc1.img bs=512 skip=63 count=78156161

Il parametro skip= conterrà l’offset di partenza, espresso in blocchi da 512 byte, mentre il
parametro count= conterrà il valore della grandezza in blocchi della partizione. Qui il valore è
determinabile sottraendo dal valore del blocco finale della partizione (come evidenziato prima
da fdisk –lu) il valore del blocco di inizio (qui 78156224 è il valore del blocco di fine partizione al
quale bisogna sottrarre 63, ovvero l’offset di inizio partizione).
Non si finirà mai di ripetere come, lavorando con formati assolutamente “raw”, si possano
effettuare tali operazioni per ricavare, di volta in volta, i formati desiderati. Con sistemi
proprietari queste operazioni spesso non sono possibili. Ora è libera scelta del singolo
utilizzare i tool che più gli aggradano, ma va ricordato di non sacrificare l’opportunità di
apertura verso altri sistemi solo per la comodità d’uso di un unico tool.

Sistemi di partizionamento
Il sistema di partizionamento dei moderni PC (quelli che un tempo erano detti IBM-
compatibili) non è certamente l’unico. Semmai, è uno dei più arcaici e ostici tra quelli
disponibili sul mercato.
Esistono altri metodi per suddividere un disco in partizioni: Mac, sistemi Unix BSD, Irix, e
Solaris usano forme di partizionamento differenti e incompatibili con quelle comunemente usate
nei PC. Linux è in grado di riconoscere, oltre a un vasto numero di file system, anche molti
metodi di partizionamento diversi. Lo stato dell’arte al momento della stampa di questo libro è
il seguente.
Acorn partition scheme. Acorn ha sviluppato una serie di computer basati su processore
RISC e con sistema operativo RISCOS. Nonostante siano sconosciuti in Italia, hanno avuto
un discreto successo nel resto del mondo:
– Cumana: sistema di partizionamento dei computer Acorn che usavano i dischi prodotti da
Cumana (ora Cumana/Canon Computing);
– EESOX: partizionamento di RISCOS per dischi prodotti da EESOX;
– ICS: la variante Acorn dell’interfaccia IDE, da cui il nome di questo schema di
partizioni;
– Native filecore: i computer Archimedes e RISC PC usavano il file system ADFS come
standard. Linux supporta anche questo schema;
– Powertec: schema di partizioni usato per i dischi SCSI di Powertec;
– RISCiX: è stato il primo porting di Unix sulla piattaforma RISC di Acorn computer. Il
suo schema di partizioni è riconosciuto da Linux.
Alpha OSF. La tabella delle partizioni della fortunata serie RISC di Digital, ovvero Alpha,
e del suo Unix ribattezzato ora TRU64.
Amiga. Il sistema di gestione dei dischi del mai troppo compianto Commodore Amiga.
Atari. Lo schema di partizionamento dell’AtariOS, sistema operativo di una fortunata serie
di computer Atari.
Macintosh Partition Table. È il vecchio schema di partizionamento di Mac noto come APM
(Apple Partition Map). Sviluppato con la prima generazione di Mac, è rimasto in voga per
oltre vent’anni prima di essere soppiantato dal nuovo schema introdotto con i Mac Intel.
PC Partition Tables (MBR)
– BSD Disk Label: è una variante del sistema di partizionamento del PC usata per poter
introdurre il concetto di slice tipico dei sistemi Unix BSD. Utilizza ancora il sistema MBR,
ma aggiunge una seconda tabella posta nel primo settore della partizione per la gestione
delle slice.
– Minix Subpartition: simile al precedente, si trova nel noto Unix didattico sviluppato da
Andrew Tannenbaum.
– Solaris X86: utilizza uno schema di partizionamento molto simile alla sua controparte per
SPARC, con solo l’aggiunta del codice necessario per effettuare il boot con il vetusto
BIOS dei PC piuttosto che con l’Open Firmware presente nelle workstation RISC di Sun.
 – Unixware slice: anche in questo caso viene usata una seconda tabella (VTOC) per gestire
il concetto di slice.
Windows Logical Disk Manager: Windows 2000 e Windows XP introducono il concetto di
“disco dinamico”, in opposizione al sistema “disco base” (MBR). Trasformando un disco
base in dinamico viene reso impossibile installare su quel disco qualsiasi altro sistema
operativo ma, per contro, si introduce una notevole serie di migliorie, specialmente nella
gestione dei RAID software.
SGI. Sistema di gestione sviluppato da SGI per il suo IRIX.
Ultrix. Il sistema è sviluppato da DEC (ora Compaq). È una variante di Unix per
piattaforma RISC.
Sun. Il sistema di partizionamento di Solaris, nativo su SPARC.
Karma. Per leggere i dischi del lettore MP3 Rio.
EFI GUID. EFI è lo standard sviluppato da Intel per cercare di superare le limitazioni del
BIOS dei PC. Attualmente è usato solo nell’architettura IA-64 e dai Mac Intel. È anche
usato nei sistemi Linux (32 o 64 bit) che devono gestire partizioni più grandi di 4 TB.
Tutto questo implica ovviamente che Linux è in grado di operare, nativamente e senza tool
applicativi, con supporti magnetici provenienti da una miriade di sistemi diversi anche
antecedenti alla sua comparsa sul mercato. Questo è un evidente vantaggio rispetto a qualunque
altro strumento per analisi forense disponibile su piattaforma Windows. Windows, infatti, è in
grado di leggere solo tre dei sistemi di partizionamento citati sopra; per tutti gli altri il supporto
deve provenire dall’applicazione stessa. Ciò si traduce in due problemi fondamentali.
Sviluppo: il produttore del programma di analisi deve accollarsi tutto l’onere per lo
sviluppo del software di gestione per i dischi provenienti da altre architetture. Questo
comporta, nella maggior parte dei casi, il supporto a un numero di architetture molto più
limitato.
Analisi: demandare l’accesso a un supporto all’applicativo significa poter utilizzare solo
le funzioni fornite da quel programma. Non permette di usare altri tool o comandi di
sistema per effettuare l’analisi. Non è una limitazione ininfluente, in quanto pone confini
ben precisi al campo d’azione del Digital Forensics expert.

MBR: il partizionamento dei PC

Il Master Boot Record è il primo settore di un supporto di memorizzazione. Esso, nel mondo
dei sistemi PC IBM, può contenere il codice che serve per effettuare il boot di un sistema
operativo (loader), lo schema di partizionamento e la marcatura del disco (Tabella 6.1). A
seconda del tipo di medium e del suo utilizzo, l’MBR può contenere solo alcuni di questi
elementi o essere del tutto ignorato dal sistema operativo.
 Tabella 6.1
Indirizzo Descrizione
0x0000 Area per il codice del loader.

0x018A
4 record da 9 byte l’uno per la descrizione delle partizioni primarie (opzionale, estensione di IBM allo
standard).
0x01B8 Marcatura del disco (4 byte).
0x01BE 4 record da 16 byte l’uno per la descrizione delle partizioni (schema standard MBR Partition Table).
0x01FE 2 byte di marcatura dell’MBR (0xAA55).

Il sistema di partizionamento MBR contiene solo le entry necessarie alla definizione di

partizioni primarie o estese. Qualora siano presenti unità logiche all’interno della partizione
estesa o slice BSD, la descrizione di queste sottostrutture è demandata ad apposite entry poste
all’interno del primo settore della partizione stessa. Questo implica che i programmi di
partizionamento (fdisk, cfdisk, parted, Partition Magic e così via) non agiscono solo all’interno
dell’MBR ma possono andare ad alterare anche il contenuto delle singole partizioni. Anche in
questo caso giova ricordare che effettuare una copia integrale del disco consente di estrarre la
struttura senza troppe difficoltà. Le entry contenute nella partition table sono strutturate secondo
lo schema della Tabella 6.2.
Tabella 6.2
Offset Descrizione
0x00 Stato (0x80 = bootable, 0x00 = non bootable, altri valori in dipendenza da boot manager diversi).

0x01
Primo settore secondo la sintassi CHS (se tale indirizzo supera i limiti di questo schema di geometria si
troverà il valore 1024,16,63).
0x04 Tipo di partizione.

0x05
Ultimo settore secondo la sintassi CHS (se tale indirizzo supera i limiti di questo schema di geometria si
troverà il valore 1024,16,63).
0x08 (4 byte) Indirizzo del primo settore secondo la sintassi LBA.
0x0C (4 byte) Indirizzo dell’ultimo settore secondo la sintassi LBA.

IBM, con l’introduzione di OS/2, sfruttò una parte dell’MBR per potervi collocare una
descrizione relativa alle partizioni da porsi nel menu generato dal boot manager del sistema
(Tabella 6.3).
Tabella 6.3
Offset Descrizione
0x00 Bit di stato (0 = compare nel menu di boot manager, 1 = non compare).
0x01 Label della partizione nel menu.

Come si nota, lo spazio a disposizione è veramente limitato. Ciò ha portato i programmatori,

nel corso del tempo, a inventarsi i metodi più fantasiosi per riuscire ad aggirare tali restrizioni.
Grub, per esempio, pone gran parte del suo codice tra la fine dell’MBR e l’inizio della prima
partizione (ovvero tra il 2° e il 62° settore). Solitamente tale spazio rimane vuoto e potrebbe
perciò essere un buon posto dove nascondere piccole ma vitali informazioni.
Come già anticipato, la descrizione delle unità logiche, così come delle slice dei sistemi
BSD, sono collocate nei primi blocchi delle partizioni descritte nella partition table, ovvero
fuori dall’MBR. La stessa cosa dicasi per la gestione dei dischi dinamici di Windows e per la
gestione dei RAID software di Linux.
Tutto questo significa sostanzialmente che anche un’architettura banale come questa può
presentare moltissime variazioni. Non è quindi il caso di dare per scontato ciò che ci si presenta
dinnanzi, poiché ci si potrebbe ingannare. Nel prosieguo sarà approfondito questo concetto.

APM: il partizionamento delle prime due generazioni di Mac

Apple, per il proprio Mac, ha potuto sviluppare un’architettura completamente nuova,
imparando dagli errori commessi da IBM per il suo PC e potendo scrivere tutto da zero, senza
doversi preoccupare della compatibilità con il passato.
Il risultato è stato uno schema di partizionamento piuttosto funzionale che ha resistito
vent’anni senza necessità di cambiamenti radicali. Per fare un esempio, Apple, con il passaggio
all’architettura Intel, ha deciso di adottare un nuovo metodo per la gestione dei dischi perché gli
ingegneri erano per il limite di 2 TB per la grandezza massima dei dischi usabili con il Mac. Il
confronto già solo con il sistema di CHS di MBR (120 GB indirizzabili) fa chiaramente capire
la differenza tra un buon progetto e uno abbozzato.
Una prima sostanziale differenza tra APM e MBR è il fatto che lo schema di partizionamento
di Apple non contiene alcun codice. Il boot non viene eseguito come nei PC, dove il BIOS
esegue pedissequamente quanto trova nei primi byte dell’MBR. Il firmware del Mac è in grado
di interpretare le singole entry della struttura contenuta nell’APM e di trovare autonomamente
qual è la partizione contenente il sistema operativo.
La partition table si trova all’inizio del disco, in particolare è scritta dal 2° settore di 512
byte dall’inizio del disco. Ciò rende possibile, per esempio, la coesistenza di una partition table
MBR e di una APM, dato che la seconda comincia esattamente dove la prima finisce.
Una nota in merito: spesso capita di acquistare un disco fisso esterno preformattato in FAT o
NTFS. Se questo viene collegato a un Mac (Intel o PowerPC che sia) e riformattato in HFS+ (o
una delle sue varianti), il computer scriverà una nuova partition table APM nel settore 1. L’MBR
nel settore 0 sarà ignorato. Non ci si deve far trarre in inganno, quindi, vedendo una partizione
MBR che non corrisponde al file system usato.
La partition table APM si compone di una serie di entry che definiscono le singole partizioni.
Si noti che la stessa tabella delle partizioni è descritta come una partizione all’interno
dell’APM.
Il contenuto di ogni singola entry è mostrato nella Tabella 6.4.
Tabella 6.4
 Byte occupati Descrizione Obbligatorio
0-1 Marcatura con valore fisso (0x504D). No
2-3 Riservato (impostato a 0). No
4-7 Numero totale delle entry nella partition table. Sì
8-11 Settore di partenza della partizione. Sì
12-15 Grandezza della partizione espressa in blocchi da 512 byte. Sì
16-47 Nome della partizione. No
48-79 Tipo della partizione (stringa). No
80-83 Offset dell’inizio del file system nella partizione. No
84-87 Grandezza del file system (data area) espresso in blocchi da 512 byte. No
88-91 Stato della partizione (codice esadecimale). No
92-95 Settore di partenza del codice per il boot. No
96-99 Grandezza del codice di boot espresso in blocchi da 512 byte. No
100-103 Specifica l’indirizzo di memoria dove deve essere caricato il codice di boot. No
104-107 Riservato. No
108-111 Entry point del codice di boot. No
112-115 Riservato. No
116-119 Checksum del codice di boot. No
120-135 Tipo di processore. No
146-511 Riservato. No

NOTA
Si può immediatamente notare come molto del seppur esiguo spazio sia sfruttabile senza alterare il
funzionamento della tabella di partizionamento del Mac. È quindi possibile introdurre sia fake entry, sia fake data
per nascondere codice o stringhe nella partition table.

Alcuni dei tipi definiti da Apple sono riportati nella Tabella 6.5.
Tabella 6.5
Tipo Descrizione
Apple_partition_map Entry per la descrizione della partition table stessa.
Apple_Driver Partizione contenente un device driver.
Apple_Driver43 Partizione contenente uno SCSI Manager 4.3.
Apple_Driver_ATA Partizione con device driver per dischi ATA.
Apple_MFS File system MFS.
Apple_HFS File system HFS (o una delle sue varianti).
Apple_Unix_SVR2 File system Unix BSD (UFS).
Apple_PRODOS File system PRODOS.
Apple_Free Partizione non utilizzata.
Apple_Scratch Partizione vuota.

Tutti i tipi che iniziano con Apple_ sono riservati dalla casa di Cupertino. Altri tipi possono
essere generati per gestire prodotti di terze parti o file system di diversi sistemi operativi.
 Si osservi che un tipico disco Mac può contenere diverse entry nella partition table anche se
in effetti utilizza una sola partizione di tipo HFS. Il numero di tali entry dipende da molte
variabili quali, per esempio, la release di Mac OS che ha creato la partition table, il tipo di
disco fisso, la presenza del sistema operativo, l’utilizzo in ambiente Classic e altro.
Tutto questo implica che la composizione di una partition table Mac non può essere
predeterminabile a priori.
Un esperto potrebbe quindi crearsi delle entry ad hoc per nascondervi le proprie
informazioni in varie partizioni non immediatamente visibili e camuffate come partizioni, per
esempio, tipo Apple_Driver. Sarebbe inoltre possibile, sebbene un po’ macchinoso, creare un disco
con entrambi i tipi di partition table (MBR e APM), visto che queste risiedono su due diversi
blocchi. In questo modo un PC potrebbe vedere una porzione di disco (o un disco vuoto) e un
Mac un file system HFS+. Si immagini per esempio di definire una entry MBR con una
partizione grande come tutto il disco e di tipo 0x82, ovvero Linux swap, e poi di definire una
partition table APM con una entry di tipo HFS. A un occhio poco attento (o esaminando il disco
con un tool capace di interpretare solo il formato MBR) potrebbe sembrare un banale disco di
swap appartenente a un grosso sistema Linux. Serve quindi un accurato controllo se si vuole
evitare di tralasciare importanti elementi.

GUID Partition Table

Il BIOS dei PC x86-compatibili è probabilmente il più vetusto dei componenti (hardware e
software) ancora in circolazione. Le sue funzioni sono ridicolmente limitate rispetto ai firmware
presenti sulle moderne workstation RISC. Intel, conscia di questo, ha approfittato dell’uscita
dell’architettura IA-64 (da non confondersi con x86_64) per lavorare su qualcosa di simile per
l’ambiente Intel. Il risultato di tale lavoro prende il nome di EFI (Extensible Firmware
Interface).
Partito in sordina, ora è decisamente diffuso in quanto è lo schema di default non solo di
Apple su piattaforma Intel, ma anche di tutti i Windows a 64 bit.
La svolta, probabilmente, è avvenuta nel gennaio del 2006 quando Apple Computer, costretta
suo malgrado all’abbandono dell’architettura PowerPC, ha scelto EFI come firmware standard
per la sua nuova linea di Mac basati su piattaforma Intel (in effetti era l’unica scelta nel mondo
Intel che potesse fornire funzioni simili all’Open Firmware della piattaforma PowerPC).
Nelle specifiche generali UEFI (Unified EFI) Intel ha introdotto un nuovo sistema di
partizionamento, noto come GPT (GUID Partition Table). Apple, alle prese con il limite dei 2
TB del sistema APM, ha deciso di utilizzare questo nuovo sistema di partizionamento per i Mac
Intel anche per poter usare un firmware EFI non modificato per il boot di OS X. Si noti infatti
che i nuovi Mac Intel, pur supportando sia APM sia GPT (oltre al vecchio MBR), possono
effettuare boot solo da dischi partizionati tramite GPT.
 GPT è un sistema di partizionamento moderno, aperto, e decisamente più duttile di MBR. I
vantaggi che offre sono molteplici.
Interoperabilità con EFI. Il firmware stesso è in grado di interpretare la struttura della
partition table e di avviare più sistemi operativi diversi. Non è più necessario utilizzare un
codice esterno come loader.
Ridondanza. Le parti più importanti di GPT (l’header e la partition table) sono scritte sia
all’inizio sia alla fine del supporto.
Controllo di ridondanza ciclico. Un valore di CRC è scritto nell’header della partition
table. EFI è in grado di calcolare e confrontare tale valore. Se l’header del GPT o la
partition table non risulta coerente con il valore di CRC prenderà in automatico la seconda
copia presente alla fine del disco e ripristinerà quanto posto all’inizio del disco. Tale
funzione limita ovviamente l’utilizzo di editor esadecimali per la modifica a basso livello
delle entry della partition table.
Utilizzo di LBA. Senza costringere a impazzire con l’uso e la conversione di due diversi
tipi di geometrie, GPT abbandona CHS in luogo di puntatori LBA a 64 bit.
La struttura di GPT è la seguente.
Legacy MBR. I primi 512 byte sono ignorati da EFI (compreso l’eventuale codice
residente). In questa posizione è posto un MBR standard con la definizione di un’unica
partizione di tipo 0xEE. Tale struttura è necessaria per evitare che utility di gestione non in
grado di leggere le strutture GPT segnalino erroneamente un disco vuoto:
root@Virtual:~# fdisk -lu /dev/sdb

Disk /dev/sdb: 60.0 GB, 60011642880 bytes

255 heads, 63 sectors/track, 7296 cylinders, total 117210240 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System

/dev/sdb1 1 117210232 58605116 ee EFI GPT
root@Virtual:~#

Header della partition table. È posizionato sul secondo settore (LBA 1) del disco. Contiene
i campi della Tabella 6.6.
Tabella di descrizione delle partizioni. Contiene le entry di descrizione delle singole
partizioni. La struttura è quella della Tabella 6.7.
Tabella 6.6 Header della partition table
Lunghezza
Nome Offset Descrizione
in byte
Identifica univocamente una partition table tipo GPT. Questo
Signature 0 8 valore deve contenere sempre la stringa “EFI PART”
(0x5452415020494645).
Numero di versione dell’header. Al momento l’unico valore
Revision 8 4
ammesso è “1.0” (0x00010000).
 Grandezza dell’header della partition table (in byte). La
HeaderSize 12 4 grandezza deve essere maggiore di 92 e minore della
grandezza logica di un blocco.
CRC dell’header. In caso di discrepanza EFI provvede a
HeaderCRC32 16 4
ricopiare l’header di riserva posto in fondo al disco.
Reserved 20 4 Deve essere a zero.
Entry point dell’header (nella quasi totalità dei casi coincide con
MyLBA 24 8
il blocco LBA 1).
Alternate LBA 32 8 Indirizzo dell’header di backup posto in fondo al disco.
Primo blocco LBA disponibile per essere utilizzato da una
First UsableLBA 40 8
partizione.
LastUsableLBA 48 8 Ultimo blocco LBA usabile per le partizioni.
DiskGUID 56 16 Identificatore GUID univoco per il disco.
PartitionentryLBA 72 8 Entry point della tabella di descrizione delle partizioni.
Numero massimo di righe della tabella di descrizione delle
NumberOfPartitionEntries 80 4
partizioni.
Grandezza, in byte, dei record che compongono la tabella di
SizeofPartitionEntry 84 4
descrizione delle partizioni.
Checksum della tabella di descrizione delle partizioni. Il suo
PartitionEntryArrayCRC32 88 4
utilizzo è analogo al CRC dell’header.
Grandezza
Riservato 92 del blocco - Padding di zeri.
92

Tabella 6.7 Descrizione delle partizioni

Nome Offset Lunghezza in byte Descrizione
Identificatore univoco del tipo di partizione. Se è pari a zero
PartitionTypeGUID 0 16
la partizione non è usata.
UniquePartitionGUID 16 16 Identificatore univoco della partizione.
StartingLBA 32 8 Blocco LBA di inizio della partizione.
EndingLBA 40 8 Blocco LBA finale della partizione.
Attributes 48 8 Attributi come definiti dalle specifiche UEFI.
Partition Name 56 72 Nome della partizione in formato Unicode.
Grandezza della
Riservato 128 Padding di zeri.
partizione -72

Linux ha da sempre un supporto completo al sistema GPT. Anche se fdisk è stato prima
ingannato, altri programmi più avanzati sono in grado di interpretare correttamente i dati
contenuti nella partition table GPT, così come sono gestiti dal kernel.
Di seguito è mostrato un esempio di un disco esterno nuovo inizializzato da un MacBook con
sistema operativo OS X 10.7.6, visto con una macchina Linux e il software parted:
root@Virtual:~# parted /dev/sdb
GNU Parted 1.7.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Disk /dev/sdb: 60.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags

1 20.5kB 210MB 210MB fat32 primary boot
2 210MB 59.9GB 59.7GB hfs+ primary

(parted)

può essere utilizzato anche con le immagini per esaminarne la partition table. Al
parted

momento attuale è il più avanzato software di partizionamento disponibile in ambito Unix, ed è

in grado di interpretare e operare con MBR, APM, BSD disklabel e GPT.

BSD disklabel
I sistemi Unix della famiglia BSD (FreeBSD, OpenBSD, NetBSD, Solaris per X86) sono stati
tra i primi a sviluppare dei metodi per aggirare gli stringenti limiti del sistema di
partizionamento MBR.
Tradizionalmente, la disklabel si collocherebbe nel primo settore dell’hard disk. Questo però
imporrebbe l’utilizzo del computer solo con sistemi Unix BSD (la stessa cosa accade quando si
cambia da disco base a disco dinamico con i moderni sistemi Windows). Per ovviare a tale
inconveniente i sistemi BSD utilizzano una partizione primaria (o estesa che sia) MBR, che
prende il nome di slice, e la suddividono in partizioni tramite la disklabel che viene scritta sul
primo settore della partizione. Il meccanismo è del tutto analogo a quanto accade, in ambito PC,
per le partizioni estese e le unità logiche.
A livello di disk label è bene ricordare che:
ogni slice può essere divisa al massimo in 16 partizioni: queste sono identificate dalle
lettere da “a” a “p”;
esistono delle lettere “riservate”: solitamente la partizione marcata “c” non è disponibile e
rappresenta l’intero disco fisso;
la partizione “b” è comunemente riservata allo swap;
la partizione “a” è quella usata per il boot.
Un’immagine contenente delle BSD disklabel può essere esaminata con GNU parted per
verificarne la struttura.

Il mondo non è mai semplice

Come si è più volte accennato in questo capitolo, viste le limitazioni degli attuali sistemi di
partizionamento si sono studiati metodi diversi per migliorare le caratteristiche dei sistemi pur
mantenendo una certa compatibilità con il passato. Senza parlare di ZFS, vi sono metodi che
dobbiamo esaminare per fornire una panoramica completa. Essi sono:
 Linux LVM;
Linux Software Raid;
Windows Dynamic Disk e Software Raid.

Linux LVM
LVM sta ovviamente per Logical Volume Manager ed è un sistema per migliorare la gestione
del sottosistema dischi rispetto a un approccio più tradizionale a dischi e partizioni. Si noti che
LVM non sostituisce le tradizionali partizioni ma inserisce un ulteriore livello tra i dischi fisici
e i file system, al fine di mascherare l’hardware.
LVM non solo è usato di default su Fedora e molte altre distribuzioni, ma è la base che
troviamo su tutti gli hypervisor KVM che sfruttano le sue funzioni di snapshot per salvare lo
stato delle virtual machine sovrastanti.
Il sottosistema LVM di Linux è un adattamento di quello presente su HP-UX, dal quale mutua
anche la sintassi dei comandi principali.
LVM si basa su una serie di concetti, illustrati di seguito, che spingono sempre più in alto il
livello di astrazione.
Physical Volume (PV). Equivale a delle partizioni su uno o più dischi fisici (tipo 0x8e). Di
solito si trova una partizione grande come tutto il disco, tranne in alcuni casi ove è presente
una partizione di swap o di boot non gestita tramite LVM (la gestione di un boot disk LVM
non è proprio banale).
Volume Group (VG). Il Volume Group è un raggruppamento di più PV in una sola entità. Si
pensi al Volume Group come a un disco virtuale (estensibile) la cui grandezza è la
sommatoria di quella dei PV associati. Il contenuto del VG sarà diviso in più Physical
Extent (la cui grandezza è determinata in fase di creazione del VG) che saranno salvate,
secondo un algoritmo predeterminato, su tutti i PV assegnati.
Logical Volume (LV). I Logical Volume sono accomunabili alle partizioni dei dischi. Ogni
VG è divisibile in uno o più Logical Volume dentro ai quali saranno poi creati i file system
veri e propri. I Logical Volume sono espandibili ad libitum o almeno finché non si
esaurisce lo spazio allocato al VG che li contiene. Sono suddivisi in Logical Extent (LE)
che sono direttamente mappate sui PE del VG cui appartengono.
I vantaggi di questa soluzione sono i seguenti.
Isolamento dall’hardware: un VG può essere composto da dischi singoli (anche con
tecnologia mista, SCSI/IDE/SATA/SAS...), RAID hardware, RAID software o un qualsiasi
mix di questi.
 Facilità di gestione: sia i VG sia gli LV possono essere espansi a caldo e senza alcun
reboot della macchina. Utilizzando un file system con le corrette caratteristiche si può
effettuare l’espansione del file system contenuto nel LV anche se lo stesso è montato e in
uso agli utenti.
Gestione degli snapshot: è possibile “congelare” un LV effettuando una sua copia a un dato
momento. Tali snapshot hanno vari utilizzi, sia per la gestione del versionamento dei file
sia per risolvere problematiche di backup.
Dal punto di vista del Digital Forensics expert, trovare un sistema basato su LVM complica
non poco le cose. In primis, trovando un disco con una partizione di tipo 0x8e è necessario
accertarsi che non faccia parte di un pool di dischi assegnati a un VG. In questo caso la quantità
di informazioni recuperabili sarà forzatamente limitata in quanto il sistema, normalmente, tende
a distribuire i PE in round robin su tutti i dischi presenti. Pertanto, disponendo di un solo disco
facente parte di un pool, al massimo sarà possibile recuperare frammenti (PE) di file system
delle dimensioni di 4 MB, se è stato lasciato il valore di default per le dimensioni del PE.
Inutile dire che in mancanza di un pool completo di dischi tutto il lavoro di estrazione dovrà
essere eseguito manualmente, forse con un minimo di aiuto da parte di un file carver.
Se il pool di dischi di un VG è completo (o se è stato usato un solo disco), si potrà recuperare
la struttura dell’intero VG con le utility fornite con LVM2. A tal fine si dovrà disporre di una
macchina di analisi Linux con il supporto LVM2 compilato nel kernel (la quasi totalità delle
distribuzioni moderne dispone già di LVM) e le utility di gestione, oppure di un pacchetto di
analisi commerciale.
Uno dei vantaggi di LVM rispetto a soluzioni analoghe è di non disporre di file di
configurazione. Tutta la descrizione della struttura risiede all’interno del VG stesso. Sotto Linux,
quindi, è sufficiente utilizzare un comando vgscan --mknodes per poter attivare (e creare) i
necessari device sotto /dev.
lvscan e lvdisplay permetteranno di esaminare la struttura dei LV.

Linux Software RAID

Linux dispone da anni del supporto per la creazione e gestione di RAID software. Dato che il
sottosistema RAID è particolarmente performante e affidabile, è ormai estesamente utilizzato in
varie realtà (non ultimi i nostri laboratori, in cui tutti i server sono basati su RAID software di
Linux).
Il RAID software supporta al momento RAID di tipo 0 (stripe), 1 (mirror), 4 (stripe with
parity), 5 (stripe with distributed parity) e 6 (stripe with double distributed parity).
Per creare un RAID software occorre innanzitutto creare delle partizioni di tipo RAID
software (0xfd) sui dischi fisici presenti nel sistema. Al contrario di un RAID hardware, che si
basa sui device fisici, un RAID software viene creato tra partizioni dei vari device.
Tutto quanto concerne la creazione e la manutenzione dei RAID sotto Linux avviene tramite la
suite di comando mdadm.
Come accadde per LVM, le prime versioni del modulo di Linux per la gestione del software
RAID (md) si basavano su un file di descrizione del RAID stesso contenuto nella directory etc il
cui nome era raidtab. Questo comportava dei problemi di portabilità dell’array, oltre a
complicare notevolmente le cose nel caso si desiderasse tenere il boot disk su RAID. Ora la
descrizione dell’array, il suo stato e la sua composizione sono contenuti all’interno del RAID
stesso, nei primi settori di ogni singola partizione. In questo modo è possibile riuscire a
ricostruire piuttosto agevolmente i RAID software di Linux (anche in caso di array degradati o
con dischi mancanti, chiaramente in relazione al tipo di parità adottata) anche su workstation che
non sono la macchina originale.
Utilizzando con una certa perizia i loop device si può lavorare direttamente sulle immagini
dei dischi del RAID originale senza essere costretti a clonarli su supporti fisici.
Nonostante i RAID software di Linux siano estesamente utilizzati e ben documentati, i
software commerciali di analisi forense hanno ancora dei problemi non indifferenti
nell’analizzarli.
Encase permette la ricostruzione di RAID hardware e software inserendo i parametri di
descrizione, come il tipo di RAID, la grandezza degli stripe e il tipo di algoritmo utilizzato per
la parità, ma purtroppo non supporta ancora tutti gli algoritmi usati da md. Si hanno perciò buone
possibilità per RAID creati su sistemi più datati, ma il software potrebbe non essere in grado di
lavorare sugli array più moderni. Ad ogni modo, il livello di supporto fornito all’investigatore è
assolutamente inferiore a quello fornito per i RAID software di Windows, dove Encase è in
grado di effettuare la quasi totalità delle operazioni in modo autonomo e automatico.
X-Ways Forensics si distingue, anche in questo caso, per avere un supporto completo. Ci si
scordi wizard o automatismi di alcun genere (non rientrano nella filosofia del programma), ma
tutti gli algoritmi usati da Linux sono pienamente supportati.
Si noti che non è assolutamente un caso raro trovare delle configurazioni Linux ove vi sia un
software RAID usato come PV di un VG. Questa configurazione può rivelarsi decisamente
complessa da analizzare, specie se si utilizzano, come detto, software commerciali.

Windows Dynamic Disk (LDM) e software RAID

Anche in Microsoft hanno provato a superare i problemi relativi al vetusto sistema MBR. Con
l’uscita di Windows 2000 è stato lanciato LDM, ovvero Dynamic Disk.
Il principio di funzionamento è piuttosto semplice. Come GPT, LDM usa un fake MBR che
segnala la presenza di LDM con l’indicazione dell’esistenza di una sola partizione di tipo 0x42.
La vera partition table è un file Jet Engine (sì, il database di Access) posto nell’ultimo megabyte
del disco fisico. LDM è assolutamente d’obbligo se si vogliono utilizzare stripe volume, RAID
software o qualunque feature avanzata della gestione dei dischi di Windows.
I limiti di LDM sono molto alti. È possibile creare fino a 2000 partizioni, la cui grandezza è
limitata solo dalla dimensione del disco fisico. Vista (e quindi 2008 Server) ha introdotto una
nuova versione di LDM basata su GPT. Il risultato è un ibrido dei due sistemi il cui
funzionamento è quantomeno particolare (in effetti, a livello di logica, LDM non ha più senso di
esistere dal momento che GPT incorpora tutte le funzioni per il quale LDM è stato creato).
La versione di LDM con fake MBR è pienamente supportata sia dai sistemi di analisi open
source sia da quelli commerciali. Su Linux è necessario che il kernel sia compilato con il
supporto Windows Dynamic Disk. Per l’analisi delle partizioni può essere usato o parted oppure
i tool prelevabili dal sito del progetto linux-ntfs.
NOTA
Si tenga conto che, al contrario di quanto afferma Microsoft, Linux può essere installato e avviato (purché il
loader sia LILO) anche da partizioni LDM. Quindi, in presenza di dischi dinamici, la presenza non è da
escludere a priori.

In presenza di stripe o RAID software, Linux caricherà in automatico il proprio modulo md con
il quale sarà in grado di interpretare e ricostruire i RAID software di Windows.
Non vi sono perciò difficoltà particolari nell’analisi di sistemi con LDM da parte di sistemi
di analisi open source.
LDM e i RAID software di Windows, al contrario di quanto accade per le loro controparti di
Linux, sono pienamente supportati sia da Encase sia da X-Ways Forensics, quindi ci si può
avvalere senza patemi d’animo anche di pacchetti commerciali.

Analisi preliminare
Esistono milioni di modi per nascondere dei file all’interno di un hard disk. Anche con
sistemi piuttosto biechi si possono raggiungere discreti risultati. Si noti l’esempio seguente.
Si collega un disco esterno a un sistema Linux. Il kernel, nel file /var/log/messages, evidenzia:
Dec 16 15:46:06 Virtual kernel: [17195537.528000] usb 5-7: USB disconnect, address 6
Dec 16 15:46:22 Virtual kernel: [17195554.148000] usb 5-8: new high speed USB device
using ehci_hcd and address 7
Dec 16 15:46:22 Virtual kernel: [17195554.280000] usb 5-8: configuration #1 chosen
from 1 choice
Dec 16 15:46:22 Virtual kernel: [17195554.280000] scsi6 : SCSI emulation for USB
Mass Storage devices
Dec 16 15:46:27 Virtual kernel: [17195559.280000] Vendor: ST96812A Model:
5PJ2SNBG Rev:
Dec 16 15:46:27 Virtual kernel: [17195559.280000] Type: Direct-Access
ANSI SCSI revision: 02
Dec 16 15:46:27 Virtual kernel: [17195559.284000] SCSI device sdc: 117210240 512-byte
hdwr sectors (60012 MB)
Dec 16 15:46:27 Virtual kernel: [17195559.284000] sdc: Write Protect is off
Dec 16 15:46:27 Virtual kernel: [17195559.284000] SCSI device sdc: 117210240 512-byte
hdwr sectors (60012 MB)
Dec 16 15:46:27 Virtual kernel: [17195559.284000] sdc: Write Protect is off
Dec 16 15:46:27 Virtual kernel: [17195559.284000] sdc: sdc1
Dec 16 15:46:27 Virtual kernel: [17195559.312000] sd 6:0:0:0: Attached scsi disk sdc
Dec 16 15:46:27 Virtual kernel: [17195559.312000] sd 6:0:0:0: Attached scsi generic
sg3 type 0

Il disco collegato viene riconosciuto come /dev/sdc, e appare come contenente una partizione
denominata /dev/sdc1. Esaminandola si nota:
root@Virtual:~# fdisk -lu /dev/sdc

Disk /dev/sdc: 60.0 GB, 60011642880 bytes

64 heads, 32 sectors/track, 57231 cylinders, total 117210240 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System

/dev/sdc1 1313 33402527 16700607+ 83 Linux
root@Virtual:~#

La partizione non occupa tutto il disco (cilindri dal 1313 al 33402527) ed è di tipo Linux swap.
Esaminando i primi cilindri del disco si nota:
root@Virtual:~# dd if=/dev/sdc1 of=sdc1-part.img bs=512 count=10
10+0 records in
10+0 records out
5120 bytes (5.1 kB) copied, 0.02023 seconds, 253 kB/s
root@Virtual:~# hexedit sdc1-part.img
<SNIP>
00000FD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000FE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000FF0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 ......SWAPSPACE2
00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00001010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00001020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
<SNIP>

Quello contenuto è sicuramente uno swap space di Linux. Si potrebbe anche provare a
utilizzarlo.
ATTENZIONE
In ambito di analisi forense un comportamento di questo genere è suicida, dato che si va ad alterare la prova.
Quella qui illustrata è solo una dimostrazione del corretto funzionamento della partizione di swap rinvenuta nel
disco.

root@Virtual:~# cat /proc/swaps

root@Virtual:~#
root@Virtual:~# swapon /dev/sdc1
root@Virtual:~# cat /proc/swaps
Filename
Priority Type Size Used
/dev/sdc1 partition 16700596 0 -2

Si colleghi ora questo disco a un sistema Mac. Da un terminale di OS X si userà il

programma a riga di comando per vedere le partizioni di tipo APM:
Curaro-IV:~ pila$ pdisk /dev/rdisk3
Edit /dev/rdisk3 -
Command (? for help): p

Partition map (with 512 byte blocks) on '/dev/rdisk3'

#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Apple_Driver43 Macintosh 56 @ 64
3: Apple_Driver43 Macintosh 56 @ 120
4: Apple_Driver_ATA Macintosh 56 @ 176
5: Apple_Driver_ATA Macintosh 56 @ 232
6: Apple_FWDriver Macintosh 512 @ 288
7: Apple_Driver_IOKit Macintosh 512 @ 800
8: Apple_Patches Patch Partition 512 @ 1312
 9: Apple_Free 33402528 @ 1824 ( 15.9G )
10: Apple_HFS Apple_HFS_Untitled_1 83805872 @ 33404352 ( 40.0G )
11: Apple_Free 16 @ 117210224

Device block size=512, Number of Blocks=0 (0.0 )

DeviceType=0x0, DeviceId=0x0

Il Finder del Mac identifica correttamente lo schema APM e monta in automatico la partizione
HFS).
Si è già sottolineato in precedenza il fatto che il metodo utilizzato dà adito a molti sospetti (il
range della partizione di swap che non copre l’intero disco, per esempio). È però significativo
che ogni sistema operativo veda quello che gli è maggiormente congeniale ignorando dati che
per l’indagine potrebbero essere fondamentali (Linux ignora la partition table APM, OS X
ignora l’MBR tipicamente PC).
Se la partizione MBR fosse stata grande come l’intero disco, non avrebbe destato sospetti.
Ovviamente l’analisi con un editor esadecimale avrebbe rivelato che non si trattava di un’area
di swap e il suo uso avrebbe potuto distruggere la partizione HFS, ma un esame poco attento
avrebbe potuto sorvolare su tale medium.
Si rifletta su quest’ultimo esempio. Si collega un disco esterno a una macchina Linux:
root@Virtual:~# fdisk -lu /dev/sdc

Disk /dev/sdc: 60.0 GB, 60011642880 bytes

64 heads, 32 sectors/track, 57231 cylinders, total 117210240 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System

/dev/sdc1 32 117209087 58604528 83 Linux
root@Virtual:~#

È presente un’unica partizione grande come tutto il disco fisso, di tipo Linux. Si prova a
controllare il tipo di file system presente. Ipotizziamo di avere fortuna:
root@Virtual:~# debugreiserfs -d /dev/sdc1
debugreiserfs 3.6.19 (2003 www.namesys.com)
Filesystem state: consistent

Reiserfs super block in block 16 on 0x821 of format 3.6 with standard journal
Count of blocks on the device: 14651120
Number of bitmaps: 448
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 14642461
Root block: 8211
Filesystem is clean
Tree height: 2
Hash function used to sort names: "r5"
Objectid map size 2, max 972
Journal parameters:
Device [0x0]
Magic [0x4f030145]
Size 8193 blocks (including 1 for journal header) (first block 18)
Max transaction length 1024 blocks
Max batch size 900 blocks
Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x0:
sb_version: 2
inode generation number: 0
UUID: 66e93464-3c81-4051-86e8-8a62759a67bc
LABEL:
Set flags in SB:
ATTRIBUTES CLEAN
===================================================================
LEAF NODE (8211) contains level=1, nr_items=2, free_space=3932 rdkey (real items 2)
-------------------------------------------------------------------------------
|###|type|ilen|f/sp| loc|fmt|fsck| key |
| | | |e/cn| | |need| |
-------------------------------------------------------------------------------
| 0|1 2 0x0 SD (0), len 44, location 4052 entry count 0, fsck need 0, format new|
(NEW SD), mode drwxr-xr-x, size 48, nlink 3, mtime 16/2006 16:24:14 blocks 1, uid 0
-------------------------------------------------------------------------------
| 1|1 2 0x1 DIR (3), len 48, location 4004 entry count 2, fsck need 0, format old|
###: Name length Object key Hash Gen number
0: ". "( 1) [1 2] 0 1, loc 40, state 4 not set
1: ".. "( 2) [0 1] 0 2, loc 32, state 4 not set
===================================================================
The internal reiserfs tree has:
0 internal + 1 leaves + 0 unformatted nodes = 1 blocks
root@Virtual:~#

ci conferma la presenza di un file system reiser. Ora sarà utilizzato un editor

debugreiserfs

esadecimale per verificare il contenuto del disco fisso:

root@Virtual:~# hexedit /dev/sdc
<SNIP>
000001A4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
000001B8 00 00 00 00 00 00 00 01 01 00 83 3F E0 FF 20 00 00 00 E0 77 ...........?.. ....w
000001CC FC 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
000001F4 00 00 00 00 00 00 00 00 00 00 55 AA 51 75 65 73 74 6F 20 C3 ..........U.Questo
.00000208 A8 20 75 6E 20 74 65 73 74 6F 20 63 68 65 20 70 61 72 74 65 . un testo che parte
0000021C 20 64 61 6C 20 74 65 72 6D 69 6E 65 20 64 65 6C 6C 61 20 70 dal termine della
00000230 61 72 74 69 74 69 6F 6E 20 74 61 62 6C 65 20 65 20 63 6F 6E partition table e con
00000244 74 69 6E 75 61 20 70 65 72 20 6C 61 20 74 72 61 63 63 69 61 tinua per la traccia
00000258 20 7A 65 72 6F 20 64 65 6C 20 64 69 73 63 6F 20 66 69 73 73 zero del disco fisso
0000026C 6F 20 63 68 65 2C 20 63 6F 6D 75 6E 65 6D 65 6E 74 65 20 6E che, comunemente non
00000280 6F 6E 20 65 27 20 75 74 69 6C 69 7A 7A 61 74 61 20 28 73 69 e' utilizzata (si
00000294 20 6E 6F 74 69 20 63 68 65 20 6C 61 20 6D 61 67 67 69 6F 72 noti che la maggior
000002A8 20 70 61 72 74 65 20 64 65 6C 6C 65 20 70 61 72 74 69 7A 69 parte delle partizi
000002BC 6F 6E 69 20 70 61 72 74 65 20 64 61 6C 20 73 65 74 74 6F 72 oni parte dal settore
000002D0 65 20 36 33 29 2E 20 56 65 6E 67 6F 6E 6F 20 71 75 69 6E 64 63). Vengono quindi
000002E4 69 20 6C 61 73 63 69 61 74 69 20 71 75 61 73 69 20 33 30 4B lasciati quasi 30Kb
000002F8 62 20 6C 69 62 65 72 69 20 65 20 61 20 64 69 73 70 6F 73 69 liberi e a disposi
0000030C 7A 69 6F 6E 65 20 64 69 20 63 68 69 20 76 6F 67 6C 69 61 20 zione di chi voglia
00000320 6F 63 63 75 6C 74 61 72 65 20 71 75 61 6C 63 6F 73 61 2E 20 occultare qualcosa.
00000334 51 75 65 73 74 6F 20 74 65 73 74 6F 20 6D 69 73 75 72 61 20 Questo testo misura
00000348 73 6F 6C 6F 20 33 34 31 20 62 79 74 65 00 00 00 00 00 00 00 solo 341 byte.......
0000035C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
00000370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
00000384 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................

Alla luce di tutto ciò appare evidente che i dati possono essere nascosti in molti modi. È
possibile utilizzare anche parti del disco che non contengono realmente un file system. Si
proceda sempre seguendo le linee guida qui indicate.
Effettuare una copia di tutto il disco, non solo delle partizioni ivi presenti.
Non fidarsi mai della partition table. Ogni singola entry deve essere verificata (attraverso
un editor esadecimale o montandola in read-only con un loop device) e occorre controllare
che non ci siano altri sistemi di partizionamento coesistenti.
Verificare la presenza di spazio non allocato, di settori tra una partizione e l’altra e il
contenuto della traccia 0.
 Capitolo 7

File system

“... Dati, dati, dati... Crescono a una velocità sempre più elevata e richiedono tecnologie sempre più sofisticate per la loro
memorizzazione. Con una digitalizzazione sempre maggiore della nostra vita, l’uso dei social network e nuove forme di
comunicazione, produciamo dati a un ritmo sempre più sostenuto.”

Premessa
I file system sono stati oggetto di un grandissimo fermento nel recente passato. Negli scorsi
anni, dopo anni di immobilismo (o quasi) smosso solo da alcune innovazioni (come i journaled
file system), la produzione esponenziale di dati, l’utilizzo massiccio di cluster, sistemi di
virtualizzazione e cloud, il consolidamento dei dati in grossi storage (block o file) e la
distribuzione massiva su centinaia o migliaia di macchine (l’approccio seguito da nomi come
Google o Facebook), hanno fatto sì che si dedicassero moltissime energie all’argomento e hanno
prodotto una serie impressionante di novità.
Questo capitolo non vuole certo essere esaustivo in merito ma fornire una panoramica su
quanto si può trovare ora sul mercato. Si passerà dai file system più comuni per arrivare a
sistemi tipici delle piattaforme di tipo enterprise e ai vari approcci.

Tipologie di file system

I file system presenti sul mercato si differenziano in base all’ambito di utilizzo. Come per
molte tecnologie vi sono file system a uso generale e altri molto specifici o legati a un utilizzo
particolare.
Si possono comunque definire quattro tipologie.
File system tradizionali: si fondano su una serie di concetti base che saranno illustrati nel
proseguo del capitolo. Sostanzialmente, con livelli di sofisticazione diversi, utilizzano
delle tabelle per la gestione dei metadati e una serie di strutture su disco (cluster, inode)
per salvare i dati. Nel corso del tempo i file system tradizionali si sono evoluti utilizzando
strutture dati più complesse per migliorare gestione e velocità, journal per la gestione dei
log delle operazioni e sistemi di caching più o meno raffinati.
File system ad oggetti: ZFS ha davvero rivoluzionato il modo di concepire i file system.
 Purtroppo questo straordinario software è da sempre afflitto da una licenza che ne ha
impedito una massiva adozione da parte di sistemi operativi diversi dai *BSD. Così Apple
ha dovuto rinunciare alla sua adozione al posto del vetusto HFS e Linux, per un’insanabile
incompatibilità tra la GPL e la licenza di ZFS, e si è dovuta accontentare di un’adozione
tramite fuser o un modulo esterno al kernel da compilarsi a parte. Ad ogni modo i concetti
alla base di ZFS hanno ispirato una serie di progetti paralleli per realizzare un file system
di tipo Copy-on-Write ad oggetti. Alcuni non sono giunti al loro completamento (Tux3) ma
altri si stanno finalmente diffondendo. Un esempio sopra tutti è btrfs, che, uscito dalla fase
sperimentale, è ora scelto da molte distribuzioni.
NOTA
Alcuni produttori di storage, in un'epoca molto recente, hanno pensato di copiare i concetti a livello più basso,
creando degli object storage, ovvero dei sistemi specializzati in grado di salvare i dati come singoli oggetti. In
questo caso l’interfaccia con i computer non sarà un file system ma una serie di API che permettono di salvare
gli oggetti (file, record o di altra natura) sul sistema direttamente dall'interno dell’applicativo.

Clustered file system: generalmente si tratta di file system che possono essere montati
contemporaneamente da più server. In questo caso uno stesso block device (tipicamente un
block storage) viene connesso a più computer che montano simultaneamente in
lettura/scrittura lo stesso file system. Per far sì che il tutto funzioni tutti i membri del cluster
dispongono di una serie di complessi meccanismi (daemon di coordinamento, una coda di
scrittura comune e organizzata...) per la gestione della scrittura di dati e metadati. Alcuni
file system sono maggiormente orientati alla creazione di cluster per bilanciamento e high-
availability (ocfs2, gfs, cxfs...) altri si trovano più tipicamente nel mondo HPC, visto che la
minimimizzazione della latenza in scrittura è stata uno dei principali obiettivi del progetto
iniziale. Lustre, GPFS e FEFS sono esempi di quest’ultima categoria. Attualmente il più
diffuso clustered file system è probabilmente il VMFS di VMware.
Distributed file systems: con lo sviluppo di datacenter sempre più grandi (Google e
Facebook sono due esempi famosi) ci si è accorti che oltre una certa soglia aggregare dati
in pochi enormi storage presenta molti lati negativi, non ultimi dei costi esorbitanti e dei
problemi legati alla gestione della replicazione e all’alta affidabilità. Molti produttori
hanno quindi pensato di invertire la tendenza e di creare dei datacenter basati su building
block non differenziati. In pratica si ritorna a una serie di server di fascia media dotati di
molta RAM, buoni processori e dischi quanto basta. Tali sistemi sono spesso collegati gli
uni agli altri per ottenere una grid di risorse comuni. In questo caso si rendono utili i file
system distribuiti, in grado quindi di prendere le risorse di I/O sparse su centinaia di
server diversi e di presentarle ai nodi di calcolo come un’unica risorsa logica. OpenAFS,
HadoopFS, Glusterfs e Googlefs sono solo alcuni degli esempi di questa categoria.
StorNext di Quantum spinge ulteriormente avanti il concetto di distributed file system
 tenendo conto anche della tecnologia e della velocità dei sistemi connessi, al fine di
procedere a distribuire in dati su tecnologie più lente o veloci in base all’utilizzo degli
stessi da parte della rete (un meccanismo del tutto analogo alle funzioni di autotier presenti
su molti storage tradizionali). Se associato a StorNext Storage Manager è in grado di
includere nel pool di risorse anche delle robotic tape library su cui riversare i dati a cui
non si accede da tempo.

NOTA
Esistono anche progetti di distributed storage, che affrontano quindi il problema a un livello più basso. Cephs
(http://www.cephs.org) è un tipico esempio di storage distribuito.

Caratteristiche comuni ai file system

I file system presentano una notevole variabilità; nondimeno si possono identificare delle
caratteristiche che, pur differendo a livello di implementazione, sono comuni a tutti. Si
esamineranno ora alcuni di questi cardini, così da capire il disegno che esiste alla base di un
file system e riuscire a sfruttarlo per un’indagine digitale.
NOTA
Quanto segue è valido per i file system tradizionali. file system ad oggetti, come ZFS, usano (si potrebbe osare
dire “finalmente”) approcci differenti.

Dati, metadati e altre strutture

Il dato è ciò che si vuole salvare sul dispositivo di memorizzazione. Può essere presente in
moltissime forme: una foto, un film, un testo, un campo, un foglio elettronico... A seconda del
tipo di dato cambierà la sua rappresentazione sui media.
Non tutti i dati devono prendere necessariamente lo status di file. Si pensi per esempio ai
milioni di record contenuti in un database server. A livello di file system, ci si presenta un
insieme poco numeroso di file, i quali contengono i dati, la descrizione delle strutture, gli indici
e altro; tali informazioni sono gestibili solamente dall’applicativo che sa come estrarli
dall’insieme organizzato che ha creato.
Lo stesso vale per la posta elettronica. Nel mondo Unix (ma anche nel mondo Windows molti
mailer usano gli stessi standard) esistono principalmente due modi per salvare le proprie mail.
Nel formato mbox si avrà un unico grande file contenente tutte le mail di una specifica cartella,
mentre nel formato maildir si avrà una struttura di directory organizzata, in cui ogni singolo file
rappresenta un messaggio. Altri esempi possono essere i virtual disk delle macchine virtuali
dove un file contiene al suo interno un intero file system, oppure i container dei programmi di
crittografia che spesso sono anch’essi delle immagini di file system.
Tutto questo serve a chiarire che non è lecito aspettarsi, a livello di file system, che vi sia un
binomio indissolubile tra dato e file. Anche se spesso un dato prodotto da un’applicazione (un
documento di testo, un’immagine, un filmato) è rappresentato da un singolo file, vi possono
essere casi (un database server, la posta in formato mbox, un file system crittografato,
un’immagine di un hard disk) in cui più dati sono inglobati in un unico file, oppure, di contro, in
cui un dato (un film su DVD, la posta elettronica in formato maildir, un backup) è “spezzettato”
su diversi file.
Alcuni file system (NTFS o btrfs) permettono di scrivere file di piccole dimensioni
direttamente come un campo descrittivo all’interno della tabella dei metadati.
Il dato descritto a livello di file system, quindi, è un file, non necessariamente coincidente con
il dato prodotto dall’applicazione. Per chiarire ulteriormente il concetto, un file è un insieme di
dati correlati visti come una singola unità e identificati da un nome. Il file sarà salvato su disco
su una serie di cluster. Il cluster è l’unità minima che un file system può allocare. Talvolta
coincide con un settore fisico di un hard disk (512 byte) e talvolta può essere di dimensioni
maggiori. Si pensi alla FAT, ovvero il file system sviluppato per MS-DOS: utilizzando una
tabella con puntatori a 16 bit poteva indirizzare solamente 65.536 cluster. Con cluster di 512
byte la massima dimensione di un hard disk indirizzabile tramite questo sistema sarebbe di 32
MB (65.536 cluster × 512 byte). Per superare tale limite, quando i dischi cominciarono a
crescere di dimensioni, gli ingegneri di Compaq pensarono di gestire blocchi di grandezza
variabile. Questo implicava che per indirizzare un disco da 1 GB, utilizzando al massimo
65.536 cluster, ognuno di questi doveva avere una grandezza di 16 KB!
Questo concetto ha delle implicazioni importanti per il Digital Forensics expert. Significa che
se un dato ha una dimensione inferiore a quella di un cluster occuperà comunque tutto il cluster
(questo dal punto di vista del file system). Di conseguenza, oltre a un enorme spreco di spazio,
sul disco fisso rimarranno molti frammenti di vecchi file. Un cluster da 16 KB, occupato per
intero dal file precedente, se assegnato a un file da 200 byte sarà perciò sovrascritto solamente
in minima parte. Esaminando a basso livello quanto presente nel resto del cluster sarà quindi
possibile riesumare gran parte del contenuto della precedente scrittura.
Con il termine metadati ci si riferisce a tutto quanto descrive il dato (d’ora in poi coincidente
con un file, visto che stiamo parlando specificamente di file system). Nei metadati sono
contenute informazioni quali le tempistiche (quando il file è stato creato, quando è stato letto
l’ultima volta, quando è stato modificato), le ACL (le Access Control List che specificano i
diritti dei singoli utenti sui dati) e le informazioni (dove il file è localizzato e la sua
dimensione). Esistono alcuni tipi di file system che conservano tali informazioni all’interno di
diverse strutture dati, per esempio le directory entry della FAT, le entry della MFT del file
system NTFS o le strutture di directory dei file system Unix come UFS o Ext2.
Se il connubio tra un file e il suo nome sembra indissolubile, si pensi che i computer
ragionano più velocemente utilizzando dei codici piuttosto che stringhe mnemoniche. Siamo
circondati da esempi di questo: l’indirizzamento IP in una rete, i sistemi di telefonia, i codici
ISBN e così via. I file system, in molti casi, non fanno eccezione. Per tutto quanto riguarda il
loro funzionamento interno utilizzano dei codici che vengono trasformati in una stringa
alfanumerica solo nel momento in cui il computer si aspetta di avere a che fare con un utente
umano.
Esistono altre due strutture dati da considerare. La prima è la struttura del file system stesso.
Dato che un file system ha lo scopo di organizzare e gestire i dati sul dispositivo di
memorizzazione, è logico aspettarsi che sia presente, sul dispositivo medesimo, una struttura
organizzata che permetta di avere una rappresentazione precisa del contenuto dell’archivio.
Tutte le informazioni atte a gestire tale struttura e l’intero complesso di dati e metadati
appartengono a questa categoria. È indubbio che file system diversi possiedano strutture di
gestione completamente diverse. Per ricorrere a un’analogia, facendo riorganizzare un archivio
a due segretarie differenti ognuna avrà il suo particolare metodo per gestire il marasma di carte.
Analogamente, anche due supporti di tipo diverso, utilizzanti lo stesso file system, avranno due
strutture di gestione diverse. Secondo la nostra similitudine, la stessa segretaria pianificherà in
modo differente la gestione della libreria dello studio medico (con un numero di volumi
limitato) rispetto all’archivio delle cartelle cliniche (ben più voluminoso). Molti file system
Unix tengono dei backup della struttura degli inode. Il numero di tali backup e la loro
collocazione varieranno in base al dispositivo di memorizzazione e alla sua grandezza.
Alcuni file system dispongono anche di dati a livello applicativo. In questa categoria sono
inseriti dati che non hanno relazione con il file system in senso stretto (ovvero non sono
necessari per leggere o scrivere un file) ma che possono espanderne le funzioni. Due esempi
palesi sono le quote del disco o il giornale di un file system di tipo journaled. Anche se spesso
queste funzioni sono trascurate durante l’investigazione, è meglio non dimenticarsi della loro
esistenza.
Riassumendo, un qualunque file system contiene in generale dati appartenenti alle seguenti
categorie: struttura del file system, metadati, dati, gestione dei nomi file mnemonici e dati
applicativi. Questo è ovviamente un modello di riferimento. Molti file system semplificano
questo sistema accorpando (od omettendo) alcune di queste strutture dati.

Logica di funzionamento

File system non journaled

La maggior parte dei file system presenti sul mercato e la quasi totalità di quelli presenti fino
a una quindicina di anni fa è di tipo non journaled. La loro logica di funzionamento è molto
semplice e ne fa dei file system molto veloci, specialmente nelle operazioni di scrittura. Il
maggiore problema di questo tipo di file system si evidenzia nel momento in cui si manifesta un
crash di sistema. In questo caso si è costretti a eseguire delle lunghe operazioni per controllare
la consistenza dei dati rispetto alle strutture di controllo del file system e dei metadati. I file
system FAT (in tutte le sue varianti) ed Ext2 sono due esempi di questa categoria.
La logica di funzionamento di un’operazione di scrittura in un file system non journaled può
essere riassunta, con qualche approssimazione, nel seguente modo.
Ricerca dello spazio libero: ogni file system ha i propri algoritmi (più o meno efficienti)
per ricercare lo spazio necessario per la scrittura di un file.
Scrittura dei dati: il dato viene scritto su una serie di cluster (contigui o no) all’interno
dello spazio libero assegnato.
Aggiornamento delle strutture di file system e di directory, dei metadati e dei dati
applicativi.
Questa serie di passi non viene eseguita in rigida sequenza. I moderni sistemi operativi
utilizzano sistemi di caching di grandi dimensioni e possono rimandare le operazioni di scrittura
anche per diverso tempo. Come detto, il problema con questo genere di file system nasce nel
momento in cui la procedura, per un crash di sistema o una mancanza di alimentazione, dovesse
interrompersi. Se ciò accadesse tra il primo e il secondo step non sarebbe un problema troppo
grave (ovviamente escludendo tra i danni la perdita dei file). Se invece questo dovesse
accadere tra il secondo e il terzo passo ci si ritroverebbe in una situazione di incoerenza del file
system, perché i dati sarebbero stati scritti sul file system ma tutte le strutture informative utili
per riuscire a ritrovarli non sarebbero state aggiornate.
In questo caso si dovrebbe utilizzare un programma di controllo di coerenza, come fsck per i
sistemi Unix o chkdsk/scandisk per i sistemi Windows. Con dischi di grandi dimensioni il tempo
richiesto per un controllo completo della coerenza potrebbe essere decisamente eccessivo. Per
questo motivo, mutuando le conoscenze accumulate con i database, sono stati introdotti i file
system journaled.

Journaled file system

Questi file system introducono una nuova logica di funzionamento. Al file system viene
associato un log (journal, “giornale”) delle operazioni. Si noti che molti file system utilizzano
dati applicativi per la gestione del giornale. L’operazione di scrittura cambia quindi come
segue.
1. Scrittura della pianificazione delle operazioni nel log.
2. Ricerca dello spazio libero: ogni file system ha i propri algoritmi (più o meno efficienti)
per ricercare lo spazio necessario per la scrittura di un file.
3. Aggiornamento del log.
4. Scrittura dei dati: il dato viene scritto su una serie di cluster (contigui o no) all’interno
dello spazio libero assegnato.
5. Aggiornamento del log.
6. Aggiornamento delle strutture di file system e di directory, dei metadati e dei dati
applicativi.
7. Aggiornamento del log.
Nel caso di un crash, a qualunque livello, la consistenza del file system è così garantita dalla
presenza del giornale. Il sistema utilizzerà quest’ultimo e completerà le transazioni lasciate in
sospeso o, in caso di impossibilità di completarle, effettuerà un completo rollback (termine
usato nei database transazionali per indicare l’operazione di ritorno allo stato precedente la
transazione, in modo che il database non si trovi in uno stato di incoerenza dovuta a
un’operazione eseguita per una parte).
È indubbio che se un tale sistema è assolutamente efficiente dal punto di vista della
protezione dei dati, è d’altro canto penalizzato nella velocità di scrittura, poiché il numero di
operazioni da compiere sale considerevolmente.
Dal punto di vista dell’analisi forense la presenza di un log è di grande aiuto. Molti file
system journaled allocano una notevole quantità di spazio per il log, quindi spesso vi si trovano
molte precedenti transazioni. Nel caso tali file fossero stati, per esempio, cancellati, tramite il
log del giornale sarebbe possibile riuscire a ottenere le informazioni necessarie per poterli
recuperare.

Clustered file system

Nel momento in cui più server devono accedere alle stesse informazioni occorre un’azione
coordinata per prevenire disastri. Se uno stesso disco con un file system fosse collegato a più
macchine la situazione diventerebbe esplosiva nel giro di poco tempo.
Si pensi a due server che debbano scrivere un dato nello stesso momento. Entrambi
cercherebbero uno spazio libero necessario. Utilizzando lo stesso algoritmo di ricerca potrebbe
essere del tutto verosimile che entrambi trovino la stessa zona libera del disco. Entrambi
allocherebbero quello spazio per loro stessi e scriverebbero due file diversi nello stesso punto,
con una conseguente mescolanza e sovrascrittura dei dati. Inoltre, al momento di scrivere i
metadati, rischierebbero di sovrascrivere gli stessi record, ponendo quindi fine a ogni speranza
di gestire il flusso in maniera corretta.
I clustered file system introducono quindi un ulteriore layer che permette ai server di
coordinare tutte le operazioni di scrittura.
Ogni clustered file system affronta il problema con modalità differenti. Tendenzialmente però
ogni nodo dispone di un servizio/daemon caricato in memoria che si occupa di creare un
collegamento (solitamente tramite rete locale) tra tutti i membri del cluster. In questo modo le
scritture possono essere coordinate attraverso vari metodi, che vanno dall’uso di una
Distributed Message Queue, alla preallocazione dei blocchi per nodo, all’uso di un Distributed
Lock Manager o al demandare le scritture a un ristretto numero di nodi.
Il principio di funzionamento è molto simile a quello di un file sytem journaled, con la
differenza che prima di ogni operazione di scrittura i nodi devono coordinarsi tra loro sia per
evitare di sovrascrivere i dati tra loro (a livello di file e a livello di metadati) sia per far sì che
le cache degli altri nodi siano avvisate di un cambiamento dei dati sul file system e possano
procedere a un’opportuna operazione di flushing.

Distributed file system

In un distributed file system si incorporano i concetti di file e network file system. Ogni nodo
si occupa di gestire le scritture sui dischi locali e poi esporta le proprie risorse a un layer
comune attraverso la rete.
Alcuni distributed file system, come per esempio OpenAFS, richiedono che localmente
(ovvero a livello di ogni server che partecipa alla cella o al pool) siano assegnati loro dei file
system journaled a uso esclusivo; altri invece richiedono un raw device che sarà poi
opportunamente formattato.
I nodi connessi al distributed file system disporranno di uno specifico client con il quale
potranno vedere il pool delle risorse condivise. A seconda delle implementazioni tale file sytem
remoto sarà visto come un network o come un native file system.
GPFS di IBM dispone di un volume manager distribuito che funziona in maniera simile al
LVM di Linux. Le risorse provenienti dai singoli storage saranno aggregate a livello di singolo
Volume Group e poi i file system GPFS saranno creati all’interno dei Logical Volume da esso
ricavati. Tali file system potranno poi essere montati da più nodi come un tradizionale clustered
file system.

Principali file system

Nei prossimi paragrafi, sino alla conclusione del capitolo, vengono presi in esame i
principali file system: FAT, NTFS, Ext2/3/4, btrfs, OCFS2, ZFS e HFS+. Di tutti questi viene
fornita la documentazione di interesse per il Digital Forensics expert, anche laddove non esista
una documentazione “ufficiale” completa e aggiornata, come per NTFS: in questo caso ci si
baserà sulle analisi condotte dai team open source.
NOTA
Nelle precedenti edizioni del libro si è trattato anche di ReiserFS. Si tratta di un file system journaled molto
efficiente e diffuso nei sistemi Linux. Purtroppo Hans Reiser, il fondatore del progetto, ha avuto la pessima idea
di uccidere sua moglie. La vicenda è proseguita per anni, fino al punto in cui lui ha ceduto e ha ammesso il fatto.
 La cosa ha avuto un forte impatto sul progetto, che non è stato continuato da nessun altro e in breve è stato
dismesso da tutte le distribuzioni. Dato che da tempo nessuno usa più ReiserFS la sua trattazione è stata
depennata.

FAT
È impossibile parlare di file system senza citare FAT. Nato con MS-DOS agli inizi degli anni
Ottanta, ha subìto alcune evoluzioni nel corso del tempo (FAT12/FAT16/FAT32). È un file
system banalmente semplice, senza caratteristiche moderne come ACL, gestione delle quoted,
journal. È inoltre terribilmente inefficiente nell’uso del disco e nella gestione della
frammentazione.
Nonostante questo si è imposto come standard e ora non solo è utilizzato su innumerevoli
supporti (USB drive, lettori MP3), ma anche su praticamente qualunque fotocamera digitale
attualmente presente sul mercato. La probabilità di imbattersi in questo file system è dunque
elevatissima.
FAT, innanzitutto, non rispecchia la divisione in quattro categorie che è stata precedentemente
esposta. Utilizza infatti un numero ridotto di strutture di gestione (in pratica solo due, la File
Allocation Table e le directory entry), che appartengono contemporaneamente a più categorie.
I concetti alla base di FAT, comunque, rimangono semplici. Per ogni singolo file o directory
viene allocata una struttura dati che prende il nome di directory entry. I contenuti di tale
struttura sono quelli riportati nella Tabella 7.1.
Se il file system è FAT32, nella tabella si potranno trovare delle entry differenti (Tabella 7.2).
FAT32 permette infatti una gestione dei nomi di file lunghi. Per i file con nomi saranno presenti
una o più LFN entry (Long file Name entry) che ne descrivono il nome. Le LFN entry precedono
sempre la normale entry con il formato descritto sopra.
Si noti che per ogni nome file è indicato solo il cluster di partenza. Per riuscire a trovare tutti
i cluster occupati dal file stesso è necessario rivolgersi alla tabella FAT.
La struttura di tale tabella è molto semplice. In pratica è composta da un solo campo, di
lunghezza variabile a seconda del tipo di FAT che si utilizza (12 bit per la FAT12, 16 per la
FAT16, 32 per la FAT32). Ogni FAT conterrà un numero di entry pari al numero di cluster
allocati per quel file system.
Tabella 7.1
Byte
Descrizione Obbligatorio
occupati
Primo carattere del nome file in ASCII (il valore sarà 0x00 o 0xe5 se l’entry libera o il
0-0 Sì
file è stato cancellato).
1-10 I caratteri da 2 a 11 del nome file. Sì
11-11 Attributi del file (è una mappa di bit). Sì
12-12 Riservato. No
13-13 Ora di creazione (decimi di secondo). No
14-15 Ora di creazione (ore, minuti, secondi). No
16-17 Data di creazione. No
18-19 Data di ultimo accesso. No
20-21 2 byte più significativi dell’indirizzo del cluster di partenza (0 per FAT12/16). Sì
22-23 Ora di ultima modifica (ore, minuti, secondi). No
24-25 Data di ultima modifica. No
26-27 2 byte meno significativi dell’indirizzo del cluster di partenza. Sì
28-31 Grandezza del file (0 per le directory). Sì

Tabella 7.2
Byte
Descrizione Obbligatorio
occupati
Numero di sequenza (per numerare le diverse LFN per un singolo nome file). La prima
0-0 entry ha valore 1 e così via per le successive. L’ultima un OR con il valore 0x40. Se Sì
l’entry è libera o il file è stato cancellato prende il valore 0x5e.
1-10 Primi cinque caratteri del nome in formato Unicode. Sì
11-11 Attributi del file (fisso a 0x0f). Sì
12-12 Riservato. No
13-13 Checksum. Sì
14-25 Nome del file (caratteri da 6 a 11 in formato Unicode). Sì
26-27 Riservato. No
28-31 Nome del file (caratteri 12 e 13 in formato Unicode). Sì

Il valore di tale entry può essere:

zero se il cluster non è al momento occupato;
un indirizzo: è il puntatore al cluster successivo occupato da quel file;
un marcatore di fine file: sarà un valore superiore a 0xff8 per FAT12, 0xfff8 per FAT16 o
0x0ffffff8 per FAT32. Indica che quel cluster è l’ultimo occupato dal file;

un marcatore di “bad cluster”: identifica un cluster danneggiato (in realtà il danno potrebbe
essere limitato a un solo settore fisico del disco facente parte di quel cluster). Esso sarà
0xff7 per FAT12, 0xfff7 per FAT16 e 0x0fffff7 per FAT32.

Per leggere un file, il sistema leggerà la relativa directory entry, prenderà l’indirizzo del
primo cluster, andrà nella FAT e leggerà l’entry corrispondente. Se troverà il marcatore di fine
file si fermerà, altrimenti si sposterà nel record relativo all’indirizzo trovato nell’entry
precedente e ripeterà l’operazione. Trovati gli indirizzi di tutti i cluster, andrà a leggere i dati
nell’ordine corretto dalla data area.
Dove si trovano tutte le strutture sopra descritte? Una prima indicazione viene fornita dal boot
sector. Esso si trova nella primissima parte di una partizione FAT e include la descrizione
completa del file system che lo contiene.
 Il boot sector è differente per un file system FAT12/16 e uno FAT32. I primi 36 byte sono
comuni e la loro struttura è quella della Tabella 7.3.
Tabella 7.3
Byte
Descrizione Obbligatorio
occupati
0-2 Codice assembly per puntare al codice necessario per effettuare il boot. No
3-10 Nome del volume OEM in ASCII. No
11-12 Numero di byte per settore. I possibili valori sono 512, 1024, 2048, 4096. Sì
Settori per cluster. Sono ammesse potenze di 2 come valori. La grandezza massima
13-13 Sì
del cluster non può essere superiore a 32 K.
14-15 Grandezza, in settori, dell’area riservata. Sì
16-16 Numero di FAT. Di norma 2 ma potrebbe essere una sola. Sì
Numero massimo di file nella directory radice. Tipicamente è 0 per FAT 32 e 512 per
17-18 Sì
FAT 12/16.
Numero a 16 bit che rappresenta il numero di settori presenti nel file system. Se il
19-20 numero non è rappresentabile con un valore di 2 byte è posto a zero e viene usato un Sì
campo di 4 byte in coda.
21-21 Tipo di supporto. È 0xf8 per i dischi fissi e 0xf0 per quelli rimovibili. No
Grandezza della FAT. È rappresentata da un valore a 16 bit che indica il numero di
22-23 Sì
settori occupati. Vale solo per FAT 12/16. Per FAT32 è a 0.
24-25 Settori per traccia del dispositivo. No
26-27 Numero di testine. No
28-31 Numero di settori prima dell’inizio della partizione. No
Valore a 32 bit (4 byte) per rappresentare il numero di settori presenti nel file system. È
32-35 Sì
0 se viene usato il campo a 16 bit al byte 19-20.

Per i file system FAT12/16 il boot sector prosegue nel modo indicato nella Tabella 7.4.
Tabella 7.4
Byte
Descrizione Obbligatorio
occupati
36-36 Identificativo del drive tramite chiamata a INT13h del BIOS. No
37-37 Riservato. No
38-38 Valore fisso di 0x29. No
39-42 Numero seriale del file system. Usato da alcune versioni di Windows. No
43-53 Nome del volume in ASCII (quello scelto dall’utente in fase di formattazione). No
Tipo di file system in ASCII. I valori possibili sono FAT, FAT12 e FAT16. Non è richiesto
54-61 No
che sia avvalorato.
62-509 Non usati. No
510-511 Signature (0xaa55). No

Il boot sector di un FAT32 è più complesso, invece, come mostra la Tabella 7.5.
Tabella 7.5
Byte
Descrizione Obbligatorio
occupati
36-39 Grandezza di una FAT, espressa in settori (numero a 32 bit). Sì
40-41 Descrive il meccanismo di ridondanza delle FAT. Mappa di bit. Sì
42-43 Numero di versione della FAT32. Sì
44-47 Cluster dove trovare la root directory. Sì
48-49 Settore dove è contenuta la struttura FSINFO. No
50-51 Settore dove è tenuta una copia del boot sector, di norma il sesto. No
52-63 Riservati. No
64-64 Identificativo del drive tramite chiamata a INT13h del BIOS. No
65-65 Riservato. No
66-66 Valore fisso di 0x29. No
67-70 Numero seriale del file system. Usato da alcune versioni di Windows. No
71-81 Nome del volume in ASCII (quello scelto dall’utente in fase di formattazione). No
Tipo di file system in ASCII. L’unico valore possibile è FAT32. Non è richiesto che sia
82-89 No
avvalorato.
90-509 Non usati. No
510-511 Signature (0xaa55). No

Le strutture dati del file system sono poste nella partizione del disco nel seguente ordine.
Reserved area: parte dal settore 0, contiene il boot sector e altre informazioni. La sua
grandezza è fissata nel boot sector stesso, nei byte 14 e 15. Per i file system FAT12/16 è
solitamente di un settore, mentre FAT32 riserva una porzione più ampia per contenere
anche le strutture dati FSINFO (fornisce informazioni al sistema operativo riguardo il
numero di cluster liberi e altro).
FAT area: in quest’area si trovano le FAT (come già spiegato, solitamente sono due, per
questioni di ridondanza). La grandezza della FAT area non è predeterminabile in quanto
dipende dal prodotto della grandezza della FAT stessa (12, 16 o 32 bit) e del numero di
settori presenti all’interno del file system. Il risultato di tale moltiplicazione va
raddoppiato in presenza di due FAT.
Data area: la data area parte a ridosso delle due FAT. La sua grandezza è fissata nel boot
sector. Nella data area sono contenuti i dati e tutte le directory entry. Per riuscire a trovare
tutte le varie directory entry si deve partire dall’unica che ha posizione nota (quella della
root directory che parte, per FAT12/16, dal primo cluster della data area e, per FAT32, dal
cluster indicato dal boot sector nei byte da 44 a 47), che provvederà a “linkare” le
successive.

Considerazioni a livello di analisi

La semplicità del file system FAT, unita a un buon editor esadecimale, permette di nascondere
dati in molti punti diversi del file system.
 Innanzitutto esistono già punti non utilizzati all’interno delle strutture dati. Per esempio, nel
boot sector i byte dal 62 al 509 sono utilizzati per inserirvi il codice necessario per il boot; nel
caso di un comune disco che non contenga il sistema operativo, tale area può essere utilizzata
per dati propri.
Si può inoltre ridurre il numero di settori della data area al fine di ricavare dello spazio tra
l’ultimo settore del file system e la fine della partizione. Tale spazio potrebbe anche avere
dimensioni ragguardevoli.
Un altro spazio si potrebbe ricavare, in un file system FAT32, spostando l’inizio della zona
riservata alla root directory. In questo modo sarebbe possibile nascondere dei dati tra la fine
della seconda FAT e l’inizio della root directory.
Questi sono solo alcuni esempi di come il file system possa essere opportunamente
modificato per ricavare spazi non facilmente individuabili ove nascondere dati. Il limite
probabilmente è dato solo dalla fantasia.
Il Digital Forensics expert dovrebbe quindi porsi come regola quella di verificare quanto
scritto nelle strutture di controllo di qualunque file system, senza fidarsi ciecamente di quanto
scritto. Ogni anomalia dovrebbe essere attentamente controllata.

NTFS
Microsoft, con il progetto Windows NT, decise di utilizzare un file system più moderno e con
caratteristiche molto più avanzate rispetto alla FAT (non che ci volesse poi molto sforzo per
riuscirci). Insieme a IBM, con il progetto OS/2, i programmatori di Microsoft avevano già avuto
un’esperienza simile con lo sviluppo di HPFS, quindi il know-how per questo compito era già
stato ampiamente acquisito.
Il team di sviluppo, sotto la guida di David Cutler, ha realizzato un file system totalmente
nuovo, che incorpora concetti assolutamente innovativi rispetto a qualunque altra cosa apparsa
prima di allora sul mercato.
NTFS, innanzitutto, ha una sola struttura fissa, il boot sector. Il layout di qualunque altra
struttura di controllo, metadato o altro non è predeterminabile, perché in NTFS qualunque cosa è
rappresentata da un file. La tabella principale per la gestione dei file, MFT (Master File Table),
è un file essa stessa e la prima referenza è un record dove si autodescrive. L’idea di base è di
una semplicità sconcertante, mentre la sua realizzazione, in termini pratici, non è proprio
elementare. Uno dei motivi è che Microsoft rilascia da anni informazioni su NTFS con il
contagocce. In effetti, gran parte delle informazioni qui esposte è basata sul lavoro di reverse
engineering dei team open source che si sono occupati di sviluppare i driver NTFS per Linux,
ossia su come si ritiene che NTFS funzioni, non su specifiche tecniche inconfutabili rilasciate
dagli sviluppatori.
 Esistono varie versioni di NTFS. In particolare sono note le seguenti.
1.0: nasce con Windows NT v. 3.1 nel 1993.
1.1: evoluzione introdotta con Windows NT v. 3.5 l’anno successivo.
1.2: introdotta con Windows NT 3.51 e presente, sostanzialmente immutata, anche in
Windows NT v. 4.0 (talvolta si trovano riferimenti a questa versione anche come NTFS v.
4.0). Offre una gestione completa delle ACL e la compressione a livello di file system.
3.0: introdotta con Windows 2000, presenta notevoli caratteristiche aggiuntive come l’EFS
(Encrypted File System), le quote, il supporto per gli “sparse file”, la directory $Extend e
così via. È nota anche come NTFS v. 5.0.
3.1: introdotta con Windows XP (noto anche come NTFS 5.1). Introduce le entry ridondate
nella $MFT. Windows 2003 Server (noto anche come NTFS 5.2) introduce delle migliorie,
così come Windows Vista e 2008 Server (informalmente NTFS 6.0) aggiungono il servizio
VSC e il Copy-on-Write, il Transactional NTFS, i link simbolici e la possibilità di ridurre
le dimensioni del file system.
NOTA
La versione 3.1 è l’ultima ufficialmente rilasciata da Microsoft. Ciononostante nei sistemi operativi successivi
sono state migliorate e aggiunte nuove funzioni senza comunque cambiare la versione del sistema.

È bene ricordare che NTFS è duttile per caratteristica progettuale, quindi il sistema operativo
può passare agevolmente da una versione all’altra. Pertanto, se per esempio si collega un disco
formattato con NTFS 1.2 su una macchina Windows 2000, il sistema operativo provvederà, in
automatico e senza alcuna richiesta di conferma da parte del sistema, ad aggiornare la versione
del file system sul disco.
Qualche anno fa, all’autore di questo libro capitò di fare una controperizia rispetto
all’operato di due CTU. Questi collegarono un disco di boot di Windows NT 3.51 (NTFS 1.2) a
un portatile Windows 2000, il tutto con un mero cavo di adattamento IDE/USB senza alcun write
blocker. Questa procedura, oltre a essere assolutamente da evitare per non apportare modifiche
sulla maggior parte dei metadati presenti, ebbe come effetto collaterale che il file system venne
aggiornato alla versione 3.0, quindi il system originario andò immediatamente in blue screen al
primo boot, perché il sistema operativo installato non era più in grado di interpretare il file
system sottostante.
Tornando alla struttura base di NTFS, il suo boot sector condivide molti campi con quello
della FAT, ivi compresa la signature (0xAA55), che è la stessa. Questo significa che un forensics
expert deve guardare attentamente al layout del boot sector per riconoscere il tipo di file system
al quale si riferisce. Quello per NTFS contiene i campi della Tabella 7.6.
Tabella 7.6
Byte occupati Descrizione Obbligatorio
0-2 Codice assembly per puntare al codice necessario per effettuare il boot. No
3-10 Nome del volume OEM in ASCII. No
11-12 Numero di byte per settore. Sì
13-13 Settori per cluster. Sono ammesse potenze di 2 come valori. Sì
14-15 Settori riservati (Microsoft specifica che tale parametro deve essere 0). No
16-20 Inutilizzato (Microsoft specifica che tale parametro deve essere 0). No
21-21 Tipo di supporto. No
22-23 Inutilizzato. (Microsoft specifica che tale parametro deve essere 0). No
24-31 Inutilizzato (Microsoft specifica che tale parametro non è controllato). No
32-35 Inutilizzato (Microsoft specifica che tale parametro deve essere 0). No
26-39 Inutilizzato (Microsoft specifica che tale parametro non è controllato). No
40-47 Settori totali nel file system. Sì
48-55 Indirizzo del cluster di partenza della MFT. Sì
56-63 Indirizzo del cluster di partenza dell’attributo $DATA dell’MFT Mirror. No
64-64 Grandezza di un’entry della MFT. Sì
65-67 Inutilizzato. No
68-68 Grandezza di un record di un indice. Sì
69-71 Inutilizzato. No
72-79 Numero di serie. No
80-83 Inutilizzato. No
84-509 Codice per il boot. No
510-511 Signature (0xaa55). No

Per montare un file system NTFS il sistema legge quindi il boot sector che si trova in testa
alla partizione, legge l’indirizzo di partenza della MFT, dopodiché legge il primo record della
MFT. Questo record fornirà al sistema tutti gli altri dettagli che servono per poter gestire il file
$MFT dove sono contenute le entry relative a tutto il resto del file system.

Prima di addentrarci nel funzionamento della MFT è bene specificare che in NTFS vi sono
altri file che contengono le strutture di controllo e gli altri dati necessari al funzionamento del
file system. Tali file sono descritti in una serie di entry riservata della MFT. Al momento queste
entry sono quelle descritte nella Tabella 7.7.
Tabella 7.7
Entry
Nome
della Descrizione
file
MFT
0 $MFT L’entry di descrizione della MFT.
1 $MFTMir Contiene un backup delle entry di questa tabella.
2 $LogFile File contenente il giornale.

3 $Volume
File contenente le informazioni di descrizione del volume, come la label, la versione e
l’identificatore.
4 $AttrDef Contiene la lista degli attributi identificativi.
5 . Contiene la descrizione della root directory del file system.
6 $Bitmap Questo file descrive lo stato di allocazione dei singoli cluster del file system.
7 $Boot È una descrizione del boot sector, visto anch’esso come un file dalla MFT.
8 $BadClus Contiene la lista dei cluster che presentano problemi sul disco.
9 $Secure Il file che contiene tutta la parte relativa alle ACL.
10 $Upcase Contiene tutti i caratteri UNICODE in maiuscolo.

11 $Exted
È una directory dove sono contenute le caratteristiche aggiuntive di NTFS. Le quote,
aggiunte di recente con la versione 5 sono poste in un file al suo interno.

Il significato e il funzionamento di ognuno di questi file saranno descritti più avanti. Si

esaminerà ora il funzionamento della MFT, compito tutt’altro che semplice.
Un’entry MFT è divisa in due sezioni: un header MFT, di dimensioni ridottissime, e un’ampia
sezione utilizzata per salvare gli attributi.
Un’entry MFT ha una lunghezza fissa di 1024 byte. Di questi, i primi 41 sono parte
dell’header (Tabella 7.8).
Tabella 7.8
Byte
Descrizione Obbligatorio
occupati
Signature. Il valore fisso è FILE. Potrebbe essere BAAD se il cluster contenesse degli
0-3 No
errori.
4-5 Valore per l’array di fixup. Sì
6-7 Numero delle entry nell’array di fixup. Sì
8-15 Numero di sequenza (LSN) per il journal ($Logfile). No
16-17 Numero di sequenza. No
18-19 Conteggio di riferimenti. No
20-21 Offset del primo attributo. Sì
Flag. È impostato a 0x01 se l’entry è usata e a 0x02 se l’entry descrive una
22-23 Sì
directory.
24-27 Spazio usato nell’entry MFT. Sì
28-31 Spazio allocato per l’entry MFT. Sì
32-39 Referenza al base record. No
40-41 ID del prossimo attributo. No

Tutto il resto dello spazio è utilizzato per gli attributi. Tali attributi sono standard e
descrivono il file (o la directory) nel suo complesso. Nel caso il numero degli attributi (e lo
spazio necessario per avvalorarli) superasse i 1024 byte si dovrà adottare una delle seguenti
strategie, o entrambe.
Utilizzo di entry MFT multiple. Per ogni file possono essere specificati fino a 65.535
attributi. Questo implica che, solamente per gli header, un’entry non è sufficiente. NTFS
prevede l’utilizzo di più entry MFT da 1024 byte per far fronte a questo problema.
Gestione di attributi non residenti. Tendenzialmente, gli attributi sono specificati come
“residenti”, ovvero il loro valore sarà contenuto nella MFT subito dopo la dichiarazione
 dell’attributo nell’header. Alcuni attributi, come il $DATA che contiene il file stesso, non
possono essere inseriti in toto nella MFT. Essi vengono quindi dichiarati come “non
residenti”, per cui nella MFT si troverà un puntatore ai cluster che li contengono.
Gli attributi standard che si possono trovare nella MFT sono elencati nella Tabella 7.9;
questa non è assolutamente esaustiva, descrive solamente i campi principali. (Se l’argomento
sembra diventare complesso, si pensi che si sta appena scalfendo la superficie.)
Proviamo a mettere un po’ di ordine nel campo. Ogni singola entry della MFT ha almeno due
attributi. Il primo è $FILE_NAME, che contiene il nome file e le informazioni riguardanti la data di
creazione, di lettura e modifica. Il secondo è $STANDARD_INFORMATION, che contiene un duplicato delle
informazioni temporali, l’owner e gli attributi di sicurezza del file. Questi due attributi sono
sempre residenti.
Tabella 7.9
Identificatore
Nome Descrizione
di tipo
Informazioni generali, come i flag, la data e l’ora di quando il file è stato
16 $STANDARD_INFORMATION creato, letto e modificato, l’identità dell’owner e il securityID associato al
file.
32 $ATTRIBUTE_LIST Lista contenente i puntatori agli altri attributi del file.

48 $FILE_NAME
Contiene il nome file codificato in Unicode e le informazioni temporali
riguardanti il file stesso.

64 $VOLUME_VERSION
Identificatore del volume. Risulta usato solo nella versione 1.2 del file
system.

64 $OBJECT_ID
Sostituisce il campo precedente dalla versione 3.0 del file system. È un
ID a 16 byte per il file o la directory.
80 $SECURITY_DESCRIPTOR Definisce le ACL e le proprietà di sicurezza del file.
96 $VOLUME_NAME Nome del volume.
112 $VOLUME_INFORMATION Contiene la versione del file system e altri dati relativi.

128 $DATA
Specifica l’intero contenuto del file. Nella quasi totalità dei casi è un
attributo non residente.
144 $INDEX_ROOT Specifica qual è il nodo radice per un albero degli indici.

160 $INDEX_ALLOCATION
Espande l’attributo $INDEX_ROOT inserendo ulteriori informazioni sui file e
le directory presenti nell’albero degli indici.
176 $BITMAP Una bitmap che descrive il file $MFT e gli indici sottesi.

192 $SYMBOLIK_LINK
Informazioni riguardanti i soft link. È usato sono nella versione 1.2 del file
system.
192 $REPARSE_POINT Sostituisce i $SOFT_LINK nella versione 3.0 e superiori di NTFS.
208 $EA_INFORMATION Usato solo per la compatibilità con il vecchio HPFS.
224 $EA Usato solo per la compatibilità con il vecchio HPFS.
256 $LOGGED_UTILITY_STREAM Contiene le informazioni riguardanti i file crittografati.

Se l’entry è riferita a un file sono sicuramente presenti uno o più campi $DATA. Come già
accennato nella tabella, il campo $DATA contiene il contenuto del file stesso o, nella maggior parte
dei casi, un puntatore a una serie di cluster sul file system che contengono tale file. Il campo
data può essere ripetuto più volte, poiché NTFS supporta un meccanismo noto come Alternate
Data Streams (ADS).
NOTA
La feature ADS è stata sviluppata inizialmente per poter gestire agevolmente i sistemi Mac via rete. I Mac
utilizzano un file system noto come HFS (Hierarchical File System) che ha una particolarità, ovvero quella di
utilizzare due fork per ogni file. Nel primo fork è salvato il file in quanto tale (data fork), nel secondo tutte le
metainformazioni che lo descrivono (resource fork). Quando un Mac utilizza un file system diverso (FAT, UFS,
ma anche un file system via rete) adopera una serie di file nascosti (il cui nome comincia con ._) per salvare le
metainformazioni del resource fork. Il risultato spesso è quello di infastidire gli utenti degli altri sistemi operativi
che non sanno come gestire tali file. Per ovviare a questo problema (e ad alcuni altri legati ai vari subsystem di
Windows NT) Microsoft introdusse il concetto degli ADS. A ogni file era possibile legare delle altre informazioni
raggiungibili tramite un puntatore al loro nome. Se il file ha nome file.txt e lo stream ha nome info si può
accedere ai dati di quest’ultimo puntando al nome file file.txt:info. In questo modo il modulo che si occupava
di gestire un fileserver tipo AFS (Apple File Server) poteva salvare i resource fork in un ADS. Si conservavano
così le informazioni, ma si evitava di creare problemi agli utenti di altri sistemi operativi che non vedevano le
informazioni aggiuntive. Il punto interessante è proprio questo. Nonostante lo scopo iniziale sia decaduto, gli
ADS sono ancora una delle feature di NTFS e gli utenti continuano a non conoscerne l’esistenza. Si noti che
aggiungendo uno stream a un file esistente le metainformazioni riguardanti quest’ultimo non cambiano. Ergo, la
tempistica, la dimensione e gli altri valori non vengono alterati. È quindi un sistema eccezionale per nascondere
dati. Solo con uno scan a basso livello della MFT si riesce a notare la presenza di più campi dati per un’entry e
capire quindi la presenza di un ADS. Con le comuni utility (Explorer o la CLI, Command Line Interface, cmd.exe)
questo non è possibile.

Nel caso un’entry MFT sia riferita a una directory, si troverà l’attributo $INDEX_ROOT che
contiene le informazioni relative ai file e alle directory incluse in essa (in caso di directory di
grandi dimensioni saranno usati allo scopo anche gli attributi $BITMAP e $INDEX_ALLOCATION).
NOTA
Anche in questo caso le cose si possono complicare. L’attributo $DATA non è utilizzato solo per puntare al
contenuto di un file. In realtà le API di Windows permettono di utilizzarlo per salvarci qualunque dato di livello
applicativo. Si pensi a un file manager che consenta di salvare delle informazioni testuali riguardanti una
directory. A questa sarà aggiunto un campo $DATA contenente tali informazioni, che saranno ignorate dal sistema
operativo per le normali operazioni sul file system ma, nel contempo, potranno essere richiamate dall’applicativo
stesso. Dato che più applicativi potrebbero voler salvare informazioni riguardo quella directory, il meccanismo
degli ADS si applica perfettamente anche alle voci di directory. Pertanto, anche in questo caso si può effettuare
un data hiding utilizzando le mere funzionalità del file system.

Allocazione dei cluster

Si è più volte accennato al fatto che NTFS utilizza dei puntatori a un certo numero di cluster
per allocare gli attributi non residenti, ivi compreso l’attributo $DATA che contiene il file stesso.
Si vedrà ora come NTFS allochi effettivamente i cluster nella MFT e come tale meccanismo
possa essere influenzato da vari fattori.
Innanzitutto si esamini l’header standard di un attributo. Si inizia con l’header standard,
valido cioè sia per un attributo residente sia per uno non residente (Tabella 7.10).
Tabella 7.10
Byte occupati Descrizione Obbligatorio
0-3 Identificatore del tipo di attributo. Sì
4-7 Lunghezza dell’attributo. Sì
8-8 Flag (definisce se l’attributo è residente o non residente). Sì
9-9 Lunghezza del nome. Sì
10-11 Offset del nome. Sì
12-13 Flag. Sì
14-15 Identificatore dell’attributo. Sì

L’header standard è seguito da due possibili header. Nel caso di un attributo residente esso
sarà quello della Tabella 7.11.
Tabella 7.11
Byte occupati Descrizione Obbligatorio
16-19 Grandezza del contenuto. Sì
20-21 Offset del contenuto. Sì

Sono quindi elencati solamente due campi che permettono di stabilire la posizione del
contenuto dell’attributo e la sua grandezza.
Un attributo non residente richiede un numero di campi maggiore per poter gestire la
complessità dell’indirizzamento su disco. Questo vale tanto più per l’attributo $DATA con file di
grandi dimensioni, dove il contenuto potrebbe essere frammentato su più zone del disco fisso. I
campi usati sono quelli della Tabella 7.12.
Tabella 7.12
Byte occupati Descrizione Obbligatorio
16-23 Virtual Cluster Number (VCN) dove inizia la runlist. Sì
24-31 VCN di fine della runlist. Sì
32-33 Offset della runlist. Sì
34-35 Grandezza della compression unit. Sì
36-39 Non usato. No
40-47 Grandezza allocata per l’attributo. Sì
48-55 Grandezza attuale dell’attributo. Sì
56-63 Grandezza inizializzata dell’attributo. No

La parte più complessa riguarda il secondo e il terzo campo della tabella. Questi vengono
avvalorati nel momento in cui il campo non residente necessita di una runlist così complessa da
non poter risiedere in una singola entry MFT (tendenzialmente questo accade per file molto
frammentati e/o di grandi dimensioni). In questo caso saranno allocate due o più entry MFT i cui
cluster saranno compresi tra quello iniziale (indicato nei byte 16-23) e quello inserito nei byte da
24a 31.
Nel caso non si rientri in questa specifica situazione la runlist seguirà l’attributo partendo
dall’offset indicato nei byte 32 e 33 dell’header dell’attributo.

Runlist
Il formato della runlist è, di base, molto semplice. Si tratta di una struttura a lunghezza
variabile composta da tre campi (Tabella 7.13).
Tabella 7.13
Campo Descrizione
È composto da un solo byte. I primi 4 bit indicano il numero di byte utilizzati dal secondo campo, i
Header
secondi 4 bit indicano il numero di byte utilizzati per il terzo campo.
Lunghezza Indica il numero di cluster utilizzati in questa runlist.
Cluster Indica il cluster di partenza di questa runlist.

Si veda il seguente esempio. Si pensi a un file chiamato test.txt. Nella MFT vi sarà un
attributo $DATA, non residente, che punterà al contenuto del file stesso. Se tale file fosse contenuto
in cento cluster a partire dal numero 365143 la sua runlist sarebbe (si ricorda che la runlist è
scritta in esadecimale e in formato big endian):
31 64 57 92 05

0x31 = 0011 0001 : i primi 4 bit indicano l’uso di 3 byte per l’offset del cluster e di un bit per
la lunghezza.
0x64: indica una lunghezza di 100 cluster a partire dall’offset.

0x59257: la rappresentazione in esadecimale del cluster 365143.

Nel caso il file fosse frammentato, si troverebbero più runlist, una di seguito all’altra,
indicanti le posizioni dei vari frammenti dei file.
Questo meccanismo, di per sé semplice e lineare, si complica notevolmente con
l’introduzione di tre possibili varianti allo schema, ovvero lo sparse e la compressione.
NTFS impiega lo sparse per minimizzare l’utilizzo di spazio su disco. Se uno o più cluster
contengono solo zeri binari, essi non saranno scritti sul file system ma ne sarà segnato solo il
numero necessario per il ricostruire il file.
Si consideri nuovamente l’esempio del file precedentemente descritto. Si supponga che solo i
primi 30 cluster contengano dati e che gli altri 70 contengano zeri binari. Si troveranno quindi
due distinte run. La prima, supponendo che il file rimanga nella stessa posizione dell’esempio
precedente, sarebbe:
31 1E 57 92 05

0x31 = 0011 0001 : i primi 4 bit indicano l’uso di 3 byte per l’offset del cluster e di un bit per
 la lunghezza.
0x1E: indica una lunghezza di 30 cluster (quelli contenenti dati non a zero) a partire

dall’offset.
0x59257: è la rappresentazione in esadecimale del cluster 365143.

La seconda, che descrive la parte a zero, sarebbe invece:

01 46

: i primi 4 bit sono a zero in quanto nessun cluster è scritto sull’hard disk
0x1 = 0000 0001

essendo questi di tipo sparse. La lunghezza è pari a un byte.

0x46: indica una lunghezza di 70 cluster (contenenti solo zeri) a partire dall’offset.

Non vi è rappresentazione dell’offset.

NTFS supporta nativamente la compressione di un file, senza ricorrere a programmi esterni.
Si noti che si parla di file e non di attributo, in quanto Microsoft stabilisce che l’unico attributo
che supporta la compressione è $DATA, e solo quando questo è dichiarato come non residente.
L’indicazione del fatto che l’entry MFT descrive un file compresso è indicata negli attributi
$STANDARD_INFORMATION e $FILE_NAME.

Il processo di compressione inizia con la suddivisione del file in una serie di parti di uguali
dimensioni.
Si prenda lo stesso file dei precedenti esempi. Si ipotizzi che il sistema scelga di dividere il
file in 4 parti da 25 cluster l’una. La compressione viene applicata a ogni singola parte. I
risultati che si possono ottenere sono i seguenti.
Dopo la compressione tutti i cluster contengono zeri: in questo caso sarà usata una runlist
di tipo sparse.
Il numero di cluster occupati dopo la compressione è lo stesso del file non compresso:
questo può accadere nel caso si tenti di comprimere un file già compresso (.jpg, .avi, .zip e
così via). In questo frangente la compressione non viene applicata.
Il numero di cluster occupati dopo la compressione è inferiore a quello del file non
compresso: viene scritta una runlist relativa alla parte compressa e una runlist di tipo
sparse relativa ai cluster risparmiati con la compressione.
Si riveda quindi l’esempio precedente. La runlist originale, relativa a un file da 100 cluster
che parta dal cluster 365143, sarebbe:
31 64 57 92 05

Si immagini di applicare la compressione al file e che il sistema lo divida in 4 parti da 25

cluster l’una; il risultato è il seguente:
la prima parte viene compressa a 16 cluster totali;
 la seconda parte contiene solo zeri;
la terza parte non è comprimibile;
la quarta parte è compressa a 9 cluster totali.
Le runlist che si otterrebbero sarebbero quindi:
31 10 57 92 05

0x31 = 0011 0001 : i primi 4 bit indicano l’uso di 3 byte per l’offset del cluster e di un bit per
la lunghezza.
0x10 =: indica una lunghezza di 16 cluster a partire dall’offset contenenti dati compressi.

0x59257 =: è la rappresentazione in esadecimale del cluster 365143.

01 09

0x1 = 0000 0001: i primi 4 bit sono a zero in quanto nessun cluster è scritto sull’hard disk
essendo questi di tipo sparse. La lunghezza è pari a un byte.
0x09 =: indica una lunghezza di 09 cluster (contenenti solo zeri) risparmiati comprimendo la

prima parte.
Non vi è rappresentazione dell’offset.
31 19 67 92 05

0x31 = 0011 0001 : i primi 4 bit indicano l’uso di 3 byte per l’offset del cluster e di un bit per
la lunghezza.
0x19 =: indica una lunghezza di 25 cluster a partire dall’offset contenenti dati non

comprimibili della seconda parte.

0x59267 =: è la rappresentazione in esadecimale del cluster 365159 (indirizzo di base + 16

cluster dei dati compressi della prima parte).

01 19

0x1 = 0000 0001: i primi 4 bit sono a zero in quanto nessun cluster è scritto sull’hard disk
essendo questi di tipo sparse. La lunghezza è pari a un byte.
0x09 = : indica una lunghezza di 25 cluster (contenenti solo zeri) ottenuti dalla compressione

della terza parte.

Non vi è rappresentazione dell’offset.
31 09 80 92 05

0x31 = 0011 0001 : i primi 4 bit indicano l’uso di 3 byte per l’offset del cluster e di un bit per
la lunghezza.
0x19 =: indica una lunghezza di 19 cluster a partire dall’offset contenenti dati non

comprimibili della quarta parte.

 0x59280 =: è la rappresentazione in esadecimale del cluster 365184 (indirizzo di base + 16
cluster dei dati compressi della prima parte + 25 cluster incomprimibili della terza parte).
01 06

0x1 = 0000 0001=: i primi 4 bit sono a zero in quanto nessun cluster è scritto sull’hard disk
essendo questi a zero.
0x06 =: indica una lunghezza di 6 cluster (contenenti solo zeri) risparmiati comprimendo la

quarta parte.
Non vi è rappresentazione dell’offset.

Principali attributi nelle entry MFT

Chiarito il funzionamento degli attributi (residenti e non residenti) e di come NTFS alloca i
cluster (compresi i casi relativi a sparse e compressione), si esamineranno ora i principali
attributi che si possono trovare nelle entry MFT. Tali attributi sono quelli che si trovano più
comunemente all’interno della MFT per la descrizione di file e directory.

$STANDARD_INFORMATION
È il primo attributo che solitamente si incontra, avendo esso un identificatore di tipo pari a
16. È sempre di tipo residente e contiene i principali metadati per file e directory. Fornisce le
informazioni riportate nella Tabella 7.14.
Tabella 7.14
Byte
Descrizione Obbligatorio
occupati
0-7 Data e ora di creazione. No
8-15 Data e ora di modifica del file. No
16-23 Data e ora di modifica della MFT. No
24-31 Data e ora dell’ultimo accesso. No
Flag (0x0001 Sola lettura, 0x0002 Nascosto, 0x0004 Sistema, 0x0020 Archivio, 0x0040
32-35 Device, 0x0080 Normale, 0x0100 Temporaneo, 0x0200 Sparse, 0x0400 Reparse point, No
0x0800 Compresso, 0x1000 Offline, 0x2000 Non indicizzato, 0x4000 Crittografato).
36-39 Numero di versioni variate. No
40-43 Numero di versione attuale. No
44-47 ClassID. No
48-51 OwnerID (Windows 2000 e successivi). No
52-55 SecurityID (Windows 2000 e successivi). No
56-63 Quota (Windows 2000 e successivi). No
64-71 Update Sequence Number (Windows 2000 e successivi). No
 $FILE_NAME
L’attributo $FILE_NAME ha due utilizzi primari. Il primo è quello di fornire informazioni alla
MFT riguardanti il file o la directory cui si riferisce. Il secondo è quello di fornire dati al
sistema di indici gestito da NTFS per migliorare la velocità di ricerca. Contiene
sostanzialmente i campi riguardanti il nome del file o della directory, alcuni metadati e una
copia dei dati di timing inclusi in $STANDARD_INFORMATION (Tabella 7.15).
Tabella 7.15
Byte
Descrizione Obbligatorio
occupati
0-7 Riferimento alla directory di appartenenza. No
8-15 Data e ora di creazione del file. No
16-23 Data e ora di modifica del file. No
24-31 Data e ora di modifica della MFT. No
32-39 Data e ora dell’ultimo accesso. No
40-47 Grandezza allocata per il file. No
48-55 Grandezza reale del file. No
Flag (0x0001 Sola lettura, 0x0002 Nascosto, 0x0004 Sistema, 0x0020 Archivio, 0x0040
56-59 Device, 0x0080 Normale, 0x0100 Temporaneo, 0x0200 Sparse, 0x0400 Reparse point, No
0x0800 Compresso, 0x1000 Offline, 0x2000 Non indicizzato, 0x4000 Crittografato).

60-63 Valore di reparse. No

Sì per una
64-64 Lunghezza del nome. directory No
per un file
Namespace: 0=POSIX: Case sensitive, permette Unicode tranne che per NULL e lo slash
(/). 1=WIN32: Case sensitive, permette Unicode tranne per \, /, <, > e ?. 2=DOS: Case Sì per una
65-65 insensitive, è scritto tutto in maiuscolo, solo set ASCII, 8.3 caratteri per il nome file. directory No
3=DOS e WIN32. Viene settato se il nome DOS è sufficiente per Win32 e non è richiesto per un file
quindi un nome di file lungo.
Sì per una
66-... Nome del file. directory No
per un file

$ATTRIBUTE_LIST
Si incontra nel momento in cui è necessario utilizzare più entry MFT per salvare tutti gli
attributi relativi a un file o a una directory. In questo caso $ATTRIBUTE_LIST conterrà la lista delle
entry MFT e degli attributi in esse contenuti, così da velocizzare il lavoro di localizzazione
degli stessi (Tabella 7.16).
Tabella 7.16
Byte occupati Descrizione Obbligatorio
0-3 Identificatore del tipo di attributo. Sì
4-5 Lunghezza dell’entry MFT. Sì
6-6 Lunghezza del nome. Sì
7-7 Offset del nome. Sì
8-15 VCN dell’entry MFT dove si trova l’attributo. Sì
16-23 Riferimento al file dove è localizzato l’attributo. Sì
24-24 Attribute ID (spesso a zero). Sì

$OBJECT_ID
NTFS non si riferisce praticamente mai al nome del file. Al suo posto utilizza un
identificatore a 128 bit che identifica univocamente tale file. Le applicazioni sono incoraggiate a
utilizzare questa informazione al loro interno. In questo caso, se l’utente dovesse decidere di
cambiare il nome del file, esso sarebbe ancora correttamente puntato da tutte le applicazioni che
ne hanno necessità. Solitamente solo il primo dei quattro campi di questo attributo è avvalorato.
Si veda la Tabella 7.17.
Tabella 7.17
Byte occupati Descrizione Obbligatorio
0-15 ObjectID. Sì
16-31 ObjectID del volume di creazione. No
32-47 ObjectID di creazione. No
48-63 DomainID di creazione. No

$REPARSE_POINT
Questo attributo è stato inserito per permettere l’aggiunta di varie funzionalità al file system
NTFS. È presente dalla versione 3.0 del file systems e, per ora, è stato utilizzato per
l’implementazione di alcune funzioni specifiche quali i symbolic link, i directory junction point
e i volume mount point.

Symbolic link
Sono stati introdotti inizialmente per facilitare la migrazione delle applicazioni dal mondo
Unix. Si tratta di un oggetto sé non legato in alcun modo con il file (o la directory a cui punta).
Questo implica che se il file (o directory) originale viene eliminato il link simbolico continuerà
a esistere (in quanto oggetto a sé stante) pur non puntando ad alcun file.
I link simbolici possono puntare a qualunque oggetto che sia raggiungibile tramite UNC,
quindi anche a file
Con l’uscita di Windows Vista i link simbolici si sono ulteriormente evoluti e ora possono
puntare non solo a file ma anche a directory.

Indici
NTFS utilizza il concetto di indice mutuandolo dai database relazionali. Molti degli attributi
contenuti nella MFT (dalla versione 3.0 di NTFS in avanti) sono gestiti attraverso un sistema di
indici e di alberi binari così da migliorare considerevolmente la velocità di ricerca dei dati in
essi contenuti.
Il funzionamento di tali indici è lungi dall’essere banale, per cui richiede una trattazione
specifica. Per prima cosa, con “indice” ci si riferisce a un insieme di attributi salvati in modo
ordinato. Tipicamente, questo è usato per le directory, dove, come già evidenziato, l’attributo
$FILE_NAME è obbligatorio nella loro definizione. Altri attributi che utilizzano gli indici sono gli

attributi di sicurezza o le quote.

NTFS gestisce gli indici tramite un B-Tree. La definizione che ne dà Wikipedia è la seguente:
I B-Alberi (o B-Tree) sono strutture dati ad albero; vengono comunemente utilizzati nell’ambito di database e file system.
Essi derivano dagli alberi di ricerca, in quanto ogni chiave appartenente al sottoalbero sinistro di un nodo è di valore inferiore
rispetto a ogni chiave appartenente ai sottoalberi alla sua destra; derivano anche dagli alberi bilanciati perché tutte le foglie
si trovano alla stessa distanza rispetto alla radice. Il vantaggio principale dei B-Tree è che essi mantengono
automaticamente i nodi bilanciati permettendo operazioni di inserimento, cancellazione e ricerca in tempi ammortizzati
logaritmicamente.

A livello di NTFS, i singoli nodi dell’albero sono gestiti con delle comuni entry MFT
contenenti una serie di attributi specifici.
$INDEX_ROOT: è usato per indici di dimensioni molto piccole ed è sempre un attributo di tipo
residente. Può contenere un solo nodo con un numero contenuto di entry. Come si deduce
dal nome, $INDEX_ROOT è l’attributo che contiene il node entry della radice dell’albero.
$INDEX_ALLOCATION: permette di allocare gli indici in una struttura esterna arbitrariamente

grande, contenente un numero non definito di nodi. Non è possibile trovare un’entry MFT
che contenga solo questo attributo, che si trova sempre in coppia con $INDEX_ROOT.
Quest’ultimo stabilirà la radice dell’albero e alcune delle sue entry, invece di essere
residenti, punteranno a quelle definite tramite l’attributo $INDEX_ALLOCATION.
Entrambi gli attributi hanno un nome che li identifica. Il nome scelto per gli attributi di
indicizzazione di una qualunque directory è $I30.
All’interno dell’entry MFT si troverà quindi un header che descrive l’attributo di indice usato
($INDEX_ROOT o $INDEX_ALLOCATION).
Tabella 7.18
Byte occupati Descrizione Obbligatorio
0-3 Identificatore del tipo di attributo indicizzato. Sì
4-7 Tipo di ordinamento dell’albero. Sì
8-11 Grandezza di ogni record dell’indice espressa in byte. Sì
12-12 Grandezza di ogni record dell’indice espressa in cluster. Sì
13-15 Non utilizzati. No
 $INDEX_ROOT header
L’header di $INDEX_ROOT sarà seguito da un unico node header e da un limitato numero di index
entry. $INDEX_ALLOCATION conterrà invece strutture tipo “index header”. Queste possono essere
salvate anche in modo non ordinato. Tali index header punteranno a cluster esterni che
conterranno i node header e le directory entry per ciascun header.
L’index record header ha la struttura mostrata nella Tabella 7.19.
Tabella 7.19
Byte occupati Descrizione Obbligatorio
0-3 Signature (INDX). No
4-5 Offset all’array di fixup. Sì
6-7 Numero di entry nell’array di fixup. Sì
8-15 Numero di sequenza per il journal ($LogFile). No
16-23 VCN di questo record nell’index stream. Sì

L’index header, come già specificato, punta a strutture esterne formate da un node header e da
diverse index entry. La struttura del node header è mostrata nella Tabella 7.20.
Tabella 7.20
Byte occupati Descrizione Obbligatorio
0-3 Offset di partenza dell’entry list (l’indirizzo è relativo all’inizio del node header). Sì
4-7 Offset della fine dello spazio utilizzato dall’entry list. Sì
8-11 Offset della fine dello spazio allocato per l’entry list. Sì
12-15 Flag. No

NOTA
Gli indici fanno parte di quelle strutture dati che utilizzano la funzione di fixup. È un sistema per controllare che
strutture dati essenziali non contengano dati errati a causa di un problema sul file system. Il sistema genera una
signature a 16 bit che è specifica per quella struttura dati. Essa viene scritta in testa alla struttura, seguita da un
array di fixup. Gli ultimi due byte di ogni cluster sono sostituiti dalla signature generata in precedenza. Il
contenuto originale di questi byte sarà inserito nell’array posto tra la signature e i dati. Quando il sistema dovrà
esaminare la struttura dati verificherà che ogni cluster contenga la signature di fixup. Verificata la correttezza
della signature, la struttura dati sarà letta per intero sostituendo i byte contenenti la signature con il contenuto
originale posto nell’array di fixup.

Le singole entry seguono quindi il node header. La struttura nelle index entry varia a seconda
dei record che è necessario indicizzare. Non è dunque possibile specificare una struttura che
possa essere uguale per ogni tipo di attributo.
L’attributo $INDEX_ALLOCATION è collegato con l’attributo $BITMAP che indica al sistema quali index
record sono effettivamente allocati per memorizzare un attributo. Tale informazione è utile
specialmente dopo cancellazioni di grandi quantità di file, che possono lasciare dei record
inutilizzati all’interno delle strutture dati allocate per gli indici.
 Strutture di metadati esterne
Come si è potuto notare precedentemente, le prime entry del file $MFT descrivono una serie di
altri file dove NTFS conserva la maggior parte dei metadati. Alcuni di questi sono
particolarmente importanti dal punto di vista dell’analisi forense in quanto descrivono
avvenimenti precedentemente accaduti o luoghi ove possono essere nascosti dati importanti.

File $BOOT
È la rappresentazione, come file, del boot sector locato al cluster 0.

File $ATTR_DEF
Questo file contiene una serie di entry che definiscono e specificano tutti gli attributi usati
all’interno della MFT. La struttura usata è indicata nella Tabella 7.21.
Tabella 7.21
Byte
Descrizione Obbligatorio
occupati
0-127 Nome dell’attributo. Sì
128-131 Identificatore del tipo. Sì
132-135 Regola per la sua visualizzazione. No
136-139 Regola di ordinamento quando fa parte di un indice. No
Flag: 0x02: può essere indicizzato. 0x04: è sempre residente. 0x08: è sempre non
140-143 Sì
residente.
144-151 Grandezza minima. No
152-159 Grandezza massima. No

File $BITMAP
Da non confondere con l’attributo $BITMAP, questo file contiene una mappa dettagliata dello
stato di allocazione di ogni cluster posto all’interno del file system. Il file è organizzato con una
serie di valori da 1 byte. Tale valore è una mappa di bit e va letta da destra a sinistra (ovvero
dal bit meno significativo al più significativo). Se il bit è a 0 il cluster non è allocato, se è a 1 il
cluster è allocato.
Si veda il seguente esempio, che riproduce i primi byte di un ipotetico file $BITMAP:
41 64 E2 12 05 (Rappresentazione esadecimale)
0x41 = 01000001
0x64 = 01100100
0xE2 = 11100010
0x12 = 00010010
0x05 = 00000101

Il valore 0x41 rappresenta lo stato dei primi 8 cluster. Leggendolo da destra a sinistra si
ottiene:
0x41 = 01000001
 Cluster 0 Allocato 1
Cluster 1 Non allocato 0

Cluster 2 Non allocato 0

Cluster 3 Non allocato 0

Cluster 4 Non allocato 0

Cluster 6 Allocato 1

Cluster 7 Non allocato 0

Per trovare lo stato di allocazione di un cluster attraverso il file $BITMAP si procede nel
seguente modo.
1. Si prende il numero identificativo del cluster (per esempio, 768431).
2. Si divide il numero per 8 (per esempio, 768431/8 = 96053). In questo modo si trova il byte
dentro cui è la bitmap per quel cluster.
3. Si utilizza il resto della divisione (0 in questo caso) per trovare il bit che rappresenta
l’allocazione di quel caso (per esempio, 0 = il primo bit partendo da destra).

File $VOLUME
È descritto nella terza entry della MFT e ha due soli attributi. Ciò significa che il file è
totalmente residente all’interno dell’entry MFT che lo descrive.
Il primo attributo è $VOLUME_NAME. È di tipo residente e contiene il nome del volume come una
stringa codificata in UTF-16.
Il secondo è $VOLUME_INFORMATION: contiene la versione e lo stato del file system, secondo il
formato indicato nella Tabella 7.22.
Tabella 7.22
Byte occupati Descrizione Obbligatorio
0-7 Non usati. No
Major number:
8-8 1 per NT. Sì
3 per 2000/2003/XP.

Minor number:
2 per NT.
9-9 Sì
0 per 2000.
1 per 2003/XP.

Flag: 0x0001 Stato Dirty.

0x0002 $Logfile ridimensionato.
0x0004 Aggiornare il file system al prossimo reboot.
10-11 0x0008 Montato in NT. No
0x0010 Cancellato il giornale delle modifiche.
0x0020 Riparare gli ObjectID.
0x8000 Riparato da chkdsk.
 File $OBJID
NTFS, al suo interno, utilizza un codice univoco per identificare ogni singolo file. In questo
modo il file può essere liberamente spostato e rinominato senza che l’applicazione che lo
utilizza abbia problemi a rintracciarlo.
Il file $OBJID contiene al suo interno una tabella che permette di fare il match tra l’ObjectID del
file e l’entry MFT che lo descrive (Tabella 7.23).
Tabella 7.23
Byte occupati Descrizione Obbligatorio
0-1 Offset alle informazioni sul file. Sì
2-3 Grandezza delle informazioni sul file. Sì
4-7 Non usati. No
8-9 Grandezza dell’entry per l’indice. Sì
10-11 Grandezza dell’ObjectID. Sì
Flag:
12-15 0x01 Esiste un “child node” Sì
0x02 Ultima entry dell’indice.

16-31 ObjectID. Sì
32-39 Puntatore all’entry MFT del file. Sì
40-55 ID del volume di creazione. No
56-71 ObjectID di creazione. No
72-87 ObjectID del dominio di creazione. No

File $Quota
Le quote disco sono un’aggiunta recente (Windows 2000) a NTFS. Non per nulla il file di
quota si trova nella directory $EXTEND, dove sono posti i file relativi alle caratteristiche
aggiuntive del file system.
Il file $QUOTA è totalmente indicizzato. Contiene due tipi di record fondamentali:
$O: correla l’OwnerID con il SID (identificatore unico di un account usato nei sistemi
Windows);
$Q: correla l’OwnerID con le informazioni di quota.

Le strutture dei due tipi di index entry sono mostrate nelle Tabelle 7.24 e 7.25.
Tabella 7.24 Struttura del record $0
Byte occupati Descrizione Obbligatorio
0-1 Offset all’OwnerID. Sì
2-3 Lunghezza dell’OwnerID. Sì
4-7 Non usati. No
8-9 Grandezza dell’index entry. Sì
10-11 Grandezza del SID (GS). Sì
 Flag:
12-15 0x01 Esiste un “child node”. Sì
0x02 Ultima entry dell’indice.

16-(16+GS-1) SID. Sì
Offset byte 0-1 OwnerID. Sì

Tabella 7.25 Struttura del record $Q

Byte occupati Descrizione Obbligatorio
0-1 Offset all’OwnerID. Sì
2-3 Lunghezza dell’OwnerID. Sì
4-7 Non usati. No
8-9 Grandezza dell’index entry. Sì
10-11 Grandezza dell’OwnerID. Sì
Flag:
12-15 0x01: Esiste un “child node” Sì
0x02: Ultima entry dell’indice.

16-19 OwnerID. Sì
20-23 Versione. No
Flag:
0x0000001 Utilizzo dei limiti di default.
0x0000002 Limite raggiunto.
0x0000004 ID cancellato.
0x0000010 Tracciatura dei dati usati.
0x0000020 Enforce dei dati usati.
24-27 Sì
0x0000040 Richiesta di tracciatura dati.
0x0000080 Creazione di un log al raggiungimento di soglia.
0x0000100 Creazione di un log al raggiungimento del limite.
0x0000200 Non più aggiornato.
0x0000400 Corrotto.
0x0000800 Cancellazioni in coda.
28-35 Byte utilizzati dall’utente. Sì
36-43 Ora di ultima modifica. No
44-51 Limite di quota (soft). Sì
52-59 Limite di quota (hard). Sì
60-67 Ora di superamento quota. Sì
68-79 SID. Sì

File $LOGFILE
$LOGFILE è descritto nella seconda entry della MFT. È il journal del file system NTFS. Il

problema principale con questo specifico file è che la sua struttura non è nota, e Microsoft non
ne ha mai documentato esattamente il formato. Tramite prove empiriche si è notato che contiene
i dati relativi agli ultimi file per i quali sono state compiute delle operazioni di scrittura, ivi
compresa una parte del contenuto di questi ultimi. La struttura però non appare fissa ma soggetta
a mutazioni che possono essere determinate da una serie di fattori quali il tipo di operazione
compiuta e la dimensione del file stesso.
 È altresì vero che ormai la totalità dei programmi di analisi forense commerciale è in grado
di fare il parsing corretto del giornale e di estrarre le informazioni contenute al suo interno. Si
presti però attenzione che non è possibile dare in pasto al software il solo $LOGFILE e la relativa
$MFT. È necessario che vi sia l’immagine dell’intero file system per poter avviare
l’elaborazione del $LOGFILE.

File $USRJRNL
Il file $USRJRNL registra i cambiamenti fatti sui file presenti nel file system all’interno di un
attributo chiamato $J, contenuto a sua volta nella porzione $DATA del file $USRJRNL. La struttura
dell’attributo $J è riassunta nella Tabella 7.26.

Caratteristiche avanzate
Windows Vista e Windows Server 2008 hanno portato NTFS a un notevole livello di maturità
(ulteriormente consolidato con 7 e Windows Server 2008 R2). Molte caratteristiche avanzate
dei vari file system sono state aggiunte a NTFS.
In primis è necessario citare il supporto per le transazioni. Il sistema sfrutta un nuovo modulo
del kernel di Windows Vista e Windows 2008 Server, detto Kernel Transaction Manager
(KTM).
In pratica, una o più operazioni di scrittura possono essere definite come “atomiche”. Il
sistema si incaricherà di controllare che tutte vadano correttamente in porto (scrittura
completata con successo) o, in caso che anche una sola di esse non vada a buon fine, che l’intero
gruppo sia eliminato e il file system torni allo stato precedente (rollback, ovvero scrittura
fallita).
Tabella 7.26
Byte occupati Descrizione Obbligatorio
0-3 Grandezza di questa entry del journal. Sì
4-5 Major number della versione. Sì
6-7 Minor number della versione. Sì
8-15 File reference al file di cui si stanno documentando i cambiamenti. Sì
16-23 File reference alla parent directory del file. No
24-31 USN per questa entry. Sì
32-39 Timestamp. Sì
Flag per il tipo di cambiamento:
0x00000001 L’attributo $DATA è stato sovrascritto.
0x00000002 L’attributo $DATA è stato esteso.
0x00000004 L’attributo $DATA è stato troncato.
0x00000010 Un ADS è stato sovrascritto.
0x00000020 Un ADS è stato esteso.
0x00000040 Un ADS è stato troncato.
 0x00000100 Una directory o un file è stato creato.
0x00000200 Una directory o un file è stato cancellato.
0x00000400 Sono cambiati gli attributi estesi.
0x00000800 È cambiato il Security Descriptor.
40-43 0x00001000 Il nome è cambiato, la corrispondente entry Sì
nel journal ha il vecchio nome.
0x00002000 Il nome è cambiato, la corrispondente entry
nel journal ha il nuovo nome.
0x00004000 È cambiato il contenuto degli indici.
0x00008000 Sono cambiati gli attributi base.
0x00010000 È stato creato o cancellato un hard link.
0x00020000 È cambiato lo stato di compressione.
0x00040000 È cambiato lo stato di cifratura.
0x00080000 L’Object ID è cambiato.
0x00100000 Il valore del reparse point è cambiato.
0x00200000 Un ADS è stato creato, cancellato o cambiato.
0x80000000 La directory o il file è stato chiuso.

44-47 Informazioni. No
48-51 SID. No
52-55 Attributi del file. No
56-57 Grandezza del nome file. Sì
58+ Nome file. Sì

Le operazioni possono avvenire su singolo file, su file e directory multiple o, usando il

modulo Distributed Transaction Coordinator, addirittura sparpagliate su un certo numero di
computer collegati in rete. Con Windows 2008 Server (o con il Service Pack 1 di Vista) tale
meccanismo è stato implementato anche all’interno di EFS.
Il nuovo file system introduce anche il supporto ai link simbolici in maniera del tutto identica
a quanto accade, da anni, nel mondo Unix. Il link simbolico può puntare sia a un oggetto sullo
stesso file system, sia a un oggetto su un altro file system NTFS (per esempio una directory su un
altro drive), sia a un oggetto disponibile attraverso una condivisione di rete (SMB). I link
simbolici, come molte delle recenti estensioni al file system NTFS, sono gestiti tramite un
apposito campo nel file $Reparse sotto la directory $Extend dove, come abbiamo visto, finiscono
tutte le estensioni del file system. Questo approccio permette ora anche a vecchi sistemi
operativi/utility di vedere il file system (anche se aggiornato), seppur con qualche feature in
meno.

VSC
Il servizio di Virtual Shadow Copy (VSC) è stato introdotto con Windows Vista e consolidato
con le successive release di Windows, per giungere a un notevole livello di maturità con
Windows 8 e Windows 2012 Server.
NOTA
Tutto il servizio di backup nativo di Windows 8 (noto come Cronologia file) utilizza il servizio VSC come base
per il suo funzionamento.
 VSC è interessante non solo per come ha implementato una feature utilissima ma anche perché
è una panacea per qualunque investigatore digitale.
Ora si esamineranno una serie di concetti generali e poi si vedrà come sono stati implementati
all’interno del servizio specifico di Microsoft.
Partendo dalle origini, uno dei maggiori problemi che da sempre affliggono l’IT riguarda il
backup. Croce di qualunque sysadmin, nel momento in cui l’infrastruttura diventa complessa
richiede notevoli risorse sia di tempo sia economiche per essere davvero utile. In particolare
due problemi diventano seccanti. Per iniziare, l’ampiezza delle finestre di backup. In un sistema
informativo moderno la quantità di dati continua a crescere e quindi il salvataggio degli stessi
richiede sempre più tempo. Si può cambiare la politica di backup in modo da ridurre al minimo
la quantità di dati da dover salvare per ogni singola sessione ma spesso è solo un palliativo.
Infatti viene chiesto sempre più insistentemente che i dati siano disponibili 24 ore su 24 e questo
ha ovviamente impatti su tutta la strategia di backup dell’azienda.
Oltre a questo spesso si deve eseguire il backup di dati complessi (tipicamente sistemi di
database) e, per riuscire a creare un backup consistente è necessario fermare il servizio (con
impatti sulla produttività) oppure usare dei complessi agent di backup in grado di dialogare con
le singole applicazioni per poter intervenire a gestire problematiche relative a file aperti, record
lock, table lock e altro.
Per ovviare a tutti questi problemi si è ricorso via via a una serie di tecnologie sempre più
sofisticate, ma specialmente all’uso delle funzioni di snapshot e di Copy-on-Write.
Gli snapshot permettono di prendere una copia consistente dell’intero file system in una
manciata di secondi e di poter quindi procedere al backup mentre il sistema è in produzione. Gli
eventuali agent specifici per le applicazioni dovranno dialogare solo con il sistema operativo e
dovranno sospendere l’attività dell’applicazione per un tempo decisamente inferiore.
Altro vantaggio degli snapshot è il fatto che fare un revert (ovvero ripristinare una situazione
precedente) è un’operazione altrettanto veloce e sicura. È quindi possibile utilizzare tale
funzioni nel caso si debbano eseguire operazioni critiche, come il patching o l’installazione di
applicativi o framework complessi.
In molti sistemi operativi tali funzioni sono implementate a livello di Volume Manager. Linux,
per esempio, le incorpora solo nel caso si usi LVM oppure con il file system btrfs.
Gli snapshot sono estesamente usati in tutti gli hypervisor, e difatti molti di essi dispongono di
API specifiche per il dialogo con gli storage.
Molti sistemi di storage (primo tra tutti NetApp, che ne ha fatto un suo cavallo di battaglia)
dispongono di funzioni di snapshot a basso livello e che lavorano a livello di LUN. Quindi si è
pensato bene di legare le funzioni di snapshot a livello di Volume Manager con quelle
disponibili in hardware dello storage così da poter disporre di un sistema ancora più duttile e
veloce.
 Microsoft ha fatto la stessa cosa con il suo servizio di VSC. Diciamo innanzitutto che si tratta
di un sistema di snapshot basato su una serie di API pubblicate dal sistema operativo e che
funziona solo su file system NTFS.
Gli attori in gioco sono due: il primo è il requester. Può essere un’utility del sistema
operativo stesso o anche un applicativo che necessiti delle funzioni di snapshot (accessibili via
API di sistema).
Il secondo è il provider, ovvero colui che realmente fornisce il servizio. Tale provider può
essere sia software sia hardware-assisted. Questo vuol dire che, in mancanza di un hardware
specializzato, esso funzionerà tramite delle specifiche routine contenute nel kernel. Nel caso,
invece, della presenza di un hardware certificato, il kernel dialogherà con lo storage per
demandare tutte le operazioni a quest’ultimo. Inutile dire che il risultato per il Digital Forensics
expert sarà totalmente differente. Nel primo caso gli snapshot saranno oggetti contenuti
all’interno di un file system (tipicamente un file system diverso da quello di origine dei dati) e
potrà essere relativamente semplice sia accertare la loro presenza sia il loro contenuto. Nel
secondo sarà necessario conoscere profondamente come tale funzione sia implementata
all’interno dello specifico storage sul quale si sta operando. Il servizio VSC hardware-assisted
rimappa infatti le funzioni richieste su quelle presenti all’interno dello storage. Chi conosce
questo mondo sa che ogni vendor implementa le funzioni base nei modi più diversi.
Le modalità di funzionamento di VSC (indipendentemente dalla loro implementazione in
hardware o in software) sono due.
Full copy/split mirror: nel momento in cui viene richiesto lo snapshot il contenuto di tutto
il disco viene copiato in un’apposita area. Al termine il disco continuerà a lavorare
normalmente mentre la copia sarà mantenuta secondo una serie di criteri stabiliti
dall’amministratore.
Copy-on-Write: funzione specifica di molti moderni file system ad oggetti, permette di
prendere uno snapshot in tempi rapidissimi. Dal momento in cui viene chiesto lo snapshot
con questa tecnica, il sistema inizia a tracciare le attività del disco. Quando si presenta la
necessità di variare un blocco tra quelli inclusi nello snapshot, tale blocco sarà prima
copiato in un’apposita area, poi sovrascritto. Rimane quindi implicito che uno snapshot
quando richiede una quantità di spazio prossima allo zero nel momento in cui viene preso.
Nel corso del tempo maggiori saranno le modifiche all’interno del volume sottoposto a
snapshot, maggiori saranno le dimensioni dello stesso.
Transfer-on-Write: simile alla funzione Copy-on-Write come logica, funziona nella stessa
maniera ma con la differenza che i blocchi non vengono copiati nello stesso disco quanto
piuttosto trasferiti su un altro volume.
Ciò che più interessa a un Digital Forensics expert è il fatto che questo servizio non solo è
sfruttato per le funzioni di backup ma anche dal servizio che gestisce i punti di ripristino. A
partire da Windows 7, infatti, il sistema operativo crea un punto di ripristino almeno una volta
alla settimana. Ulteriori punti di ripristino possono essere creati anche dagli installer delle
applicazioni in modo che sia possibile tornare alla situazione precedente l’installazione. Alla
luce di tutto questo, all’interno di questi snapshot si possono trovare file e directory che, per
esempio, sono stati cancellati recentemente, anche se i settori di appartenenza sono stati rimossi.
Il repository usato comunemente da VSC è la directory System Volume Information (almeno
per quanto riguarda gli snapshot di tipo Copy-on-Write), mentre può essere specificato per
quanto riguarda le funzioni di split mirror e di Transfer-on-Write.
Si noti che i file creati dal sistema VSC non sono da intendersi come una copia dei file
cancellati o modificati, quanto piuttosto come una concatenazione delle copie dei blocchi che
sono stati sovrascritti su disco dal momento in cui è stato preso lo snapshot. Questo ci può far
capire come l’idea di usare strumenti di analisi o recovery come il carving su questi file rischi
di non portare ad alcun risultato utile. Sarà quindi necessario virtualizzare la macchine e usare
le funzioni interne del sistema operativo oppure utilizzare un software di analisi forense che
supporti il VSC (tutti i principali pacchetti commerciali permettono di gestire questa feature).

Ext2,Ext3 ed Ext4
Ext2, Ext3 ed Ext4 sono tre file system usatissimi nel mondo Linux. Ext2 è stato per anni il
file system di riferimento e, in pratica, l’unico utilizzato come nativo. Quando la tecnologia
cominciò a spostarsi verso file system dotati di journal, nacquero vari progetti per far fronte a
questa mancanza, quindi arrivarono ReiserFS, XFS, JFS ed Ext3. Quest’ultimo nacque come
evoluzione di Ext2 e per essere compatibile con esso. Infatti, un file system Ext3 può essere
montato anche da un vecchio kernel in modalità Ext2 e tutte le utility sviluppate specificamente
per Ext2, compresi molti undeleter, possono essere utilizzate sul nuovo Ext3.

Ext4
Ext4 non nasce come un nuovo file system ma piuttosto come una serie di estensioni
retrocompatibili per migliorare le performance e superare i limiti di Ext3. Molti criticarono
questa scelta e alla fine si decise di effettuare un fork del file system. Il nuovo Ext4 comparve
come development file system nella versione 2.6.19 del kernel e fu considerato stabile con la
versione 2.6.28.
In questa parte saranno elencate le nuove caratteristiche del file system. Da un punto di vista
relativo alla Digital Forensics, l’analisi di un file system Ext4 è del tutto identica a quella di un
Ext3. Addirittura, se non sono state usate le funzioni di extent, sarà possibile montare un file
system Ext4 come fosse un Ext3 e utilizzare tutte le utility relative a quest’ultimo.
Le principali aggiunte di Ext4 sono le seguenti.
Address Space: Ext4 estende l’indirizzamento di Ext2/3 da 32 bit a 48 bit. Tutto il sistema
è inoltre concepito per poter arrivare fino a 64 bit di indirizzamento, anche se tale feature
non è al momento nemmeno contemplata in RoadMap (potrebbe essere inserita in un
ipotetico Ext5). Utilizzando 48 bit i limiti del file system sono innalzati a 16 TB per
singolo file e fino a 1 EB per file system.
Extent: la gestione del mapping indiretto tipica dei file system Unix si rivela molto
inefficiente per file contigui di grandi dimensioni. In questo caso il mapping tende a
crescere considerevolmente e diventa molto lento da gestire. Inoltre ha un pesante impatto
a livello di I/O durante molte operazioni di scrittura e cancellazione in quanto il mapping
deve essere aggiornato dopo la scrittura di ogni singolo blocco. Un extent è un insieme
logico di blocchi contigui della grandezza massima di 128 MB. È mappato come un singolo
blocco e quindi riduce drasticamente il numero di operazioni necessarie per la sua
gestione.
Mballoc: al contrario dei suoi predecessori Ext4 non richiede di allocare i blocchi uno
alla volta ma permette all’allocatore di richiedere un numero variabile di blocchi (vale
anche per gli extent) per ogni singola chiamata. Supponendo di dover scrivere un file da
300 MB su un file system con blocchi da 4 k (standard) in Ext2/3 l’allocatore sarà
richiamato 76.800 volte. Al contrario con Ext4, usando l’allocatore multiblocco e gli
extent, basterà un’unica operazione.
Allocation Delayed: Ext4 alloca lo spazio necessario per la scrittura di un file solamente
nel momento in cui viene effettuato il flush della cache. Tale approccio permette di gestire
le variazioni di grandezza dei singoli file in maniera più coerente rispetto a file system che
allocano immediatamente lo spazio che occorre per un file. Si pensi per esempio alla
scrittura di un file temporaneo. Il file viene aperto, riempito e poi cancellato. Ext2/3 in
questo caso allocano immediatamente tutto lo spazio necessario al file, indipendentemente
dal fatto che questo poi continui a crescere, venga ridotto oppure cancellato. Ext4 al
contrario potrebbe, nel migliore dei casi, non allocare mai tale spazio, in quanto il file
potrebbe essere cancellato prima che effettui il flush su disco.
Preallocation: per alcune applicazioni, al contrario di quanto spiegato nel paragrafo
precedente, occorre allocare immediatamente tutto lo spazio necessario (tipicamente i vari
software di download P2P). Ext4 permette di effettuare questa operazione.
Directory Limit: è ora possibile superare il limite di 32.000 sottodirectory per singola
cartella.
Online defrag.
Fast checksum.
 Caratteristiche comuni
Ext2/3/4 sono sviluppati sulla logica del classico file system UFS di Unix BSD. Rispetto a
quest’ultimo, molte strutture logiche e molti componenti non più utili sono stati sfrondati,
ottenendo un file system più snello e semplice da gestire.
La struttura di Ext2/3/4 è piuttosto semplice e lineare. I primi 1024 byte del file system (2
cluster) sono lasciati liberi per caricarvi un boot code (opzionalmente ora è possibile integrare i
boot loader LILO e GRUB direttamente nel master boot record). I successivi due cluster sono
occupati dal superblock. Il superblock è una struttura fondamentale del file system e contiene
informazioni vitali per il suo funzionamento. La sua importanza è tale che varie copie di esso
sono salvate all’interno di tutto il file system.
A seguito del superblock iniziale vi può essere una reserved area opzionale, seguita da quella
che è la struttura fondamentale del file system, ovvero il block group. Tutta l’area del file
system compresa tra la reserved area e la fine del file system è divisa in block group. Essi,
tranne l’ultimo, contengono tutti lo stesso numero di blocchi (ogni blocco è un insieme atomico
di cluster e ha una dimensione che varia da 1024 a 4096 byte, ovvero da 2 a 8 cluster).
In ogni block group sono contenuti una copia del superblock (a meno che non sia attiva la
sparse option, nel qual caso solo alcuni block group contengono tali copie di backup), la group
description table, la block bitmap, la inode bitmap, la inode table e il file content.

Il superblock
Il superblock è la struttura primaria del file system. Come già detto, occupa due cluster (anche
se i dati realmente usati nel superblock sono molto inferiori) e parte dopo 1024 byte dall’inizio
del file system. In teoria vi è una copia del superblock in ogni block group del file system. In
pratica i moderni kernel di Linux attivano la cosiddetta sparse option che fa sì che solamente
alcuni specifici block group ne contengano una copia (Tabella 7.27).
Si notino i flag contenuti nei byte da 92 a 103. Essi determinano la presenza di una serie di
caratteristiche aggiuntive che possono influenzare il comportamento del sistema operativo di
fronte a un’operazione di mount.
Le caratteristiche compatibili non pregiudicano il montaggio in modalità read/write anche se
il sistema operativo non le supporta. Le caratteristiche incompatibili fanno sì che il sistema
operativo rifiuti di montare il file system se non è in grado di supportarle. Le caratteristiche di
compatibilità in sola lettura permettono al sistema operativo di montare il file system in tale
modalità se le caratteristiche qui elencate non sono supportate.
Tabella 7.27
Byte
Descrizione Obbligatorio
occupati
0-3 Numero di inode nel file system Sì
4-7 Numero di blocchi nel file system. Sì
8-11 Numero di blocchi riservati per prevenire il riempimento del file system. No
12-15 Numero di blocchi non allocati. No
16-19 Numero di inode non allocati. No
20-23 Blocco di partenza del block group 0. Sì
24-27 Grandezza dei blocchi. Sì
28-31 Grandezza dei frammenti. Sì
32-35 Numero di blocchi in ogni block group. Sì
36-39 Numero di frammenti in ogni block group. Sì
40-43 Numero di inode in ogni block group. Sì
44-47 Data e ora dell’ultimo montaggio. No
48-51 Data e ora dell’ultima modifica. No
52-53 Numero di montaggi effettuati. No
54-55 Massimo numero di montaggi. No
56-57 Signature (valore fisso a 0xef53). No
Stato del file system:
0x0001 Clean.
58-59 No
0x0002 Errori presenti nel file system.
0x0004 I problemi con gli inode orfani è stato corretto.

Metodo di gestione degli errori:

0x1 Continua e ignora.
60-61 No
0x2 Rimontare il file system in sola lettura.
0x3 File system Panic.

62-63 Minor version. No

64-67 Data e ora dell’ultimo controllo di integrità. No
68-71 Intervallo massimo tra un controllo di consistenza e l’altro. No
Sistema operativo che ha creato il file system:
0x0 Linux.
0x1 GNU Hurd.
72-75 No
0x2 Masix.
0x3 FreeBSD.
0x4 Lites.

76-79 Major version. Sì

80-81 UID che può utilizzare i blocchi riservati. No
82-83 GID che può usare i blocchi riservati. No
84-87 Primo inode della zona non riservata del file system. No
88-89 Grandezza di una singola struttura di inode. Sì
(Solo se si tratta di una copia di backup) Block group dove questa copia del
90-91 No
superblock è salvata.
Flag per le caratteristiche compatibili:
0x0001 Preallocazione dei blocchi di directory per la riduzione della frammentazione.
0x0002 Presenza di inode della parte server di AFS.
92-95 0x0004 Il file system è dotato di journal (è un Ext3). No
0x0008 Gli inode hanno attributi estesi.
0x0010 Il file system può essere ridimensionato per adattarsi a partizioni più grandi.
0x0020 Le directory usano le hash table.
 Flag per le caratteristiche incompatibili:
0x0001 Compressione.
96-99 0x0002 Le entry di directory contengono il campo per la descrizione del tipo di file. Sì
0x0004 Il file system necessita un recovery.
0x0008 Il file system usa un device per il journal.
Flag per le caratteristiche di compatibilità per sola lettura:
0x0001 Utilizzo di superblock sparse.
100-103 No
0x0002 Il file system contiene un file di grandi dimensioni.
0x0004 Le directory utilizzano i B-Tree (sperimentale).

104-119 ID del file system. No

120-135 Nome del volume. No
13-199 Percorso di ultimo montaggio. No
200-203 Algoritmo di utilizzo delle bitmap. No
204-204 Numero di blocchi da preallocare per i file. No
205-205 Numero di blocchi da preallocare per le directory. No
206-207 Non usati. No
208-223 Journal ID. No
224-227 Inode per il journal. No
228-231 Device per il journal. No
232-235 Inizio della lista degli inode. No
236-1023 Non usati. No

Group description table

Questa struttura di soli 32 byte è posta in testa (o appena dopo la copia del superblock, se è
presente) di ogni block group. Descrive la struttura del block group e fornisce i puntatori
necessari alle strutture ivi contenute (Tabella 7.28).
Tabella 7.28
Byte occupati Descrizione Obbligatorio
0-3 Blocco di partenza della block bitmap. Sì
4-7 Blocco di partenza della inode bitmap. Sì
8-11 Blocco di partenza della inode table. Sì
12-13 Numero di blocchi non allocati nel block group. No
14-15 Numero di inode non allocati nel block group. No
16-17 Numero di directory nel block group. No
18-31 Non usati. No

Block bitmap e inode bitmap

Queste due strutture contengono una mappa di bit relativa ai blocchi utilizzati nel block group
(block bitmap) e al numero di inode utilizzati e liberi (inode bitmap). La grandezza di una block
bitmap è sempre pari a un blocco. Questo implica che il numero di blocchi all’interno di un
block group è sempre pari al numero di bit contenuti un singolo blocco (quindi 8192 con blocchi
da 1 KB, 16.384 con blocchi da 2 KB, 32.768 con blocchi da 4 KB).

Inode
Gli inode sono strutture utilizzate per salvare tutti i metadati per un file o una directory. La
grandezza di un inode è di 128 byte; è locato nella inode table la cui posizione è indicata nella
group description table (Tabella 7.29).
Vanno fatte alcune considerazioni. Un inode può puntare direttamente a un gruppo di
dimensioni fino a 12 blocchi. Questo significa che se il file ha una grandezza massima di 12
228/24 576/49 152 byte (rispettivamente per block size di 1024/20 248/4096) l’inode può
provvedere direttamente al puntamento dei blocchi necessari per alloggiarlo.
Tabella 7.29
Byte occupati Descrizione Obbligatorio
File Mode (tipo e permessi):
Permessi:
0x001 Other – execution.
0x002 Other – write.
0x004 Other – read.
0x008 Group – execute.
0x010 Group – write.
0x020 Group – read.
0x040 User – execute.
0x080 User – write.
0x100 User – read.

0-1 File Mode: Sì

0x200 Sticky bit.
0x400 Set Group ID.
0x800 Set User ID.

File Type:
0x1000 FIFO.
0x2000 Character device.
0x4000 Directory.
0x6000 Block device.
0x8000 Regular file.
0xA000 Link simbolico.
0xC000 Socket Unix.

2-3 16 bit inferiori dello UID. No

4-7 32 bit inferiori della grandezza in byte. Sì
8-11 Data/ora di ultimo accesso. No
12-15 Data/ora di ultima modifica del file. No
16-19 Data/ora di ultima modifica dei metadati. No
20-23 Data/ora di cancellazione. No
24-25 16 bit inferiori del GID. No
26-27 Conteggio dei link. No
28-31 Conteggio dei settori. No
 Flag:
0x00000001 Cancellazione sicura.
0x00000002 Tieni una copia dei dati dopo la cancellazione.
0x00000004 Compressione.
0x00000008 Aggiornamenti sincroni.
32-35 0x00000010 File non modificabile. No
0x00000020 Solo aggiunte.
0x00000040 File non incluso nel comando dump.
0x00000080 Ora di accesso non aggiornata.
0x00001000 Directory indicizzata tramite hash.
0x00002000 I dati dei file sono gestiti tramite il journal di Ext3.

36-39 Non usati. No

40-87 Puntatore diretto a un insieme di 12 blocchi. Sì
88-91 Puntatore a un blocco di puntatori a 1 livello. Sì
92-95 Puntatore a un blocco di puntatori a 2 livelli. Sì
96-99 Puntatore a un blocco di puntatori a 3 livelli. Sì
100-103 Generation number (usato da NFS). No
104-107 Blocco per gli attributi estesi (ACL per i file). No
108-101 32 bit superiori per la grandezza del file/ACL per le directory. Sì/No
112-115 Indirizzo di blocco di un frammento. No
116-116 Indice del frammento nel blocco. No
117-117 Dimensione del frammento. No
118-119 Non usato. No
120-121 16 bit superiori dello User ID. No
122-123 16 bit superiori del Group ID. No
124-127 Non usati. No

Nel caso la grandezza fosse maggiore, l’inode userà i byte 88-91 per puntare a un blocco che
sarà usato per indirizzare i blocchi necessari al file per allocare lo spazio dopo i primi 12
(puntamento indiretto). All’interno del blocco vi saranno delle strutture dati di 4 byte che
puntano ai blocchi che effettivamente contengono i dati. Il numero di strutture contenute dipende
ovviamente dalla grandezza del blocco (128 per un blocco da 1024 byte, 256 per uno da 2048 e
512 per uno da 4096).
Nel caso anche questo sistema non si rivelasse sufficiente, sarà possibile usare un sistema a 2
livelli. Il puntatore dell’inode punterà al primo blocco, che conterrà una serie di liste ad altri
blocchi che contengono puntatori ai blocchi che contengono i dati.
Se neanche questo sistema bastasse, si potrà usare un sistema a tre livelli, dove l’inode punta
a un primo blocco di puntatori, che puntano a un secondo livello di blocchi, che puntano a un
terzo livello di blocchi, che puntano infine ai blocchi dati. Dato che la progressione è
geometrica, non è difficile capire che con questo metodo è possibile indirizzare file di notevoli
dimensioni.
I byte dal 108 al 111 possono contenere due dati in alternativa. Per i sistemi con indirizzamento
di file system a 64 bit conterranno i 32 bit superiori rappresentanti la grandezza del file. Nei
sistemi con valori a 32 bit, conterranno le ACL per le directory. Per distinguere quale dei due
valori vi è contenuto, un’apposita caratteristica di compatibilità sarà impostata nel superblock.

Attributi estesi
Se un file o una directory fanno uso degli attributi estesi (come le POSIX), l’inode di quel file
punterà a un blocco che conterrà tali attributi. Gli attributi estesi sono una serie di ACL che
permettono un settaggio dei diritti utente in maniera più completa rispetto alle solite tre triple di
attributi tipiche del mondo Unix (rwxrwxrwx). Nel mondo Linux tutti i file system evoluti
supportano tali attributi estesi di default anche se, normalmente, non sono utilizzati, se non per
alcuni grossi server dipartimentali.
Come sono organizzati gli attributi estesi all’interno del blocco? All’inizio del blocco vi è un
header che permette al sistema di riconoscere che, all’interno di questo, sono contenuti degli
attributi estesi e non i dati di un file. L’header è seguito da una serie di etichette che
rappresentano i nomi degli attributi che sono settati all’interno del blocco. I valori di tali
attributi partono dal fondo del blocco (potrebbero non essere nello stesso ordine in cui sono
dichiarate nella label) e risalgono verso l’inizio del blocco. Il blocco viene quindi riempito dal
basso e dall’alto fino ad arrivare al centro dello stesso.
L’header contiene le informazioni riportate nella Tabella 7.30.
Tabella 7.30
Byte
Descrizione Obbligatorio
occupati
0-3 Signature (valore fisso 0xEA020000). No
Numero di file che usano gli attributi qui dichiarati. (Feature non ancora supportata,
4-7 No
Linux utilizza un blocco di attributi estesi per ogni file.)
8-11 Numero di blocchi usati. Sì
12-15 Hash. No
16-31 Riservati. No

A seguito dell’header si trovano le strutture di descrizione degli attributi estesi (Tabella

7.31).
Tabella 7.31
Byte occupati Descrizione Obbligatorio
0-0 Lunghezza del nome. Sì
Tipo di attributo:
0x1 Attributo a User Space.
0x2 POSIX ACL.
0x3 POSIX ACL Default (vale solo per le directory).
1-1 No
0x4 Attributo a Trusted space.
0x5 Lustre (non usato da Linux ma solo dal clustered
file system Lustre).
0x6 Attributo a Security Space.
2-3 Offset al valore. Sì
4-7 Locazione del blocco dove si trova il valore. Sì
8-11 Grandezza del valore. Sì
12-15 Hash del valore. No
16+ Nome del valore in ASCII. Sì

I valori corrispondenti ai tipi 0x1, 0x4 e 0x6 sono semplicemente la valorizzazione degli
attributi dichiarati nella struttura dati sopra. Nel caso in cui gli attributi facciano parte di un
ACL POSIX (tipi 0x2 o 0x3), la valorizzazione degli stessi non sarà un singolo valore ma una
struttura dati anch’essa, che parte con un header ed è seguita da una lista di entry.
L’header è semplicissimo (si ricordi che si trova nella parte del valore, quindi in fondo al
blocco). Si veda la Tabella 7.32.
Tabella 7.32
Byte occupati Descrizione Obbligatorio
0-3 Versione. Sì

Di seguito vi sono le strutture dati per le entry delle ACL POSIX (Tabella 7.33).
Tabella 7.33
Byte occupati Descrizione Obbligatorio
Tag:
0x01 Utente, come specificato nell’inode di riferimento.
0x04 Gruppo, come specificato nell’inode di riferimento.
0-1 0x20 Altri, tutti gli altri utenti. Sì
0x10 Maschera di permessi effettiva.
0x02 Utente, come specificato negli attributi estesi.
0x08 Gruppo, come specificato negli attributi estesi.

Permessi:
0x01 Esecuzione.
2-3 Sì
0x02 Scrittura.
0x04 Lettura.

4-7 UID/GID (vale solo per i tipi 0x02 e 0x08). Sì

Directory entry
Finora si è parlato di superblock, di blocchi dati e di inode che contengono i metadati. Non si
è ancora accennato a come viene gestita la parte relativa ai nomi file e alla struttura delle
directory. Questi dati sono contenuti nelle directory entry, che si trovano nei blocchi allocati
per le directory stesse.
Esistono due tipi di strutture per la gestione dei nomi file. La vecchia struttura (che non è più
la scelta normale per i nuovi sistemi) ha il layout indicato nella Tabella 7.34.
Tabella 7.34
Byte occupati Descrizione Obbligatorio
0-3 Identificatore dell’inode. Sì
4-5 Lunghezza di questa entry. Sì
6-7 Lunghezza del nome. Sì
8+ Nome in ASCII. Sì

Come si vede, il meccanismo è semplice. Ogni directory entry contiene il nome del file o
della directory e punta direttamente all’inode di riferimento, che a sua volta contiene i metadati
e i puntatori ai blocchi dati.
I nuovi kernel usano una struttura più efficiente per le directory entry. Un apposito campo del
superblock setta una “incompatible feature” per determinare se il file system usa la nuova
struttura dati (Tabella 7.35).
Tabella 7.35
Byte occupati Descrizione Obbligatorio
0-3 Identificatore dell’inode. Sì
4-5 Lunghezza di questa entry. Sì
6-6 Lunghezza del nome. Sì
Tipo di file:
0x0 Sconosciuto.
0x1 File.
0x2 Directory.
7-7 0x3 Character device.
0x4 Block device.
0x5 FIFO.
0x6 Socket Unix.
0x17 Link simbolico.

8+ Nome in ASCII. Sì

Link simbolici
I link simbolici sono file di tipo speciale che puntano a un altro file o directory. Non hanno
bisogno di una struttura apposita. Essi sono contenuti all’interno di un normale inode, nella parte
relativa ai puntatori dei blocchi. Se il path del target è inferiore ai 60 caratteri sarà salvato nella
parte relativa all’allocazione diretta dei 12 blocchi, altrimenti si userà un blocco esterno puntato
da un’allocazione indiretta a un livello.

Journal
In Ext3/4 viene utilizzato un journal per salvare i metadati così che il sistema possa essere
ripristinato a maggiore velocità nel momento in cui dovesse verificarsi un crash.
Il journal di un file system Ext3/4 è composto da quttro distinte strutture.
La prima è quella che descrive il superblock del journal. Esso può essere v.1 o v.2; entrambi
hanno la prima parte in comune, il v.2 ha più campi in coda.
La prima parte della struttura (11 byte) non solo è in comune tra i due superblock ma è anche
utilizzata dalle strutture di descrizione dei blocchi di commit e di revoke (Tabella 7.36).
Tabella 7.36
Byte occupati Descrizione Obbligatorio
0-3 Signature (valore fisso 0xC03B3998). Sì
Tipo di blocco:
0x1 Blocco di descrizione.
0x2 Blocco di commit.
4-7 Sì
0x3 Superblock v.1.
0x4 Superblock v.2.
0x5 Blocco di revoke.

8-11 Numero di sequenza. Sì

I superblock v.1 e v.2 hanno in comune i campi indicati nella Tabella 7.37.
Tabella 7.37
Byte occupati Descrizione Obbligatorio
12-15 Grandezza del blocco del journal. Sì
16-19 Numero di blocchi allocati per il journal. Sì
20-23 Blocco di partenza del journal. Sì
24-27 Numero di sequenza della prima transazione. Sì
28-31 Blocco del journal ove risiede la prima transazione. Sì
32-35 Codice di errore. No

Il solo journal v.2 aggiunge i campi indicati nella Tabella 7.38.

Tabella 7.38
Byte occupati Descrizione Obbligatorio
36-39 Caratteristiche compatibili. No
40-43 Caratteristiche incompatibili. No
44-47 Caratteristiche per la compatibilità in sola lettura. No
48-63 UUID del journal. No
64-67 Numero di file system che usano il journal. No
68-71 Punto dove si trova la copia del superblocco. No
72-75 Numero massimo di blocchi del journal per transazione. No
76-79 Numero massimo di blocchi del file system per transazione. No
80-255 Non usati. No
256-1023 ID a 16 byte dei file system che usano il journal. No

Al superblocco fanno seguito quindi i blocchi di descrizione di commit o di revoke. La prima

parte (11 byte) della loro descrizione è identica a quella dei superblock.
Il description header fa seguire i campi indicati nella Tabella 7.39.
Tabella 7.39
Byte occupati Descrizione Obbligatorio
0-3 Blocco del file system. Sì
Flag:
 0x01 Il journal è stato ignorato.
4-7
0x02 L’entry ha lo stesso UUID della precedente. Sì
0x04 Il blocco è stato cancellato da questa transazione.
0x08 Ultima entry del blocco di descrizione.
8-23 UUID (non esiste se il flag è 0x02). No

Si noti che nel giornale si trovano tanti blocchi di descrizione quanti sono i blocchi del file
system su cui si dovrà operare (pensandoci, è assolutamente logico, dato che per ogni
operazione su un blocco del file system ci deve essere una corrispondente entry nel giornale).
Il blocco di commit non ha una struttura propria come il blocco di descrizione; ha solo
l’header standard (byte 0-11) in quanto l’unica necessità che ha è quella di sapere a quale blocco
si riferisce la transazione in corso.
Il blocco di revoke ha invece una propria struttura che segue, ovviamente, lo standard header
(Tabella 7.40).
Tabella 7.40
Byte occupati Descrizione Obbligatorio
12-15 Numero di byte di dati da revocare. Sì
Lista, in indirizzi da 4 byte, degli indirizzi dei blocchi
16-SIZE Sì
da eliminare.

OCFS2
OCFS2 è uno dei clustered file system standard di Linux. Al contrario di GFS, che è
praticamente confinato nel mondo Red Hat, è diffuso in moltissime distribuzioni. Inoltre è la
base usata sia da tutte le soluzioni di clustering di Suse Linux sia dall’Oracle VM Server, la
soluzione di virtualizzazione basata su XEN. La sua spiegazione in questo capitolo ha quindi il
duplice scopo di mostrare come funzioni un clustered file system shared storage e di
documentarne le principali strutture dati, poiché non sarebbe strano che potesse essere oggetto
di esame da parte di un qualsiasi Digital Forensics expert.
OCFS2 è un progetto di Oracle. Il primo file system(OCFS) è stato scritto principalmente per
i cluster RAC (Real Application Clustered) e ha fatto la sua prima apparizione attorno all’anno
2000. Oracle ha poi iniziato nel 2003 lo sviluppo di un clustered file system di tipo generico
(non legato quindi ai propri prodotti). Le prime versioni sono uscite nell’agosto del 2005,
mentre nel gennaio 2006 il file system è stato incorporato ufficialmente nel kernel di Linux.
OCFS2 è a tutti gli effetti un clustered file system. Linux (e altri sistemi Unix) supportano due
tipi di clustered file system.
I primi (come Lustre, MAPR, HDFS e Ceph) sono i clustered file system di tipo parallelo. In
pratica ogni nodo del cluster dispone di un RAID di dischi locali. Le risorse di tutti i singoli
nodi sono condivise in modo da presentarle come facenti parte di un unico address space
comune a tutti i partecipanti. Tendenzialmente questo approccio è tipico di datacenter di
grandissime dimensioni (Google con il suo GoogleFS è un tipico esempio) oppure per sistemi di
cluster HPC.
OCFS2 fa parte del secondo tipo di clustered file system, ovvero quelli comunemente noti
come shared disk. Sono solitamente utilizzati per permettere a più sistemi di scrivere su uno
stesso storage in comune (per questioni di bilanciamento di carico o di high availability). Il
vantaggio di una configurazione di questo genere è quello di disporre di un medium comune che
sia notoriamente più veloce ed efficiente di quanto possa essere un network file system quale
NFS o CIFS.
Gli shared file system sono di due tipi diversi: asimmetrici e simmetrici. I primi permettono
a tutti i nodi di leggere e scrivere dal disco comune, ma solo a un nodo di aggiornare i metadati.
I secondi distribuiscono anche le scritture dei metadati tra tutti i server, utilizzando un metodo di
coordinamento tra i nodi per evitare problemi di sovrapposizione e locking (tipicamente si tratta
di una rete separata di hearthbeat sui cui gira un sistema di message queue). OCFS2 fa parte di
quest’ultima categoria.
Pur essendo, a livello di struttura, un file system di tipo tradizionale (quindi ben lontano dai
paradigmi di ZFS), utilizza un gran numero di nuove tecnologie tipiche dei file system più
avanzati.
Blocchi variabili: usati per la gestione dei metadati, hanno dimensioni da 512 byte a 4 KB.
Data cluster: usati per la gestione dei dati, hanno dimensione da 4 KB a 1 MB.
Extent: come Ext4, OCFS2 è in grado di gestire gruppi di blocchi come singole unità di
allocazione, in modo da velocizzare il trattamento di file di notevoli dimensioni.
Journaling.
Neutro a livello di architettura e endian: OCFS2 è agnostico rispetto all’architettura
hardware del processore e alla sua endian. Nodi appartenenti a diverse architetture
possono compartecipare nella gestione di un singolo file system condiviso.
Distributed Lock Manager: integrato con il file system e disponibile con praticamente
qualunque distribuzione Linux, permette una gestione efficace e distribuita delle funzioni di
locking sullo storage.
Gestione intelligente degli inode: come l’ormai defunto e compianto ReiserFS, permette a
più file di piccole dimensioni di condividere lo stesso inode in modo da utilizzare in
maniera efficiente lo spazio a disposizione.
Integrazione: a OCFS2 si accede dalle applicazioni attraverso il servizio VFS e quindi non
richiede l’utilizzo di alcuna speciale API per la sua gestione a livello applicativo.

Cluster
OCFS2 ha bisogno di un sistema di gestione dei cluster per coordinare le operazioni, come
per esempio la gestione dei nodi attivi e il fencing. Tutti i nodi devono avere la stessa
configurazione e devono conoscere tutti gli altri server che hanno accesso allo stesso storage.
Attualmente ci sono due modi per gestire un cluster OCFS2.
OCFS2 Cluster Base (O2CB). È l’implementazione a livello di kernel di gestione della
configurazione del cluster, ma fornisce solo i servizi di base necessari per avere un file
system in cluster in esecuzione. Ogni nodo scrive in un file di hearthbeat per far sapere agli
altri che il cluster è vivo. Questa modalità non ha la capacità di rimuovere nodi da un
cluster vivo e non può essere utilizzato per lock a livello di cluster POSIX.
Linux HA. Utilizza strumenti user-space, come heartbeat e pacemaker, per eseguire la
gestione del cluster. Questi pacchetti fanno parte di una suite completa di gestione per
cluster sia kernel level sia applicativi e quindi il loro scopo non è assolutamente
dipendente dalla presenza di OCFS2.
Certamente Linux HA è un progetto completo, ma se quello che è richiesto è un cluster per la
sola gestione dello storage condiviso, O2CB è permette un deploy molto più semplice e veloce.

Formato del disco

OCFS2 separa il modo in cui dati e metadati vengono memorizzati su disco. Per facilitare
l’operazione, ha due tipi di blocchi.
Metadati o semplicemente “blocchi”. La più piccola unità indirizzabile. Tali parti
contengono i metadati del file system, come gli inode, gli extent block e i descrittori di
gruppo. Le dimensioni dei blocchi vanno da 512 byte a 4 KB (incrementato in potenze di
due). Ogni blocco di metadati contiene una firma relativa al tipo di dati in esso contenuti.
Tale firma viene verificata durante le operazioni di lettura.
Data cluster (spazio di memorizzazione dei file). Hanno dimensioni che vanno da 4 KB a 1
MB (in potenze di due). Un cluster di dati più grande riduce la dimensione dei metadati del
file system, come bitmap di allocazione, rendendo le attività del file system, come
allocazione di dati o controlli del file system, più veloci. D’altra parte, un cluster di
dimensioni elevate aumenta la frammentazione interna. Viene da sé che cluster di piccole
dimensioni sono più utili in situazioni dove vi siano un gran numero di file mentre cluster
di grandi dimensioni sono l’ideale in caso di file come tablespace di database oppure file
video.
Inode. Un inode occupa un intero blocco. Dato che OCFS utilizza per ogni singolo file,
come minimo, un blocco per l’inode, uno o più extent block per i puntatori, e uno o più
cluster per i dati del file vero e proprio, questo fa sì che si sprechi un notevole quantitativo
di blocchi per la gestione dei metadati di ogni file. Per ridurre al minimo questo problema,
OCFS2 compatta i file di dati, se sono di piccole dimensioni, all’interno degli inode stessi
 (esattamente come fa talvolta NTFS con i file di piccole dimensioni dentro la $MFT).
Questa caratteristica è nota come inline data.
Gli inode usano puntatori a 64 bit e quindi possono indirizzare dischi (o LUN) di grandi
dimensioni. Al contrario di quanto accade per gli inline data, in OCFS2 il layout dei dati su
disco viene gestito tramite un B-Tree che ha come radice l’inode che punta al file. L’inode punta
direttamente a una serie di extent block che possono puntare direttamente a uno o più data
cluster che contengono i dati oppure a una serie di ulteriori extent block che fungono da nodi
intermedi dell’albero. I data extent contengono l’offset relativo alla distanza dei data cluster da
essi controllati rispetto alla radice dell’albero. In questo modo è possibile indirizzare
direttamente i singoli blocchi del file senza doverlo scorrere in maniera sequenziale. Un campo
speciale chiamato l_tree_depth contiene la profondità dell’albero. Un valore pari a zero indica
che i dati si trovano direttamente nei data cluster puntati dal primo livello di block extent
dell’albero.
La parte di locking (cosa quasi ovvia per un prodotto sviluppato da una società leader nel
campo dei database) è particolarmente sofisticata. Il locking avviene a livello di inode. Se una
risorsa deve accedere a un file e ottenere un locking deve richiederlo a uno specifico daemon
che gira su ogni nodo, ovvero il DLM. Tutti i daemon DLM dei nodi partecipanti al cluster
insistono su una unica struttura dati e quindi il lock è automaticamente propagato anche agli altri
server. Il DLM offre sei modalità di lock. Di queste, attualmente OCFS2 ne utilizza tre per
differenziare le modalità di accesso a un file: exclusive, protective read e null lock. Le altre tre
modalità sono invece usate a livello di inode.
Read-write lock: è il lock usato per quei file su quali leggono e scrivono più server
contemporaneamente. Permette di creare una coda in cui sono inserite le operazioni di
scrittura provenienti dai vari nodi.
Inode lock: è utilizzato per la gestione delle operazioni di aggiornamento dei metadati.
Open lock: viene utilizzato per le operazioni di cancellazione di un file. Quando un file è
aperto, viene richiesto un open lock in modalità protective read. Se il nodo intende
eliminarlo, esso richiederà exclusive lock. Se lo ottiene significa che nessun altro nodo sta
utilizzando il file e può essere quindi eliminato senza problemi.
Le voci di directory sono memorizzate come coppie nome-inode in speciali blocchi detti
directory block. L’accesso alle voci di directory da parte del file system non è diverso rispetto
a quello di un file. Tuttavia, i directory block vengono allocati come data cluster e non come
metadata block. Poiché un data cluster è di dimensioni maggiori rispetto a un block per la
gestione della directory ne è allocata solo una minima parte. Lo spazio in eccesso all’interno del
data cluster viene utilizzato con il crescere della directory. All’esaurirsi dello spazio all’interno
del data cluster ne saranno instanziati di nuovi.
 Una nuova funzionalità introdotta nel file system è una struttura a indice (sempre basata su B-
Tree) contenente gli hash dei nomi delle directory. A ogni hash è collegato l’entry point del data
cluster relativo a quella directroy. Da quel punto in poi il suo contenuto sarà ricercato
linearmente all’interno della struttura di descrizione della directory (vedi il paragrafo
precedente).

Metadati
Una directory speciale di sistema (//) contiene tutti i file di metadati per il file system. Questa
directory non è accessibile attraverso una normale operazione di mount del file system da un
supporto regolare. Si noti che il path // è utilizzato solo dallo strumento debugfs.ocfs2. I file di
sistema sono diversi dai file normali, sia in termini di come si memorizzano le informazioni sia
relativamente al loro contenuto.
Un esempio di un file di sistema è lo slotmap, che definisce la mappatura di un nodo nel
cluster. Quando un nodo si unisce un cluster, fornisce il suo ID univoco associato al DLM. La
slotmap fornisce un numero di slot, e il nodo eredita tutti i file di sistema associati a quel
numero di slot. L’assegnazione del numero di slot non è persistente a ogni reboot, quindi un nodo
può ereditare i file di sistema utilizzati precedentemente da un altro nodo. Tutti i file di sistema
associati a un nodo sono contraddistinti dal numero di slot per differenziarli tra di loro.
NOTA
Se il concetto appare oscuro è bene ricordare che la directory // non è univoca ma comune a tutti i nodi, e quindi
contiene tutti i file di sistema di tutti i nodi.

Un file di global bitmap nella directory di sistema tiene traccia dei blocchi allocati sul
device. Ogni nodo mantiene anche un file di sistema con una local allocation table, che gestisce
i data chunk già ottenuti dalla bitmap globale. Il mantenimento di allocazioni locali permette a
ogni nodo di disporre di una serie di blocchi preallocati e di ridurre quindi le operazioni di
richiesta di nuovo spazio e che potrebbero essere oggetto di contesa tra i nodi.
Le allocation unit sono divise nel seguente modo.
inode_alloc: assegna gli inode per il nodo locale.
extent_alloc: alloca gli extent block per il nodo locale. Gli extent block sono le strutture di
metadati usati per indirizzare i data cluster collegati al B-Tree di uno specifico inode.
local_alloc: alloca i data cluster usati per scrivere il contenuto dei file.
Ogni allocatore è associato a un inode, e mantiene le allocazioni in unità conosciute come
block group I gruppi di allocazione sono preceduti da un descrittore di gruppo che contiene i
dettagli sul block group, come per esempio le unità libere, l’allocazione bitmap e così via.
L’inode allocator contiene una catena di puntatori a dei group descriptor block. Quando lo
spazio all’interno di questa catena si esaurisce vengono allocati dei nuovi group descriptor
block utilizzando la forma di linked list. Il risultato finale è una sorta di array di linked list. Il
tutto è gestito in modo da minimizare il numero di hop necessari a scorrere la catena.
Le cose si complicano quando i blocchi di dati assegnati vengono liberati perché quei blocchi
potrebbero appartenere alla allocation map di un altro nodo. Per risolvere questo problema, un
truncate log mantiene i blocchi che sono stati liberati a livello locale ma non sono stati ancora
restituiti alla global bitmap. Una volta che il nodo riesce a porre un lock sulla global bitmap,
marca i data cluster come liberi a livello globale e li elimina dal suo truncate log.
Un file non viene fisicamente eliminato fino a quando tutti i processi che vi accedono sono
chiusi. File system come Ext3/4 mantengono una orphan list, che contiene un elenco di file che
sono stati scollegati ma ancora sono in uso dal sistema. OCFS2 mantiene anche una lista per
gestire gli inode orfani. Le cose sono un po’ più complesse, tuttavia, perché un nodo deve
verificare che un file da cancellare non solo non sia utilizzato da alcuno dei propri processi ma
anche da quelli presenti sugli altri nodi del cluster. Questo controllo viene coordinato
utilizzando il DLM, che verifica che non vi siano lock a livello globale sui file da eliminare. Il
nodo che deve cancellare un file tenta di porre un lock di tipo esclusivo sul file. Se tale
operazione non riesce, il file verrà spostato nella directory riservata ai file orfani e
contrassegnato dal flag OCFS2_ORPHANED_FL. La directory riservata ai file orfani viene
successivamente sottoposta a scansione per verificare la presenza di file dispongano più di lock
esclusivi, in modo che possano essere rimossi fisicamente dal dispositivo di memorizzazione.
OCFS2 mantiene un journal per far fronte a incidenti imprevisti. Esso utilizza il servizio
Linux JBD2 per il journaling. I file di journal sono mantenuti, per nodo, per tutti gli I/O eseguiti
localmente. Se un nodo muore, è responsabilità degli altri nodi del cluster terminare le
operazioni rimaste in sospeso dal nodo deceduto in modo da mantenere un stato coerente del file
system.

Caratteristiche aggiuntive
OCFS2 ha un paio di altre caratteristiche distintive particolarmente interessanti.
Reflink è l’implementazione degli snapshot dei file utilizzando Copy-on-Write (COW).
Quindi OCFS2 non dipende dalla presenza di LVM (come altri file system Linux) per la
gestione degli snapshot.
Metaecc è un sistema CRC (CRC32) per il controllo dei metadati. Se il CRC calcolato non
è coerente con quello letto successivamente il sistema rimonta il file system in sola lettura
per evitare ulteriori problemi.

Digital Forensics
Come appare evidente, l’analisi di un clustered file system può essere un po’ complicata dato
che vi sono un notevole numero di sistemi di coordinamento, strutture dati globali e locali,
nonché svariati livelli di cache.
Al momento attuale nessun clustered file system è supportato da alcun software di Digital
Forensics, commerciale o open che sia. L’unico tool disponibile per l’esame delle strutture
interne di OCFS2 è debug.ocfs2. Si tratta di un utility a riga di comando, che dispone di una
propria shell e di un proprio set di comandi con i quali si possono leggere e decodificare le
strutture dati a basso livello del file system (questo è anche uno dei motivi per i quali sono
esposti i principi di funzionamento di OCFS2 senza entrare nel dettaglio a byte level: quanto
esposto è ciò che serve per riuscire a fare, con un minimo di pratica, un’analisi di un file system
OCFS2 con il tool di debug fornito con le utility).

HFS+
HFS+ è l’evoluzione del file system originariamente sviluppato per l’Apple Macintosh.
Rispetto al file system originale sono state introdotte notevoli migliorie, tanto che questo file
system ha retto senza alcun problema il peso degli anni. Nonostante inizialmente Apple avesse
pensato di sostituire HFS+ in Leopard con ZFS, il supporto introdotto è in sola lettura. Tale
supporto è tuttavia stato eliminato con Snow Leopard.
HFS e HFS+ sono due file system alquanto particolari, sviluppati per superare i limiti
dell’epoca. HFS fu introdotto per sopperire agli svantaggi del DOS e del primo file system dei
sistemi Macintosh, MFS, che permetteva solo di gestire una struttura di memorizzazione flat.
HFS fu sviluppato tenendo conto del fatto che i sistemi Macintosh necessitavano di gestire una
quantità notevole di metadati, non affrontabile con alcun sistema disponibile a metà degli anni
Ottanta.
Per la prima volta fu introdotto il concetto di fork. Ogni file presentava due distinti fork: un
data fork contenente i dati del file e un resource fork contenente invece i metadati e le
informazioni supplementari su di esso.
Nel 1998 fu introdotto HFS+ e, successivamente, le sue varianti (HFS+ journaled, detto anche
HFSX, e HFS+ Journaled Case Sensitive). HFS+ presenta una serie notevole di vantaggi
rispetto al vecchio HFS.
Migliore gestione dello spazio su disco: la quantità di spazio indirizzabile è di 16 TB.
Supporto a file di grandi dimensioni: la grandezza massima di un file è passata dai 2 GB
della prima versione ai 16 TB della versione corrente.
Numero di file per cartella: attualmente è possibile memorizzare fino a 2.147.483.648 file
per cartella.
Gestione nomi di file lunghi fino a 255 caratteri e con supporto Unicode.
 Struttura di HFS+
La prima cosa da precisare in relazione a HFS e a tutte le sue successive evoluzioni è che
funziona con un meccanismo di alberi binari. La ragione è molto semplice, ovvero quella di
migliorare drasticamente le performance di ricerca dei file su disco. Molte delle caratteristiche
che hanno fatto la fortuna del Mac derivano proprio dal fatto che il sistema è rapidissimo nella
ricerca dei file.
Purtroppo la gestione di un albero binario non è semplice. L’albero deve essere sempre
perfettamente ordinato se non si vuole perdere immediatamente di efficienza. Anche la variante
creata da Apple (B*-Tree) non è esente da questo problema, e la macchina spesso e volentieri
passa il suo tempo a riorganizzare l’albero, specie se vi sono state massicce modifiche nel
layout del disco.
In HFS+ sono stati quindi introdotti i file di catalogo. La loro posizione è fissa e si possono
trovare consultando il blocco 2 (Volume Header) del file system. I file di catalogo contengono
l’elenco completo di tutti gli oggetti presenti in ogni directory. Si noti che i file di catalogo sono
anch’essi gestiti come degli alberi binari (B*-Tree).
A livello di layout su disco, HFS+ lavora con i cosiddetti allocation block. Questi ultimi, da
specifica, dovrebbero avere come dimensione una potenza di 2. In realtà Apple stessa consiglia
che gli allocation block siano dei multipli di 512, ovvero il settore dell’hard disk; la grandezza
usata di default è di 4096 byte. HFS+ usa puntatori a 32 bit, quindi al massimo si possono
allocare 4.294.967.296 allocation block.
Tutte le strutture proprie del file system sono contenute all’interno degli allocation block. Per
evitare la frammentazione, più allocation block sono collegati in un clump. La grandezza del
clump è specificata nel Volume Header.

Volume Header
Il Volume Header è sempre posto, come spiegato prima, nel blocco 2, ovvero 1024 byte dopo
l’inizio del disco. I primi due settori (0 e 1) sono infatti riservati per contenere il codice di
boot. Per ragioni di sicurezza, un Alternate Volume Header è posto a 1024 byte prima della fine
del volume.
Nel Volume Header sono contenute una serie di informazioni vitali, elencate di seguito.
Signature (valore fisso a 0x482b).
Versione.
Attributi.
Data/ora di ultimo montaggio.
Data/ora di creazione.
Data/ora di modifica.
 Data/ora dell’ultimo backup.
Data/ora dell’ultimo controllo sul file system.
Numero di file presenti.
Numero di directory usate.
Grandezza dei blocchi.
Numero totale di blocchi usati.
Numero di blocchi liberi.
Prossimo blocco libero da allocare.
Grandezza di un clump.
Grandezza massima di dati in un clump.
Prossimo CatalogID.
Encoding (bitmap).
Info per il Finder.
Info Allocazione dei file.
Info Extents dei file.
Info Catalogo dei file.
Info Attributi dei file.
Info Startup file.
La sua struttura completa, nonché le dimensioni dei campi, è ben esemplificata in questa
porzione di codice:
struct HFSPlusVolumeHeader {
UInt16 signature;
UInt16 version;
UInt32 attributes;
UInt32 lastMountedVersion;
UInt32 reserved;

UInt32 createDate;
UInt32 modifyDate;
UInt32 backupDate;
UInt32 checkedDate;

UInt32 fileCount;
UInt32 folderCount;

UInt32 blockSize;
UInt32 totalBlocks;
UInt32 freeBlocks;

UInt32 nextAllocation;
UInt32 rsrcClumpSize;
UInt32 dataClumpSize;
HFSCatalogNodeID nextCatalogID;

UInt32 writeCount;
UInt64 encodingsBitmap;

UInt8 finderInfo[32];
HFSPlusForkData allocationFile;
HFSPlusForkData extentsFile;
HFSPlusForkData catalogFile;
HFSPlusForkData attributesFile;
HFSPlusForkData startupFile;
};
typedef struct HFSPlusVolumeHeader HFSPlusVolumeHeader;

Come si vede, il Volume Header contiene una serie di campi che devono essere
continuamente aggiornati dal file system, come per esempio la data di ultima modifica e ultimo
backup, il conteggio delle cartelle e dei file presenti, lo spazio libero, il prossimo blocco da
allocare e l’ID del prossimo catalogo. Questo significa che praticamente ogni qualvolta viene
fatta una minima modifica sul file system il blocco 2 deve essere aggiornato. Questo certo non
giova ai dischi rigidi e meno che mai permetterebbe a HFS+ di essere usato con successo su un
supporto SSD con un numero di scritture per blocco limitate.

Allocation File
Tiene traccia di quali blocchi di allocazione sono liberi e quali in uso. Come in altri file
system, la struttura utilizzata è quella di una bitmap dove ogni bit è utilizzato per salvare lo stato
di un allocation block. L’Allocation File è memorizzato come un file normale e non occupa uno
spazio riservato all’inizio del volume; può cambiare di dimensione e non deve essere
memorizzato in blocchi contigui nel volume.

Extend Overflow File

È un altro B*-Tree che registra i blocchi allocati a ogni extension di un file. Ogni record nel
Catalog File è in grado di registrare fino a otto extension per file; superate le otto extension, è
possibile registrarne altre, che però finiranno nell’Extents Overflow File.
All’interno dell’Extend Overflow File sono segnati anche i bad sector. La dimensione di
default di un record di estensione è di 1 KB in Mac OS e di 4 KB in OS X.

Attribute File
Questa struttura dati è peculiare di HFS+ (ovvero non ha un corrispondente nel file system
HFS da cui deriva); è basata anch’essa su un B*-Tree. L’Attribute File può gestire tre distinti
tipi di record di 4 KB.
Inline Data Attribute: contiene attributi di piccole che possono essere memorizzati nel
record stesso.
Data Attribute: contiene riferimenti a un massimo di otto extension che possono contenere
attributi di maggiori dimensioni.
Extension Attribute: vengono usati per estendere i record Fork Data Attribute.

Startup File
È una struttura dati che permette di effettuare lo startup di un sistema operativo che non
supporta nativamente HFS+. È usato principalmente dai loader di Linux su piattaforma
PowerPC.

ZFS
Quando fu scritta la prima edizione di questo libro, l’autore era assolutamente convinto che
ZFS avrebbe in pochissimo tempo soppiantato la maggior parte dei file system presenti sul
mercato. Purtroppo, problemi di licenza (per il porting nel kernel di Linux), con Apple (che
dopo aver introdotto il supporto in Read Only con Leopard lo ha tolto nelle successive versioni)
e uno sviluppo meno rapido del previsto da parte di Sun non ne hanno facilitato né la diffusione
né tantomeno l’adozione da parte di altre realtà.
Al momento è estesamente usato nei sistemi *BSD e derivati, e in particolare nella
piattaforma FreeNAS, dove fa la parte del leone.
È un peccato, perché ben pochi progetti sono stati così rivoluzionari come lo è stato ZFS.
Nella pagina What is ZFS (http://www.opensolaris.org/os/community/zfs/whatis/) si nota una frase che
potrebbe sembrare altezzosa: “... Abbiamo gettato via vent’anni di supposizioni obsolete,
eliminato la complessità alla fonte e creato un sistema di archiviazione che è un piacere da
usare...”. In realtà ogni singola parola è vera. E per questo un plauso va a chi ha saputo
“reinventare la ruota” da zero con nuove basi e nuovi principi.
Da qualche tempo pare che le trattative tra Oracle e Apple siano riprese e quindi c’è una
tenue speranza che ZFS approdi sulla piattaforma Mac (e sarebbe un toccasana dopo anni di
evoluzioni del vetusto HFS). Ad ogni modo ZFS è stato ispirante. Inizialmente sotto Linux è
partito il progetto Tux3, che però procede a passi lentissimi. Poi è arrivato BtrFS (trattato alla
fine del capitolo), che ha ripreso molti dei concetti di ZFS. Ora BtrFS è un file system stabile e
OpenSuSE lo può utilizzare come file system di default.
NOTA
Nonostante l’entusiasmo di chi scrive, al momento attuale nessun software di analisi forense, commerciale od
open source, supporta ZFS. Il tempo dirà chi ha visto più lontano. Quindi, ora come ora, se vi dovesse mai
capitare una macchina Solaris/OpenSolaris/BSD/FreeNAS con dischi ZFS sappiate che dovrete fare tutto a
mano.

Concetti chiave
Innanzitutto ZFS getta al vento tutto quello che siamo abituati a pensare in relazione ai dischi.
Si dimentichino RAID, mirror, stripe, partizioni, volumi, slice, MBR, GPT, LDM, LVM. Tutto è
semplicemente obsoleto.
ZFS nasce con l’idea di pool di storage. Un pool di storage può essere formato da dischi con
tecnologie completamente differenti: RAID, SAN o qualunque cosa possa fornire uno spazio ove
salvare dati. La parte divertente è che il miglior storage possibile con ZFS è quello che viene
comunemente definito JBOD (Just a Bunch Of Disks). La parte di ridondanza, qualunque sia il
livello che si vuole implementare, è meglio lasciarla fare a ZFS in fase di definizione di uno
zpool. Per esempio, il comando
zpool create mypool mirror c0d0 c1d1

crea uno zpool che è un mirror di due dischi fisici presenti sul sistema. Nel caso si volessero
aggiungere altri due dischi in mirror allo stesso pool sarebbe sufficiente digitare
zpool add mypool mirror c0d1 c1d0

per trovare immediatamente il nuovo spazio disponibile a tutti i file system creati all’interno
dello zpool, il tutto mentre i file system sono montati e gli utenti lavorano.
Se è parso semplice gestire un sistema Linux con LVM, ZFS dovrebbe apparire banale.
Inoltre il sistema è in grado di bilanciare automaticamente il carico tra i dischi, quindi,
lavorando su un numero di dischi fisici maggiore, è probabile che aumenti la banda passante,
che sarà la sommatoria di quella dei singoli canali.
Ma questa non è l’unica caratteristica rivoluzionaria. Uno dei problemi principali di ogni file
system usato al momento è quello di capire se i dati sono affidabili. Certo, se si tratta di un
errore dovuto a un bad block, la logica sottostante è in grado di dialogare con il file system
mostrandogli che il blocco fisico non è affidabile. Ma che dire se si tratta di un problema
dovuto a un’alterazione dei dati causata da un’interruzione, uno sbalzo di corrente o un
intervento non previsto? Al momento attuale nessun sistema di correzione, hardware o software
che sia, è in grado di risolvere questa situazione.
ZFS agisce in due modi. In prima istanza tutte le operazioni di copia sono transazionali e con
un metodo di Copy-on-Write, e questo aiuta a mantenere coerente lo stato del file system. Oltre a
ciò, ogni singolo blocco ha un proprio checksum, che deve essere corretto. In caso contrario il
sistema agirà per risolvere il problema, per esempio ricostruendo i dati dalla parità di un
RAIDZ o leggendo il blocco dall’altro disco del mirror.
RAIDZ è un’altra delle feature di ZFS, ovvero un RAID 5 con prestazioni migliori e una
gestione della parità che elimina l’unico problema che affligge il RAID 5: una perdita di
tensione tra l’aggiornamento dei dati e la loro parità.
Se questo non bastasse, ZFS usa una pipeline per le operazioni di I/O e tutte le ottimizzazioni
che solitamente si trovano negli stadi di pipeline delle CPU, ovvero gestione delle priorità,
ottimizzazione del flusso delle operazioni in base al loro peso, esecuzione fuori ordine e
aggregazione dell’I/O. Il risultato è che le operazioni su ZFS sono solitamente di qualche ordine
di grandezza più rapide e consentono di gestire carichi che potrebbero mettere in crisi altri file
system.
ZFS gestisce a livello nativo snapshot sia in sola lettura sia in lettura e scrittura. Gli snapshot
sono usati anche per la gestione dei backup, che quindi diventa più rapida e non necessita di
programmi di terze parti.
La compressione nativa (2-3x di media) non permette solo di aumentare lo spazio a
disposizione, ma anche di ridurre la banda necessaria, migliorando così le performance
generali.
All’interno di uno zpool si possono creare al massimo 264 file system diversi che
condividono lo stesso spazio e che dispongono di caratteristiche proprie come il livello di
ridondanza o la gestione delle quote. Creare un file system è banale e veloce come lo è creare
una directory in un altro sistema. I file system possono essere nidificati creandone uno dentro
l’altro.
Infine, tutto il file system utilizza puntatori a 128 bit che non solo permettono di superare i
vincoli dell’attuale tecnologia ma che lo pongono come il file system definitivo, dato che i suoi
limiti non sembrano, al momento, nemmeno teoricamente avvicinabili.
Tutto questo fa senz’altro di ZFS un file system di prim’ordine, ma è indubbio che la
ricostruzione delle informazioni di uno ZFS sia un’operazione tutt’altro che banale. Anzitutto
perché come si è già avuto modo di sottolineare non vi è nulla che possa aiutare l’investigatore
nel suo lavoro: niente Encase, FTK, X-Ways, Sleuth kit o altro. In secondo luogo perché il file
system è complesso e anche un lavoro manuale non si preannuncia per nulla semplice.

zpool e device
Uno zpool (l’unità base entro alla quale sono creati i file system) è un insieme di virtual
device dove lo zpool stesso coincide con la radice o root vdev. Tali virtual device possono
essere di due tipi differenti.
Device fisici: sono tutti i dischi (o media scrivibili) disponibili al sistema operativo,
ovvero riconosciuti da un driver o da un modulo. I device fisici sono anche chiamati, e non
a caso, leaf device.
Device logici: sono dei raggruppamenti di leaf device organizzati dalle routine di gestione
di ZFS. Possono essere, per esempio, mirror oppure RAIDZ.
Per comprendere ciò si immagini lo zpool (root vdev) come la radice dell’albero. Se nello
zpool vi sono solo device fisici vi saranno una serie di foglie (leaf) collegate alla radice. Per
esempio, lo zpool test potrebbe essere connesso alle foglie /dev/c0d0 e /dev/c0d1, ovvero due
dischi fisici.
Nel caso indicato nei comandi riportati nel paragrafo “Concetti chiave”, dove i due device
fisici sono collegati come mirror a uno zpool, potremmo immaginare una struttura a tre livelli,
dove la root è lo zpool test, il primo nodo è il mirror e infine le foglie /dev/c0d0 e /dev/c1d1
sono foglie del nodo rappresentante il mirror.
Il mirror sarà quindi il device logico connesso allo zpool. Questa rappresentazione è
meramente architetturale: significa che il sistema operativo non vedrà un device (ovvero un file
nella directory /dev/) corrispondente al device logico del mirror connesso allo zpool.
Affinché un disco fisico venga riconosciuto come facente parte (direttamente o attraverso un
device logico) di uno zpool ZFS dovrà contenere una vdev label.
La vdev label è una struttura di 256 KB contenente tutti i campi necessari. Dato che è un
componente assolutamente chiave nella struttura del file system, se ne troveranno 4 all’interno di
ogni disco fisico al fine di evitare problemi nel caso una si corrompesse.
Le 4 vdev label si trovano, precisamente, all’inizio e alla fine del disco. Dal settore LBA 0 al
settore 511 si troverà la prima, dal settore 512 al settore 1023 la seconda. Per trovare le altre due si
dovrà contare a ritroso dall’ultimo settore del disco. A 512 settori dalla fine si troverà la quarta,
a 1024 settori dalla fine la terza.
Le vdev label sono aggiornate partendo dalle pari (L0 e L2) all’inizio dell’operazione, per poi
aggiornare le dispari (L1 e L3) a operazione conclusa
La vdev label è strutturata nel seguente modo.
I primi 8 KB sono vuoti. La scelta non è casuale: anche se non è raccomandato farlo, un
disco ZFS potrebbe essere partizionato attraverso VTOC (o BSD disk label) o GPT (EFI).
Quindi, per evitare possibili sovrascritture di queste strutture (ove presenti), i primi 8 KB
sono lasciati vuoti.
I successivi 8 KB contengono il Boot Block Header. Il supporto per il boot da ZFS è una
novità piuttosto recente e la struttura di questo blocco non è stata ancora del tutto
formalizzata. Anche Sun non l’ha ancora pubblicata ufficialmente.
I successivi 112 KB contengono delle strutture complesse, costituite da coppie nome-
valore in formato XDR nvlist (si vedano le main page di libnvpair e nvlist_free per
ulteriori ragguagli). Esse contengono sia una descrizione generale dello zpool e del file
system ZFS sia di tutto l’albero partente dal leaf device stesso per arrivare al root device
dello zpool.
NOTA
Si noti l’approccio. Si immagini uno zpool con due dischi in mirror. Le nvlist delle vdev label di ognuno si
troveranno le descrizioni dei due device fisici (i dischi) e del device logico del mirror (3 definizioni in tutto). Nel
caso di uno zpool formato da 4 dischi (A, B, C, D, per semplificare) riuniti in due distinti mirror (M1 e M2), nelle
vdev label di A e B si troveranno le descrizioni dei device A, B e M1, mentre nelle vdev label di C e D si
troveranno quelle di C, D e M2. Questo perché ogni mirror è un’entità logica separata e i suoi componenti
devono conoscere la struttura di cui fanno parte ma non è necessario che conoscano quelle degli altri device
logici sottesi allo stesso zpool (root device).

I successivi 128 KB contengono la lista degli uberblock. Tali strutture, concettualmente

molto simili ai superblock dell’UFS, contengono le informazioni che permettono l’accesso
alle informazioni contenute all’interno dello zpool. Esiste un solo uberblock attivo alla
 volta. Per trovarlo occorre trovare quello con il più alto valore di transaction group e un
checksum SHA-256 valido. Per evitare problemi di disponibilità dell’uberblock in caso di
malfunzionamenti l’uberblock attivo non è mai sovrascritto. Piuttosto, un altro elemento
dell’array sarà aggiornato con una versione modificata dell’uberblock; terminato
l’aggiornamento il nuovo uberblock diventerà quello attivo e sarà inibita la scrittura su di
esso, e così via, a rotazione.

Dettagli tecnici della vdev label

La struttura delle nvlist contenute nei 112 KB successivi ai primi 16 raggruppa i valori della
Tabella 7.41.
Tabella 7.41
Nome Tipo Descrizione
U int
version Versione del file system.
64
Name String Nome dello zpool di appartenenza.
U int
State Stato dello zpool; può essere 0 (attivo), 1 (esportato) o 2 (distrutto).
64
U int
Txg Identificativo del transaction group nel quale è stata scritta la nvlist.
64
U int
Pool_guid Guid dello zpool.
64
U int
Top_guid Guid del top level vdev di questo sottoalbero.
64
U int
Guid Guid di questo vdev.
64
È una struttura ricorsiva che serve per descrivere la struttura gerarchica di questo
vdev_tree Nvlist
sottoalbero.

La struttura di quest’ultima nvlist è mostrata nella Tabella 7.42.

Tabella 7.42
Nome Tipo Descrizione
Può assumere i seguenti valori:
disk identifica un disco (leaf);
le identifica un file storage (leaf);
Type String mirror descrive un mirror (logical);
raidz descrive un raidz (logical);
replacing identifica un mirror in ricostruzione dopo il fault di un disco;
root identifica il root vdev dell’albero.

U int
Index È l’indice del vdev all’interno dell’array.
64
U int
Guid Identificativo guid dell’elemento vdev.
64
Percorso usato per identificare il device dal sistema operativo, usato solo per i leaf
Path String
device.
Devid String DeviceID usato per questo vdev nell’array. Usato solo per i logical vdev.
 Identificativo di un oggetto contenente un array di identificativi di oggetti. Ogni elemento di
U int
metaslab_array questo array può essere un identificativo di un oggetto di una space map per uno
64
specifico metaslab.
U int
metaslab_shift Log in base 2 della grandezza del metaslab.
64

ashift
U int Log in base 2 della minima unità allocabile per questo top level vdev. Il valore è 10 per i
64 RAIDZ e 9 negli altri casi.
U int
asize Quantità di spazio allocabile in questo top level vdev.
64
children Nvlist Array delle nvlist rappresentanti ogni elemento figlio di questo top level vdev.

Dettagli tecnici degli uberblock

Tabella 7.43
Nome Descrizione
Magic number che identifica il file system; il suo valore è sempre 0x00bab10c (giochino di
ub_magic sostituzione, rappresenta il termine “oo-ba-block”). È scritto esattamente identico nelle macchine
big endian, e 0x0cb1ba00 nelle macchine little endian.

ub_version
Il campo identifica il formato del file system su disco. Attualmente è sempre 0x1. La versione è
identica a quella che si trova all’inizio della nvlist.

ub_txg
Tutte le attività di scrittura di ZFS sono raggruppate in transazioni. Questo dato rappresenta
l’identificativo della transazione all’interno della quale questo uberblock è stato scritto.
È la somma di tutti i vdev contenuti in questo sottoalbero. All’apertura del pool il sistema ricalcola
ub_guid_sum questa somma e la confronta con quella contenuta in questo campo per verificare se tutti i vdev
sono disponibili.

ub_time
Identifica il momento nel quale questo uberblock è stato scritto. Il formato è il classico Unix, ovvero il
numero di secondi trascorsi dal 1° gennaio 1970 in UTC.
ub_rootbp Contiene la locazione del MOS (Meta Object Set).

Boot block
Al termine del boot block vi è uno spazio di 3,5 MB riservato alla parte relativa al boot da
uno zpool. Il suo uso è ancora in fase di definizione e sviluppo. Quello che è importante, dal
punto di vista dell’analista forense, è che questo spazio è presente in tutti gli zpool, quindi in
quelli che non sono usati per il boot potrebbero essere memorizzate informazioni non
raggiungibili dal file system.

Puntatori ai blocchi, diretti e indiretti

ZFS usa, come molti file system di derivazione Unix, un sistema di puntamento ai blocchi che
utilizza puntatori diretti o indiretti, ovvero puntatori che puntano direttamente al dato interessato
o a blocchi di puntatori a cascata.
Dove ZFS si differenzia dagli altri file system è nella grandezza di questi puntatori: mentre la
maggior parte dei file system oggi in uso lavora con puntatori a 32 bit, ZFS utilizza puntatori a
128 bit. Lo spazio di indirizzamento è talmente vasto che un solo ZFS potrebbe contenere
agevolmente tutto il sapere attualmente presente su tutti i sistemi digitali del pianeta e avere
ancora spazio per ulteriori dati. Una cosa è certa: è sia scalabile sia pronto per affrontare le
sfide di domani.
Prima di esaminare la struttura del puntatore è bene definire alcuni concetti chiave di ZFS. Il
primo è DVA.
Il DVA (o Data Virtual Address) è una combinazione tra l’ID a 32 bit del vdev interessato e
l’offset a 63 bit che identifica il blocco da 512 byte contenuto all’interno del vdev. La
combinazione di questi due valori permette di definire un indirizzo univoco per ogni singolo
blocco contenuto nello zpool. All’interno di un singolo puntatore vi sono tre strutture che
possono contenere un indirizzo DVA. A seconda di quanti DVA sono avvalorati si parlerà di un
blocco normale, doppio (2 DVA) o triplo (3 DVA).
Si faccia attenzione al fatto che per trovare il blocco fisico puntato dalla DVA all’interno del
vdev è necessario compiere un’operazione matematica che consiste nel fare uno shift a sinistra
di 9 e aggiungere il valore costante 0x400000, pari alla grandezza delle vdev label e del boot
block.
Uno dei campi del puntatore prende il nome di GRID ed è stato pensato per gestire la struttura
degli zpool. Al momento attuale non è usato.
Un’altra particolarità di ZFS è il GANG. Il GANG è un bit associato a una DVA; indica che
l’indirizzo non punta a un dato ma a un successivo puntatore, ovvero che è stato usato un
puntamento indiretto. ZFS aggiunge ulteriori livelli ogni volta che il quantitativo di dati cresce
oltre la capacità di puntamento di quello specifico livello. Il massimo di livelli di puntamento
concatenati è 6 e permette di puntare a un oggetto di grandezza massima di 264.
Infine, una delle particolarità di ZFS è un estensivo uso dei checksum per il controllo dei dati.
Al contrario di altri file system, dove il checksum è usato solo per le strutture del file system,
ZFS effettua il checksum di tutto, compresi i dati dentro il file system.
È quindi impossibile che i dati possano rovinarsi senza che il file system si accorga della
cosa. A ogni DVA è associato un relativo checksum; questo è calcolato se quanto è puntato dalla
DVA è un leaf (quindi dati) oppure un GANG (blocco di indirizzamento indiretto).

Struttura del blocco

Il blocco è organizzato come segue. Innanzitutto vi è una struttura ripetuta tre volte (una per
ogni DVA). La sua grandezza totale è di 128 bit (Tabella 7.44).
Dopo le tre ripetizioni della struttura di cui sopra (si noti che sono sempre presenti, anche in
blocchi normali o doppi nei quali le strutture non avvalorate saranno poste a zero) vi è
un’ulteriore struttura dati da 64 bit composta nel modo indicato nella Tabella 7.45.
Tabella 7.44
Campo Grandezza (in Descrizione
bit)
vdev 32 ID del vdev interessato.
GRID 8 Riservato per usi futuri connessi alla struttura dei RAIDZ.
Grandezza totale dei dati puntati, comprese le strutture usate per il puntamento
ASIZE 24
indiretto (GANG).
GANG 1 Indica che il puntatore punta a un blocco di puntatori.
offset 63 Offset del blocco interno al vdev.

Tabella 7.45
Grandezza
Campo Descrizione
(in bit)
Endian 1 Posto a 0 se big endian, a 1 se little endian.
Level 7 Identifica il livello di indirizzamento del puntatore. Possono essere fino a 6.
Type 8 Indica il tipo di dato puntato da questo blocco.
Identifica se vi è un checksum, cosa riguarda e che tipo di algoritmo è usato per il
checksum stesso. I valori possibili sono:
1 Checksum attivo (fletcher2).
2 Off.
3 “Label” (sha-256).
Checksum 8
4 Gang Header (sha-256).
5 Zilog (fletcher2).
6 fletcher2 (fletcher2).
7 fletcher4 (fletcher4).
8 sha256 (sha256).

Indica se è usata una compressione ed eventualmente il tipo. Per ora è implementato solo
l’algoritmo lzjb ma il tipo di campo e il suo uso fanno presupporre che ulteriori algoritmi
potrebbero essere implementati in futuro:
Comp 8
1 Compressione attiva (lzjb).
2 Compressione non attiva.
3 Lzjb (lzjb).

Grandezza logica, indica la grandezza del dato puntato senza compressione e l’overhead
lsize 16
dovuto ai blocchi di indirizzamento indiretto (GANG).
psize 16 Grandezza fisica del dato dopo la compressione.

A seguire si trovano tre campi da 64 bit denominati padding. Sono inutilizzati e riservati per
usi futuri.
Infine si trovano, in sequenza, i tre checksum relativi ai tre DVA. Possono essere a zero nel
caso che i DVA non siano avvalorati o se il campo checksum è posto a 2 (off).

Gestione degli oggetti, metadati e relazioni

Quanto descritto non sembrerebbe tanto dissimile da un qualunque file system Unix quale
Ext2/3 o UFS. In realtà ZFS è un file system ad oggetti. Questo significa che ogni cosa
all’interno del file system è descritta come un oggetto.
Quindi, contrariamente a quanto si potrebbe pensare, non vi è una catena logica del tipo
uberblock → puntatore → dato, ma vi è una serie di ulteriori strutture che definiscono l’oggetto
prima che lo stesso sia puntato dai blocchi di puntatori già descritti.
Tali strutture sono poste tra l’uberblock e i blocchi di puntatori usati poi per puntare i settori
sul disco. L’insieme di queste strutture è chiamato DMU (Data Management Unit) e il suo
scopo è di organizzare dati e strutture logiche in oggetti veri e propri.
Gli oggetti gestibili da un file system ZFS sono quelli della Tabella 7.46.
Tabella 7.46
Tipo Descrizione ID
DMU_OT_NONE Oggetto non allocato. 0

DMU_OT_OBJECT_DIRECTORY Oggetto di tipo DSL ZAP. 1

DMU_OT_OBJECT ARRAY Oggetto usato per gestire array di oggetti. 2

DMU_OT_PACKED_NVLIST Oggetto contenente una struttura di nvlist. 3

DMU_OT_SPACE_MAP Oggetto che punta a una struttura di controllo dei blocchi utilizzati. 8

DMU_OT_INTENT LOG Intent log. 9

DMU_OT_DNODE Oggetto di dnode. 10

DMU_OT_OBJSET Insieme di oggetti. 11

DMU_OT_DSL_DATASET_CHILD_MAP
Oggetto DSL ZAP che punta a un figlio DSL che contiene informazioni relative 13
a directory.

DMU_OT_DSL_OBJSET_SNAP_MAP
Oggetto DSL ZAP che contiene informazioni relative a uno snapshot di un 14
dataset.

DMU_OT_DSL_PROPS
Oggetto DSL contenente informazioni relative a un oggetto DSL con 15
informazioni di directory.
Lista di puntatori relativi a informazioni di deadlist, ovvero a liste di puntatori
DMU_OT_BPLIST cancellati dall’ultimo snapshot e deferred free list utilizzate per operazioni di 16
sync.
DMU_OT_ACL Oggetto per ACL. 17

DMU_OT_PLAIN_FILE File ZPL. 18

DMU_OT_DIRECTORY_ CONTENTS Oggetto ZAP con directory ZPL. 19

DMU_OT_MASTER_NODE
DMU_OT_DELETE_QUEUE
DMU_OT_ZVOL
Oggetto ZAP con ZPL Master Node: oggetto usato per identificare la root 20
directory, cancellare code o modificare la versione del file system.
Questo oggetto contiene la lista delle cancellazioni che erano in corso al
momento in cui il file system è stato smontato oppure è mancata la corrente. 21
La lista è usata per completare l’operazione durante il prossimo mount.
Volume ZFS. 22

DMU_OT_ZVOL_PROP Proprietà relative a un volume ZFS. 23

Questi oggetti sono definiti come tali in apposite strutture da 512 byte chiamate dnode. Tali
strutture contengono informazioni relative all’oggetto e una lista (diretta o indiretta) di blocchi
del file system che faranno parte dell’oggetto stesso.
I campi che compongono la prima struttura di tipo dnode (dnode_phys_t) nei 512 byte di un
dnode sono elencati nella Tabella 7.47.
Tabella 7.47
Grandezza
Campo Descrizione
(in bit)
dn_type u int 8 Valore relativo al tipo di oggetto rappresentato.
Contiene un log in base 2 della grandezza (in byte) del blocco di indirizzamento
dn_indblkshift u int 8
indiretto all’oggetto.
dn_nlevels u int 8 Indica il numero di livelli di indirizzamento indiretto necessari per questo oggetto.
dn_nblkptr u int 8 Indica quanti blocchi di indirizzamento sono contenuti in questo dnode.
Indica il tipo di dati che sono contenuti nel bonus buffer. I possibili valori sono:

Nome
Descrizione
Valore

DMU_OT_PACKED_NVLIST_SIZE
Il bonus buffer contiene la grandezza in byte di una DMU_OT_PACKED_NVLIST.
4

DMU_OT_SPACE_MAP_HEADER
Il bonus buffer contiene l’header di una space map.
7
dn_bonustype u int 8
DMU_OT_DSL_DIR
Il bonus buffer contiene un oggetto di tipo DLS. Directory usata per definire le
relazioni tra i dataset.
12

DMU_OT_DSL_DATASET
Il bonus buffer contiene un oggetto di tipo DLS. Dataset usato per la definizione
degli snapshot.
16

DMU_OT_ZNODE
Il bonus buffer contiene dei metadati ZPL.
17

dn cheksum u int 8 Checksum.

dn_compress u int 8 Determina se la compressione è utilizzata ed eventualmente il tipo.
dn_pad[1] u int 8 Riservato.
Determina la grandezza di un block size, espressa in numero di settori fisici (disk
dn_datablkszsec u int 16
sector) da 512 byte. Può variare da 1 a 256.
Grandezza in byte del bonus buffer. Il tipo di dati contenuti è definito dal campo
dn_bonuslen u int 16
dn_bonustype.

dn_pad2[4] u in 8 Riservato.
dn_maxblkid u int 64 Contiene il blockID dell’ultimo blocco di puntamento ai dati dell’oggetto.
Somma della grandezza totale di tutti i blocchi di puntamento dell’oggetto (diretti e
dn_secphys u int 64
indiretti).
dn_pad3[4] u int 8 Riservato.
dn_blkptr variabile Array di blocchi di puntamento.
dn_bonus variabile Bonus buffer.

Molto spesso gli oggetti sono poi raggruppati in appositi object set. Un esempio di object set
potrebbe essere snapshot, clone, volume.
Per definire gli object set ZFS usa una seconda struttura, sempre facente parte della DMU,
che prende il nome di objset_phys_t.
 Tale struttura è composta da una serie di record sempre uguali, organizzata come nella
Tabella 7.48.
Tabella 7.48
Grandezza (in
Campo Descrizione
bit)
È un array di dnode_phys_t, uno per ognuno degli oggetti facenti parte dell’object
metadnode Array
set.
os_zil
header
Struttura zil_header (descritto più avanti).

Determina il tipo di object set e può assumere uno dei seguenti valori:

Nome
Descrizione
Valore

DMU_OST_NONE
Object set non inizializzato.
0

os_type u int 64 DMU_OST_META

Object set di tipo DSL.
1

DMU_OST_ZFS
Object set di tipo ZPL.
2

DMU_OSTZVOL
Object set di tipo ZVOL.
3

Gestione di snapshot e dataset

Finora si sono viste le strutture fondamentali di uno ZFS. Vi è anzitutto la vdev label, poi gli
uberblock, il boot block, il DMU per la gestione degli oggetti, che possono essere singoli
oppure raggruppati in set, e infine i blocchi che li compongono, puntati da un sistema di
puntatori diretti o indiretti.
Si noti che non si è minimamente accennato a nulla che sia una struttura di controllo del file
system, come la gestione dei file e delle directory, le ACL, la gestione degli snapshot o altro.
Ciò perché a questo punto si può iniziare un discorso analogo a quello di NTFS. Dove in NTFS
ogni cosa, comprese le strutture di controllo proprie del file system, è un file, in ZFS funziona
allo stesso modo, parlando però di oggetti e set di oggetti al posto del più limitato concetto di
file.
Esistono quindi una serie di moduli aggiuntivi che sfruttano i meccanismi di manipolazione
degli oggetti di ZFS per la gestione delle funzioni principali. Ciò significa anche che, in linea
teorica, non vi è limite al numero di funzioni integrabili a ZFS. È sufficiente dotare il file system
di un nuovo modulo scritto per quella funzione.
 Il primo dei moduli che si esamineranno prende il nome di DSL, ovvero Dataset and
Snapshot Layer. Il suo scopo principale è di gestire le relazioni presenti tra gli object set.
Gli object set per un file system ZFS possono essere fondamentalmente di quattro tipi diversi.
File system. Per gestire una serie di oggetti in maniera conforme allo standard POSIX.
NOTA
A questo punto è bene precisare che il concetto di file system così come lo si pensa tradizionalmente diventa
fuorviante. In ZFS in effetti lo troviamo con due accezioni diverse, proprio per la sua natura ad oggetti. Si può
affermare che ZFS in quanto tale non sia un file system, poiché la sua struttura interna, come si è visto sinora,
non ha alcun riferimento a file o directory. Il suo scopo è di fornire un layer per la gestione e la memorizzazione
di oggetti, strutturati in insiemi di blocchi. Il “file system” così come noi lo intendiamo è semplicemente
un’astrazione di tali oggetti fornita da un apposito object set. Proprio per questo motivo in ZFS possiamo avere
non uno ma decine o centinaia di “file system” interni a un singolo zpool. Essi sono semplicemente delle
astrazioni logiche atte a visualizzare gli oggetti come file e cartelle. In questo modo il suo approccio è
profondamente diverso a qualunque altra cosa vista finora.

Cloni. Un clone è la stessa cosa di un file system, eccettuato il fatto che non è creato da
zero ma è la copia di un file system esistente. Più in dettaglio, un clone deriva da uno
snapshot ma, al contrario di quest’ultimo è una copia in read/write. È chiaro che questa
operazione, trattandosi di oggetti, è banale e velocissima, in quanto si tratta di duplicare
solamente le DMU e i puntatori dei blocchi. Man mano che i dati del clone cambieranno
rispetto al file system originale, nuovi oggetti saranno istanziati.
Snapshot. È una copia in sola lettura di un file system. È equivalente a congelare lo stato
del file system in un dato momento del tempo. Gli snapshot sono utili specialmente per le
operazioni di backup.
Volume. È un volume logico esportato da ZFS che viene visto dal sistema operativo come
un comune block device.
Il modulo DSL è quindi fondamentale in quanto questi object set possono essere manipolati e
occorre gestire le interdipendenze che si creano.
Le operazioni che possono essere eseguite sugli object set sono le seguenti.
Creazione di uno snapshot. Come si è già accennato, lo snapshot è un’immagine dello stato
di un file system in un dato momento. Non è possibile distruggere un file system se vi sono
degli snapshot creati su di esso, ma sarà necessario eliminare prima gli snapshot.
Creazione di un clone. Il clone, o copia in scrittura di uno snapshot, dipende dallo
snapshot di creazione, che quindi non può essere cancellato senza eliminare prima lo
snapshot. Se si volesse eliminare il file system da cui snapshot e clone dipendono si
dovrebbero rimuovere, in sequenza, clone, snapshot e file system.
Figli. Questa è una caratteristica incredibile di ZFS, almeno finché non si capisce la vera
natura ad oggetti di ZFS. È possibile creare dei figli. Si immagini di creare un file system
 per le home directory degli utenti (/home). In un comune sistema Unix si creerà il file
system, si monterà su /home e si creeranno le sottodirectory necessarie. In ZFS è più
pratico creare un file system per /home e dei file system figli per ogni singolo utente. In
questo modo ogni utente disporrà di un proprio file system, con un proprio set di ACL e una
propria gestione delle quote. È chiaro che se si volesse, in questo caso, eliminare il file
system padre /home si dovrebbero eliminare tutti i file system dei singoli utenti.
Se già la situazione delle interdipendenze può apparire complessa, si pensi cosa può
accadere in produzione con file system figli con snapshot e cloni che dipendono da essi.
Il modulo DSL riveste quindi un’importanza fondamentale. La sua struttura è piuttosto
complessa ed è basata su alcuni tipi diversi di oggetti.
Alla base della struttura DSL vi è un oggetto primario di tipo DMU_OST_META. Questo oggetto
(anche chiamato MOS o Meta Object Set) è unico per ogni zpool ed è puntato direttamente
dall’uberblock della vdev label. Nel MOS vi è un singolo oggetto che prende il nome di object
directory. Ogni singolo oggetto del pool è localizzabile partendo dall’object directory.
Scendendo nello specifico, l’object directory è un oggetto di tipo ZAP (ZFS Attribute
Processor), i cui dettagli saranno discussi nell’apposito paragrafo), composto da tre soli campi
(Tabella 7.49).
Tabella 7.49
Campo Descrizione

root_dataset
È l’ID di un oggetto particolare ovvero il “root DSL Directory” che è referenziato da tutte le strutture
DSL del pool. Come dice il nome, si tratta della “root directory” della struttura DSL.

config
Rappresenta l’ID di un oggetto DMU_OT_PACKED_NVLIST che descrive la struttura dei vdev del pool; è
del tutto simile a quello presente nella vdev label.

sync_bplist
È l’ID di un oggetto di tipo DMU_OT_SYNC_BPLIST che contiene la lista dei blocchi che devono essere
cancellati durante il prossimo gruppo di transazioni.

Pertanto, per semplificare, la struttura DSL è composta da un oggetto radice, unico per lo
zpool e denominato MOS o DSL Directory. Questo sottende ad altri oggetti DSL, ovvero un DSL
Dataset (chiamato anche dataset attivo), che controlla la struttura del file system creato, e dei
DSL Dataset figli, che vengono istanziati al momento in cui sono creati snapshot del file system
(un DSL Dataset per ogni snapshot). Quindi, per distruggere un file system sarà necessario
distruggere tutti i DSL Dataset che dipendono dal principale e che descrivono snapshot e cloni. I
cloni, essendo delle copie in read/write di uno snapshot, saranno anch’essi dotati di un proprio
DSL Directory.
Si è già accennato alla possibilità di creare dei figli. Per ognuno di essi sarà un oggetto DSL
Directory figlio per ogni file system figlio. La lista di tali DSL Directory figli (uno per figlio) è
gestita da uno ZAP Object che dipende dal DSL Directory padre.
La struttura DSL sottesa al DSL Directory figlio è del tutto identica a quella del root DSL
Directory (quindi può avere un DSL Dataset con dei figli e degli ulteriori DSL Dataset figli per i
figli dei figli). La struttura di un oggetto DSL Directory (padre o figlio che sia) è mostrata nella
Tabella 7.50.
Tabella 7.50
Campo Grandezza Descrizione
dd_creation_time u int 64 Data di creazione dell’oggetto DSL.
dd_head_dataset_obj u int 64 ID del dataset attivo.
dd_parent_obj u int 64 ID del DSL Directory che sottende questo DSL Directory.
dd_clone_parent_obj u int 64 Valido solo per i cloni, contiene l’ID dello snapshot su cui il clone è basato.
ID dell’oggetto ZAP che contiene la lista nome/ID per tutti i figli di questo DSL
dd_child_dir_zapobj u int 64
Directory.
dd_used_bytes u int 64 Spazio totale (in byte) usato da questo dataset (inclusi snapshot, figli e cloni).
Spazio fisico (in byte) usato da questo dataset (inclusi snapshot, figli e cloni)
dd_compressed bytes u int 64
per le parti dove la compressione è stata abilitata.
Spazio fisico (in byte) usato da questo dataset (inclusi snapshot, figli e cloni)
dd_uncompresse_bytes u int 64
dove la compressione non è abilitata.
dd_quota u int 64 Quota (ove settata) per l’intero dataset.
Spazio riservato per essere usato dal dataset di questo oggetto DSL
dd_reserved u int 64
Directory.
ID dell’oggetto ZAP che contiene tutte le caratteristiche di tutti i dataset
dd_props_zapobject u int 64 contenuti in questo DSL Directory. La sua struttura è riportata nella Tabella
7.51.

La struttura di un oggetto ZAP è mostrata nella Tabella 7.51.

Tabella 7.51
Campo Descrizione Valore
1 non settato
2 non permessa
aclinherit Controlla l’ereditarietà tra i dataset.
3 passthrough
4 sicura
1 non settato
aclmode Maschera per i permessi e l’owner di file e directory. 2 groupmsk
3 passthrough
0 spento
atime Setta se l’atime deve essere aggiornato.
1 acceso
0 spento
checksum Dice se è usato un algoritmo di checksum utilizzato nel dataset.
1 acceso

0 spento
compressione Specifica se è attiva la compressione.
1 acceso
0 non usa device
devices Specifica se i device node sono esportati dal dataset.
1 usa device
0 no
exec Setta la possibilità di lanciare programmi all’interno del dataset.
1 sì
mountpoint Identifica il punto di montaggio del dataset all’interno del DSL Directory. Stringa
Dimensione in byte della
quota Setta la quota per la dimensione del dataset.
quota
0 lettura e scrittura
readonly Imposta la possibilità di modificare gli oggetti all’interno di un dataset.
1 sola lettura
recordsize Dimensione del blocksize degli oggetti interni al dataset. Grandezza in byte
Dimensione dello spazio riservato a questo oggetto DSL Directory e a
reservation Grandezza in byte
tutti i dataset che dipendono da esso.
0 no
setuid Determina se si può rispettare il byte setuid.
1 sì
Stringa contenente le
sharenfs Determina se il dataset può essere esportato via NFS.
opzioni nfs
0 no
snapdir Determina se la directory .zfs posta nella root è visibile.
1 sì
Potenza di 2 compresa
volblocksize Determina il blocksize del volume.
tra 512 e 128 K
volsize Grandezza del volume, valido solo per i volumi. Grandezza in byte
0 no
zoned Determina se il volume è controllato da una local zone.
1 sì

La struttura di un oggetto DSL Dataset è mostrata nella Tabella 7.52.

Tabella 7.52
Campo Grandezza Descrizione
ds_dir_obj u int 64 ID dell’oggetto DSL Directory che referenzia questo dataset.
Il campo è valido solo se il dataset rappresenta un file system, un clone o
ds_prev_snap_obj u int 64
un volume. In questo caso contiene l’ID dell’ultimo snapshot effettuato.
ds_prev_snap_txg u_int_64 ID del transaction group di quando è stato preso l’ultimo snapshot.
Il campo è valido solo per dataset che rappresentino uno snapshot.
ds_next_snapshot_obj u_int_64
Contiene l’ID dello snapshot più recente.
ID di un oggetto ZAP contenente la lista nomi/ID per ogni snapshot del
ds_snapnames_zapobj u int 64
dataset. Ogni record contiene il nome dello snapshot e il suo ID.
Vale zero se il dataset non è riferito a uno snapshot. In caso contrario
ds_nu_children u int 64
contiene il numero di referenze allo snapshot.
ds_creation_time u int 64 Data di creazione del dataset.
ds creation tgz u int 64 ID del transaction group dell’operazione di creazione del dataset.
ds_deadlist_obj u int 64 ID della deadlist.
ds_used_bytes u int 64 Numero di byte usati dall’oggetto che rappresenta questo dataset.
ds_compressed bytes u int 64 Numero di byte occupati dove è stata usata la compressione.
ds_uncompressed_bytes u int 64 Numero di byte occupati dove non è stata usata la compressione.
Quando viene eseguito uno snapshot esso è una lista di puntatori agli
oggetti facenti parte del file system originale. Nel corso del tempo però molti
ds_unique_bytes u int 64
oggetti diventeranno unici dello snapshot. Questo dato rappresenta lo
spazio occupato da questi oggetti.
ID che rappresenta univocamente questo dataset tra tutti i dataset aperti al
ds_fsid_guid u int 64
momento. Potrebbe variare nel corso del tempo.
ds_guid u int 64 ID univoco del dataset.
ds_restoring u int 64 È posto a 1 durante un restore.

ds_bp
Puntatore Puntatore al blocco che contiene la locazione dell’object set che
di blocco rappresenta questo dataset.
 Oggetti ZAP
Come si è già avuto modo di accennare, esistono degli oggetti che contengono degli oggetti
che contengono a loro volta delle liste di nomi/valori. Questi oggetti sono controllati da un
modulo apposito che prende il nome di ZAP (ZFS Attribute Processor) che sta sopra al DMU.
Gli oggetti ZAP sono usati estesamente per scopi come salvare le proprietà di un dataset,
navigare in un file system e in generale salvare le proprietà dei singoli oggetti.
I tipi di oggetti ZAP utilizzabili da un file system ZFS sono i seguenti:
DMU_OT_OBJECT_DIRECTORY

DMU_OT_DSL_CHILD_OBJECT

DMU_OT DSL_DS_SNAP_MAP

DMU_OT_DSL_PROPS

DMU_OT_DIRECORY_CONTENTS

DMU_OT_MASTER_NODE

DMU_OT_DELETE_QUEUE

DMU_OT_ZFS_PROP

Inoltre gli oggetti ZAP, per una questione di efficienza, possono essere di due tipi diversi, a
seconda del numero di informazioni che possono contenere al loro interno: microzap e fatzap.
Il tipo non è fisso: un oggetto ZAP può contenere sia entry di tipo micro sia entry di tipo fat.
L’unico limite è che non ci possono essere entry di tipo diverso all’interno di un unico blocco.
Per poter operare una distinzione la prima word a 64 determina se lo zap è di tipo micro o fat.
Nel caso di un microzap:
Campo Descrizione Valore
ZBT_MICRO Quello che segue sono entry microzap. (NULL << 63) + 3

Nel caso di un fatzap il primo blocco avrà un header di questo tipo:

Campo Descrizione Valore
ZBT_HEADER Questo è un blocco di tipo fat. (NULL << 63) + 1

Tutti i blocchi fat successivi al primo avranno un identificativo di questo tipo:

Campo Descrizione Valore
ZBT_LEAF Identificativo di un blocco fat che segue un header. (NULL << 63) + 0

Micro
Un blocco microzap è semplice. I primi 128 byte rappresentano l’header del blocco che
contengono, oltre all’entry del blocco appena descritta, un salt di 64 bit che è utilizzato dalle
funzioni di hash e un pad successivo di 42 byte. I restanti 64 byte contengono la prima delle
entry microzap. Nella tabella seguente è mostrata una struttura ricorrente con i seguenti campi.
Campo Grandezza Descrizione
mze_value u int 64 Valore dell’entry.
mze_cd u int 32 È usato per poter distinguere due entry nel caso abbiano lo stesso valore.
mze_pad Variabile Riservato.
mze_name Stringa Nome dell’entry terminato da NULL.

Fat
Un blocco ZAP ha una struttura molto più complessa e articolata. Il motivo è che è pensato
per contenere dati che siano diversi dal classico u int 64 contenuto nelle entry microzap.
Ogni blocco fatzap consiste in una struttura zap_phys_t seguita da strutture di tipo zap_leaf_phys_t.
Il numero di strutture che seguono la zap_phys_t dipende dalla quantità di dati e di singole entry
presenti in ogni singola leaf. Tutte le strutture sono poi indicizzate usando una tabella di
puntatori che usano come indice il valore hash del nome delle singole leaf.
Il layout della struttura zap_phys_t è mostrato nella Tabella 7.53.
Tabella 7.53
Campo Grandezza Descrizione
zap_block_type u int 64 Identifica il tipo di blocco. È sempre posto a ZBT_HEADER.
zap magic u int 64 Sempre a 0x2F52AB2AB.
Struttura che descrive come è composta la tabella dei puntatori (struttura riportata
zap_table_phys tabella
nella Tabella 7.54).
zap_free_blk u int 64 Contiene l’ID del prossimo blocco libero che sarà usato per la prossima foglia.
zap_num_leaf u int 64 Numero di foglie contenute in questo oggetto.
zap_salt u int 64 Usato dalle funzioni di hash.
zap_num_entries u int 64 Numero di attributi salvati in questo oggetto.
Lo zap leaf array che segue questo blocco può contenere 8192 slot. Se il numero
zap leaf[8192] di attributi è inferiore saranno salvati in questo blocco e saranno salvati qui; in
caso contrario questo campo non sarà avvalorato.

La struttura della tabella dei puntatori è invece quella della Tabella 7.54.
Tabella 7.54
Campo Grandezza Descrizione
zt_blk u int 64 ID del primo blocco della tabella dei puntatori.
zt_numblock u int 64 Numero di blocchi usati in totale per la tabella dei puntatori.
zt_shift u int 64 Numero di bit usati dal valore di hash come indice della tabella.
zt_nextblk u int 64 Usato quando la tabella cambia di dimensioni.
zt_blks_copied u int 64 Usato quando la tabella cambia di dimensioni.

La struttura usata per le foglie si compone invece di vari blocchi. Il primo è l’header che ha
la struttura della Tabella 7.55.
Tabella 7.55
 Campo Grandezza Descrizione
lhr_block-type u int 64 Identificativo del blocco di tipo zap leaf. Il valore è sempre ZBT_LEAF.
lhr_next u int 64 Identificativo del prossimo blocco usato per contenere i leaf chunk.
lhr_prefix U int 64 Usato per trovare l’entry all’interno del singolo blocco.
lhr_prefix_len U int 64 Usato per trovare l’entry all’interno del singolo blocco.
lhr_magic U int 64 Sempre 0x2AB1EAF.
lhr_nfree U int 64 Numero di chunk liberi per questa leaf.
lhr_nentries U int 64 Numero di entry in questa leaf.
lhr_free_list U int 64 Lista di chunk liberi.
Leaf Hash Lista di 8 KB In questa lista sono conservati gli hash dei chunk che compongono questa leaf.

Dato che non si può sapere a priori che tipo di valori saranno inseriti in ogni singola entry di
ogni leaf, è necessario usare una struttura che sia duttile a sufficienza per accogliere quanto si
vorrà inserire. Negli oggetti di tipo fatzap, quindi, ogni foglia è rappresentata da una serie di
chunk (di tre tipi diversi) dentro ai quali saranno salvati i valori delle singole entry. In
particolare, ogni entry sarà rappresentata da un array di tipo zap_leaf_entry, che ne descriverà il
contenuto, e da uno o più chunk di tipo zap_leaf_array dove saranno conservati i valori. La
struttura dei primi è mostrata nella Tabella 7.56, quella dei secondi (usati effettivamente per
contenere nomi e dati) nella Tabella 7.57.
Tabella 7.56
Campo Grandezza Descrizione
le type u int 64 Sempre ZAP_LEAF_ENTRY.
le_int_size u int 64 Grandezza in byte di questa entry.
le_next u int 64 Prossima entry.
le_name_chunk u int 16 Contiene l’ID del chunk che preserva i primi 21 caratteri del nome dell’entry.
le_name_lenght u int 16 Grandezza totale del nome dell’entry.
le value chunk u int 16 ID del chunk che contiene il valore dell’entry.
le_value_lenght u int 16 Grandezza del valore dell’entry.
le_cd u int 64 Usato nel caso che più entry nella stessa leaf abbiano lo stesso hash.
le_hash u int 64 Hash del nome del valore dell’entry.

Tabella 7.57
Campo Grandezza Descrizione
la_type u int 64 Sempre ZAP_LEAF_ARRAY.
la_array 21 byte Contiene un nome o un valore.
la_next u int 16 Usato per collegare più chunk assieme nel caso sia necessario.

ZFS e ZPL
ZPL è il componente fondamentale per far sì che tutto questo sistema possa in effetti essere
utilizzato per salvarvi dei dati da un sistema Unix. Il suo scopo, come si capisce dal nome per
esteso, ovvero Zetafs Posix Layer, è quello di mappare la struttura ad oggetti gestita da uno ZFS
in una classica rappresentazione a file e directory tipica di un file system POSIX.
Appare quindi immediato capire come possa ZFS gestire file system multipli in uno zpool e
crearli a una velocità che ha lasciato basito chiunque lo abbia visto in funzione almeno una
volta. I file system non sono altro che una serie di strutture per permettere l’interpretazione degli
oggetti del pool; in particolare, i file system sono oggetti di tipo ZPL.
Ogni oggetto ZPL punta a un oggetto particolare che prende il nome di master node, la cui
posizione è fissa e il cui ID è sempre 1.
Questo oggetto, come ogni cosa all’interno di un oggetto ZPL, è a sua volta un oggetto di tipo
ZAP che, in questo specifico caso, contiene due attributi:
Campo Descrizione Valore
ID dell’oggetto
Questo oggetto contiene la lista delle cancellazioni che erano in corso al momento
DELETE_QUEUE in cui il file system è stato smontato oppure è mancata la corrente. La lista è usata
che
rappresenta la
per completare l’operazione durante il prossimo mount. Versione del file system.
delete queue.
ROOT Oggetto che funge da root directory del file system. ID dell’oggetto.

I file e le directory del file system sono quindi tutti rappresentati da degli oggetti ZAP
contenenti i valori riportati nella Tabella 7.58.
Tabella 7.58
Campo Grandezza Descrizione
zp_atime 2x u int 64 Data di ultimo accesso.
zp_mtime 2x u int 64 Data di ultima modifica.
zp_ctime 2x u int 64 Data di ultimo cambiamento.
zp_crtime 2x u int 64 Data di creazione.
zp_gen u
int 64
u int 64 Transaction group in cui il file è stato scritto.

zp_mode u int 64 Contiene le ACL POSIX e il tipo di file.

zp_size u int 64 Grandezza del file in byte.
zp_parent u int 64 ID dell’oggetto che rappresenta la directory padre.
zp_links u int 64 Numero di hard link a questo oggetto.
zp_xattr u int 64 ID di un oggetto ZAP che contiene gli attributi nascosti di questa directory.
zp_rdev u int 64 Device per i file di tipo CHARACTER o BLOCK DEVICE.
Flag ZFS. I valori possono essere 0x1 (vi sono attributi nascosti) oppure 0x2 (gli attributi
zp_flags u int 64
del file sono soggetti a ereditarietà).
zp_uid u int 64 uid dell’owner.
zp_gid u int 64 gid dell’owning group.
zp_acl u int 64 Struttura che rappresenta le ACL ZFS per questo oggetto.

Le ACL ZFS sono piuttosto articolate (nonostante il progetto lineare la complessità di ZFS
sarà apparsa evidente al lettore ben più di una volta nel corso di queste pagine). Le ACL si
possono trovare all’interno dell’oggetto ZAP che descrive il file oppure, nel caso che siano
molte e non trovino posto, come oggetti indipendenti.
La struttura zp_acl è mostrata nella tabella che segue.
Campo Grandezza Descrizione
Definisce se le ACL sono esterne. In tal caso conterrà l’ID di un oggetto di tipo
z_acl_extern_obj u int 64
DMU_OT_ACL che le racchiuderà.

z_acl_count u int 32 Numero di ACL relative a questo oggetto.

z_acl _version u int 16 Riservato.
z_acl_pad u int 16 Riservato.
In caso di ACL interna contiene un array al massimo di 6 ACE ( Access Control
z_ace_data array
Entry).

Una singola ACL ha la struttura seguente.

Campo Grandezza Descrizione
Contiene un uid o un gid nel caso che i campi ACE_OWNER, ACE_GROUP e ACE_OTHER non
a_who uid
siano avvalorati.
a_access_mask u int 32 Access mask a 32 bit.
a_flags u int 16 Descrivono il tipo di ACL e se è soggetta a ereditarietà.
a_type u int_16 Descrive il tipo di ACL.

Intent log
Il log di ZFS è pari al journal di un file system journal ma con una differenza, e cioè che
contiene sufficienti informazioni per poter concludere le transazioni; non contiene quindi solo i
metadati, ma anche i dati necessari.
Il motivo di tutto questo è piuttosto semplice. ZFS riunisce tutte le scritture in gruppi di
transazioni che poi vengono scritte atomicamente su disco. Tra un’operazione di scrittura fisica
e l’altra tutte le variazioni sono gestite come oggetti DMU in memoria. Quindi, per evitare la
perdita totale dei dati nella cache nel caso di una caduta di tensione, il log contiene tutte le
informazioni necessarie per poter completare la transazione.
Questo meccanismo, insieme al Copy-on-Write, che fa sì che i blocchi che compongono un
oggetto non siano mai sovrascritti in fase di scrittura/modifica ma vengano copiati su blocchi
nuovi prima dell’operazione, fa di ZFS il file system più sicuro che esista. Difatti, non solo è
possibile recuperare facilmente un file nella versione precedente la modifica ma, al contrario di
altri file system journaled come Reiser, non fa mai operazioni di rollback nel caso di caduta di
tensione ma porterà sempre a termine l’ultima operazione effettuata.

Conclusioni su ZFS
ZFS è un file system complesso. La sua gestione ad oggetti lo rende completamente diverso
da qualunque cosa comparsa finora nel panorama dell’informatica. Tale complessità, se da un
lato provoca smarrimento in chiunque voglia affrontare l’analisi a basso livello (e onestamente
è veramente l’ultima delle possibilità), dall’altro lato permetterà, nel momento in cui saranno
disponibili tool necessari, di disporre di una notevole quantità di informazioni che si
riveleranno utilissime in fase di indagine.
Inoltre, la sua struttura non permette di effettuare molte di quelle operazioni di data hiding a
basso livello che tanto danno filo da torcere a un forensics expert. In ogni modo, ZFS è un
fenomeno che non può essere ignorato.

BtrFS (Butter File System)

Chi segue il mondo dei file system sa che la saga di ZFS è seconda solo a quella di Final
Fantasy. È inutile stare a cercare di capire di chi sia la colpa di tutto questo (se di Oracle che
sembra osteggiare molti dei progetti open source ereditati dall’acquisto di Sun, della licenza o
di cos’altro), ma il risultato non cambia. ZFS è un file system rivoluzionario che non ha ricevuto
l’attenzione e l’uso che avrebbe dovuto.
Come già accennato, soprattutto sulla piattaforma Linux (che utilizzando la licenza GPL per il
proprio kernel ed essendo quest’ultima incompatibile con quella di ZFS impedirà per sempre
l’incorporazione del codice di ZFS a kernel level) si sono creati una serie di progetti che
potessero replicare le feature di ZFS.
BtrFS è il primo esempio (si potrebbe aggiungere funzionante, dato che il progetto Tux3,
avviato ben prima, sta arrancando) di file system di tipo Copy-on-Write (COW) e sfrutta molti
dei concetti tipici di ZFS. A differenza di quest’ultimo non è un file system ad oggetti ma usa una
struttura basata su B-Tree molto più simile a quella di OCFS2 (mutua da ZFS i concetti di
gestione degli snapshot, del Copy-on-Write, della gestione diretta dei pool di dischi e della
gestione dei nested file system, mentre da OCFS2 la gestione dei dati basata su B-Tree ed
extent).
BtrFS nasce come file system versatile. Coniuga infatti molte caratteristiche server-based ma,
nel contempo, è stato scelto come file system di default di MeeGoo e, quindi, anche del suo
successore Tizen; si può quindi già trovare su alcuni modelli di telefoni Samsung.
BtrFS deve allora unire i seguenti aspetti.
Scalabilità: deve poter funzionare sui sistemi di storage moderni e quindi raggiungere
dimensioni ragguardevoli, magari effettuando il join di più LUN provenienti da back-end di
tipo differente. Deve inoltre essere in grado di funzionare sia sistemi con risorse di
memoria e CPU limitate (smartphone) sia su grandi server dipartimentali.
Performance.
Protezione dei dati: da sempre un obiettivo primario. Questo file system include numerose
 feature come checksum su vari livelli, strutture dati e duplicazione dei metadati.
Adattabilità: il file system deve essere in grado di adattarsi alle diverse tecnologie di
storage su cui andrà installato. Supporta quindi funzioni specifiche come la gestione del
TRIM su SSD o la possibilità di effettuare il join di LUN provenienti da tecnologie
totalmente differenti.

Introduzione e principi di funzionamento

BtrFS nasce dalle idee base di ZFS. Il suo sviluppo è il risultato dello sforzo congiunto sia
della comunità open source sia di alcune società IT che lo hanno sponsorizzato fin da subito. Tra
queste vi sono Red Hat, Suse, Fujitsu, Intel e Oracle. Non sorprende quindi che tra le sue
caratteristiche principali vi siano delle feature di classe enterprise.
CRC: sia i dati sia i metadati sono validati tramite CRC. Questo permette di identificare
velocemente i possibili errori e intervenire in maniera tempestiva.
Snapshot: non solo BtrFS ha il supporto agli snapshot ma fornisce all’utente anche la
possibilità di avere degli snapshot scrivibili (cloni) e di usarli come dei tradizionali file
system.
Supporto multipiattaforma: qualunque sistema Linux (o Linux-based, come Tizen) potrà
utilizzare un file system BtrFS, indipendentemente dall’architettura su cui è basato.
Resize e deframmentazione a caldo: tutte le operazioni di manutenzione si possono eseguire
anche con il sistema in produzione.
Compressione online.
Gestione efficiente dei file di piccole dimensioni.
Ottimizzazione specifiche per le varie tecnologie di storage.
A livello di layout del file system, si può affermare che si tratta di una foresta di B-Tree con
una radice comune, i dati sono salvati in extent di grandezza variabile e dotati di checksum per
un controllo sull’integrità dei dati, funziona con il principio del Copy-on-Write e utilizza degli
appositi counter per trovare le referenze ai singoli extent usati al fine di gestire efficacemente le
routine di space reclamation.
Tutta la struttura relativa ai metadati e al puntamento degli extent usati per i dati è contenuta
all’interno di una serie di B-Tree. Tali B-Tree sono utili in quanto sono strutture molto duttili e
possono essere modificati in maniera veloce in modo da poter gestire il comportamento tipico
di un file system basato su COW.
Si ipotizzi ora una struttura semplice.
 Il root block del B-Tree contiene i puntatori ai nodi da lui direttamente linkati. Ora si
immagini di dover cambiare la chiave n. 13. Dato che è un file system COW, tutto quello che
viene variato sarà scritto in blocchi nuovi e si dovrà tenere traccia delle modifiche, siano esse
relative ai dati o ai metadati. Quindi, in questo caso quello che sarà duplicato saranno il root
block (in quanto deve puntare a un nuovo nodo) e il nodo dove sarà necessario variare la
chiave.

Prendere uno snapshot diventa un’operazione semplicissima. Si dovrà duplicare solo il root
tree del file system.

Con l’andare del tempo il nuovo root block continuerà a puntare ai blocchi puntati al
momento della cattura dello snapshot, mentre il B-Tree del file system continuerà a variare nel
corso del tempo.
 Ogni singolo blocco dispone di un counter che tiene conto di quante volte esso è referenziato
all’interno del file system. Tale counter permette di gestire quindi in maniera corretta la
cancellazione del blocco. Il blocco sarà cancellato e il suo spazio restituito al computo dello
spazio libero del file system solamente nel caso le sue referenze siano pari a zero.

Strutture dati all’interno dei B-Tree

I B-Tree usati in BtrFS sono piuttosto semplici. I costrutti contenuti all’interno dell’albero
sono solamente di tre tipi diversi: key, item e block header.
Una key è una struttura base che serve a puntare un oggetto, come nella tabella seguente.
Campo Tipo
Object ID Unsigned a 64 bit
Type Unsigned a 8 bit
Offset Unsigned a 64 bit

Un item è una struttura dati che incorpora una key e due campi aggiuntivi.
Campo Tipo
Key Struct di tipo “key”
Offset Unsigned a 32 bit
Size Unsigned a 32 bit

Tutti i blocchi, indipendentemente dalla loro posizione e utilizzo, contengono in testa un block
header. I blocchi intermedi dell’albero contengono solamente delle coppie fomate da una key e
da un block-pointer. Le foglie dell’albero contengono invece degli array formati da coppie
item/data.
All’inizio del blocco si troverà l’array contenente gli “item” mentre l’array che contiene i
blocchi “data” si troverà alla fine, in ordine inverso rispetto al primo. In questo modo il primo
elemento “item” farà paio con il primo elemento “data” letto partendo dalla fine del blocco.
Entrambi gli array crescono verso il centro del blocco.
Dato che i blocchi “data” hanno una grandezza variabile, per la loro gestione sono instanziati
diversi tipi di strutture di controllo del file system. Il tipo di struttura che si troverà associata al
blocco “data” sarà indicata attraverso il valore type della key a esso associata.
NOTA
Non si faccia confusione. I blocchi “data” non contengono dati relativi ai file ma si tratta sempre di strutture di
controllo facenti parte dei metadati.

BtrFS, come altri file system (NTFS e OCFS2), permette la gestione di inline data ovvero la
possibilità di salvare i file di piccole dimensioni all’interno degli extent utilizzati per la
gestione dei metadati tramite B-Tree.
Ogni singolo B-Tree all’interno del file system è considerato come un oggetto a sé. Quando,
per esempio, è necessario copiare un nuovo file all’interno del file system, si istanzierà un
nuovo object_id che sarà associato al root node di un nuovo B-Tree. La stessa cosa dicasi di un
subvolume, di uno snapshot o di qualunque altra struttura sia interessata dalla creazione di un
nuovo root block di un B-Tree.
Quello in cui BtrFS differisce sostanzialmente da ZFS è nella gestione dello spazio in cui
sono allocati i file. BtrFS utilizza una classica struttura a inode tipica del file system Unix. A
differenza dei file system Unix più classici BtrFS utilizza però in maniera molto intensa il
concetto di extent. Lo scopo di BtrFS è quello di ridurre al massimo la frammentazione in
scrittura.
I file vengono memorizzati in extent, le aree contigue su disco che contengono i dati senza
intestazioni aggiuntive o formattazione di alcun genere (i dati sono scritti raw). Un extent item
registra un generation numer per ogni extent allocato e una coppia di valori (disk_block, number of
blocks) in modo da registrare i dati dell’extent utilizzato per lo specifico file. All’interno

dell’extent usato per salvare i dati sono riportati l’offset logico e il numero di blocchi usati
dall’extent item che lo descrive. In qusto modo è possibile, per esempio, effettuare delle
operazioni di riscrittura sul file senza dover prima dover cercare l’extent item all’interno dei
metadati.
Il modo di gestire le directory diventa un mero esercizio di intuitività. Verrà istanziato un
apposito B-Tree, che conterrà un root node, e degli extent che conterranno a loro volta degli
array di tipo dir item. Ogni array conterrà due campi.
Campo Tipo
File Name Strings
Object_ID Unsigned a 64 bit

Ogni directory ha inoltre due indici associati (e contenuti in appositi nodi del B-Tree) per
permettere delle veloci ricerche all’interno delle directory.

Struttura del file system

Un file system BtrFS è generalmente descritto come una foresta di B-Tree. Una struttura
apposita (superblock) viene posta in una locazione specifica e fissa del file system. Tale
superblock punta a un tree of tree-roots, ovvero un B-Tree che tiene traccia degli starting point
(cioè dei root block) di tutti i B-Tree presenti. Questi alberi possono essere dei seguenti tipi.
Sub-Volume: permettono di gestire tutti i file e le directory visibili. Ogni subvolume è
implementato come un diverso B-Tree e ognuno di essi è indicizzato dal tree of tree-roots.
Ogni subvolume è gestito come un file system separato all’interno dello stesso volume. Su
ogni subvolume si possono fare delle operazioni di snapshot e cloning in maniera
indipendente gli uni dagli altri.
Extent-allocation tree: è un albero di extent item e traccia tutti gli extent allocati finora nel
volume, indipendentemente da quale sia il B-Tree a cui appartengono. Viene usato come
mappa per la gestione dello spazio libero nel disco, ma anche come backup per recuperare
il puntamento a uno o più extent se questi fossero danneggiati all’interno del B-Tree di
appartenenza dell’extent.
Checksum tree: contiene un B-Tree nel quale si trova un valore di checksum per ogni extent
allocato all’interno del volume.
Chunk and device tree: è una sorta di “hardware abstraction layer” tra il file system e la
struttura reale dei dischi. È tramite di esso che si possono gestire i livelli di RAID
all’interno di un BtrFS. In pratica, a seconda del livello di RAID scelto viene generato un
B-Tree con la mappa dei blocchi reali e la loro struttura logica da presentare al file system.
Reloc Tree: è un albero specializzato per la gestione della riallocazione degli extent. È
usato estesamente dalle routine di deframmentazione del file system.
Come si può notare vi sono moltissime strutture da variare per qualunque operazione che
coinvolga una struttura su disco. Inoltre, dovendo gestire tutto il file system con delle logiche di
COW, si capisce subito che per ogni operazione si generano centinaia di blocchi duplicati, dato
che ognuna di esse coinvolgerà, quantomeno, a livello di superblock, di tree of tree roots, di
extent allocation tree, checksum tree, oltre al B-Tree descrittivo di ogni singolo file. Per questo
motivo tutte le variazioni sono accumulate in apposite aree di memoria. Molto spesso lavorando
su vari file, grandi quantità di operazioni finiscono per accumularsi sulle stesse strutture ed
extent. Il file system quindi le ammassa in memoria e poi effettua le operazioni di scrittura su
disco a intervalli regolari. Tali operazioni avvengono di norma ogni 30 secondi e prendono il
nome di “checkpoint”. Quando un checkpoint viene effettuato il superblock viene modificato per
puntare al nuovo checkpoint. In caso di crash del file system, il sistema ripartirà usando l’ultimo
checkpoint disponibile, così da partire con tutte le strutture corrette.

Device e Volume Manager

BtrFS dispone di un proprio device manager e quindi non necessita né di quello standard di
Linux né tantomeno di LVM (anche se è possibile utilizzarli entrambi). Al momento sono
supportati i livelli di RAID 0/1/10. Il supporto ai livelli 5/6 è atteso da tempo ma svariati bug
ne hanno bloccato il deploy sia nella versione 3.5 sia nella 3.6 del kernel di Linux. Gli
sviluppatori si sono impegnati per avere una versione stabile del subsystem RAID 5/6 per la
versione 3.9 del kernel.
BtrFS lavora dividendo lo spazio di allocazione messo a disposizione dai vari device in
chunk. Ogni chunk ha una grandezza approssimata dell’1% dello spazio totale. I chunk vengono
poi divisi in modo da riflettere il livello di RAID e il layout fisico dei dischi. Per esempio, nel
RAID 1 ogni logical chunk sarà diviso in due parti identiche e ognuna di esse sarà scritta su un
disco diverso.
Il B-Tree Chunk and device gestirà, come precedentemente scritto, la traduzione tra i logical
chunk e le parti fisiche.
Il vantaggio di una struttura del genere sarà, nel momento in cui saranno disponibili i livelli
RAID 5/6, di poter passare da un livello all’altro di RAID in maniera molto semplice, a caldo e
senza avere un impatto sul file system (è necessario solo ricalcolare il Chunk and device tree).
Oppure si potrà disporre di diversi livelli RAID sugli stessi dischi (per esempio RAID 1 per i
metadati e RAID 5 per i dati).

Conclusioni
ZFS e BtrFS costituiscono una strada che, indipendentemente da tutto, è segnata. Tutti i file
system prima o poi la imboccheranno, indipendentemente dalla piattaforma.
Dal punto di vista dell’analisi forense, questi sistemi sono una miniera d’oro e un incubo. Una
miniera d’oro perché l’uso esteso delle funzioni COW, degli snapshot e dei cloni rischia di
lasciare su disco milioni di tracce che possono essere vitali per un indagine.
Di contro la complessità delle strutture rende praticamente impossibile un esame a mano.
Molto si può fare con i tool di debug ma è assolutamente necessario che le software house che si
occupano di sviluppare strumenti di analisi forense investano per poter automatizzare il
recupero di file o di parti d’essi, così come l’analisi degli snapshot dimenticati. Ci si augura che
questo accada al più presto.
 Capitolo 8

Tool e programmi di analisi

“... Storage, cartella Programmi, Digital Forensics, e qui si apre la mia cassetta degli attrezzi virtuale. Ho il programma
giusto quasi per qualunque cosa. La parte più difficile è tenere aggiornata la collezione...”

Premessa
“La vita è come una scatola di cioccolatini, non sai mai quello che ti capita” diceva Forrest
Gump nell’omonimo film.
Poche frasi si possono applicare meglio alla professione del Digital Forensics expert.
L’informatica è un mondo e il suo campo di applicazione è vastissimo. Ergo, sul nostro tavolo
può arrivare di tutto.
DIARIO DI UN DIGITAL FORENSICS EXPERT
Nel corso degli anni abbiamo accumulato un’enorme collezione di strumenti, insieme a shell script e altri
programmi sviluppati in autonomia. Abbiamo dedicato un intero storage alla parte di utility e tool. Al contrario di
quanto è accaduto in passato, alcuni pacchetti di analisi forense sono diventati strumenti di uso quotidiano. Ormai
tutte le analisi si svolgono con un connubio di software e sistemi operativi commerciali e open source. La via del
pragmatismo nella Digital Forensics è fissata.

La bravura di un investigatore informatico risiede probabilmente nella capacità di riutilizzare

un ampio ventaglio di semplici programmi, adattandoli di volta in volta a ciò che gli occorre.
Debugger, editor esadecimali, tool di sviluppo, linguaggi di scripting vengono usati in
contesti del tutto nuovi, per arrivare al fine ultimo, ovvero trovare la fonte di prova necessaria
per dare una svolta all’indagine.
Anche in questo caso è bene avere un atteggiamento il più pragmatico possibile. Non è
pensabile di utilizzare unicamente strumenti commerciali o unicamente software open source:
ciascuno dei due mondi ha delle lacune che possono essere colmate solo attingendo da entrambi.
È vero. Vi sono pacchetti che sembrano promettere di essere lo “Shangri-la” della Digital
Forensics. Ovviamente questo non corrisponde a verità. Alcuni sicuramente facilitano non di
poco l’analisi dei reperti ma certamente non possono coprire il fabbisogno totale di un
laboratorio di Digital Forensics.
Ciò che si intende asserire è che la dipendenza da questi programmi è sempre dannosa. Non
si può pretendere di usare uno di questi programmi come unico ambiente di lavoro per tutte le
indagini. La “colpa” di questo atteggiamento, che a volte capita di riscontrare, non è di tecnici e
investigatori, ma di una campagna promozionale fuorviante e di certificazioni che mirano a
verificare non tanto le competenze informatiche/investigative del soggetto quanto piuttosto la sua
conoscenza delle funzioni del programma specifico.
Anche il miglior programma di analisi forense non potrà essere utilizzato in ogni situazione:
vi sono limiti dettati dal sistema operativo “ospite”, dai file system supportati, dai tipi di binari
interpretabili, dalla potenza del sistema di scripting e da mille altri fattori.
La duttilità è la qualità primaria che deve appartenere a un investigatore informatico, che
potrà raggiungere gli obiettivi con i mezzi più consoni al proprio modo di lavorare e alla
propria formazione; basta che i mezzi non divengano alla lunga solo “il” mezzo.

Categorie
I tool necessari per l’analisi forense rientrano in una serie predeterminata di categorie, le
quali rispecchiano i diversi livelli di un’indagine che, partendo dallo strato più superficiale,
scendono sempre più in profondità alla ricerca delle evidenze.
Sistemi di virtualizzazione. Non sempre un Digital Forensics expert può usare il suo
sistema preferito. Talvolta, specialmente nel momento in cui si ha a che fare con applicativi
e formati file particolari, può essere necessario lavorare con una copia del sistema sul
quale si sta indagando. In questo caso sarà obbligatorio operare in un ambiente che sia il
più possibile controllato e controllabile. Anche la caccia a malware e phishing potrebbe
richiedere di far girare la macchina compromessa per capire dove il software vada a
salvare i dati o chi cerchi di contattare. Tutto questo risulta molto più semplice lavorando
con sistemi virtuali. Non solo. Spesso e volentieri i sistemi da analizzare sono loro stessi
virtuali. Chi scrive da molto tempo non fa più un deploy di un server fisico. Anche le
aziende di minori dimensioni scelgono di usare macchine virtuali in cloud o di avere una
piccola infrastruttura in proprio (due nodi e uno storage) così da poter consolidare il parco
macchine e minimizzare i costi di gestione. Al momento vi sono davvero una pletora di
sistemi di virtualizzazione da poter utilizzare sulle piattaforme x86 e x86_64, sia open
source sia commerciali. Quindi nel laboratorio è bene poter disporre di un sistema analogo
sia per la virtualizzazione delle macchine reali (come si è appena mostrato) sia per la
gestione di eventuali macchine virtuali acquisite sul campo.
Programmi di hacking/cracking. Al contrario di quanto può pensare il profano,
difficilmente un Digital Forensics expert deve ingegnarsi per superare le protezioni
usualmente poste in essere dai sistemi operativi: il metodo di lavoro permette
semplicemente di ignorare account e ACL del file system (anche se le cose stanno
cambiando anche da questo punto di vista). Di contro, spesso vi sono protezioni a livello
 di file, come password per l’apertura dei documenti o sistemi di crittografia. In questi casi
possono tornare utili programmi di brute force per l’attacco delle password o per il
recupero delle stesse da file di cache, registry, memoria, file di swap e file temporanei.
Recentemente si è lavorato molto nel campo, con l’adozione di librerie specializzate, come
le CUDA o le future OpenCL, che hanno permesso di spostare parte dell’elaborazione nelle
potenti GPU delle moderne schede grafiche. Alcuni programmi di password cracking hanno
tratto enormi vantaggi da questo aumentando le proprie performance di diversi ordini di
grandezza. Altri tool utili sono i sistemi di debugging e disassembling per approfondire il
funzionamento del codice.
Programmi di conversione. Spesso non è possibile utilizzare direttamente i dati trovati. Si
pensi, per esempio, alla posta elettronica in formati proprietari (file OST di
Exchange/Outlook, file NSF di Lotus Notes), ai dati contenuti in un database (Oracle,
SQLServer, Informix, MySQL, PostgreSQL) o ai formati immagine meno diffusi (IFF, PCX,
RGBA, UFO, TGA...). È indispensabile, quindi, possedere programmi che siano in grado
di effettuare le conversioni di formato necessarie.
Programmi di file analysis. All’interno di questa categoria vi sono tutti i programmi che
vengono utilizzati per analizzare i singoli file. Si parte quindi dai visualizzatori di file, per
passare ai programmi che verificano l’adesione tra dati e metadati (tipicamente controllano
che il file contenga ciò che ci si aspetta, evidenziando, per esempio, se quanto viene
descritto come un file di testo non contenga, in realtà, un’immagine JPEG), a quelli che
verificano che non siano presenti contenuti nascosti (come stegdetect, che evidenzia la
presenza di materiale steganografico), ai correlatori di log e molti altri. A questa categoria
appartengono anche gli indispensabili editor esadecimali utili per l’analisi a basso livello.
Programmi di data e file recovery. Effettuando questo tipo di lavoro occorre spesso
analizzare anche ciò che non è immediatamente visibile. Tornano quindi utili tutti quei
programmi per il recupero dati sia a livello di file system (file cancellati, file system
corrotti, hardware malfunzionante), sia a livello applicativo (database corrotti, estrazione
dati da piattaforme proprietarie).
Questi tool saranno obbligatoriamente multipiattaforma. È consigliabile riuscire a lavorare
con programmi che siano facilmente portabili da un’architettura a un’altra. Molti strumenti open
source lavorano nativamente sotto GNU/Linux o BSD ma possono essere ricompilati, senza
eccessive difficoltà, sotto OS X (in fondo si tratta di uno Unix, anche se molto dissimile dagli
altri) o sotto Windows (specialmente tramite l’ambiente di compatibilità Cygwin). Molto utili
sono anche i programmi scritti in Java, viste le caratteristiche di questo linguaggio.
Purtroppo non sempre questo è possibile. La maggior parte dei programmi di data recovery,
sia a livello di file system sia a livello di dati applicativi, è disponibile solo per la piattaforma
di riferimento. Per esempio, non esistono praticamente programmi per il recovery e la
conversione dei formati file di Outlook (OST e PST) per piattaforme diverse da Microsoft
Windows o per il recovery di file cancellati su HFS che non siano per Mac.

Sistemi di virtualizzazione
I sistemi di virtualizzazione sono usati, in ambito forense, più spesso di quanto si sia portati a
credere. Senza di essi, si dovrebbe possedere laboratori contenenti decine di computer
specializzati per compiti differenti. Vi sono due distinte tipologie d’uso di un ambiente virtuale
per un Digital Forensics expert.
Virtual appliance. È una serie di ambienti specializzati destinati ad ambiti particolari. Un
esempio classico è un ambiente Windows Server per il recovery di database Exchange,
oppure un motore Oracle o SQL Server per lavorare su file di database.
Sandbox. Vi sono casi in cui è necessario lavorare direttamente con il sistema operativo
del computer oggetto di verifica. Dato per scontato che non si possono modificare le
evidenze usando l’hardware reale, è possibile utilizzare un sistema di virtualizzazione per
lavorare con una copia su un ambiente controllato e controllabile.
Come accennato, la virtualizzazione è ora in un periodo di grande risalto, complici sia il
nuovo trend dei processori multicore, sia le estensioni specifiche delle nuove generazioni di
CPU (IVT di Intel e AMD-V di AMD), sia i recenti dettami di risparmio energetico. Pertanto,
non solo sono drasticamente migliorati gli ambienti di virtualizzazione, ma è sempre più comune
trovare computer virtuali che richiedono di essere esaminati.

VMware
VMware Inc. ha avuto il pregio di essere la prima società a lavorare su sistemi di
virtualizzazione per piattaforme IA-32 e compatibili, iniziando a operare nel lontano 1998.
Questo fatto non solo ha assegnato a VMware il vessillo di pioniera nel campo, ma le ha anche
garantito la possibilità di accumulare un know-how assolutamente ineguagliato rispetto sia
all’ambito commerciale sia a quello open source.
VMware da sempre si è distinta per essere un’azienda in continua evoluzione. Ha introdotto
la virtualizzazione nella piattaforma x86, ha spinto per l’adozione di estensioni specifiche nei
processori prodotti da AMD e Intel, ha sviluppato hypervisor level-1 e level-2 (Mac
compreso), ha continuato a implementare nuove feature nei suoi prodotti e ha introdotto la
virtualizzazione della parte desktop, ivi compresa la parte per l’accelerazione della grafica 3D
lato server. Il tutto mantenendo anche una serie di prodotti free to use.
In questo modo ha reso la soluzione di virtualizzazione alla portata di tutti e, nel contempo, ha
combattuto con onore l’avanzata di concorrenti e del mercato open source.
Nella gamma dei prodotti VMware, alcuni meritano una speciale attenzione.
VMware Workstation: è uno dei primi prodotti della casa di Palo Alto e da anni è la
soluzione di riferimento per il mercato desktop. Ogni nuova release segna un ulteriore
passo. Progressivamente si sono introdotte nuove feature come il supporto ai vari USB (3.0
compreso), l’unificazione del virtual hardware che ha portato, per esempio, a poter fare un
deploy direttamente su piattaforma ESX oppure a mantenere una totale compatibilità tra
workstation, player, ESX e Fusion. Tra le feature più utili si segnalano le seguenti:
– snapshot multipli: è possibile effettuare un freeze della macchina virtuale in ogni
momento e salvarne lo stato nel corso del tempo. In questo modo si possono effettuare
delle analisi preservando lo stato della memoria durante le operazioni cruciali;
– modalità di gestione del disco “not persistent”: configurando un disco in questa modalità
la macchina virtuale salverà tutte le operazioni di scrittura in una serie di file separati che
saranno eliminati al termine della sessione. In questo modo si possono eseguire operazioni
potenzialmente distruttive (o che semplicemente potrebbero alterare la prova) sapendo che
saranno ripetibili;
– teaming: più macchine virtuali possono essere lanciate contemporaneamente per formare
una rete totalmente virtuale in un ambiente controllato;
– supporto per periferiche USB 3.0;
– supporto per l’utilizzo di monitor multipli;
– supporto per macchine virtuali provenienti da altri fornitori.
VMware Fusion: è il prodotto di virtualizzazione riservato alla piattaforma Mac. È ormai
perfettamente allineato con tutti gli altri prodotti della casa.
VMware ESX Server: è il virtualizzatore Type-1 della casa di Palo Alto. È il punto di
riferimento di tutti i prodotti lato server della società, da VMware Workstation (che guarda
caso utilizza lo stesso virtual hardware) al vCloud Director, ovvero l’orchestrator di
VMware per la gestione dei sistemi cloud (che usano ESX come nodi). La base del sistema
è gratuita ma tutte le funzioni interessanti sono riservate alle versioni a pagamento.
VMware Converter: permette di trasformare una macchina reale in un PC virtuale da
utilizzarsi con uno dei vari prodotti di virtualizzazione di VMware. Il processo di
adattamento dei driver e del sistema operativo per la nuova architettura è totalmente
automatizzato e non necessita di ulteriori interventi.
NOTA
L’utilizzo di ambienti di virtualizzazione per lavorare sul sistema operativo della macchina acquisita impone la
modifica della copia di lavoro. Non si deve quindi mai operare sulla prima copia lavoro, bensì su una delle
successive. In ogni caso ci possono essere molte situazioni in cui questo non è necessario, specialmente in
presenza di programmi scritti appositamente, ambienti con sistemi operativi proprietari o qualora si indaghi su
un crimine informatico e si sospetti la presenza di programmi come trojan e worm. In particolare, si vuol far
notare come l’hash del vmdk vari costantemente durante l’analisi. Anche ricorrendo a tecniche di analisi non
 invasive, come il tradizionale boot con un live CD o una sua ISO, l’hash delle singole partizioni del disco virtuale
rimarrà identico ma quello del disco virtuale sarà sempre diverso. Lo stesso comportamento si evidenzia anche
usando dischi read-only o in modalità independent.

Si ipotizzi di sospettare la presenza di un trojan appositamente scritto per spedire

informazioni prelevate dal computer violato. In questo caso si potrebbe non solo virtualizzare la
macchina violata, ma anche un PC per l’analisi del traffico di rete nonché un’intera rete virtuale.
Tali macchine dovrebbero essere lanciate come parte di un team, così da virtualizzare
l’infrastruttura di rete ed esaminare i comportamenti del trojan in un ambiente dove non può
creare danni.

Parallels
Parallels è una giovane software house con base a Renton (Washington). È giunta alla ribalta
nel 2006, quando ha presentato la prima soluzione di virtualizzazione per sistemi Mac basati su
chip Intel Core. Nel giro di poco tempo il prodotto ha compiuto grandi balzi in avanti e la
società ha introdotto una notevole serie di migliorie in tutta la sua linea di prodotti di
virtualizzazione, compresi quelli per Linux e per Windows.
Al momento, pur focalizzandosi sulle soluzioni per la piattaforma Mac, offre anche sistemi di
hypervisor type-1 per server e soluzioni per il deploy e la gestione di piattaforme di tipo cloud.
Parallels Desktop per Mac è stato per molto tempo lo standard de facto per i sistemi di
virtualizzazione per Mac. Ora ha dovuto cedere il passo sia a VMware Fusion sia a soluzioni
più diffuse come VirtualBox. Rimane comunque uno dei bestseller tra i software disponibili per
Mac.

Xen
Nato come progetto di “paravirtualizzazione” presso i laboratori informatici dell’università
di Cambridge, Xen è probabilmente il progetto open source più avanzato esistente. Il grande
balzo di Xen è arrivato con la versione 3.0.x, che ha introdotto una notevole serie di migliorie
sfruttando le estensioni Intel-VTx per AMD-V. Prima di questo sviluppo Xen poteva far
funzionare, come “guest OS”, solo sistemi operativi opportunamente modificati. Non c’erano
problemi con sistemi open source, ma di fatto questo rendeva impossibile utilizzare qualunque
sistema commerciale.
Xen è stato acquistato in toto da una delle aziende maggiormente impegnate nel campo dei
thin client, ovvero Citrix. Quest’ultima rende ancora disponibile Xen come prodotto open
source a sé stante. Xen rimane la soluzione standard usata da moltissimi progetti open source e
commerciali anche di terze parti (primo tra tutti Oracle Virtual Server). Tutti i prodotti lato
server di Citrix sono basati su Citrix Xen Server, pur potendo essere integrati anche con altri
hypersor.

KVM
I progetti di virtualizzazione su Linux si sprecano, quindi non è raro imbattersi in qualche
novità ogni pochi mesi. KVM è molto interessante perché è direttamente integrato all’interno del
kernel vanilla (dalla versione 2.6.20) di Linux. È perciò disponibile virtualmente su ogni
computer che abbia installato un kernel di Linux recente e un processore X86 con le estensioni
per la virtualizzazione. KVM si distingue per una notevole velocità di esecuzione e per un
ottimo supporto. Per la parte a user space utilizza una versione modificata di QEMU. Tra i vari
progetti basati su questo modulo si distingue Proxmox (http://pve.proxmox.com/wiki/Main_Page), una
versione di Debian molto personalizzata e dotata di interfaccia web di gestione. Il sistema si
installa su praticamente qualunque moderno PC in pochi minuti e ha un footprint invidiabile
anche paragonato ai migliori hypervisor di VMware. La differenza rispetto a ESX si nota nel
supporto hardware, decisamente più ampio, dato che Proxmox è basato su un kernel standard,
seppur sfrondato di ogni componente che possa sottrarre RAM o risorse ai sistemi ospiti.

VirtualBox
Nato come progetto per la creazione di un hypervisor level-2 indipendente dalla piattaforma
da parte di Sun Microsystems, VirtualBox ha compiuto il suo cammino piuttosto in sordina
rispetto ai suoi più blasonati contendenti.
Stranamente il passaggio a Oracle non ha portato gli stessi scombussolamenti al progetto che
ci sono stati con OpenOffice e MySQL. Oracle ha continuato sulla strada di SUN e nello
sviluppo del progetto.
Il risultato è un sistema di virtualizzazione di tutto rispetto. Come detto rimane un un hypersor
type-2, il che significa che non è pensato per essere un sistema di tipo Bare Metal (anche se vi
sono molte minidistro Linux che sono costruite per fare da supporto a VirtualBox e, se abbinate
con l’ottima GUI web PHP VirtualBox, permettono di creare un sistema di virtualizzazione
completo e del tutto equivalente, come funzioni, a un type-1).
Il vantaggio di VirtualBox risiede però proprio nel fatto che è in grado di funzionare in
maniera indipendente dal sistema ospite. Tutte le funzioni sono disponibili per tutti i sistemi
operativi, così come il virtual hardware che è identico per tutte le versioni. Addirittura la
funzione di teleport (equivalente al vMotion di VMware) può effettuare il passaggio di una VM
da un nodo all’altro anche se questi funzionano su sistemi diversi.
VirtualBox non è pensato per far funzionare infrastrutture critiche (per ora non è dotato di
alcuna funzione di HA), ma come virtualizzatore desktop ha sicuramente dei punti a proprio
favore e gli permette di rivaleggiare con VMware Workstation.
 Anche VirtualBox dispone di funzioni di snapshot e di “immutable images” (equivalente ai
“non persistent disk” di VMware Workstation). Inoltre può importare senza troppi problemi le
virtual appliance (in formato OVF) di VMware. Può quindi rappresentare un’ottima scelta per le
workstation da analisi all’interno di un laboratorio di analisi forense.
Un laboratorio di informatica forense dovrebbe essere dotato di vari sistemi per l’esame di
macchine virtuali. Tali sistemi dovrebbero essere sia degli hypervisor, capace di far girare le
macchine stesse, sia del software in grado di permettere il loro esame come fossero delle
macchine fisiche. X-Ways Forensics è, per esempio, in grado sia di importare vari formati di
virtual disk sia di esaminare i dump della memoria di una macchina virtuale. Una volta dotatisi
di una sistema come quello descritto sarà possibile:
gestire sistemi per l’analisi: nei nostri laboratori disponiamo di varie virtual appliance
specializzate per alcuni tipi di analisi. Dato che sarebbe troppo oneroso dedicare una
singola macchina reale solo ad alcuni specifici tipi di analisi, è molto più pratico
virtualizzare tali sistemi e attivarli al momento. Non solo; con la distribuzione dei
laboratori sul territorio sempre più spesso ci si trova a operare su sistemi remoti attraverso
una qualche forma di telecontrollo. Tali workstation possono essere quindi virtuali,
migliorando la gestione generale dei sistemi;
esaminare il contenuto di macchine reali (trasformate in virtuali) e di PC virtuali giunti in
laboratorio.
Sarebbe buona cosa disporre di almeno un paio di sistemi di virtualizzazione leader nel loro
settore, per non dover passare la maggior parte del tempo a convertire le macchine da un
formato all’altro. Si è notato comunque che la maggior parte delle utility usate per convertire
macchine reali in macchine virtuali opera con il formato vmdk di VMware.
A tal fine è bene segnalare alcune utility e programmi che potrebbero tornare utili.
LiveView (http://liveview.sourceforge.net/): questo programma, prodotto dalla Carnegie
Mellon University, permette di trasformare un’immagine fisica (dd) in una macchina vmdk.
Se il sistema operativo interno della macchina è Windows è anche in grado di effettuare
l’injection dei driver necessari e di adattare i file di configurazione relativi alla fase di
boot. Unico grosso difetto di LiveView è uno sviluppo lentissimo, che lo ha reso
praticamente obsoleto.
dd2vmdk (http://sourceforge.net/projects/dd2vmdk/): è un tool online che permette di generare i
file di configurazione necessari per creare un vmdk da un file dd;
raw2vmdk (http://sourceforge.net/projects/raw2vmdk/): è un programma Java-based. Scritto sul
codice di LiveView, più alcune integrazioni, permette di convertire immagini dd in VMDK
utilizzabili da tutti gli hypervisor che supportano tale formato.
 NOTA
Ad ogni buon conto sia qemu sia VirtualBox (entrambi mediante i tool di controllo a riga di comando) permettono
di effettuare conversioni dal formato raw a quelli dei virtual disk più diffusi. Entrambi gli strumenti effettuano però
una conversione che richiede la lettura di tutto il disco (non creano solamente i file di configurazione con la
geometria del disco) e quindi sono decisamente più lenti delle utility di cui sopra.

Programmi di hacking e cracking

Come già specificato in precedenza, una corretta procedura di analisi raramente richiede
l’utilizzo di software atto a violare le protezioni poste a controllo del sistema.
Il motivo dovrebbe ora essere piuttosto lampante: non effettuando il boot con il sistema
operativo della macchina, bensì collegando i drive direttamente al sistema di analisi (sulla
quale il Digital Forensics expert gode di tutti i diritti necessari per accedere a basso livello
all’hardware), sarà possibile effettuare un bypass sia della parte di autenticazione (login) sia
dei privilegi di accesso del file system (ACL). Il Digital Forensics expert avrà semplicemente i
diritti di “root” (amministratore di sistema) su tutti i media collegati per l’analisi.

Casi possibili
Se questo idilliaco quadro funziona nella stragrande maggioranza dei casi, esistono situazioni
in cui, invece, si deve ricorrere ai trucchi e agli artifici più biechi per forzare le difese del
sistema. Il Digital Forensics expert deve allora posare il camice bianco per vestire, con
altrettanta disinvoltura, il cappello di un hacker white hat (perché anche in questo caso egli è
autorizzato a fare ciò che sta facendo).
Quando accade questa metamorfosi? Ecco alcuni esempi.
Utilizzo di sistemi di crittografia. Non esiste nulla che possa impensierire maggiormente un
Digital Forensics expert, specialmente se non si tratta di banalità tipo un cifrario di Cesare
come il ROT13. Una bestia nera rimangono i sistemi Mac. Se una volta la parte di
crittografia non era particolarmente diffusa, ora come ora le cose stanno cambiando
drasticamente. OS X Lion include di default FileVault 2. Al contrario del suo predecessore,
che crittografava solamente le home directory ed esponeva il sistema a un attacco a
dizionario per trovare la password di login, tale sistema effettua una vera e propria
crittografia di tipo Full Disk basata su AES-XTS, un’estensione particolare del più
standard AES-128 ottimizzata per le operazioni su sistemi FDE. Anche Microsoft si è
notevolmente evoluta. Solitamente la parte di crittografia è stata riservata per le versioni
aziendali o professionali dei propri sistemi operativi. La versione 8.1 di Windows ha
invece esteso a tutte le versioni, incluse quelle consumer, la crittografia BitLocker, sia per i
media connessi saltuariamente sia per i dischi di boot del sistema operativo. Non solo, ma
 per gli utenti che fanno uso di un account online e di TPM essa verrà abilitata per default.
Lo stesso dicasi per quei computer a cui saranno collegati dei telefoni basati su Windows
Phone. In quest’ultimo caso la crittografia sarà abilitata per default su entrambi i
dispositivi.
Utilizzo del sistema operativo originale. Come già accennato in precedenza, parlando dei
sistemi di virtualizzazione, talvolta non si può pensare di utilizzare le sole potenzialità
della macchina di analisi. La presenza di programmi particolari, di protezioni legate
all’hardware (è vero, sarebbero quasi tutte aggirabili “craccando” il codice con IDA Pro –
http://www.datarescue.com –, ma il tempo necessario per farlo è spesso troppo elevato) o di

ambienti la cui configurazione è così particolare da renderla difficilmente replicabile,

l’analisi su un virus o uno worm richiedono talvolta che si utilizzi il sistema operativo
della macchina originale. In questo caso è implicito che il forensics expert è soggetto a
tutte le limitazioni poste dal sistema operativo. Ci si dovrà quindi dotare quantomeno di
tool per resettare le password di accesso degli utenti e per ottenere l’accesso come
amministratori di sistema.
NOTA
Ciò non significa che si userà anche il disco originale della macchina, ma piuttosto una copia di lavoro dello
stesso sull’hardware originale (a patto che non si possa replicare) o all’interno di una macchina virtuale.

Protezione dei file. Talvolta sono imposte delle limitazioni a livello del file e
dell’applicativo utilizzato per aprirlo. File di Word, Excel, file ZIP dotati di password
sono un classico esempio. Anche in questo caso si rende necessario l’utilizzo di un
password cracker.

Password resetting

Reset password
Ogni sistema operativo ha una sua modalità per effettuare il reset della password di
amministrazione. Talvolta l’operazione è incredibilmente banale, ma in qualche caso potrebbe
diventare difficoltosa a causa di alcune protezioni. Come regola generale, disponendo
dell’accesso all’hardware è praticamente impossibile non riuscire a compiere questa
operazione.

BIOS password
I moderni computer (tranne i Mac e quelli che incorporano anche un firmware EFI) sono
ancora legati a questo vetusto pezzo di software.
È raro dover resettare la password di un BIOS, e tale processo dovrebbe essere effettuato
solo se non vi sono altre soluzioni plausibili.
Quando è necessario effettuare un reset? Ecco alcuni esempi.
Per abilitare il boot della macchina. Il BIOS potrebbe essere stato programmato per non
effettuare il boot della macchina senza una password specifica.
Per cambiare le impostazioni di boot della macchina, per esempio nel caso in cui si
desideri effettuare l’acquisizione del computer attraverso una live distro e il computer si
rifiuta di effettuare un boot da CD-ROM. Una possibile alternativa potrebbe essere
l’apertura della macchina e l’estrazione dei dischi. Tale soluzione potrebbe essere
difficoltosa in presenza di un RAID hardware con controller integrato in piastra.
Per disabilitare hardware che potrebbe essere problematico od ottimizzazioni che
impediscono l’uso di sistemi diversi. Alcune ottimizzazioni del BIOS potrebbero rendere
difficoltoso l’uso di sistemi operativi diversi da quello installato. Esperti informatici e/o
hardcore gamer spesso ricorrono a timing della RAM molto spinti o all’overclocking del
bus di sistema o della CPU. Lo stesso dicasi per un hardware particolare che potrebbe non
essere riconosciuto e bloccare il processo di boot del software usato per effettuare la
copia dei dati.
Per resettare la password del BIOS è necessario accedere all’interno del computer.
NOTA
Si tenga sempre presente che il computer è un oggetto fisico oltre che un sistema informatico. Sarebbe il caso
di documentare tutte le operazioni di apertura/chiusura/modifica e di utilizzare una procedura consolidata per
evitare di distruggere prove fisiche che potrebbero essere utili ad altre branche della polizia scientifica, quali
impronte digitali nell’interno dello chassis, polvere e cadaveri di insetti (si trovano più spesso di quanto non si
possa pensare).

Si localizzi il jumper di reset della CMOS (di solito posto vicino alla batteria) o la batteria a
tampone che conserva le informazioni della CMOS. Si tolga l’alimentazione elettrica e si agisca
sul jumper di reset della CMOS (come indicato sul manuale d’uso del computer o della scheda
madre, sempre che sia disponibile) o si tolga la batteria della CMOS per alcuni minuti. Si
riporti il sistema alla condizione originale e si dia corrente.
ATTENZIONE
Effettuando questa procura non si azzera solo la password, ma ogni dato conservato nella CMOS. Il più
importante di questi è certamente il time, ovvero la data e l’ora di sistema. In molte indagini il timing è
indispensabile per poter coordinare gli avvenimenti intercorsi all’interno di una rete di computer. Tutto questo
deve essere tenuto ben presente per non perdere irrimediabilmente delle informazioni preziose

Linux su x86 root password reset

 La password di root su un sistema Linux può essere cambiata con alcuni semplici passi
(ovviamente sempre che il sistema non usi sistemi di Full Disk Enryption).
In primo luogo si deve bloccare il boot loader in modo che non continui la sequenza di boot
così da poter variare i parametri di boot.
NOTA
Se l’utente ha protetto il boot loader con una password sarà necessario utilizzare un Linux su live CD per
operare il cambio di password.

Fermato il boot loader, andranno variati i parametri di boot. Il funzionamento del boot loader
dipende molto dai file di configurazione e dalle opzioni impostate dalla distribuzione installata.
SuSE, per esempio, utilizza sia per LILO sia per GRUB un identico menu con una riga in cui
inserire ulteriori parametri di boot. Altre distribuzioni diversificano il comportamento dei due
boot loader.
Chiarito come operare nel caso che si sta affrontando, è necessario aggiungere all’entry di
default il parametro:
init=/bin/bash

In questo modo il processo che si incarica di effettuare il boot (init) sarà sostituito da una
shell carattere (/bin/bash) subito dopo il caricamento del kernel. Il sistema interromperà il boot e
lascerà visibile solo una shell con i diritti di root.
A questo punto occorre dare i comandi elencati nella Tabella 8.1.
Tabella 8.1
Comando Funzione svolta
mount –o remount,rw / Permette di accedere al file system montato in modalità lettura/scrittura.
passwd Cambia la password di root.
sync Effettua il flush della cache del file system e forza la scrittura su disco.
Ctrl+Alt+Canc Effettua il reboot della macchina.

NOTA
Lo stesso procedimento si può applicare su molti differenti Unix, su piattaforma x86 o RISC. L’unica parte che
cambia considerevolmente è quella riguardante il boot in single user mode, che va quindi adattata di volta in
volta in base al tipo di hardware e di sistema.

Mac OS X Administrator password reset

Per prima cosa è necessario controllare se il computer è stato protetto con una password a
livello di firmware EFI.
Se la password fosse stata settata, le uniche due valide alternative sarebbero:
togliere la batteria interna aspettando che la RAM si cancelli;
togliere il disco fisso interno e collegarlo a un altro computer Mac.
 Eliminato questo problema (o constatato che non esista), si deve disporre del disco di
installazione di OS X. Si effettui il boot dal disco di installazione (facendo un boot del Mac con
il DVD inserito e tenendo premuto il tasto C) e si scelga la voce Reset password dal menu
Utility.
Un programma effettuerà la scansione dei login presenti e chiederà di quale si vuole
eliminare la password.
NOTA
Anche se si effettua il cambio della password di un utente tramite questo sistema, se FileVault (funzione di
home directory crittografata) è attivo la home directory non potrà essere decrittata con la nuova password.
Procedere al cambio password per questo motivo è assolutamente inutile. Nel caso si stia analizzando un
computer con OS X Lion o superiore con FileVault 2 tale operazione non potrà essere portata a termine, dato
che tutti i file di sistema che contengono le informazioni accounting stanno anch’essi in una partizione cifrata.

Windows (da 2000 in poi) Administrator password reset

Windows si dimostra inutilmente complicato nell’effettuare questa operazione; inutilmente
perché la procedura è in ogni caso fattibile avendo accesso fisico alla macchina (ovviamente a
scanso della presenza di una cifratura con BitLocker), quindi non prevedere tale procedura da
sistema operativo non aggiunge nulla alla sicurezza ma complica solamente la vita agli utenti.
Un discorso a parte va fatto però per i nuovi sistemi Windows 8, con il quale sono possibili
due tipi di account. Il primo è un account locale, che è esattamente come tutti gli altri account di
Windows. Il secondo è un account online. Si può paragonare l’account online a un account di
dominio, con la differenza che il dominio è mondiale ed è gestito direttamente da Microsoft
attraverso i servizi in cloud.
La gestione degli account online di Windows 8 è peculiare e quindi è il caso di tenere
presente una serie di nozioni in quanto possono essere utili nel momento in cui sia necessario
analizzare un sistema di questo genere.
In primis, il computer deve essere connesso online quando l’account viene installato. Molto
probabilmente questo è avvenuto durante la prima fase dell’installazione del sistema operativo.
Quando si acquista una macchina Windows 8 il processo di installazione va terminato con una
serie di impostazioni tra cui appunto la connessione a Internet e la gestione di un account. Se il
computer è collegato a Internet sarà proposta di default la creazione di un account online, che
può poi essere gestito dal sistema operativo o, per tutta una serie di funzioni, dal sito
https://account.live.com. Altrimenti sarà proposta la creazione di un più tradizionale account

locale.
Da notarsi che la presenza e l’utilizzo di un account online cambia alcuni comportamenti del
computer, e per certi versi può facilitare la vita a un Digital Forensics expert.
Molte opzioni sono sincronizzate online. Il tema scelto, lo sfondo e le personalizzazioni
dell’ambiente sono gestiti alla stregua di un roaming profile. Utilizzando uno stesso account su
più macchine tutte queste avranno un ambiente di lavoro univoco. Inoltre, e questo è da tenere
bene in considerazione, nel caso si decida di attivare la cifratura BitLocker, onde evitare di
dimenticare o perdere le chiavi, il sistema propone di default di copiare i propri certificati di
cifratura all’interno dell’account. Questo vale sia per i dischi di sistema sia per quelli
rimovibili. Considerando che il nuovo Windows 8.1 utilizzerà BitLocker out-of-the-box,
saperlo può essere un modo per riuscire a gestire una situazione che potrebbe diventare un
problema insormontabile.
Gli account online di Windows pongono poi dei problemi relativamente alla gestione delle
password. Innanzitutto il comportamento del sistema con gli account online è differente sia da
quello con gli account locali sia con quelli di dominio.
La prima volta che ci si collega con un account online il sistema deve essere necessariamente
connesso a Internet. In tal caso il sistema provvederà a creare una home directory sotto /Users e
a creare delle entry specifiche nel registry. In particolare nel percorso
\HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users sarà creata una subkey con
l’RID dell’account Microsoft a cui si fa riferimento.
All’interno della subkey il valore CachedLogonInfo conterrà la versione cifrata della password.
Tale valore non è temporalmente limitato e quindi non scade mai.
Il funzionamento della parte di autenticazione sarà il seguente. Per iniziare il sistema
provvederà a verificare la password introdotta rispetto a quella presente nella cache: strano a
dirsi questo accade sia che il computer sia connesso a Internet sia che sia offline. Se è offline il
sistema permetterà di loggarsi all’interno dell’account utilizzando l’ultima password presente
nella cache; se è online il sistema permetterà di loggarsi con l’ultima password presente nella
cache. Si possono manifestare due casi:
la password nella cache è identica a quella online: nulla accadrà e si effettuerà il login;
la password nella cache è diversa da quella online: nel caso si inserisca la password nella
cache si potrà accedere al proprio login (bug di sicurezza). La password nella cache non
verrà aggiornata e quindi potrà essere utilizzata per continuare a lavorare sul computer
finché non si inserisce almeno una volta la nuova password. Infatti nel caso si inserisce la
password online, il sistema operativo la verificherà con quella nella cache, trovandola
diversa, la verificherà con quella online e, nel caso questa sia corretta, provvederà ad
aggiornare la copia nella cache durante le procedure di login.
Al momento attuale non c’è alcun programma di password cracking che sia in grado di
effettuare un attacco al campo CachedLogonInfo.
L’unico programma in grado di resettare in maniera corretta tale valore è PC Unlocker
(http://www.pcunlocker.com/). Mediante tale sistema è possibile creare un boot disk (USB o CD-
ROM) in grado di resettare le password di qualunque account di Windows, ivi compresi quelli
contenuti all’interno di Active Directory.
Fino a poco tempo fa vi erano una numerosa serie di progetti open o free che permettevano di
effettuare la stessa operazione. Nessuno di questi supporta però alcuna versione di Windows
che sia maggiore di XP e quindi sono da considerarsi del tutto obsoleti. Considerando che il
costo di PC Unlocker è inferiore ai 30 dollari non vale la pena di impazzire.

Password cracking
La nobile arte del password cracking è decisamente più complessa di quanto si possa intuire
dai film di Hollywood riguardanti gli hacker, dove il belloccio di turno riesce a indovinare la
password giusta in 30 secondi con la pistola alla tempia e altre distrazioni attorno, oppure
indovinando il codice una cifra alla volta (con quale criterio non si capirà mai). Il problema del
password cracking è riuscire a farlo in tempi che siano, quantomeno, umani. Per riuscirci è
necessario evitare di doversi scontrare con la parte di forza bruta (ovvero il tentare tutte le
password possibili).

Wordlist
Il primo passo per ridurre i tempi è possedere una wordlist molto completa. È statisticamente
provato che la maggior parte delle password è basata su parole di senso compiuto. Possedere un
dizionario completo permette quindi di indovinare la maggior parte delle password in un tempo
estremamente ridotto.
È implicito che una wordlist non deve limitarsi ai soli termini italiani e inglesi ma deve
contenere anche parole differenti come nomi, cognomi, modelli di automobili, termini calcistici
e molto altro. Esistono vari siti dove reperire wordlist:
http://wordlist.sourceforge.net

http://www.openwall.com/wordlists

Si resista alla tentazione di unire tutte le wordlist trovate in un unico dizionario. Si finirebbe
per rallentare inutilmente la ricerca. Piuttosto è bene informarsi sul soggetto che ha scelto la
password e provare le wordlist che più gli si addicono.

Password cracker
Esistono decine di password cracker disponibili via Internet. Essi si differenziano, oltre che
per l’efficienza e la velocità, anche per lo scopo per il quale sono stati scritti. Esistono
sostanzialmente due tipi di password cracker:
 password cracker di sistema, mirati al cracking di account di sistema, lavorando
direttamente sui file che contengono gli account come l’accoppiata passwd/shadow di
Unix, il SAM di Windows o le strutture di OS X;
password cracker per applicativi, mirati a effettuare il crack di password utilizzate in
specifici formati file (come .zip, .rar, .doc, .xls, .pwl e così via).

I password cracker per applicativi sono sicuramente quelli più usati in analisi forense. Si
vedranno di seguito, comunque, i più noti di entrambe le categorie.
È inutile dire che si cercano sempre nuovi modi per migliorare l’efficienza dei password
cracker, dato che devono gestire un numero sempre più elevato di possibili chiavi e
combinazioni. Ormai è assodato da anni l’uso delle GPU nel password cracking. ElcomSoft
(http://www.elcomsoft.com) prima tra tutte ha creato un sistema per sfruttare sia le GPU di nVIDIA
(grazie alle CUDA library) sia quelle di AMD (usando le librerie OpenCL funzionano oltre che
con le discreet graphic card anche con le APU) con risultati che, in molti casi, sono superiori di
50 volte a quelli ottenibili tramite la sola CPU. Per fare un mero esempio, il cracking di una
password in formato NTLM ha prodotto, su un FX8500, circa 40.000.000 di password al
secondo. La stessa macchina, dotata di una normalissima scheda basata su un chip AMD Radeon
7770 overcloccato, ha raggiunto le 880.000.000 password al secondo. Le ultime versioni del
software di ElcomSoft sono in grado di funzionare anche in maniera distribuita su centinaia di
client diversi. Il software può essere accelerato anche con la serie di Desktop Supercomputer
Tesla di nVIDIA.
La concorrenza non è stata a guardare. Sia LastBit (http://www.lastbit.com) sia Passware
(http://www.lostpassword.com/) dispongono ora di suite ottimizzate sia con l’uso distribuito su più
nodi sia usando le schede grafiche.
Il software di ElcomSoft, almeno la suite completa, non è un programma economico ma si
dimostra validissimo specie se non si ha molto tempo per riuscire a trovare quanto si sta
cercando.
In alternativa sono disponibili le seguenti alternative.

Password cracker di sistema

John the Ripper (http://www.openwall.org): è uno dei più famosi password cracker disponibili.
Out-of-the-box è in grado di lavorare sui principali formati password usati nei sistemi
Unix, Windows (sono supportate tutte le versioni fino alla 7, 8 solamente per gli account
locali). Esistono decine di patch che ne estendono le capacità permettendogli di supportare
i sistemi OpenVMS, le password del web server Apache e gli shadow file di OS X (non
per tutte le versioni di OS X). Per i fortunati possessori di un cluster esiste una versione in
grado di lavorare sulle librerie MPI per effettuare il guessing delle password in maniera
distribuita.
Ophcrack (http://ophcrack.sourceforge.net): questo password cracker si basa sul meccanismo
delle rainbow table, ossia tavole precalcolate, solitamente contenute in un database, di
password crittografate. In questo modo il tempo per trovare una password si riduce
notevolmente, dato che è sufficiente effettuare una query SQL sulle password presenti
piuttosto che dover calcolare tutte le possibili configurazioni. Si può quindi preallocare il
tempo di calcolo quando le macchine sono libere oppure acquistare una delle rainbow
table già generate (ne esistono fino a 120 GB di dimensione, in grado di trovare qualsiasi
password in formato NTLM).
Medusa (http://www.foofus.net/jmk/medusa/medusa.html): è un login cracker in grado di agire non
solo su file locali, come John the Ripper, ma anche su servizi remoti. Supporta un notevole
numero di servizi, compresi server di posta, database server, ssh, Gui VMware e molti
altri.

Password cracker per applicativi

Passware Kit (http://www.lostpassword.com): come già accennato, Passware dispone di una
suite completa che, nella versione Forensics (che è realmente una versione ottimizzata per
l’uso in ambito Digital Forensics), può lavorare su più di 200 tipi di file e codifiche. In
particolare si vuole porre l’accento sul fatto che è incluso anche un modulo che permette la
ricerca in memoria delle chiavi crittografiche per i più comuni sistemi di Full Disk
Encryption. Tale modulo è integrato anche con il Firewire Memory Imager che è in grado
di effettuare un dump della memoria attraverso la porta Firewire eventualmente presente
sul computer. Un prodotto che costa una frazione della suite di ElcomSoft ma che
rivaleggia ad armi pari con quest’ultima. Decisamente un best buy per un laboratorio.
Last Bit Software Megapack (http://lastbit.com): nel corso del tempo ha decisamente perso
smalto. Rimane una buona suite di password cracking ma è ormai assolutamente indietro
rispetto ai rivali. Se una volta aveva il vantaggio di un rapporto prezzo/prestazioni
veramente elevato, ora anche in questo campo ha perso punti. Per disporre della versione
accelerata si deve avere una licenza di OctoPass, che, come minimo, costa 299 euro per la
versione fino a 10 agenti. Può essere usato come un prodotto alternativo e a minor costo
rispetto a ElcomSoft e Passware, ma conviene investire qualche soldo in più e passare al
prodotto di Passware.

Debugger, decompiler e disassembler

 Talvolta si rende necessario guardare attentamente al funzionamento del software per
individuare variazioni o per esaminare il comportamento dello stesso. Ciò può essere utilissimo
in caso di sistemi violati o nell’analisi di software virale o di worm. Allo scopo si citano i
seguenti programmi.
IDA Pro ( https://www.hex-rays.com): è uno dei migliori software al mondo nel suo settore. IDA
Pro è un dissassembler e un debugger con sistemi di gestione e visualizzazione che
permettono di investigare all’interno di file binari, il cui funzionamento è ignoto, con
relativa semplicità. È il tool perfetto per chiunque si interessi di virus, malware e spyware.
Funziona su piattaforma Windows e Linux e permette di gestire una vastissima gamma di
architetture hardware e software. Purtroppo è uno dei programmi più piratati del pianeta e
questo ha portato a far sì che la sua distribuzione abbia avuto una storia piuttosto
travagliata.
OllyDbg (http://ollydbg.de): non è un debugger a Ring 0 ma possiede una buona serie di
funzioni utili per effettuare il debugging e per disassemblare il codice sotto Windows. Nel
2012 è stato aggiornato ed è giunto alla versione 2.0 che introduce molte nuove feature. Da
allora non si hanno però ulteriori sviluppi. È shareware e ha un costo assolutamente alla
portata di chiunque.
Java Decompiler (http://java.decompiler.free.fr/): dopo l’abbandono di JAD, Java
Decompiler è considerato il decompiler e disassembler standard per lavorare su Java.
Funziona sia come programma a sé sia come plug-in per l’IDE open source Eclipse.
Spices.NET Decompiler (http://www.9rays.net): è un decompilatore commerciale (per
piattaforma Windows). Decompila binari di tipo MSIL generando codice sorgente in
diversi linguaggi di alto livello (C#, VB.NET, Delphi.Net, J# e C++).

Network dissector
Un network dissector risulta necessario molto più spesso di quanto si potrebbe pensare.
Analizzare il comportamento di un worm, tracciare l’attività originata da un certo computer,
estrarre una conversazione VoIP da un flusso dati, verificare il comportamento di un nuovo
protocollo sono solo alcuni dei possibili esempi di un suo utilizzo.
Il mondo open source ci ha regalato uno dei più interessanti software attualmente esistenti,
ovvero Wireshark (http://www.wireshark.org), che ha una serie di feature che lo rendono un prodotto
unico nel suo genere.
Utilizza libpcap come formato file per i dump di rete. Ciò lo rende interoperabile con una
notevole serie di altri prodotti e comandi Unix, come tcpdump o snort. Attualmente libpcap è
da considerarsi la lingua franca dei formati file per software di analisi e intercettazione
dati su rete.
Ampio supporto per formati file proprietari. Oltre a libpcap, Wireshark supporta molti
formati file appartenenti a software o hardware proprietari, il che comporta la possibilità
di acquisire fonti di prova da una notevole serie di prodotti differenti.
– Sun snoop e atmsnoop
– Shomiti/Finisar Surveyor
– Novell LANalyzer
– Microsoft Network Monitor
– AIX iptrace
– Cinco Networks NetXray
– Network Associates Windows-based Sniffer e Sniffer Pro
– Network General/Network Associates DOS-based Sniffer
– AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek/EtherHelp/PacketGrabber
– RADCOM WAN/LAN Analyzer
– Network Instruments Observer version 9
– Lucent/Ascend router debug
– HP-UX nettl
– router ISDN Toshiba
– ISDN4BSD i4btrace utility
– EyeSDN USB S0>
– IPLog, format prodotto da Cisco Secure Intrusion Detection System
– pppd logs (pppdump)
– VMS TCPIPtrace/TCPtrace/UCX$TRACE
– DBS Etherwatch VMS
– Visual Network Visual UpTime
– CoSine L2
– Accellent 5 Views LAN
– Endace Measurement System ERF
– Linux Bluez Bluetooth stack hcidump -w
– Catapult DCT2000
Permette di esportare i dati in un ampio numero di formati. È quindi possibile utilizzare
Wireshark non solo per l’analisi ma anche per fornire alle controparti i dati nel formato più
consono:
– libpcap, tcpdump e vari altri strumenti che utilizzano il formato di cattura tcpdump
(*.pcap, *.cap, *.dmp);
– Accellent 5Views (*.5vw);
– HP-UX’s nettl (*.TRC0, *.TRC1);
 – Microsoft Network Monitor - NetMon (*.cap);
– Network Associates Sniffer - DOS (*.cap, *.enc, *.trc, *fdc, *.syc);
– Network Associates Sniffer - Windows (*.cap);
– Network Instruments Observer version 9 (*.bfr);
– Novell LANalyzer (*.tr1);
– Sun snoop (*.snoop, *.cap);
– Visual Networks Visual UpTime traffic (*.*).
Ampia libreria di protocolli. Wireshark può effettuare il dissecting di un numero
impressionante di protocolli, posti ai vari livelli dello standard ISO/OSI. L’elenco
completo è disponibile alla pagina http://www.wireshark.org/docs/dfref e include oltre 1000
protocolli diversi.
Potente sistema di filtri. Il traffico può essere filtrato con un sistema molto potente di filtri
basati su espressioni booleane. Praticamente ogni singolo campo di ognuno dei protocolli
gestiti può essere utilizzato come parametro per la scrittura di un filtro. Un sistema di
colorazione può essere associato ai filtri per poter distinguere correttamente il traffico ed
evidenziare ciò che maggiormente interessa.
Sistema di cattura. Wireshark può catturare il traffico in completa autonomia senza dover
utilizzare programmi terzi. La suite comprende inoltre una versione testuale che può essere
adoperata laddove non è disponibile un’interfaccia grafica, oppure in una sonda per
catturare del traffico effettuando eventualmente un filtraggio dei pacchetti già in fase di
acquisizione.
Multipiattaforma. Wireshark può funzionare sulla maggior parte degli Unix, su Microsoft
Windows (tramite le librerie WinPcap, http://www.winpcap.org) e su OS X.

Un altro software particolarmente interessante è Xplico (http://www.xplico.org/). Non è un

dissector ma un tool di Network Forensics. Giunto alla versione 1.0.1, non è uno dei programmi
con lo sviluppo più rapido del mondo ma sta procedendo bene. La GUI è decisamente ben
progettata e di facile utilizzo; l’unico problema è che il numero di protocolli supportati non è
elevato (e alcuni dei più utili sono tuttora in fase di sviluppo). Xplico estrae mail, file,
immagini, conversazioni e altro da un dump raw di rete, permettendo quindi l’analisi di quanto
passato senza che occorra essere degli esperti di TCP/IP.

Programmi di conversione
Un dato non sempre può venire esaminato nella sua forma originaria. In molti casi, il ruolo<