Új funkcióval bővült a Cydia: megérkezett a TSS Center. Ugyanakkor ezzel egy időben a 6.x esetén mentett SHSH-k is eltűntek, de a két dolog csak közvetve függ össze. Lássuk, mi történt pontosan.

Előzetes kiegészítés: az SHSH-k felhasználhatósága az iPhone 4s óta már másképp működik, ez a cikk az újabb készülékekre már csak általánosságaiban igaz.

Hová tűntek az iOS 6-os SHSH-k?

Alább hosszabban is írunk a dolog hátteréről, de akik csak a lényegre kíváncsiak, nekik röviden összefoglalnák, miről van szó.

Saurik közzétett egy cikket pár napja, amiben leírta, hogy a Cydia által mentett iOS 6-os SHSH-k sajnos használhatatlanok. A mentett SHSH-k jelenleg csak az iPhone 4, iPhone 3GS vagy iPod touch 4G esetén használhatóak fel, ezeknél újabb készülékek esetén nem. Ha viszont TinyUmbrella segítségével, közvetlenül az Apple-től kértük le az SHSH-t, vagy a redsn0w vagy iFaith segítségével magáról az eszközről mentettük le, azokat továbbra is fel lehet használni, és ezeket újból fel lehet tölteni majd a Cydiába. Az iOS 6-nál korábbi SHSH-kat ez a probléma nem érinti.

Mikor érvényes tehát egy, az iOS 6 bármely verziójához tartozó SHSH?

Először például akkor, ha azt közvetlenül az Apple-től kértük le a TinyUmbrellával, mikor az Apple épp hivatalosan aláírta még. Ez azt jelenti, hogy a 6.1.2-höz tartozó SHSH-t a TinyUmbrellával akkor mentettük le, amikor még nem jelent meg a 6.1.3, mert ekkor az Apple épp a 6.1.2-t írta alá. Ez bármely típusú készülék esetén használható módszer, de mindig csak ahhoz a verzióhoz lehet lekérni az SHSH-t, ami az adott készülékhez legfrissebb hivatalos firmware, mert azt írja csak alá az Apple.

Másik lehetőség, ha azt a készüléken épp fent lévő iOS 6-os rendszerről mentettük le a redsn0w fetch opciójával vagy az iFaith segítségével. Ehhez olyan készülékre van szükség, ami támogatja a limera1n exploitot: ez lehet iPhone 4, iPhone 3GS vagy iPod Touch 4G. Itt mindegy, hogy az Apple éppen mit ír alá, csak az számít, hogy a készüléken éppen milyen iOS-verzió van. Ha 6.1.2 van rajta, akkor ahhoz tudjuk lementeni. Ha 6.0, akkor pedig ahhoz. iPhone 4-nél újabb készülékek esetén ez nem működik.

Ha a Cydia mentette nekünk a 6.0 – 6.1.2 közötti SHSH-kat, vagy azokat szintén a Cydiából és nem az Apple-től kértük le a TinyUmbrella segítségével, akkor azok az SHSH-k használhatatlanok.

Most lássuk kicsit részletesebben is a történetet.

Mi az a TSS?

A biztonságos rendszer egyik pillére, amikor a készülékre telepített szoftver ellenőrzésre kerül, biztosítva azt, hogy ez valóban az a szoftver, amire számítunk. Ezt kriptográfiai aláírásokkal biztosítják, amik segítségével egy-egy adatblokk hitelessége ellenőrizhető, így például egy operációs rendszeré is, mint az iOS az iPhone-on. Az Apple tehát aláírja a szoftvert, amit a készülékre kiad.

Miközben a készülék rendszere betölt, minden egyes lépés ellenőrzi a következő lépés aláírását, mielőtt továbblépne. Feltételezve, hogy minden lépés megfelelően működik, biztonságban érezhetjük magunkat annak tekintetében, hogy a készüléken az a rendszer fut, aminek kell, bármiféle olyan módosítás nélkül, amelyek nemkívánt dolgokat tehetnek (legyen az káros kód, például malware, vagy olyan kiegészítések, amelyeket nem kívántunk feltenni).

