Metagames - Custom Firmware 4.30

Récupéré sur gueux, traduit par un membre, source originelle teknicoconsolas => Waninkoko.

Citation:

1. Les clés privées ne peuvent pas être calculées pour les firmwares > = 3.56, et ne sont stocker dans aucun endroit , seulement Sony les possèdes , et si nous avons pu les obtenir c'été grâce à une erreur de leur part car ils ont mal appliqués l'algorithme de chiffrage , donc avec certaines opérations mathématiques nous avons pu calculer ces clés privées

2. Oui on peut créer un CFW 3.61, l'unique obstacle est de récupérer les clés publiques, lesquelles peuvent s'obtenir, avec une difficulté plus ou moins grande , mais on peut. Chaque loader est chiffrer avec une clé privée et est déchiffré par la clé publique correspondante. Mais le loader de plus bas niveau dans un FW est chiffrer et est déchiffré par le root key, qui est INVARIABLE parce que le root key public utilisé pour déchiffrer une instance loader se trouve dans le metldr (évidemment, le metldr doit posséder la clé publique pour déchiffrer le loader) et le metldr ne peut pas être mis a jour , c'est a dire que la rootkey ne peut pas changer d'une version a une autre de firmware parce que sa fausserait tout.

Donc , si nous voulons crée un firmware 3.61 , en modifiant le LV2 pour ajouter de nouvelle fonctionnalité , nous devons hacker toute la chaines de loader pour arriver au LV2:

METLDR -> LV0LDR -> LV0 -> LV1LDR -> LV1 -> LV2LDR -> LV2

C'est plus ou moins la chaine de loader ( j'ignore si il y a une petite difference dans le FW 3.61)

Le METLDR ne peut pas être mis a jour comme je l'ai dis.

Le METLDR déchiffre le LV0LDR avec le root key (le LV0LDR c'est le loader de plus bas niveau, apres le METLDR) et il l'exécute.

Le LV0LDR déchiffre le LV0 avec la lv0-key (cette clé peut changer entre chaque version de firmware puisque le LV0LDR peut être mis a jour et c'est pourquoi le LV0 nous pouvons le chiffrer avec une clé privée et mettre a jour le LV0LDR pour le déchiffré avec la nouvelle clé publique correspondante) et il l'exécute.

Le LV0 déchiffre le LV1LDR....

blablabla..

Le LV2LDR déchiffre le LV2 avec la lv2-key et il l’exécute.

C'est pourquoi, si nous voulons un CFW, nous avons besoin de déchiffrer le LV0LDR (avec la root key, publier par geohot et elle ne va jamais changer), modifier LV0LDR changer la clé de déchiffrage de LV0 (nous la changeons pour une clé qui est capable de déchiffrer un LV0 chiffré avec une clé privée que nous connaissons ...qu'elle clé privée? n'importe lequel, c'est une clé que nous générons), nous chiffrons LV0LDR avec le root key, et nous pouvons alors modifier le LV0 à notre guise puisque maintenant le LV0 sera déchiffré par une clé publique différente, de laquelle nous connaissons la clé privée. Et ainsi nous modifions toute la chaîne jusqu'à arriver au LV2, et le modifier

Puis bon, je raconte les grandes lignes de la méthode (quand je dis chiffré / déchiffré, je ne me rapporte pas aux contenus des loaders, parce que cela fonctionne avec un chiffrage symétrique AES.
Le RSA contrôlent les clés publiques / privées, avec l'objectif UNIQUE de vérifier que les dits loaders n'ont pas été modifiés).

Dans le cas du FW 3.61 le sujet est un peu plus complexe puisque les clés publiques RSA et les clés AES ne sont pas faciles à obtenir, mais il existe des méthodes pour les obtenir y a des gens qui les ont, et c'est pourquoi ce n'est pas impossible.

Maintenant, il faut prendre en compte qu'un seul CFW peut s'installer sur les consoles se trouvant en FW 3.55 ou inférieur, parce que dans les versions supérieures on utilise un nouvel superviseur , qui vérifie le paquet d'actualisation (les données internes du PUP,pour que ce soit plus clair) qui check les nouvelles signatures

Une dernière chose, certains pense que si, après avoir installer un CFW 3.56/3.60/3.61, vous ne pourrez pas recommencer à installer d'autre CFW (c'est-à-dire, vous restez pour toujours dans ce CFW ou mettre a jour en FW officiel). La réponse est OUI, mais bon, il est préférable d’éviter puisque, après avoir créé une instance CFW, nous pouvons modifier le VSH pour utiliser le vieille superviseur (qui lui ne check pas les nouvelles signatures et c'est pourquoi nous n'avons pas d'obstacle pour installer de nouveaux CFW), ou modifier l'APPLDR pour qu'il nous permette de charger le nouvel superviseur mais modifié pour qu'il ne vérifie pas les signatures (le nouvel superviseur peut être modifié, mais nous avons besoin de modifier aussi l'APPLDR de notre FW actuellement installé pour pouvoir rechiffrer une instance superviseur avec une clé privée connue et que tout de suite l'APPLDR est capable de le déchiffrer et de l'exécuter).

Voila c'est tout.