UTILITAIRE DE SANITIZATION DES DISQUES/FICHIERS (SUPPRESSION IRREMEDIABLE DES DONNEES CONFIDENTIELLES)

Commentaire de violent_ken le 15/04/2007 20:28:05

Tout simplement pour minimiser la possibilité de récupération des données. Parce que même à 00, c'est pas encore sécurisé... D'où l'intérêt de faire plusieurs passes.

Je ne m'y connais malheureusement pas suffisement sur la technologie des disques durs pour te donner une réponse complète, mais demande à jmfmarques, il s'y connait bien !


Tu peux lire aussi ce thread : http://www.vbfrance.com/infomsg_CONCATENER-CHAINE-QUELQUES-MO_921256.aspx?p=4

Quelques liens :
http://www.mag-securs.com/spip.php?article7475
http://www.clubic.com/actualite-352-effacement-de-donnees-protegees.html



En gros, je propose le service "Destruction logicielle par réécriture (surcharge) sur le disque dur" vendu ici :
http://www.invirtuel.fr/notre-metier/notre-metier-effacement-securise.php


@+

Commentaire de jack le 15/04/2007 20:44:50 administrateur CS

Pour info :
"Sanitization" est le terme anglais de "sanitation" en fr : Nettoyage par élevation de température.
J'espère que les disques durs sont water-proof ... euf, étanches !

Commentaire de violent_ken le 15/04/2007 20:48:13

EB ==> Héhé, en effet, mais


-pour la string aléatoire, je ne récupère qu'un pointeur renvoyé par la dll (pas de manip de string). Et comme le temps de création "d'une zone mémoire" de 2Mo par la dll est pratiquement négligeable devant le temps mis a écrire le résultat dans le disque/fichier, pas possible d'optimiser vraiment ici

-pour les &H55 et &HAA, ma foi pourquoi pas virer le StrPtr(s) et utiliser un tableau de bytes ? Faut comparer (d'ailleurs exit le bug que je citais avec cette méthode)



Jack ==> A vrai dire j'ai pas vraiment chercher à traduire ^^ J'ai gardé le terme anglais défini ici : http://en.wikipedia.org/wiki/Sanitization_(classified_information)

@+

Commentaire de violent_ken le 15/04/2007 20:56:08

Bah oui mais non ;)

Parce qu'en VB, la création d'une d'un tableau de 2097152 bytes aléatoires met quand même 300 fois plus de temps que l'appel à la dll ;)

Ok pour les strings avec des 55, mais pas ok pour la string aléatoire ^^

@+

Commentaire de violent_ken le 15/04/2007 20:58:29

Suis-je bête, le construire une seule fois est suffisant... tout comme ma string que je reconstruis à chaque fois dans la boucle du For...

Là il y a de l'optimisation à faire!!

@+

Commentaire de violent_ken le 15/04/2007 21:04:21

mdr ;)

La MAJ arrive dans 2 minutes ^^
@+

Commentaire de violent_ken le 15/04/2007 21:19:53

Voilà qui est fait ;)

Au passage j'ai précalculé toutes les opérations qui étaient effectués dans la boucle dans la version précédente...

C'est mieux comme çà ^^
@++

Commentaire de violent_ken le 15/04/2007 21:22:52

lol oui, je maintiens que c'est impossible de faire mieux niveau perf que la dll !

300 fois plus rapide, la dll, 300 fois ^^

Commentaire de violent_ken le 15/04/2007 21:46:30

Je vois ce que tu veux dire.

Mais, en VB, comment remplirais tu de manière rapide un tableau de 2097152 de taille avec des bytes aléatoires ?


Moi je fais :


Option Explicit

Private Declare Function GetTickCount Lib "kernel32.dll" () As Long

Private Sub Command1_Click()
Dim lTim As Long
Dim tb(2097151) As Byte
Dim x As Long

    lTim = GetTickCount
    Call Randomize
    For x = 0 To 2097151
        tb(x) = Int(Rnd * 256)
    Next x
    lTim = GetTickCount - lTim
    
    Me.Caption = CStr(lTim)
End Sub



550 ms tout de même... alors que l'appel à la dll prend un temps de l'orde de quelques pauvres ms.

@+

Commentaire de violent_ken le 15/04/2007 21:56:10

Un secteur de disque fait généralement 512 octets.

