In queste settimane alcuni articoli hanno parlato nuovamente dei confronti tra le velocità di copia eseguite con diverse modalità o software.
L’argomento periodicamente ritorna alla ribalta, ed è un bene: l’attività di copia forense rappresenta un impegno importante per il Digital Forensics Expert o per le Forze dell’Ordine. Ogni ora risparmiata è un’ora in più che il professionista può dedicare ad attività più impegnative e interessanti, come l’analisi della copia prodotta.
Come è buona prassi nella Digital Forensics, anche noi a suo tempo abbiamo testato in laboratorio i tool menzionati, per verificare quanto suggerito dai vari articoli.
Riportiamo un confronto risalente ormai a quasi due anni fa e ci ripromettiamo di eseguire nuovi test per verificare se le nuove versioni dei tool hanno comportato migliorie e ribaltamenti nella classifica.
Strumentazione hardware
Supporto da copiare: Hard disk da 2.5” TOSHIBA MK5061GSYN da 500 GB
Workstation utilizzata per la copia: CPU e RAM sovradimensionati, tutto collegato in eSATA
Write blocker: TABLEAU T35es
Supporto di destinazione: RAID 0
In sintesi l’unico collo di bottiglia è il bus del disco sorgente, e la strumentazione ha potenza di calcolo più che sufficiente.
Software utilizzati
Ai fini di questo resoconto citeremo solo i risultati dei due maggiori competitor: X-Ways Forensics (o meglio WinHex) e FTK Imager.
Le versioni utilizzate:
WinHex 16.2 SR-7
FTK Imager 3.0.1.1467
Entrambi i software sono stati configurati per creare una copia in formato EWF in un unico file non segmentato con compressione standard, calcolarne l’hash SHA-1 (FTK anche l’MD5, in quel periodo X-Ways non supportava il calcolo contemporaneo di due hash) e verificare la copia prodotta.
Premettiamo che il file ottenuto aveva dimensioni comparabili.
Il risultato
Long story short:
FTK Imager: Acquisizione 4:37 ore, verifica 0:57 ore
WinHex: Acquisizione 1:56 ore, verifica 0:52 ore
WinHex vince con 2 ore e mezza di distacco!
Due ore e mezza risparmiate nella copia di un singolo disco, quindi è facile capire la portata del vantaggio acquisito durante attività pesanti di copia che coinvolgono numerosi dischi.
La spiegazione
Quale può essere il motivo di un simile abissale divario prestazionale?
Abbiamo una struttura hardware assolutamente identica, quindi la motivazione deve risiedere nel software.
Teniamo momentaneamente la soluzione in sospeso e lasciamo spazio ai commenti 🙂 .
Il futuro
Data l’enorme evoluzione dei software negli ultimi 2 anni, ci ripromettiamo di eseguire una nuova serie di test nei prossimi mesi e di verificare se le prestazioni dei software sono modificate, in meglio o in peggio.
Concludiamo allegando i log delle due operazioni.
WinHex
17/01/2012, 21.30.32 WinHex 16.2 SR-7 Create Disk Image Computer: ########## User: ########## Source: Hard disk 4 Sectors 0-976773167 Destination: F:\images\HD_05c\HD_05.e01 Model: TOSHIBA MK5061GSYN Serial No.: ########## Firmware Rev.: 9999 Bus: RAID Total capacity: 500.107.862.016 bytes = 466 GB Bytes per sector: 512 Sector count: 976.773.168 Windows disk signature: ########## Unpartitionable space: 2.048 Sectors ATA password protection: not supported SMART: n/a (Funzione non corretta.) Partitioning style: MBR Partition 1 Sectors 2.048 - 409.599 Partition table: Sector 0 File system: NTFS Name: SYSTEM Total capacity: 208.666.624 bytes = 199 MB Sector count: 407.552 Bytes per sector: 512 Bytes per cluster: 4.096 Free clusters: 43.677 = 86% free Total clusters: 50.943 NTFS version: 3.1 Volume flags: 0x0000 Partition 2, lost Sectors 2.049 - 409.600 Partition table: Sector 1 File system: NTFS Total capacity: 208.666.624 bytes = 199 MB Sector count: 407.552 Bytes per sector: 512 Bytes per cluster: 4.096 Free clusters: 0 = 0% free Total clusters: 116.847.359 Partition 3 Sectors 409.600 - 935.188.479 Partition table: Sector 0 File system: NTFS Total capacity: 478.606.786.560 bytes = 446 GB Sector count: 934.778.880 Bytes per sector: 512 Bytes per cluster: 4.096 Free clusters: 104.950.557 = 90% free Total clusters: 116.847.359 NTFS version: 3.1 Volume flags: 0x0000 Volume GUID: ########## Partition 4 Sectors 935.188.480 - 976.560.127 Partition table: Sector 0 File system: NTFS Name: RECOVERY Total capacity: 21.182.283.776 bytes = 19,7 GB Sector count: 41.371.648 Bytes per sector: 512 Bytes per cluster: 4.096 Free clusters: 752.661 = 15% free Total clusters: 5.171.455 NTFS version: 3.1 Volume flags: 0x0000 Volume GUID: ########## Partition 5 Sectors 976.560.128 - 976.771.119 Partition table: Sector 0 File system: FAT32 Name: HP_TOOLS Total capacity: 108.027.904 bytes = 103 MB Sector count: 210.992 Usable sectors: 202.800 First data sector: 8.192 Bytes per sector: 512 Bytes per cluster: 1.024 Free clusters: 94.057 = 93% free Total clusters: 101.400 FAT1 = FAT2 Volume label date: 13/02/2011 01.05.18 Clean shut down: Yes I/O error-free: Yes Unused inter-partition space: Sectors 0 - 2.047 (1,0 MB) Sectors 976.771.120 - 976.773.167 (1,0 MB) = 2,0 MB Hash of source data: AB886E69B38DE50647C8A6A2AD78B32FDE7EFA32 (SHA-1) 17/01/2012, 23.26.39,3 Imaging completed. Duration: 1:56:06 h Image consisting of 1 segment(s). 4.108 MB/min Compression ratio: 86% SMART: n/a (Funzione non corretta.) 18/01/2012, 00.19.45,4 Hash re-computed: AB886E69B38DE50647C8A6A2AD78B32FDE7EFA32 Data authenticity OK Duration: 0:52:58 h 9.002 MB/min 1:56:06 h + 0:52:58 h = 2:49:05 h
FTK Imager
Created By AccessData® FTK® Imager 3.0.1.1467 110406 Case Information: Acquired using: ADI3.0.1.1467 Case Number: ########## Evidence Number: ########## Unique Description: ########## Examiner: ########## Notes: ########## -------------------------------------------------------------- Information for F:\images\HD_05b\HD_05: Physical Evidentiary Item (Source) Information: [Drive Geometry] Cylinders: 60.801 Tracks per Cylinder: 255 Sectors per Track: 63 Bytes per Sector: 512 Sector Count: 976.773.168 [Physical Drive Information] Drive Model: TOSHIBA MK5061GSYN SCSI Disk Device Drive Serial Number: ########## Drive Interface Type: SCSI Source data size: 476940 MB Sector count: 976773168 [Computed Hashes] MD5 checksum: 02277cf9447ecf9183f7b70f9025e7d7 SHA1 checksum: 61d71e7742d48033b01f2f93b802af7e0d0957c1 Image Information: Acquisition started: Tue Jan 17 11:47:18 2012 Acquisition finished: Tue Jan 17 17:34:28 2012 Segment list: F:\images\HD_05b\HD_05.E01 Image Verification Results: Verification started: Tue Jan 17 17:34:37 2012 Verification finished: Tue Jan 17 18:31:31 2012 MD5 checksum: 02277cf9447ecf9183f7b70f9025e7d7 : verified SHA1 checksum: 61d71e7742d48033b01f2f93b802af7e0d0957c1 : verified
potrebbe essere un problema di settori danneggiati? la differenza dei tempi e’ troppo grande
Credo che il maggior tempo impiegato da FTK Imager dipenda sia dal dal calcolo del secondo valore di hash, sia da una maggiore efficienza di WinHex nella compressione, considerato che l’hard disk acquisito aveva molto spazio libero. Per un ulteriore riscontro di potrebbe fare un test senza compressione e/o con un hard disk “pieno”.