CptPingu, pour le coup du scanf("%s", &nomfichier), étrangement ça marche aussi (jamais compris pourquoi d'ailleurs, p't'être pour avoir une structure un peu uniforme pour les args de scanf; le compilateur doit détecter qu'on passe un char** et remplacer implicitement l'argument str par *str).

Bonjour;

if(3*d/n*n==3*d) im=3*d/n; else im=1+3*d/n;
peut être remplacé par simplement :
im=1+(3*d-1)/n;

D'un point de vue algorithmique, il n'est pas nécessaire de faire la boucle sur k; il suffirait par exemple de le calculer à partir de i et j
5ijk=n(ij+ik+jk) => k=(nij)/(5ij-n(i+j)),
puis regarder s'il y a égalité 5ijk==n(ij+ik+jk).
Ca diminuera le temps de calcul d'un facteur assez élevé! (bien que pour des nombres aussi petits je suppose que le calcul ne prend qu'un instant, mais bon, pour le principe, et si tu veux par la suite travailler avec des nombres arbitrairement grands...)


Voilà, c'est pas exhaustif, on peut toujours améliorer... mais bonne continuation.

pour ajouter, le seul intérêt éventuel aurait été d'épargner à l'utilisateur la tâche du test des mots de passe, autrement dit un code qui effectue lui-même la vérification sur le fichier ciblé (y a moyen de revenir à une durée de l'ordre de l'année alors probablement).
Ceci rendrait ton code plus intéressant je pense, car en l'état, force est de constater qu'il ne sert à rien.

"il est rapide"... t'as essayé de trouver un mot de passe, comme ça, juste pour voir? A raison de 5 sec. par tentative (faut bien les tester les mots générés), pour un mot de passe de 5 caractères (ce qui est peu), ça prendrait de l'ordre du millier  d'années... alors bon pour la rapidité on repassera je pense.

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.

au lieu de renvoyer une erreur si la matrice n'est pas symétrique :
Ax=b
tu peux multipier g/d par tA, la transposée de A :
=> Mx=c avec M=tA.A et c =tA.b

du coup M est symétrique et tu peux résoudre le système par la méthode GC.


suggestion bien entendu...

euh si on veut...
considère simplement que les arguments sont stockés l'un après l'autre dans une zone de mémoire spéciale (la pile, qui sert à contenir variables locales, arguments et adresses de retour).
Le compilateur ne fait pas de différence entre arguments fixes et arguments optionnels, lors de l'appel de la fonction il se contente de tout empiler.

petit exemple, pour appeler Sum(2,1,3) :
__asm
{
   ...
   push 3L;
   push 1L;
   push 2L;
   call dword ptr[Sum];  
   ...
}

Juste pour info, puisque tu dis avoir eu du mal à trouver, une petite variante pour l'utilisation d'arguments variables sans varlist :
il suffit de récupérer l'adresse mémoire du dernier argument fixe, de cette manière on peut accéder aux suivants par un pointeur.

par exemple, une fonction Sum(unsigned n,...) qui additionne n entiers :

unsigned Sum(unsigned n,...)
{
   unsigned *data=1+&n;
   unsigned i,result=0;
   for(i=0;i<n;i++) result+=data[i];
   return result;
}

et on peut appeler Sum(2,1,1) ou Sum(3,1,4,178) ou ...


c'est sans doute ce que fait varlist implicitement.

Une petite remarque:
lors de la libération de la dll (méthode remotethread), tu appelles FreeLibrary dans le contexte du processus cible mais en lui passant comme paramètre (via CreateRemoteThread) l'adresse de base de la dll...alors que FreeLibrary attend plutôt un handle sur le module (qui aurait éventuellement pu être récupéré par le code de retour du thread LoadLibrary)?! Quelque chose m'aurait-il échappé?

c'est exactement ce qu'il voulait dire : si tu entres 123 alors que tu es en base 2 alors comportement indéfini.

"si on veut empêcher tout modification" == "accessible en lecture uniquement"
non?

attention à la signification de 'portée' : il s'agit du domaine où l'on peut utiliser une variable, qu'elle soit ou non modifiable n'y change rien.

Sur ce, bonne continuation.