Auteur Sujet: Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible  (Lu 4921 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne hanackin

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8169
  • Apple Fan Boy !

cydia shsh cydia shsh


Si vous allez dans cydia récemment, et que vous avez remarqué que vos SHSH n’apparaissaient plus, ne paniquez pas, ceci est tout à fait normal. Jay Freeman, alias Saurik, le créateur de Cydia vient d’implémenter une nouvelle méthode de sauvegarde de vos fichier SHSH. Les SHSH ainsi que les APTickets sont maintenant récupérés et sauvegardés pas le TSS Center, qui se trouve un peu plus dans la page d’accueil de Cydia.


Cependant, au vu de le dernière mise à jour iOS 6.1.3, Apple a bouché 4 des failles utilisées par le jailbreak, çà, plus le fait que la communauté du Jailbreak n’a toujours pas trouvé de méthode de uupgrade/downgrade récente, il n’y a à ce jour que les iPhone 3GS, iPhone 4 et iPod Touch 4 qui peuvent procéder à un downgrade de iOS 6.1.3 à 6.1.2 ou bien passer de 6.0 vers 6.1.2 par exemple.


Les autres iDevices sont condamnés à attendre le jailbreak iOS 7, si vous êtes passé à iOS 6.1.3 car il n’y a aura pas mise à jour du jailbreak d’ici là. Si vous avez un appariel iOS avec un Jailbreak Tethered sous iOS 6.0, 6.0.1, 6.1 et 6.1.2, vous pouvez installez le paquet « Evasi0n 6.0-6.1.2 Untether » qui est disponible dans Cydia. Et enfin, si vous disposez d’un appareil iOS, non Jailbreaké sous iOS 6.0, 6.0.1, 6.1 et 6.1.2, il vous suffit d’utiliser l’outil de Jailbreak Evasi0n pour le Jailbreaker


Pour plus de détails et d’informations, rendez-vous sur le forum, vous y trouverez un article de Saurik, expliquant et détaillant tout ceci.


on en parle


Mots-clés: iphonejailbreak, iphonejailbreak.fr

 Macbook Pro 15" - Mavericks 10.9.1 - itunes 11.1.3 
 Iphone 5(S), 4(S), Ipad 4, Mini - IOS 7.0.4  Jailbreak Evasi0n 1.0.1  FREE 
✦ ASUS X501A 17" - Windows 8.1 64 bits - itunes 11.1.3 ✦

Hors ligne hanackin

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8169
  • Apple Fan Boy !
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #1 le: 09 avril 2013, 14:01:27 »
Voici la traduction d'un article de Saurik à propos de tout ceci expliquant et détaillant la situation : http://www.saurik.com/id/15

------------------------------------------------------

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 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 lesquels je travaille ; la rédaction de ces articles peuvent être exténuant par moments, mais à un certain niveau, la tâche n'est pas qu'enrichissante, mais amusante.

Malheureusement, ce n'est pas pour ça que je rédige cet article: à la place, je suis ici pour être le porteur de mauvaises nouvelles qui vont probablement me faire obtenir une tonne de mails haineux. Plus précisément, je vous écris ceci pour dire à tous que les données TSS enregistrées sur Cydia pour iOS 6.0-6.1.2 sont inutilisables. Je vais aussi tenter d'expliquer quelques informations sur le processus, d’où vient l'erreur et ce que les utilisateurs peuvent maintenant faire à la place.

Dans le processus, je vais vous expliquer quelques parties du mécanisme de sécurité logiciel iOS 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 APTicket mises en cache (quelque chose dont je ne savais pas vraiment grand chose avant d'écrire cela).

Mon objectif est que d'ici la fin de cette article, vous lecteurs, allez comprendre suffisamment sur le processus pour apprécier l'erreur, l'historique de la question et pourquoi çà n'a pas été détecté avant. En outre, il faut espérer que cela sera un peu plus clair lorsque l'information en cache APTicket  sera utilisable (car il s'avère que les APTickets cachent une fourchette assez étroite des usages) et la façon dont les utilisateurs affectés pourraient-ê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ù sont enregistrés les APTickets  iOS 6 sont en fait les l'iPhone 3G(S), iPhone 4, et l'iPod Touch 4. Sur ces appareils, les utilisateurs peuvent , et probablement «devraient» enregistrer le APTicket qui existe actuellement en permettant leur appareil de démarrer. Cela peut être fait avec un outil qui peut récupérer cette information en utilisant l'exploit bootrom limera1n, tels que redsn0w ou iFaith, et télécharger le nouveau dans Cydia.)

Qu'est-ce que TSS ?

Un des aspects pour maintenir un système "sécurisé" est de vérifier que le logiciel qui est installé est le logiciel que vous attendiez. Ceci est fait en utilisant des "signatures" cryptographiques  qui peuvent démontrer l'authenticité d'un bloc de données, tels que le système d'exploitation l'exécute sur un appareil tel qu'un iPhone. Apple "signe" tous les logiciels qu'ils mettent sur un iPhone.

Quand le périphérique démarre, chaque étape vérifie la signature de la prochaine étape avant de passer à la suivante. En supposant que chaque étape fonctionne correctement, vous pouvez vous sentir en sécurité que tout le système exécute le logiciel qu'il 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éelle, 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 ya de nombreux bugs, petites et grandes, qui permettent aux "attaquants" de contourner les divers contrôles. Il est particulièrement difficile que les attaques peuvent permettre des choses comme evasi0n : un "jailbreak untethered", où le logiciel a été modifiée en permanence d'une manière qui va à chaque réinitialisation, ré-attaquer les exploits à chaque démarrage.

Par conséquent, on doit planifier la manière dont les corrections de bugs seront mis en place et seront nécessaires : il ne suffit pas de simplement signer des logiciels, car une fois qu'un bug est trouvé, les utilisateurs peuvent toujours juste revenir à cette version "boguée" connue, prendre le contrôle, puis éventuellement travailler sur leur chemin de retour, certainement, mais, même s'ils sont coincés à l'ancienne version, cela peut déjà être une perte assez coûteux.

La façon dont les fournisseurs généralement résolvent ce problème est de mettre des restrictions 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 un code daté (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é durant très longtemps 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 la dernière.

La Solution d'Apple qui e été déployée avec iOS 3.x (iOS 2.x était signée, mais n'avait pas de protection du tout pour le downgrade), était d'avoir chaque installation unique du système d'exploitation et de vérifier, à ce moment sur Internet, que la version du logiciel installé est "celle que nous avons pour but de vous permettre d'installer". Le vérificateur est le Tatsu Signing Server,, ou «TSS».

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écris il ya quelques années dans un article précédent, «Mise en cache du serveur de Signature d'Apple", consistait à «personnaliser» les fichiers qui étaient utilisés dans le cadre du processus du logiciel d'installation du système exploitation iOS (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é" dans un dossier qui 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 ont été utilisées pour ce processus sont appelées, selon l'endroit où vous le trouvez, la '"puce unique ID" ou le «ECID» (un acronyme dont personne n'est sûr de la signification derrière, mais cela signifie probablement quelque chose comme "identité à puce exclusive"). Cette ECID est un petit bloc de données représentées par un nombre qui est unique pour chaque appareil iOS d'Apple qui a été expédié.

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 des informations de personnalisation (qui est l'ECID), parfois quelques données aléatoires en apparence seulement "pour faire bonne mesure", c'est ainsi qu'une nouvelle signature signe l'intégralité du fichier.

La signature réelle à l'intérieur de ce blob est le SHSH, ou signature hash (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 de le signer: nous préférons les sauver.

Comment est compilé 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 «signez» 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é par une seconde clé "publique" que vous êtes en mesure de diffuser largement à l'avance pour toute personne qui s'en soucis.

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 a 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 de l'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êter, puis y revenir plus tard quand vous avez la deuxième partie. A tout moment, les données dont vous avez besoin sont 160 bits des données et la longueur que vous avez haché au préalable. Cela signifie qu'il existe un moyen efficace de «continuer de hacher 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 une "digestion partielle" sur le serveur dans le cadre d'une demande de TSS, qui est ensuite complétée par le serveur et signé avec sa clé.

Enfin, à l'intérieur d'un fichier de mise à jour logicielle iPhone (IPSW) (qui est en fait un fichier ZIP) il y a un «manifeste de version» qui contient une liste des noms de fichiers et, pour chacun, son empreinte (ce qui est le hachage de ses données, y compris la signature qui est attaché chez Apple) ainsi que l'une de ses digestions partielles pour le fichier sans le bloc signature sur la fin (de sorte qu'il puisse être complété par TSS).

Le processus de personnalisation implique en 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.

La mise en cache du serveur de 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 en plein milieu sur ce serveur qui pourrait tout simplement stocker tous les SHSH unique qui ont été renvoyés pour chaque fichier de chaque version du micrologiciel pour chaque appareil appartenant à toutes les personnes sont intéressées de pouvoir downgrader (les 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 j'avais é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 ECID de tous les utilisateurs dans une gigantesque base de données, afin qu'il puisse continuer à chaque fois qu'Apple publie une nouvelle version du firmware de demander des informations SHSH à tous "en masse".

Finalement, cependant, vous vous retrouvez avec autant d'ECID dans ​​le fichier que vous essayez de demander à un certain nombre de serveurs des centaines de milliers de fois moins, il devient donc très évident de savoir comment arrêter une telle opération. Pendant quelques années, je n'ai ainsi pas pu lancer le serveur proxy "man in the middle", ni être en mesure de fournir le service d'enregistrement automatique des SHSH des gens.

Cependant, j'ai toujours été en mesure d'aider les utilisateurs à obtenir automatiquement leurs données stockées par l'application Cydia "sur le terrain": Cydia demande les 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 pour moi pour le garder en lieu sûr.

Comment APTicket a changer les choses?

Lorsque iOS 5 est sorti, Apple a changé le jeu un peu : SHSH, le système dont je connaissais beaucoup de choses et avait passé énormément de mon temps à développer des outils pour récupérer et stocker des données étaient en chemin mais un nouveau système de vérification appelé APTicket avait été mis en place pour remplacer entièrement dans un certain nombre de dispositif à venir.

La personne qui a ensuite passé beaucoup de temps à étudier APTicket n'était pas moi : c'est effectivement MuscleNerd, le développeur de redsn0w. De plus, pas plus tard que fin Septembre2012, au JailbreakCon, j'ai pu entendre poser des questions de l'auditoire à iH8sn0w sur APTickets après sa présentation, comme si toutes mes connaissances sur la façon dont ils fonctionnent était secondaires; 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 en savoir un peu plus à ce sujet, mais j'étais surtout concentré sur la recherche de bogues dans l'analyseur de certificat et ne regardait qu'une seule étape du processus de démarrage, j'ai donc continué à ne pas savoir comment APTicket était utilisé, ou en tout cas comment les divers périphériques étaient affectés par leur présence.

Cependant, à un niveau élevé, ce qu'est l'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 pour démarrer le périphérique. 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 l'APTicket peut simplement stocker l'empreinte vierge d'origine des fichiers à partir du fichier IPSW.

En outre, il réduit considérablement le nombre de signatures dont le serveur d'Apple a besoin pour fonctionner : chaque fois qu'il publie une nouvelle version d'iOS, il exigence que le logiciel soit signé pour chaque périphérique spécifique qui nécessite un très grand nombre de signatures cryptographique, 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, l'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. Ce "nonce" est un nombre généré de façon aléatoire pendant le processus de restauration, et qui rend ainsi l'APTicket spécifique à chaque restauration simple et non mis en cache.

Mettre en cache le non mis en cache

La question est alors, et si les APTickets résolvent les problèmes qu'avaient les SHSH : pourquoi les gens les sauvent encore ? On aurait pu s'attendre à ce point que, quand Apple avait introduit les 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 : la compatibilité en arrière et un peu d'erreurs de mise en œuvre.

Tout d'abord, Apple ne peut pas juste reflasher le bootloader sur les dispositifs existants qui sont sur ​​le terrain et ceux-ci vérifiés par la première étape en utilisant SHSH. Cela signifie que si vous avez des données SHSH stockées pour cette première étape, il n'y 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 le nombre de nonce fixe que vous avez. Je crois comprendre que c'est comme ça que l'astuce de MuscleNerd "re-restore" fonctionne.

Profitant de ces erreurs qui ont permis quelques trucs intéressants, tels que permettre aux gens de passer d'une version d'iOS 5 à une autre, ou de permettre à l'iPad 2 d'être downgradé vers iOS 5 depuis iOS 6 (si vous avez les 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 s'il le souhaitent lire la FAQ JailbreakQA sur SHSH et APTicket.

Alors qu'est-ce qui est possible actuellement ?

Alors que ai mentionné un certain nombre d'astuces intéressantes, elles sont principalement liées soit à des anciennes versions d'iOS ou d'anciens appareils. Avec les nouveaux appareils, les 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é résolues. Comme les nouveaux appareils n'ont jamais eu accès à installations des versions plus anciennes d'iOS, ces limitations commencer à 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 qu'Apple ne peut pas résoudre et nous permet de contourner ou de modifier tout ce qui vient après lui dans la séquence de démarrage. En utilisant cet exploit, il est possible de downgrader ces dispositifs exploitables pour toute les 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 de revenir à iOS 4 (même à partir d'iOS 6) momentanément, puis de 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 ils sont exploitables avec limera1n et les périphériques iOS d'après sont sortis après 6 et ne peuvent 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 TSS iOS 4 sauvés.

La suite en dessous !
« Modifié: 09 avril 2013, 17:01:34 par hanackin »

 Macbook Pro 15" - Mavericks 10.9.1 - itunes 11.1.3 
 Iphone 5(S), 4(S), Ipad 4, Mini - IOS 7.0.4  Jailbreak Evasi0n 1.0.1  FREE 
✦ ASUS X501A 17" - Windows 8.1 64 bits - itunes 11.1.3 ✦

Hors ligne hanackin

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8169
  • Apple Fan Boy !
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #2 le: 09 avril 2013, 14:01:39 »
Qu'est-ce que le service TSS de Cydia fait ?

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 les blobs SHSH sauvegardés : toutes les descriptions antérieures (y compris purplera1n.com, l'originale de geohot, qui permettait aux utilisateurs d'enregistrer un blob SHSH critique "for a purplera1ny day"), s'est fondé sur un outil comme redsn0w pour un jour exister.

À l'époque, cependant, nous n'avions 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 des demandes, qui seraient capable d'enregistrer des informations à travers de son chemin et puis plus tard, les refaire quand vous ne pouviez plus faire les demandes pour obtenir cette information auprès d'Apple.

Cela signifie que vous pouviez utiliser iTunes lui-même pour effectuer des restaurations de n'importe quelle version que vous aviez déjà installé précédemment en l'incitant à se connecter à mon serveur au lieu du serveur d'Apple (que nous avions en utilisant les entrées "etc/hosts", ce qui était facile à configurer à la fois sur Windows et Mac OS X). J'avais également fourni une implémentation open-source de TSS que d'autres pouvaient utiliser pour apprendre et construire des outils et des serveurs locaux.

Pendant que vous utilisiez le serveur, j'enregistrais aussi votre ECID et tentais alors de demander toute nouvelle version d'iOS sur votre compte. Au fil du temps, j'avais fini par avoir des dizaines de millions de ECID et avais construit une l'infrastructure qui me permettait 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 rapide assez, et d'une autre manière trop rapide pour Apple, P).

Au fil du temps, bien sûr, il est devenu impossible d'avoir tout ce service centralisé, alors j'ai commencé à enregistrer les informations en utilisant Cydia lui-même, basé sur une API de configuration appelée "TSS@home" (qui a plus de sens dans sa version originale, où appareils téléchargeaient des unités de travail et sauvaient des TSS pour le compte d'autrui, mais a fini par être déployé dans Cydia comme une caractéristique qui sauve le 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, pose un sérieux problème : vous avez à traiter avec des gens qui pourraient délibérément uploader des 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 pourrait être utilisées pour valider les blobs comme ils ont été téléchargés de la même manière que l'iPhone pourrait 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 serveurs et dispersés géographiquement gérant ce système particulier) de demander un grand nombre de blobs SHSH par ordinateur à travers le monde, ce que j'ai fini par avoir est un service qui permet aux utilisateurs de télécharger des données SHSH, vérifier les données, puis de les récupérer plus tard. Les développeurs d'autres outils qui ont travaillés avec les SHSH m'ont ainsi tendu la main pour me demander comment ils pouvaient télécharger des blobs.

Et à propos du stockage des APTicket ?

Lorsqu'Apple a introduit APTicket, les données que mon serveur stockait 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 aussi 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 mon API "vérification" TSS@home") afin de ne pas demander que les informations SHSH étaient stockées pour une ECID particulière pour une version spécifique d'iOS, à moins qu'une APTicket soit également enregistrée. Pas de réels changements ont été apportés au système afin de permettre que ces APTickets arrivent : ils ont simplement été enregistrés comme un effet secondaire des demandes qui ont été déjà faites.

Apparemment, c'est ce dont les gens avaient besoin, et quelque chose comme l'année dernière, les utilisateurs étaient très heureux avec les APTickets que je sauvegardaient. Comme je l'ai décrit plus haut, cependant : je ne sais vraiment pas grand chose sur APTicket, même maintenant, et de ce fait j'ai compté sur les personnes qui construisent les outils qui utilisent APTicket pour me dire quels étaient les changements que je devais faire, que ce soit dans processus de vérification ou les demandes elles-mêmes.

Mais alors quel est le problème ?

À ce stade, je pense que j'ai décrit tout ce qu'il faut pour expliquer la situation actuelle : tout les APTickets que Cydia lui-même a demandé a 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és son vérifiés par l'algorithme de MuscleNerd.

Au lieu de cela, les demandes étant faites via Cydia pour recueillir des informations SHSH pour iOS 6 n'ont pas entraînées de billets utiles. En effet, au lieu de mieux imiter les demandes qu'Apple mis en place quand j'ai commencé le service, je filtrais le manifeste que j'envoyais à Apple pour inclure uniquement les informations sur les fichiers qui avaient eu le digest partiel dont j'ai parlé plus tôt, seuls les fichiers qui ont un digest partiel sont pertinents pour les SHSH.

Toutefois, les signatures APTicket complètent le digest, pas de digest partiel et donc même des descriptions de fichiers qui n'ont pas digest partiel doivent être envoyés au TSS pour obtenir un billet complet. Ce qui devait donc être utilisé comme un filtre est "fichiers contenant des toutes informations digest" et pas seulement ceux qui ont des partiels (il n'y a jamais un digest partiel digest complet), pour 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 suffisants 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, fonctionnent très bien. Si ces billets sont téléchargés dans Cydia, puis téléchargées après, ils continueront de fonctionner : ce ne sont que les billets téléchargés par les clients Cydia eux-mêmes qui ont été touchés.

Pourquoi est-ce que personne ne l'a remarqué ?

Comme indiqué précédemment, ma connaissance des APTickets avait été entièrement relégué à ce que me disaient les gens qui construisent des outils qui utilisent APTickets : quand les APTickets avaient été introduis, mon entré en service était simplement devenue obsolète, mais j'ai ensuite étendu le service à la demande d'autres développeurs car il semblait qu'ils pouvaient 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 construisaient des outils qui utilisaient des APTickets construisaient aussi des outils qui téléchargeaient des APTickets. Il est donc arrivé que les développeurs tels que MuscleNerd et iH8sn0w n'aient pas personnellement testé leurs outils par rapport aux données enregistrées par le client pour les utilisateurs de TSS Cydia. Quand à moi, je n'avais jamais utilisé un APTicket en tant qu'utilisateur : jusqu'à écrire cet article, je ne savais même pas dans quelles situations ils étaient utilisables.

Pourtant, iOS 6 a été présent pendant des mois et l'on aurait pu s'attendre à ce que certains utilisateurs remarquent le problème. Toutefois, étant donné les restrictions complexes que nous avions sur notre utilisation des APTickets, de nombreux utilisateurs (même dans les grandes discussions sur des sites comme JailbreakQA) pensaient à une mauvais utilisation des outils ou tout simplement pensaient que les outils nécessaires devaient être mis à jour et apparemment n'ont jamais soulevé des questions.

Enfin, il n'y a avait tout simplement pas 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, donc les gens la plupart du temps souhaitaient juste utiliser TSS afin de revenir à iOS 5. Puis, jusqu'à il y a quelques semaines, iOS 6 eu enfin un jailbreak untethered disponible, et les gens n'ont pas eu besoin de restaurer ou downgrader : il suffisait juste de restaurer.

Heureusement, j'ai été informé par MuscleNerd que des modifications avaient été apportées à redsn0w afin que toute situation similaire que l'on pourrait éventuellement rencontrer dans l'avenir (où l'information manifestement utilisée par nos outils différait, entraînant Cydia d'enregistrer des informations inutilisable) quelque chose qui va être signalé alors que la fenêtre de signature est toujours ouverte, ce qui permet de corriger des choses.

Qu'est-ce que cela signifie pour moi maintenant ?

Honnêtement, en raison des différentes limites 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, les APTickets iOS 6 sont tout à fait inutiles : vous ne pouvez pas les utiliser pour le downgrade, vous ne pouvez pas les utiliser pour mettre à niveau, vous ne pouvez même pas les utiliser pour simplement restaurer la version d'iOS que vous utilisez actuellement, les réponses de 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 Touch 4 répondent à ces exigences. En particulier, aucun iPad, iPhone, ni aucun récent (même pas l'iPhone 4S) ne possèdent un moyen connu pour utiliser les informations TSS iOS 6 mises en cache. Cela signifie que 74,2% des utilisateurs de Cydia ne sont pas affectés du tout.

Deuxièmement, pour le reste, les 25,8% des utilisateurs de Cydia sur iOS 6 qui mettent en cache les APTickets est être utile, et de loin, pour le principal objectif qui est de restaurer ou de récupérer la version d'iOS untethered que vous utilisez actuellement. A titre d'exemple, un utilisateur est en cours d'exécution 6.1.2 et accidentellement met à niveau vers 6.1.3. Alternativement, ils endommagent accidentellement leur installation iOS a tel point qu'il a besoin de restaurer.

Dans chacun de ces deux cas d'utilisation, l'alternative à un exploit APTicket est de passer à iOS 6.1.3, comme ce scénario ne s'applique qu'aux gens qui possèdent des appareils plus anciens (ceux qui sont soumis à limera1n), iOS 6.1.3 est encore jailbreakable (comme devraient l'être 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 devoir utiliser un jailbreak 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) de télécharger cet outil dès maintenant et de l'utiliser pour télécharger des informations TSS complètes.

Note : J'ai été informé par MuscleNerd qu'il y a un problème mineur dans la version actuelle de redsn0w qui va provoquer les blobs extraient de l'appareil de ne pas être téléchargés sur les serveurs de Cydia. Il avait l'intention de faire une nouvelle version mais il a dû s'absenter pour la HITBSecConf2013 (une conférence internationale sur la sécurité à laquelle evad3rs donne une présentation sur evasi0n). 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élais, j'ai décidé que cette information devait être libéré plus tôt.

En utilisant la version actuellement publiée de Redsn0w il sera toujours (pour autant que je comprends) possible de copier les données TSS actifs à partir de votre appareil et de les stocker localement sur ​​votre ordinateur. Et selon ce que je crois comprendre, 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 pour télécharger votre information TSS, mais ce programme n'est disponible que pour Windows (les utilisateurs de Mac OS X vont certainement devoir attendre que la nouvelle version de redsn0w soit disponible).
« Modifié: 09 avril 2013, 20:04:49 par tonio026 »

 Macbook Pro 15" - Mavericks 10.9.1 - itunes 11.1.3 
 Iphone 5(S), 4(S), Ipad 4, Mini - IOS 7.0.4  Jailbreak Evasi0n 1.0.1  FREE 
✦ ASUS X501A 17" - Windows 8.1 64 bits - itunes 11.1.3 ✦

Hors ligne hanackin

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8169
  • Apple Fan Boy !
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #3 le: 09 avril 2013, 14:05:21 »
réservé

 Macbook Pro 15" - Mavericks 10.9.1 - itunes 11.1.3 
 Iphone 5(S), 4(S), Ipad 4, Mini - IOS 7.0.4  Jailbreak Evasi0n 1.0.1  FREE 
✦ ASUS X501A 17" - Windows 8.1 64 bits - itunes 11.1.3 ✦

Hors ligne hanackin

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8169
  • Apple Fan Boy !
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #4 le: 09 avril 2013, 17:04:30 »
première partie de la traduction terminée !!!  :)thermo je m'attaque à la deuxième !  :=think2

 Macbook Pro 15" - Mavericks 10.9.1 - itunes 11.1.3 
 Iphone 5(S), 4(S), Ipad 4, Mini - IOS 7.0.4  Jailbreak Evasi0n 1.0.1  FREE 
✦ ASUS X501A 17" - Windows 8.1 64 bits - itunes 11.1.3 ✦

Hors ligne maitre.artificier

  • Passe sa vie sur iphonejailbreak
  • ********
  • Messages: 6019
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #5 le: 09 avril 2013, 18:10:57 »
C'est toi le malade mon ami, merci pour ce boulot de fou!!

:pol: Pas de discussions concernant des applications / tweaks et sources crackées sur le forum, merci!! :pol:

Hors ligne Marmoul

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 6968
  • Apple of the firefighters
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #6 le: 09 avril 2013, 18:11:51 »
Bravo pour la traduction
 :)thanks1

Hors ligne hanackin

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8169
  • Apple Fan Boy !
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #7 le: 09 avril 2013, 18:56:10 »
bon c'est fini !!  :)div51 si avec avec çà vous n'avez pas tout compris, je ne peux plus rien pour vous !!  :!txt34

 Macbook Pro 15" - Mavericks 10.9.1 - itunes 11.1.3 
 Iphone 5(S), 4(S), Ipad 4, Mini - IOS 7.0.4  Jailbreak Evasi0n 1.0.1  FREE 
✦ ASUS X501A 17" - Windows 8.1 64 bits - itunes 11.1.3 ✦

Hors ligne batistab17

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8047
  • Apple's addict
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #8 le: 09 avril 2013, 19:25:23 »
 thankstourne:) au top cette traduction, tu es un pro de l'anglais moi je vais devoir retourner prendre des cours  :!txt34
iPhone 5S sous l'iOS 10.2



Hors ligne hanackin

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8169
  • Apple Fan Boy !
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #9 le: 09 avril 2013, 19:47:35 »
thankstourne:) au top cette traduction, tu es un pro de l'anglais moi je vais devoir retourner prendre des cours  :!txt34

