pour JS8 moi j'aurais voulu faire des boucles de boucles mais **No Sms** possible. (car je ne ve pas 26*6 opérations mais 26^6 opérations :-) )
C'est le cas, 6 boucles imbriquées de 26 passages ça fait bien 26^6 traitements au final
1 Le C++ ne sait pas ce qu'est une boucle
Le C++ connait for(;
, "for" est une instruction de bouclage donc C++ connait les boucles, manquerait plus que ça on serait bien emm3rdé
2 Ce que tu dis est possible avec un dico
Eh ouais mais encore faut-il être sûr que la solution sera dedans (ça fait référence à l'épreuve de JavaScript n°8 hein, y'a tout un débat dessus sur le forum) donc avoir un bon dictionnaire, et puis c'est à mon avis plus interressant de coder un brute-forcer où on est obligé de retranscrire l'algorithme de vérification à l'origine en JavaScript en C ou en C++, mais sur le fond c'est clair que ça va plus vite, autant tester cette méthode en amont pour peut-être gagner du temps.
1 Le C++ initialise une variable, définit une butée, et fait une (ou plusieurs) action(s) (en general incrementation)
En brut c comme si tu ecrivais:
@debut
i=0
...code...
if (butée atteinte) jump fin
i++
jump @debut
@fin
c'est beau l'algorithmie...
En somme ça veut dire (et c'est assez faux également, faut le savoir) qu'une fois compilé, le code machine préfèrera un code du style :
mov cx, 0
@debut
[traitement]
cmp cx, butee
jz @suite
inc cx++
jmp @debut
@suite
...
plutot que :
mov cx, butee
@debut
[traitement]
or cx, cx
loopnz @debut
...
Qui fait gagner à la fois des instructions et du temps machine (si si, "loop" fait gagner du temps machine depuis le 80486
)
Hors la plupart (pour ne pas dire la totalité) des compilateurs aujourd'hui génèrent un code dit "optimisé" et même si c'est pas toujours vrai, la première implémentation en tant que telle ne peut absolument pas être considérée comme optimisée, c'est une abstraction algorithmique qui ne prend pas en compte la réalité des cycles d'horloges et du temps d'exécution des instructions sur les processeur à base de jeu Intel.
tout le monde aura compris qu'un while et preferable dans ce genre de traitement ou le nombre d'operations est inconnu.
Héhé, l'idée est là, mais pareil, il s'agit (à mon avis) de sortir une liste des solutions possibles sans pour autant les valider à chaque fois et pour cause, on a que deux moyens pour valider la solution; faire des requêtes directement sur le site et récuperer le cas échéant un code HTTP 200 ou 404 (j'ai essayé il n'a pas aimé), selon le langage utilisé c'est pas gagné parcequ'il faut également se cogner la communication HTTP avec les cookies etc.
Ou alors passer la liste des solutions trouvées par force brute au dico et on en revient toujours à la même chose, avec un peu de chances on aura la bonne solution dans le dico mais rien de sûr.
De plus, utiliser directement un dictionnaire fera gagner beaucoups de temps dans la foulée, donc l'opération de brute-forcing ne sert à rien...
Pour en revenir à ça, et dans ce sens, un while ne sert pas à grand chose vu que le traitement n'est censé s'arreter que quand la liste est totalement crée... Dans la pratique on peut afficher les résultats en même temps que le programme cherche et tomber sur la solution par hasard tandis que le code tourne encore, auquel cas on peut (voire on est plus ou moins obligé même si c'est pas propre) vérifier le clavier et dès qu'une touche est enfoncée avoir un GOTO qui nous rebalance à la suite du code (ouai parcequ'un break suffira pas là dans plusieurs FOR imbriqués) ou effectivement tout passer sous condition while et rajouter une condition, mais on perd à chaque vérification de la condition énormément de temps également et si la structure est un peu plus correcte ou plutot conventionnelle, il n'en reste pas moins que c'est un peu lourd comme code au final...
En somme le dictionnaire selon moi c'est à tester en premier lieu, avec un balez de dico, ptet ça passe, mais à l'origine on est pas censé savoir que le mot qu'on cherche est compréhensible, donc dans tous les cas c'est pas une très bonne solution. Les attaques par force brute étant ultra grillées dans un contexte réel, il y a très peu de cas où celà s'applique de manière réellement efficace.
(J'en ai trouvé une dernièrement, sur un site vulnérable, lequel m'affiche la liste d'utilisateurs (fixe) du site mais pas les mots de passe, sachant que le site va sans doute pas bouger, ça vaut le coups de brute forcer le compte d'un utilisateur en prenant bien soin d'espacer les requêtes pour éviter de se faire détecter par les logs ou les sondes d'intrusion, et encore... il suffit que les mots de passes soient renouvelés fréquemment et/ou qu'il fasse genre un minimum de 6 caractères alphanumériques avec caractères spéciaux "*!$%?-#&" et on est pas pret de mettre la main dessus...)
BufferBob.