[C] ALGORITHME BRUTE FORCE

Commentaire de Neo_Fr le 21/03/2007 11:30:48

Ouai j'avou sa serait mieux de pouvoir choisir une plage de caractere, je ferais bientot une maj...

Commentaire de BruNews le 21/03/2007 20:34:47 administrateur CS

La source propose une méthode de génération des différentes combinaisons, chacun peut en faire (pas sur CS) ce qu'il veut ensuite au lieu du simple printf.

Commentaire de Neo_Fr le 21/03/2007 22:44:17

Si je teste rien c'est parceque c pas le but du prog, je fourni juste la fonction de brute force avec un exemple des plus basic, a vous de vous en servir comme bon vous semble...

Je cherche juste des conseilles pour l'optimiser c tt...
(Pas la peine de me dire de virer printf je le mis juste pour l'exemple)

Pour medhi: je voit pas pourquoi des admins supprimeraient ma source je n'ai pas trouver d'algo brute force utilisant cette méthode, en plus quand je vois les dizaines de calculettes ou de pseudo-virus qui trainent....

Commentaire de mehdi7604 le 21/03/2007 23:29:59

meme les mots atachées à ta sources : bruteforce , motdepasse , générateur : ça n'a pas l'air d'etre inocent ;-) .

Commentaire de mehdi7604 le 22/03/2007 18:41:51

ok bonne chance :-)

Commentaire de BruNews le 25/03/2007 19:50:20 administrateur CS

Renomme le ex_ en exe et tu utiliseras à tes risques et périls.
Un exe direct dans le zip est supprimé au téléchargement, CS ne doit pas être tenu responsable en cas de virus.

Commentaire de LeFauve42 le 26/03/2007 18:53:53

Salut,

C'est mignon ton code, mais je ne pense pas qu'en pratique ca permette de casser quelque chose de plus de 5 ou 6 caracteres dans un temps "raisonable" :o)

Ceci dit, c'est plutot bien ecrit.

Voici quelques astuces pour l'optimiser un peu:
- D'abord, les realloc() sont a proscrire. Dans ton cas tu ne l'appelles pas souvant, mais c'est tres couteux, et en plus tu n'en as pas besoin. Il te suffit d'allouer un buffer de taille max, et de le remplir de zeros et hop, tu peux l'utiliser pour toutes les tailles.
- Ta boucle de mise en cascade des retenues pourrait etre beaucoup optimisee: En effet, tu la parcours du dernier caractere au premier. C'est generalement une bonne habitude quand la valeur max est le resultat d'une fonction, mais ce n'est pas le cas ici. De plus, comme il s'agit d'une retenue, les valeurs ne changent pas aleatoirement. Je dirais meme que ce sera toujours uniquement les "n" premiers qui vont changer, mais des que tu arrives sur une case sans retenue, il n'est plus possible que d'autres cases changent.

Donc, au lieu de parcourir tout ton tableau, tu peux le parcourir en partant du debut uniquement tant qu'il y a des debordements (valeurs >= 107)

- Un autre truc qui ne gagnera rien en vitesse, mais tu devrais utiliser un truc genre sizeof(ALL)/sizeof(char) au lieu de 107 (eventuellement tu peux faire un #define) pour que ce soit plus lisible. Tu ne perds pas de temps car c'est calcule a la compilation

- Pour calculer la plupart des fonctions de hash, tu utilises les caracteres de ton mdp du premier au dernier. Tu aurais donc interet a calculer ce hash pendant que tu construis ta chaine. Si tu te debrouilles bien, tu peux stocker les valeurs intermediaires et les reutiliser (ex: apres avoir calcule hash('aaaaaaaaaa'), tu peux rapidement recalculer hash('aaaaaaaaab)').

Evidemment, ca rend le code beaucoup moins lisible, mais c'est aussi ca la force brute :o)

En fait, pour la plupart des trucs de hash, tu n'as pas besoin d'avoir ton mdp stocke en memoire sous forme claire. Ce qui peut te faire gagner du temps (mais du coup, ton prog d'exemple avec printf() ne serait plus possible). L'ideal serait d'avoir un tableau d'int au lieu de char. Ca prendrait plus de place, mais le proc adresserait alors des cases memoires multiples de 4 ce qui le ferait aller plus vite (les procs modernes n'aiment pas les adresses impaires).

Enfin, ce genre de progs est parmis les quelques programmes qui gagnent encore a etre ecris en assembleur, donc sorti de l'aspect "didactique", je te deconseillerais donc de l'utiliser dans le vrai monde.

Sinon pour repondre a ta question, tu ne gagnerais pas grand chose en faisant calculer les mdp par un thread et le hash par un autre.
L'ideal serait de couper le nombre de possibilites a tester en deux (ou plus si tu as plus de cores sur ton proc) et de donner a chaque thread une partie des calculs a effectuer.
Attention, sur un monocore, ca n'apportera rien, et ca prendra sans doute legerement plus de temps.

Comme tu affiches le temps, je suppose que tu as du noter les perfs de ton programme.
Je serais currieux de savoir combien l'optimisation de la boucle des retenues te fais gagner.

Bonne chance,
Eric

NB: Ca me rappelle ma jeunesse quand on se tappait la bourre pour les calculs de nombre premiers avec les potes :o)

Commentaire de Neo_Fr le 31/03/2007 14:33:29

Merci de tes conseils lefauve,
- Pour les realloc je ne pensse pas qu'ils ralentissent vraiment
le prog etant donné que je l'appelle tres peu souvent, mais peut etre qu'un malloc, free a chaque fois serait plus rapide?

- J'ai légerement améliorer la boucle d'incrémmentation,
dès que je trouve un 0, je sort de la boucle...

- Que veut tu dire par "Tu aurais donc interet a calculer ce hash pendant que tu construis ta chaine." ?
Tu veut dire de faire la comparaison pendant la génération du mdp (a la place de printf), si c'est le cas c ce que j'ai fait

- Et sinon est-ce que tu pourrait m'expliquer l'histoire du tableau d'int, je vois vraiment pas comment je pourrais faire
pour récupérer le mdp "en clair" pour pouvoir le hasher ensuite.

Merci

Commentaire de Neo_Fr le 08/05/2007 12:27:44

Merci d'avoir corriger les bugs