Comment effacer vraiment un disque dur avant de le revendre ou le donner ?

Originally published at: http://korben.info/effacer-vraiment-disque-dur-de-revendre-donner.html

Vous le savez surement, un simple formatage ne suffit pas pour vraiment supprimer les données présentes sur un disque dur ou une clé USB. Il est toujours possible de les récupérer comme je l’expliquais la dernière fois. Heureusement, il existe des tas de logiciels (comme wipe ou dban), certains payants, qui permettent de supprimer VRAIMENT…

il vaut mieux utiliser /dev/urandom sous linux.
/dev/random est beaucoup plus lent. Meme pour une antique disquette de 720 ko c’est trop lent.

Une passe suffit ! pas besoin d’en faire sept. Faire sept passe risque plutôt de détruire le disque donc si le but c’est de le détruire … autant le détruire c’est d’ailleurs la seul solution “military grade”

Récupérer les données d’un disque qui meure à petit feux c’est une chose, récupérer depuis un disque qui a été wipé il faut tout simplement oublier. Il y aura de toute façon une partie du fichier qui sera illisible car corrompu, plus le fichier est gros et plus cela réduit les chances de récupérer quoi que ce soit.

Voir : http://www.howtogeek.com/115573/htg-explains-why-you-only-have-to-wipe-a-disk-once-to-erase-it/

1 « J'aime »

j’ai lu que sur un SSD (ou une clé usb ou tout autre appareil qui fonctionne uniquement avec des puces) que de faire X passes ca sert a rien

sur une puce la memoire est toujours au meme endroid (c’est un transistor)
alors que sur un disque dur mecanique, le bit peut laissé un residuel magnetique et c’est ca qui permet la recupération

maintenant j’ignore si c’est vrai ou faux… mais ca me parait logique…
d’ailleur mac os ne propose PAS plusieurs passes quand on formate un SSD, alors que pour HDD si

Sur les ssd intel secure erase fait le job, pour le reste la commande schred existe et est plus pratique qu’un dd :wink:

heu …
Korben … mon cher Manu :wink:
il est où ton 500Go ? 'veux bien le récupérer moi !!!

Tiens, je vais profiter de cet article pour poser une question à laquelle je n’ai jamais vraiment trouvé de réponse…

Comment se fait-il qu’il ne soit pas “possible” de réellement effacer un disque dur, même après plusieurs passes ?
Pourtant, si l’on s’affaire à remplir bit par bit un disque dur de zéros, il ne devrait au final plus rien rester, non ? Étant donné que dans un usage normal, l’OS est a priori apte à manipuler des bits sans erreurs, pourquoi un programme de wipe ne saurait pas modifier l’intégralité du disque dur ? Est-ce parce qu’il puisse arriver que le processus “saute” des bits par ci par là, qui restent intacts ?

Et du coup, autre question : qu’en est-il des mémoires flash ? (SSD, clés USB, cartes SD, etc)

(oui je sais, beaucoup de “?” ici :wink: )

La seconde étape consite à vérifier lque c’est le bon disque :slight_smile:

[quote=“Ailothaen, post:7, topic:5038, full:true”]
Tiens, je vais profiter de cet article pour poser une question à laquelle je n’ai jamais vraiment trouvé de réponse…

Comment se fait-il qu’il ne soit pas “possible” de réellement effacer un disque dur, même après plusieurs passes ?
Pourtant, si l’on s’affaire à remplir bit par bit un disque dur de zéros, il ne devrait au final plus rien rester, non ? Étant donné que dans un usage normal, l’OS est a priori apte à manipuler des bits sans erreurs, pourquoi un programme de wipe ne saurait pas modifier l’intégralité du disque dur ? Est-ce parce qu’il puisse arriver que le processus “saute” des bits par ci par là, qui restent intacts ?[/quote]
Tu résonnes en bit binaire, mais c’est un stockage magnétique de cellules (aimants) très rapprochées.
Les bits sont des minis aimants orienté Nord ou Sud, sauf qu’en pratique il ne sont jamais parfaitement alignés et le controlleur arrondi pour trouver des bits numérique :
Si Nord parfait vaut 1 et Sud parfait 0, le contrôleur interprétera 0.0-0.3 en 0, 0.7-1.0 en 1 et 0.4-0.6 en erreur de lecture.
Quand tu écris un bit particulier, les aimants sont tellement rapprochées que tu influences les bits d’à coté,
Ex : 1 0 1 0 1 0 que tu veux changer en 0 0 0 0 1 0.
Avant tu aurais comme niveau physique :
0.8 0.2 0.8 0.2 0.8 0.2, après écriture tu aurais 0.3 0.0 0.3 0.1 0.8 0.2
En écrivant 0 sur le premier bit, tu as “renforcé” le 0 du second bit.
En écrivant 0 sur le 3eme bit tu as “renforcé” l’orientation 0 des bits 2 et 4.
Avec les “arrondis” du contrôleur de disque les bits sont parfaitement lisibles. En lisant les niveaux physiques (analogiques) on peut déduire l’état précédent des bits.

[quote=“Ailothaen, post:7, topic:5038, full:true”]Et du coup, autre question : qu’en est-il des mémoires flash ? (SSD, clés USB, cartes SD, etc)[/quote]Pour limiter l’usure les contrôleurs flash ne laissent pas l’accès direct aux cellules NAND, quand tu écris des données c’est le contrôleur qui choisit une cellule moins usée pour écrire dessus. Mon ex précédent serait donc (avec beaucoup d’approximations):
101010xx => 000010xx
Les cellules NAND de l’octet d’origine resteront inchangées, et tout le nouvel état de l’octet sera écrit dans des cellules ayant moins d’écritures au compteur.
Le contrôleur fait aussi plein d’autres truc (ex: réécrire de vieux bit avant que leur état soit perdu), c’est tellement complexe, que la norme prévoit une instruction secure erase.

