Forums GAMERGEN

Où sont passées mes données iOS 6 (SHSH...) ?

Règles du forum
Postez vos news concernant les smartphones et tablettes des systèmes d'exploitation iOS, Android et Windows Phone. Afin que l'affichage et la navigation restent simple et rapide pour tous, appliquez les balises suivantes au début des titres de vos news en fonction de l'OS correspondant à l'information: [iOS] / [And] / [Win]

Utilisez également des titres explicites en complément des balises.

Où sont passées mes données iOS 6 (SHSH...) ?

Message non lupar MDProz » 09 Avr 2013, 14:54

Bonjour,

Depuis peu, sur Cydia, Jay Freeman (saurik) nous informe:

Where did my iOS 6 TSS data go?
Normally, I get to write articles (or give talks, or leave many-page long comments on various websites and forums) on interesting aspects of technology, confusing aspects of business, protocols and the people who standardized them, or new tools that I've been working on; writing these articles can be grueling at times, but at some level the task is not just rewarding, but fun.
Sadly, that is not why I have been working on this article: instead, I am here to be the bearer of bad news that will likely cause me to get a ton of hatemail. :( Specifically, I am writing this to tell everyone that the TSS data Cydia saved for iOS 6.0-6.1.2 is unusable. I'm also going to attempt to explain some background on the process, what the mistake was, and what users can now do instead.
In the process, I am going to explain a few parts of the iOS software security mechanism that I have not seen described often outside of technical presentations at security conferences. Additionally, I will summarize, from the perspective of a user, what is currently possible with cached APTicket information (something I actually did not know much about before writing this).
My goal is that by the end of this article readers will understand enough of the process to appreciate the mistake, the history of the issue, and why it was never caught. Additionally, it will hopefully be slightly more clear when cached APTicket information is usable (as it turns out that cached APTickets have a rather narrow range of uses) and how affected users might still be able to get this data.
(For those who don't care about the long explanation below: the only devices where saved iOS 6 APTickets are actually ever useful are the iPhone 3G[S], iPhone 4, and the 4th generation iPod touch; on these devices, users can, and probably "should", save the APTicket that is currently allowing their device to boot. This can be done with a tool that can dump this information using the limera1n bootrom exploit, such as redsn0w or iFaith, and upload the replacement to Cydia.)


Traduction 1re partie:
Où sont passées mes données TSS iOS 6 ?
Normalement, j'arrive à écrire des articles (ou donner des conférences, ou laisser un grand nombre de pages de longs commentaires sur les différents sites et forums) sur les aspects intéressants de la technologie, confondant les aspects des affaires, les protocoles et les personnes qui les ont standardisé, ou de nouveaux outils que nous avons travaillé sur la rédaction de ces articles qui peuvent être exténuant par moments, mais à un certain niveau, la tâche est non seulement enrichissant, mais amusant.
Malheureusement, ce n'est pas pour ça que je travaille sur cet article: à la place, je suis ici pour être le porteur de mauvaises nouvelles qui vont probablement me faire obtenir une tonne de hatemail. : (Plus précisément, je vous écris ceci pour dire à tous que les TSS données enregistrées sur Cydia pour iOS 6.0-6.1.2 sont inutilisables. Je vais aussi tenter d'expliquer quelques informations sur le processus, ce que l'erreur a été, et ce que les utilisateurs peuvent maintenant faire à la place.
Dans le processus, je vais vous expliquer quelques parties du mécanisme iOS logiciels de sécurité que je n'ai pas vu souvent décrits en dehors des présentations lors de conférences techniques de sécurité. En outre, je vais résumer, du point de vue d'un utilisateur, ce qui est actuellement possible avec les informations mises en cache APTicket (quelque chose que je ne savais pas vraiment avant d'écrire cela).
Mon objectif est que d'ici la fin de cette article, les lecteurs vont comprendre suffisamment le processus d'apprécier l'erreur, l'historique de la question, et pourquoi il n'a jamais été pris. En outre, il faut espérer qu'elle sera un peu plus clair lorsque l'information APTicket cache est utilisable (car il s'avère que APTickets cache une fourchette assez étroite des usages) et la façon dont les utilisateurs affectés peut-être encore en mesure d'obtenir ces données.
(Pour ceux qui ne se soucient pas de la longue explication ci-dessous: les seuls appareils où il est possible d'enregistrer iOS 6 APTickets sont l'iPhone 3G [S], iPhone 4, et l'iPod de 4ème génération. Sur ces appareils, les utilisateurs peuvent , et probablement «devrait», enregistrer le APTicket qui est actuellement en permettant leur appareil de démarrer. Cela peut être fait avec un outil qui peut vider cette information en utilisant l'exploit bootrom limera1n, tels que redsn0w ou iFaith, et télécharger le remplacement de Cydia.)

What is TSS?
One aspect of maintaining a "secure" system is to verify that the software that is installed on it is the software that you were expecting. This is done by using cryptographic "signatures" that can demonstrate the authenticity of a block of data, such as the operating system running on a device such as an iPhone. Apple "signs" all of the software that they put on an iPhone.
As the device boots up, each step verifies the signature of the next step before moving onwards. Assuming that each step works correctly, you can then feel safe that the entire system is running the software that it was intended to run, with no modifications that might do things you don't want (whether it be actual malware, or adding cool features that you didn't authorize).
Of course, that assumption is unrealistic for a system as complex as the iPhone: there are many bugs, large and small, that allow attackers to bypass various checks. Particulary tricky attacks can allow for things like evasi0n: an "untethered jailbreak", where the software has been permanently modified in a way that will persist across reboots, re-attacking exploits each boot.
Therefore, one has to plan how bug fixes will be rolled out and required: it isn't sufficient to just sign software, as once a bug is found, users could always just downgrade to that known buggy version, take control, and then potentially work their way back up; certainly, though, even if they are stuck at the old version, that may already be a sufficiently costly loss.
The way vendors typically solve this is by having restrictions past just "valid signature" when new software is installed: the most common being "the software being installed must not be older than the software it is replacing, either by checking a version number or an encoded date (which is, really, just another way of encoding a version number)". Most systems use this scheme.
Apple, however, decided that this wasn't sufficient, as this allows one to actively maintain a device effectively at an old version for a long time. Additionally, it means that if you have a device you haven't used in a very long time, and many software revisions have been released between then and now, you could choose to upgrade to any of those versions, not just the latest.
Apple's solution to this, which they deployed with iOS 3.x (iOS 2.x was signed, but had no downgrade protections at all), was to have every single installation of the operating system verify, at that moment over the Internet, that the version of the software being installed is "the one we intended to allow you to install". The verifier is the Tatsu Signing Server, or "TSS".


Traduction 2nd partie:
Qu'est-ce que le TSS?
Un aspect de maintenir une "sécurité" du système est de vérifier que le logiciel est installé sur le logiciel que vous attendiez. Ceci est fait en utilisant des aspects cryptographiques "signatures" qui peuvent démontrer l'authenticité d'un bloc de données, tels que le système d'exploitation exécuté sur un appareil tel qu'un iPhone. Apple "signe" tous les logiciels qu'ils mettent sur un iPhone.
Comme le périphérique démarre vers le haut, chaque étape vérifie la signature de la prochaine étape avant de passer à compter. En supposant que chaque étape fonctionne correctement, vous pouvez sentir la sécurité que tout le système exécute sur le logiciel qui a été conçu pour fonctionner sans aucune modification, et qui pourrait faire des choses que vous ne voulez pas (que ce soit malware réel, ou l'ajout de fonctionnalités intéressantes que vous n'avez pas autorisé).
Bien sûr, cette hypothèse n'est pas réaliste pour un système aussi complexe que l'iPhone: il y a de nombreux bugs, petits et grands, qui permettent d'attaquer afin de contourner les contrôles divers. Particulièrement difficiles, les attaques peuvent permettre des choses comme evasi0n: un "jailbreak untethered", où le logiciel a été modifié en permanence d'une manière qui va à chaque réinitialisation, ré exploiter chaque démarrage.
Par conséquent, on doit planifier la manière dont les corrections de bugs seront mis en place et nécessaires: il ne suffit pas de simplement signer les logiciels, car une fois qu'un bug est trouvé, les utilisateurs peuvent toujours juste revenir à cette version connue, prendre le contrôle, puis éventuellement travailler leur chemin de retour, certainement, mais, même s'ils sont coincés à l'ancienne version, qui peut déjà être une perte assez coûteux.
La façon dont les vendeurs vont généralement résoudre ce problème est d'avoir des restrictions passé juste "signature valide". Lorsqu'un nouveau logiciel est installé: le plus commun étant "le logiciel en cours d'installation ne doit pas être plus âgé que le logiciel qu'il remplace, soit en vérifiant le numéro de version ou une date codée (qui est, vraiment, juste une autre façon de coder un numéro de version) ". La plupart des systèmes utilisent ce système.
Toutefois, Apple a décidé que ce n'était pas suffisant, car cela permet de maintenir activement un dispositif efficace à une ancienne version pendant une longue période. En outre, cela signifie que si vous avez un appareil que vous n'avez pas utilisé dans un temps très long, et que les révisions de nombreux logiciels ont été libérés entre alors et maintenant, vous pouvez choisir de mettre à niveau vers l'une de ces versions, et pas seulement plus tard.
Solution d'Apple pour ce qui ont déployé avec iOS 3.x (iOS 2.x été signé, mais n'avait pas de protection du tout downgrade), était d'avoir chaque installation unique du système d'exploitation de vérifier, à ce moment sur l'Internet, que la version du logiciel installé est "celui que nous avons pour but de vous permettre d'installer". Le vérificateur est le Signing Server Tatsu, ou «TSS».

What is SHSH?
The important detail of the signing process is then to know exactly what is signed. Over the years, this has changed. The system that I had described a few years ago in a previous article, "Caching Apple's Signature Server", involves "personalizing" the files that are used as part of the iOS operating system software installation process (which is known as "restoring").
This personalization is done by adding data to each file that is specific to the device on which the software will be installed, and then having the resulting "personalized" file be signed again by Apple. (I say signed "again", as the original files distributed by Apple are already signed, but they do not contain this device-specific information and are entirely generic.)
The device-specific information that was used for this process is called, depending on where you find it, the "unique chip ID" or the "ECID" (an acronym that no one is sure of the meaning behind, but probably means something like "exclusive chip ID"). This ECID is a small block of data represented as a number that is unique to every iOS device that Apple has shipped.
This ECID is then sent to Apple, along with the list of files that are being signed. Apple then returns a "blob" for each file, which is a block of data that replaces the existing signature on the file with both the personalization information (which is the ECID), sometimes some random data seemingly just "for good measure", as well as a new signature that signs the entire file.
The actual signature inside of this blob is the SHSH, or signature hash (maybe "signed hash"; again, no one is really that certain, but we largely agree on "signature"). As the ECID of a device never changes, if you can then save the SHSH of a personalized file, you can always use it later to install that file, even if Apple is no longer willing to sign it: we thereby like saving these.


Traduction 3ème partie:
Qu'est-ce que le SHSH?
Le détail important du processus de signature est alors de savoir exactement ce qui est signé. Au fil des ans, cela a changé. Le système que j'avais décrit il ya quelques années dans un article précédent, «Mise en cache du serveur Signature d'Apple", consiste à «personnaliser» les fichiers qui sont utilisés dans le cadre du processus d'exploitation iOS système logiciel d'installation (qui est connu comme «restauration») .
Cette personnalisation se fait par l'ajout de données pour chaque fichier qui est spécifique à l'appareil sur lequel le logiciel sera installé, puis d'avoir le résultat "personnalisé" dossier soit à nouveau signé par Apple. (Je dis signé "nouveau", comme les fichiers originaux distribués par Apple sont déjà signés, mais ils ne contiennent pas cette information spécifique à l'appareil et sont entièrement générique).
Les informations spécifiques à l'appareil qui a été utilisé pour ce processus est appelé, selon l'endroit où vous le trouvez, l '"ID puce unique" ou le «ECID» (un acronyme que personne n'est sûr de la signification derrière, mais cela signifie probablement quelque chose comme "identité à puce exclusif"). Cette ECID est un petit bloc de données représentées par un nombre qui est unique à chaque appareil iOS d'Apple qui a été expédiée.
Cette ECID est ensuite envoyé à Apple, ainsi que la liste des fichiers qui sont signés. Apple renvoie alors un "blob" pour chaque fichier, qui est un bloc de données qui remplace la signature existante sur le fichier à la fois les informations de personnalisation (qui est l'ECID), parfois quelques données aléatoires en apparence seulement "pour faire bonne mesure", comme ainsi une nouvelle signature qui signe l'intégralité du fichier.
La signature réelle à l'intérieur de ce blob est le SHSH, ou hash signature (peut-être "signé hash", encore une fois, personne n'est vraiment sûr, mais nous sommes largement d'accord sur la "signature"). Comme l'ECID d'un dispositif ne change jamais, si vous pouvez ensuite sauvegarder le SHSH d'un dossier personnalisé, vous pouvez toujours l'utiliser plus tard pour installer ce fichier, même si Apple ne veut plus la signer: nous avons ainsi par exemple sauvé ceux-ci.

How is each SHSH computed?
I now must make a slight detour to describe signatures: the way these work involves something called a "hash"; when you "sign" a file, you first take a "hash" of the file and then "encrypt" that hash using an encryption key that only you have (a "private key") but that can be decrypted by a second "public" key that you are able to widely distribute ahead of time to anyone who cares.
The result of "hashing" is sometimes called a "digest" because what a hash effectively does is to make a smaller version of the file. This smaller file is typically a fixed length that is unrelated to the size of the original file: it is instead determined by the choice of hashing algorithm. The algorithm that is used for verifying iOS is SHA-1, which generates a 160-bit digest.
When you are constructing a digest using SHA-1, you can actually do it "piecemeal": you can get part of the data and stop, and then later come back when you have the second part. At any moment, the only data you need is 160-bits of data and the length you have so far hashed. This means that there is an efficient way to "continue hashing a file from where you left off" when using SHA-1.
Apple uses this trick to generate its personalized signatures: instead of sending the entire file into the server, or even storing the entire file on the server, requiring it to still run the hashing algorithm on potentially hundreds of megabytes of data, Apple sends only a "partial digest" to the server as part of a TSS request, which is then completed by the server and signed with their key.
Finally, inside of an iPhone software (IPSW) update file (which is really just a ZIP file) is a "build manifest" that contains a list of filenames and, for each one, its digest (which is the hash of its data, including the signature it has attached to it from Apple) as well as one of these partial digests for the file without the signature block on the end (so it can be completed by TSS).
The personalization process thereby involves taking the build manifest, building a TSS request, sending it to Apple, getting the result, and then modifying each of the files that were listed by replacing the signature section with the blobs returned by TSS. The resulting modified files are sent to the device, which verifies the ECID inside of them, and also validates the signature hash.


Traduction 4ème partie:
Comment est calculé chaque SHSH?
Je dois maintenant faire un léger détour pour décrire les signatures: la manière dont ces travaux implique ce qu'on appelle un "hash", lorsque vous «signer» un fichier, vous devez d'abord prendre un "hash" du fichier, puis "crypter" ce hachage en utilisant une clé de chiffrement que vous seul avez (une «clé privée»), mais qui peut être décryptée par une seconde clé "publique" que vous êtes en mesure de diffuser largement à l'avance pour toute personne qui s'en soucie.
Le résultat de «hachage» est parfois appelé un "digest" parce que ce qui fait un hachage efficace est de faire une plus petite version du fichier. Ce fichier plus petit est généralement une longueur fixe qui n'est pas lié à la taille du fichier d'origine: elle est plutôt déterminée par le choix algorithme de hachage. L'algorithme qui est utilisé pour vérifier iOS est SHA-1, ce qui génère un résumé de 160-bit.
Lorsque vous construisez un condensé en utilisant SHA-1, vous pouvez effectivement le faire «à la pièce»: vous pouvez obtenir une partie des données et d'arrêt, puis revenir plus tard quand vous avez de la deuxième partie. A tout moment, les données dont vous avez besoin est de 160 bits de données et la longueur que vous avez est bien haché. Cela signifie qu'il existe un moyen efficace de «continuer le hachage d'un fichier, où vous l'avez laissé" en utilisant SHA-1.
Apple utilise cette astuce pour générer ses signatures personnalisées: au lieu d'envoyer l'ensemble du dossier sur le serveur, ou même stocker l'intégralité du fichier sur le serveur, l'obligeant à toujours exécuter l'algorithme de hachage sur potentiellement des centaines de mégaoctets de données, Apple envoie seulement un "digestion partielle" sur le serveur dans le cadre d'une demande de TSS, qui est ensuite complété par le serveur et signé avec sa clé.
Enfin, à l'intérieur d'un fichier mise à jour logicielle iPhone (IPSW) (qui est en fait un fichier ZIP) est une «construire manifeste» qui contient une liste de noms de fichiers et, pour chacun, son empreinte (ce qui est le hachage de ses données, y compris la signature qu'il a attaché d'Apple) ainsi que l'un de ces digestions partielles pour le fichier sans le bloc signature sur la fin (de sorte qu'il peut être complété par TSS).
Le processus de personnalisation impliqué prenant ainsi le manifeste de construction, la construction d'une demande de TSS, l'envoyer à Apple, d'obtenir le résultat, puis en modifiant chacun des fichiers qui ont été énumérés par le remplacement de la section de signature avec les blobs retournés par TSS. Les fichiers résultants modifiés sont envoyés vers le dispositif, qui vérifie l'intérieur de leur ECID, et valide également la signature de hachage.

Caching Apple's Signature Server
When Apple started doing this, we figured out how it worked, and the course of action was clear: to setup a man-in-the-middle attack on this server that would simply store every single SHSH that was returned for every file of every firmware version for every device owned by all of the people who cared about being able to downgrade (both jailbreakers, and App Store developers who need to test their apps on earlier firmware versions).
I built this system as a service and wrote an article about how the process worked and how it could be used. Initially, the system acted only "in the middle", but it was immediately enhanced to save all of the ECIDs of all of the users in a massive database, so it could go on its own every time Apple released a new firmware version in order to request everyone's SHSH information "en masse".
Eventually, though, you end up with so many ECIDs on file that you are trying to request from a number of servers hundreds of thousands of times fewer, that it becomes very obvious how to shut down such an operation. For a couple years now, I have thereby not been able to run the "man in the middle" proxy server, nor am I able to provide the service of automatically saving peoples' SHSH for them.
However, I have still been able to help users automatically get their data stored by having the Cydia application do it "in the field": Cydia requests SHSH blobs from Apple and uploads them to my servers whenever it notices you don't have the information stored on my servers. Additionally, I provide an API that allows third-party tools that retrieve and manage the same information to upload it to me for safe keeping.


Traduction 5eme partie:
La mise en cache du serveur Signature d'Apple
Quand Apple a commencé à le faire, nous avons compris comment ça marchait, et le cours de l'action était clair: mettre en place une attaque man-in-the-middle sur ce serveur qui serait tout simplement stocker tous les SHSH unique qui a été renvoyée pour chaque fichier de chaque version du micrologiciel pour chaque appareil appartenant à toutes les personnes qui ont pris soin de ne pas pouvoir downgrade (deux jailbreakers, et les développeurs de l'App Store qui ont besoin de tester leurs applications sur les premières versions du firmware).
J'ai construit ce système comme un service et a écrit un article sur la façon dont le processus fonctionne et comment il pourrait être utilisé. Initialement, le système a agi seul "au milieu", mais il a été immédiatement renforcée pour enregistrer toutes les IDCI de tous les utilisateurs dans une gigantesque base de données, afin qu'il puisse continuer à chaque fois qu'Apple a publié une nouvelle version du firmware pour demander des informations SHSH de tous "en masse".
Finalement, cependant, vous vous retrouvez avec IDCI tant sur le fichier que vous essayez de demander à un certain nombre de serveurs centaines de milliers de fois moins, qu'il devient très évident de savoir comment arrêter une telle opération. Pour quelques années maintenant, j'ai ainsi pu lancer le "man in the middle" serveur proxy, je ne suis pas en mesure de fournir le service d'enregistrement automatique SHSH peuples pour eux.
Cependant, j'ai toujours été en mesure d'aider les utilisateurs pour obtenir automatiquement leurs données stockées par l'application Cydia et le faire "sur le terrain": demandes Cydia blobs SHSH d'Apple et les télécharge vers mes serveurs chaque fois qu'il constate que vous n'avez pas l'information stockés sur mes serveurs. En outre, je vous propose une API qui permet des outils tiers que récupérer et gérer les mêmes informations pour le télécharger sur moi pour garder sûr.

How did APTicket change things?
When iOS 5 came out, Apple changed the game slightly: SHSH, the system that I had known a lot about and had spent an inordinate amount of my life building (over and over again, due to changing limitations and scale requirements) tools to retrieve and store data for, was on its way out; a new verification scheme called APTicket was clearly setup to replace it entirely in some upcoming device.
The person who then spent a lot of time looking into APTicket was not me: it was actually MuscleNerd, the developer of redsn0w. Additionally, as recently as late September of 2012, at JailbreakCon, I can be heard asking questions from the audience to iH8sn0w about APTickets after his presentation, as all of my knowledge of how they worked was secondhand ;P.
Since then (a few months ago), I spent some time reverse engineering the APTicket verification system, and thereby know some more about it; however, I was mostly concentrating on finding bugs in the certificate parser, and only was looking at a single stage of the bootup process, so I continue to not know everywhere an APTicket is used, or certainly how various devices are affected by their presence.
However, at a high level, what the APTicket is is a single block of data that is signed as a whole and that contains the digest of all of the files that will be used as the device boots. In various ways this is much more efficient than having to personalize each and every single part: you don't even need to rewrite the files, as the APTicket can just store the pristine original digest of the files from the IPSW.
Additionally, it drastically reduces the number of signatures that Apple's servers need to perform: every time they release a new version of iOS, their requirement that the software must be signed for every specific device requires an immense number of crytographic signatures; the APTicket mechanism reduces the number of signatures they have to calculate by a factor of between 10 and 20 times.
Further, the APTicket has a special quirk: a "nonce" (a word with a fairly interesting history) is stored inside of it (meaning that it, too, is signed during the restore process by TSS) that is verified in addition to the ECID. This "nonce" is a number that is generated at random during the restore process, and which thereby makes the APTicket specific to every single restore and uncacheable.


Traduction 6eme partie:
Comment APTicket a changé les choses?
Lorsque iOS 5 est sorti, Apple a changé le jeu un peu: SHSH, le système que je connaissais beaucoup de choses sur et avait passé énormément de mon immeuble de vie (encore et encore, en raison des limitations évolution et les exigences d'échelle) des outils pour récupérer et stocker des données pour, était sur son chemin, un système de vérification nouveau appelé APTicket a été clairement configurer pour le remplacer entièrement dans un certain dispositif à venir.
La personne qui a ensuite passé beaucoup de temps à étudier APTicket n'était pas moi: il a été effectivement MuscleNerd, le développeur de redsn0w. En outre, pas plus tard que la fin de Septembre 2012, à JailbreakCon, je peux être entendu pour poser des questions de l'auditoire à iH8sn0w sur APTickets après sa présentation, que toutes mes connaissances de la façon dont ils ont travaillé était secondaire; P.
Depuis lors (il y a quelques mois), j'ai passé un peu de temps sur la rétro-ingénierie du système de vérification APTicket, et ainsi savoir un peu plus à ce sujet, mais j'étais surtout concentrer sur la recherche de bogues dans l'analyseur certificat, et ne regardais une seule étape du processus de démarrage, si je continue à ne pas savoir comment une APTicket est utilisé, ou en tout cas comment les divers périphériques sont affectés par leur présence.
Cependant, à un niveau élevé, ce qui est le APTicket est un seul bloc de données qui est signé dans son ensemble et qui contient le résumé de tous les fichiers qui seront utilisés comme périphérique démarre. De diverses manières, ce qui est beaucoup plus efficace que d'avoir à personnaliser chaque pièce unique: vous n'avez même pas besoin de réécrire les fichiers, comme le APTicket pouvez simplement stocker l'empreinte vierge d'origine des fichiers à partir du fichier IPSW.
En outre, il réduit considérablement le nombre de signatures que les serveurs d'Apple ont besoin pour effectuer: chaque fois qu'ils publient une nouvelle version d'iOS, leur exigence est que le logiciel doit être signé pour chaque périphérique spécifique et nécessite un très grand nombre de signatures Crytographic, le mécanisme APTicket réduit le nombre de signatures qu'ils ont à calculer par un facteur compris entre 10 et 20 fois.
En outre, le APTicket a une particularité spéciale: un "nonce" (un mot avec une histoire assez intéressante) est stocké à l'intérieur de celui-ci (ce qui signifie que, lui aussi, est signé au cours du processus de restauration par TSS) qui est vérifié en plus de la ECID. Cette "nonce" est un nombre généré de façon aléatoire pendant le processus de restauration, et qui rend ainsi la APTicket spécifique à chaque restauration simples et Uncacheable.

Caching the Uncacheable
The question then is, if APTickets solve the problems that SHSH had: why do people still save them? One would expect at this point that when Apple introduced APTickets, that all of the work attempting to store and process this data for later use would have stopped. Obviously, this is not the case. There are two things going on here: backwards compatibility and a few implementation mistakes.
First, Apple can't just reflash the bootloader on the existing devices that are in the field, and those verify the first step using SHSH. This means that if you have SHSH data stored for that first stage, it doesn't matter whether you have an APTicket for the remaining stages or not: you can trick the first stage. If nothing else, this lets you downgrade to iOS versions that did not use APTicket.
Second, this is a complex verification system, involving a lot of little steps; as an example, at some point you have to reset the nonce: if the nonce never changes, then you can save the APTicket data for whatever fixed nonce you have, and it all looks very much like it did back when we only had the ECID to worry about. It is my understanding that this is how MuscleNerd's "re-restore" trick works.
Taking advantage of these mistakes has allowed for a few interesting tricks, such as allowing people to switch from one version of iOS 5 to another, or allowing the iPad 2 to be downgraded to iOS 5 from iOS 6 (if you have TSS information saved for iOS 4, to use as an intermediary). For more information on how you can use these techniques, users may wish to read the JailbreakQA FAQ entry on SHSH and APTicket.


Traduction 7eme partie:
Mise en cache du Uncacheable
La question est alors, si APTickets résoud les problèmes qui avaient avec SHSH: pourquoi les gens peuvent encore les sauver? On aurait pu s'attendre à ce point que, quand Apple a introduit APTickets, que tout le travail d'essayer de stocker et de traiter ces données pour une utilisation ultérieure serait arrêté. Évidemment, ce n'est pas le cas. Il y a deux choses qui se passent ici: compatibilité en arrière et un peu de mise en œuvre erreurs.
Tout d'abord, Apple ne peut pas juste reflasher le bootloader sur les dispositifs existants qui sont sur le terrain, et ceux de vérifier la première étape en utilisant SHSH. Cela signifie que si vous avez des données stockées SHSH pour cette première étape, il n'a pas d'importance si vous avez un APTicket pour les étapes restantes ou non: vous pouvez tromper la première étape. Si rien d'autre, cela vous permet de revenir à des versions iOS qui n'utilisaient pas APTicket.
Deuxièmement, il s'agit d'un système de vérification complexe, impliquant un grand nombre de petites étapes, comme, par exemple, à un certain moment vous devez réinitialiser le nonce: si le nonce ne change jamais, alors vous pouvez enregistrer les données APTicket quelle qu'en soit fixe nonce que vous avez, et tout semble très bien comme elle l'a fait en arrière quand nous n'avions que l'ECID de s'inquiéter. Je crois comprendre que c'est comme ça que MuscleNerd de "re-restauration des œuvres" trick.
Profitant de ces erreurs, cela a permis quelques trucs intéressants, tels que permettre aux gens de passer d'une version d'iOS 5 à l'autre, ou de permettre à l'iPad 2 d'être déclassé à iOS 5 d'iOS 6 (si vous avez des informations TSS enregistrés pour iOS 4, à utiliser en tant qu'intermédiaire). Pour plus d'informations sur la façon dont vous pouvez utiliser ces techniques, les utilisateurs peuvent souhaiter lire l'entrée JailbreakQA FAQ sur SHSH et APTicket.

So, what actually is possible?
While I have mentioned a number of interesting tricks, they are mainly related to either old versions of iOS or old devices. With newer devices, APTickets are more deeply ingrained in the bootup process; and with newer versions of iOS, most of the mistakes that had been used have now been fixed. As newer devices never had access to install older versions of iOS, these limitations start overlapping.
In particular, many older devices are subject to an exploit called limera1n, which attacks the first-level bootloader of the device: this is something that Apple can't fix, and allows us to bypass or alter everything that comes after it in the bootup sequence. Using this exploit, it is possible to downgrade these exploitable devices to any version for which you have your TSS information saved.
Another opportunity allows you to sidestep the APTicket process by way of iOS 4, which predates the introduction of that feature. This allows devices that have TSS information for both iOS 4 and iOS 5 to downgrade to iOS 4 (even from iOS 6) momentarily and then upgrade to iOS 5. There is only one device, however, where this matters: the iPad 2. Older devices have limera1n, and newer devices did not have iOS 4.
Finally, for devices running iOS 5, we have the ability to restore any other version of iOS 5. This is only relevant on the iPad 2, iPad 3, and the iPhone 4S (as earlier devices are exploitable with limera1n, and later devices came out after iOS 6 and thereby cannot use iOS 5). While the iPad 2 is also the device from the previous category, this can work even if you don't have iOS 4 TSS information saved.


Traduction 8eme partie:
Donc, ce qui est réellement possible?
Alors je l'ai mentionné un certain nombre de trucs intéressants, ils sont principalement liées soit à des anciennes versions d'iOS ou d'anciens appareils. Avec les nouveaux appareils, APTickets sont plus profondément ancrés dans le processus de démarrage, et avec les nouvelles versions d'iOS, la plupart des erreurs qui ont été utilisés ont été fixés. Comme les nouveaux appareils n'ont jamais eu accès à installer des versions plus anciennes de iOS, ces limitations ont commencé à se chevaucher.
En particulier, de nombreux anciens appareils sont soumis à un exploit appelé limera1n, qui attaque le bootloader de premier niveau de l'appareil: c'est quelque chose que Apple ne peut pas résoudre, et nous permet de contourner ou de modifier tout ce qui vient après lui dans le démarrage séquence. En utilisant cet exploit, il est possible de rétrograder ces dispositifs exploitables pour toute version pour laquelle vous avez vos informations TSS enregistrés.
Une autre possibilité vous permet de contourner le processus APTicket au moyen d'iOS 4, qui est antérieure à l'introduction de cette fonctionnalité. Ceci permet aux périphériques qui ont des informations TSS à la fois pour iOS 4 et iOS 5 pour revenir à iOS 4 (même à partir d'iOS 6) momentanément, puis mettre à niveau vers iOS 5. Il n'y a qu'un seul appareil, cependant, où cette question est importante: l'iPad 2. Les appareils plus anciens ont limera1n, et les nouveaux appareils n'ont pas iOS 4.
Enfin, pour les appareils exécutant iOS 5, nous avons la possibilité de restaurer n'importe quelle autre version de l'iOS 5. Ceci n'est valable que sur l'iPad 2, iPad 3 et l'iPhone 4S (en tant que dispositifs antérieurs sont exploitables avec limera1n, et plus tard périphériques iOS est sorti après 6 et ne peut donc pas utiliser iOS 5). Alors que l'iPad 2 est aussi le dispositif de la catégorie précédente, cela peut fonctionner, même si vous n'avez pas d'informations iOS TSS 4 sauvés.

What does Cydia's TSS service do?
Moving back for a moment to the service I have provided for storing TSS information, it is important to know that it was designed for SHSH. The reason I built it was to have a concrete way to use saved SHSH blobs: all previous descriptions (including geohot's original purplera1n.com, which allowed users to save one critical SHSH blob "for a purplera1ny day"), relied on a tool like redsn0w to one day exist.
At the time, however, we did not have such a tool, and thereby needed something "simpler". My idea was to build an implementation of the TSS server, one that could even transparently provide information from Apple by passing requests through, that would be able to save information on its way through and then later replay it when you could no longer make the requests for this information from Apple.
This meant that you could use iTunes itself to perform restores of any version you had ever previously installed by tricking it into connecting to my server instead of Apple's server (which we did using "etc/hosts" entries, which is easy to configure on both Windows and Mac OS X). I also provided an open-source implementation of TSS that others used to learn from and build local tools and servers.
As you used the server, I also saved your ECID, and would then attempt to request any newer version of iOS on your behalf. Over time, I ended up having tens of millions of ECIDs on file, and had built out infrastructure allowing me to rapidly dump, in parallel, large numbers of SHSH blobs from Apple's servers as fast as I could (which in a way was not fast enough, and in a way was too fast for Apple ;P).
Over time, of course, it became impossible to have all of this service centralized, so I began saving the information using Cydia itself, based on an API I setup called "TSS@home" (which made more sense in its original incarnation, where devices would download work units and save TSS on behalf of others, but ended up being deployed to Cydia as a feature that saved SHSH only for the running device).
Offering such a service, where data is uploaded by random devices, has a serious problem: you have to deal with people who might be purposely uploading invalid or corrupt blobs. I thereby reached out to MuscleNerd while building TSS@home, who provided to me a sketch of an algorithm that could be used to validate blobs as they were uploaded in the same way that an iPhone would verify them during boot.
At this point, while I had only been trying to distribute the load (both for me and for Apple, as they seemed to have multiple, geographically dispersed servers handling this particular system) of requesting large numbers of SHSH blobs to computers around the world, what I ended up with was a service that allowed users to upload SHSH data, verify that data, and then retrieve it later. The developers of other tools that worked with SHSH thereby reached out to me asking how they could upload blobs.


Traduction 9ème partie:
Que signifie le service TSS Cydia?
Pour en revenir un instant sur le service que j'ai fourni pour stocker des informations TSS, il est important de savoir qu'il a été conçu pour SHSH. La raison pour laquelle je l'ai construit était d'avoir un moyen concret d'utiliser blobs SHSH sauvegardés: toutes les descriptions antérieures (y compris purplera1n.com originale geohot, qui permettait aux utilisateurs d'enregistrer un blob SHSH critique »pour une journée purplera1ny"), s'est fondé sur un outil comme redsn0w.
À l'époque, cependant, nous n'avons pas eu un tel outil, et donc besoin de quelque chose «plus simple». Mon idée était de construire une implémentation du serveur TSS, qui peut même fournir des informations de manière transparente d'Apple en passant par les demandes, qui serait capable d'enregistrer des informations sur son chemin à travers et puis plus tard, rejouer quand vous ne pourrez plus faire les demandes pour obtenir cette information auprès d'Apple.
Cela signifie que vous pouvez utiliser iTunes lui-même et effectuer des restaurations de n'importe quelle version vous aviez déjà installée précédemment en l'incitant à se connecter à mon serveur au lieu du serveur d'Apple (que nous avons utilisé "etc / hosts" entrées, ce qui est facile à configurer à la fois Windows et Mac OS X). J'ai également fourni une implémentation open-source de TSS que d'autres utilisés pour apprendre et construire des outils et des serveurs locaux.
Comme vous avez utilisé le serveur, j'ai aussi enregistré votre ECID, et tentera alors de demander toute nouvelle version d'iOS sur votre compte. Au fil du temps, j'ai fini par avoir des dizaines de millions de IDCI au dossier, et avait construit sur l'infrastructure de me permettre de rapidement vider, en parallèle, un grand nombre de blobs SHSH depuis les serveurs d'Apple aussi vite que je le pouvais (qui d'une manière n'était pas assez rapide, et d'une manière trop rapide pour Apple, P).
Au fil du temps, bien sûr, il est devenu impossible d'avoir tout cela centralisé, alors j'ai commencé à enregistrer les informations en utilisant Cydia lui-même, basée sur une API de configuration appelé I "TSS @ home" (qui fait plus de sens dans sa version originale, où les appareils seraient télécharger en unités de travail et d'économiser TSS pour le compte d'autrui, mais a fini par être déployé à Cydia comme une caractéristique qui a sauvé SHSH uniquement pour le périphérique en cours d'exécution).
Offrir un tel service, où les données sont téléchargées par des dispositifs aléatoires, a un sérieux problème: vous avez à traiter avec des gens qui pourraient être délibérément upload blobs invalides ou corrompus. J'ai donc tendu la main à MuscleNerd tout en construisant TSS @ home, qui m'a fourni un croquis d'un algorithme qui pourraient être utilisées pour valider les blobs comme ils ont été téléchargés de la même manière que l'iPhone serait de les vérifier lors de l'initialisation.
À ce stade, alors que j'avais seulement essayé de répartir la charge (à la fois pour moi et pour Apple, car ils semblaient avoir de multiples et dispersés géographiquement serveurs gérant ce système particulier) de demander un grand nombre de blobs SHSH pour ordinateurs à travers le monde, ce que j'ai fini par avoir était un service qui permet aux utilisateurs de télécharger des données SHSH, vérifier que les données, puis le récupérer plus tard. Les développeurs d'autres outils qui ont travaillé avec SHSH ainsi tendu la main pour me demander comment ils pouvaient télécharger des blobs.

What about APTicket storage?
When Apple introduced APTicket, the data my server was storing was no longer relevant. However, as part of the process of downloading SHSH information, Apple sends an APTicket as well. I thereby modified my service to also store the APTicket that was downloaded as part of the SHSH collection process (with some further help from MuscleNerd to learn how to validate and refer to APTicket instances ;P).
An additional modification was made to keep Cydia (or any other client using my TSS@home "check" API) to not claim that the SHSH information was stored for a particular ECID running a particular version of iOS unless an APTicket was also stored. No real changes were made to the system to make these APTickets happen: they were simply saved as a side effect of the requests that were already being made.
Apparently, this is what people needed, and for something like a year users were very happy with the APTickets that I was saving. As I described earlier, however: I really don't know much about APTicket, even now, and thereby have been reliant on the people building the tools that use APTicket to tell me what changes I needed to make, either to the verification process or the requests themselves.


Traduction 10eme partie:
Qu'en est-il du stockage APTicket?
Lorsque Apple a introduit APTicket, les données de mon serveur stockées n'étaient plus pertinentes. Toutefois, dans le cadre du processus de téléchargement de l'information SHSH, Apple envoie un APTicket ainsi. J'ai donc modifié mon service pour stocker le APTicket qui a été téléchargé dans le cadre du processus de collecte SHSH (avec l'aide de MuscleNerd pour apprendre à valider et à se référer à des instances APTicket, P).
Une autre modification a été faite pour maintenir Cydia (ou tout autre client en utilisant mes TSS @ home "check" API) de ne pas demander les informations SHSH qui ont été stockées pendant une ECID particulière et qui exécute une version spécifique d'iOS, à moins qu'une APTicket a également été enregistrée. Pas de réels changements ont été apportés au système pour faire ces APTickets: ils sont simplement enregistrés comme un effet secondaire des demandes qui ont été déjà faites.
Apparemment, c'est ce que les gens avaient besoin, et quelque chose comme un utilisateur de l'année ont été très heureux avec les APTickets que j'avais épargné. Comme je l'ai décrit plus haut, cependant: je ne sais vraiment pas grand-chose des APTicket, même maintenant, et de ce fait, j'ai compté sur les personnes qui construisent les outils qui utilisent APTicket de me dire quels sont les changements que je devais faire, que ce soit au processus de vérification ou les demandes elles-mêmes.

So, what is the problem here?
At this point, I think I have described everything I need in order to explain the current situation: all of the APTickets Cydia itself requested from Apple for iOS 6 are useless. The word "useless" is important, as it is not accurate to use the word "corrupt": the data that was uploaded was not lost or damaged, and in fact all of the tickets that were stored verified per the algorithm from MuscleNerd.
Instead, the requests being made via Cydia to collect SHSH information for iOS 6 did not result in useful tickets. This is because, in order to better emulate the requests Apple had been making when I first started the service, I filter the manifests I send to Apple to only include information about files that had the partial digests I discussed earlier, as only files that have partial digests are relevant for SHSH.
However, the APTicket signs complete digests, not partial digests, and so even descriptions of files that do not have partial digests need to be sent to TSS to get a complete ticket. What really should therefore be used as a filter is "files with digest information at all", not just those that have partial digests (there is never a partial digest without a full digest), effectively finding all "real" files.
The result is that the APTickets that were downloaded and saved by Cydia itself are not sufficient to boot a device. However, tickets that were downloaded or otherwise obtained by tools such as redsn0w, iFaith, or TinyUmbrella, will work fine. If those tickets are uploaded to Cydia and then downloaded back, they also will continue to work: it is only tickets downloaded by Cydia clients themselves that were affected.


Traduction 11ème partie:
Alors, quel est le problème ici?
À ce stade, je pense que j'ai décrit tout ce qu'il faut pour expliquer la situation actuelle: tout le Cydia APTickets lui-même demandé pour Apple pour iOS 6 sont inutiles. Le mot «inutile» est important, car il n'est pas juste d'utiliser le mot «corrompu»: les données qui ont été téléchargées n'ont pas été perdues ou endommagées, et en fait tous les billets qui ont été stockées sont vérifiées par l'algorithme de MuscleNerd.
Au lieu de cela, les demandes étant faites via Cydia pour recueillir des informations SHSH pour iOS 6 n'a pas entraîné de billets utiles. En effet, afin de mieux imiter les demandes Apple avait été prise quand j'ai commencé le service, je filtrais le manifeste-j'envoyais à Apple pour inclure uniquement les informations sur les fichiers qui a eu la "digestion partielle" dont j'ai parlé plus tôt, seuls les fichiers qui ont une "digestion partielle" sont pertinentes pour SHSH.
Toutefois, les APTicket complètes digère et pas partielle digère, et de sorte que même des descriptions de fichiers qui n'ont pas digère partielle doivent être envoyés au TSS pour obtenir un billet complet. Ce qui devrait donc être utilisé comme un filtre est "fichiers contenant des informations digest du tout», et pas seulement ceux qui ont des digestions partielles (il n'y a jamais un condensé partiel sans une pleine digest), effectivement trouver tous les "vrais" fichiers.
Le résultat est que les APTickets qui ont été téléchargés et enregistrés par Cydia lui-même ne sont pas suffisantes pour démarrer un périphérique. Cependant, les billets qui ont été téléchargés ou autrement obtenus par des outils tels que redsn0w, iFaith ou TinyUmbrella, fonctionne très bien. Si ces billets sont téléchargés sur Cydia, puis téléchargées en arrière, ils continueront de travailler: il est plus que billets téléchargés par les clients eux-mêmes Cydia qui ont été touchés.

(=>Désolé pour cette partie mais je ne vois ni ne lis correctement la traduction !!!) :mrgreen:

Why did no one notice this?
As stated before, my knowledge of APTickets has been entirely relegated to what I am told by the people who build tools that use APTickets: when APTickets were introduced, I assumed my service would simply become obsolete, but then extended the service at request of other developers as it seemed like it could still provide some benefit to the community (although increasingly less and less, it seems).
Meanwhile, all of the people who build tools that use APTickets also build tools that download APTickets. It therefore happened that developers such as MuscleNerd and iH8sn0w do not personally test their tools against data saved for users by Cydia's TSS client. As for myself, I've never actually used an APTicket as a user: until writing this article, I did not even know in what situations they were usable.
Still, iOS 6 has been out for months, and one would have expected that some users would have noticed the problem. However, given the complex limitations that we have on our usage of APTickets, many users (even in larger discussions on sites like JailbreakQA) believed themselves to be misusing the tools, or simply thought the tools needed to be updated, and so seemingly never reported the issues.
Finally, there simply hasn't been much reason for users to attempt to use any of the TSS information for iOS 6 during these months: for the entire release cycle of iOS 6.0, there was no untethered jailbreak available, so people mostly wished to use TSS to downgrade to iOS 5. Then, until a few weeks ago, iOS 6 had an untethered jailbreak available, so people did not need to restore or downgrade: they would just restore.
Thankfully, I have been told by MuscleNerd that changes have been made to redsn0w to make any similar situation we may potentially run into in the future (where the manifest information being used by our tools differs, causing Cydia to save unusable information) something that will be noticed while the signing window is still open (in fact, he believes the very first day), allowing things to be corrected.


Traduction 12eme partie:
Pourquoi personne n'a remarqué?
Comme indiqué précédemment, ma connaissance de APTickets a été entièrement relégué à ce qu'on me dit par les gens qui construisent des outils qui utilisent APTickets: quand APTickets ont été introduites, je suis entré en service serait simplement devenu obsolète, mais ensuite étendu le service à la demande des autres développeurs car il semblait qu'il pouvait encore offrir certains avantages à la communauté (bien que de plus en plus de moins en moins, il me semble).
Pendant ce temps, tous les gens qui construisent des outils qui utilisent APTickets ont aussi construit des outils de téléchargement d'APTickets. Il est donc arrivé que les développeurs tels que MuscleNerd et iH8sn0w n'ai pas personnellement tester leurs outils par rapport aux données enregistrées par le client pour les utilisateurs de TSS Cydia. Quant à moi, je n'ai jamais utilisé un APTicket en tant qu'utilisateur: jusqu'à écrire cet article, je ne savais même pas dans quelles situations ils sont utilisables.
Pourtant, iOS 6 a été pendant des mois, et l'on aurait pu s'attendre à ce que certains utilisateurs aient remarqué le problème. Toutefois, étant donné les restrictions complexes que nous avons sur notre utilisation de APTickets, de nombreux utilisateurs (même dans les grandes discussions sur des sites comme JailbreakQA) croyaient être un mauvais usage des outils, ou tout simplement pensé que les outils nécessaires pour être mis à jour, et apparemment jamais signalé les questions.
Enfin, il n'a tout simplement pas été beaucoup de raisons pour que les utilisateurs tentent d'utiliser toute information TSS pour iOS 6 au cours de ces derniers mois: pour le cycle de publication entière de iOS 6.0, il n'y avait pas de jailbreak untethered disponible, afin que les gens la plupart du temps souhaitent utiliser TSS de revenir à iOS 5. Puis, jusqu'à il ya quelques semaines, iOS 6 avait un jailbreak untethered disponible, afin que les gens n'aient pas besoin de restaurer ou à la baisse: ils suffit de restaurer.
Heureusement, j'ai été informé par MuscleNerd que des modifications ont été apportées à redsn0w de faire toute situation similaire, on peut éventuellement rencontrer dans l'avenir (où l'information se manifester utilisés par nos outils diffère, entraînant Cydia pour enregistrer les informations inutilisable) quelque chose qu'on remarquera alors que la fenêtre de signature est toujours ouverte (en fait, il croit que le premier jour), ce qui permet des choses à corriger.

What does this mean for me now?
Honestly, due to the various limitations on the exploits we have for the reuse of APTickets, not many users are affected by this issue. First, if you have a recent device, iOS 6 APTickets are entirely useless: you cannot use them to downgrade, you cannot use them to upgrade, you cannot even use them to just restore the version of iOS you are currently running; cached responses for iOS 5 are of general interest, not iOS 6.
The set of devices that are able to run iOS 6 and that are also old enough to be subject to this exploit is actually fairly small: only the iPhone 3G[S], iPhone 4, and the 4th generation iPod touch meet these requirements. In particular, no iPad, nor any recent iPhone (not even the iPhone 4S) has any known way to use cached iOS 6 TSS information. This means that 74.2% of Cydia users are not affected at all.
Secondly, for the remaining 25.8% of Cydia users for which cached iOS 6 APTickets could be useful, by far the primary purpose is to restore or otherwise recover the version of iOS you are currently running untethered. As an example, a user is currently running 6.1.2 and accidentally upgrades to 6.1.3. Alternatively, they accidentally break their iOS installation so badly that they need to restore.
In either of these two use cases, the alternative to an APTicket exploit is to upgrade to iOS 6.1.3; as this scenario is only applicable to people running older devices (those subject to limera1n), iOS 6.1.3 is still jailbreakable (as should all future versions of iOS on these devices), but the result will not be an untethered jailbreak: many users (including myself) really hate using tethered jailbreaks.
Thankfully, this situation is actually fairly easily solved: redsn0w has the ability to dump the full TSS information from a device (also using that same limera1n exploit). I thereby encourage users of devices capable of being exploited by limera1n (the iPhone 3G[S], iPhone 4, or 4th generation iPod touch) to download this tool right now and use it to upload complete TSS information.


Traduction dernière partie:
Qu'est-ce que cela signifie pour moi?
Honnêtement, en raison des limites différentes sur les exploits que nous avons pour la réutilisation des APTickets, pas beaucoup d'utilisateurs sont concernés par ce problème. Tout d'abord, si vous avez un appareil récent, iOS 6 APTickets sont tout à fait inutile: vous ne pouvez pas les utiliser pour downgrade, vous ne pouvez pas les utiliser pour mettre à niveau, vous ne pouvez même les utiliser pour simplement restaurer la version d'iOS que vous utilisez actuellement, les réponses mises en cache pour iOS 5 sont d'intérêt général, et non iOS 6.
L'ensemble des dispositifs qui sont en mesure d'exécuter iOS 6 et qui sont également assez vieux pour être soumis à cet exploit est en fait assez faible: seulement l'iPhone 3G [S], iPhone 4, et l'iPod de 4ème génération répondent à ces exigences. En particulier, aucun iPad, iPhone, ni aucun récent (même pas l'iPhone 4S) possède un moyen connu pour utiliser les informations mises en cache iOS TSS 6. Cela signifie que 74,2% des utilisateurs de Cydia ne sont pas affectés du tout.
Deuxièmement, pour le reste, 25,8% des utilisateurs de Cydia pour iOS 6 qui ont en cache APTickets pourrait être utile, et de loin, le principal objectif est de restaurer ou récupérer la version d'iOS que vous utilisez actuellement untethered. A titre d'exemple, un utilisateur est en cours d'exécution 6.1.2 et 6.1.3 accidentellement mises à niveau. Alternativement, ils cassent accidentellement leur installation iOS si mal qu'on a besoin de restaurer.
Dans chacun de ces deux cas d'utilisation, l'alternative à un exploit APTicket est de passer à iOS 6.1.3, que ce scénario ne s'applique qu'aux gens qui courent les appareils plus anciens (ceux qui sont soumis à limera1n), iOS 6.1.3 est encore jailbreakable (comme le devraient toutes les futures versions d'iOS sur ces appareils), mais le résultat ne sera pas un jailbreak untethered: de nombreux utilisateurs (moi y compris) déteste vraiment évasions tethered.
Heureusement, cette situation est en fait assez facile à résoudre: redsn0w a la capacité de vider les informations TSS complète à partir d'un périphérique (également en utilisant cet exploit limera1n même). J'ai donc encourager les utilisateurs d'appareils susceptibles d'être exploitées par limera1n (l'iPhone 3G [S], iPhone 4, iPod touch 4ème génération) pour télécharger cet outil dès maintenant et l'utiliser pour télécharger des informations TSS complète.


La traduction a été faite avec Google Traduction et mes petites compétences.
Toutefois, si expert il y a, je vous invite fortement à apporter les corrections nécessaires.
En vous remerciant de votre indulgence.
La source est entièrement de Jay Freeman (saurik) via Cydia.
:mrgreen:
Dernière édition par mike68660 le 09 Avr 2013, 19:15, édité 3 fois.
Image

Image Image
Avatar de l’utilisateur MDProz Admin
Admin
Messages: 22439
Inscription: 04 Avr 2012, 22:14
Pays: France

Re: Où sont passées mes données iOS 6 (SHSH...) ?

Message non lupar MDProz » 09 Avr 2013, 16:26

....Suite et fin de la traduction :mrgreen:

Note: I have been told by MuscleNerd that there is a minor issue in the current version of redsn0w that will cause blobs retrieved from the device to not be uploaded to Cydia's servers. He had intended to get a new version out by the time he had to leave for HITBSecConf2013 (an international security conference at which evad3rs is giving a presentation about evasi0n), but schedules did not permit this. I had then hoped that this new version of redsn0w could be released before this article, but due to the longer delay I have decided that this information needed to be released sooner.
Using the currently released version of redsn0w will still (as far as I understand) copy the active TSS data from your device and store them locally on your computer. It is then my understanding that redsn0w will be able to upload this information at a later time from your computer. Alternatively, there is a program called iFaith, developed by iH8sn0w, that can be used to immediately upload your TSS information; however, this program is only available for Windows (so users of OS X will definitely have to wait until the new version of redsn0w is available).


Traduction de la Note:
Note: J'ai été informé par MuscleNerd qu'il ya un problème mineur dans la version actuelle de redsn0w qui va provoquer des taches extraites de l'appareil pour ne pas être téléchargées sur les serveurs de Cydia. Il avait l'intention d'obtenir une nouvelle version par le temps qu'il a dû quitter pour HITBSecConf2013 (une conférence sur la sécurité internationale à laquelle evad3rs donne une présentation sur evasi0n), mais les horaires ne le permettaient pas. J'avais alors exprimé l'espoir que cette nouvelle version de redsn0w pourraient être libérée avant cet article, mais en raison de la prolongation du délai, j'ai décidé que cette information devait être libérée plus tôt.
En utilisant la version actuellement publiée de Redsn0w sera toujours (autant que je comprends) copier les données TSS actifs à partir de votre appareil et les stocker localement sur votre ordinateur. Il est alors, je crois comprendre que redsn0w sera en mesure de télécharger ces informations à une date ultérieure à partir de votre ordinateur. Sinon, il y a un programme appelé iFaith développé par iH8sn0w, qui peut être utilisé immédiatement et télécharger votre information TSS, mais ce programme n'est disponible que pour Windows (afin que les utilisateurs de Mac OS X devront certainement attendre jusqu'à ce que la nouvelle version de redsn0w soit disponible).


La traduction a été faite avec Google Traduction et mes petites compétences.
Toutefois, si expert il y a, je vous invite fortement à apporter les corrections nécessaires.
En vous remerciant de votre indulgence.
La source est entièrement de Jay Freeman (saurik) via Cydia.
:mrgreen:
Image

Image Image
Avatar de l’utilisateur MDProz Admin
Admin
Messages: 22439
Inscription: 04 Avr 2012, 22:14
Pays: France

Re: Où sont passées mes données iOS 6 (SHSH...) ?

Message non lupar sebiinhoo » 11 Avr 2013, 12:39

Sacré travail ! Bravo
iPhone 5S - iOS 8.1 Jailbreak
Avatar de l’utilisateur sebiinhoo Gamer Maitre
Gamer Maitre
Messages: 289
Inscription: 27 Oct 2010, 21:06
Prénom: Sebastien
Pays: France
Sexe: Homme

Re: Où sont passées mes données iOS 6 (SHSH...) ?

Message non lupar yamin » 11 Avr 2013, 13:25

Absent jusqu'au 15 Novembre
yamin Ancien
Ancien
Messages: 9620
Inscription: 29 Juil 2010, 10:01
Pays: France


 

Retourner vers Smartphones et Tablettes (Android, iOS et Windows)