UTILITAIRE DE SANITIZATION DES DISQUES/FICHIERS (SUPPRESSION IRREMEDIABLE DES DO
shadowmoy
Messages postés
340
Date d'inscription
jeudi 25 juillet 2002
Statut
Membre
Dernière intervention
25 août 2007
-
15 avril 2007 à 20:19
ivensonsia Messages postés 1 Date d'inscription vendredi 27 avril 2012 Statut Membre Dernière intervention 21 mai 2012 - 21 mai 2012 à 16:14
ivensonsia Messages postés 1 Date d'inscription vendredi 27 avril 2012 Statut Membre Dernière intervention 21 mai 2012 - 21 mai 2012 à 16:14
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/42284-utilitaire-de-sanitization-des-disques-fichiers-suppression-irremediable-des-donnees-confidentielles
https://codes-sources.commentcamarche.net/source/42284-utilitaire-de-sanitization-des-disques-fichiers-suppression-irremediable-des-donnees-confidentielles
21 mai 2012 à 16:14
b = writeBytes(hFile, 0, _55buffer, CUInt(itemSize))
b = b And writeBytes(hFile, 0, _AAbuffer, CUInt(itemSize))
Using randomGen As New RandomGeneration(CInt(itemSize))
b = b And writeBytes(hFile, 0, randomGen.GetData, CUInt(itemSize))
End Using
If b Then
txt.Text = "Done."
Else
txt.Text = "Failed to write to file."
Marshal.FreeHGlobal(_AAbuffer)
Marshal.FreeHGlobal(_55buffer)
Return False
End If
Else
Dim lLastSize As UInteger = CUInt(itemSize - BUFFER_SIZE * (tMax - 1))
For y As Long = 0 To tMax - 2
b = writeBytes(hFile, y * BUFFER_SIZE, _55buffer, CUInt(BUFFER_SIZE))
b = b And writeBytes(hFile, y * BUFFER_SIZE, _AAbuffer, CUInt(BUFFER_SIZE))
Using randomGen As New RandomGeneration(BUFFER_SIZE)
b = b And writeBytes(hFile, y * BUFFER_SIZE, randomGen.GetData, CUInt(BUFFER_SIZE))
End Using
If b Then
tValue += 1
txt.Text = String.Format("Done : {0}/{1}", tValue, tMax)
Else
txt.Text = "Failed to write to file."
Marshal.FreeHGlobal(_AAbuffer)
Marshal.FreeHGlobal(_55buffer)
Return False
End If
My.Application.DoEvents()
Next y
b = writeBytes(hFile, (tMax - 1) * BUFFER_SIZE, _55buffer, lLastSize)
b = b And writeBytes(hFile, (tMax - 1) * BUFFER_SIZE, _AAbuffer, lLastSize)
Using randomGen As New RandomGeneration(CInt(lLastSize))
b = b And writeBytes(hFile, (tMax - 1) * BUFFER_SIZE, randomGen.GetData, lLastSize)
End Using
If b Then
txt.Text = "Done."
Else
txt.Text = "Failed to write to file."
Marshal.FreeHGlobal(_AAbuffer)
Marshal.FreeHGlobal(_55buffer)
Return False
End If
can somebody explain to me what is this mean?? please...URGENT.
24 mai 2010 à 12:15
Version .Net à jour ici : http://www.vbfrance.com/codes/UTILITAIRE-SANITIZATION-DISQUES-DURS-FICHIERS-SUPPRESSION-DONNEES-CONFIDENTIELLES_51792.aspx
@+
27 avril 2007 à 21:08
Note : ce code inclus dans ma nouvelle source : http://www.vbfrance.com/codes/FILESYSTEMLIBRARY-TOUT-FSO-SUR-FICHIERS-DOSSIERS-DISQUES_42404.aspx (la MAJ ce soir)
@+
22 avril 2007 à 13:47
@+
22 avril 2007 à 13:30
Pour Violent_Ken
J'ai remarqué que pour le conversion d'un currency en 2 long signés tu as supprimé le test sur le passage positif/négatif du mot de 32 bits High : cela n'est pas génant pour l'instant car nos disques durs sont encore trop petits mais dans quelques temps risque de bug !!!
Bravo à vous deux : je vous mets à tous deux un 10 mais il n'est que virtuel malheureusement
21 avril 2007 à 22:08
Vraiment très fort... çà vaut le coup de faire un MAJ ^^
@+
21 avril 2007 à 20:07
21 avril 2007 à 19:42
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...)
++
21 avril 2007 à 19:04
@
21 avril 2007 à 14:16
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 !
@+
21 avril 2007 à 11:45
"Mais par contre le résultat n'est pas convenable, la distribution des bytes n'étant pas pseudo-aléatoire" oui c'etait a l'arache juste pour montrer que en diminuant le nombre d'appel a rnd tu pouvais gagner enormement de temps...
Bon voici un autre exemple plus propre et plus aleatoire (500 cycles en 5 secondes!)
Private Sub GenBytes(ByRef tb() As Byte)
Dim x As Long
Dim i As Long
For i = 1 To 151
tb(i) = Int(256 * Rnd)
Next i
For x = 151 To 2097151 - 1000 Step 1000
tb(x) = Int(256 * Rnd)
For i = x + 1 To x + 1000
tb(i) = (tb(x) Xor tb(i - x))
Next i
Next x
End Sub
Clair que ca vaudra pas le code de Eb mais bon...
Sinon comment analyse tu le niveau "pseudo aleatoire" ? ca m'interesse!
++
21 avril 2007 à 11:40
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
21 avril 2007 à 11:13
@+
21 avril 2007 à 10:18
Bon ben si tu es motivé, çà m'intéresse ^^
@+
21 avril 2007 à 01:35
Surtout si on optimise la partie tableau pas tres bien foutue il faut l'avouer dans le projet original :p
@+
20 avril 2007 à 17:08
@+
20 avril 2007 à 17:06
Donc c'est 5 fois plus rapide que le Rnd*256.
Mais par contre le résultat n'est pas convenable, la distribution des bytes n'étant pas pseudo-aléatoire ==> (test effectué avec 2M valeurs)
http://www.enregistrersous.com/images/69389407420070420170612.jpg
@+
20 avril 2007 à 16:50
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 ;)
++
20 avril 2007 à 16:26
- attention aux dépassements de capacités notamment dans tb(x + 3) = l(2) + l(3) - l(0)
- j'avoue que je ne sais pas comment tu as fait le test ? Chez moi j'obtiens 223s, soient près de 4 minutes pour 500 cycles (compilé bien sur) ??? Tu es sur des 38s ?? (ou alors mon P4 fatigue vraiment ^^)
@+
20 avril 2007 à 16:15
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!)
++
20 avril 2007 à 14:04
Erf entre 2.5 secondes et 4.5 minutes, je veux bien que vb soit plus lent que de l'asm mais pas a ce point.
Ou tu es Eb ? montre nous que Vb peut etre plus rapide!
Ou alors je m'en va rejoindre Brunews sur le forum Cpp!! lol
Non vraiment je suis etonné quand meme de voir une telle différence!
Mais la ou je dis que je suis contre la dll, c'est que si on part de ce principe on ne va plus chercher la moindre optimisation en vb et on va recourrir chaque fois a une dll tierce...
Pour certaine appli on se retouvera vite avec 50 dll!
Et donc comme le dit Eb autant coder directement en C++
++
20 avril 2007 à 13:21
-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, @+
20 avril 2007 à 12:08
Source interessante!
par contre je suis de l'avis de Eb sur le tout en VB du moins pour cette source, car j'ai pas testé mais c'est quand meme ton dur qui ralentit le plus... non ?
Car le temps que tu genere ton tableau doit a peine laisser le temps au disque de se repositionner lol...
Enfin j'exagere, mais pour de l'ectiture sur dique je pense que Vb est suffisement rapide!
En tout cas c'est une tres bonne source! merci ;)
++
19 avril 2007 à 23:25
De rien
19 avril 2007 à 23:13
A mon humble avis c'est le contraire, VB est fait pour assembler des pièces logicielles, moins il y a de codage en VB et mieux c'est.
19 avril 2007 à 22:56
une application non professionnelle cela reste acceptable.Un grand bravo à Violent_Ken
18 avril 2007 à 19:26
Pour le "code louche", pas de problèmes, mieux vaut être prudent ^^
@+
18 avril 2007 à 18:23
18 avril 2007 à 08:35
non pas que son contenu soit un virus, trojan ou autre... mais là, l'utilisateur est prevenu qu'il ne s'agit pas d'un simple 'pong'...
18 avril 2007 à 01:17
(on ne parle de "Ce code" (donc là au masculin) qu'après :p
c'est la fatigue :D
18 avril 2007 à 01:16
faut revoir votre message, je suis pas très bon en grammaire, mais là (entre les chevrons) :
CETTE SOURCE EST MARQUE COMME LOUCHE PAR UN ADMIN, ET >>IL<< PEUT ÊTRE "DANGEUREU>>X<<" DONC PRUDENCE !
Qu'est ce qui est dangereux ? Dans le contexte, c'est la source ?
donc :
CETTE SOURCE EST MARQUE COMME LOUCHE PAR UN ADMIN, ET ELLE PEUT ÊTRE "DANGEUREUSE" DONC PRUDENCE !
(on ne parle de "son exécution" (donc là au masculin) qu'après :p
Voilà ;)
++
18 avril 2007 à 00:44
Dis moi tu as était récement controlé pour sorti une appli comme ca ;)
Hors mis cela ca me semble pas mal.
Have Fun ;)
17 avril 2007 à 14:05
Cela dit, les données sont bien évidemment définitivement effacées (avec les trois passes de réécriture).
@+
17 avril 2007 à 10:17
16 avril 2007 à 23:58
Merci Brunews
16 avril 2007 à 21:42
Par "louche" il faut comprendre "potentiellement dangereux", rien de plus.
16 avril 2007 à 21:37
Galain ==> C'est vrai que le "louche" est peut être pas le mot qui convient le mieux^^, mais bon, avec la msgbox qui s'affiche, le visiteur sera vraiment averti pour de bon ^^
Et merci encore pour le commentaire positif, çà fait plaisir ;)
@+
16 avril 2007 à 21:35
16 avril 2007 à 21:32
Je ne comprend point pourquoi ce code a été marqué comme louche par un admin : oui il est "dangereux" si on ne comprend point le but de ce code.Mais l'auteur a prévenu les visiteurs et leur fournit assez d'information pour comprendre le but de ce même code
Donc j'en conclus que le visireur qui teste ce code sait ce qu'il fait et est une personne averti!
Bravo Violent_Ken et dommage que je ne puisse pas noté un autre 10 pour cette source : chapeau bas
Galain
16 avril 2007 à 21:03
16 avril 2007 à 19:29
MadM@tt ==> Oui, je préfère prévenir ;) Faudrait pas qu'un utilisateur inatentif sanitize son disque dur par mégarde O_o
Et effectivement, le respect de la norme garantit une certaine efficacité du programme ^^
moustachu ==> Héhé, ma pauvre petite clé USB subit énormément de choses ces derniers temps... je viens de remarquer sur le screenshot : plus de 46Go d'utilisés dessus ;) lol, elle ne fait que 986Mo ^^
Pour l'histoire de l'écrasement, comme le dit zavier666, il est toujours possible, même si çà parait bizarre, de récupérer des données après formatage, et même après écrasement(s). Mais évidemment, l'opération est lente et doit être réalisée par des professionnels. Bien sur, on ne récupèrera que des "bribes" de fichiers.
Le meilleur moyen de supprimer définitivement les données est quand même l'utilisation d'un degausser (très fort champ magnétique qui supprime toutes les données).
"La programme le plus dangereux de VBFrance" ==> Je préfère prévenir ! Comme çà je suis tranquille ;)
Petite doc en anglais : http://www.usenix.org/publications/library/proceedings/sec96/full_papers/gutmann/
A noter qu'ici sont proposées 35 passes !
La conclusion indique que la sanitization n'est pas possible totalement, même avec un grand nombre de passes.
Mais bon, les 3 passes proposées ici sont généralement les plus utilisées car relativement efficaces.
Merci pour tous les commentaires, @+
16 avril 2007 à 18:16
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
16 avril 2007 à 15:03
Avec un titre comme ça je ne risque pas de tester ton prog ;o). As-tu usé beaucoup de disques durs avant de terminer ton prog ^^.
J'entends souvent dire "Même après formatage, on peut récupérer les fichiers".
Quand un fichier est supprimé puis écrasé par un autre (physiquement) comment peut on récupérer les données d'avant ? C'est naïf comme question, hein. On pourrait multiplier la capacité de stockage d'un disque alors ^^
Beau boulot (je pense). "La programme le plus dangereux de VBFrance" ça fait classe ! Je vais essayer de faire le plus innofensif :o)
++
Moustachu
16 avril 2007 à 14:30
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 !
16 avril 2007 à 00:34
j'en connais un autre : Eraser
16 avril 2007 à 00:29
Merci, @+
16 avril 2007 à 00:20
cette ligne est associée si l'on peut dire à celle-ci: mov eax, edx ;//on recommence
Le nombre aléatoire créé au mov edx,eax est réutilisé au mov eax,edx.
J'avais fait la présentation avec Notepad mais le site n'a pas gardé le format des lignes
Désolé
16 avril 2007 à 00:11
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+
15 avril 2007 à 22:59
@+
15 avril 2007 à 22:57
J'ai testé sur un disque dur en NTFS et cela fonctionne très bien
Un grand bravo
15 avril 2007 à 22:38
Mais comme la dll est en ASM et que je ne connais pas l'ASM, je n'ai pu que l'utiliser sans vraiment la comprendre O_o
Le code est en tout cas fourni dans le zip. Si tu es motivé... ^^
@+
15 avril 2007 à 22:19
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)
15 avril 2007 à 22:14
J'avoue que je suis curieux de voir une telle function ^^ Faut utiliser quel genre d'opérations ? (parce que j'avoue que je n'ai pas vraiment cherché à décortiquer l'ASM de Brunews).
@+
15 avril 2007 à 22:10
@+
15 avril 2007 à 22:06
15 avril 2007 à 22:06
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^^).
@+
15 avril 2007 à 21:59
15 avril 2007 à 21:56
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.
@+
15 avril 2007 à 21:49
(j'ai pas tout lu le truc de la norme alors je suis peut
etre sous informé :p)
15 avril 2007 à 21:46
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.
@+
15 avril 2007 à 21:41
15 avril 2007 à 21:22
300 fois plus rapide, la dll, 300 fois ^^
15 avril 2007 à 21:21
15 avril 2007 à 21:19
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 çà ^^
@++
15 avril 2007 à 21:05
15 avril 2007 à 21:04
La MAJ arrive dans 2 minutes ^^
@+
15 avril 2007 à 21:03
Au moins tu t'en rend compte tout seul c'est deja ça
:p
15 avril 2007 à 20:58
Là il y a de l'optimisation à faire!!
@+
15 avril 2007 à 20:57
15 avril 2007 à 20:56
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 ^^
@+
15 avril 2007 à 20:51
Je suis pour le 100% vb. Car si on ajoute des truc en C autant faire tout en C !
@+
15 avril 2007 à 20:48
-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)
@+
15 avril 2007 à 20:47
j'espere que tu comptes pas "remettre" des données sensible dessus c'est surtout ça la question :p
15 avril 2007 à 20:44
"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 !
15 avril 2007 à 20:40
Non sans blague un tableau d'entier aurait fait l'affaire et c'est bcp bcp plus rapide. je me trompe ? Non je crois pas :p
15 avril 2007 à 20:28
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
@+
15 avril 2007 à 20:19