Természetesen ez a feltételezés eléggé valószínűtlen egy olyan összetett rendszer kapcsán, mint amilyen az iOS: rengeteg hiba van benne, nagyobbak és apróbbak, ami miatt a támadók kikerülhetik az ellenőrzéseket.

Nem elegendő csak magát a szoftvert aláírni, hiszen akkor amint egy hibát kijavítanak, a felhasználók egyszerűen nem frissítenek, vagy visszateszik a korábbi, a hibát még tartalmazó verziót, átveszik felette az irányítást, ami utat nyithat arra, hogy az új verzióban is találjanak hibákat.

A rendszerek fejlesztői ezt általában úgy orvosolják, hogy korlátozásokat vezetnek be, ami miatt csak az aktuálisan a készüléken lévő verzióval egyező vagy újabb kerülhet fel az eszközre. Ezt vagy a verziószám, vagy egy kódolt dátum segítségével ellenőrzik. Az Apple viszont úgy döntött, hogy ez nem elegendő, hiszen lehetővé teszi, hogy a készüléken lévő verziót bármeddig újratehessük, és ne legyünk rákényszerítve a frissebb verziókra; illetve hogy az időközben megjelent köztes szoftververziókon is nyugodtan végigmehetünk, nem pedig csak az aktuálisan legfrissebb tehető fel rögtön.

Az Apple ezt úgy oldotta meg, hogy az iOS 3.x-tól kezdődően a telepítés folyamata csak akkor indul el, ha a szoftververziót vissza tudta ellenőrizni az Apple az interneten keresztül, és a rendszer azt dobta rá vissza, hogy ez az a verzió, amit épp engedélyeznek telepíteni. Valójában már az iOS 2.x is tartalmazott aláírást, de nem volt benne downgrade elleni védelem.

Az aláírást és így a telepítendő szoftver verzióját ellenőrző szerver a Tatsu Signing Server, vagyis a TSS.

Mi az az SHSH?

Röviden összefoglalva ez az az aláírásfájl, ami a készülék számára visszaigazolja az Apple-től a telepítést, így a készülék elfogadja a telepíteni kívánt szoftvert, és a folyamat elindul. Erről kicsit részletesebben itt írtunk már korábban: Mi az az SHSH, és hogyan működik a TinyUmbrella?

Az aláírási folyamat legfontosabb része, hogy tudjuk, pontosan mi is kerül aláírásra. Az évek során ez persze változott. A Saurik által korábban leírt rendszer a folyamat során testre szabja a készülékre kerülő szoftvert. Ez a testreszabás úgy néz ki, hogy az adott eszközhöz tartozó azonosító kerül minden egyes fájlhoz, majd ezeket a fájlokat írja újból alá az Apple. Az eredeti fájlok természetesen már eleve tartalmaznak aláírást, de nincs bennük az eszköz egyedi azonosítója.

Az egyedi azonosító, amit ehhez felhasználnak, az az ECID, ami minden egyes iOS eszköz esetén egyedi. Ezután az ECID elküldésre kerül az Apple felé együtt az aláírandó fájlok listájával, majd erre az Apple szervere visszaküldi az aláírást (blob) minden, a listában szereplő fájl számára. Ezek a blobok váltják fel az eredeti aláírásokat, és már tartalmazzák a testreszabást az ECID-nek köszönhetően, valamint egy fő aláírást, ami az egész fájl tartalmát is aláírja.

Az SHSH tehát ezeket a testre szabott aláírásokat jelenti. Mivel az ECID egy adott eszköz esetén állandó, így ha le tudjuk menteni egy ilyen testre szabott fájl SHSH-ját, akkor azt a fájlt akkor is fel tudjuk tenni, ha az Apple már nem írja alá. Ez viszont kissé változott az iPhone 4s és újabb készülékek esetén.

Hogyan készülnek az SHSH-k?

Tartsunk egy kis kitérőt az aláírások kapcsán. Az aláírások esetén szükség van egy úgynevezett hash-re: amikor aláírunk egy fájlt, először vesszük a fájl hash-ét, aztán elkódoljuk ezt a hash-t (encrypt) egy titkosítási kulccsal, amit csak mi ismerünk (private key), viszont ez visszafejthető egy nyilvános kulccsal (public key).