Ecrire dans un disque secteur par secteur (donc avec un tableau de bytes de 512 de taille) nécessiterait 1953215 boucles, donc près de 2 millions de générations de tableau + 2 millions d'écritures sur le disque..... pour un disque de 1Go.


Donc pour mes 200Go, il faudrait 400 millions de tableaux et 400 millions d'écritures sur le disque. Pas gérable.



Donc j'ai choisi un buffer raisonnable de 2Mo, soient 4096 secteurs de disque, et je n'ai ainsi plus que 500 accès/écritures sur le disque pour un disque de 1Go (sachant que c'est l'opération la plus lente).




De toutes manières, quelle que soit la taille du buffer, il faudra avoir généré 1 milliard de nombres aléatoires pour couvrir 1Go.

Plus le buffer est grand, moins on accède de fois au disque.

@+

Commentaire de violent_ken le 15/04/2007 22:06:01

Ben, selon le protocole du département américain de la défense (DOD 5220.22-M), la troisième passe d'écriture consiste en un remplissage de bytes aléatoire sur la totalité du disque, et non en la répétition de n fois un buffer tité aléatoirement.

Autrement dit, je suis obligé de regénérer mon buffer aléatoire à chaque cycle.




500 cycles * 550 ms = plus de 4.5 minutes passées exclusivement à générer des tableaux.

Et j'ai fait un bench, il faut seulement 2.5 secondes avec la dll pour générer le même nombre de bytes aléatoires.


Donc 110 fois moins de temps (et pas 300 comme je le disais un peu au hasard^^).

@+

Commentaire de EBArtSoft le 15/04/2007 22:10:11 administrateur CS

Par consequent il faut tout simplement trouver un remplacant a "rnd" comme la fait BruNews. En vb et bien codé je pense qu'on peut atteindre une procedure VB 50 a 10 fois moins rapide que celle de Bruno.

@+

Commentaire de EBArtSoft le 15/04/2007 22:19:55 administrateur CS

C'est plus simple que ce que tu sembles croires :p
En tout cas personnellement j'aurais immediatement decortiqué le code de Bruno a reception ! Car la moindre ligne de code vaux son pesant d'or :p

(desolé pour le flood :p)

Commentaire de Galain le 15/04/2007 22:57:25

Salut Violent_Ken
J'ai testé sur un disque dur en NTFS et cela fonctionne très bien
Un grand bravo

Commentaire de Galain le 16/04/2007 00:11:44

Salut Violent_Ken
Je t'envoie le code de la dll avec les commentaires sur la génération des nombres aléatoires. l'instrution principale est rdtsc dont le rôle est détourné afin d'avoir une valeur aléatoire de base

__declspec(naked) long* __stdcall bnAlloc2MoAlea()
{
  __asm {
    push    PAGE_READWRITE
    push    MEM_COMMIT or MEM_RESERVE or MEM_TOP_DOWN
    push    2097152 ;// 2 Mo
    push    0
    call    dword ptr VirtualAlloc  ;// alloue le buffer contenant les valeurs aléatoires
    test    eax, eax          ;// test si EAX en retour = 0
    je      short allocEXIT   ;// si oui : l'allocation buffer a échouée
    push    edi               ;// sauvegarde des pointeurs
    push    eax
    push    ebx
    mov     edi, eax          ;// EDI = *pdt
    mov     ebx, 131072       ;// NBR TOURS DE 16 OCTETS
    rdtsc                     ;// rdtsc est une instruction qui stocke dans edx/eax un nombre de 64 bits
                              ;// représentant le nombre de cycle horloge fait depuis le démarrage ( sous toute réserve)  
    mov     edx, eax          ;// EDX = nombre aléatoire
    mov     ecx, 214013       ;// multiplicateur
    sub     edi, 4            ;// compense le 1° add   edi,4 (edi est le pointeur de la zone allouée)
  nextNBR:
    mov     eax, edx          ;// EAX = EDX
    mul     ecx               ;// EAX = ECX * EAX
    add     eax, 2531011      ;// EAX = EAX + constante
    add     edi, 4            ;// pointeur + 4
    mov     edx, eax          ;// // nouveau nombre aléatoire  ----------------------------------------------------
    ror     eax, 16           ;// rotation à droite de 16 bits de EAX ( les 16 bits de poids faibles deviennent    |
                              ;// les 16 bits de poids forts)                                                      |
    add     eax, 7979999      ;// EAX = EAX + constante                                                            |
    mov     [edi], eax        ;// on stocke une valeur aléatoire 32 bits soit 4 octets                             |
                                                                                                                   |
    mov     eax, edx          ;//on recommence <<<<<---------------------------------------------------------------                                                                                     |
    mul     ecx
    add     eax, 2531011
    add     edi, 4            ;// pointeur + 4
    mov     edx, eax          ;// seedRand
    ror     eax, 16
    add     eax, 7979999
    mov     [edi], eax
    
    mov     eax, edx
    mul     ecx
    add     eax, 2531011
    add     edi, 4            ;// pointeur + 4
    mov     edx, eax          ;// seedRand
    ror     eax, 16
    add     eax, 7979999
    mov     [edi], eax
    
    mov     eax, edx
    mul     ecx
    add     eax, 2531011
    add     edi, 4            ;// pointeur + 4
    mov     edx, eax          ;// seedRand
    ror     eax, 16
    add     eax, 7979999
    
    dec     ebx               ;// 1 tour en moins
    mov     [edi], eax
    jnz     short nextNBR     ;// si nbre de tours <> 0 on refait le boucle
    pop     ebx
    pop     eax               ;// POINTEUR ORIGINAL
    pop     edi
allocEXIT:
    ret     0
  }
}

