Écrire un keygen pour Nanosaur, Bugdom, Otto Matic, etc.

Mettez à disposition vos propres cours de cracking ou des cours que vous trouvez intéressant.

Écrire un keygen pour Nanosaur, Bugdom, Otto Matic, etc.

Messagepar coucoupoulet » 15 Juillet 2013, 23:36

Introduction

Salut ! Je suis nouveau dans le monde du crack, mais étant programmeur et ayant toujours adoré "fouiner" dans le fonctionnement des logiciels, je saute enfin le pas !

Je me suis mis en tête de cracker des jeux auxquels je jouais en version d'essai quand j'étais plus jeune sur Mac. Quiconque ayant eu un Mac dans la fin des années 90 se souviendra de Nanosaur et Bugdom ! Heureusement, ils ont porté les jeux sur Windows depuis ; comme ça, je pourrai utiliser OllyDbg 2.01h confortablement dans une VM. La flemme de chercher un debugger antique pour Mac OS 9.

J'avais envie d'écrire un keygen car je trouve que c'est plus propre de laisser l'exécutable intact.

J'ai mis un samedi entier à décortiquer Nanosaur et à écrire un keygen. Ensuite j'ai mis une heure le lendemain à adapter le keygen à tous les autres jeux de cet éditeur ; il n'y a pas grand chose qui change entre chaque jeu. Donc finalement une journée + une heure pour un keygen valable sur 12 logiciels, c'est rentable non ? :D

Les jeux sont téléchargeables là : hxxp:\\ifdgames.com\pub\win ; retapez l'URL correctement à la main. Ce qui nous intéresse est nanosaur_install.exe, installez-le.

(Avertissement : ça va être long et détaillé !)

Trouver la routine de validation

Nanosaur demande :
- un nom
- le serial
- un "order number" (numéro de commande)

C'est présenté dans une boîte de dialogue Windows standard avec trois champs pour entrer du texte. C'est le seul endroit du jeu où il y a des champs de texte, donc rien de sorcier pour trouver la routine de validation : suffit de trouver les appels à GetDlgItemText ou similaire.

J'entre n'importe quoi dans les 3 champs, je clique sur "Validate", et le message bad boy apparaît. Dans Olly, je mets en pause. Attention, l'exécution a sûrement été arrêtée dans une routine d'attente de Windows et Olly affichera le code de ntdll, donc il faut repasser dans le module Nanosaur.

Une fois que j'ai le code de Nanosaur devant les yeux, je fais "Search for all intermodular calls" (car c'est le module Nanosaur qui appelle GetDlgItem, qui est dans un module quelconque de Windows). Pas de surprise, trois appels à USER32.GetDlgItemTextA, dont le premier est à l'offset 4291e6.

Entre 4291e6 et 42928d, les traitements ne sont pas super intéressants. Ce qui nous intéresse c'est surtout "CALL 43eb8d", à l'offset 429290. On sait que c'est cette routine qui teste le serial car, juste après le CALL, Nanosaur affiche le message bad boy si EAX contient zéro. Donc on note qu'à la fin de la routine de vérification, EAX sera le flag de validation du serial.

Entrée dans la routine de validation : rencontre avec la structure "[NANO]" [43eb8d]

Un argument est passé à cette routine 43eb8d, que Nanosaur s'empresse de stocker dans ESI. C'est un pointeur vers une zone mémoire qui commence par le texte "[NANO]".

Cette zone est beaucoup référencée par la suite : Nanosaur va chercher pas mal de trucs à X octets après "[NANO]". Je suppose que, dans le code du jeu, cela correspondait à une structure C. Pour faire court, dans la suite du tuto, quand je dis "NANO+X", ça fait référence à X octets après le début de cette structure.

On peut déjà noter que notre nom est stocké à NANO+0x12C, et notre serial est stocké un peu plus loin à NANO+0x1AC.

Préparer le compound [43eba3-43edb9]

Entre 43eb8d et 43ecfa, Nanosaur construit ce que j'appelle le "compound", qu'il va manipuler pour vérifier le serial. En gros, le compound, c'est votre nom en majuscules et sans les espaces, suivi de la représentation ASCII de l'order number. Si le tout fait moins de 8 caractères, Nanosaur complète avec 0x5D (']').

