Capitandomi spesso si tenere conferenze e workshop mi trovo sempre il problema di comandare il mio PC per far avenzare le slide della mia presentazione. Ogni volta, per andare avanti o indietro, mi devo avvicinare al PC e premere il tasto del mouse... che bello se potessi trovare un sistema che mi evitasse questa noia!

Manco a farlo apposta ecco che il Wiimote (il joystick della console Wii) e un programmino di nome wminput mi risolvono il problema in un battibaleno!

Molte volte capita di trovarsi la rete molto lenta e magari non abbiamo a disposizione un tool semplice ed immediato che ci rileva quale software sta occupando banda.

Bene NetHogs, ci permette di fare tutto ciò in pochi passi, innanzitutto dobbiamo installarlo. Il tool è fruibile in ambienti GNU/Linux quindi procedo con l'installazione su una distro Ubuntu 10.04 con il solito comando:

sudo apt-get install nethogs

Personalmente uso parecchio Mediawiki (il motore di Wikipedia); lo ritengo un ottimo strumento per fare molte cose: dal sito senza troppe pretese fino al portale per della documentazione on-line.

alcune volte però scrivere una pagina di mediawiki può risultare difficoltoso (sebbene una volta imparato risulta quasi automatico), ancora peggio se ci troviamo nella situazione di avere un testo molto lungo e con molte formattazioni da riportare in una pagina di Mediawiki!

Da oggi però ho scoperto un tool che può risolvere entrambi questi problemi in un battibaleno: SUN Wiki Publisher!

Svolgendo alcuni casi in cui serviva creare delle timeline per verificare l'attività del computer in esame, mi è venuta la voglia di creare una piccola GUI (Graphical User Interface), insomma un'interfaccia grafica, per i due strumenti presenti nello Sleuthkit ossia tsk_gettimes e mactime, che servono proprio a generare la timeline e salvarla in formato CSV (leggibile con un foglio elettronico).

Il programmino l'ho chiamato NBTempo, un semplice Bash script con interfaccia di dialogo fatta tramite YAD (Yet Another Dialog).

Quante volte vi sarà capitato di dover dire come modificare un file di testo ad una o più persone... se le persone sono tutte nella stessa stanza, bene, ma se non ci sono la cosa diventa un po' più complicata.

La soluzione potrebbe essere, ad esempio, quella di avere un editor di testi con una chat incorporata in modo da poter dire-e-far-vedere cosa e come modificare nel testo. A questo pensa gobby!

Gobby gira su Windows, Linux, Mac OS X e altre piattaforme UNIX-like e permette di condividere uno o più file di testo con uno o più interlocutori, inoltre, nella parte bassa dello schermo, gobby mette a disposizione dell'utente una finestra con cui chattare con gli altri partecipanti.

La caratteristica interessante del programma è che tutte le modifiche, che un partecipante fa sul lavoro collaborativo, vengono viste in tempo reale anche da tutti gli altri evidenziando il testo con dei colori scelti dai partecipanti.

Ma vediamo come.

Qualche giorno fa mi sono reso conto che in azienda sta per scadere la licenza dell'antivirus AVG, e mentre esploravo il portale con tutti i prodotti mi ritrovo un link con la dicitura AVG Rescue CD (immagine ISO da masterizzare).

La curiosità mi spinge ad effettuare il download e testarlo, in fin dei conti è gratuito e per di più sono circa 64 MB. Insomma può sempre tornare utile.

Il banco di prova è una VM (virtual machine) Windows XP Pro SP3, naturalmente sarà infestata di qualche virus...

Se si deve acquisire un hard disk in maniera forense, ossia con tutti i crismi necessari al fine di garantire che la copia sia identica all'originale, a tutti quelli che operano nel settore viene subito in mente l'uso di DD, DCFLDD o DC3DD (nel mondo Open Source GNU/Linux), con le classiche opzioni e parametri.

Gli approcci sono due:

1. Ottimistico (consideriamo il disco sano e tutti i settori sani).
2. Pessimistico (consideriamo che il disco abbia qualche settore danneggiato)

