dd if=/dev/sdx of=image.dd bs=512 conv=noerrors,sync

Cette commande va copier l'intégralité du disque sdx dans le fichier image.dd.

• bs=512, taille des blocks du disque, si non mentionnée, dd prend la valeur de la taille des blocks par défaut.
• conv=noerrors,sync dd ne s'arrêtera pas en cas d'erreur de lecture sur un block. Après plusieurs essais, il s'avère que dd s'interrompt en cas de block défectueux sur un disque en panne… Doit-on différencier un block défectueux d'une erreur de lectrue de block?

Contrairement à dd et à dcfldd, dc3dd ne s'interrompt pas quand elle essaie de lire un secteur défectueux. la commande lancée:

dc3dd if=/dev/sdx hofs=image.111 split=10G verb=on hash=md5 log=dc3dd.log hlog=md5.log

• if comme dd, la source, dans le même principe que hofs, il existe hifs
• hofs: la sortie, avec calcul de hash
• split: En cas de découpage de fichier, définit la taille de chaque partie. Avec un split de 10G, une image de 5OOGO donnera 50 fichiers.
• splitformat:image.111, format du nom des fichiers. Voir plus bas
• verb: verbosité
• hash: format de hash, il est possible de mettre sha1 ET md5, ex: hash=md5,sha1
• log: emplacement du fichier de log
• hlog:emplacement du fichier contenant les hashs
• il existe errlog…
  

Une option hashwindow permet de calculer le hash à intervalle régulier. Il est intéressant de la mettre à la même valeur que split pour obtenir ainsi le hash de chaque partie de l'image.

Certaines docs mentionnent progress=on, ma version ne reconnaissait pas cette option.

111 donnera 001,002, etc…
000 donnera 000,001,002, etc…
aaa donnera aaa,aab,aac,etc…

Après nommage des fichiers avec comme format 1111, autopsy v3 ne reconnait pas l'image splittée. Il faudra revenir à un format à 3 caractères. Par contre, autopsyv2 n'a pas eu de difficultés à retrouver les fichiers au format 1111.

dc3dd possède une option qui permet d'accéder directement au disque sans être contraint par le kernel caching.

iflag=direct

Avec conv=noerror,sync iflag=direct, dc3dd permet une récupération plus fine des erreurs sur un disque. Voir ddrescue pour plus de détails.

La version utilisée actuellement est la v1.3.4-1. Il s'avère que comme dd, la commande s'interrompt an cas de bloc défectueux. Certains évoquent un bug de cette version, d'autres évoquent que, parce que dcfldd est un fork de dd, il se comporte comme la commande dd.

La commande ddrescue entre plus dans un cotnexte de récupération de données que de forensics pur. D'autant plus, que cette commande est utilisée en cas d'erreurs sur un disque et que de ce fait, la copie exacte du disque ne peut plus être garantie.

ddrescue va en premier lieu se concentrer sur les secteurs saints du disque, pour ensuite revenir sur les erreurs et tenter de les lire et d'en extraire les données. Cette stratégie est bien sûr paramétrable via les options de ddrescue.

La principale force de cet outil est sa capacité à reprendre son traitement après une interruption quelconque. Ceci est possible grâce aux fichiers de logs créés pendant le processus.

commande de base:

ddrescue /dev/sdx image.ddrescue log.txt

/dev/sdx est la source, image.ddrescue la destination et log.txt le fichier de logs. Ce fichier de logs sera rempli en renseignant les blocks de datas lus et leurs états:

#      pos       size status
0x00000000 0x14580200 +
0x14580200 0x28852000 ?

Les différentes valeurs de “status”:

• ? nontried
• * bad area non trimmed
• / bad area non split
• - bad hardware block(s)
• + finished

Pour relancer la commande à partir de son point d'arrêt, il suffit de la relancer à l'identique:

ddrescue /dev/sdx image.ddrescue log.txt

