Az egész azzal kezdődött, hogy valaki a betöltési képernyő színét akarta manipulálni. Ehhez a készülék NVRAM-jában kellett módosítani egy értéket, ami viszont egy nem várt mellékhatással járt: többen is helyreállíthatatlan állapotba (bricked) juttatták ezzel a készüléküket.

Ezután bukkant fel Redditen egy olyan csomag híre, ami ezt az egészet egy újabb szintre emeli, és egy konkrét utasítással az NVRAM módosítása szándékosan vágja tönkre a készüléket. Természetesen a csomag készítője külön kiemelte, hogy ez csak egy “proof of concept”, és hogy senki se telepítse, de tényleg ne, mert nem helyrehozható a dolog. Meglepő lenne, hogy egy jailbreakelt készülék egy egyszerű utasítással tönkretehető? Pedig ez még csak nem is az első ilyen dolog.

Előzmények

A gond igazából sosem maga a jailbreak volt, az ugyanis önmagában nem fogja tönkretenni a készüléket, ellenben korlátlan hozzáférést nyújt a felhasználó számára, kikerülve minden biztonsági korlátozást, amit csak az Apple a rendszerbe épített. A nagy hatalommal ugyanakkor nagy felelősség is jár: a felhasználónak tisztában kell azzal lennie, hogy a korlátozások hatástalanítása egyben védtelenné is teszi adott esetben a rendszert, és így olyan dolgok is végrehajthatóak rajta, amik jailbreak nélkül nem lennének lehetségesek.

A legelső brickelések még az első generációs iPhone és az iPhoneOS 1.x idején voltak, amikor Zibri kilépett az iPhone Dev-Team-ből, majd a sajátjaként adta ki azt a jailbreaket, amin előtte többen dolgoztak együtt. Mivel viszont Zibri saját bevallása szerint sem értett a programozáshoz, így az általa kiadott jailbreakben több hiba is volt, amelyek miatt számtalanszor frissítette az alkalmazást. Az egyik, és legsúlyosabb ilyen hiba talán az, hogy az általa kiadott “ZiPhone” jailbreak használatakor a folyamat kérés nélkül downgrade-elte a készülék bootloaderét 3.9-re a függetlenítés miatt (hiszen annak idején először kizárólag csak az AT&T-nél volt elérhető a készülék) – ez viszont több esetben is sikertelen volt.

A bootloader piszkálgatása ugyanakkor annyira veszélyes dolog, hogy még az Apple sem tette azt a firmware-be, pedig egy huszárvágással pontot tudtak volna tenni az akkor még illegális függetlenítés végére, ha egyszerűen frissítik a bootloadert. Ennek a hibának az eredményeként az érintett készülékek tulajdonosai azt tapasztalták, hogy nem ment az EDGE (még ugye nem volt iPhone 3G, és így 3G-támogatás), vagy nem volt elérhető a Wi-Fi vagy a Bluetooth, vagy akár egyszerre mindhárom “elmúlt” a készülékről. Zibri később kiadott egy javított verziót, ez viszont az érintett készülékek esetén mindegyiknek ugyanazt a “00:5a:49:42:52:49”-es MAC címet adta – ami viszont nem más, mint Zibri neve ASCII kódban… Minden egyes hálózati eszköz egyedi MAC címmel rendelkezik, így nyilvánvaló, hogy ez miért is problémás, azon túl, hogy ebben is csak saját magát élte ki. No persze ehhez az adott felhasználónak egy külön szoftvert kellett lefuttatnia, így nem egy, a készülékre letöltött csomag okozta mindezt.

A BootNeuter ezzel szemben már egy, a Cydiából letölthető alkalmazás, ami képes az első generációs iPhone (iPhone 2G) esetén felülírni nemcsak a bootloadert, de a basebandet is, így téve maradandóan függetlenné az adott készüléket.

A BootNeuter használatáról itt írtunk bővebben: Az iPhone 2G gyári függetlenítése.

Szintén a basebandet tudja birizgálni, de csak az 5.8-as bootloaderrel rendelkező iPhone 3G-k esetén a fuzzyband illetve a pHaseBanDowngrader is. A segítségükkel lehetséges adott baseband-verzió visszaírása, és ennek köszönhetően az adott basebanddel működő szoftveres függetlenítés lehetővé válik.

A készülék basebandjét piszkálni ugyanakkor nem feltétlen tanácsos, ahogyan azt az iPad basebandet (06.15.00) felhasználó függetlenítés esetén is láthattuk már: az iPad baseband nem telepíthető fel a 2011 35. hetén és azután gyártott iPhone 3GS-ekre. Az ilyen készülékeken az iPad baseband visszavonhatatlan kárt okoz, amit az azóta már megjelent iPad baseband downgrade sem tud helyrehozni, a készülék bricked.

Az évek során elérhetővé vált szoftverek tehát már bizonyították, hogy azokkal adott esetben végleg tönkre lehet tenni egy készüléket, de azért ezek működése lényegesen bonyolultabb, mint egy egyszerű parancs lefuttatása.

Az NVRAM és a DClr

Az NVRAM olyan memóriarész a NOR chipen belül, ami “nem felejti el” az abban tárolt tartalmat kikapcsoláskor (a normál RAM tartalma kikapcsoláskor elvész). Az iOS-t futtató eszközök esetén az NVRAM a különböző környezeti változók értékeit tárolja, ilyen például az alma logó és a háttér színe bekapcsolás közben.

