Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
XPKeygen — Generiert gültige Windows-XP- und Server-2003-Produktschlüssel durch Rekonstruktion von Elliptische-Kurven-Signaturen und BINK-Ressourcen, mit einem Parser für pidgen.dll-BINK-Strukturen. | Kitploit
Tools/GitHubGitHub/endermanch/xpkeygen
Reverse EngineeringKryptographieBinäranalyse
GitHubendermanch/xpkeygen

XPKeygen

Generiert gültige Windows-XP- und Server-2003-Produktschlüssel durch Rekonstruktion von Elliptische-Kurven-Signaturen und BINK-Ressourcen, mit einem Parser für pidgen.dll-BINK-Strukturen.

Repository anzeigen
1.1k68vor 1 MonatVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

XPKeygen

Ein Windows-XP-/Windows-Server-2003-VLK-Keygenerator. Dieses Tool ermöglicht es Ihnen, gültige Windows-XP-Schlüssel auf Basis des Raw Product Key zu generieren, der zufällig sein kann. Der Raw Product Key (RPK) wird in Form von 9 Ziffern XXX-YYYYYY angegeben und ist nur erforderlich, um einen Windows-XP-Schlüssel zu generieren.

XP Keygen

Download

Gehen Sie zum Tab Releases und laden Sie die neueste Version von dort herunter.

Pläne

Dieses Projekt ist nicht tot – ich werde mein Bestes tun, um es zur Vollendung zu bringen.

Das Problem

Im Allgemeinen trennt uns von der Generierung gültiger Windows-XP-Schlüssel für JEDE EDITION und JEDEN BUILD nur das Fehlen der jeweiligen privaten Schlüssel, die aus ihren öffentlichen Gegenstücken in pidgen.dll erzeugt werden. Es gibt keinen Code für die diskrete Logarithmusfunktion elliptischer Kurven, der online weithin verfügbar ist, sondern nur vage Informationen darüber, wie man es macht.

Im Laufe der Zeit wurde das Problem teilweise gelöst.

Die BINK-Ressource war in keiner Weise codiert und die Daten wurden lediglich sequenziell in die Ressource geschrieben. sk00ter hat das BINK-Format in den MDL-Foren ebenfalls vollständig erklärt.

Unter Nutzung des vorhandenen Wissens der Community zu diesem Thema habe ich einen BINK-Reader in Python 3 geschrieben. Die Datei ist in diesem Repository öffentlich; klicken Sie hier, um den Quellcode anzusehen.

Die Lösung des diskreten Logarithmus ist der am wenigsten erforschte Forschungsbereich Stand 28. Mai 2023. Mein Freund nephacks hat jedoch genau jenes schwer fassbare Werkzeug gefunden, um dieses schwierige Problem in den dunkelsten Ecken des Internets zu lösen. Es heißt ECDLP (Elliptic Curve Discrete Logarithm Problem) Solver von Mr. HAANDI. Da es äußerst mühsam war, es online zu finden, habe ich es auf meiner Website erneut hochgeladen. Sie können das Tool hier herunterladen.

Die ReadMe-Datei, die mit der Version 0.2a des Solvers geliefert wird, ist für sich genommen gut genug, sodass jeder mit Verstand das Tool einrichten kann. Allerdings ist es nicht Open Source, weshalb die Integration in meinen Keygen nachweislich unmöglich ist.

Im Idealfall würde der Keygen Sie nach einer aus pidgen.dll extrahierten BINK-Ressource fragen, die er dann in folgende Segmente entpackt:

  • Öffentlicher Schlüssel (pubX; pubY)
  • Generator (genX; genY)
  • Basispunkt (a; b)
  • Punktanzahl p

Mit Kenntnis dieser Segmente würde der Keygen die Generatorordnung genOrder mithilfe des Schoof-Algorithmus per Brute-Force ermitteln, gefolgt vom privaten Schlüssel privateKey, wobei die berechnete genOrder genutzt wird, um den optimalsten Pollard-Rho-Algorithmus anzuwenden. Es besteht kein Zweifel, dass wir mit moderner Rechenleistung jeden privaten Schlüssel innerhalb von 20 Minuten knacken können, sofern wir den funktionierenden Algorithmus haben.