Nel caso in cui l'approccio ottimistico sia sconfessato, perchè durante l'acquisizione ci si ritrova con degli errori di lettura, allora si tenderà a porsi nell'ottica pessimistica, a volte anche ricominciando tutto d'accapo.

Esaminiamo gli scenari:

dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32K

Il suscritto comando leggerà blocchi da 32Kb dal disco /dev/sdb e scriverà sul disco destinazione /media/sdc1 (montato in scrittura) il file disco.dd, l'opzione conv=noerror,sync serve a due cose:

1. Noerror - indica a dd di non fermarsi di fronte ad eventuali errori di lettura, ignorando i blocchi illeggibili, ma questo, senza il sync, cambierebbe l'indirizzamento del disco, poichè l'immagine (disco.dd) del disco avrebbe una dimensione finale errata, inferiore a quella del disco originale.
2. Sync - Il flag sync forza dd a scrivere i blocchi della dimensione prescelta (es. BS=32K) e se non ci sono abbastanza dati per riempire il blocco, quest'ultimo sarà riempito di zeri (0s padding). Questo crea un problema, il file immagine di destinazione avrà una dimensione multipla del BS prescelto. Es. se il disco origine è di 6Kb ed il BS=4K, il file immagine avrà come dimensione 8Kb.

Inoltre, con un BS=32K e conv=noerror,sync, se dovessimo incontrare dei settori danneggiati, che però appartengono al buffer di lettura di 32Kb, il dd così configurato andrebbe a riempire ben 32Kb di zeri, sacrificando anche i settori sani che potrebbero esserci in quei 32Kb.

Se ci sono solo due di settori danneggiati 512 bytes * 2 =1024 bytes = 1Kb, significa che i rimanenti 31Kb saranno azzerati, perchè dd ha letto un blocco da 32Kb ha incontrato degli errori ed ha fatto il riempimento di zeri su tutto il blocco letto.

Quindi la soluzione sarebbe quella di impostare dd con un BS=512, che è la misura minima di un settore, così da leggere il disco, settore per settore e nel caso uno di essi fosse illeggibile, sarebbe riempito di zeri (sync), mentre il settore successivo (leggibile) sarebbe letto correttamente, preservandone il suo contenuto.

dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=512

Il problema di questa configurazione è che stressa di più gli hard disk, costringendoli a moltissime letture (sector by sector) e rende l'operazione più lenta.

Come risolvere?

Ci sono dei tools alternativi come ddrescue o dc3dd, che permettono di leggere blocchi di dimensioni maggiori di 512 bytes, ma nel momento in cui si trovano di fronte ad un errore, questi useranno il block size di dimensione minima, 512 bytes appunto e lo riempiranno di zeri.

DC3DD ha il default blocksize di 32768 bytes (32Kb), al fine di aumentarne la performance.

Il file immagine finale è calibrato sulla dimensione del disco sorgente indipendentemente dalla dimensione del blocco, così la dimensione del file immagine è esattamente la stessa, come se avessimo usato un BS=512. 

Sector Error Recovery

Quando si incontra un errore ed il block size è più grande del settore del device sorgente, e il parametro conv=sync,noerror è impostato, dc3dd cerca dalla fine all'inizio del blocco e prova a leggere ciascun settore indvidualmente, così i settori buoni saranno acquisiti e quelli cattivi saranno rimpiazzati dagli zero.

Questa caratteristica permette di acquisire le aree non danneggiate del disco a velocità maggiori, (dato che il BS=32K), senza perdere i blocchi di dati che circondano un bad sector.

Per attivare questa modalità è richiesto il direct I/O mode abilitato (iflag=direct su Linux, /dev/rdisk* su Mac OS X). 

dc3dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32k iflag=direct

oppure con ddrescue 

ddrescue -d -r3 /dev/sdb /media/sdc1/disco.dd log.txt

In sostanza il parametro iflag=direct o -d per ddrescue, serve a bypassare la Kernel Cache (pagecache)¹ e accedere direttamente al disco (direct I/O), considerando così la dimensione minima del settore.

Chi volesse usare DCFLDD con direct access non può utilizzare il parametro iflag=direct, dato che dcfldd è un fork di dd, quindi non segue lo stesso sviluppo di quest'ultimo, ma può accedere al device sorgente in direct I/O tramite il /dev/raw (per questo documentarsi sul device raw in Gnu/Linux).