A hash-elés eredményét általában digest-nek nevezik, ami valójában az adott fájlra jellemző, kis méretű “digitális ujjlenyomat”. Ez a kisebb fájl általában megadott méretű, ami független az eredeti fájl méretétől, ehelyett a használt kódolási algoritmus határozza meg. Az iOS ellenőrzésénél használt algoritmus az SHA-1, ami 160 bites digest-et eredményez. Az SHA-1 használatakor a digest készíthető darabonként is: vehetjük az adat egyik részét, hash-eljük, majd megállunk, aztán később vehetjük a másik részét, és azzal folytatjuk.

Az Apple is ezt használja a testre szabott aláírások készítésekor: ahelyett, hogy az egész aláírandó fájlt elküldetné a szerverére, vagy eleve ott tárolná őket, esetenként több száz MB-os fájlokat hash-elgetve, az Apple csak egy úgynevezett “partial digest”-et küld a szervernek a TSS lekérés részeként, amit a szerver így befejez, és aláírja a saját kulcsával.

Végül pedig az iOS szoftver telepítőfájljában (IPSW, ami valójában egy átnevezett ZIP) található egy úgynevezett “build manifest”, ami tartalmaz egy listát a fájlnevekkel és egyenként a hozzájuk tartozó digest-tel (ami ugye az adott fájl hash-e, valamint az ahhoz tartozó aláírás az Apple-től) és egy partial digest-tel, aláírás-blokk nélkül (így azt a TSS be tudja fejezni).

A testreszabás tehát fogja a build manifest-et, összeállítja belőle a TSS lekérést, elküldi azt az Apple-nek, visszakapja a választ, ami alapján módosítja a listában található összes fájl aláírási blokkját a TSS-től visszakapott blobokkal. Az így módosított fájlokat átküldi a folyamat a készülékre, és a készülék visszaellenőrzi belőlük az ECID-et, valamint az aláírást.

Az Apple aláírásainak mentése

Amikor az Apple elkezdte ezt az egész aláírási procedúrát, a jailbreakes fejlesztők rájöttek, hogyan működik, és egyértelmű volt, mit kell tenniük: úgynevezett man-in-the-middle módszerrel létrehoztak egy olyan szervert, ami a folyamatba ékelődve elmenti az összes SHSH-t az adott eszközök esetén, amik rajta keresztül kérik azt le az Apple-től. Ezzel lehetővé tették az adott készülékek esetén, hogy bármikor vissza lehessen tenni rájuk az aktuális verziónál korábbit. Ez nem csak a jailbreakelők számára lehet hasznos, hanem azoknak a fejlesztőknek is, akik korábbi iOS-verziókon akarják tesztelni az alkalmazásaikat.

A Saurik által a Cydiába integrált rendszer eredetileg valóban csak köztes eszközként furakodott az aláírási folyamatba, de később ez megváltozott azzal, hogy mentette az eszközök ECID-jét, így amikor az Apple újabb firmware-verziót adott ki, a Cydia képes volt tömegesen lekérni az SHSH-kat az összes regisztrált eszköz esetén.

Ennek eredménye azonban az lett, hogy olyan mennyiségű ECID került regisztrálásra, ami az SHSH-lekérések nagy száma alapján felhívta az Apple figyelmét is a dologra, és a lekérések forrását beazonosítva könnyen léphettek az ügyben, és megakadályozták a működését. Így a Cydia már nem képes man-in-the-middle módon menteni az SHSH-kat, sem automatikusan lekérni azokat a korábban regisztrált eszközökhöz.

A megoldás erre a TSS Center lett. Ezzel a készüléken futó Cydia figyelmezteti a felhasználót, ha az aktuálisan aláírt verzióhoz nincs mentve az SHSH, majd a megfelelő opcióra rányomva azt le is tudja kérni az Apple-től, és felküldi egyben a Cydiába is.

TSS Center

Az új opciót a Cydia főoldalán lefelé görgetve találjuk meg. Nyomjunk a TSS Center (SHSH & APTicket) opcióra az eléréséhez:

Ezután az oldal tetején a megszokott módon a Cydia listázza a jelenleg a készülékünkhöz tárolt SHSH-kat, és értesít minket, ha az aktuálisan aláírt verzióhoz nincs mentve az SHSH. Jelen esetben ez például a 6.1.3 lehet:

Az SHSH mentéséhez ekkor nyomjunk rá a Save 6.1.3 Now opcióra, mire elindul a lekérés, ami néhány másodpercet vesz igénybe:

Ezután az oldal tetején lévő listában meg is jelenik a frissen mentett SHSH:

Mi az az APTicket, és hogyan változtatta meg a dolgokat?

Amikor az iOS 5 megjelent, az Apple kicsit megváltoztatta az egész játékot: az SHSH kezdett eltűnni, és lassan elkezdte átvenni a helyét az APTicket. Ezért például MuscleNerd is részletesebben is beleásta magát az APTicket lelkivilágába. Mivel azonban az SHSH-k egyszerű lementését és központosított tárolását Saurik oldotta meg a Cydia segítségével, így később ő is az APTicket felszíne alá nézett, és hibákat keresett az APTicket elenőrzésében.

Az APTicket gyakorlatilag egy aláírt adatblokk és tartalmazza az összes olyan fájl aláírását, ami az eszköz betöltése során használatra kerül. Ez azt jelenti, hogy a restore során nem szükséges minden egyes fájlt egyenként testre szabni, mert az APTicket tartalmazhatja az IPSW-ből származó fájlok eredeti és érintetlen digest-jét is. Emellett drasztikusan csökkenti a szükséges aláírások számát is, amit az Apple szervereinek generálnia kellene, mikor megjelenik egy új iOS-verzió.

Az APTicket tartalmaz továbbá egy úgynevezett “nonce“-t, egy egyetlen alkalommal használt számsort, ami szintén alá van írva az egész APTickettel együtt, és a restore során ellenőrzésre kerül az ECID mellett. Ez a nonce számsor a restore folyamat során kerül generálásra véletlenszerűen, így az APTicket minden egyes restore folyamat esetén egyedi lesz, és ezért gyakorlatilag nem lehet elmenteni.

Elmenteni az elmenthetetlent

A kérdés tehát az, hogy ha az APTicket használata kiküszöböli az SHSH kapcsán kihasználható hibát, mégis miért mentik az emberek az APTicketes SHSH-kat? Mert szerencsére van két dolog, ami miatt mégis hasznuk lehet: az egyik a visszamenőleges kompatibilitás, a másik pedig néhány hiba az egész implementációban.

Először is az Apple nem tudja felülírni a már legyártott készülékek bootloaderét, így azok a restore folyamat első lépésében az SHSH-t használják. Ez azt jelenti, hogy amennyiben megvan az SHSH az első lépéshez, onnantól már nem számít, van-e APTicket a folyamat többi lépéséhez, hiszen már az első lépésnél ott a lehetőség a trükközésre. Ha pedig más nem, ez lehetőséget adhat olyan verzióra downgrade-elni, ami még nem használt APTicketet.

Másodszor pedig ott van egy igen összetett ellenőrzési rendszer, ami sok apró lépésből épül fel, és így több hibára is lehetőséget ad. Például a folyamat során valamikor a nonce újraírásra kerül: ha a nonce értéke ekkor nem változik, akkor egyszerűen lementjük az APTicket adatblokkot, és akkor már majdnem ugyanaz a helyzet, mint amikor még csak az ECID okozta a nehézségeket. MuscleNerd legjobb tudomásunk szerint nem közölt részleteket, de az valószínűsíthető, hogy a redsn0w re-restore trükkje is ennek köszönhetően működik az adott készülékeken.

Kihasználva a fenti lehetőségeket, több érdekes trükk születhetett meg, így például az iOS 5 egyes verziói közötti oda-vissza mozgás lehetősége, vagy az iPad 2 iOS 6-ról iOS 5-re történő downgrade-elése meglévő iOS 4-es SHSH mellett. Ezekről a lehetőségekről bővebben itt írtunk: Frissült a redsn0w: tethered iOS 6 jailbreak Cydiával, és re-restore.

Akkor tehát mire van lehetőségünk?