Par exemple : si votre nom est "jean" et votre order "9", le compound sera "JEAN9]]]".

Le compound est stocké à NANO+0x12A, à l'envers ! Pourquoi ils le rangent à l'envers ? Aucune idée, car cela n'a aucune incidence sur la vérification du serial par la suite. C'est peut-être pour obfusquer, mais dans ce cas c'est naze car le nom qu'on a entré se trouve juste après, en NANO+0x12C... bref, faut pas chercher.

Au passage, en 43ed07 et 43ed0e, Nanosaur regarde si votre nom est "BETA" ou "DEMO" et fait quelque chose de spécial dans ce cas-là. J'avais la flemme de regarder ce qu'il fait, mais si vous avez envie d'investiguer vous avez l'adresse où chercher.

Si le nom n'est ni BETA ni DEMO, il saute à 43edbf et c'est là que ça devient intéressant : on commence à calculer des hashes magiques.

Hasher le compound [43edbf-43ee19]

Nanosaur calcule un hash du compound et le stocke en LOCAL.13. Voici ce qui se passe :

En 43ede7, il copie la valeur de NANO+0x238 dans LOCAL.13. Je *suppose* que c'est la constante 0x11, car ça n'a pas bougé après beaucoup d'essais. En d'autres termes, on initialise le hash avec la valeur 0x11.

Ensuite, [43edee-43edfc] est une boucle toute conne qui ajoute la valeur de chaque octet du compound à LOCAL.13. Il part du dernier octet du compound à l'envers, puis remonte jusqu'à tomber sur 0x00, qui marque la fin du compound.

Pour finir, il fait le modulo de LOCAL.13 par 0x1D (constante stockée en NANO+0x23C) et stocke ça dans LOCAL.13. Cet octet sera le hash qui va servir plus tard pour saler le serial.

Vérifier la longueur du serial [43ee20-43ee39]

Après avoir hashé le compound, Nanosaur vérifie la longueur du serial. Je vous résume : le serial doit faire entre 19 et 23 octets, et en pratique ils feront 19 octets (on verra pourquoi).

Si le serial a une autre longueur, on saute à 43ef76, que j'ai annoté "HahaNoWayInHell" dans mon désassemblage car ça met EAX à zéro et retourne à la routine mère, qui, rappelez-vous, affiche le message de bad boy si EAX est zéro.

Mais pourquoi faire simple quand on peut faire compliqué ? Voici une reconstitution de leur algo de vérification de longueur du serial...

4 == ((0xCCCCCCCD * (length+1)) >> (32+2))

Cette expression est vraie pour les valeurs de length entre 19 et 23. Bref, continuons...

Hasher le serial [43ee48-43eef4]

Une fois qu'il sait que le serial a la bonne longueur, il entre dans une boucle qui itère sur 4 blocs de 4 octets du serial et qui a pour but de produire un hash du serial.

Chaque bloc est séparé par un caractère "junk" ignoré par l'algo de vérification. Si je schématise, le serial a cette forme :

XXXX-XXXX-XXXX-XXXX

On retrouve bien nos 19 octets. Chaque "XXXX" constitue un bloc et les "-" sont ignorés. Ici j'ai mis des "-" mais si ça vous amuse de séparer les blocs avec des "@" ou des "!", lâchez-vous.

Les 4 octets de chaque bloc sont passés à la routine 43e8c6. Celle-ci génère deux mini-hash d'un octet chacun, et qu'on stocke en mémoire. Mis bout à bout, on obtient ainsi un hash de 8 octets.

En plus de générer ces deux mini-hash, la routine calcule un 3ème mini-hash temporaire. C'est une restriction supplémentaire sur la forme du serial. Ce 3ème mini-hash doit être égal à "0x15 AND PremierOctetDuBloc", sinon le serial est invalide et on nous éjecte vers HahaNoWayInHell.

Je ne vais pas expliquer l'algo de la routine 43e8c6 en français, ce serait trop long, alors voici une reconstruction en Python :