Sobald der Keygen den richtigen privaten Schlüssel per Brute-Force ermittelt hat, reduziert sich die Aufgabe darauf, tatsächlich einen Schlüssel zu generieren, was dieser Keygen tut. Um Ihnen eine bessere Perspektive zu geben, kann ich Ihnen den Ablauf des idealen Keygens zeigen. Durchgestrichen ist, was mein Keygen implementiert:

Funktionsprinzip

Wir müssen einen zufälligen Raw Product Key als Basis verwenden, um eine Produkt-ID in der Form AAAAA-BBB-CCCCCCS-DDEEE zu generieren.

Produkt-ID

Die OS-Familienkonstante AAAAA ist für jede Serie von Windows XP unterschiedlich. Beispielsweise beträgt sie für SP3 76487.

Die Abschnitte BBB und CCCCCC codieren im Wesentlichen den Raw Product Key. Wenn beispielsweise der erste Abschnitt gleich XXX und der zweite Abschnitt gleich YYYYYY ist, wird der Raw Product Key als XXX-YYYYYY codiert.

Die Prüfziffer S wird so gewählt, dass die Summe aller C-Ziffern, zu der sie addiert wird, eine durch 7 teilbare Zahl ergibt.

Der Public-Key-Index DD zeigt uns, welcher öffentliche Schlüssel verwendet wurde, um die Authentizität unseres Product Keys erfolgreich zu verifizieren. Beispielsweise beträgt er 22 für Professional-Schlüssel und 23 für VLK-Schlüssel.

Eine zufällige Zahl EEE wird verwendet, um jedes Mal eine andere Installations-ID zu generieren.

Product Key

Der Product Key selbst (nicht zu verwechseln mit dem RPK) hat die Form FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK, codiert in Base-24 mit dem Alphabet BCDFGHJKMPQRTVWXY2346789, um Zeichen auszuschließen, die leicht verwechselt werden können, wie I und 1 oder O und 0.

Gemäß der Formel für die Alphabetkapazität kann der Schlüssel höchstens 114 Bits an Informationen enthalten. $$N = \log_2(24^{25}) \approx 114$$

Basierend auf dieser Berechnung entpacken wir den 114-Bit-Product Key in 4 geordnete Segmente:

Der Einfachheit halber kombinieren wir die Segmente Upgrade und Serial zu einem einzigen Segment namens Data. Nach dieser Logik können wir den RPK extrahieren, indem wir Data nach rechts verschieben, und ihn wieder einpacken, indem wir Bits nach links verschieben, da die meisten a priori gültigen Product Keys, die ich geprüft habe, das Upgrade-Bit auf 1 gesetzt hatten.

Microsoft überarbeitete das Product-Key-Format mit Windows Server 2003, um einen Backend-Server-Authentifizierungsschlüssel aufzunehmen, was ein tatsächlich sicherer Ansatz zur Lizenzvalidierung war, da niemand jemals erraten konnte, welchen Validierungsalgorithmus sie auf ihrem privaten Server eingesetzt hatten. Neben der Hinzufügung des Online-Validierungsmechanismus erhöhten sie auch die gesamte Arithmetik von 384 auf 512 Bits und den Signaturskalar auf 62 Bits an Informationen.

Wenn wir jedoch einen Schlüssel ohne die Online-Aktivierung im Hinterkopf generierten, könnten wir dennoch gültige Schlüssel erzeugen, die uns durch die Einrichtung des Betriebssystems bringen. Und genau das tut der Code – er generiert einen zufälligen 10-Bit-Authentifizierungsschlüssel. Heutzutage spielt das überhaupt keine Rolle mehr, da die Aktivierungsserver nicht mehr erreichbar sind und Server 2003 als Abandonware gilt; genauso sollte dieses gesamte Projekt nicht als Piraterie betrachtet werden.