Noha van lehetőség több esetben különféle trükközésekre, ezek legtöbbször vagy korábbi iOS-verziókhoz vagy régebbi készülékekhez kapcsolódnak. Az újabb eszközök esetén az APTicket sokkal mélyebbre van bevésve a betöltési folyamatba, és az újabb iOS-verziókban már a legtöbb kihasznált hiba is javításra került. És mivel az újabb eszközökre nincs lehetőség régebbi iOS-verziót telepíteni, így ezek a korlátozások is folyamatos átfedésben maradnak.

Szerencsére több régebbi készülék esetén működőképes a limera1n exploit, ami az első szintű bootloadert képes támadni: ezt a hibát az Apple csak hardverfrissítéssel tudta javítani, így a korábbi eszközökben, ahol még a hibát tartalmazó bootloader van, lehetőségünk van átugorni vagy megváltoztatni a betöltési folyamat következő lépéseit. Az exploitnak köszönhetően így ezek az eszközök downgrade-elhetőek is, ha a kívánt verzióhoz megvan az SHSH.

A másik lehetőség, amit mindez kínál, hogy kikerülhetjük az APTicketet az iOS 4 segítségével, mert az a verzió még az APTicket bevezetése előtti. Ezzel a megoldással ha az eszközhöz van SHSH-nk mind az iOS 4-hez és az iOS 5-höz, akkor átmenetileg visszatehető rá az iOS 4, hogy aztán arról frissítsük iOS 5-re, és így akár iOS 6-ról is downgrade-elhetjük. Ez összesen egyetlen eszköz esetén jöhet szóba, ez pedig az iPad 2: a régebbi készülékeken ott a limera1n exploit, így erre nincs szükség, az újabb készülékekre pedig nem volt iOS 4.

Végül pedig az iOS 5-öt futtató eszközök esetén ad lehetőséget arra, hogy az iOS 5 egyes verziói között mozogjunk. Ez csak az iPad 2, az iPad 3 és az iPhone 4s esetén jön szóba, szintén amiatt, mert a korábbi eszközökön ott a limera1n lehetősége, az újabb eszközök pedig már eleve iOS 6-tal érkeztek. És míg az iPad 2 esetén az előbbi opció is elérhető lehet, ha van hozzá iOS 4-es SHSH, addig ez utóbbi opció akkor is működik, ha az nincs.

A Cydia TSS működéséről

Ameddig nem volt APTicket, a Cydia “make my life easier” opciójára rányomva onnantól a Cydia egyszerűen lekérte az eszköz nevében az Apple szerverétől az adott iOS-verzióhoz tartozó SHSH-t. Ehhez összesen az eszköz ECID-jét, a típusát, és a menteni kívánt SHSH-hoz tartozó iOS-verziót kellett tudnia. Később, mikor az Apple már nem írta alá az adott iOS-verziót, akkor pedig még az iTunes-t is ki tudta szolgálni az SHSH-val egy hosts fájl módosítás után, ahogyan itt már leírtuk, mert a TinyUmbrella TSS szerver része is ugyanezen a módon működik: Mi az az SHSH, és hogyan működik a TinyUmbrella?.

Ez a megoldás kényelmes volt, viszont az iOS 5 megjelenésével a dolgok megváltoztak, és a TSS szerveres megoldás sem a Cydia, sem a TinyUmbrella használatakor nem eredményezett sikeres restore-t, hanem előre aláírt firmware-t kellett készíteni például a redsn0w segítségével: Stitch a redsn0w-ban: iOS5-ös firmware aláírása SHSH-val.

A dolog másik része volt, hogy a Cydiában több millió eszköz adata gyűlt össze, és így mikor megjelent egy újabb iOS-verzió, az SHSH-k automatikus lekérését a Cydia nem tudta a felhasználók számára elég gyorsan végezni a regisztrált eszközök magas száma miatt. Persze ez a rengeteg lekérés viszont sok volt az Apple-nek, így lépéseket tettek ellene.

Saurik is lépett, és megoldotta, hogy maguk az eszközök kérjék le az SHSH-t, majd tölthessék azt fel a Cydia szerverére. Ehhez persze figyelembe kellett venni azt is, amikor valakik szándékosan hibás blobokat töltenek fel. Ezért MuscleNerd segítségével ellenőrző algoritmust is kapott a feltöltéseket kezelő rész, ami hasonló ahhoz, amit az iOS rendszer betöltésekor a készülékek bootloadere is használ. Ezen felül egy API-t és készített, így más szoftverek is feltölthetnek SHSH-t a Cydiába, mint például a redsn0w.