Code: Tout sélectionner
def check4(buf):
   # buf est un tableau de 4 octets du bloc à vérifier
   A = buf[0] & 0x0F   # NB: '@'&15==0, 'A'&15==1,... 'O'&15==15
   B = buf[1] - 0x30   # NB: '0'==0x30
   C = buf[2] - 0x30
   D = buf[3] & 0x0F

   x = A-((D+B)%5)
   if x < 0:
      x += 10

   minihash1 = (x*10+B) & 0xff
   minihash2 = (C*10+D) & 0xff

   # sxbyte() est une reconstitution du sign-extend d'un octet en x86
   minihash3 = sxbyte(minihash1) + sxbyte(minihash2)
   minihash3 %= 5
   minihash3 += x

   # en base 10, remplacer le chiffre des unités par 0 (ex: 185-->180)
   x = (minihash3//10) * 10
   if minihash3 < 0:
      x += 1
   minihash3 -= x

   if A != minihash3:
      # invalide, renvoyer vers HahaNoWayInHell
      raise Exception

   return minihash1, minihash2


Pour ceux que ça intéresse, là j'ai simplifié la division par 10, mais en réalité elle est obfusquée de façon hallucinante. Ils s'y prennent comme ça dans le code :

(0x66666667 * x) >> 34

Je sais pas comment ils ont trouvé ça, mais j'ai testé et ça semble diviser par 10 à tous les coups pour des valeurs raisonnablement petites.

Saler le hash du serial (round 1) [43ee9c-43eee9]

On a hashé le serial, ce hash fait 8 octets. Mais ce n'est pas fini, ce hash doit être salé avec le hash du compound (1 octet calculé plus haut) et avec une suite constante de 8 octets, 0x1e034f3424572f35, présente à NANO+0x8C. J'appelle cette suite "le sel".

(Techniquement, le salage est fait progressivement, bloc par bloc, après chaque appel à la routine 43e8c6, mais pour simplifier je vais expliquer le procédé comme si on le faisait *après* avoir obtenu le hash de 8 octets.)

Voici le code Python reconstituant le processus de salage :

Code: Tout sélectionner
# serhash : tableau de 8 octets représentant le hash du serial
# comhash : hash du compound (1 octet)
# salt    : tableau de 8 octets représentant le sel

for i in range(0,8):
   serhash[i] += comhash - salt[i]
   if serhash[i] < 0:
      serhash[i] += 0x5e


Saler le hash du serial (round 2) [43eefa-43ef4c]

Nanosaur sale une deuxième fois le serial, cette fois-ci avec les derniers octets du compound. Pour être exact, il utilise les octets du compound à partir de l'indice 8.

Par exemple, si le compound est "NANOSAUR1337", il n'utilisera que "1337" pour faire ce second salage.

Ainsi, si le compound fait 8 caractères, il n'y aura pas de deuxième salage (je rappelle que le compound fait 8 caractères minimum, si l'utilisateur a entré un truc trop court, c'est complété avec des ']'). Mais je suis perfectionniste alors j'ai décidé d'étudier quand même le deuxième salage. Comme ça, mon keygen pourra générer des serials pour des noms de plus de 8 caractères.

Voici une reconstitution de l'algo du deuxième round de salage en Python :

Code: Tout sélectionner
for i in range(0,8):
   for j in range(8+i, len(compound), 8):
      serhash[i] += comhash - compound[j]
      if serhash[i] < 0:
         serhash[i] += 0x5e

Pour résumer, les deux phases de salage peuvent être simplifiées en un seul programme python :

Code: Tout sélectionner
def salt_byte(byte, grain):
   byte += comhash - grain
   if byte < 0:
      byte += 0x5e
   return byte
   
for i in range(0,8):
   h = serhash[i]
   h = salt_byte(h, salt[i])
   for j in range(8+i, len(compound), 8):
      h = salt_byte(h, comhash)
   serhash[i] = h


Tour de magie final [43ef4e-43ef4c]

