Cette version est périmée, je pourrai vous envoyer la nouvelle d'ici quelques temps, actuellement je suis en vacances, et je n'ai pas accès à mes sources.

k = (c1 ^ c2) * c3;

si ton bloc est "abc" ou "bac" le résultat sera le même. Donc non, tu n'as pas une solution unique pour tous les cas (alors que tu pourrais techniquement l'avoir bloc par bloc).

Ensuite, pourquoi ne pas simplement convertir la valeur de k en une chaine hexadécimale, au lieu de faire le modulo/+33 ? C'est ce qu'on utilise, généralement, et ca te permet de conserver la valeur entière (qui est plus rapide à comparer qu'une chaine) et de travailler avec de plus grands blocs.

Pour aller plus loin, tu pourrais hasher les blocs résultants jusqu'à n'en obtenir qu'un certain nombre (et donc avoir une longueur fixe, comme l'a mentionné neo_fr)

non, c'est juste que les 3 touches sont placée l'une à côté de l'autre, et que j'ai l'habitude de signer oli, du coup ben c'est un réflexe...

Premier comment : oui, et la version en arbre gèrera les parenthèses.
Deuxième comment : si tu veux, c'est utilisé comme tel
Troisième comment : je sais et oui ^_^ enfin, ça gère toutes les chaines en C like... Si tu veux faire un test plus facile à comprendre, change la ligne 183 du main en
oli.Code = //code;
Ca prendra la chaine juste en dessous comme script, ce sera plus facile pour la compréhension, puisque plus court. Et tu verras par la même occasion que la chaine est parsée correctement.

Le parser sort une suite de lexèmes, plus exactement dans un map dont l'index est la position du lexem.
Pour spécifier la syntaxe, un exemple est donné dans le main. Comme je l'ai déjà dit, une documentation arrivera d'ici peu.
Expressions arithmétiques/logiques, tu penses à quoi ?

Quant à la version en arbre, je travaille actuellement sur la façon dont ce sera rendu, donc je ne préfère pas répondre encore.

Bien sûr que c'est a but pédagogique. Ma remarque était plus d'ordre disons éthique, pas du tout une critique sur le bien fondé de poster cette source.
Mais c'est quand même fort étonnant que le système puisse ainsi cacher n'importe quel processus. Cacher un processus sensible, fort bien, mais logiquement ces processus sont par défaut cachés par Windows, puisque logiquement ces même processus font partie intégrante de Windows (en espérant être clair...).

Enfin bref, c'est vrai que ça peut être fort utile dans beaucoup de cas.

C'est quand même vachement limite... Pourquoi Windows laisse faire ça ? A mon avis la plupart des progs qui se cachent sont plutôt des virus non ?

rol ? ror ? Qu'est-ce que c'est ?

Je m'incline. Je lirai ça en détail après mes examens :-S

Merci pour les infos. C'est clair que le hachage est lent, mais je proposait ça si vraiment on veut ou doit vérifier l'intégrité du fichier... Personnellement je ne vérifie jamais. C'est selon moi la façon de faire la plus safe et c'est cela que je voulais exprimer.

Réaliser des fichiers qui ont la même clef... Es-tu sûr que ce soit si simple ? Quoi qu'il en soit, pour la vérification, je pense que cela deviennte difficile de créer une clef qui donnera un fichier décrypté ayant le même hash...