[ Leírás ] Az EterPack

[masodikbela]

Szóval eljött az ideje az első posztnak, úgyhogy mivel a következő az EterWizard lesz, ezért összerakok egy átfogó ismeretterjesztőt az eterpackról és annak működéséről, illetve bizonyos gyengeségeiről is szó lesz a témában. Az ötlet igazából onnan jött, hogy gyakorlatilag egy évtizede használjuk már, és mégis senki semmit nem tud róla...

EterPack?

A Metin2 adatfájlait (alapból *.eix, *.epk) hívjuk így. Ugyebár mindenki látott már ilyeneket, az *.eix (feltételezem EterIndex, vagy EterpackIndex) tartalmazzák az adott csomag fájlneveit/"elérési útját", illetve információkat arról, hogy melyik fájl hol található a packban (*.epk, feltételezem EterPack ), ahol ugyebár fizikailag tárolva vannak a fájlok.

Az index

Nos ugyebár az előbb említettem nagy vonalakban, hogy mi is a szerepe, de nézzünk bele kicsit mélyebben a dologba.
Az index alapjáratom minimum 12 byte hosszú, ez alatt semmiféleképpen nem nem beszélhetünk index fájlról, hiszem az index alapból így épül fel:

• header, 12 byte (lásd: CEterPack::__BuildIndex(CEterFileDict& rkFileDict, bool bOverwrite))
  
  1. fourCC ->  4 x BYTE = DWORD hosszúságú, ez azonosítja az index fájl kódolásának típusát (egyeseknek biztos feltűnt, hogyha ránéznek hex editorban az indexre, akkor látják ezt)
     Típusok:
     • EPKD: titkosítás: nincs compress: nincs (alapból nem ez van beállítva csomagolásnál)
       
     • MCOZ:
         titkosítás: 4 kulcsos TEA titkosítás (legtöbb kliensben ez az egy titkosítás van használva, pack fájlok nincsenek titkosítva)
         compress: szokásos lzo1x-es compress, ami egyébként nagyon jó arányú tömörítést végez
       Alapból ezt használja a csomagoló.
       
     Át lehet írni, ha egyedit szeretnél, értelme nem sok, egy mozdulattal lehet módosítani, szerepe azonban a csomagoló számára fontos, így tudja azonosítani az index fájl "típusát" (mivel lett compresselve, cryptelve, stb...)
     
  2. verziószám -> 1x DWORD (4 Byte): értelme nem sok van, gondolom korábban a ymir átcsomagolta a fájlokat és nem szerette volna, hogy a régi fájlok működjenek a kliensben. Át lehet írni, mivel alapból a csomagolók szűrik, viszont egyrészt könnyen módosítható, másrészt ki is lehet venni a csomagolókból az ellenőrzését. (+ csomagoló ad rá syserrt is, hogy mi a baj kicsomagolásnál).
     
  3. indexek száma -> 1x long (4 Byte): valódi fájlok számát tartalmazza, azaz hogy hány darab "index" van a későbbiekben a fájlban (területszámításhoz kell (pl for loop, stb...)).
     
• indexek (186 (crc ellenőrzés esetén, md5 esetén 198) byte * indexek száma a mérete).
  [Csak regisztrált felhasználók láthatják ezt a tartalmat.]
  egy kép a structról. Ezeknek a feladata a fájlok nevének, és adatainak tárolása, mint pl hol foglal helyet az adatfájlban, mekkora a mérete, mi a checksumja, mivel lett csomagolva, stb (gondolom a képen egyértelműen látszik).
  Itt már jobban van értelme módosítást végrehajtani. Például crc helyett md5-öt használni, vagy akár csak + byteokkal megnövelni a structot, és máris képtelenek más bontók hasznosítani az index fájlunkat. (Nem egy nagy védelem, ASM-hez jobban értők simán visszakeresik a structod méretét.)
  

Szóval mint az látható, index fájl nem FELTÉTLENÜL szükséges bontáshoz. Persze elég bonyolult úgy bontani, hogy nem tudod a fájl konkrét méretét, vagy nevét, de ha a pack fájl nincs titkosítva, akkor esetleg egy ilyet is meg lehet játszani.
Érdekesség, hogy csupán az index fájl használatával lehet készíteni olyan toolt, amely bizonyos fájlokat megkeres anélkül, hogy kibontanád a teljes packot. Későbbiekben ha lesz rá időm, biztosan fogok egy ilyet is valahova kirakni

