A Windows XP korszak egyik legismertebb „urban legendje” a hírhedt:

FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8

termékkulcs. Sokan emlékeznek rá, hogy ezzel a kóddal „minden XP-t fel lehetett tenni”, de kevesen tudják, mi volt a technikai háttér, hogyan működött valójában a Windows Product Activation (WPA), és miért volt ez a kulcs különleges. A történet egyik legautentikusabb forrása Dave W. Plummer, a Microsoft egykori fejlesztője, aki az operációs rendszer oldalán a Windows Product Activation integrációjáért és védelméért felelt.

Ebben a cikkben egyrészt végigvesszük Plummer beszámolóját, másrészt technikai és történeti kontextusba helyezzük: hogyan működött a termékaktiválás, mi az a volume licence (VLK), miért volt más a „corporate” média, és hogyan kapcsolódik mindehhez a legendás Microsoft Bob – elrejtve, tömörítve, titkosítva, 10 MB-nyi „zajként” a lemezképen.

Windows Product Activation: mi volt a cél?

A Windows XP volt az első széles körben elterjedt Microsoft asztali operációs rendszer, amely komoly, hardverhez kötött termékaktiválási rendszert vezetett be. A WPA célja az volt, hogy:

• megakadályozza a tömeges, azonos kulccsal történő illegális telepítéseket,
• összekösse a termékkulcsot egy adott gép hardverkonfigurációjával,
• online vagy telefonos aktivációval ellenőrizze a kulcs érvényességét.

Plummer elmondása szerint ő nem a kulcsok mögötti matematikai rendszert tervezte – azt a „nagyon nagy fejű” kriptográfusok és licencrendszer-szakértők készítették –, hanem az operációs rendszerbe épített védelmi és integrációs réteget: hogyan ellenőrzi a rendszer a médiát, hogyan kezeli a különböző kiadásokat, és hogyan kapcsolódik az aktivációs folyamathoz.

Retail vs. Volume Licensing: miért kellett külön „corporate” média?

A Microsoftnak két alapvetően eltérő felhasználói csoportja volt:

• kiskereskedelmi (retail) felhasználók – dobozos vagy OEM (előtelepített) Windows, egyedi kulcs, aktiválás online/telefonon;
• nagyvállalati ügyfelek – több száz vagy több tízezer PC, központi telepítés, gyakran offline gépek, saját belső telepítési folyamatokkal.

A nagyvállalatok számára az lett volna gyakorlatilag kezelhetetlen, ha minden egyes gépet külön-külön aktiválni kellene a Microsoft felé. Erre született a Volume Licensing modell, amelyhez külön volume media (volume licenc lemezkép) és Volume License Key (VLK) tartozott.

A rendszer egyik alapelve az volt, hogy:

• a volume kulcs csak a volume médiát tudja „feloldani”,
• egy retail CD-t soha nem lehetett érvényesíteni volume kulccsal,
• a két világ (retail és volume) technikailag is el volt választva.

Ez a szétválasztás kulcsfontosságú volt: ha egy volume kulcs működött volna bármilyen, boltban kapható XP CD-vel, a kalózkodás még gyorsabban és még szélesebb körben terjedhetett volna.

A „rejtett bizonyíték”: 10 MB-nyi Microsoft Bob a lemez mélyén

Hogyan tudja a rendszer megkülönböztetni, hogy egy adott lemez retail vagy volume? Plummer megoldása az volt, hogy a volume média tartalmazott egy speciális, csak ott jelenlévő bináris blobot, nagyjából 10 MB-nyi adatot. Ez az adat:

• magas entrópiájú, „zajos” bináris tartalom volt,
• nem volt könnyen tömöríthető,
• csak a volume lemezeken szerepelt, a retail médián nem.

A meglepő csavar: ez a 10 MB-nyi titkosított adat Microsoft Bob volt. Plummer fogta a Microsoft Bob lemezének adatait, majd többszörösen tömörítette és titkosította. A célja nem az volt, hogy Bobot „elrejtse”, hanem hogy jó minőségű, kvázi-véletlenszerű bináris adatot kapjon, amelyet a rendszer hash-elni és ellenőrizni tud.

Plummer saját bevallása szerint fiatal fejlesztőként nem volt teljesen biztos abban, hogy mennyire bízhat a CryptGenRand véletlenszám-generátorban, ezért inkább egy már eleve tömörített bináris képet (Microsoft Bob) választott alapnak, amelyet tovább tömörített és titkosított. A végeredmény egy olyan blob lett, amely:

• csak a volume médián volt jelen,
• hash-elhető és ellenőrizhető volt a kulcs ellenében,
• gyakorlatilag visszafejthetetlen volt a nyilvánosság számára – Plummer szerint „még az AI korszakban sem fejtette ki senki”.