Ce code n'engage que moi et il est possible que j'ai fait des erreurs : pour moi l'assembleur est bien loin
a+

Commentaire de violent_ken le 16/04/2007 00:29:43

Ah, merci bien pour les commentaires du code ASM : je regarde çà demain en profondeur !

Merci, @+

Commentaire de MadM@tt le 16/04/2007 14:30:33

ça fait peur à utiliser avec tous les messages attention attention !! lol
En tout cas c'est vraiment bien, surtout que ça respecte une norme, alors la t'es sur de ton coup (que ça va bien être efficace)
Bravo !

Commentaire de zavier666 le 16/04/2007 18:16:59

Des professionnel sont capables avec des machines perfectionnées de lire des données réécrites huit fois par dessus!!!!

Comment? eh bien comme dans tout phénomène magnétique (utilisé pour écrire sur un dur) lorsque tu changes un bit d'état (passage de 0 à 1 par exemple) et que tu fais l'inverse après (passage de 1 à 0), la matière sur le disque ne revient pas exactement à son état de départ (on appelle cela un phénomène d'hystérésis). cela permet non pas de récupérer des fichiers au complet (ne comptons donc pas la dessus pour augmenter nos capacité de stockage :) ) mais des fragments de fichiers qui permettent dans certains cas de prouver le stockage d'un fichier illicite sur un PC par exemple.

slts!
-------------------------------------------
Toujours + de VB et d'API => API @ la Loupe
http://xav.prog.power.free.fr

Commentaire de jack le 16/04/2007 21:03:45 administrateur CS

Bah y-a de la lecture ici ! lol

Commentaire de Galain le 16/04/2007 21:35:49

Donc j'en conclus que le visiteur bien sûr : un doigt a ripé

Commentaire de BruNews le 16/04/2007 21:42:41 administrateur CS

Le site ne veut pas être responsable de dommages potentiels, il est normal qu'on se prémunisse.
Par "louche" il faut comprendre "potentiellement dangereux", rien de plus.

Commentaire de moustachu le 17/04/2007 10:17:56

zavier666 et violent_ken > Merci votre éclairage. Quel phénomène cet hysteresys ! Toujours là pour nous embêter ! (6 ans d'étude de physique qui parlent ;o)) Mais sur clé usb ? C'est pas magnétique là , si ?

Commentaire de apxa le 18/04/2007 00:44:20

Iop all,
Dis moi tu as était récement controlé pour sorti une appli comme ca ;)
Hors mis cela ca me semble pas mal.

Have Fun ;)

Commentaire de mortalino le 18/04/2007 01:17:59

correction