Elliptische Kurven

Elliptic Curve Cryptography (ECC) ist eine Art Public-Key-Kryptosystem. Diese Klasse von Systemen stützt sich auf anspruchsvolle „Einbahnstraßen“-Mathematikprobleme – einfach in die eine Richtung zu berechnen und schwer in die „andere“ Richtung zu lösen. Manchmal werden sie als „Falltür“-Funktionen bezeichnet – leicht hineinzufallen, schwer zu entkommen.[5]

ECC beruht auf dem Lösen von Gleichungen der Form $$y^2 = x^3 + ax + b$$

Im Allgemeinen gibt es 2 Sonderfälle der in der Kryptographie verwendeten elliptischen Kurve – F2m und Fp. Sie unterscheiden sich nur geringfügig. Beide Kurven sind über dem endlichen Körper definiert; Fp verwendet einen Primzahlparameter, der größer als 3 ist, F2m nimmt $p = 2m$ an. Microsoft verwendete Letzteres in seinem Algorithmus.

Eine elliptische Kurve über dem endlichen Körper Fp besteht aus:

  • einer Menge von ganzzahligen Koordinaten ${x, y}$, sodass $0 \le x, y < p$;
  • einer Menge von Punkten $y^2 = x^3 + ax + b \mod p$.

Eine elliptische Kurve über F17 würde so aussehen:

F17 Elliptic Curve

Die Kurve besteht aus den blauen Punkten im obigen Bild. In der Praxis sind die in der Kryptographie verwendeten „elliptischen Kurven“ „Punktmengen in einer quadratischen Matrix“.

Die obige Kurve ist „lehrreich“. Sie bietet eine sehr kleine Schlüssellänge (4-5 Bits). In realen Anwendungen verwenden Entwickler typischerweise Kurven mit 256 Bits oder mehr.

BINK-Ressource

Da es sich um ein Public-Key-Kryptosystem handelt, musste Microsoft den öffentlichen Schlüssel mit seiner Windows-XP-Version teilen, um eingegebene Product Keys dagegen zu prüfen. Dieser ist in pidgen.dll in Form einer BINK-Ressource gespeichert. Der erste Satz BINK-Daten dient zur Validierung von Retail-Schlüsseln, der zweite jeweils für die OEM-Schlüssel.

Die Struktur der BINK-Ressource für Windows 98 und Windows XP ist wie folgt:

Jedes Segment ist mit einer anderen Farbe markiert; die BINK-Headerwerte sind gleich.

BINK

Windows Server 2003 und Windows XP x64 implementieren es anders:

Und hier sind meine Strukturprototypen für den BINK-Reader in C:```c typedef struct _EC_BYTE_POINT { CHAR x[256]; // x-coordinate of the point on the elliptic curve. CHAR y[256]; // y-coordinate of the point on the elliptic curve. } EC_BYTE_POINT;

typedef struct _BINKHDR { // BINK version - not stored in the resource. ULONG32 dwVersion;

root@kitploit:~
// Original BINK header.
ULONG32 dwID;
ULONG32 dwSize;
ULONG32 dwHeaderLength;
ULONG32 dwChecksum;
ULONG32 dwDate;
ULONG32 dwKeySizeInDWORDs;
ULONG32 dwHashLength;
ULONG32 dwSignatureLength;

// Extended BINK header. (Windows Server 2003+)
ULONG32 dwAuthCodeLength;
ULONG32 dwProductIDLength;

} BINKHDR;

typedef struct _BINKDATA { CHAR p[256]; // Finite Field order p. CHAR a[256]; // Elliptic Curve parameter a. CHAR b[256]; // Elliptic Curve parameter b.

root@kitploit:~
EC_BYTE_POINT G;    // Base point (Generator) G.
EC_BYTE_POINT K;    // Public key K.

} BINKDATA;

typedef struct _BINKEY { BINKHDR header; BINKDATA data; } BINKEY;

root@kitploit:~
Falls du weiterforschen möchtest: Der Quellcode von `pidgen.dll` und all seinen Funktionen ist in diesem Repository im Ordner „pidgen“ verfügbar.

### Reverse Engineering des privaten Schlüssels

Wenn wir gültige Product Keys für Windows XP generieren wollen, müssen wir den entsprechenden privaten Schlüssel mithilfe des mit `pidgen.dll` gelieferten öffentlichen Schlüssels berechnen, was bedeutet, dass wir die Einweg-ECC-Aufgabe umkehren müssen.

Gemessen am Schlüssel in BINK beträgt die Kurvenordnung **384 Bits** unter Windows XP bzw. **512 Bits** unter Server 2003 / XP x64. Die Berechnungsschwierigkeit mit dem effizientesten Pollard-Rho-Algorithmus mit asymptotischer Komplexität $O(\sqrt{n})$ läge für Windows XP bei mindestens $O(2^{168})$ und für Windows Server 2003 bei $O(2^{256})$, aber zu unserem Glück hat Microsoft den Wert der Signatur unter Windows XP auf 55 Bits und unter Windows Server 2003 auf 62 Bits begrenzt, um die Anzahl passender Produktschlüssel zu reduzieren, wodurch die Schwierigkeit auf ein weitaus besser handhabbares $O(2^{28})$ / $O(2^{31})$ sinkt.

Wie bereits erwähnt, gibt es nur ein öffentliches Werkzeug, das unsere aktuellen Anforderungen erfüllt: den ECDLP-Solver von Mr. HAANDI.<br>

Um den privaten Schlüssel zu berechnen, müssen wir dem Tool die öffentlichen ECC-Werte aus der BINK-Ressource sowie die Ordnung `genOrder` des Basispunkts `G(Gx; Gy)` zur Verfügung stellen. Die Ordnung des Basispunkts kann mit SageMath berechnet werden.

**Hier ist der grundlegende Algorithmus, den ich verwendet habe, um den privaten Windows-98-Schlüssel zu ermitteln:**

1. Berechne die Ordnung des Basispunkts mit **SageMath**. Führe in SageMath die folgenden Befehle aus:
    1) `E = EllipticCurve(GF(p), [0, 0, 0, a, b])`, wobei `p`, `a` und `b` die dezimal dargestellten Elliptische-Kurve-Parameter aus der BINK-Ressource sind.
    2) `G = E(Gx, Gy)`, wobei `Gx` und `Gy` die dezimal dargestellten Koordinaten des Basispunkts aus der BINK-Ressource sind.
    3) `K = E(Kx, Ky)`, wobei `Kx` und `Ky` die dezimal dargestellten Koordinaten des öffentlichen Schlüssels aus der BINK-Ressource sind.
    4) `n = G.order()`, `n` ist die berechnete Ordnung des Basispunkts. **Die Berechnung kann einige Zeit dauern, selbst auf den neuesten Builds.**
    5) Faktorisiere die Ordnung mit `factor(n)`. Microsoft hat für die Punktordnungen Primzahlen verwendet. Wenn also die Zahl selbst zurückgegeben wird, ist das völlig normal.
    6) Speichere die resultierenden Faktoren der Ordnung irgendwo.
    7) `-K` liefert dir die Inverse des öffentlichen Schlüssels in einer projektiven Ebene mit Koordinaten `(x : y : z)`. Speichere die `y`-Koordinate irgendwo, sie wird benötigt, um einen korrekten privaten Schlüssel zu erzeugen.
2. Berechne den privaten Schlüssel mit **ECDLP Solver v0.2a**.
    1) Das Tool wird mit einer Jobvorlage `job_template.txt` und einer ReadMe-Datei geliefert. Es ist notwendig zu verstehen, wie das Tool funktioniert, um es zu verwenden.
    2) Füge alle öffentlichen Elliptische-Kurve-Werte aus der BINK-Ressource ein, **außer der `Ky`-Koordinate**. Um einen korrekten privaten Schlüssel zu erzeugen, **musst du die inverse Koordinate `-Ky` verwenden, die du zuvor in SageMath berechnet hast.**
    3) Füge die Faktoren der Basispunktordnung `n` ein und gib die Anzahl der Faktoren an. Sie wird höchstwahrscheinlich `1` sein, da Microsoft für ihre Generatorordnungen hauptsächlich Primzahlen verwendet.
    4) Führe das Tool `<arch> ECDLP Solver.exe <job_name>.txt` aus und warte, bis es den privaten Schlüssel `k = %d` für dich berechnet.

**Hier ist ein Beispiel für den Windows-XP-Job `job_xp.txt`, der den korrekten privaten Schlüssel für den ECDLP-Solver liefert.**```pascal
GF := GF(22604814143135632990679956684344311209819952803216271952472204855524756275151440456421260165232069708317717961315241);
E := EllipticCurve([GF|1,0]);
G := E![10910744922206512781156913169071750153028386884676208947062808346072531411270489432930252839559606812441712224597826,19170993669917204517491618000619818679152109690172641868349612889930480365274675096509477191800826190959228181870174];
K := E![14399230353963643339712940015954061581064239835926823517419716769613937039346822269422480779920783799484349086780408,17120082747148185997450361756610881166187863099877353630300913555824935802439591336620545428308962346299700128114607];
/*
FactorCount:=1;
61760995553426173
*/

