Il primo giorno è stato interamente dedicato alla presentazione di software ed hardware di supporto alla computer forensic, con particolare attenzione alla mobile forensic (quella dei cellulari, per capirci). Tutti molto disponibili i rappresentanti delle ditte intervenute. Nonostante qualche intoppo, dovuto soltanto alla densità elevatissima di cose interessanti, ho trovato estremamente utile la panoramica che ne ho ricavato, sia dal punto di vista di cosa offre il mercato, sia per quello che nelle brochures non c’è scritto.

Il giorno successivo è stato dedicato invece alla gara denominata “CyberCop”, in parallelo ai seminari, che purtroppo non ho potuto seguire, dato che ho partecipato con la mia squadra, composta quasi all’ultimo momento, e peraltro ci siamo conosciuti sul posto, visto che una metà non conosceva l’altra metà. Ma l’affiatamento è stato immediato, e ci siamo battuti con tenacia fino alla fine, anche se ha vinto la squadra con più esperienza, come era anche atteso che fosse.
L’intreccio informatico-giuridico era degno dei più intricati casi mai scritti dai migliori giallisti, con un criminale virtuale che dimostrava una grande competenza sia in campo informatico che nelle tecniche e metodi di indagine delle Forze dell’Ordine.
Alla fine siamo riusciti a mettergli le mani addosso, in senso virtuale, ma il tempo per risolvere l’enigma è scaduto senza che riuscissimo a dimostrare, con prove in grado di reggere un processo, che il criminale fosse proprio quello.

L’ultimo giorno si è svolta la simulazione del dibattimento in aula, con tanto di Pubblico Ministero, Difensore e Giudice, e non si sono fatti mancare nulla: prove non ammesse, eccezioni del difensore, imbarazzo del Pubblico Ministero e colpo di scena finale. Insomma, una sceneggiatura perfetta per una puntata di Law&Order.

Se da un lato mi viene da dire “Pazienza, andrà meglio la prossima volta”, dall’altra devo ammettere di aver “rosicato” un poco, lo confesso. Ero convinto di aver inquadrato perfettamente il modus operandi del criminale virtuale, ma i fatti mi hanno dato torto, e sulle prime ci sono rimasto parecchio male.
Poi, dopo qualche giorno, a mente fredda, mentre scrivevo un qualcosa legato alla sfida (e che per ora non posso dire), ho capito parecchie cose su come sono andati i fatti.

Riassumendo brevemente, a parte quello che mi ripeto spesso, ossia che c’è veramente tanto da imparare, forse troppo, il problema è stato proprio l’essere convinto di aver inquadrato la situazione. Due parole: presunzione e pregiudizio.

Il presumere di aver compreso tutto di una situazione, quando se ne ha un punto di vista ristretto e limitato, porta a sottovalutare la realtà e sopravvalutare l’immagine che ce ne siamo fatta. arrivando a scartare elementi che ad un osservatore esterno e non coinvolto appaiono palesi. Per fare un esempio: in una certa fase vi era un file ZIP protetto da password. Ero talmente convinto che il criminale virtuale fosse troppo furbo per usare una password debole, che non ci ho neanche provato a fare un attacco a dizionario. Invece la password era banale, di quattro lettere e senso compiuto, in un attacco a dizionario l’avrei trovata in pochi secondi.

Il pregiudizio di avere di fronte qualcuno “che ci capisce”, ma non così tanto, visto che usa software comuni e strategie note, mi ha fatto di nuovo sottovalutare la situazione. Ho subito associato al criminale virtuale la figura di quello che conosce tutti i programmini del mondo, ma in fondo non sa come funzionano e soprattutto perché. Un esempio: il criminale virtuale aveva un campionario estesissimo di software per crittografia e steganografia, e c’era una immagine che risultava differente da una copia presente in Rete. Le ho provate tutte: analisi del contrasto, mappatura, confronto per sottrazione, istogrammi RGB, ma ho mancato la prova più ovvia: l’immagine conteneva dati nascosti da steganografia, appunto.

