En mai 1996, sur le forum Usenet consacré à Quake , des joueurs prenaient déjà les paris... Le jeu n'était pas sorti, le CD non plus, et la question qui tournait en boucle à l'époque c'était : combien de temps tiendrait la protection anti-copie du jeu ? Certains misaient deux semaines après la sortie, d'autres 5 jours maximum...

De son côté, id Software s'apprêtait à presser son shareware sur un disque mais Quake n'occupait que 22 Mo des 640 disponibles. Du gâchis de place ? Pas vraiment puisque le reste du CD a été rempli avec tout le catalogue maison. Des jeux complets en versions chiffrées, c'est-à-dire plusieurs DOOM, Final Doom, Hexen, Heretic qu'on déverrouillait par téléphone...

Source

Le CD est finalement sorti le 30 août 1996 et le concept était bien pensé, sur le papier en tout cas... Le programme affichait un nombre de onze chiffres, les Américains appelaient le 1-800-ID-GAMES, un opérateur encaissait la thune et donnait en échange un numéro de déverrouillage à retaper. Le premier nombre changeait à chaque lancement et tournait toutes les 5 minutes, précisément pour qu'un code ne puisse pas servir deux fois.

Mais le 8 octobre suivant, coup de tonnerre ! Le groupe GNOMON sortait QCRACK.EXE pour faire tout sauter ! Ça n'aura pris que 39 jours !

source

Ce qu'ils avaient compris, c'est que le numéro donné au téléphone ne contenait aucun secret. Il attestait simplement du paiement et de rien d'autre. Le programme livré sur le CD savait fabriquer ce numéro tout seul à partir de celui qu'il venait lui-même d'afficher, et son seul travail consistait donc à comparer les deux.

Toute la protection tenait, comme souvent, dans le fait que personne n'était censé regarder comment ça fonctionnait.

Source

Toutefois, ce mécanisme de vente n'était pas vraiment une bourde d'id Software. Eux n'étaient que les clients de TestDrive Corp, qui vendait cette solution brevetée .

Et ce brevet expliquait très précieusement comment ça fonctionnait... Le poste de l'utilisateur produit un numéro, l'opérateur distant le valide et renvoie un code d'activation, et c'est le poste de l'utilisateur qui vérifie ce code. Le brevet va même jusqu'à donner son exemple, à savoir un numéro dont les chiffres totalisent 10, et un code de retour dont les chiffres totalisent 15.

La faille était donc déposée à l'office des brevets quatre ans avant que le CD arrive en rayon.

Le reste raconte quand même une fin de production difficile. La base qui associe chaque jeu à son identifiant contenait également une faute de casse sur Final Doom, "Final" au lieu de "final", ce qui envoyait la génération du code chercher le mauvais fichier. Résultat, le client qui appelait et payait pour Final Doom n'arrivait pas à le déverrouiller.

Alors que le pirate, lui, y arrivait à tous les coups !

Et si je vous raconte tout ça c'est surtout parce que Fabien Sanglard s'est amusé à redémonter le CD-Rom cet été , et qu'il y a aussi trouvé de jolies surprises comme une version en clair de cette base posée juste à côté de sa version chiffrée + des fichiers temporaires et des sauvegardes d'éditeur oubliés au pressage.

Je vous invite vraiment à lire son analyse, c'est super intéressant !

Source : PC Gamer

Enfin !! Le compteur du projet de décompilation de GoldenEye 007 affiche dorénavant 208 fichiers traités sur 208, et cela pour les trois versions de la cartouche, japonaise et européenne comprises. Le dernier commit du dev KholdFuzion est d'ailleurs classe, puisqu'il porte le titre "*james bond will return. *".

Oh yeah !

Techniquement, le code C reconstitué ressort du compilateur sous la forme d'une ROM identique à celle de 1997, octet pour octet. C'est précisément ce que veut dire le mot "matching" dans ces projets. Ce n'est donc pas un jeu équivalent qui se comporterait pareil que le jeu d'origine... Non, c'est exactement le même binaire !

Après comme vous vous en doutez, le dépôt, lui, n'embarque pas tous les assets nécessaires à la compilation, pour des questions de droits d'auteur comme d'hab. Le README du projet nous explique ainsi qu'il faut posséder une copie du jeu, et que les scripts iront extraire ce qui manque de votre côté.

Après c'est pas cette recompilation qui fait que GoldenEye devient soudainement "moddable". En effet, il l'est depuis longtemps, via le GoldenEye Setup Editor de SubDrag, Wreck et Zoinkity, capable d'importer vos propres modèles 3D dans le jeu.

Ce qui change par contre, c'est que jusqu'ici on éditait des structures dans un binaire, alors que maintenant on modifie le moteur en C et on recompile. C'est le même chemin qu'avait pris ce bon vieux Duke Nukem Zero Hour l'an dernier .

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Et c'est d'ailleurs ce que fait KholdFuzion à côté, avec GoldenRecomp , qui recompile la ROM en exécutable PC natif. Avec ça, le jeu peut tourner sur un ordinateur. Apparemment, c'est plutôt stable, et le son est bon.

Mais toute l'interface multijoueur reste à faire, le ciel du barrage part en vrille parce que le moteur de rendu ne digère pas les commandes de dessin maison, et certaines armes tirent trop vite maintenant que tout tourne à 60 images par seconde. Ce n'est donc pas encore vraiment jouable.

Aucune release n'a été publiée à ce jour, ni même un tag, ce qui veut dire qu'on est encore loin d'un portage installable comme celui de Zelda 64 . Faudra compiler vous-même, après avoir "build" une ROM depuis la branche du projet conçue pour ça.

Dans le même style, n'oubliez pas l'existence de GoldenEye-Recomp de SunJaycy , qui lui, est déjà jouable avec du multijoueur en ligne, mais qui n'a rien à voir avec tout ça puisqu'il recompile la version Xbox 360 qui n'est jamais sortie, et pas la N64.

Bref, si vous attendiez un exécutable à lancer ce soir, ce n'est pas ce que vous aurez mais ce qui s'annonce ensuite est très prometteur !

Source