Coquille ou non-sens :wink: ici :

cela ne suffit pas être pour être certain

  • /dev/random est bloquant lorsque l’entropie devient trop faible, effacer un disque peut prendre une année comme ne jamais se terminer… Quant à faire 7 passes avec /dev/urandom sur un disque de 4 To cela peut prendre 1 mois.

  • Avec une seule et unique passe, que cela se fasse avec/dev/zero ou /dev/urandom ça ne change rien si on considère que “l’ennemi” possède des moyens d’analyses poussés. Il ne lui est pas plus difficile de filtrer des zéros que des suites aléatoires de zéro et de un qu’il peut lire sur le support lui-même comme tout le monde.

  • @Ailothaen : le disque dur n’enregistre pas des 0 et des 1 mais du magnétisme sur un support analogique avec toutes les imperfections et les imprécisions existantes.

  • Utiliser dd pour écraser les données d’un disque dur, n’empêche pas le disque lui même de faire son travail de réallocation de blocs (Cf. SMART). Ces secteurs corrompus ne sont plus accessibles à celui qui voudrait les effacer, alors qu’ils peuvent contenir des informations exploitables. Je conseillerais donc de faire une seule passe avec dd if=/dev/zero si le disque ne contient rien d’important et qu’on souhaite en faire cadeau à quelqu’un , ou de le détruire carrément à la perceuse, au marteau, … sinon.

1 « J'aime »

L’histoire des 7 passes vient d’un papier théorique de Guttman, basé sur les technologies de stockage de l’époque (MFM et RLL).

Il est douteux que la technique décrite dans sa théorie est été jamais été mise en oeuvre.
(Guttman parle d’une tentative d’archéo-informatique sur un disque de 80Mo de Cray-1 en 2011.)

Et à la fois la techno d’encodage et la densité de stockage ont énormément progressé - cela rend le papier encore plus obsolète.
Cf : www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html#Epilogue pour le commentaire de Guttman lui-même.

Par contre, il y a bien un gain théorique à effacer avec de l’aléatoire que mettre à zéro. Cela serait plus facile de détecter un signal rémanent - sauf que avec les encodages modernes, l’encodage de “0” n’est pas aussi trivial. Mais la régularité ouvre la porte à une attaque par méthode statistique.

Dans la vie pratique : J’ai eu à faire face à un disque effacé par erreur par DBan, dans la situation ou les bretelles et la ceinture avaient déjà lâché.
Nous avons fait le tour des professionnels de la place et aucun ne pouvait y faire quoi que ce soit, même si on mettait sur la table 50k€.(C’était un WD Caviar Black de 250Go.)

J’en reste aux solutions suivantes :

  • depuis Windows : Eraser
  • si c’est du contenu banal (ex : collection de films) : dd if=/dev/zero of=/dev/diskX
  • si l’on peut booter sur un CD/USB : DBAN
  • si c’est vraiment super-sensible : broyage physique du disque

Mais j’avoue que cela m’a fait un peu mal au coeur de faire broyer les 96 disques d’un SAN…

Bonjour,
J’ai un ami bossant dans un Département de recherche en sécurité minformatique sui m’a récemment fait part de son expérience concernant la récupération de données sur des disques durs à plateau brûlés. C’est possible en fonction de l’état du disque dur . Il existe des outils confidentiels (secret défense) permettant de récupérer un disque dur effacé quel que soit le software de suppression de données utilisé.

[quote=“Quezako, post:12, topic:5038, full:true”]Je crois savoir qu’il faut du matériel haut de gamme et assez cher pour examiner un disque dur ouvert et surtout nécessite un environnement sain sans poussière, renseignez vous sur les tarifs des sociétés qui proposent ce genre de service, c’est très cher…[/quote]Pas besoin d’ouvrir un disque pour récupérer les données effacées de manière logiciel, l’ouverture est nécessaire quand il y’a eu des dégâts physiques (Ex: poussière, ou tête de lecture HS)

Pour lire les états antérieurs de bit il “suffit” de reprogrammer le firmware pour lire plusieurs niveaux de bits magnétiques (au lieu de lire zéro ou un, tu reprogrammes pour sortir plusieurs niveau logiciels des bits ex 0 à 3).

Sur le fond tu as entièrement raison, tout ça est théorique : Quand bien même ou pourrait lire l’état n-1 de chaque bit, tu ne sauras pas dans quel ordre ces bits ont été modifiés, sans cette variable temporelle les possibilités pour interpréter ces données sont quasi infini.

Chui Con moi !
Y avait d’autres outils que la disqueuse pour effacer un disque ? ?

Comme le disait croux, l’entropie devient vite un problème avec urandom et l’écriture devient très très très longue.
Pour écrire sur le disque à sa vitesse max (150 Mo/s en général), j’utilise openssl pour crée une clé pseudo aléatoire à partir de urandom, le tout pipé dans “pv” pour avoir une progress bar.

Ce qui nous donne pour les plus pressés :
for i in 1 2 3; do openssl enc -aes128 -k "$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" < /dev/zero | pv -trb > /dev/sda ;done

1 « J'aime »

A chaque fois que je dois utiliser la commande “dd”, je rajoute l’argument bs=4M pour accélérer significativement la copie
L’inconvénient de la commande “dd” est qu’elle ne donne pas le pourcentage de copie, de plus elle ne traite qu’un disque à la fois.
Ces inconvénients disparaissent avec la commande dcfldd