Errori banali, dettati appunto da presunzione e pregiudizio. Le mie convinzioni personali mi hanno impedito di accettare ed accertare i fatti come erano. Era un gioco, ma se fosse stata una indagine reale il danno sarebbe stato tutt’altro che trascurabile.

Sul treno del ritorno, con il mio amico Lorenzo, stavamo ricapitolando gli errori e le sviste commesse, ripetendoci ad ogni passo: “Manco le basi!“.

Oltre questo, la lezione ha avuto per me un valore incalcolabile, a parte la constatazione di avere ancora molto da imparare: si può essere buoni tecnici, ma fare l’investigatore è tutto un altro paio di maniche.

Per il resto, ho ancora parecchio materiale da elaborare, contatti da perfezionare e qualche nuovo amico, che male non fa.

Conto di partecipare anche l’anno prossimo, ma così faranno le altre squadre, e la battaglia sarà dura. Ma il divertimento sarà maggiore, ne sono certo.

Le bandierine

Il pen drive contiene due filesystem nascosti, oltre a quello “visibile”. Entrambi sono di tipo FAT, creati con l’ausilio dei loop device in Linux. Il primo, in FAT32 con etichetta di volume nascosto1, ha questi dati di dimensione ed utilizzo:

• Totale: 1.009.729.536 byte
• Usati: 11.706.368 byte
• Liberi: 998.023.168 byte

Per poterlo montare senza lamentele da parte del sistema operativo, basta creare un loop device con questo comando:

# losetup -o 1009935360 /dev/loop1 pen-drive.dd

e di seguito usare il comando mount sul device appena assegnato, ossia loop1, in questo modo:

# mount -t vfat /dev/loop1 /media/loop1 -o ro,noatime

Le opzioni usate sono per essere proprio sicuri che niente venga toccato. I file sono quattro, tutte immagini. Lavorando con i comandi ls e stat si ottengono tutte le informazioni richieste:

# ls -l
-rwxr-xr-x 1 root root 3256972 21 ott 13:26 img_0154.jpg
-rwxr-xr-x 1 root root 2882079 21 ott 13:26 img_0155.jpg
-rwxr-xr-x 1 root root 3447899 21 ott 13:26 img_0156.jpg
-rwxr-xr-x 1 root root 2107408 21 ott 13:26 img_0477.jpg
# stat *
  File: `img_0154.jpg'
  Size: 3256972   	Blocks: 6368       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 6           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:34.000000000 +0200
Change: 2008-10-21 13:26:56.000000000 +0200
  File: `img_0155.jpg'
  Size: 2882079   	Blocks: 5632       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 7           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:38.000000000 +0200
Change: 2008-10-21 13:26:56.000000000 +0200
  File: `img_0156.jpg'
  Size: 3447899   	Blocks: 6736       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 8           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:40.000000000 +0200
Change: 2008-10-21 13:26:57.000000000 +0200
  File: `img_0477.jpg'
  Size: 2107408   	Blocks: 4120       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 9           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:46.000000000 +0200
Change: 2008-10-21 13:26:57.000000000 +0200

Il conteggio delle bandierine è presto fatto:

• 4 per il filesystem (tipo, dimensione, libero/occupato)
• 4 per i file trovati
• Per ogni file sono 5 bandierine: nome, dimensione ed i tre orari, accesso, modifica, creazione.

In totale fanno 28 punti per questo filesystem.

Passiamo ora a quello che si è rivelato più difficile da trovare. E’ “contenuto” all’interno di quello normalmente visibile, è in FAT16 ed ha etichetta nascosto2. Questi i suoi dati dimensionali:

• Totale: 409.378.816 byte
• Usati: 516.096 byte
• Liberi: 408.862.720 byte

Per poterlo montare senza lamentele, prima si crea il loop device così:

# losetup -o 512000000 /dev/loop2 pen-drive.dd

poi si procede al mount:

# mount -t vfat /dev/loop2 /media/loop2 -o ro,noatime

Et-voilà. Ora passiamo ai file, solo due, entrambi PDF, datasheet di componenti elettronici: una memoria RAM ed un controller per porte seriali.
Come sopra, lavorando di ls e stat abbiamo tutto quello che ci serve:

# ls -l
-rwxr-xr-x 1 root root 364643 21 ott 13:32 16c450.pdf
-rwxr-xr-x 1 root root 146960 21 ott 13:33 62256.pdf
# stat *
  File: `16c450.pdf'
  Size: 364643    	Blocks: 720        IO Block: 8192   regular file
Device: 702h/1794d	Inode: 12          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:32:46.000000000 +0200
Change: 2008-10-21 13:32:46.000000000 +0200
  File: `62256.pdf'
  Size: 146960    	Blocks: 288        IO Block: 8192   regular file
Device: 702h/1794d	Inode: 13          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:33:18.000000000 +0200
Change: 2008-10-21 13:33:18.000000000 +0200

Il conteggio delle bandierine in questo caso è di 16, 4 per il filesystem, 2 i file, 5 per file per i metadati.

In totale è possibile totalizzare 44 punti. Andando di solo carving al massimo si ottengono 12 punti (6 per i file e per ogni file l’unico metadato disponibile è la dimensione).

La classifica

A pieni punti abbiamo:

• Denis Frati, veloce, accurato e preciso (e su di lui non avevo alcun dubbio, bravo Denis!)
• Daniele Murrau, sintetico e preciso
• Davide Paltrinieri, una giovane promessa che ha dimostrato tenacia e intuito, a cui va un plauso aggiuntivo per il fatto di essere da poco utente Linux, e quindi con la difficoltà ulteriore di trovarsi a “domare” un sistema operativo poco conosciuto (…non oso pensare a cosa potrà fare fra qualche anno. E’ meglio tenerselo come amico, ecco)

Seguono le menzioni d’onore:

• Enrico Ardizzoni
• Stran0
• Nanni Bassetti

che pur impegnandosi hanno “mancato” il secondo filesystem nascosto, quello con etichetta nascosto2. Bravi comunque.
Se lo desiderate potete pubblicare nei vostri siti/blog un post con la procedura seguita per trovare le vostre bandierine, e se me lo notificate aggiungo il link alla vostra spiegazione.

La procedura per creare il pen drive

Non è molto lunga, né complicata, una volta capito l’uso dei loop device. Il pen drive conteneva una unica partizione da due gigabyte, al momento dell’acquisto. Ho provveduto a cancellarla ed a crearne una che occupasse circa la metà dello spazio disponibile, formattandola in FAT32.

Ho poi creato un loop device che puntasse esattamente al primo settore dopo la partizione visibile, usando il comando visto sopra. In questo modo ho potuto lavorare su nascosto1 senza creare partizioni, formattandolo in FAT32 e copiandoci sopra i file delle quattro immagini.

A questo punto ho messo mano al terzo filesystem, il secondo nascosto. Ho creato un loop device che partiva dal byte 512.000.000 del pen drive, in modo da avere un numero facile da ricordare (come hanno correttamente ipotizzato Denis e Davide). Il problema è che il loop device “termina” alla fine fisica del pen drive, ossia dopo 1,5 gigabyte, quindi se si va a formattare il loop device si corre il rischio di cancellare il filesystem nascosto creato in precedenza. Viene in aiuto il comando mkdosfs di Linux che consente di specificare di quanti blocchi da 1 kilobyte è composto il filesystem. Ho assegnato 400 megabyte per questo secondo filesystem, in modo da poter preservare l’altro nascosto. Qui sotto una figura che riassume la geometria dei tre filesystem.

La struttura dei filesystem nel pen drive