Und die ECDLP-Solver-Ausgabe dazu:

ECDLP Solver Output

Wichtiger Hinweis:

Beachte: Ich konnte mit dem von mir rekonstruierten privaten Schlüssel keinen korrekten Windows-XP-x64-Schlüssel erzeugen, selbst unter Verwendung der Ky-Koordinate anstelle des üblichen -Ky. Aus irgendeinem Grund gelang es mir auch nicht, die Ordnung des Basispunkts von Windows Server 2003 mit SageMath zu berechnen. Ich ließ es 12 Stunden lang auf meinem i7-12700K rechnen, aber es hing immer noch bei der Berechnung fest.

Produktschlüssel validieren / generieren

Der Rest der Arbeit wird im Code dieses Keygens erledigt.

Bekannte Probleme

  • Einige Schlüssel sind nicht gültig, aber das kommt insgesamt seltener vor. Ungefähr 2 von 3 Schlüsseln sollten funktionieren.
    Behoben in v1.2. Frühere Versionen erzeugten mit einer exakten Wahrscheinlichkeit von 0x40000/0x62A32 einen gültigen Schlüssel, was exakt 0.64884, also etwa 65 %, ergab. Meine Schätzung von „2 von 3“ war unvorstellbar genau.
  • Auf mehreren Windows-XP-Systemen getestet. Funktioniert unter Professional x86, allen Service Packs. Andere Windows-Editionen funktionieren möglicherweise nicht. x64 FUNKTIONIERT NICHT.
  • Die Schlüsselgenerierung für Server 2003 ist noch nicht enthalten.
    Behoben in v2.2.
  • Manche Windows-XP-VLK-Schlüssel sind tendenziell „schlechter“ als andere. Einige davon können nach der Installation ein defektes WPA mit leerer Installations-ID auslösen. Die besten Chancen auf „bessere“ Schlüssel hast du, wenn der BBB-Abschnitt auf 640 gesetzt ist und der CCCCCC-Abschnitt nicht null ist.
  • Die Schlüsselgenerierung für Windows Server 2003 ist defekt. Ich weiß nicht einmal, wo ich dort anfangen soll. Die Schlüssel scheinen nirgendwo gültig zu sein, aber der Algorithmus ist gut dokumentiert. Meine Implementierung erzeugt etwa 1 von 3 „gültigen“ Schlüsseln.
    Behoben in v2.3*.

Literatur

Ich werde in späteren Versionen weitere gute Lektüre in die Bibliografie aufnehmen.

Grundlagen der Windows-XP-Aktivierung verstehen:

  • [1] Inside Windows Product Activation - Fully Licensed | archive.org
  • [2] MSKey 4-in-1 ReadMe | archive.org
  • [3] Windows序列号产生原理(椭圆曲线法) | archive.org