A data fájl

Nos mint a neve is mondja, itt vannak fizikailag tárolva a fájlok, ezeket indexeli az eix fájl. Túl sok dolgot nem lehet róla elmondani, mivel szimplán és egyszerűen nem áll másból, mint adatból. Na persze fontos megemlíteni itt is a kódolásokat és a compresst.
Típusok (typek szerint):

• COMPRESSED_TYPE_NONE (type 0): Nos ez az a verzió, ami gyakorlatilag csak egymás mellé beteszi a fájlba a kliens fájljait.
  [Csak regisztrált felhasználók láthatják ezt a tartalmat.]
    Titkosítás: nincs
    Compress: nincs
  
• COMPRESSED_TYPE_COMPRESS (type 1): Neve gondolom mindent elárul, simán csak compressel. Ebben az esetben már nem csak a fájlok vannak tárolva a packban, hanem a compresshez szükséges
  [Csak regisztrált felhasználók láthatják ezt a tartalmat.]
  is. Erről elég annyit tudni, hogy minden fájl elé kerül egy ilyen.
    Titkosítás: nincs
    Compress: lzo1x-es compress
  
• COMPRESSED_TYPE_SECURITY (type 2): Számomra ez tetszik a legjobban, mivel ennek konkrétan megvan az algoritmusa, és lehet módosítani, nem úgy, mint a következő esetekben. Mint azt a neve is mondja, itt már compress és titkosítás is van, a header pedig továbbra is ugyan az, mint a korábbi esetben.
    Titkosítás: 4 kulcsos TEA titkosítás (hasonló mint az index esetében, csak más a kulcs)
    Compress: lzo1x-es compress
  
• COMPRESSED_TYPE_PANAMA (type 3): Nem tudok róla sokat elmondani, mivel type 2-nél nagyobb titkosítást nem használtam még, ha egyszer lesz időm jobban utána fogok járni.
    Titkosítás: cryptoPP-s panama
    Compress: ? (szerintem nincsen, hacsak a panama alapból nem compressel)
  
• COMPRESSED_TYPE_HYBRIDCRYPT (type 4): Nagyjából annyit tudok róla, hogy a szerver küldi el bejelentkezés után a kulcsokat, amik a kibontáshoz kellenek. Hasonló barátja a COMPRESSED_TYPE_HYBRIDCRYPT_WITHSDB (type 5) ami annyiban különbözik tőle, hogy részlegesen bontja ki a fájlokat, tehát mindig csak annyit, amennyi szükséges (pl mapváltáskor szokott a kliens SDB kulcsokat küldeni).
  

Érdekességnek még elmondható a csomagolásról, hogy az index fájl kódolása a csomagolás végén történik.

Compress és crypt előtt:

Utána:

A TEA cipher

[Csak regisztrált felhasználók láthatják ezt a tartalmat.]Spoiler:

Nos érdemes megnyitni a tea.cpp-t, mivel minden fontos dolog ezzel kapcsolatban ott található. A titkosítás a tea_encrypt függvénnyel kezdődik, ezt hívhatjuk meg ha valamit titkosítani akarunk. Ez a funkció készíti elő az adatot a cryptelésre. Láthatóan nem egyben történik a titkosítás, hanem bizonyos darabokra osztottan.

Ezután eljutunk a

[Csak regisztrált felhasználók láthatják ezt a tartalmat.]

. Igen igen, itt láthatunk pár veszélyes alien jelet, mint pl a shiftelés (<< >>), XORolás (^), ANDolás (&), összeadás (+), és végül kivonás (-). Nem kell megijedni, és megérteni sem feltétlenül, hogy mi mire való. Kezdetnek nézzük meg, hogy a TEA hogy is működik.

[Csak regisztrált felhasználók láthatják ezt a tartalmat.]

Az adat jól láthatóan két szálon fut, és mindkét szálon máshogy "titkosítódik". A mi esetünkben az y és a z változók jelentik ezeket a szálakat.