Ecco tutto. Quindi niente di esoterico, né da guru, solo un po’ di fantasia e di conoscenze dei vari filesystem.

Considerazioni finali

Finalità del game era appunto di offrire un momento di svago utile, con lo scopo neanche tanto nascosto di fornire un minimo di spunti di approfondimento. Loop device, filesystem, partizioni, geometrie, tutti concetti abbastanza basilari, ma troppo spesso dimenticati, nascosti da troppe “finestre e pulsanti”.

Altro intento era di mostrare che il solo carving non risolve tutto. Foremost in pochi secondi estrae tutti i file dall’immagine del pen drive, ma non offre informazioni su tempi e modi in cui i file sono giunti sul supporto. In un caso reale probabilmente la ricostruzione della timeline può essere fondamentale. Come fondamentale può essere la dimostrazione dell’intento, ossia che la struttura dei filesystem contenuti sul supporto è intenzionalmente mirata a nasconderne parte del contenuto.

La sofisticazione nei metodi usati è stata volutamente tenuta ad un livello basso, senza stratificare altri tipi di data hiding. Nella vita reale un tale metodo non resisterebbe a lungo all’analisi di una persona competente. Inoltre vi sono forti controindicazioni per la integrità dei dati nel tempo: un errore di manovra e dati scritti nella partizione visibile possono andare a sovrascrivere porzioni vitali dei dati o della struttura del filesystem della partizione da 400 Mbyte, quella col nome nascosto2.

Ecco anche il motivo per scegliere FAT come filesystem: le strutture di lavoro sono tutte concentrate all’inizio della partizione, per cui si può essere ragionevolmente certi che da un certo punto in poi niente viene scritto o letto durante il normale accesso al filesystem, rendendo possibile “includere” un altro filesystem al suo interno. Questo ad esempio con ext2/3 non è possibile, perché le strutture di supporto e di lavoro del filesystem sono sparse per tutta la partizione, per ragioni di efficienza e prestazioni. Quindi includere un altro filesystem in esso, completamente invisibile, è quasi impossibile.

E’ tutto. Ancora grazie a tutti i partecipanti. Al prossimo gioco.

Antefatto

Un normalissimo pen drive, acquistato in un centro commerciale per pochi euro. Dentro vi ho nascosto dei dati sotto forma di normali file (immagini e testi).
Usando foremost o photorec (due applicazioni tipicamente di uso forense) potreste trovare immediatamente i dati ed i file, ma… Dove sarebbe il gusto del gioco?

Le bandierine da conquistare

• Una bandierina per ogni filesystem che riuscirete a montare senza errori (ossia senza che il sistema operativo lamenti errori), a parte quello non nascosto.
• Una bandierina per ogni informazione che riuscirete ad estrarre dal singolo filesystem, in particolare: etichetta del volume, tipo di filesystem, dimensione totale, spazio occupato/libero.
• Una bandierina per ogni file che riuscirete a trovare.
• Una bandierina per ogni informazione trovata sul singolo file nascosto, ossia: nome originale, date di modifica/accesso/creazione.

Il “reperto”

L’immagine dell’intero pen drive, ottenuta con “dd”, è in un file zip da 26 megabyte, attenzione che una volta esploso occuperà 2 gigabyte, quindi procurate di avere spazio disco a sufficienza.
Il reperto è prelevabile qui:
Pen drive data hiding game (novembre 2008)

Le regole

• Prima regola: NON SI VINCE NIENTE. Ma proprio niente, neanche un misero link nel blogroll.
• Seconda regola: le risposte solo per e-mail, usando uno dei miei contatti. Qualsiasi altra forma di comunicazione semplicemente verrà ignorata.
• Terza regola: messaggi/post/annunci in mailing list tipo “è una scemenza” “è facile” “non mi ci spreco nemmeno” non fanno comunque vincere niente, ma si fa una figura peggiore. Se non interessa partecipare, non si partecipa e punto, nessuno ne sentirà la mancanza.
• Quarta regola: usate quello che vi pare, le procedure che volete, gli strumenti che preferite. Se volete potete citarli nel messaggio-soluzione, ma non è importante.
• La regola della vittoria: vince chi trova più bandierine, documentandole. Dato che decido io cosa è giusto e cosa non lo è, dovete essere convincenti.

