Mindenekelőtt kijelenteném, hogy ez csak egy technical breakdown a FoxComm 5 rendszerben található DRM-ről, letöltés/leak nem lesz itt megtalálható, és kérés esetén sem adom ki sem a telepítőt, sem a decryptelt fájlokat.
Kezdjük azzal, hogy mi is ez a FoxComm 5. Ez egy, a “2HB Informatika” (a későbbiekben 2HB) által nem hivatalosan módosított Windows 11 operációs rendszer. Ez egy megvásárolható release, amiért egyszeri árat kell fizetni, és a további frissítésekért szintén fizetni kell. A probléma ott kezdődik, hogy a rendszer megvételéhez a vásárlónak át kell mennie egy úgynevezett “3FA” hitelesítésen, ami annyit takar, hogy a 2HB számára 10 HUF összeget kell utalnia, a közleményben pedig meg kell adnia a telefonszámát. Miután ez megtörtént, a 2HB egy számukra tetszőleges időpontban megkeresi a vásárlót egy rejtett (No Caller ID) telefonszámról. Telefonos egyeztetés után a 2HB áttereli a vásárlót egy másik chat platformra (Meta Messenger, Viber, Telegram), ahol videóhívásban a vásárlónak fel kell mutatnia a személyi igazolványát és egy, a nevére szóló számlát. - Érdekesen hangzik, mi? - Sikeres “hitelesítés” után pedig megtörténik az operációs rendszer telepítése a videóhívásban. Sketchy az egész, ugye? Természetesen az ÁSZF-ük AI-generált katyvasz, ami említést sem tesz arról, hogy kezelnének okiratot. Akkor miért is kell felmutatni, hm? Érdemes még hozzátenni, hogy az ÁSZF-et csakis a telepítés után látja a vásárló, amikor már a számítógépén van a szoftver.
Térjünk is a lényegre: a “rendszerben” található DRM-re. Az operációs rendszerben a szokásos Windows 11 aktiválási rendszer található, az nem lett módosítva, a mellékelt segédprogramoknál már más a story.
A legtöbb alkalmazásban minimális DRM található, tippem szerint azért, mert benne felejtették (erről majd később). A foxmain a fő produkció.
Az olvashatóság kedvéért több rétegre bontom a védelmet: L1, L2 és így tovább. A sorrendnek nincs jelentősége.
L0? Igen, fentebb azt írtam, hogy nincs jelentősége a sorrendnek, viszont ez a - mondhatni - nulladik védelmi réteg, ami miatt nem lehet tovább bontogatni a programokat. Minden FoxComm bináris, amit a vásárló (pontosabban a segédprogramok egyike) a szerverről letölt, a vásárló gépéhez kötött egyéni titkosítással van ellátva, és hab a tortán, hogy ‘.efi’ kiterjesztést kap. Teljes bináris titkosítás alá kerül, így a program nem is futtatható. Ezt a titkosítást a letöltő/frissítő program oldja fel a felhasználó hardverazonosítójával és a szerver által adott kulccsal. A hardverazonosítót az alábbi formula alapján kreálja, és egy kis titkosítással eltárolja a ‘Barel’ registryben:
raw = WMI(ProcessorId)+WMI(BaseBoard.SerialNumber)
+WMI(CSProduct.UUID)
+WMI(BaseBoard.Product)
missing field -> "N/A"
raw = raw.replace(" ","B").replace("+","C").replace("-","D")
hwid = SHA256(raw, UTF8) -> hex UPPERCASE (64 chars)A szerver által küldött kulcs a ‘Vihar’ nevű registryben tárolódik. Érdekesség, hogy a ‘Vihar’ kulcs módosításra kerül, ha az egyik program tamper védelme aktiválódik. Ez a módosítás abban merül ki, hogy a ‘Vihar’ kulcs ‘0’ értékekkel lesz feltöltve. Ez könnyen törölhető/visszaállítható.
A teljes decryption formula az alábbi:
K(x) = PBKDF2-SHA256(UTF8(x), salt=01..08, iters=1000, 32B)
D(x, c) = AES-256-ECB(K(x)).decrypt(c).unpadPKCS7
hwid = sha256(WMI).hex.upper # bearer token
bootpw = D(hwid, b64(Vihar))[5:-11]
exe = D(bootpw, bytes(x.efi)) # "MZ"
identity = D(hwid, b64(Barel)) # == hwid
serial = D(hwid, b64(serial))
valid = RSA-SHA256-PKCS1(JSON.stringify(data), signo, NEW_MODULUS, 65537)Ó, igen, a jó öreg MITM támadás. Minden response, ami a 2HB szervere felől érkezik, validálva van kliensoldalon egy RSA-kulccsal. Ez nagyon szuper, ha a vásárló ténylegesen MITM támadás alatt áll, viszont a letöltött fájlokat nem validálja sehogy utólag. Egy kis bytepatch, és máris elfogad bármit a kliens.
Az alkalmazások a webes requestek elküldése előtt validálják a vásárló gépén található “Lunava/Licence” registryket, amelyeket később elküldenek a szervernek. A következő értékeket nézik és validálják:
Ha valamelyik érték hiányzik vagy nem megy át a validáláson, akkor egy szép kis message box jelzi nekünk, hogy “Registry Szabotázs” történt, és a program módosítja a fentebb említett Vihar registryt, ezzel jelezve, hogy piszkálva lettek a kulcsok.
A program futás közben csinál egy nagyon érdekes dolgot. Emlékszik még valaki a colos22 és HErBY közötti vitára? Akkoriban a ‘huminecraft’ kliens egy olyan vicces lépést tett, hogy mindegyik felhasználó gépén letiltotta HErBY oldalait azzal, hogy a hosts fájlban localhostra irányította a domaineket. Vicces, mi? Nos, a FoxComm se csinál jobbat: ha a hosts fájlban megtalálja a saját domainjét, a ‘dimitris.masbate.hu’-t, ezt szépen átírja ‘ne.csinald.ezt.hu’-ra. Komikus, mi? Kár, hogy bizonyos programoknál elfelejtették átírni, és a ‘magdalena.masbate.hu’ domaint keresi a program.
És a főbb védelmi rétegek végére is értünk. A legtöbbjük szimpla reversingel kiolvasható és patchelhető. Még a poén kedvéért megemlíteném a nevetséges “gyerekzár” funkciót, ami egy programba égetett érték (445500), valamint a szerver által kiadott kliens verziószámot. - Hogy micsoda? - Igen, a kliens által megjelenített verziószámokat a szerver adja ki, és nem a kliensprogram tárolja. Felesleges internetkapcsolat ellenőrzésekkel van tele a program vagy a Google-t pingeli vagy a ’http://wtfismyip.com/text’-ről kéri le a user publikus címét. Az összes bináris az Obfuscar által van “titkosítva”, amit nevetségesen egyszerű kijátszani.
Természetesen sok más nevetséges megoldás található ezekben a programokban, amelyekről, amint lehetőség adódik, készítek egy újabb bejegyzést.
Végszóként annyit tudnék mondani, hogy aki a rendszer megvásárlását fontolgatja, jól gondolja át, hogy egy ilyen gyenge védelemmel ellátott rendszert szeretne-e használni úgy, hogy a megvásárláshoz hivatal által kiállított okiratot kell felmutatnia, és csak a rendszer telepítése után látja az ÁSZF-et.
Jogilag megkérdőjelezhető, morálisan egyenesen elítélendő. Jól fontoljátok meg, hogy kiben bíztok és hova teszitek a pénzetek.