Faisons le point. À ce niveau, si on n'a pas encore été virés vers HahaNoWayInHell, on est déja bien :

  • on a fait le compound
  • on a hashé le compound (--> 1 octet)
  • on sait que le serial a la bonne longueur (généralement 19 octets)
  • on sait que le serial suit une règle cohérente (adéquation 1er octet de chaque bloc <--> 3ème mini-somme)
  • on a hashé le serial
  • on a salé le hash du serial une fois (avec 0x1e034f3424572f35)
  • on a salé le hash du sérial une deuxième fois (avec les octets du compound)
Donc on a un beau serial et un beau hash salé, mais on n'a pas encore vérifié si tout ça est en adéquation avec le nom et l'order number que l'utilisateur a entré.

C'est tout con ! Après tout le salage, il suffit que le hash salé soit égal aux 8 premiers octets du compound !

En gros, si notre compound était "JEAN9]]]" (soit 0x4a45414e395d5d5d), on doit retomber sur un hash salé ayant la valeur 0x4a45414e395d5d5d. Magique !

Si ce n'est pas le cas, on est viré vers HahaNoWayInHell ; sinon, EAX est mis à 1, on retourne, et le message good boy apparaît.

Le plus dur est fait, il ne reste plus qu'à écrire le keygen.


Écrire le keygen

Pas de solution miracle, on va être obligé d'écrire un keygen qui marche par force brute. Si vous avez une solution plus élégante, n'hésitez pas à m'en faire part.

Le principe sera de générer toutes les combinaisons de serial possibles jusqu'à ce qu'on en trouve une qui soit valide. On a déjà décortiqué l'algorithme de validation, donc c'est du gâteau.

Heureusement, les blocs de 4 caractères sont validés indépendamment les uns des autres. Du coup, on peut procéder bloc par bloc, ce qui réduira largement le temps de calcul.

Pour générer les combinaisons de 4 caractères, il est intéressant de rappeler les traitements appliqués aux caractères d'un bloc au tout début de la routine 43e8c6. Je vous remets le code Python reconstitué :

Code: Tout sélectionner
   # buf est un tableau de 4 octets du bloc à vérifier
   A = buf[0] & 0x0F   # NB: '@'&15==0, 'A'&15==1,... 'O'&15==15
   B = buf[1] - 0x30   # NB: '0'==0x30
   C = buf[2] - 0x30
   D = buf[3] & 0x0F

C'est intéressant car ça nous donne des limites pour éviter de cruncher des combinaisons inutiles comme des malades.

Comme on applique "AND 0x0F" aux octets #0 et #3 d'un bloc, on peut éviter de générer des blocs redondants en définissant une fourchette allant par exemple de 'A' à 'A'+0x0F (soit de 'A' à 'P').

Ensuite, on retranche 0x30 (soit le code ASCII pour '0') aux octets #1 et #2 d'un bloc. Ça veut dire que la fourchette pour ces octets démarrera au caractère 0x30, mais on n'a pas vraiment de limite supérieure. Une solution serait de se cantonner à l'ASCII 7-bits, donc de '0' à '~' (0x30-0x7E)... Mais ça fait beaucoup. Ça m'étonnerait d'ailleurs que le keygen des auteurs originaux utilise vraiment un mélange de caractères minuscules et majuscules. Donc on peut fixer une limite plus raisonnable, de '0' (0x30) à 'Z' (0x5A).

Si on est *vraiment* perfectionniste, on peut encore mieux choisir ses jeux de caractères, car il peut y avoir des confusions genre "Il1" ou "O0". Pour le jeu de caractères des octets #0 et #3, on peut prendre par exemple "PA23456789JKLMN?", car déjà ces caractères sont lisibles, et en plus si on AND tout ça par 0xF (=15), on obtient 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15. Pour les octets #1 et #2, c'est un peu plus freestyle, alors je propose '23456789ABCDEFGHJKLMNPQRSTUVWXYZ', ces caractères se distinguent bien.

Expérimentalement j'ai découvert qu'on peut restreindre les deux jeux à '0123456789' et ça marche toujours sans problème.

Keygen pour Nanosaur, c'est fait !