E' chiaro che per uso forense si tende ad usare di più uno strumento come DC3DD dato che ha anche caratteristiche di multiple hashing automatico, verifica, ecc.. Es.:

dc3dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32k iflag=direct progress=on hash=md5,sha1 log=log.txt vf=/dev/sdb verifylog=log_verifica.txt

¹ La page cache è il luogo in cui il kernel mantiene in RAM una copia dei dati, per migliorare le prestazioni evitando l'I/O del disco, quando i dati che devono essere letti sono già in RAM. DC3DD è basato su DD, quindi iflag=direct funziona anche con DD.

Il tempo libero serve anche a sperimentare e quando si ha la passione per la computer forensics, son dolori...

Tramite Nigilant32 (presente nella parte Live di CAINE 1.5) faccio l'immagine della Ram del mio PC, mentre è in uso, e la salvo sul file RAM.IMG.

ram.img - dump della mia ram 1.3Gb

Tramite editor esadecimale, vedo che tra le tante stringhe, contenute nel file, ne prendo una a casaccio per fare il mio test, la stringa è "awatarami".

Cerco con strings e il parametro -t d (che mi genera anche l'offset in decimale) ottenendo:

strings -t d ram.img | less
33593  Skype z awatarami

Quindi segno l'offset come: 33593

Poi cerco con grep ed i parametri
-i ignora il maiuscolo/minuscolo;
-a tratta il file binario come se fosse testuale;
-b stampa il byte offset;
-o Mostra solo la parte di linea che coincide con la stringa cercata;

grep -iabo awatarami ram.img
33593:awatarami

Passo all'uso di xxd (editor esadecimale da riga di comando) e con -s lo faccio partire dall'offset trovato:

xxd -s 33593 ram.img | less
08339: 2053 6b79 7065 207a 2061 7761 7461 7261   Skype z awatara
08349: 6d69 204b 6c6f 6e69 6573 2e3c 6272 2f3e  mi Klonies.

08359: 3c61 2068 7265 663d 2273 6b79 7065 3a3f 
08389: 5374 77c3 b372 7a20 4b6c 6f6e 6965 3c2f  Stw..rz Klonie08399: 613e 0050 6f6b 61c5 bc20 c59b 7769 6174  a>.Poka.. ..wiat
083a9: 7520 7377 c3b3 6a20 5765 654d 6565 2e3c  u sw..j WeeMee.<

Ma su questi due strumenti NON ho finito di lavorarci, quindi, armato di cronometro ho fatto questo esperimento:

grep -iaob mustafa /cygdrive/c/immaginidd/barbuto.dd
tempo: 52 secondi e 50 centesimi - offset corretto 113917010

$ strings -t d /cygdrive/c/immaginidd/barbuto.dd | grep -i mustafa
113917010 tuo fratello Mustafa
tempo: 29 secondi e 84 centesimi - offset corretto 113917010

Insomma strings in pipe con grep è molto più veloce (il 51% in più).

Una spiegazione c'è, che fa capire la potenza dell'operatore "pipe" (|) e di Linux.

Le ragioni della lentezza sono molteplici, ma una su tutte:

strings ha un algoritmo infinitamente più semplice e veloce di grep, e la quantità di dati che estrae è esigua, per cui il secondo grep, il cui input è generato da strings, ha molto meno input da esaminare.

Per avere conferma di ciò, basta mandare l'output di strings su un file, e vedere che è immensamente più piccolo del file intero su cui strings ha lavorato.

inoltre ci sono altre ragioni, fra cui il fatto che grep è costruito per cercare in file di testo, suddiviso in righe, e con un set di caratteri ben definito, e passsandogli un binario, come appunto un'immagine dd, non è che lo aiuti molto.

Strings invece produce un output molto vicino a quello su cui grep offre le prestazioni migliori.

In sostanza, strings estrae le stringhe da un file binario e passa il suo output in pipe a grep, che opererà la ricerca della parola "mustafa", su un output testuale e ridotto, sfruttando al massimo la sua potenza.

La stessa sperimentazione la si può fare usando queste immagini.