Láthatunk előre definiált értékeket is. Az egyik ilyen a TEA_ROUND, ami azt határozz a meg, hogy ez a korábban említett titkosítás hányszor megy végig egy-egy adatblokkon. A másik ilyen a DELTA, ami egy szám, gyakorlatilag a kulcsszámításhoz használja a funkció. Ezeket akár lehet módosítani is, és ezzel már magában megakadályozhatjuk azt, hogy a kliensünket más csomagolóval kibonthassák, de erről majd később.

---

Térjünk is át ennek az egésznek a gyengeségeire, és hogy hogyan javíthatunk a csomagjaink és egyben kliensünk biztonságán.

Több kulcs? Hogyan?

[Csak regisztrált felhasználók láthatják ezt a tartalmat.]Spoiler:

Nos először is beszéljünk az ANDolásról. Ugyebár az AND műveletet több helyről ismerhetjük, például digitális technika órákról (amennyiben volt), vagy akár a függvénytáblánkból, vagy akár informatika óráról, esetleg jobb helyeken matekon is volt róla szó. A lényege, hogy az azonos helyiértéken található biteket megvizsgáljuk, és amennyiben azonos mindkét szám adott helyiértékén a bit, úgy egy 1-est kap a végeredményben kapott számunk azon a helyiértéken. (példa: 00B & 11B = 00B; 01B & 11B = 01B; 10B & 11B = 10B; 11B & 11B = 11B)

Hogy erre miért is volt szükség? Nos ha jobban megnézzük a tea_code funkciónkat, láthatjuk, hogy key változót (ami ugyebár a kulcs, amit általában LZO-nak szoktunk hívni (nem értem miért, csak egy 4 x 4 byteos kulcs...)) a következő képpen indexeljük: key[sum & 3] Nos ugyebár alapjáraton 4 részes kulcsot használ a kliens, és a sum & 3 művelet végeredménye sumtól függően lehet 0, 1, 2 és 3. És ugyebár c++-ban az indexek 0-ról indulnak, tehát ergó ha a 3-as számot nagyobbra vesszük, és az eterpack.cpp-ben a kulcshoz is hozzáadunk + "fragmenteket", akkor máris több (jobban mondva hosszabb) kulcsot használ a kliensünk.

"Loopholes"

[Csak regisztrált felhasználók láthatják ezt a tartalmat.]Spoiler:

A cipher gyengesége

Nos az egész dolognak a legnagyobb gyengesége, hogy legalább 10 éve minden kliens ugyan ezt használja. Tehát például nekem nincs szükségem más kliensére, hogy az algoritmust ismerjem, mivel még a forrás is publikus hozzá. Ebből adódóan gyakorlatilag csak a kulcsra van szükségünk, és máris bonthatjuk más kliensét. A kulcsot elsőre úgy tűnhet, hogy "hah, áthelyezem 'oszt ennyi" megoldással már minden ki van védve. Nos szó sincs erről.

Az egyik módja a kulcsok megszerzésére az, hogy egy dll segítségével detourt ("elterelőt") rakunk a tea_decode funkcióba, ami gyakorlatilag a mi funkciónkat hívja meg ugyan azon argumentumokkal, ebből adódóan a kulcsok is átadódnak (hiszem az is az argumentumok között van). Ezután már csak szépen ki kell íratni a kulcsokat. Ezt a módszert használja az EterWizard is.
Ezen módszer ellen a legkönnyebb védekezési módszer ha a TEA_ROUNDOT vagy a DELTA-t átírjuk, mivel így ha meg is van a szükséges kulcs, az algoritmus már nem (teljesen) ugyan az, mint a többi kliensben. Persze jobban hozzáértők ezt az apró számkülönbséget (mert igazából erről van szó, egy számot átírtál most, gg) könnyen kiszűrik, de nyilván erre az országban tapasztalataim szerint nem túl sokan képesek (azok közül akik metinnel foglalkoznak), szóval ez már egy elfogadható megoldás.

Egy másik mód, hogy a kulcsokat meghosszabbítjuk. Természetesen ezen esetben is fennáll annak az eshetősége, hogy jobban hozzáértő személy ránéz, és megmondja a turpisságot, de ez már nem olyan, mintha egy számot írtál volna át.

Egy harmadik mód (igazából a 2. kiegészítése) az, hogy készítesz egy "kulcsgyártó" algoritmust. Ebben az esetben fizikailag nem található meg a kulcs a kliensben, mivel "dinamikusan" (nem random!) gyártódnak le a kulcsok valaminek a függvényében. Ez már egy kicsit komolyabb módszer. (Én személy szerint ezt az elvet követtem a playhardos csomagoló megalkotásánál.)

