COMBINAISONS DE STRINGS
Bacterius
Messages postés
3792
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
-
5 févr. 2010 à 15:20
JulioDelphi Messages postés 2226 Date d'inscription dimanche 5 octobre 2003 Statut Membre Dernière intervention 18 novembre 2010 - 10 févr. 2010 à 10:09
JulioDelphi Messages postés 2226 Date d'inscription dimanche 5 octobre 2003 Statut Membre Dernière intervention 18 novembre 2010 - 10 févr. 2010 à 10:09
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/51250-combinaisons-de-strings
https://codes-sources.commentcamarche.net/source/51250-combinaisons-de-strings
10 févr. 2010 à 10:09
Avec BarWF (http://3.14.by/en/md5) et un CPU double CORE, et une CG ATI (ATI Radeon HD 4870), on peut brute forcer un MD5 à hauteur de plus de 1 milliards de hashs testés à la seconde.
9 févr. 2010 à 19:48
De toute façon, le récursif c'est assez mauvais dans la plupart du temps. Je t'engage à rendre ton code linéaire au possible, et là le gain va être très important il me semble. Normalement, un brute force devrait pouvoir tourner à au moins 100 millions (voire 200) combinaisons par seconde, sur un tel bolide (3,2 GHz). Perso, quand j'ai essayé le code ASM (je l'ai vu aussi), je suis monté à 67 millions de tests par seconde, sur deux coeurs 1,8 GHz chacun.
Cordialeemnt, Bacterius !
9 févr. 2010 à 12:11
J'ai été sur asmfr et j'ai trouvé un brute-force beaucoup plus rapide que le mien :
http://www.asmfr.com/codes/FAST-MD5-CRACKER_40047.aspx
Le principe reste le même, et pourtant pour donner un ordre d'idées, j'execute environ
420 000 combinaisons par seconde avec un processeur de 3,2 Go (et sans traitements) contre
"presque 50 million de mots de passe par seconde" avec un processeur Intel Core 2 duo E6600 +
le traitement de comparaison de Hash MD5.
J'crois que je suis loin du compte avec ma fonction récursive.
9 févr. 2010 à 03:59
Scanline pointeurs rapidité
Le type String étant déjà régi à l'aide de pointeurs par Delphi (il me semble), c'est déjà assez rapide. Et sinon, on peut toujours utiliser un tableau dynamique d'octets (ou de caractères), mais il va falloir recoder la concaténation, tout ça, de façon rapide, alors bon ...
Mais de là à utiliser une image pour faire du brute force, non je ne pense pas que ça aiderait. Mais ce qu'est que mon avis, pourquoi pas ?
Cordialement, Bacterius !
8 févr. 2010 à 12:53
ScanLine serait-il plus rapide que les gestion de chaines de caractères ?
En utilisant 1 pixel = 1 caractère...
DH
8 févr. 2010 à 10:46
Merci pour ces précisions.
Je suis tombé par hasard sur le projet de distributed.net qui essaye un principe similaire, en utilisant plusieurs ordinateurs en réseau.
http://fr.wikipedia.org/wiki/Distributed.net
8 févr. 2010 à 04:07
"Comme tu l'as fais remarqué, l'application se gèle, et donc impossible de mettre en pause
le programme."
Tu peux inclure un compteur, qui s'incrémente à chaque combinaison, et toutes les dix mille combinaisons par exemple tu lances Application.ProcessMessages. Ainsi, la mise à jour de l'application ne prendra quasiment aucun temps de calcul, mais ton application répondera quand même (il suffit que l'application réponde toutes les 50 ms pour que ça soit fluide).
"sachant qu'avec un i7 on peut aller jusqu'à 8 coeurs,
penses-tu que cela apporte quelque chose ?"
Tu peux aussi prendre 16 coeurs, 32 coeurs ... 512 coeurs ...
Et à mon avis, le temps utilisé pour diviser le travail entre les processeurs, pour les faire communiquer entre eux, ralentirait le calcul plus qu'il ne l'améliorerait.
"ou est-ce tout simplement une illusion de penser pouvoir faire un brute-force plus rapide ?"
Oui, c'est une illusion. Le brute force n'est pas une solution en soi et il ne faut pas chercher à aller toujours plus vite. Tu peux bien sûr faire des petites merveilles d'optimisation, travailler sur trois cents supercalculateurs à la fois, etc ... mais il y a tout bonnement trop de combinaisons. Rien qu'en incluant que les caractères minuscules, sur une longueur de 10 caractères, on a déjà 26^10 141167095653376 combinaisons. Et si l'on travaille sur les caractères alphanumériques avec caractères spéciaux (le plus commun en vrai), on aurait 122^10 730463141542791783424 combinaisons. Et là, faut s'accrocher.
Cordialement, Bacterius !
7 févr. 2010 à 21:15
Je me posais justement la question pour "Application.ProcessMessages".
Comme tu l'as fais remarqué, l'application se gèle, et donc impossible de mettre en pause
le programme.
Je me posais une autre question par rapport à une eventuelle division de taches?
C'est à dire de diviser toute les combinaisons en plusieurs petites combi. :
de a > aaaa
de aaaa > aaaaaaaa
de aaaaaaaa> aaaaaaaaaaaaaaaa... etc...
Pour donner un processus différent à chaque "Core Processeur".
sachant qu'avec un i7 on peut aller jusqu'à 8 coeurs,
penses-tu que cela apporte quelque chose ? ou est-ce tout simplement une illusion de penser pouvoir faire un brute-force plus rapide ?
5 févr. 2010 à 15:20
pour gagner encore davantage en vitesse, supprimer la ligne "Application.ProcessMessages". Elle cause la mise à jour de l'interface graphique de l'appli, et traite les messages souris, clavier, etc ... si on l'enlève totalement, ça bloque l'appli pendant le travail, mais en général on ne l'exécute que tous les X itérations de l'algorithme, en choisissant bien X de sorte que l'application réponde quand même sans trop effectuer de mises à jour coûteuses.
Il y a également d'autres moyens d'optimiser ce code. Mais ne nous attendons pas à des performances exceptionnelles, pour un mot de longueur N, il y a 26^N façons d'arranger ce mot en utilisant les lettres de a à z, et on n'a pas compté les mots de longueur inférieure, qui sont eux aussi inclus, donc pour un mot de dix lettres, il y a déjà plus de 145 mille milliards de combinaisons ... c'est déjà hors de portée :'(
Cordialement, Bacterius !
PS : cet algorithme s'appelle aussi un brute-force alphabétique.