Mi a helyzet az APTicketek tárolásával?

Amikor az Apple bevezette az APTicketet, kicsit megváltoztak a dolgok. Saurik módosította az SHSH tárolás folyamatát úgy, hogy az mentse az APTicketet is, és egyúttal azt is beállította, hogy a Cydia csak akkor jelezze mentettnek az adott SHSH-t, ha az tartalmazza az APTicketet is. Az APTicketet a lekérés eredményeként a Cydia automatikusan megkapta, így csak tárolni kellett.

Ez nagyjából egy évig rendben is ment.

Miért nem jók az iOS 6-os SHSH-k?

A Cydia által letöltött iOS 6-os SHSH-k a MuscleNerd segítségével elkészített algoritmus szerint ellenőrzésre kerültek. Ugyanakkor kiderült, hogy ezek mégsem használhatóak. Ennek az az oka, hogy a Cydia által használt lekérés kissé eltér attól, amit az Apple az iOS 6 óta használ. Egészen pontosan a Cydia által emulált lekérés csak azokhoz a fájlokhoz kért aláírást, amelyek a cikkben már tárgyalt partial digest-tel rendelkeznek, hiszen az SHSH esetén csak ezek a relevánsak, így a többi kiszűrésre került.

Ugyanakkor az APTicket teljes digest-eket ír alá, így még azoknak a fájloknak az adatai is szükségesek egy teljes lekéréshez, amelyeknél nincs partial digest. Ezért a Cydia a lekéréskor az összes, digest-tel rendelkező fájlra kellett volna szűrjön, és nem csak azokra, amelyeknél partial digest van.

Ennek eredményeként a lekért és elmentett APTicketek nem elegendőek ahhoz, hogy az eszköz betöltése sikeres legyen, mert gyakorlatilag hiányos az APTicket aláíráskészlete. Ugyanakkor a más eszközökkel, így a cikk elején is már írt TinyUmbrellával közvetlenül az Apple-től, vagy a redsn0w és iFaith segítségével az eszközről lementett SHSH-k megfelelőek. Ráadásul az ezekkel lementett SHSH-kat feltölthetjük a Cydiába, így onnantól bármikor lekérhetőek onnan. Egyedül a Cydia által mentett iOS 6-os SHSH-k azok, amik így nem használhatóak.

Miért nem tűnt ez fel senkinek?

Mivel az APTicketek bevezetése jóformán hasznavehetetlenné tette az SHSH-k mentését, így Saurik is úgy gondolta, hogy nem is lesz majd valódi szükség arra, hogy a Cydia mentse az újabb SHSH-kat. Mint kiderült, van rá szükség, és az így mentett SHSH-k egyes esetekben továbbra is használhatóak, ahogyan azt fentebb már írtuk.

Ugyanakkor mivel az iOS 6 sok mindent megváltoztatott, és ráadásul sem jailbreak nem volt hozzá hónapok, sem az egyes eszközöket nem frissítették hozzá, így a felhasználók joggal hihették azt, hogy csak azért nem megy az adott SHSH-val a dolog, mert a használt szoftver nem támogatja a piszkálni kívánt iOS-verziót, így nem jelezték ezt hibaként.

Ráadásul mivel ugye jailbreak sem volt, így akinek ez fontos szempont volt, az általában nem frissített iOS 6-ra, így meg sem próbált downgrade-elni, ha meg mégis, az iOS 5-ös SHSH-k iPhone 4s-nél korábbi készülékeken lehetővé tették a downgrade-et, így nem tűnt fel, hogy gond lehet. Mikor pedig megjelent az iOS 6-ra a jailbreak, már nem is volt szükség downgrade-re, egyszerűen fel lehetett tenni a 6.1.2-t is, és mehetett a jailbreak.

Mit jelent ez számunkra?

