ALGORITHME DE BRUTEFORCE POUR LES CRACKERS
cs_juju12
Messages postés
966
Date d'inscription
samedi 3 avril 2004
Statut
Membre
Dernière intervention
4 mars 2010
-
5 juil. 2009 à 00:13
pianist1 Messages postés 1 Date d'inscription mardi 23 décembre 2008 Statut Membre Dernière intervention 7 août 2009 - 7 août 2009 à 15:03
pianist1 Messages postés 1 Date d'inscription mardi 23 décembre 2008 Statut Membre Dernière intervention 7 août 2009 - 7 août 2009 à 15: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/50262-algorithme-de-bruteforce-pour-les-crackers
https://codes-sources.commentcamarche.net/source/50262-algorithme-de-bruteforce-pour-les-crackers
7 août 2009 à 15:03
Merci d'avance.
20 juil. 2009 à 16:34
20 juil. 2009 à 10:36
Aidez moi svp
10 juil. 2009 à 19:08
10 juil. 2009 à 11:51
De toutes facons, il faut relativiser un peu : Meme en testant 1.000.000.000 cles/secondes (ce qui est beaucoup) il faudrait presque 50 ans pour essayer tous les mots de passes a 9 caracteres :o)
On pourrait facilement faire reculer cette limite avec un appel recurcif sans trop d'impact sur les performances (un appel de fonction tous les 49 ans, 57 jours et des brouettes ne vas pas ralentir notablement le programme :op ) mais je ne suis pas sur que ce soit le vrai probleme...
Bien qu'inutilisables dans la vraie vie, ces algos sont toujours assez interessants a optimiser, juste pour le fun.
Oh1234: A notre epoque, avec les smartcards et autres solutions a base de "keyfile" sur cle USB, un mot de passe peut faire bien plus que 107 caracteres (sans parler des solutions a base de "phrases de hash", mais pour craquer ces dernieres une attaque brute force sur la phrase n'est pas le moyen le plus efficace).
9 juil. 2009 à 22:40
Pour autant, avec un password de 12:
pow(105, 12) = 1795856326022129150390625
UINT64 max = 18446744073709551615
Cette méthode limite le password à 9 char maxi en bossant avec du UINT64, faudra pas le perdre de vue.
9 juil. 2009 à 21:23
9 juil. 2009 à 17:53
on a:
len = strlen(rotation);
donc possible 105 ici.
dans la boucle:
end = (long int) pow(len, j);
donc possible:
end = pow(105, 105);
qui donne 1.6783263083479555842921809575671e+212
ça rentrerait sur entier 64 bits ???
A moins de n'avoir rien compris à l'histoire, ça me semble du grand nimporte quoi.
6 juil. 2009 à 17:11
6 juil. 2009 à 17:10
6 juil. 2009 à 13:13
Il y a quelques bonnes idees, mais ca reste tres facilement ameliorable.
C'est dommage d'utiliser des % et des divisions (tres lentes) dans ta boucle.
Si ton jeu de caracteres a essayer avait la taille d'une puissance de 2 (par exemple 64), tu pourrais t'en sortir avec des >> et des & bien plus rapides.
Petit detail: Pourquoi dimensionner ton rotation a 200 ?
tu pourrais utiliser rotation[]. De meme, tu peux gagner un peu de temps en remplacant le strlen() par sizeof(rotation)/sizeof(char) (qui sera calcule a la compilation une fois pour toutes).
Tu peux aussi eviter de faire un pow (tres couteux) a chaque iteration:
Tu mets:
end=pow(len,j-1);
juste avant la boucle, et tu reemplaces ton ancien appel par:
end *= j;
Du coup, tu n'as plus qu'un seul appel a pow par execution et une multiplication par iteration (au lieu d'un appel a pow par iteration).
Voila, amuse toi-bien a optimiser tout ca !
Eric
5 juil. 2009 à 00:27
5 juil. 2009 à 00:25
5 juil. 2009 à 00:18
Ceci rendrait ton code plus intéressant je pense, car en l'état, force est de constater qu'il ne sert à rien.
5 juil. 2009 à 00:13
D'autre part, je ne vois pas l'utilité de ce code puisqu'il se contente d'énumérer les combinaisons alpha-numériques possibles, ce qu'on peut très bien faire directement à la main.