(on ne parle de "Ce code" (donc là au masculin) qu'après :p

c'est la fatigue :D

Commentaire de Galain le 18/04/2007 18:23:59

Rassures-toi Thomas il n'y a aucun problème

Commentaire de Galain le 19/04/2007 22:56:34

Je me suis amusé à le tester en tout VB (plus de DLL en C) : c'est plus lent mais cela fonctionne nickel et pour
une application non professionnelle cela reste acceptable.Un grand bravo à Violent_Ken

Commentaire de Galain le 19/04/2007 23:25:18

La DLL en C ne me génait point : c'est juste pour voir la différence au niveau temps
De rien

Commentaire de violent_ken le 20/04/2007 13:21:56

Salut à tous, alors niveau gestion du temps, il faut :

-2.5 secondes pour générer 10^9 bytes avec la dll
-4.5 minutes en VB (avec Rnd)


Le temps d'écriture de disque est très largement supérieur au temps de génération des bytes avec la dll.
Cependant, en "tout VB", c'est quand même 0.5 secondes pour un tableau de 2Mo... donc cela double le temps d'exécution et ramène le temps de génération du tableau dans le même ordre de grandeur que le tems d'écriture.



Donc en résumé :
-"tout VB" : temps d'écriture équivalent au temps de calcul
-avec la dll : temps de calcul infime devant le temps d'écriture.

Par conséquent, supprimer la dll revient à doubler le temps d'éxecution, ce qui n'est pas vraiment terrible.


Et comme dit Brunews, la dll ne pose pas de problèmes car il est d'ailleurs inutile de l'enregistrer (pas activeX) ==> suffit de la poser dans le App.Path. Donc pas gênante du tout au final.

Et elle permet de diviser le temps par 2 ! Gain énorme vu que la sanitization d'un disque est lente.



Merci encore pour les commentaires, @+

Commentaire de draluorg le 20/04/2007 16:15:47

re re,

Eh l'a fallu que je test...

j'obtiens des temps 7 * plus rapide qu'avec ta boucle en faisant ainsi:

Option Explicit

Private Declare Function GetTickCount Lib "kernel32.dll" () As Long

Private Sub Command1_Click()

    Dim lTim As Long
    Dim x As Long
    Dim l(5) As Long
    
    Call Randomize
    
    l(1) = Int(Rnd * 32)
    l(2) = Int(Rnd * 64)
    l(3) = Int(Rnd * 128)
    l(4) = Int(Rnd * 32)
    l(5) = Int(Rnd * 64)
    
    Dim tb(2097151) As Byte
    lTim = GetTickCount
    
    For x = 0 To 2097151 - 10 Step 10
        l(0) = Int(Rnd * 128)
        tb(x) = l(0)
        tb(x + 1) = l(0) + l(1)
        tb(x + 2) = l(0) + l(2)
        tb(x + 3) = l(2) + l(3) - l(0)
        tb(x + 4) = l(0) + l(1) + l(2)
        tb(x + 5) = l(3) + l(0) - l(5)
        tb(x + 6) = l(5) + l(0) + l(1)
        tb(x + 7) = (l(3) + l(0)) / 2
        tb(x + 8) = l(5) + l(0)
        tb(x + 9) = l(5) + l(2) + l(0)
        tb(x + 10) = l(0) / 2
    Next x
    
    lTim = GetTickCount - lTim
    
    Me.Caption = CStr(lTim)
    
End Sub

Bon d'accord c'est assez barbar mais c'est fait en 5 minutes et  justement c'est encore tres optimisable, et de 4,5 minutes on descend a 38 secondes! (compilé évidement!)

++

Commentaire de draluorg le 20/04/2007 16:50:54

eh non j'ai compté que ta boucle chez moi mettait 347 Ms
et la mienne 47 ms
C'est donc environs 7 * plus rapide, si je divise 4,5 minutes par 7 j'obtiens envorons 38 secondes...

atta je test avec 500 cycles...

Voila 36 secondes chez moi en faisant ceci:

Option Explicit

Private Declare Function GetTickCount Lib "kernel32.dll" () As Long

Private Sub Command1_Click()
    
    Dim lTim As Long
    Dim i As Integer

    lTim = GetTickCount

    For i = 1 To 500
        GenBytes
    Next i
    
    lTim = Round((GetTickCount - lTim) / 1000, 3)
    Me.Caption = CStr(lTim)


End Sub


Private Sub GenBytes()

    Dim x As Long
    Dim l(5) As Long
    Dim tb(2097151) As Byte
    
    Call Randomize
    
    l(1) = Int(Rnd * 32)
    l(2) = Int(Rnd * 64)
    l(3) = Int(Rnd * 128)
    l(4) = Int(Rnd * 32)
    l(5) = Int(Rnd * 64)
    
    For x = 0 To 2097151 - 10 Step 10
        l(0) = Int(Rnd * 128)
        tb(x) = l(0)
        tb(x + 1) = l(0) + l(1)
        tb(x + 2) = l(0) + l(2)
        tb(x + 3) = l(2) + l(4) + (l(0) / 2)
        tb(x + 4) = l(0) + l(1) + l(2)
        tb(x + 5) = l(3) + l(0)
        tb(x + 6) = l(5) + l(0) + l(1)
        tb(x + 7) = (l(3) + l(0)) / 2
        tb(x + 8) = l(5) + l(0)
        tb(x + 9) = l(5) + l(2) + l(0)
        tb(x + 10) = l(0) / 2
    Next x
    
End Sub

PS: J'ai un P4 aussi ;)

++

Commentaire de violent_ken le 20/04/2007 17:08:22

Bien sur, le graphe représente l'occurence en fonction du numéro de byte, échelle 0-255 en abscisse et 0-occurence max en ordonnée

@+

Commentaire de violent_ken le 21/04/2007 10:18:55

mwahaha ;)

