Apple va bloca posibilitatea de a face downgrade de iOS incepand cu iOS 5

In urma cu 2 ani de zile Apple lansa iOS 3 impreuna cu iPhone 3GS si introducea un nou sistem care impiedica utilizatorii sa faca restore la versiuni vechi ale iOS. Atunci Dev Team concepuse o metoda de a combate aceasta limitare care in final ne dadea posibilitatea de a salva SHSH-uri ce puteau fi folosite pentru a face restore la orice versiune veche de iOS pentru care aveam acel SHSH salvat. 2 ani de zile ne-am chinuit cu aceste SHSH-uri insa Apple pare sa doreasca sa ne scuteasca de acest chin si in iOS 5 va bloca posibilitatea de a mai face downgrade pentru iOS. Asta inseamna ca odata ce ati instalat iOS 5.1 nu mai puteti reveni deloc la iOS 5.0.

Dev Team a explicat in cursul noptii trecute ce anume implica limitarea impusa de catre Apple comparand noul sistem cu cel existent pentru downgrade-ul de baseband. In momentul de fata downgrade-ul de baseband este imposibil de facut, in afara situatiei in care ai un iPhone 4 si instalezi o versiune beta a iOS a carui baseband il poti readuce la o valoare mai mica. Asa va face Apple si cu iOS, va implementa un sistem care va genera un cod unic la restore pentru fiecare terminal, cod care este verificat de fiecare data cand pornim dispozitivul nostru si care este deocamdata imposibil de spart sau „falsificat”. Acel cod unic este generat aleator la fiecare restore si nu depinde de ECID precum SHSH-ul deci fara codul de cryptare al Apple este foarte greu de „ghicit” acel cod si este foarte greu de falsificat autentificarea terminalului la fiecare pornire.

Acest nou sistem va fi implementat de catre Apple incepand cu iOS 5 si partea interesanta este ca Apple ar putea da oricand posibilitatea de a reveni la un firmware vechi. Aceasta posibilitate poate fi oferita prin semnarea codurilor pentru restore(asemantaoare SHSH-urilor) pentru terminale vechi. In general dupa lansarea unei noi versiuni a iOS Apple inca semneaza SHSH-uri pentru cea veche pentru cateva zile deci un lucru asemanator se va intampla si in iOS 5.

Partea buna pentru cei care au orice terminal compatibil cu iOS 5, in fara de iPad 2, este ca limera1n va permite intotdeauna tethered jailbreak-ul pe iOS 5 si vom putea face downgrade la iOS 4, daca avem SHSH, insa pentru a face acest lucru s-ar putea sa trebuiasca sa folosim versiuni vechi ale iTunes. Dev Team sustine ca Apple va lansa noi versiuni ale iTunes care vor contine metode de a bloca restore-ul la vechi versiuni ale iOS deci ar fi bine sa va salvati de pe acum iTunes 10.3 in calculator deoarece s-ar putea sa aveti nevoie de program.

In final Dev Team spune ca noul sistem va bloca posibilitatea de a face restore la versiuni vechi ale iOS incepand cu iOS 5 GM care va fi lansat peste cateva luni. Cred ca multi se astepatau ca Apple sa implementeze un asemenea sistem si era oarecum normal avand in vedere ca de 2 ani de zile ne tot chinuim cu SHSH-uri. Asa cum au aparut acum 2 ani de zile SHSH-urile, vor aparea alte metode de a face restore si Dev Team a spus deja ca are cateva metode de a combate aceste limitari.

In concluzie, incepand cu iOS 5 vom fi nevoiti sa folosim noi metode de a face restore pentru iOS.

It looks like Apple is about to aggressively combat the “replay attacks” that have until now allowed users to use iTunes to restore to previous firmware versions using saved SHSH blobs.

Those of you who have been jailbreaking for a while have probably heard us periodically warn you to “save your blobs” for each firmware using either Cydia or TinyUmbrella (or even the “copy from /tmp during restore” method for advanced users).  Saving your blobs for a given firmware on your specific device allows you to restore *that* device to *that* firmware even after Apple has stopped signing it.  That’s all about to change.

Starting with the iOS5 beta, the role of the “APTicket” is changing — it’s being used much like the “BBTicket” has always been used.  The LLB and iBoot stages of the boot sequence are being refined to depend on the authenticity of the APTicket, which is uniquely generated at each and every restore (in other words, it doesn’t depend merely on your ECID and firmware version…it changes every time you restore, based partly on a random number).  This APTicket authentication will happen at every boot, not just at restore time.  Because only Apple has the crypto keys to properly sign the per-restore APTicket, replayed APTickets are useless.

This will only affect restores starting at iOS5 and onward, and Apple will be able to flip that switch off and on at will (by opening or closing the APTicket signing window for that firmware, like they do for the BBTicket).  geohot’s limera1n exploit occurs before any of this new checking is done, so tethered jailbreaks will still always be possible for devices where limera1n applies.  Also, restoring to pre-5.0 firmwares with saved blobs will still be possible (but you’ll soon start to need to use older iTunes versions for that). Note that iTunes ultimately is *not* the component that matters’s the boot sequence on the device starting with the LLB.

Although it’s always been just “a matter of time” before Apple started doing this (they’ve always done this with the BBTicket), it’s still a significant move on Apple’s part (and it also dovetails with certain technical requirements of their upcoming OTA “delta” updates).

Note: although there may still be ways to combat this, a beta period is really not the time or place to discuss them.  We’re just letting you know what Apple has already done in their exisiting beta releases — they’ve stepped up their game!