A WPA tehát nem csak a kulcs matematikai érvényességét vizsgálta, hanem azt is, hogy a lemezképen valóban ott van-e ez a speciális, titkosított Bob-adat. Ha nem, a volume kulcs nem működött.

Miért nem működött az FCKGW kulcs egy sima XP CD-vel?

Sokan emlékeznek rá, hogy az FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8 kulcsot beírva egy „sima” Windows XP telepítő CD-n a telepítés elbukott, vagy aktivációt kért. Ennek oka pontosan az előbb leírt mechanizmus:

• a kulcs volume licenc kulcs (VLK) volt,
• a retail CD nem tartalmazta a Microsoft Bobból képzett, titkosított 10 MB-os blobot,
• így a WPA ellenőrzése elbukott: a kulcs nem passzolt a médiához.

Másképp fogalmazva: nem a kulcs volt „mágikus”, hanem az a tény, hogy a kalózok kezébe egyszerre került egy érvényes VLK és a hozzá tartozó volume lemezkép. A kettő együtt tette lehetővé a látszólag „legális” telepítéseket.

Hogyan működött a WPA a volume médián?

A WPA több lépésben dolgozott:

1. Termékkulcs ellenőrzése – a beírt kulcsnak át kellett mennie a termékkulcs-ellenőrző matematikai algoritmuson. Ez a rész nem Plummer hatáskörébe tartozott, hanem a licencrendszer tervezőihez.
2. Médiaellenőrzés – a rendszer megvizsgálta a lemezképet, és ellenőrizte, hogy jelen van-e a megfelelő bináris blob (a titkosított Microsoft Bob), amely a volume médiát azonosította.
3. Hardverhez kötés / aktiváció – retail esetben a kulcsot és a hardverkonfigurációt aktiválni kellett a Microsoftnál. Volume esetben, ha a kulcs és a média együtt érvényes volt, a WPA egyszerűen kihagyta az aktivációs folyamatot, és a rendszer teljesen aktiváltnak látszott.

Ez a kombináció – érvényes VLK + megfelelő volume média – azt eredményezte, hogy az ilyen telepítések a korai Windows Update ellenőrzéseken is átmentek, mintha teljesen legitim, nagyvállalati telepítések lettek volna.

Hogyan szivárgott ki az FCKGW kulcs és a volume ISO?

A történet kritikus pontja az, amikor a Microsoft belső, nagyvállalati felhasználásra szánt „corporate” médiája és egy hozzá tartozó VLK kikerült a cég falain kívülre. Plummer beszámolója szerint:

• a Windows XP RTM (Release to Manufacturing) verziója gyártásba került,
• néhány héttel a kiskereskedelmi rajt előtt a Devils0wn (Devil’s Own) nevű warez csoport közzétett egy teljes, nem béta, „Windows XP Pro Corporate” ISO-t,
• az ISO mellé publikálták az FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8 kulcsot is,
• ez az ISO volume média volt, tehát tartalmazta a Microsoft Bobból képzett 10 MB-os blobot.

Innentől kezdve a kalózoknak két lehetőségük volt:

• egyszerűen kiírni az ISO-t CD-re, és a kulcsot ráírni filctollal (Sharpie) – a legendás fotó a „FCKGW” feliratú lemezről ebből a korszakból származik,
• vagy a kulcsot „belesütni” módosított telepítőképekbe, hogy a felhasználónak még be sem kelljen írnia.

A kiszivárgás forrása nem ismert teljes bizonyossággal. Plummer is csak annyit mond, hogy a legvalószínűbb, hogy egy OEM vagy hardverpartner (például nagy PC-gyártó) lehetett az eredeti forrás, mivel:

• nagyon kevés szervezet rendelkezett ilyen korán volume médiával és VLK-val,
• ezeknek a partnereknek időben meg kellett kapniuk a végleges médiát, hogy a rajtra kész gépeket szállíthassanak.

Konkrét névvel kapcsolatban a közösségben gyakran emlegetnek nagy OEM-eket, de Plummer hangsúlyozza: nem tudja biztosan, ki volt a forrás. Az viszont tény, hogy a kiszivárgás még a kiskereskedelmi rajt előtt megtörtént, így a WPA hardverhez kötött aktivációs mechanizmusa a volume ágon gyakorlatilag sosem kapott esélyt teljesen betölteni a szerepét.

Mi történt ezután? Feketelistázás, SP1, SP2 és WGA