Adapter le keygen à Bugdom 1 et Bugdom 2

On ne va pas s'arrêter sur une si bonne voie ! Essayons un autre grand classique des jeux Mac, des mêmes auteurs : Bugdom. À l'époque j'avais le premier modèle d'iMac et il y avait juste Nanosaur dessus... quand j'ai vu les nouveaux modèles d'iMac, où Bugdom était pré-installé, j'étais jaloux de ne pas l'avoir :( J'ai joué à la démo de Bugdom pendant des heures et je n'ai jamais eu le jeu complet !

Téléchargeons et installons bugdom_install.exe. La fenêtre d'enregistrement est exactement la même : on nous demande un nom, un serial, et un numéro de commande. Essayons notre keygen dessus, on ne sait jamais... bon, sans surprise ça ne marche pas.

Ouvrons-le dans Olly... Tiens donc, c'est exactement le même algo ! Les instructions sont exactement les mêmes. Toujours la même structure "NANO" sauf que là le marqueur de début est "[BUGDOM_1]", mais tous les éléments sont au même endroit en mémoire. Après une investigation de quelques minutes, le seul truc qui change est le salt de 8 octets, qui devient ici 0x1e041357244b2b1d.

Dans le keygen, si on remplace le sel de Nanosaur par celui-là, bingo ! Les verrous de Bugdom sautent.

Allez, on en essaie un autre... Bugdom 2. Là encore la routine de validation est identique. Le sel est ici 0x1e0949242b1b335f. Suffit de le mettre dans le keygen et ça passe !

Adapter le keygen à Otto Matic, Enigmo 1, Enigmo 2, Nanosaur 2, Billy Frontier

Là ça devient carrément de la gourmandise car je m'attaque à des jeux auxquels je n'ai jamais vraiment joué. C'est plus pour le fun du crack que par réel besoin.

Essayons Otto Matic. Sans surprise, le sel est différent (0x1e0a3b2551180a2d), mais bizarrement notre keygen ne fonctionne plus.

L'algo de validation semble être identique à celui de Nanosaur aux premiers abords. Hop, un breakpoint au cœur de la routine de validation pour voir ce qui s'y passe. Un coup d'œil dans la structure NANO en mémoire (qui démarre ici par le marqueur "[ottomatic]"), et on s'aperçoit que le compound n'est pas construit de la même façon.

Rappelons-nous : avec Nanosaur, si j'entre "JEAN" comme nom et "9" en numéro de commande, je m'attends à voir apparaître "JEAN9]]]" à l'envers ("]]]9NEAJ") aux environs de NANO+1AC. Mais avec Otto Matic, ce qui apparaît c'est "))))NEAJ". Tiens donc... L'order number n'apparaît plus en clair et on ne complète plus avec des ']'.

Honnêtement, j'avais la flemme de lire le code assembleur qui faisait ça, donc j'ai joué avec des valeurs différentes. C'est moins scientifique mais ça va plus vite. Voici le résultat de quelques essais :

  • "JEAN", "8" --> "((((NEAJ"
  • "JEAN", "9" --> "))))NEAJ"
  • "JEAN", "10" --> "****NEAJ"
  • "JEAN", "11" --> "++++NEAJ"
Hmmm... Ces caractères se suivent en ASCII ! "(" est 0x28, ")" est 0x29, etc. Donc est-ce qu'il suffit d'ajouter 0x20 à l'order number pour obtenir le caractère de remplissage ? Pas si vite : avec "JEAN" et "16", on obtient " NEAJ" (4 espaces suivis de NEAJ – le HTML bouffera probablement les espaces). L'espace a le code 0x20. Du coup, le caractère de validation est obtenu avec ceci :

0x20 + (order % 0x10)

Des essais avec des order numbers plus grands le confirment : c'est un cycle qui se répète de 16 en 16.

OK, mais si le nom fait plus de 8 caractères ? Eh bien il n'y a tout simplement pas de remplissage supplémentaire et le compound ne prend plus du tout compte de l'order number.

Mais même avec ces modifs, le keygen ne fonctionne toujours pas pour Otto Matic. Il nous manque un truc qui m'a mis un peu de temps à trouver. Dans Nanosaur, souvenez-vous, le premier hash calculé est un hash de 1 octet sur le compound. On le démarrait avec la valeur constante 0x11. Mais dans Otto Matic, la valeur d'initialisation du compound semblait changer pour chaque nouvelle combinaison nom/order. J'ai décortiqué le code qui génère cette valeur de départ, en voici une reconstitution :

Code: Tout sélectionner
      cl = 0xff & (order >> 8)
      dl = 0xff & (order + 0x11)
      init = sxbyte((cl ^ dl) & 0xff)

(Rappel: sxbyte() est l'équivalent du sign-extend d'un octet en assembleur x86)

Une fois ces changements intégrés au keygen, ça roule pour Otto Matic !

Enigmo 1, Enigmo 2, Nanosaur 2, et Billy Frontier utilisent le même principe qu'Otto Matic. Il faut juste aller chercher leurs salts et les remplacer dans le keygen.

Tant que j'y étais j'ai adapté le keygen pour d'autres logiciels et jeux édités par IFD, dont je n'avais jamais entendu parler mais qui utilisent tous le même principe.

Conclusion

C'était long ! Ça m'a sûrement pris autant de temps à rédiger ce tutoriel qu'à décortiquer les jeux et écrire le keygen :D

Moralité #1 : persévérer. Nanosaur est mon deuxième crack d'un soft commercial (le premier était Sapiens, j'écrirai peut-être un article dessus un de ces quatre), et mine de rien c'est un gros morceau pour un débutant en crack. Je vous l'ai présenté d'une manière assez linéaire mais je n'ai pas mentionné toutes les fausses pistes qui m'ont fait perdre du temps. Par moments j'avais l'impression de refaire toujours le même passage sans avancer. Mais tant qu'on n'abandonne pas, quitte à faire des petites pauses pour rester frais, tout reste possible !

Moralité #2 : Nanosaur est sorti en 1998, mais ce keygen fonctionne sur des jeux sortis en 2006 pour les plus récents. Je ne comprends pas pourquoi l'éditeur ressort le même algorithme depuis des années dans tous leurs jeux. Ils devraient investir un peu de temps à chaque nouveau jeu pour modifier l'algo ne serait-ce que légèrement. C'est assez ridicule qu'un gusse comme moi, simplement armé de patience (et d'un bagage de programmeur certes), ait pu faire sauter tout leur catalogue en quelques heures.

J'espère que cet article était intéressant et pas trop lourd. Personnellement, ça me permet de garder une trace de mon cheminement, et surtout de nettoyer mon keygen : en expliquant comment j'ai fait, ça m'a forcé à simplifier ce qui pouvait l'être. Évidemment, je suis ouvert à toute critique, suggestion et correction.

J'ai attaché le keygen ci-dessous (nécessite Python 3) pour que vous ayez une vision d'ensemble de son fonctionnement. S'il vous plaît, évitez de le répandre sur des sites de warez, je poste ça dans un but éducatif et je ne veux aucun mal aux éditeurs.

D'ailleurs s'ils tombent dessus, qu'ils prennent plutôt ça comme un appel amical à se sortir les doigts du cul pour sécuriser un peu leurs bouzins ! Au lieu de réutiliser le même algo pendant 15 ans ;)

Ah, au fait, si vous voulez vous désenregistrer d'un jeu pour continuer à faire des essais, il faut virer un fichier nommé "ifdreg.dat".

Bisous !

– coucoupoulet

nanobrute.py
(dommage qu'il n'y ait pas de coloration syntaxique python sur ce forum ;))
python a écrit:Et voilà une jolie coloration syntaxique :lol:
Dernière édition par Bango le 16 Juillet 2013, 08:50, édité 1 fois.
Raison: keygen :/
Avatar de l’utilisateur
coucoupoulet
 