en même temps je suis bilingue, je parle anglais depuis que je suis petit  :)div51

 Macbook Pro 15" - Mavericks 10.9.1 - itunes 11.1.3 
 Iphone 5(S), 4(S), Ipad 4, Mini - IOS 7.0.4  Jailbreak Evasi0n 1.0.1  FREE 
✦ ASUS X501A 17" - Windows 8.1 64 bits - itunes 11.1.3 ✦

Hors ligne batistab17

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8047
  • Apple's addict
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #10 le: 09 avril 2013, 19:49:13 »
Ah oui ça aide  :!txt34
iPhone 5S sous l'iOS 10.2



Hors ligne Marmoul

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 6968
  • Apple of the firefighters
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #11 le: 09 avril 2013, 19:57:35 »
Moi aussi je suis bilingue...
Après un gros apéro je parle le franglais angel57;) :!txt16

Hors ligne tonio026

  • Modérateur Global
  • Permanent
  • *****
  • Messages: 1721
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #12 le: 09 avril 2013, 20:06:07 »
je n'ai trouvé que 4 petites fautes. j'avais commencé a essayer de traduire, mais quand je lis ce que tu as traduit, je ne comprends même pas en français alors.....
chapeau bas mon ami!!!

IPHONEJAILBREAK EST UNE SACRE BONNE RAISON D'ETRE HEUREUX