Valójában a felhasználóknak csak kisebb részét érinti a probléma. Először is az újabb eszközök esetén az iOS 6-os APTicket teljességgel használhatatlan: nem lehet vele sem downgrade-elni, sem az aktuálisan legfrissebb szoftververziónál korábbira frissíteni (például ha jelenleg 6.0 van az eszközön, akkor arról 6.1.2-re frissíteni), de még csak az aktuálisan a készüléken lévő firmware újrarakására sem alkalmas (tehát mondjuk a készüléken lévő 6.1.2-t sem lehet vele újratenni).

Azok az eszközök tehát, amelyeken bármiféle iOS 6-os SHSH használható egyáltalán, mindössze csak az iPhone 3GS, az iPhone 4 vagy az iPod Touch 4G. Semmi más készüléktípus esetén nincs jelenleg semmi ismert mód az iOS 6-os SHSH-k felhasználására. Ez tehát azt jelenti, hogy a Cydia felhasználók (és így a jailbreakelők) 74.2%-ának nem is probléma mindez.

Másodsorban a fennmaradó 25.8% számára az iOS 6-os SHSH-k elsődleges felhasználása a restore lenne arra a verzióra, ami éppen a készüléken fut, és ami untethered módon jailbreakelhető. A problémát az jelenti, ha valaki bármi okból annyira összekutyulja a készüléke rendszerét, hogy kénytelen restore-olni (vagy például belefut valami áprilisi tréfába, ahogyan azt páran tették).

Ebben az esetben a jobbik véglet, hogy a redsn0w fetch opciója segítségével a restore előtt mentjük a készüléken jelenleg lévő 6.1.2-es blobot, majd azt feltöltjük a Cydiába – itt van egy kis hiba a redsn0w legfrissebb verziójában is, ami miatt a feltöltés jelenleg nem sikerül, de ezt MuscleNerd hamarosan javítja, és közben azért a redsn0w a számítógépen már tárolta az adott SHSH-t. A másik lehetőség a készülékről való mentéshez az iFaith, aminél nincs gond a feltöltéssel, viszont ez utóbbi program pedig csak Windows-ra van.

A rosszabb eshetőség, amikor hamarabb sikerül elindítani a restore-t, mint az SHSH-t menteni a készülékről, és így felkerül a 6.1.3 a készülékre. Jailbreak ezekre az eszközökre ekkor is van, de csak tethered, így kényelmetlen. A tethered és untethered jailbreak közti különbségről bővebben itt: Gyakori kérdések: mi a különbség a tethered és untethered jailbreak közt?.

Mi minden új iOS-verzió megjelenésekor a TinyUmbrellával az Apple szervereiről történő SHSH-mentést javasoljuk, így aki követte ezt a tanácsunkat, annak nincs miért aggódnia, az Apple-től mentett SHSH-ja jó. Ezen túl a sn0wbreeze legújabb verziója is ellenőrzi már a használni kívánt SHSH-t, és figyelmeztet minket, ha az hibás (v2.9.14: After Cydia’s mishap with aptickets from 6.0 –> 6.1.2 (causing soft-dfu loops), sn0wbreeze now includes an apticket validation. It will verify the apticket after browsing for iOS5+ blobs in iFaith mode.).

Milyen lehetőségeink vannak iPhone 3G, iPhone 4 és iPod Touch 4G esetén?

Ha csak Cydiában van mentve az SHSH-nk, de például 6.1.2 van fent, akkor mentsük le azt a készülékünkről akár a redsn0w, akár az iFaith segítségével, mert másképp nem fogjuk tudni az aktuálisan a készüléken lévő iOS-verziót újratenni, hanem csak a 6.1.3-at, amire csak tethered jailbreak van.

Ha nem frissítettük a készülékünket 6.1.2-re, és így mondjuk 5.1.1 van rajta, akkor 6.1.2-re már nem fogjuk tudni frissíteni, és ahhoz utólag már sehogyan sem tudunk majd SHSH-t szerezni. Vagy nem frissítünk, vagy marad a 6.1.3, és a tethered jailbreak.

Ha megpróbáljuk a készüléken újratenni az aktuális iOS-verziót, de a vége Soft DFU lesz, akkor hibás SHSH-t használtunk. Ebben az esetben is leginkább csak a 6.1.3 marad lehetőségként.

Legutóbbi frissítés: 2017.05.02.