Elliptische-Kurven-Kryptografie verstehen:

  • [4] Elliptic Curve Cryptography for Beginners - Matt Rickard | archive.org
  • [5] Elliptic Curve Cryptography (ECC) - Practical Cryptography for Developers | archive.org
  • [6] A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography - Cloudflare | archive.org

Öffentliche Diskussionen:

  • [7] Windows 98 Equivalent // Server 2003 Algorithm | archive.org
  • [8] Cracking Windows XP | archive.org

Mitwirken / Verwendung

Wenn du diese Software vorführen oder forken möchtest, gib bitte Endermanch, z22 und MSKey als Quelle an.
Du kannst sie nach Belieben anpassen, solange sie Open Source bleibt. Lizenziert unter der GNU General Public License v3.0.

Beiträge und Fragen sind jederzeit willkommen.

Tool herunterladen
  • BINK-Ressourcenextraktion
  • Brute-Force-Lösung des diskreten Logarithmus elliptischer Kurven (genOrder, privateKey)
  • Product-Key-Verarbeitungsmechanismus
  • Windows-XP-Schlüsselgenerierung
  • Windows-XP-Schlüsselvalidierung
  • Windows-Server-2003-Schlüsselgenerierung
ZiffernBedeutung
AAAAAOS-Familienkonstante
BBBChannel-ID
CCCCCCSequenznummer
SPrüfziffer
DDPublic-Key-Index
EEEZufällige 3-stellige Zahl
SegmentKapazitätDaten
Upgrade1 BitUpgrade-Versionsflag
Serial30 BitsRaw Product Key (RPK)
Hash28 BitsRPK-Hash
Signatur55 BitsElliptische-Kurven-Signatur für den RPK-Hash
SegmentKapazitätDaten
Upgrade1 BitUpgrade-Versionsflag
Channel-ID10 BitsDer BBB-Teil des RPK
Hash31 BitsRPK-Hash
Signatur62 BitsElliptische-Kurven-Signatur für den RPK-Hash
Auth Key10 BitsBackend-Authentifizierungswert
OffsetValue
0x0000BINK-ID
0x0004Größe der BINKEY-Struktur in Bytes (in der Praxis immer 0x16C)
0x0008Länge des Headers (in der Praxis immer 7)
0x000CPrüfsumme
0x0010Nummerncodiertes Datum – BINKEY-Version (in der Praxis immer 19980206)
0x0014Größe der ECC-Kurvenordnung (in der Praxis immer 12)
0x0018Hash-Länge (in der Praxis immer 28)
0x001CSignaturlänge (in der Praxis immer 55)
0x0020Ordnung des endlichen Körpers p
0x005CKurvenparameter a
0x0098Kurvenparameter b
0x00D4x-Koordinate des Basispunkts Gx
0x0110y-Koordinate des Basispunkts Gy
0x014Cx-Koordinate des öffentlichen Schlüssels Kx
0x0188y-Koordinate des öffentlichen Schlüssels Ky
OffsetValue
0x0000BINK-ID
0x0004Größe der BINKEY-Struktur in Bytes
0x0008Länge des Headers (in der Praxis immer 9)
0x000CPrüfsumme
0x0010Nummerncodiertes Datum – BINKEY-Version (in der Praxis immer 20020420)
0x0014Größe der ECC-Kurvenordnung (in der Praxis immer 16)
0x0018Hash-Länge (in der Praxis immer 31)
0x001CSignaturlänge (in der Praxis immer 62)
0x0020Länge des Backend-Authentifizierungswerts (in der Praxis immer 12)
0x0024Länge der Produkt-ID (in der Praxis immer 20)
0x0028Ordnung des endlichen Körpers p
0x0068Kurvenparameter a
0x00A8Kurvenparameter b
0x00E8x-Koordinate des Basispunkts Gx
0x0128y-Koordinate des Basispunkts Gy
0x0168x-Koordinate des öffentlichen Schlüssels Kx
0x01A8y-Koordinate des öffentlichen Schlüssels Ky