Twee jaar geleden lanceerde Apple iOS 2 samen met de iPhone 3GS en introduceerde een nieuw systeem dat voorkomt dat gebruikers kunnen herstellen naar oude versies van iOS. Vervolgens bedacht het ontwikkelteam een methode om deze beperking te bestrijden, die ons uiteindelijk de mogelijkheid gaf om SHSH's op te slaan die konden worden gebruikt om te herstellen naar elke oude versie van iOS waarvoor we die SHSH hadden opgeslagen. Twee jaar lang hebben we met deze SHSH's geworsteld, maar Apple lijkt ons van deze pijn te willen redden en zal in iOS 3 de mogelijkheid van downgraden voor iOS blokkeren. Dit betekent dat als je eenmaal iOS 2 hebt geïnstalleerd, je helemaal niet meer terug kunt naar iOS 5.
Het Dev-team legde gisteravond uit wat de door Apple opgelegde beperking inhoudt, waarbij het nieuwe systeem werd vergeleken met het bestaande voor de downgrade van de basisband. Op dit moment is het onmogelijk om de basisband te downgraden, behalve als je een iPhone 4 hebt en je een bètaversie van iOS installeert waarvan je de basisband terug kunt zetten naar een lagere waarde. Dit is wat Apple ook met iOS gaat doen: het zal een systeem implementeren dat voor elke terminal een unieke herstelcode genereert, een code die wordt gecontroleerd elke keer dat we ons apparaat aanzetten en die momenteel onmogelijk te kraken of te "vervalsen" is. . Die unieke code wordt bij elke herstelactie willekeurig gegenereerd en is niet afhankelijk van de ECID zoals de SHSH, dus zonder de coderingscode van Apple is het erg moeilijk om die code te "raden" en is het erg moeilijk om de authenticatie van de terminal te vervalsen elke keer dat deze wordt gestart .
Dit nieuwe systeem zal door Apple worden geïmplementeerd vanaf iOS 5 en het interessante is dat Apple altijd de mogelijkheid zou kunnen geven om terug te keren naar een oude firmware. Deze mogelijkheid kan worden geboden door herstelcodes (vergelijkbaar met SHSH) voor oude terminals te ondertekenen. Over het algemeen ondertekent Apple na de release van een nieuwe versie van iOS nog een paar dagen SHSH's voor de oude, dus iets soortgelijks zal gebeuren in iOS 5.
Het mooie voor degenen die een terminal hebben die compatibel is met iOS 5, zonder iPad 2, is dat limera1n altijd een vastgebonden jailbreak op iOS 5 toestaat en dat we kunnen downgraden naar iOS 4 als we SHSH hebben, maar om dit te doen moeten we moet mogelijk oude versies van iTunes gebruiken. Het ontwikkelaarsteam beweert dat Apple nieuwe versies van iTunes zal uitbrengen die methoden zullen bevatten om het herstel naar oude versies van iOS te blokkeren, dus het zou goed zijn om iTunes 10.3 vanaf nu op je computer op te slaan, omdat je het programma mogelijk nodig hebt.
Ten slotte zegt het ontwikkelaarsteam dat het nieuwe systeem de mogelijkheid blokkeert om te herstellen naar oude versies van iOS, te beginnen met iOS 5 GM, dat over een paar maanden zal verschijnen. Ik denk dat velen verwachtten dat Apple een dergelijk systeem zou implementeren en het was enigszins normaal gezien het feit dat we al twee jaar met SHSH's worstelen. Net zoals SHSH twee jaar geleden verscheen, zullen er andere herstelmethoden verschijnen en het ontwikkelteam heeft al gezegd dat het verschillende methoden heeft om deze beperkingen te bestrijden.
Concluderend zullen we vanaf iOS 5 nieuwe methoden moeten gebruiken om iOS te herstellen.
Het lijkt erop dat Apple op het punt staat de "replay-aanvallen" agressief te bestrijden die gebruikers tot nu toe in staat hebben gesteld iTunes te gebruiken om eerdere firmwareversies te herstellen met behulp van opgeslagen SHSH-blobs.
Degenen onder jullie die al een tijdje aan het jailbreaken zijn, hebben ons waarschijnlijk regelmatig horen waarschuwen om "je blobs op te slaan" voor elke firmware met behulp van Cydia of TinyUmbrella (of zelfs de "kopieer van /tmp tijdens herstel" -methode voor gevorderde gebruikers). Door uw blobs voor een bepaalde firmware op uw specifieke apparaat op te slaan, kunt u *dat* apparaat naar *die* firmware herstellen, zelfs nadat Apple ermee is gestopt deze te ondertekenen. Dat draait allemaal om veranderen.
Vanaf de iOS5-bèta verandert de rol van de "APTicket" - het wordt gebruikt zoals het "BBTicket" altijd is gebruikt. De LLB- en iBoot-fasen van de opstartvolgorde worden verfijnd om afhankelijk te zijn van de authenticiteit van het APTicket, dat uniek wordt gegenereerd bij elke herstelactie (met andere woorden, het hangt niet alleen af van uw ECID- en firmwareversie... het verandert elke keer dat u herstelt, deels op basis van een willekeurig getal). Deze APTicket-authenticatie vindt plaats bij elke keer opstarten, niet alleen tijdens het hersteltijdstip. Omdat alleen Apple over de cryptosleutels beschikt om het APTicket per herstel correct te ondertekenen, zijn opnieuw afgespeelde APTickets nutteloos.
Dit heeft alleen invloed op herstelbewerkingen vanaf iOS5 en hoger, en Apple kan die schakelaar naar believen aan- en uitzetten (door het APTicket-ondertekenvenster voor die firmware te openen of te sluiten, zoals ze doen voor de BBTicket). geohot's limera1n-exploit vindt plaats voordat deze nieuwe controles zijn uitgevoerd, dus tethered jailbreaks zullen nog steeds altijd mogelijk zijn voor apparaten waarop limera1n van toepassing is. Ook, herstellen naar firmwares van vóór 5.0 met opgeslagen blobs is nog steeds mogelijk (maar daarvoor zul je binnenkort oudere iTunes-versies moeten gebruiken). Merk op dat iTunes uiteindelijk *niet* het onderdeel is dat hier van belang is. Het is de opstartvolgorde op het apparaat, beginnend met de LLB.
Hoewel het altijd slechts "een kwestie van tijd" is geweest voordat Apple hiermee begon (ze hebben dit altijd gedaan met het BBTicket), is het nog steeds een belangrijke stap van Apple (en het sluit ook aan bij bepaalde technische vereisten van hun aankomende OTA-delta "updates).
Opmerkingen: hoewel er misschien nog steeds manieren zijn om dit te bestrijden, een bètaperiode is echt niet het moment of de plaats om ze te bespreken. We laten je alleen weten wat Apple al heeft gedaan in hun bestaande bètaversies: ze hebben hun spel opgevoerd!