Pour récupérer le plus de données possibles, il faudra relancer pluqieurs fois ddrescue. La première fois, il sera possible de l'éxécuter sans tenter de lire les erreurs:

ddrescue -n /dev/sdx image.ddrescue log.txt

• -n: empêche ddrescue de revenir sur les erreurs

ceci fait, un fichier de logs est constitués avec les zones saines, et les zones en erreurs marquées par *.

En deuxième lieu, cette commande permettra à ddrescue de tenter de lire les secteurs en erreur (marqués /) 3 fois avant de les marquer ”-” ou “bad” .

ddrescue -r3 -d /dev/sdx image.ddrescue log.txt

• -r3: relis les erreurs 3 fois avant de les marquer bad.
• -d: permet d'accéder au disque directement sans passer par le cache Kernel. La différence est visible dans le fichier de logs. Sans -d, le fichier présentera par exemple 15 errors, avec une taille globale de ces erreurs de 61440 octets, soit 4096 octets par erreur. La logique voudrait que la taille globale des erreurs soit de 15*512=7680 octets. En ajoutant cette option, on permet à ddrescue un “accès direct” au disque et de tenter de récupérer plus finement les données présentes.

une fois cette commande finie, le fichier de logs doit présenter des positions soient marquées + “finished” ou - “bad”:

0x38684000 +
# pos size status
0x00000000 0x32B77800 +
0x32B77800 0x00000200 -
<snip>
0x38684000 0x00000200 -
0x38684200 0x14013E00 +

Cet extrait montre l'état final des secteurs, et surtout, la size des positions est bien de 512 octets (0x00000200).

pour finir, il est possible de définir à ddrescue avec quel caractère il doit remplacer les erreurs, cela permet de discriminer les zéros normaux des zéros mis pour remplacer les erreurs.

Peu importe l'outil utilisé, le principe est le même. Une image disque sera faite à partir d'un OS embarqué sur le pc à analyser. L'image, au lieu d'être enregistré localement, sera envoyé svia le réseau dans un fichier ouvert sur un pc tiers. Le pc considéré comme client est le pc à analyser. Le pc qui acueillera l'image sera le serveur. Le transfert de l'image sera faite via l'outil netcat (nc).

Côté serveur: On place ce poste en écoute:

nc -l -p 2525 | dd of=/net_image.dd

• -l: place nc en écoute
• -p 2525: port TCP en écoute

La commande nc est pipé à dd, cela implique que tout ce qui arrive dans nc via le réseau sera renvoyé dans dd.

Côté client:

dd if=/dev/sda | nc 192.168.55.20 2525

La commande dd est pipé à nc, tout ce que dd va lire, il va le renvoyer à nc.

Au final, on retrouve notre commande dd, la seule différence est qu'elle passe par un tunnel nc.

Lors de la copie octet par octet d'un disque, il est possible de tomber sur une erreur. Il faut garder à l'esprit qu'à chaque tentative d'accès à un secteur défectueux, il y a des chances de corrompre ceux alentours. Ceci dit, dd, dcfldd proposent l'option conv=noerror,sync. Elle permet à la commande de ne pas s'interrompre quand elle rencontre une erreur. De ce fait, il y a un risque d'abîmer encore un peu plus un disque déjà défectueux et cela autant de fois qu'il va rencontrer une nouvelle erreur. dc3dd, en cas d'erreur, essaie de la corriger et continue même en cas d'échec.

Il est conseillé d'utiliser ces trois commandes sans ces options et ainsi de l'interrompre en cas d'erreurs. Par la suite, il conviendra d'utiliser ddrescue pour, dans un premier temps récupérer le plus de données possibles et seulement après se concentrer sur les erreurs.

Les erreurs sur disque vont également modifier la gestion des hashs calculés.

md5sum /dev/sdx

Cette commande retournera certainement une erreur à cause des blocs défectueux présents sur la source. Il faudra donc calculer le hash en entrée et en sortie de commande.

