The Sleuth Kit Informer
Numero 19
http://www.sleuthkit.org/informer
http://sleuthkit.sourceforge.net/informer
Brian Carrier
carrier at sleuthkit dot org
Numero19
15 Marzo 2005
Traduzione : Maurizio Anconelli
Contenuti
Agganciare le IO Calls per supporto immagini Multi-Formato (di Michael Cohen)
Introduzione
Questo numero di Informer è unico in quanto contiene articoli che descrivono due differenti approcci allo stesso problema. Il primo articolo descrive le nuove funzionalità di file immagine della versione 2 di The Sleuth Kit, che supporta dischi e file immagine sezionati. Il secondo articolo è di Michael Cohen e descrive come PyFlag avesse aggiunto il supporto per differenti formati di file immagine ancor prima della versione 2 di TSK. PyFlag utilizza TSK per analizzare le immagini di filesystem.
Nell'ultimo numero di Informer, ho menzionato come non avrei più creato la versione di testo a causa del tempo necessario a tradurre manualmente il file html in puro testo. Alexander Ehlert mi ha inviato una mail spiegandomi come lynx possa essere utilizzato per estrarre il testo da una pagina HTML, quindi utilizzerò questo sistema per questo ed i futuri numeri (fino a chè non avrò trovato un sistema migliore per la gestione dei documenti).
Novità?
Saranno presto rilasciate le nuove versioni di TSK e Autopsy. TSK v2 ha svariate nuove funzionalità incluse il supporto per dischi ed immagini frazionati (come spiegato più avanti in questo numero), autorilevamento del tipo di filesystem ed un nuovo design interno. Sono presenti anche alcune nuove caratteristiche aggiunte ai tool esistenti. Al fine di rimuovere un'HPA da un disco ATA è stato aggiunto lo strumento disk_sreset e diskstat è stato rinominato in disk_stat per cercare di rendere più chiaro il nome dei programmi. Autopsy è stato aggiornato alla versione 2.04 e supporta ora dischi e file immagine sezionati.
Il quinto Annual Digital Forensic Research Workshop (DFRWS) ha annunciato in Gennaio la relativa Call for Papers. Una delle aree di interesse generale è lo sviluppo ed il test degli strumenti in generale, è quindi un'ottima opportunità per pubblicare lavori su tool basati suTSK/Autopsy o su altri strumenti Open Source.
Call For Papers
The Sleuth Kit Informer sta cercando articoli su strumenti open source e tecniche per l'investigazione digitale (computer / digital forensics) ed incident response. Sono apprezzati, ma non richiesti, articoli che parlano di The Sleuth Kit e Autopsy. Argomentazioni d'esempio includono (ma non sono limitate a):
Tutorials strumenti open source
Esperienze e commenti sull'utilizzo di strumenti open source
Nuove tecniche di investigazione con tools open source
Test e risultati di tools open source
http://www.sleuthkit.org/informer/cfp.html
Nuovo Supporto File Immagine
Brian Carrier
Introduzione
La versione 2 di The Sleuth Kit (TSK) ha finalmente aggiunto il supporto per i file immagine oltre alle partizioni raw. TSK supporta ora i dischi raw e le immagini divise e le future versioni supporteranno i formati compressi e non-raw. Questo articolo descrive come utilizzare le nuove funzionalità e ne fornisce una descrizione dell'implementazione ad alto livello.
Utilizzo
Ci sono due nuovi elementi da considerare con TSK. Uno è il formato del file immagine ed il secondo è la posizione dell'offset di una specifica partizione o filesystem nell'immagine di un disco.Conseguentemente sono presenti due nuovi flag da linea di comando.Il flag -i è opzionale ed è utilizzato per specifici formati di file immagine. Se non specificato, il programma proverà a rilevare il formato. Il secondo fleg è -o ed è usato per specificare l'offset dove inizia una specifica partizione.
Quando specificato, l'argomento tipo di immagine è una lista di uno o più tipi di formato separati da virgole. Al momento l'argomento necessita solo un tipo, ma le future versioni potranno richiedere tipi multipli. I tipi al momento supportati sono raw e split e con un'mmagine base è possibile usare gli argomenti -i raw o -i split. In futuro i programmi potranno utilizzare i formati di file immagine ACME Company con dati integrati e bisognerà utilizzare -i acme,split se il file immagine è diviso in vari file.
L'argomento offset è, di default, in settori. Per specificare che la partizione inizia nel settore 63, ad esempio, bisogna usare -o 63. Se si vuole specificare l'offset usando una differente dimensione dei blocchi, la grandezza dei blocchi dovrà essere passata nel formato of offset@blocksize. Per specificare, ad esempio, che la partizione inizia nel blocco 1000 e che ciascun blocco è di 2048 bytes, bisogna utilizzare -o 1000@2048.
La posizione dei nomi dei file immagine per ogni comando non è cambiata. Se vengono utilizzate immagini frazionate, i nomi devono essere dati in maniera ordinata, ad esempio: fls image.dd.01 image.dd.02 image.dd.03 image.dd.04 .... Per specificare un gran numero di file è possibile utilizzare l'asterisco * : fls image.dd.*.
Questo è un esempio di argomenti possibili:
# fls -i split -o 63 -f ntfs disk1.dd.*
In questo esempio è utilizzata la nuova funzionalità di autorilevamento :
# fls -o 63 disk1.dd.*
Se abbiamo un'immagine di partizione raw bisogna evitare l'argomento -o (e trarre vantaggio dalla nuova funzionalità di autorilevamento di filesystem):
# fls part1.dd
Nuovo Strumento
E' disponibile un nuovo tool utile con i formati di file immagine. Il programma img_stat mostrerà i dettagli relativi al file immagine. Informazioni d'esempio includono il range di settori per ciascuna immagine frazionata ed altri dati integrati che saranno mostrati per i futuri formati di file. Per determinare il tipo di formato del file può essere utilizzato il flag -t.
Implementazione Generale
Questa sezione contiene informazioni per chi fosse interessato al codice del nuovo tool supporto immagine. La nuove funzionalità sono state aggiunte creando una nuova libreria imgtools. Questa libreria è utilizzata per leggere i dati dall'immagine. Il codice del filesystem non conosce in nessun modo quale formato di immagine è utilizzato.
Prima di essere processato, il file immagine è aperto utilizzando la funzione img_open . Questa funzione determina il tipo di file immagine ed inizializza una struttura dati IMG_INFO.Questa struttura di dati viene passata al codice che gestisce il file system ed il disco ed è utilizzato per leggere tutti i dati. La libreria imgtools contiene tutto il codice capace di leggere i file immagine.
Conclusione
La versione 2 di TSK ha finalmente introdotto il supporto a dischi e file immagine frazionati, rendendo l'impostazione del caso più semplice. Questo articolo ha descritto a livello base l'utilizzo dei nuovi tools e funzionalità.
Agganciare le IO Calls per supporto Immagini Multi-Formato
Michael Cohen
Introduzione
Analizzando immagini di hard disk, capita spesso che queste siano fornite in formati leggermente differenti dalle consuete immagini di partizione create con dd. Ciò può succedere a causa della suddivisione (split) dell'immagine in file multipli o l'immagine potrebbe essere stata acquisita utilizzando Encase (TM) che adotta il suo formato proprietario di file immagine.
Alcuni tool forensici richiedono che il file immagine sia in uno specifico formato. Le precedenti versioni di Sleuthkit, ad esempio, richiedevano che l'immagine fosse un'immagine di partizione in formato non compresso, ottenuta magari utilizzando il tool a linea di comando dd:
dd if=/dev/hda1 of=image.dd
Se si disponeva di un'immagine raw del disco es. /dev/hda, l'investigatore era costretto ad utilizzare dd per sezionare l'immagine originale in partizioni conformi alla tabella delle partizioni (Notare che il salto di 63 settori è normalmente recuperato dalla tavola delle partizioni utilizzando sfdisk, mmls o tools similari)::
dd if=disk_image.dd of=partition_image.dd bs=512 skip=63
Ciò può rappresentare una gran perdita di tempo in caso l'hard disk di origine sia molto grande. Sarebbe quindi auspicabile avere un livello di astrazione che converta al volo i differenti tipi di file immagine (immagini di partizione rispetto a immagini di disco) senza richiedere un'ulteriore copia dell'immagine.
Questa funzionalità diviene ancor più desiderabile se consideriamo l'analisi di immagini che sono state salvate utilizzando la compressione. Il popolare software Encase(tm), ad esempio, salva le immagini in un formato proprietario denominato `The Expert Witness Compression Format`[1]. Questo formato comprende sia la compressione che la suddivisione dell'immagine in parti gestibili. E' possibile abilitare qualsiasi tool al supporto automatico di queso formato immagine fornendo un livello d'astrazione trasparente.
Agganciare le IO per divertimento e profitto
Il pacchetto PyFlag[2] ha una patch a livello IO Subsystem per Sleuthkit che gli permette di operare su un numero di formati di file differenti. Sebbene Sleuthkit sia un tool eccellente, diventa presto evidente come le stesse funzionalità siano richieste anche per gli altri tools, come strings, sfdisk etc.
Modificando il codice sorgente di un'applicazione si ottiene un incremento in quanto ad esigenze di manutenzione del codice per l'adattamento alla patch del sottosistema di IO ad ogni rilascio di una nuova versione di Sleuthkit. Gli sviluppatori di PyFlag hanno dovuto quindi trovare una via migliore. Idealmente il tool non avrebbe dovuto richiedere nessuna modifica al codice ed avrebbe dovuto permettere a programmi arbitrari l'utilizzo trasparente dei formati supportati.
L'ovvia soluzione al problema consisteva in un livello di astrazione basato sulle tecniche di library hooking.
Quando un programma richiede un'operazione di IO su un file (ad es. Per aprire, leggere o scrivere il file), è molto raro che il programma si occupi di esguire la system call direttamente. In effetti molti programmi chiameranno quando richiesto le librerie C open(), read() e write(). Visto che molti programmi non sono compilati staticamente ma sono collegati dinamicamente, il collegamento alle librerie C è eseguito a run time, attraverso il collegamento dinamico.
Molte implementazioni di collegamento dinamico (ed in particolare il GNU libc dynamic loader) permettono ad una libreria di essere caricata anticipatamente, prima delle altre librerie di sistema. Inoltre, se una libreria fornisce un simbolo richiesto, il linker arresterà la ricerca dello stesso nelle altre librerie. Questa proprietà permette ad una libreria "l'aggancio" di un'altra funzione di libreria semplicemente mascherando la funzione di libreria con una definita localmente.
Utilizziamo un esempio per illustrare questa tecnica. Assumiamo di avere il seguente programma scritto in codice pseudo C :
main() {
fd=open("somefile",O_RDONLY);
read(fd,buffer,SIZE);
close(fd);
}All'esecuzione di questo programma, viene chiamata la funzione della libreria C open (che esegue realmente la system call). Il programma legge quindi alcuni dati dal filehandle chiamando la funzione read della libreria C ed in ultimo chiama la funzione close della libreria per chiudere il filehandle.
Nell'implementazione glibc del dynamic loader (l'unica utilizzata in molti sistemi Linux), la variabile d'ambiente LD_PRELOAD specifica il nome della libreria che dovrebbe essere caricata prima di ogni altra. Se il simbolo desiderato è presente all'interno della libreria impostata maschererà le altre funzioni con lo stesso nome contenute nelle altre librerie.
Nel nostro caso dobbiamo agganciare le funzioni open(), read() e close(), dobbiamo quindi creare un oggetto condiviso (una libreria - la chiameremo hooker object) con queste funzioni definite. Dopo aver impostato LD_PRELOAD al percorso dell' hooker object che abbiamo creato, la nostra libreria catturerà tutte le chiamate alla funzione specifica:
External program ---> Hooker object ---> real libc functions
Il risultato di ciò è che fintanto che il programma esterno è eseguito, opera in una semplice partizione che si presenta come fosse ottenuta utilizzando dd. Nella pratica, tuttavia, l' hooker object è capace di leggere immagini più complesse, emulando una semplice immagine di partizione per il programma esterno.
Implementazione
Il tool di PyFlag iohooker implementa questa tecnica. Oltre a catturare le funzioni hook open, read, write etc, cattura anche le funzioni di stream fopen, fread, fwrite etc. Supporta più programmi esterni quali dd, sfdisk, tutti gli eseguibili Sleuthkit, strings e molti altri.
IOHooker è distribuito in due componenti. Il componente principale è un oggetto condiviso chiamato libio_hooker.so. Per controllare questo oggetto le variabili d'ambiente sono settate attraverso un programma wrapper: iowrapper.
Come dimostrazione scarichiamo la versione binaria di PyFlag`[3]. Scompattiamo la distribuzione nella nostra home ed entriamo nella directory.
Il primo passo, prima di poter usare iowrapper è quello di settare la variabile d'ambiente LD_LIBRARY_PATH . Ciò è richiesto per permettere di trovare libio_hooker.so al dynamic linker . Se omettiamo questa impostazione il linker non potrà lanciare l'iowrapper::
~/pyflag$ ./bin/iowrapper -h ./bin/iowrapper: error while loading shared libraries: libio_hooker.so: cannot open shared object file: No such file or directory
Dopo aver impostato la variabile d'ambiente LD_LIBRARY_PATH , possiamo lanciare normalmente l'iowrapper:
~/pyflag$ export LD_LIBRARY_PATH=`pwd`/libs/
~/pyflag$ ./bin/iowrapper
This program wraps library calls to enable binaries to operate
on images with various formats. NOTE: Ensure that libio_hooker.so
is in your LD_LIBRARY_PATH before running this wrapper.
Usage: ./bin/iowrapper -i subsys -o option prog arg1 arg2 arg3...
-i subsys: The name of a subsystem to use (help for a list)
-o optionstr: The option string for the subsystem (help for an example)
-f wrapped filename: All wrapped filenames will start
with this string. This is useful for programs that need to
open other files as well as the target file (for example
/usr/bin/file needs to open magic files as well).
Loading library now for hookingIl messaggio finale "Loading library now for hooking" conferma come l'hooker object sia pronto ed inizializzato. Controlliamo prima quali IO Subsystems siano supportati dall'iowrapper:
~/pyflag$ ./bin/iowrapper -i help
Loading library now for hooking
Available Subsystems:
standard - Standard Sleuthkit IO Subsystem
advanced - Advanced Sleuthkit IO Subsystem
sgzip - Seekable Gzip format
ewf - Expert Witness Compression format
raid - Raid 5 implementation
Unhandled Exception(IO Error): No such IO subsystem: helpCiascun subsystem richiede opzioni specifiche che abbiano un significato. Il filesystem avanzato permette agli utenti di specificare degli offdets arbitrari, come pure multipli sets di immagini frazionate. Possiamo avere spiegazioni più dettaglate in merito a queste opzioni:
~/pyflag$ ./bin/iowrapper -i advanced -o help
Loading library now for hooking
Advanced io subsystem options
offset=bytes Number of bytes to seek to in
the image file. Useful if there is some extra data at the start
of the dd image (e.g. partition table/other partitions)
file=filename Filename to use for split files.
If your dd image is split across many files, specify this parameter
in the order required as many times as needed for seamless
integration
A single word without an = sign represents a filename
to usePer il nostro primo esempio useremo il tool di Sleuthkit fls per elencare i file presenti nella partizione 6 di un'immagine di hard disk. Il tool fls non permette di selezionare un offset dall'inizio del filesystem all'interno dell'immagine, di conseguenza abbiamo bisogno di mediarlo. Come prima cosa calcoliamo l'offset di inizio della partizione:
/pyflag# sfdisk -uS -l /tmp/test.dd
Disk /tmp/test.dd: cannot get geometry
Disk /tmp/test.dd: 0 cylinders, 0 heads, 0 sectors/track
read: Inappropriate ioctl for device
Warning: The partition table looks like it was made
for C/H/S=*/255/63 (instead of 0/0/0).
For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/tmp/test.dd1 63 96389 96327 de Dell Utility
/tmp/test.dd2 * 96390 19647494 19551105 7 HPFS/NTFS
/tmp/test.dd3 19647495 58733639 39086145 c W95 FAT32 (LBA)
/tmp/test.dd4 58733640 117210239 58476600 5 Extended
/tmp/test.dd5 58733703 59328044 594342 82 Linux swap
/tmp/test.dd6 59328108 117210239 57882132 83 LinuxL'inizio della partizione 6 risiede nel settore 59328108 * 512 bytes = 30375991296. Possiamo quindi utilizzare il wrapper per costringere fls a leggere il filesystem da questo offset:
~/pyflag$ ./bin/iowrapper -i advanced -o offset=30375991296,filename=/tmp/test.dd fls -f linux-ext3 foobar Set file to read from as /tmp/test.dd d/d 11: lost+found d/d 32769: etc l/l 12: cdrom d/d 131073: var ... d/d 3211272: opt d/d 3555336: initrd l/l 16: vmlinuz
Da notare che fino a che fls è attivo apre e legge il file foobar. Poichè il wrapper fornisce questo file con dati validi, fls non si accorge che in realtà il file non esiste.
Per il prossimo esempio utilizziamo EnCase(tm) per creare un evidence file di un floppy. Il comando file non è capace di determinare il contenuto dell'immagine, a causa del formato proprietario EWF:
~/pyflag$ file test.e01 test.e01: data ~/pyflag$ hexdump -C test.e01 | head 00000000 45 56 46 09 0d 0a ff 00 01 01 00 00 00 68 65 61 |EVF...ÿ......hea| 00000010 64 65 72 00 00 00 00 00 00 00 00 00 00 b2 00 00 |der..........²..| 00000020 00 00 00 00 00 a5 00 00 00 00 00 00 00 80 00 10 |.....¥..........|
Per vedere il contenuto dell'immagine mediamo il programma hexdump:
~/pyflag$ ./bin/iowrapper -i ewf -o filename=test.e01 hexdump -C test.e01 | head 00000000 eb 3c 90 4d 53 44 4f 53 35 2e 30 00 02 01 01 00 |ë<.msdos5.0.....| 00000010 02 e0 00 40 0b f0 09 00 12 00 02 00 00 00 00 00 |.à.@.ð..........| 00000020 00 00 00 00 00 00 29 fc 02 29 08 4e 4f 20 4e 41 |......)ü.).no na| 00000030 4d 45 20 20 20 20 46 41 54 31 32 20 20 20 33 c9 |me fat12 3É|
Da questo dump esadecimale sembra che l'immagine appartenga ad un floppy FAT 12. Come conferma possiamo eseguire il comando file sull'immagine. Siccome file ha bisogno di aprire altri file oltre all'immagine (ha bisogno di aprire il file magic), dobbiamo fare in modo che hooker non catturi questi altri file (altrimenti se il programma file provasse ad aprire il file magic, sarebbe portato ad aprire l'immagine al suo posto). A questo scopo possiamo utilizzare il flag -f per restringere l'hooking al solo file passato come parametro:
~/pyflag$ ./bin/iowrapper -i ewf -f test.e01 -o filename=test.e01 file test.e01 test.e01: x86 boot sector, code offset 0x3c, OEM-ID "MSDOS5.0", root entries 224, sectors 2880 (volumes <=32 mb) , sectors/fat 9, serial number 0x82902fc, unlabeled, fat (12 bit)
E' possibile utilizzare fls di Sleuthkit in quest'immagine creata con EnCase:
~/pyflag# ./bin/iowrapper -i ewf -f test.e01 -o filename=test.e01 ./bin/fls -f fat12 test.e01 r/r 9: gunzip.exe r/r 11: Hiew.exe r/r 12: tar.exe r/r 22: cygwin1.dll ..
In ultimo estraiamo l'immagine Encase in un'immagne dd standard. Catturiamo dd e redirigiamo l'output in un file:
~/pyflag$ ./bin/iowrapper -i ewf -f test.e01 -o filename=test.e01 dd if=test.e01 > /tmp/test.dd
Accesso Remoto su sistemi operanti
Può capitare l'esigenza di analizzare remotamente un sistema unix attivo. Questo per poter velocemente vedere se il sistema è compromesso, senza dover prima acquisire l'intera immagine. Possiamo utilizzare i nostri strumenti forensici per esaminare il row device remoto utilizzando il sottosistema IO remoto.
.. nota: Questo tipo di analisi è molto delicata poichè il sistema è operante e sta utilizzando il filesystem. I tools forensici accedono al raw device mentre è modificato rendendolo suscettibile a conflitti. Se ad esempio un file è rimosso nel momento in cui una utility forensica sta accedendo all'inode della sua directory, possono essere ricavati dati inconsistenti.
Le conseguenze di ciò possono essere un crash dei tool forensici o un passaggio di risultati inconsistenti. Per il sottosistema IO è tuttavia impossibile alterare in ogni maniera il sistema attivo (fintanto che il dispositivo raw è aperto in sola lettura).
Uno dei problemi più comuni accedenso un sistema remoto sono autenticazione e crittografia. L'accesso al raw device attraverso la rete può facilmente poortare alla compromissione dell'account root attraverso la diffusione di informazioni sensibili del sistema (ad es. il file shadow). E' conveniente demandare a programmi dedicati come Secure Shell (ssh) i problemi di autenticazione ed encryption. Questo è l'approccio utilizzato dall'accesso remoto al sottosistema IO. Gli unici requisiti necessari sul sistema live sono un server ssh ed il programma remote_server (che può essere compilato staticamente).
I passi per accedere ad un dispositivo raw attraverso la rete sono i seguenti:
Disporre di una versione statica di remote_server - il componente remote server installato sulla macchina.
Disporre di un server ssh con il permesso di accedere da root.
Utilizzare il sistema locale per accedere al dispositivo raw remoto intercettando le chiamate di libreria attraverso il wrapper.
Il seguente è un esempio di una sessione che può essere eseguita verso una macchina remota:
~/pyflag$ ./bin/iowrapper -i remote -o host=target,
server_path=/path/to/remote_server,device=/dev/hda
mmls -t dos foo
DOS Partition Table
Units are in 512-byte sectors
Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000062 0000000062 Unallocated
02: 00:00 0000000063 0000096389 0000096327 Dell Utilities FAT (0xde)
03: 00:01 0000096390 0019647494 0019551105 NTFS (0x07)
04: 00:02 0019647495 0058733639 0039086145 Win95 FAT32 (0x0C)
05: 00:03 0058733640 0117210239 0058476600 DOS Extended (0x05)
06: ----- 0058733640 0058733640 0000000001 Extended Table (#1)
07: ----- 0058733641 0058733702 0000000062 Unallocated
08: 01:00 0058733703 0059328044 0000594342 Linux Swap / Solaris x86 (0x82)
09: 01:01 0059328045 0117210239 0057882195 DOS Extended (0x05)
10: ----- 0059328045 0059328045 0000000001 Extended Table (#2)
11: ----- 0059328046 0059328107 0000000062 Unallocated
12: 02:00 0059328108 0117210239 0057882132 Linux (0x83)
Possiamo ora elencare il contenuto della partizione windows:
~/pyflag$ ./bin/iowrapper -i remote -o host=target,
server_path=/path/to/remote_server,device=/dev/hda,
offset=0000096390s fls -f ntfs foo
d/d 12763-144-4: Documents and Settings
d/d 6672-144-3: DRIVERS
d/d 6941-144-6: I386
r/r 6915-128-3: IO.SYS
d/d 62628-144-5: LDIR
r/r 6916-128-3: MSDOS.SYS
d/d 16844-144-1: My Music
r/r 6671-128-3: NTDETECT.COM
r/r 6670-128-3: NTLDR
d/d 13231-144-4: Program Files
...Nell'analisi precedente abbiamo utilizzato i seguenti parametri:
host La stazione alla quale dobbiamo autenticarci. server_path Il percorso al programma remote_server. Questo programma deve risiedere sulla macchina remota. device Il dispositivo raw da esportare offset Un offset da utilizzare sul target remoto. Può essere specificato in settori s), kilobytes (k) o meganbytes(m) a seconda del suffisso.
.. nota:: Questo tipo di analisi può facilmente rilevare la presenza di file o directory nascoste, anche in caso siano presenti rootkits installati a livello del kernel. Questo poichè la maggior parte dei rootkits a livello kernel intercettano le chiamate di sistema che accedono ai file sul filesystem ma non filtrano l'accesso ai dispositivi raw. Siccome fls legge la struttura del file dal dispositivo raw, è indipendente dai driver di filesystem del kernel a dalle relative chiamate di sistema.
Sebbene sia possibile che i rootkits filtrino il dispositivo raw per nascondere file, cio ne accrescerebbe drasticamente la complessità.
Conclusioni
L'hooking delle librerie è una potente tecnica che permette di inserire un wrapper tra un eseguibile arbitrario e l'immagine. PyFlag ha sviluppato un livello di astrazione dell'immagine che permette a programmi differenti il supporto automatico e trasparente di una varietà di formati d' immagine forensica.
Il sottosistema IO remoto permette l'accesso e l'analisi di dispositivi raw remoti da parte di tools forensici, rendendo possibile il rilevamento remoto di alcuni rootkit.
[1] The Expert Witness Compression
Format: http://www.asrdata.com/SMART/whitepaper.html
[2]
PyFlag: http://pyflag.sourceforge.net/
[3]
binary version of PyFlag:
http://pyflag.sourceforge.net/Downloads/index.html
Copyright © 2005 by Brian Carrier. All Rights Reserved
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.
| Per
informazioni contattare staff@cybercrimes.it
Il logo cybercrimes.it e le immagini relative sono di proprietà del sito. La documentazione presente nel sito è soggetta alla licenza Creative Commons ed è quindi liberamente riproducibile riportando il nome dell'autore originale. |
