UTILITAIRE DE SANITIZATION DES DISQUES DURS/FICHIERS (SUPPRESSION DE DONNÉES CON
Profil bloqué
-
24 mai 2010 à 22:14
cs_ben00000 Messages postés 5 Date d'inscription mardi 1 février 2011 Statut Membre Dernière intervention 19 avril 2011 - 5 mai 2011 à 09:03
cs_ben00000 Messages postés 5 Date d'inscription mardi 1 février 2011 Statut Membre Dernière intervention 19 avril 2011 - 5 mai 2011 à 09:03
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/51792-utilitaire-de-sanitization-des-disques-durs-fichiers-suppression-de-donnees-confidentielles
https://codes-sources.commentcamarche.net/source/51792-utilitaire-de-sanitization-des-disques-durs-fichiers-suppression-de-donnees-confidentielles
5 mai 2011 à 09:03
31 juil. 2010 à 11:55
J'aurais besoin de savoir si on peut sataniser le disque C:\ ?
Merci
26 mai 2010 à 09:49
BruNews --> merci beaucoup pour le zip ! Je l'ai téléchargé et j'intégrerai dès que je trouverai un peu de temps (ce Week End normalement).
Galain --> Merci pour le retour sur NTFS !
Pour ce qui est de la passe "random", c'est effectivement à cause de l'OS 64-bit que cela ne fonctionne pas, vu que l'appel à la dll de Brunews retourne une adresse mémoire de taille 4 octets sur tous les OS (vu que le 64-bit n'est pas pris en compte). Donc adresse mémoire invalide sur OS 64-bit (qui attend 8 octets) = erreur lors de l'écriture.
Pour l'effacement du fichier, il faudrait effectivement l'implémenter afin d'enlever toute trace du fichier. Je l'ai pas fait simplement pour pouvoir effectuer mes tests plus simplement (sans avoir à recréer N fois mon fichier ^^). La trace dans la MFT est problématique en effet. Il faudrait éventuellement renommer le fichier avant suppression.
gillardg --> Effectivement, en 1 passe de 3 trois écritures (ou bien 3 passes en fonction de la terminologie ?) ce n'est pas suffisant. Du coup quand je mettrai à jour le code, j'ajouterai une option pour pouvoir choisir ses passes. Cà permettra de configurer le nombre, l'ordre, mais aussi la valeur à écrire (si d'aventure 0x55 et 0xAA n'étaient pas souhaités). J'essayerai de pondre quelque chose "d'un peu ouvert" au niveau de l'architecture du code, de sorte qu'il soit possible d'ajouter très facilement de nouveaux types de passes en implémentant un quelconque algorithme autre que valeur constante ou random...
Au passage j'ai pensé à un truc en lisant le commentaire de Brunews : de mémoire j'ai mal codé le calcul de la taille du buffer pour l'écriture Random(). Il se pourrait que j'ai mis une valeur en dur qui ne fonctionne pas au top avec des disques dont la taille des secteurs n'est pas 512... J'ai pas vérifié, c'est de mémoire, je regarderai en détail ce WE si je trouve le temps !
@+
25 mai 2010 à 21:59
Ton code fonctionne correctement pour des fichiers dans une partitions NTFS : l'idéal ensuite est d'effacer purement et simplement le fichier. Il convient d'ajouter que le nom du fichier est toujours visible dans l'enregistrement NTFS associé à ce fichier sauf si cet enregistrement est réutilisé par le système ou l'utilisateur pour un autre fichier à créer. Cependant NTFS ne se soucie guère de ces enregistrements effacés et en crée des nouveaux pour ses besoins propres. Ce qui veut dire que l'on n'a plus le contenu du fichier mais on a encore son nom ce qui peut renseigner sur le contenu qu'il avait auparavant.
Je pense qu'en FAT on a la même configuration pour retrouver le nom du fichier dans le répertoire : seule la première lettre est modifiée par le caractère & ( ce caractère est le caractère d'effacement sur une entrée 32 bits de répertoire en FAT)
Mes essais sur une partition à "sanitiser" ont été faits en lockant la partition ( c'était une partition non système classique en NTFS avec une centaine de fichiers ). J'ai retrouvé une partition RAW sans aucun système de fichiers.
Evidemment étant moi-même en 64 bits la passe aléatoire me causait une erreur et je l'ai supprimé pour les tests précédents
voici ci-dessus les résultats de mes tests en NTFS de ton superbe projet
Bravo
25 mai 2010 à 11:14
la NSA préconise un minimum de 5 passes pour chaque octet à "sanitizer"
il y a un vieil utilitaire (!norton(?)) qui le fait en 7 passes
24 mai 2010 à 23:00
Brunews te fournit la dll en 64 bits au post précédent
J'ai bien sanitisé une partition NTFS avec les 2 premières passes ( celle avec Random bloquait) : est-ce dû à l'Os 64 bits ou a Visual Basic 2010 Express -> je penche largement pour l'OS
très beau travail et code très propre (par rapport à ma version Net de "Accès Direct disques et Partitions")
Allez c'est mérité 10/10 mon pote et bravo
24 mai 2010 à 22:46
http://brunews.com/alloc.zip
Dans zip: bn64Alloc.dll (2 Ko) et tstAlloc.exe (4 Ko).
DLL exporte:
void* __fastcall bnAlloc2MoAlea(), BLOC DE 2 MO idem à la DLL 32.
int bnTestSse(), C'est un INT32 le retour.
tstAlloc.exe est prog de test de la DLL.
Commence par appeler bnTestSse(), si retour est 0 ne pas aller plus loin.
Le minimum requis est CPU avec SSE 4.1, donc vieux CPU ne pas insister sinon badaboum.
Ensuite:
pmem = bnAlloc2MoAlea(); // BLOC DE 2 Mo rempli alea
if(pmem == 0) STOP !!! MANQUE MEMOIRE (un comble en x64 mais...)
J'affiche tout pmem par DWORDs dans un fichier.
LIBERATION: VirtualFree(pmem, 0, MEM_RELEASE); A NE PAS OUBLIER !!!
BIEN PENSER QUE C'EST __fastcall EN x64 !!!
Bosse bien, ciao...
24 mai 2010 à 22:14
Je viens de découvrir ton code et cela me rappelle de très bons souvenirs. il faut dire qu'à une époque nous avions eu des discussions plus qu'intéressantes au sujet de clusters,secteurs et autres paramètres liés au disque dur
Je vais regarder ton code et le tester sur une partition NTFS
Cela est vrai que Vista et Seven nous bloque en écriture avec Writefile mais c'est pour la "sécurité" de l'OS.
A+ pour la note et mes impressions définitives