Messages: 2
Inscription: 15 Juillet 2013, 22:08

Re: Écrire un keygen pour Nanosaur, Bugdom, Otto Matic, etc.

Messagepar Bango » 16 Juillet 2013, 08:59

Bonjour, et merci pour ta participation!

Joli boulot ;)
coucoupoulet a écrit:Nanosaur est sorti en 1998, mais ce keygen fonctionne sur des jeux sortis en 2006 pour les plus récents. Je ne comprends pas pourquoi l'éditeur ressort le même algorithme depuis des années dans tous leurs jeux.

Peut -être qu'ils n'ont jamais eu à s'en inquiéter :roll: Pourquoi changer quelque chose qui fonctionne? :)

coucoupoulet a écrit:J'ai attaché le keygen ci-dessous (nécessite Python 3) pour que vous ayez une vision d'ensemble de son fonctionnement. S'il vous plaît, évitez de le répandre sur des sites de warez

Pour palier le problème de distribution, je me suis permis de retirer le code du keygen. Tu as fais un tut bien complet, qui donnera à tous ceux qui le souhaitent l'occasion de le mettre en application pour se faire soi même le keygen...(et t'inquiète pas, tu auras rapidement un aperçu en MP de ceux qui ont en besoin ;))
Dis moi si ça te pose un souci, je demanderai à notre chef admin vénéré à tous si cela n'est pas contraire aux règles.
Dernière édition par Bango le 16 Juillet 2013, 11:04, édité 1 fois.
Raison: orthographe :/
\ô/
Avatar de l’utilisateur
Bango
Modérateur
Modérateur
 