Hors ligne hanackin

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8169
  • Apple Fan Boy !
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #13 le: 09 avril 2013, 20:07:22 »
je n'ai trouvé que 4 petites fautes. j'avais commencé a essayer de traduire, mais quand je lis ce que tu as traduit, je ne comprends même pas en français alors.....
chapeau bas mon ami!!!

corrige les fautes poto fais toi plaise  ;D

 Macbook Pro 15" - Mavericks 10.9.1 - itunes 11.1.3 
 Iphone 5(S), 4(S), Ipad 4, Mini - IOS 7.0.4  Jailbreak Evasi0n 1.0.1  FREE 
✦ ASUS X501A 17" - Windows 8.1 64 bits - itunes 11.1.3 ✦

Hors ligne debels

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 5601
  • aller de l'avant
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #14 le: 09 avril 2013, 20:28:30 »
Oui l'ami bravo pour ce taf.rien que de regarder j'ai la migraine et en plus la langue de shakespeare et moi on à jamais été copain.bravo Hanakin.quand je vois le mal que je me donne des fois pfffffffffff

Galaxy note3
Ipodtouch5G
appletv3
timecapsule
Imac 27  2013

Hors ligne hvdcgkl

  • Administrateur
  • Se shoote à l'iphonejailbreak.fr
  • *****
  • Messages: 13109
    • Team iphonejailbreak
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #15 le: 10 avril 2013, 10:22:32 »
Superbe boulot de traduction merci mon ami