Livello di competenza richiesto

Non è un game particolarmente difficile, anche se occorre avere un po’ di esperienza. Il tipo di data hiding utilizzato è piuttosto semplice, anzi, quasi banale. Però, dato che stiamo parlando di didattica, è una buona palestra.

La soluzione

Verrà pubblicata più avanti, anche se nessuno parteciperà.

E’ tutto. Buona esplorazione.

• Non si vince niente
• Non dovete linkarmi
• Vince chi mette più dettagli: dove come perché quando cosa
• Perde chi non partecipa

Cos’è questo:

Risposte solo via mail.

Sarò meno presente nei prossimi giorni. Vado in modalità “risparmio energetico”, sperando di ricaricarmi un po’. Quanfo ritorno a piena potenza avrete risposte risposte e spiegazioni.

Volete un aiuto? Per intanto la categoria assegnata dovrebbe suggerire qualcosa.

Per il resto, you’re on your own (sempre gradito Alan Parsons).

Il test viene con la soluzione, quindi non si vince nulla, è solo un utile esercizio. La soluzione, che ho trovato per primo (fatemi vantare un po’ ogni tanto…) mi ha fruttato un piccolo dispositivo per l’analisi delle sim card offerto da IISFA.

Questa la storia, al solito totalmente inventata:
Il file da analizzare è questo, l’unica digital evidence disponibile per le indagini: è una e-mail intercettata, si teme possa nascondere un messaggio in codice relativo ad un imminente attacco terroristico. I sospettati usano un metodo non convenzionale per nascondere i dati. Il file cifrato con 256 AES e non c’e’ il tempo di forzare la password con un attacco brute force!

Lo scopo è rilevare il messaggio nel più breve tempo possibile, ed ovviamente la procedura deve essere documentata e ripetibile.

Per la soluzione e le considerazioni basta continuare a leggere il resto.

Il messaggio è:

Secret Mission:

Make a kamikaze attack on 24 Sept at 11.00 in the same instant in

1) Churc S.Phelipe
2) Vatican Bank Office in S.Peter
3) Vatican Museum
4) Churc S.Lazarus

The explosive is ready in Mullah Saddam in Milan MIC.

Osama Bin Laden

Procedura per arrivare al messaggio:

1. Nel file ZIP c’è un messaggio e-mail salvato nel formato di Outlook.
2. il messaggio ha due allegati: una immagine ed un file compresso con WinZip versione >=9 che possiede la cifratura AES256, incompatibile con tutti gli altri compressori (pkunzip e unzip di Linux terminano con un errore: unsupported compression method 99).
3. i 4 numeri nel messaggio sono da interpretare come coppie di coordinate nella foto. A quelle coordinate c’è nascosto un messaggio fra le parole “by” e “Night” che è proprio la password necessaria ad aprire il file compresso con WinZip:

   babbati1550356tucayai

4. Il file compresso e cifrato con WinZip è un file di testo semplice con il messaggio riportato sopra.

Qui potete vedere un ingrandimento della zona dell’immagine dopo l’applicazione del filtro “sharpen” con indice 80 in Gimp.

Considerazioni

La lunghezza della password (21 caratteri) dimostra a posteriori che qualsiasi tentativo di attacco brute force è destinato a fallire miseramente, ed a maggior ragione in questa situazione in cui una decifrazione ottenuta in data successiva a quella degli ipotetici attentati è del tutto inutile.