Messages: 1525
Inscription: 23 Juillet 2007, 15:33
Localisation: Gotham city

Re: Écrire un keygen pour Nanosaur, Bugdom, Otto Matic, etc.

Messagepar coucoupoulet » 16 Juillet 2013, 09:16

Pas de problème ! Du coup ça forcera ceux qui veulent le keygen à lire le tutoriel en entier :twisted:

D'ailleurs ce n'est pas très dur à reconstituer, il y a juste l'algo de bruteforce à réécrire.
Avatar de l’utilisateur
coucoupoulet
 
Messages: 2
Inscription: 15 Juillet 2013, 22:08

Re: Écrire un keygen pour Nanosaur, Bugdom, Otto Matic, etc.

Messagepar baboon » 16 Juillet 2013, 10:13

Très bon tuto :)
J'aime bien le ton et les explications !

Pour ce qui est de la division faite avec la multiplication et le décalage, c'est une optimisation faite par le compilateur : hxxp://blogs.msdn.com/b/devdev/archive/ ... 02980.aspx + hxxp://www.nynaeve.net/?p=115 pour plus de détail :)

[EDIT] d'ailleurs la vérification de la longueur du serial 4 == ((0xCCCCCCCD * (length+1)) >> (32+2)) peut ête simplifiée en ... (length+1) / 5 == 4 :)
Newbie mais ayant soif d'apprendre et étant motivé
Avatar de l’utilisateur
baboon
Modérateur
Modérateur
 
Messages: 3274
Inscription: 08 Juillet 2005, 17:49

Re: Écrire un keygen pour Nanosaur, Bugdom, Otto Matic, etc.

Messagepar Bango » 16 Juillet 2013, 11:09

Ça y est ça parle de python, Baboon sort de sa cave (à bières) :lol:

Encore une fois, bon travail "mon poulet" ;) , d'autant que j'avais pas vu que c'était le premier post :)
\ô/
Avatar de l’utilisateur
Bango
Modérateur
Modérateur
 
Messages: 1525
Inscription: 23 Juillet 2007, 15:33
Localisation: Gotham city

Re: Écrire un keygen pour Nanosaur, Bugdom, Otto Matic, etc.

Messagepar lautheking » 16 Juillet 2013, 11:36

Effectivement, il vaut mieux ne pas distribuer le keygen: cela nous évite des ennuis et c'est motivant pour ceux qui suivent le tutorial ! Sinon le texte est clair et bien rédigé, bravo coucoupoulet :)
"Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety."
- Benjamin Franklin
Avatar de l’utilisateur
lautheking
Triumvirat
Triumvirat
 
Messages: 2930
Inscription: 05 Février 2004, 16:01


Retourner vers Tutoriels

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité