Xbox 360 reset glitch hack - az új házi fejlesztésű hack

Bevezetés / néhány fontos tény:

Tmbinc maga mondta, hogy az aláíratlan kód futtatása az X360-on szoftver alapú megközelítéssel többnyire nem működik, mert úgy tervezték, hogy szoftveres szemszögből biztonságos legyen.
A processzor a ROM-ból (1bl) kezd kódot futtatni, amely azután elkezd betölteni egy RSA-val aláírt és RC4-gyel titkosított kóddarabot a NAND-ból (CB).
A CB ezután inicializálja a processzor biztonsági rendszerét, melynek feladata, hogy valós idejű titkosítást és a fizikai DRAM memória hash-ellenőrzését elvégezze. Abból, amit találtunk kiderült, hogy AES 128-at használ titkosításra és erős (Toeplitz?) hashelést.

A titkosítás minden bootnál más, mert többek között a következőkből áll össze:
- az egész biztosítékszett egy hashéből
- az időalap számláló értékéből
- egy valódi véletlen értékből, amely a processzorba ágyazott, hardveres véletlenszám generátortól jön. A fat gépeknél ez a generátor elektronikus úton kikapcsolható, de van egy ellenőrzés a „látszólagos véletlenségre” (pusztán az 1-es értékű bitek számlálása) a CB-ben, ez csak egy látszólag megfelelő véletlen számra vár.
A CB képes valamilyen egyszerű bájtkód alapú szoftver motort futtatni, amelynek feladata főként a DRAM inicializálása. A CB tudja betölteni a következő bootloadert (ez a CD) a NAND-ból a DRAM-ba és futtatni azt.
Alapvetően a CD fogja betölteni az alapkernelt a NAND-ból, megpatchelni és futtatni azt.
Ez a kernel tartalmaz egy kicsi, kiváltságos kóddarabkát (ez a hypervisor), ami az egyetlen kód, amelynek elég jogosultsága van aláíratlan kódot futtatni, mikor a konzol működik.
A 4532/4548-as verziószámú kernelekben, egy kritikus biztonsági rés jelent meg, és minden ismert X360 hacknek szüksége van egyre ezek közül, hogy kihasználhassák ezt a biztonsági rést és aláíratlan kódot futtassanak.
A mostani X360-asokon, a CD tartalmaz egy hasht erről a két kernelről, és megállítja a boot folyamatot, ha megpróbálsz egyet betölteni közülük.
A hypervisor egy viszonylag kicsi kóddarabka, amely hibák után kutat, és nyilvánvalóan egy újabbnak sincs semmilyen hibája, amely lehetővé tenné az aláíratlan kód futtatását.
Másrészről tmbinc mondta, hogy a 360-at nem úgy tervezték, hogy ellenálljon bizonyos hardveres támadásoknak, mit például amilyen az időzítés támadás és a glitchelés.
A glitchelés itt alapvetően a processzor hibák triggerelésének folyamata elektronikus értelembe véve. Ez a módszert használtuk, hogy lehetővé tegyük aláíratlan kód futtatását.

A reset glitchről néhány szóban:

Azt találtuk ki, hogy folyamatosan pici reset impulzusokat küldünk a processzornak, amíg az annyira lelassul, hogy nem indítja újra magát, de helyette megváltoztatja a kód futtatását. Ez nagyon hatásos abban, hogy a bootloaderek memcmp funkciói úgy megváltozzanak, hogy azok visszatérési értéke mindig ”nincs különbség” legyen. A memcmp-t gyakran használják, hogy összehasonlítsák a következő bootloader SHA hash-értékét egy letárolttal, és engedélyezze annak futását, ha a két érték egyezik. Így a NAND-ba beletehetünk egy olyan bootloadert, amely megbukik a hash-ellenőrzésen és glitcheljük az előző bootloadert, amely lehetővé teszi szinte bármilyen kód futtatását.

A fat hack részletei:

A fat gépeken a bootloader, amit mi glitchelünk a CB, így olyan CD-t tudunk futtatni, amilyet akarunk. Cjak észrevette, hogy a CPU_PLL_BYPASS jel érvényesítésével a CPU órajel sokat lassul, és van egy tesztpont az alaplapon, itt a CPU órajelének törtrésze mérhető. 200 MHz, amikor a dashboard fut, 66.6 MHz amikor a konzol bootol, és 520 KHz amikor a jel érvényesítve van.

Valahogy így néz ki a dolog:

- POST 36 kódnál érvényre juttatjuk a CPU_PLL_BYPASS jelet
- a POST 39 kezdetére várunk (POST 39 az a memcmp funkció, amely a tárolt hasht és az image hasht hasonlítja össze) és elindítunk egy számlálót
- amikor a számláló elért egy pontos értéket (ez gyakran a POST 39 hosszának a 62%-ánál van), akkor küldünk egy 100ns-os CPU_RESET impulzust
- várunk egy kis időt és ezután érvénytelenítjük a CPU_PLL_BYPASS jelet
- a CPU sebessége visszatér normális értékre, és egy kis szerencsével, ahelyett, hogy POST AD hibát kapnánk a boot folyamat folytatódik és a CB a mi egyedi CD-nket futtatja.

A NAND tartalmazza a zéróparitású CB-t, a mi payloadunkat az egyedi CD-ben és egy módosított SMC image-t.
Természetesen a glitch ebben a formában megbízhatatlan, így egy módosított SMC image-t használunk (például a gyári image 5-ször bootol újra, mielőtt RROD-t dobna), ami végtelen sokszor újraindul, amíg a konzol helyesen be nem bootolt.
A bekapcsolástól számítva, a legtöbb esetben a glitch kevesebb, mint 30 másodperc alatt sikerült.

A slim hack részletei:

A bootloader, amit glitchelünk a CB_A, így olyan CB_B tudunk futtatni, amilyet akarunk.
A slim gépek alaplapján nem találtunk CPU_PLL_BYPASS jelvezetéket.
Az első ötletünk az volt, hogy kivesszük az X360 27 MHz-es mester kristályát és saját órajelet generálunk helyette, de ez egy bonyolult módosítás volt és nem hozott jó eredményeket.
Más módszer után néztünk, hogy lelassítsuk az órajelet. Felfedeztük, hogy a HANA chipnek van egy konfigurálható PLL regisztere egy 100 MHz-es órajelhez, ami CPU-t és a GPU-t differenciális párban hajtja.
Nyilvánvalóan ezeket a regisztereket az SMC írja az I2C buszon keresztül.
Az I2C busz szabadon elérhető, még a J2C3-as foglalatra is ki van vezetve.
Így a fegyverválasztásnál a HANA chip mellett döntöttünk, hogy lelassítsuk az CPU-t (sajna tmbinc, mindig nem lehet igazad, nem unalmas és egy érdekes buszon ül ).

Valahogy így néz ki a dolog:

- leküldünk egy I2C parancsot a HANA-nak, hogy lelassítsuk a CPU-t POST D8 kódnál
- a POST DA kezdetére várunk (POST DA az a memcmp funkció, amely a tárolt hasht és az image hasht hasonlítja össze) és elindítunk egy számlálót
- amikor a számláló elért egy pontos értéket, akkor egy 20 ns-es CPU_RESET impulzust küldünk
- várunk egy kicsit és az után egy I2C parancsot küldünk a HANA-nak, hogy állítsa vissza a szokásosra a CPU órajelét
- a CPU sebessége visszatér normális értékre, és egy kis szerencsével,ahelyett, hogy POST F2 hibát kapnánk a boot folyamat folyatódik és a CB_A a mi egyedi CB_B-ket futtatja.

Amikor a CB_B elindul, a DRAM még nincs inicializálva. Ahhoz, hogy bármilyen CD-t futtatni tudjon néhány patchelést kell rajta elvégezni.
Ezek a következők:
- mindig aktív zéróparitás mód, így módosított SMC image-t tudunk használni
- nem fejti vissza a CD-t, helyette egy szöveges CD-t vár a NAND-ban
- ne állítsa le a boot folyamatot, ha a CD hash-értéke nem jó

CB_B RC4 eljárással titkosított, a kulcsok a CPU kulcsból származnak, így hogy is patcheljük a CB_B anélkül hogy tudnánk a CPU kulcsot?

Az RC4 titkosítás alapvetően = szöveg és pszeudó – véletlenszerű – kulcsfolyam kizáró vagy kapcsolata

Ha ismerjük a szöveget és a titkosítást, úgy megkaphatjuk a kulcsfolyamot és a kulcsfolyammal le tudjuk titkosítani a saját kódunkat.

Valahogy így néz ki a dolog:

- a sejtett pszeudó-véletlenszerű- kulcsfolyam = titkosítás és a szöveg kizáró vagy kapcsolata
- az új titkosítás = a sejtett pszeudó - véletlenszerű- kulcsfolyam és a szöveg-patch kizáró vagy kapcsolata

Azt gondolhatnád, hogy itt a „tyúk és a tojás” problémája áll fenn, hogy kerül a szöveg az első helyre?

Egyszerű: a fat gépekből megvoltak a szöveges CB-k és úgy gondoltuk, hogy a kód első pár bájtja ugyanaz lenne, mint az új CB_B esetében. Így titkosítani tudunk egy kis darab kódot, hogy kinyerjük a CPU kulcsot és visszafejtsük a CB_B-t.
A NAND tartalmazza a CB_A-t, a patchelt CB_B-t, a mi payloadunkat egy egyedi szöveges CD-ben és a módosított SMC image-t.
Az SMC image úgy lett módosítva, hogy végtelen számú újraindítást hajtson végre, valamint gátoljuk a periodikus I2C parancs küldésében, amíg mi a sajátunkat küldjük.
Lehet, hogy még nem esett le számodra, de a CB_ A nem tartalmaz ellenőrzést a visszahívott biztosítékokról, így ez egy patchelhetetlen hack!

Fenntartások:

Semmi sem tökéletes, így van pár fenntartás a hackkel kapcsolatban:
- a glitch amit találtunk eléggé megbízható ( átlagosan próbálkozásonként 25% a sikerrátája), igénybe vesz néhány percet, míg az aláíratlan kód bebootol.
- a sikerráta úgy tűnik, valami olyasmitől függ, mint annak bootloadernek a hash-értéke, amit futtatni akarunk.
- precíz és gyors hardvert igényel, ami képes reset impulzust küldeni.

Jelenlegi megoldásunk:

Xilinx CoolRunner II CPLD (xc2c64a) fejlesztői panelt használtunk, mert gyors, precíz, frissíthető, olcsó és képes két különböző feszültségszinttel működni egy időben.
Az X360 48 MHz-es készenléti órajelét használjuk a glitch számlálóhoz. A slim gépek hackjéhez, a számláló még 96 MHz-en megy (az órajel felfutó és lefutó élére is növekszik az értéke).
A CPLD kódja VHDL nyelven írt.
Szükségünk van ara, hogy ismerjük az aktuális POST kódot, az első implementációnk a teljes 8 bites POST portot használja, de már képesek vagyunk a POST kód egyetlen bitváltozását figyelni, ezzel később egyszerűbbé téve a forrasztást.

Következtetések:

Megpróbáltuk, hogy a hackhez szükséges eszközök semmilyen MS által levédett kódot ne tartalmazzanak.
A célja a hacknek , hogy futtassuk a Xellt vagy egyéb ingyenes szoftvert. Én (GliGli) nem azért csináltam, hogy támogassam a kalózkodást vagy bármit, ami ezzel kapcsolatos. Csupán azt akartam, hogy a hardverrel, amit vettem azt csináljak, amit akarok, beleértve a saját natív kódom futtatását.

Köszönet:
GliGlinek, Torisnak a visszafejtésért és hack fejlesztésért.
cOznak a visszafejtésért és bétatesztelésért.
Razkarnak, tuxusernek a bétatesztelésért.
cjaknak, Redline99nek, SeventhSonnak, tmbincnek (és akiket kifelejtettem volna) a megelőző visszafejtésekért és vagy 360-on való hackekért.

Fordította: korni