A Microsoft reakciója több lépcsőben érkezett. Plummer szerint a kiszivárgott kulcsokhoz tartozó Product ID-ket (PID) a cég elkezdte feketelistázni. Az FCKGW kulcs egy úgynevezett „640-es tartományba” eső PID-re fordult le, amelyet később „toxikusnak” minősítettek.

A gyakorlatban ez azt jelentette, hogy:

• Service Pack 1 – elkezdte blokkolni a kiszivárgott kulcsokhoz tartozó PID-eket,
• Service Pack 2 és a Windows Genuine Advantage (WGA) – tovább szigorította az ellenőrzést, és bizonyos esetekben már a frissítések letöltését is megtagadta az ilyen telepítésektől.

Fontos, hogy a Microsoft nem kapcsolta le teljesen a volume licencelési csatornát. A nem kiszivárgott VLK-k és a hozzájuk tartozó volume média továbbra is működött, hiszen a nagyvállalati ügyfelek számára ez kritikus funkció volt. A célzott feketelistázás a konkrétan ismert, kompromittált kulcsokra és PID-ekre irányult.

Tervezési kompromisszum: kényelem vs. kockázat

A történet tanulsága technikai és üzleti szempontból is érdekes. A tervezési döntés a következő volt:

• Cél: a nagy, megbízhatónak tekintett ügyfelek számára kényelmes, offline telepítési út biztosítása,
• Eszköz: külön volume média + VLK, aktiváció nélküli, de ellenőrzött telepítési folyamat,
• Védelem: a média és a kulcs szoros összekapcsolása (Bob-blob + kulcs-matematika).

A tervezés technikailag működött: egy volume kulcs nem tudta „feltörni” a retail médiát, és a WPA csak akkor engedte át a telepítést aktiváció nélkül, ha a kulcs és a média együtt érvényes volt. A működési hiba az volt, hogy:

• a volume média és egy érvényes VLK kiszivárgott a Microsoftból vagy partnerei köréből,
• ez még azelőtt történt, hogy a termék a boltok polcaira került volna,
• innentől kezdve a WPA hardverhez kötött aktivációs mechanizmusa a volume ágon gyakorlatilag „kikapcsolt állapotban” maradt a kalózverziók számára.

Ez a kompromisszum jól mutatja, mennyire nehéz egyensúlyt találni a felhasználói kényelem (nagyvállalati telepítések egyszerűsége) és a biztonság/licencvédelem között. A rendszer technikailag kifinomult volt – a Microsoft Bobot titkosított „zajként” használni a médiaazonosításhoz kifejezetten kreatív megoldás –, de a leggyengébb láncszem végül az emberi tényező és az ellátási lánc lett.

Érdekességek és utóélet

• Microsoft Bob mint rejtett payload – kevesen gondolnák, hogy a sokat gúnyolt Microsoft Bob egy része évekig ott lapult a Windows XP volume lemezein, többszörösen tömörítve és titkosítva, pusztán „jó minőségű random adatként”.
• „Mágikus kulcs” mítosz – a közösségi emlékezetben az FCKGW kulcs sokszor úgy él, mint egy univerzális „mesterkulcs”. A valóságban ez egy konkrét VLK volt, amely csak a megfelelő volume médiával együtt működött.
• AI-korszak és Bob – Plummer szerint a mai napig, még a mesterséges intelligencia és modern visszafejtő eszközök korában sem sikerült senkinek ténylegesen kinyerni a Bob-adatot a volume lemezekről. A többszörös tömörítés és titkosítás, valamint az ismeretlen kulcsok miatt ez gyakorlatilag értelmetlen feladat lenne.

Összegzés: mit tanulhatunk ebből Linuxos szemmel?

Linuxos, nyílt forráskódú közösségként érdekes kívülről szemlélni egy ilyen, erősen zárt, licencközpontú rendszer működését. A Windows XP WPA és az FCKGW története jól rávilágít arra, hogy:

• a technikai védelem (kriptográfia, médiaellenőrzés, hardverhez kötés) önmagában nem elég, ha a kulcsok és médiák kezelése nem biztonságos,
• a kényelmi funkciók (offline volume telepítés) gyakran új támadási felületet nyitnak,
• a szoftverterjesztés és licencelés üzleti döntései legalább annyira meghatározzák a biztonságot, mint a kód minősége.

Ugyanakkor technikai szempontból nehéz nem elismerni a kreativitást: egy kudarcot vallott terméket (Microsoft Bob) ilyen módon újrahasznosítani, mint magas entrópiájú, titkosított „bizonyítékot” a volume médián, kifejezetten elegáns mérnöki húzás. A FCKGW-kulcs legendája mögött tehát nem varázslat, hanem nagyon is konkrét, jól átgondolt – és emberi hibák által mégis megkerülhető – technikai rendszer állt.