Bon ben si tu es motivé, çà m'intéresse ^^
@+

Commentaire de EBArtSoft le 21/04/2007 11:40:40 administrateur CS

Bon j'ai fait mon petit bench vite torché, voila les resultat :

asm + dll : 156ms
asm + vb  : 109ms
rnd + vb  : 13375ms

asm + dll : 140ms
asm + vb  : 94ms
rnd + vb  : 13234ms

asm + dll : 156ms
asm + vb  : 94ms
rnd + vb  : 16312ms

Detail du bench :

    t = GetTickCount
    For i = 0 To 10
        n = bnAlloc2MoAlea()
        Call bnFreeAlloc(n)
    Next
    List1.AddItem "asm + dll :" & GetTickCount - t

    t = GetTickCount
    For i = 0 To 10
        Obj.bnAlloc2MoAlea Tbl(0)
    Next
    List1.AddItem "asm + vb :" & GetTickCount - t

    t = GetTickCount
    For i = 0 To 10
        For j = 0 To 2097151
            Tbl(j) = Rnd * 255
        Next
    Next
    List1.AddItem "rnd + vb :" & GetTickCount - t

Detail de la machine :

P4 1.6Ghz
1024 Ram

Conclusions :

J'obtiens de meilleur resultat avec de "l'assembleur embarqué" ceci s'explique par le fait que BruNews fait une alloc a chaque appel alors qu'il suffit de reutiliser le tableau dimentionné par VB. Ainsi le cout d'un appel a la propriete est minimisé face a l'allocation... bref si ça interresse j'ai le code :p

Commentaire de violent_ken le 21/04/2007 14:16:10

EB ==> Dsl, j'ai pas WLM d'installé (ni MSN) en ce moment car formatage pas très loin... ;)
Pour le code, oui çà m'intéresse, si tu peux le poster ce serait cool ;)

Et merci pour les bench, c'est bon à savoir...


Dralurog ==> 500 cycles en 5 secondes !! Grosse optimisation.
Pour l'analyse du niveau des tirages aléatoires, le plus simple est de comptabiliser le nombre d'occurence de chaque byte (http://www.enregistrersous.com/images/69389407420070420170612.jpg pour le premier cas).

Donc je confirme, ton dernier algo répartit correctement les bytes
http://www.enregistrersous.com/images/79659193820070421140643.jpg

Faudrait une étude plus poussée pour voir s'il n'y a pas de répétition de suites de bytes ou autre, mais c'est déjà vraiment mieux !

@+

Commentaire de draluorg le 21/04/2007 19:42:37

erf! lol 1,4 secondes pour 500 cycles! Chapeau bas monsieur!
Mais bon je pige rien de chez rien au code :(

Sinon avec methode en declarant tb() en global comme toi au lieu de le passer en byref a chaque fois je tombe a 2.2 secondes :P (bon ok je sors...)

++

Commentaire de violent_ken le 21/04/2007 22:08:31

WAOUH, tu es mon gourou EB !! ;)

Vraiment très fort... çà vaut le coup de faire un MAJ ^^
@+

Commentaire de violent_ken le 22/04/2007 13:47:21

Effectivement. Mais de toutes façons, je pense que la méthode la meilleure serait de faire un CopyMemory ==> plus de bug et plus rapide ;)

@+