Ezt a színt a DClr nevű, 32 hexa karakterből álló, 16 bájt hosszú változó tárolja, ami csak iPhone 5-től kezdve létezik. Ez teszi lehetővé, hogy a fekete színű készülékek betöltés közben fekete háttérrel fehér alma logót, a fehér (és arany) készülékek pedig fehér háttér előtt fekete almát mutassanak a SpringBoard betöltődéséig, amikor is az átveszi a képernyő tartalmát, majd betölti a grafikus felületet:

A betöltéskor a következő játszódik le: a készülék beolvassa a DClr_override változó értékét az NVRAM-ból. Ha ilyen változó nincs, akkor a rendszer a DClr-t fogja keresni a Syscfg alatt. Ha ott nem talál ilyet, akkor pedig a ClrC-ből olvassa be ezt az értéket. Ez eddig még rendben is van.

A gond az, hogy ennek a változónak az értéke mindössze egyetlen paranccsal módosítható – ami önmagában még nem lenne gond, mert a változó szintén egyetlen paranccsal törölhető is. A gond akkor van, ha a DClr_override nem megfelelő értéket kap. Ekkor ugyanis az iBoot meg fogja tagadni a DeviceTree betöltését, ami miatt a készülék nem fog tovább bootolni. Mivel az NVRAM tartalmát még egy restore sem írja felül, így ezzel a készülék a jelenleg elérhető módszerekkel javíthatatlan állapotba kerül.

Mennyire kell ettől tartani?

Ha nem jailbreakeljük a készüléket, akkor nyilván ez nem érint minket, az App Store-os appok esetén meg nem kell ilyesmitől tartanunk.

Mivel jailbreak után root jogosultsággal teljes hozzáférésünk van a rendszerhez, egy megfelelően előkészített cydiás csomag lefuttathatja azt a parancsot is, ami az NVRAM-ba írja a DClr_override olyan értékét, amitől az iBoot kiakad, ezzel brickelve a készülékünket. A veszély tehát jailbreakelt készülékek esetén valós, ugyanakkor ha szokás szerint odafigyelünk arra, hogy honnan és mit telepítünk a Cydiában, akkor valószínűleg nincs mitől tartanunk.

További probléma, hogy amennyiben a készülékünkön telepítve és bekapcsolva van az OpenSSH ÉS nem változtattuk volna meg a root jelszavát, akkor ez a végzetes parancs még akár távolról, SSH-n keresztül is lefuttatható, és a következő újraindítás után már vége is a készülékünknek. Természetesen az OpenSSH nem része a jailbreaknek, aki meg mégis telepíti, az nyilván tudja, hogy mit csinál, és a root jelszavát is megváltoztatja – vagy legalább lelövi az SSH-t, ha már nem használja.

Hogyan védhető ki?

Felmerülhet, hogy ha mindez ennyire problémás, akkor miért nem töröljük le a jailbreakelt készülékről az nvram binárisát? Onnantól akkor már nem lehetne lefuttatni a végzetes parancsot. Ezt várhatóan gond nélkül megtehetjük (legalábbis egy teszt iPhone 3GS-en nekünk ezután is gond nélkül betöltött a rendszer, de ez nem jelenti azt, hogy iPhone 5 és újabb készülékeken is teljes biztonsággal így van), ám sajnos azonban ez nem akadályozza meg, hogy egy csomagba ezt a binárist is betegye annak rosszindulatú készítője.

A megelőzés legjobb módja, ha nem adunk hozzá a Cydiában ismeretlen source-okat, és nem telepítünk ilyen source-okról semmit. Nyilván itt talán nem kell külön hangsúlyozni, hogy a tört appokat és tört tweakeket tartalmazó warez-source-ok kifejezetten veszélyesek lehetnek ilyen szempontból. (Hasonlóan érdemes talán elkerülni a több ezer csomaggal bíró forrásokat is: minél több ugyanis a csomag, annál nagyobb az esélye, hogy nem megfelelő azok átnézése és átcsúszhat egy ilyesmi.)

Ha nem akarjuk letörölni az nvram binárisát, akkor átmeneti védelmet nyújthat az is, ha a jailbreakelt készüléken az /etc/profile szerkesztésével hozzáadunk egy alias-t:

• alias nvram=’echo denied’

További biztosítás, ha ezután a /etc/profile fájlt immutable-é tesszük (ezzel az nem módosítható, és így az alias sem szedhető ki):

• chflags schg /etc/profile

Fontos megjegyezni, hogy ez csak akkor nyújt védelmet, ha nem a teljes elérési úttal hivatkozik valaki az nvram parancsra.

Mivel ez csak a jailbreakes felhasználókat érinti, így elképzelhető, hogy az Apple nem nagyon fog ezzel kezdeni semmit, hiszen azt már eddig is tudhattuk, hogy mi a cég álláspontja a jailbreak kapcsán. Ha tehát jailbreakelünk, akkor érdemes nagyon odafigyelni, hogy honnan és mit telepítünk, és nem lehet elégszer hangsúlyozni, de célszerű távoltartani magunkat a wareztól, mert ott benne van a pakliban az is, hogy egy ilyenbe belefutunk. Annyit meg egy warezolt dolog sem ér, hogy a készülékünket tönkrevágjuk vele.

Figyelem! Kérünk mindenkit, hogy semmiképp se próbálja ki a parancsot (így azt nem is írtuk le itt), mert tényleg tönkreteszi vele a készülékét, amit jelenleg sehogyan sem lehet helyrehozni! Az itt leírtak el nem olvasásából vagy meg nem értéséből fakadó problémákért nem tudunk felelősséget vállalni.