De plus, l'image obtenue ne sera pas la copie exacte de la source à cause des erreurs qui seront remplacées par des zéros ou autres caractères.

cat image.split.0* > image.dd

C'est utile si on souhaite calculer le md5 de l'image splittée obtenue.

cat image.split.0* | md5sum

Le calcul du hash d'un disque en analyse et la partie la plus délicate et la plus sensible. Dans une logique forensic, il est indispensable de conserver l'intégrité de la preuve. Pour cela, le calcul du hash permetra à posteriori de prouver qu'aucune modification n'ait été apportée au support confié.

Plusieurs cas se posent alors:

• Le cas où le support est sain et la calcul du hash est réalisable sur le support.
• Le deuxième cas abordé plus haut, et celui où le support est défectueux, auquel cas un calcul sur le support sera impossible. De plus, un trop grand nombre de lectures sur ce support risquerait de l'endommager encore.

La commande dc3dd (et aussi les autres) propose le calcul du hash en entrée de processus ET en sortie de processus. De plus, une dernière comparaison du hash en le calculant sur l'image obtenue permet un suivi et une preuve “suffisante” pour des autorités. Cependant, peut-on considérer que le calcul d'un hash en entrée et sortie de process puisse certifier la non-modification des données traitées, je n'ai rien trouvé la dessus.

md5sum /dev/sdx

x: étant la lettre du disque en cours

• Le disque ne DOIT pas être monté car dans ce cas, on perd le bénéfice de la preuve, et la pièce est corrompue.
• Ne marchera pas si le disque présente des blocks défectueux.

dc3dd hif=/dev/sdx hof=image.111 split=10G verb=on hash=md5 log=dc3dd.log hlog=md5.log

cat image.* | md5sum

Ces trois commandes devraient donner le même résultat.

md5sum /dev/sdx

x: étant la lettre du disque en cours

Cette commande retournera une erreur d'entrée/sortie.

Pour la création de l'image, soit on utilise dc3dd avec les options conv=noerror,sync, soit on utilise ddrescue. Le choix de l'une ou l'autre dépendra des prérogatives de chacun en termes de finalités (forensics ou récupération de données).

cat image.* | md5sum

Les deux dernières commandes devraient donner le même résultat.

Dues aux erreurs présentes sur le disque, la copie n'est plus conforme au support, il est indispensable de le notifier dans tout rapport.

Montage du disque:

  mount -o ro,loop,noexec,noatime image.dd /mnt/disque

Calculer le hash de ses fichiers:

find . -type f -exec md5sum {} \; > /filelist.md5

En sortie:

root@machine:/mnt/disque # cat /filelist.md5
md5checksum ./nomfichier.ext

md5sum -c filelist.md5 

Résultat de la commande:

root@machine:/mnt/disque # cat /filelist.md5
./nomfichier.ext:  OK

  mount -t vfat -o ro,noexec,loop image.dd /mnt/disque

Cette commande est applicable si image.dd est l'image d'une partition, et non d'un disque entier.

• -t: type du système de fichiers, -t auto permet à mount de détecter automatiquement le type de fs.
• -o: options: ro:read-only, noexec: pas d'éxécution de binaires en provenance de l'image, loop: montage sur une loop, option intéressante:noatime: ne met pas à jour les dates d'accès aux fichiers

Pour monter une partition contenue dans l'image du disque, il faudra, au préalable calculer l'offset à partir duquel la partition débute. L'exemple d'un disque contenant une MBR. Il faut indiquer à la commande mount que la partition commence après la MBR grâce à l'option offset.

La MBR fait 63 secteurs, chacun faisant une taille de 512 bytes. L'offset sera donc de 32256, et mount commencera sa lecture au 64ème secteur.

mount -o offset=32256,ro,noexec,loop image.dd /mnt/disque

Pour connaître le secteur de début d'une partition, il faudra utiliser fdisk -l par exemple. Cette commande indique aussi la taille des secteurs.

Non encore testé.