endermanch/xpkeygenWindows XP Keygen
Un générateur de clés VLK pour Windows XP / Windows Server 2003. Cet outil permet de générer des clés Windows XP valides à partir de la clé de produit brute (Raw Product Key), qui peut être aléatoire.
La clé de produit brute (RPK) est fournie sous la forme de 9 chiffres XXX-YYYYYY et n'est nécessaire que pour générer une clé Windows XP.
Rendez-vous dans l'onglet Releases et téléchargez-y la dernière version.
Ce projet n'est pas mort — je ferai de mon mieux pour le mener à bien.
En général, la seule chose qui nous sépare de la génération de clés Windows XP valides pour CHAQUE ÉDITION et CHAQUE VERSION est l'absence des clés privées respectives générées à partir de leurs homologues publiques dans pidgen.dll. Il n'existe pas de code pour la fonction de logarithme discret sur courbe elliptique largement disponible en ligne, seulement des informations vagues sur la façon de procéder.
Au fil du temps, le problème a été partiellement résolu.
La ressource BINK n'était encodée d'aucune manière et les données étaient simplement écrites séquentiellement dans la ressource. sk00ter a également entièrement expliqué le format BINK sur les forums MDL. En utilisant les connaissances communautaires antérieures sur le sujet, j'ai écrit un lecteur BINK en Python 3. Le fichier est public dans ce dépôt, cliquez ici pour voir le code source.
La solution du logarithme discret est le domaine de recherche le plus inexploré à la date du 28 mai 2023. Cependant, mon ami nephacks a tout de même trouvé cet outil insaisissable pour résoudre ce problème difficile dans les recoins les plus sombres d'Internet. Il s'appelle ECDLP (Elliptic Curve Discrete Logarithm Problem) Solver de Mr. HAANDI. Comme il était extrêmement frustrant de le trouver en ligne, je l'ai remis en ligne sur mon site Web. Vous pouvez télécharger l'outil ici.
Le fichier ReadMe fourni avec la version 0.2a du solveur est suffisant en soi, donc toute personne avec un minimum de jugeote saura configurer cet outil. Cependant, il n'est pas open-source, son intégration dans mon keygen s'avère donc impossible.
Dans le scénario idéal, le keygen vous demanderait une ressource BINK extraite de pidgen.dll, qu'il décomposerait ensuite dans les segments suivants :
pubX ; pubY)genX ; genY)a ; b)pEn connaissant ces segments, le keygen rechercherait par force brute l'ordre du générateur genOrder à l'aide de l'algorithme de Schoof, puis la clé privée privateKey, en exploitant le genOrder calculé pour utiliser l'algorithme de Pollard-Rho le plus optimal. Nul doute que nous pouvons casser n'importe quelle clé privée en une vingtaine de minutes avec la puissance de calcul moderne, à condition de disposer d'un algorithme fonctionnel.
Une fois que le keygen a fini de trouver par force brute la bonne clé privée, la tâche se résume à générer réellement une clé, ce que fait ce keygen. Pour vous donner une meilleure perspective, je peux vous fournir le déroulement du keygen idéal. Ce qui est barré correspond à ce que mon keygen implémente :
genOrder, privateKey)Nous devons utiliser une clé de produit brute aléatoire comme base pour générer un ID de produit sous la forme AAAAA-BBB-CCCCCCS-DDEEE.
| Chiffres | Signification |
|---|---|
| AAAAA | Constante de famille d'OS |
| BBB | ID de canal |
| CCCCCC | Numéro de séquence |
| S | Chiffre de contrôle |
| DD | Index de clé publique |
| EEE | Nombre aléatoire à 3 chiffres |
La constante de famille d'OS AAAAA diffère pour chaque série de Windows XP. Par exemple, elle vaut 76487 pour SP3.
Les sections BBB et CCCCCC encodent essentiellement la clé de produit brute. Par exemple, si la première section est égale à XXX et la seconde à YYYYYY, la clé de produit brute sera encodée comme XXX-YYYYYY.
Le chiffre de contrôle S est choisi de sorte que la somme de tous les chiffres C, une fois S ajouté, forme un nombre divisible par 7.
L'index de clé publique DD nous permet de savoir quelle clé publique a été utilisée pour vérifier avec succès l'authenticité de notre clé de produit.
Par exemple, il est de 22 pour les clés Professional et de 23 pour les clés VLK.
Un nombre aléatoire EEE est utilisé pour générer un ID d'installation différent à chaque fois.
La clé de produit elle-même (à ne pas confondre avec la RPK) se présente sous la forme FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK, encodée en Base-24 avec
l'alphabet BCDFGHJKMPQRTVWXY2346789 afin d'exclure tout caractère pouvant être facilement confondu, comme I et 1 ou O et 0.
D'après la formule de capacité de l'alphabet, la clé peut contenir au plus 114 bits d'information. $$N = \log_2(24^{25}) \approx 114$$
Sur la base de ce calcul, nous décomposons la clé de produit de 114 bits en 4 segments ordonnés :
| Segment | Capacité | Données |
|---|---|---|
| Upgrade | 1 bit | Indicateur de version Upgrade |
| Serial | 30 bits | Clé de produit brute (RPK) |
| Hash | 28 bits | Hash RPK |
| Signature | 55 bits | Signature à courbe elliptique pour le hash RPK |
Par souci de simplicité, nous allons combiner les segments Upgrade et Serial en un seul segment appelé Data. Avec cette logique, nous pourrons extraire la RPK en
décalant Data vers la droite et la réintégrer en décalant les bits vers la gauche, car la plupart des clés de produit a priori valides que j'ai vérifiées avaient le bit Upgrade défini sur 1.
Microsoft a retravaillé son format de clé de produit avec Windows Server 2003 pour y inclure une clé d'authentification de serveur backend, ce qui constituait une approche réellement sécurisée de la validation de licence, car personne ne pouvait deviner quel algorithme de validation ils avaient utilisé sur leur serveur privé. Outre l'ajout du mécanisme de validation en ligne, ils ont également fait passer l'arithmétique globale de 384 à 512 bits, et le scalaire de la signature à 62 bits d'information.
| Segment | Capacité | Données |
|---|---|---|
| Upgrade | 1 bit | Indicateur de version Upgrade |
| Channel ID | 10 bits | La partie BBB de la RPK |
| Hash | 31 bits | Hash RPK |
| Signature | 62 bits | Signature à courbe elliptique pour le hash RPK |
| Auth Key | 10 bits | Valeur d'authentification backend |