L’applicazione dei classici tool tipo stegdetect all’immagine non fornisce risultati utilizzabili, o non li fornisce del tutto, a dimostrazione del fatto che i tool sono utili quando il problema che ci si trova ad affrontare è stato già risolto almeno una volta. Qualcosa di simile al problema degli antivirus, che riconoscono solo i virus noti.

Nell’immaginario mediatico il bravo investigatore forense apre il suo notebook (ultimo modello con uno schermo da 30″) e esegue uno dopo l’altro i tool furbissimi e velocissimi sul file da lavorare, per arrivare in pochi secondi al risultato. Scene come questa abbondano in telefilm noti e meno noti appartenenti al genere. E’ simile alla tipica rappresentazione dell’hacker (da strapazzo, lo aggiungo io) che per essere assunto viene messo davanti al portale di accesso di una qualche agenzia governativa di sicurezza nazionale e con la pistola alla tempia deve irrompere nel sito in un minuto o finisce impallinato (in una pellicola non troppo recente c’era anche una signora che provvedeva ad aggiungere una ulteriore “distrazione”…).

Non è per niente così. Se si procede alla cieca si perde tantissimo tempo, e si imboccano strade senza uscita. E quando ci si trovi davanti ad una situazione nuova, qualsiasi tool si rivelerà di poco aiuto, al più potrà servire per escludere soluzioni note. E non è solo questione di trovare il tool giusto, altrimenti sarebbe sufficiente acquistare qualsiasi cosa sia disponibile sul mercato per diventare infallibili: sarebbe come pretendere di essere un grande programmatore solo per avere acquistato un supercomputer e tutti gli strumenti di sviluppo disponibili.

Per ultimo, non meno importante del resto, si deve riflettere su questo: il prodotto delle indagini finisce spesso, se non sempre, in una aula di tribunale, e qui le regole sono ben diverse. Non vince il più bravo, o il più dotato, ma il più tenace, quello che meglio conosce i meccanismi della giustizia e della legge.

Arrivare in aula con un risultato, senza la procedura ripetibile per ottenerlo, significa far escludere del tutto la prova, vanificando molto spesso non solo il proprio lavoro.

Un aspetto del tutto ignorato è il fatto che occorre saper scrivere in italiano corretto, con uno stile chiaro e conciso. Una splendida analisi che porta alla scoperta di prove importantissime, corredata da una relazione scritta in modo incomprensibile o passibile di più interpretazioni diventa un’arma a doppio taglio, o un boomerang. Niente spazio a speculazioni e tecnicismi, niente sfoggio di gergo incomprensibile che fa tanto hacker, ma diventa controproducente in un ambiente non informatico.

Per ora chiudo qui. I commenti sono sempre aperti alle vostre considerazioni.

Per prima cosa la soluzione: lo schema elettronico c’era, nascosto nel file dict nella directory src/fcrackzip-0.3. Era in formato PDF, codificato in BASE64, il sistema utilizzato per trasmettere allegati nella e-mail.

Di seguito passo a presentare il solutore: il bravissimo Denis Frati, che ha risolto il rompicapo in meno di mezza giornata. Menzione d’onore a Nanni Bassetti, che ci è arrivato poco dopo.

Lascio la parola a loro, nelle rispettive relazioni sull’attività svolta per trovare il file occultato:

• Il file nascosto era questo (PDF 17k)
• La relazione di Denis Frati (PDF 940k)
• La relazione di Nanni Bassetti (PDF 140k)

Grazie a tutti per aver partecipato, ed alla prossima sfida.

E’ strettamente legata alla information security, ma il punto di vista è quasi totalmente differente. Spesso per ottenere prove valide e decisive si deve sfruttare una qualche debolezza nelle difese di un sistema informatico. O si devono adottare strumenti più da criminale informatico che da esperto di sicurezza. Non è raro il caso in cui si ricorra a programmi per spezzare cifrature o rivelare password per accedere al contenuto di un supporto.

Per chi vuole avere un “assaggio” di come funzioni il tutto, ho creato una simulazione di caso reale. Se volete cimentarvi e mettere alla prova le vostre abilità di Sherlock digitali, continuate a leggere

La storia (completamente inventata, ed ovviamente ogni riferimento a situazioni e casi reali è una coincidenza e nulla più), è questa:

Una società di ricerca finanziata dal governo ha messo a punto un nuovo sistema di cifratura che consentirebbe un vantaggio consistente alla nazione, permettendo comunicazioni virtualmente inviolabili. Ovviamente se anche altre nazioni ottengono lo stesso sistema si perde il vantaggio, per cui il livello di segretezza del progetto è massimo.
C’è un problema: il responsabile della sicurezza informatica della società si è accorto di un accesso insolito ad alcuni file del progetto, in particolare allo schema elettronico del dispositivo.

Indagando con discrezione ha individuato il responsabile di questi accessi, anche se ovviamente le prove sono molto labili e non utilizzabili in giudizio.

Con l’aiuto delle forze dell’ordine è riuscito a prendere con le mani nel sacco il presunto colpevole, ma l’unica irregolarità rilevata è un pen drive USB trovato indosso al sospetto. Ad un primo esame nel pen drive non sembrano essere presenti file sospetti, ed il problema è che in questa situazione potrà contestare al sospetto soltanto una violazione delle politiche di sicurezza aziendali, che vietano di introdurre qualsiasi dispositivo o supporto di memorizzazione nell’azienda. In questo caso il massimo che può capitare è un richiamo ufficiale ed una multa salata, ma niente di più.
Se invece si riuscisse a trovare prova che dentro il pen drive vi sono file appartenenti al progetto del sistema crittografico la cosa assumerebbe ben altri contorni. In particolare il file che si sospetta sia presente nel pen drive dovrebbe essere uno schema elettronico.

Il vostro compito è analizzare l’immagine del pen drive e verificare se all’interno esista un file con uno schema elettronico, nascosto o meno.

Queste le regole d’ingaggio:

1. Il pen drive è formattato con filesystem FAT
2. Non è stata usata nessuna crittografia, non ci sono password da scoprire
3. Non sono stati usati programmi sviluppati appositamente (posso assicurare che sarebbe stato impossibile recuperare alcunché dal pen drive, in questo caso)
4. Il file, se c’è, è in un formato assolutamente comune, non è stata utilizzata una applicazione dedicata agli schemi elettronici, altrimenti sarebbe stato impossibile aprire il file senza quella applicazione

Regole per aggiudicarsi la vittoria:

• verificare se vi è effettivamente uno schema elettronico nascosto nel pen-drive
• dove è nascosto
• in che formato file è memorizzato
• la procedura ripetibile per estrarlo dal pen drive, sempre ammettendo che il file ci sia
• la soluzione dovrà essermi inviata direttamente per posta elettronica al mio indirizzo, e farà fede la data ed ora riportata dal mio server di posta. Non sono accettati altri mezzi di invio della soluzione. I commenti a questo articolo sono chiusi per questo motivo.

Il premio: Ovviamente la pubblicazione su questo sito della soluzione con nome e cognome del vincitore e se il vincitore possiede un sito web, un link al suo sito dal blogroll (NB: per ovvi motivi saranno esclusi siti che possiedano a mio insindacabile giudizio contenuti poco appropriati o contrari all’etica, ad esempio, siti a contenuto sessuale esplicito, siti contenenti software pirata o palesemente illegale, siti di lamer e “acari” vari, splog e simili…).

Se decidete di partecipare implicitamente accettate tutte le regole qui descritte.

A questo punto non mi rimane che augurarvi buona caccia.
L’immagine del pen drive, ottenuta con il comando dd è qui (dimensione 2,6M).

Nel settembre 2004 ho partecipato ad una delle loro sfide, dette Scan of the Month, e mi sono classificato fra i primi dieci.

Il testo con il quale ho partecipato è qui.

English version.