****************************************
Nouveau twitter : http://twitter.com/hvdcgkl1
Mon twitter officiel refonctionne http://twitter.com/hvdcgkl

Hors ligne Fabinio

  • Passionné
  • Administrateur
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 6587
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #16 le: 10 avril 2013, 22:51:20 »
Superbe boulot de traduction merci mon ami

Pfff oué c'est clair
Merci et bravo hanackin

Pour débloquer  votre téléphone ça se passe sur cette image

Hors ligne hanackin

  • Modérateur Global
  • Passe sa vie sur iphonejailbreak
  • *****
  • Messages: 8169
  • Apple Fan Boy !
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #17 le: 10 avril 2013, 22:59:16 »
 :)thanks1 les gars  ;D

 Macbook Pro 15" - Mavericks 10.9.1 - itunes 11.1.3 
 Iphone 5(S), 4(S), Ipad 4, Mini - IOS 7.0.4  Jailbreak Evasi0n 1.0.1  FREE 
✦ ASUS X501A 17" - Windows 8.1 64 bits - itunes 11.1.3 ✦

Hors ligne akh99

  • Junior
  • **
  • Messages: 93
  • dans la matrice...
Une nouvelle méthode de sauvegarde des shsh dans Cydia est disponible
« Réponse #18 le: 11 avril 2013, 09:09:47 »
merci beaucoup
c'est très intéressant
____________________________________
iPhone5 ios 9.0.2 JB
iPodTouch 4 ios 7.1.2 JB
iPad 4 ios 8 JB
Apple TV 3
Samsung Galaxy note 10.1 (oups!...)