Esetlegesen egy negyedik mód is szóba jöhet: cseréld le az egész TEA ciphert, használj valami egyedit. Pl metin2deven akár már 10€-ért kaphatsz egy ciphert, esetleg érdemes ennyit rászánni (én nem tudok ajánlani egyet sem, mivel nem vettem még senkitől soha).

A kliens gyengesége

Nos ebből több is van. Az egyik ilyen, hogy alapjáraton a csomagolóban található egy Extract() funkció az eterpackon belül, így lehetőség van minden komolyabb erőfeszítés nélkül ezen funkció meghívására. Ez minden bonyodalom nélkül ki fogja pakolni neked az egész eterpack tartalmát (ugyebár ez classon belül található, így az egyetlen probléma csak az, hogy minden eterpack fájl ami be van töltve a kliensbe egy ilyen classt kap, amin belül gyakorlatilag tárolva van).

Erre gyakorlatilag még nincs tool, mondjuk mi már tervezünk egy ilyet is készíteni. Legegyszerűbb módja a kivédésnek, hogy a kliensből takarítsuk el ezt a funkciót.

Másik ilyen probléma, hogy a kliens ugyebár cacheli a fájlokat alapjáraton. Na most ez nekünk okozhat problémát, mivel én nemrégiben láttam olyan toolt, ami szépen ebből a cacheből kirángatta a fájlokat. Sajnos nem volt szerencsém komolyabban megvizsgálni ezt az eszközt, mivel nem kaptam készhez, viszont a "használója" volt olyan rendes, és tesztelt nekem egy-két dolgot, így sikerült rájönnöm, hogy a cachet használja valahogyan.

Megoldás: cache kikapcsolása. Amúgy sem volt túl sok értelme, én nem vettem észre teljesítményváltozást mióta a kliens nem használja ezt a cachet. Ez a CEterPackManager::LoadStaticCache funkció kiiktatásával tehető meg legegyszerűbben.

Oké, tegyük fel, hogy vettünk egyedi ciphert, tutira 100%, hogy soha senki nem bontja ki, dll-t se tudnak bele injectelni, az egész már űberfancymenciszuperzsírkirály. Igen ám... de ha nem távolítjuk el a korábbi csomagolási metódusokat, esetlegesen adódhatnak kellemetlenségeink ebből. Tehát ugyebár korábban említettem, hogy lehetséges mind az index fájlt, mind a pack fájt mindenféle csomagolás és compress nélkül csomagolni, és ezt is képes a kliens felhasználni. Nos igen, ha ezzel nem is tudnak olyan fajta kárt okozni, hogy kilopnak valamit a kliensből, hackeléshez viszont ideális lehet. Én egy sima kis egyszerű pc fájlt csomagolok, vagy esetleg egy alap rootot, amiben aztán kijavítom a crasheket amik inkompatibilitásból adódnak, és máris lehet tolni a dmgt meg a multit meg mindent, mert benne maradt ez az opció is.

Megoldás: EterPack.cpp-ben a __BuildIndex funkcióban kiiktatni az if (fourcc == eterpack::c_IndexCC) ágat (ugye ha ezt a fourcc-t találja az index fájlban, akkor nem próbálja meg decryptelni az indexet). Továbbá érdemes a get és get2 funkciókból kiszedni a használatban nem lévő titkosítási metódusokat, így biztosan nem fogja a kliens betölteni a többi ciphert.

---

Ha már az eterpacknál tartunk, esetleg felmerülhet még az a kérdés, hogy hogyan készíthetünk egyedi csomagolót. Nos a tools mappában találhatunk egy makepack nevé projectet, azzal el lehet játszadozni. Esetleg lehet használni az én packmakeremet is (ami hamarosan ide is felkerül) ami gyakorlatilag az eredeti, kisebb fixekkel és felhasználóbarátabb átalakítással.

Gyakorlatilag ennyi, amit így hirtelenjében érdemesnek találtam leírni. Esetlegesen ha valaki érdeklődő az eterpackkal kapcsolatban, és van további kérdése, a topicban nyugodtan felteheti, és megpróbálok rá választ adni