Le True Blue continue de faire parler de lui

Depuis deux jours, le True Blue fait pas mal parler de lui, principalement sur sa manière de fonctionner. Nous avons d'un côté la team AC1D qui nous signale que le True Blue ne fait qu'utiliser des fichiers du dev_flash, puis de l'autre l'équipe derrière le True Blue qui se défend de ces accusations en nous annonçant que tout cela n'est basé que sur des spéculations.

Alors que nous pensions que tout était dit, un nouveau message concernant le True Blue vient de faire son apparition et cette fois-ci pour défendre ses bienfaits. En effet, il y a peu, "XpreatorianX" (un membre de PS3Crunch) nous a laissé un billet destiné à montrer que l'annonce de la team AC1D était fausse et nous explique pourquoi.


Voici ce qu'il nous dit :

La supposée théorie sur les Sprx est fausse et je vais vous dire pourquoi.

J'écris ceci, dans le but de détruire toutes les fausses informations qui circulent sur les forums. J'espère que Gary passera par ici, pour confirmer mes dires à ce sujet.

Alors, pourquoi la théorie sur les Sprx est fausse ? Vous devez surement savoir que la PS3 utilise des clés pour chiffrer, déchiffrer et, fondamentalement, authentifier tout ce qui se trouve sur le système. Les jeux ne font pas exception à la règle. Les clés requises pour les jeux sont dans l'Appldr (IIRC. Ou c'est dans l'Isoldr. Mais je suis sûr à 95 % c'est dans l'Appldr.), et non pas dans des "pilotes" ou plutôt des Sprx dans le cas présent. C'est pour cela que personne n'a pris de Sprx à partir d'un firmware supérieur, pour les modifier, pour ensuite les mettre sur un custom firmware 3.55. C'est parce qu'ils n'ont rien à voir avec les jeux. De plus, il est impossible de le faire. C'est aussi la raison pour laquelle nous n'avons jamais touché aux Sprx à ce jour. Nous avons toujours travaillé avec des EBOOT qui sont signés avec les clés présentes dans l'Appldr.

Maintenant, si vous ne croyez toujours pas que la théorie sur les Sprx est 100 % fausse, posez-vous deux questions simples. Pourquoi personne n'a encore modifié de Sprx ? Pourquoi avons-nous toujours utilisé des eboot.bin et nous recherchons les clés de chiffrement des firmwares supérieurs ? C'est parce que les Sprx ne sont pas utiles pour le lancement des jeux.

Alors, pourquoi la team AC1D nous sort cette théorie ? Eh bien je ne vais pas m'engager sur ce terrain, mais il suffit de regarder où se trouve la scène underground en ce moment. Cela devrait vous donner une bonne indication sur leurs raisons. Mais ils ne font que de la désinformation.

Vous ne me croyez toujours pas ? Lisez donc le PS3devwiki alors.

Suite à ce message laissé par Xpreatorianx, Deank, créateur entre autres de multiMAN, a aussi souhaité laisser un message. Celui-ci est composé de quelques citations provenant de Xpreatorianx, ici elles seront dissociées par plusieurs citations. Voici ce qu'il dit :

Citation de Xpreatorianx :

Quiconque s'y connaît un peu sur la façon dont la PS3 fonctionne, sait que les Sprx n'ont rien à voir avec l'exécution des jeux sur le système. Tout ce qui concerne les jeux est contrôlé par l'Appldr et les clés, non pas les Sprx. Sinon les jeux seraient vendus avec les Sprx qui contiennent les clés, auquel cas nous les aurions déjà.

Sérieusement, nous n'avons jamais patché de Sprx pour faire tourner des jeux ? C'est vous qui le dites, mais les Sprx n'ont strictement rien à voir là-dedans.

Réponse de Deank :

En fait, ce n'est pas entièrement vrai. Quiconque n'y connaît rien en programmation (PC / Mac *nix PS2 / PS3) n'aurait rien compris. Je vais essayer de faire une explication très simple pour que tout le monde comprenne.

Laissons de côté les mots tels que Sprx/Self /Eboot.bin, nous parlerons ici d'exécutables (Self / Elf / Eboot.bin) et de bibliothèques ou modules (Sprx / Prx). Pour rendre la compréhension encore plus facile, il suffit de se dire que les exécutables sont des .Exe et que les bibliothèques / modules sont des .Dll comme dans un environnement Windows.

Quoi qu'il en soit, quand on parle de SPRX, vous devez différencier les Sprx des jeux et les Sprx du firmware, parce qu'ils sont légèrement différents, sur la façon dont ils sont utilisés.

Citation de The Xpreatorianx :

Sérieusement, nous n'avons jamais patché de Sprx pour faire tourner des jeux ? C'est vous qui le dites, mais les Sprx n'ont strictement rien à voir là dedans.

Réponse de Deank :

Eh bien si, nous l'avons fait. Même les ebootFIX / ebootMOD fonctionnent de cette manière ( Sprx => Self => Eboot.bin ), sinon rien ne fonctionnerait. Pensez qu'un sprx de jeu fonctionne comme une DLL, qui est juste composé d'un certain nombre de fonctions exportées dans un fichier à part, de sorte que vous n'ayez pas à tous les charger avec votre exécutable (Eboot.bin ou blabla.exe). Chaque fois que vous avez besoin d'une fonction dans la bibliothèque (sprx / dll) - vous chargez la bibliothèque, appelez la fonction et déchargez la bibliothèque. C'est tout à propos des fichiers Sprx.

Pour les Sprx du firmware, l'explication ci-dessus peut être utilisée, mais la principale différence est que toutes les applications utilisent ces bibliothèques dite "système". Que ce soit un jeu, le lecteur vidéo, l'application PS Store ou le logiciel de diaporama de photo. Chacune de ces applications a un moment donné utilisé un Sprx du firmware, parce qu'elles ont besoin de ces fonctions (pour accéder à des fichiers / dossiers, accéder au réseau, lire des images jpg / png, lire / monter / utiliser les archives Psarc).

Oublions un instant les clés de chiffrement et le cryptage, et concentrons-nous sur les firmwares et les différences notables entre les bibliothèques / Sprx.

Nous avons une console (appelons-la THE_BOX), possédant un firmware 3.XX et nous créons une application pour ce firmware, qui affiche un texte fantaisiste à l'écran. Une telle application ressemblerait à ceci :

• Charge les modules système : lib_screen.sprx (nous pouvons donc les utiliser) ;
• Charge le module système : lib_text.sprx ;
• Initialise l'affichage : utilise la fonction init_screen (1920, 1080, 3D) de la librairie système lib_screen.sprx ;
• Écrier le texte : utilise la fonction draw_text(x, y, “Hello World”, red_color, vertically, with_water_effect) de la librairie Système lib_text.sprx ;
• Attendre 30 secondes et quitter le processus.

Ainsi, nous testons notre application sur un firmware 3.XX et tout fonctionne comme prévu. Un joli texte est dessiné en Full HD en mode 3D et dispose d'un shader de type eau, pour qu'il ressemble vraiment à de l'eau.

Par accident, nous avons une deuxième console (THE_BOX_2), qui possède un firmware 1.XX (un peu vieux, mais nous avons besoin de tester notre application dessus dans tous les cas). Nous chargeons notre application et au lancement nous aurons plusieurs problèmes :

• Soit un écran noir ;
• Soit un texte "Bonjour tout le monde" en 2D, à l'horizontale et non à la verticale, avec une couleur gris terne et sans effets appliqués.

Que se passe-t-il réellement ?

Nous savons que THE_BOX_2 possède une ancienne version du firmware et probablement des modules système bien différents. Après une petite enquête, nous constatons que cette version du firmware possède ses bibliothèques / Sprx, mais qu'elles ne fournissent que des fonctionnalités limitées :

• Init_screen (1920, 1080) (il manque le paramètre 2d/3d)
• draw_text (x, y, "Bonjour le monde") (pas d'autres paramètres)

C'est un miracle si notre application a fonctionné en firmware 1.XX et n'a pas plutôt crashé.

Cela devrait expliquer pourquoi les bibliothèques (Sprx du firmware de la PS3) peuvent affecter le fonctionnement des jeux, des performances et de la compatibilité.

Maintenant, revenons à la réalité. En ce moment, des jeux demandent de posséder une version 3.6+, or nous pouvons encore les lire avec un firmware 3.55. Dans la plupart des cas, les jeux n'ont pas besoin ou n'utilisent pas toutes les fonctions présentes dans les bibliothèques système des firmwares récents. Heureusement, même maintenant avec le firmware 4.00 il y a des jeux qui utilisent des fonctions disponibles dans les Sprx des firmwares 3.41 et 3.55.

Alors, admettons que nous avons les clés et que le jeu en question n'utilise pas les librairies du firmware 4.0. Nous ouvrons nos jeux avec quelques outils pour les décrypter (provenant d'un firmware 4.0), puis nous modifions, signons (avec les clés du firmware 3.55) tous les Eboot.bin / Self / Sprx présents. Au final le jeu fonctionnera sur un firmware 3.55.

Maintenant, nous allons prendre un autre jeu et faire la même chose qu'au-dessus. Admettons que ce jeu soit particulier (comme la plupart qui vont suivre), et qu'il utilise en fait de nouvelles fonctions uniquement disponibles dans les nouveaux Sprx présents dans le firmware 4.0. Nous testons ce jeu et constatons que celui-ci ne démarre pas (écran noir) ou démarre avec une erreur, bloque au bout de deux minutes de jeu, etc.

Nous décidons donc de faire les choses proprement. Puisque nous sommes vraiment expérimentés, nous allons chercher les modules système que ce jeu particulier utilise dans le firmware 4.0. Il est évident que les Sprx de notre firmware manquent de quelques modules et nous devons trouver un moyen de les ajouter ou simplement trouver une méthode pour utiliser les nouveaux modules (en espérant qu'il ne bloqueront pas d'autres applications installées sur notre PS3). Pour commencer, il faut regarder les fichiers exécutables du jeu (Eboot.bin / Self) et les bibliothèques du jeu (Sprx) pour trouver quels modules sont utilisés. Bien sûr, ce n'est pas écrit en gros et en large et la plupart du temps vous ne voyez rien de facilement lisible, mais vous pouvez trouver les fonctions appelées en assembleur qui permettent de charger les modules avec des identifiants spécifiques. Après quelques jours / semaines, nous trouvons enfin tous les identifiants de module, alors maintenant nous connaissons les modules qui doivent être remplacés ou encore édités (parce qu'il est coutume d'appeler / utiliser des fonctions d'autres modules du système).

Une fois que nous sommes absolument sûrs que tout est bon, nous signons (et chiffrons si besoin) les fichiers de notre console THE_BOX_2 (utilisant l'ancien firmware) et nous pouvons apprécier le résultat.
Maintenant, revenons aux clés de chiffrement. Le "S" de "Sprx" et de "Self" signifie "Signé", il faut trouver un moyen de supprimer la protection de ces Sprx système et des jeu (Sprx / Self / eboot.bin) et ensuite travailler sur ce qu'ils contiennent. Une fois que vous avez fini, vous les signez à nouveau pour votre firmware avec les clés souhaitées (que ce soit pour un firmware 3.41, 3.55 ou 4.0).

Je ne possède pas un dongle True Blue et la raison de ce message est de donner une explication vraiment simplifiée de ce qu'on peut faire, même sans les clés du firmware 4.0.

C'est un challenge pour tout le monde, mais vous avez tous la possibilité de faire vos preuves en installant un firmware 3.15 sur votre PS3 et ensuite en essayant de modifier Uncharted 3 pour qu'il fonctionne sur ce firmware. Fondamentalement, c'est toujours la même chose. Si vous pouvez faire fonctionner Uncharted 3 sur un firmware 3.15, alors vous serez un héros et serez aimé de la scène PS3.

J'espère que ce message ne fut pas trop ennuyeux à lire pour vous, mais en tant que programmeur et étant quelqu'un qui a regardé et appris de tout ça, j'ai décidé de clarifier les choses pour que "tout le monde" puisse comprendre.

Enfin pour finir cette belle romance, voici un dernier message de Deank, qui a pour principal but de répondre à plusieurs messages postés sur PS3Crunch :

Les fichiers Sprx n'ont rien à voir avec la protection. Comme j'ai essayé de l'expliquer dans mon message, même si aucun(e) cryptage / clé  n'est / ne sont utilisé(s), il y a encore beaucoup de choses à faire pour tenter de lancer quoi que ce soit demandant un firmware supérieur dans l'environnement d'un firmware inférieur. Personne n'a dit que les clés se trouvaient dans les Sprx / Eboot / Self ou autre.

Les déclarations de la team AC1D concernant le vsh.self du firmware 4.00 à 3.41 sont ridicules. Elles ne montrent que leur manque de connaissances, le vsh étant chargé et utilisé entre les redémarrages de la PS3. Hormis cela, je pense avoir tout dit dans mon précédent post.

Les Sprx des jeux (comme tout self / Eboot.bin) doivent être décryptés (vous avez besoin des clés des firmwares supérieurs). Les Sprx du firmware aussi.

Il n'y a aucune possibilité en firmware 3.55 (ou 3.41 ou même 3.99) d'utiliser les Sprx du firmware 4.00.

Un jeu peut fonctionner que si tous les Sprx / Self / Eboot.bin sont déchiffrés et re-signés pour le firmware 3.55, mais la plupart exigeraient beaucoup plus, tout simplement parce que le firmware 3.55 ne possède pas les même fonctions / support.

Les déclarations de la team AC1D sont fausses et infondées.

Que caches-tu joli True Blue...

Eh bien, nous pouvons dire que le message de Deank (Dean pour les intimes) est très simple à comprendre. Si vous n'avez toujours pas compris, voici ce qu'il faut en retenir :

• Les Sprx (du firmware ou des jeux) sont des librairies qui contiennent plusieurs modules ;
• Les jeux utilisent les modules présents dans les Sprx du firmware ;
• Les Sprx du firmware 4.0 possèdent de nouveaux modules, absents dans les firmwares inférieurs ;
• Il faudrait décrypter les Sprx du firmware 4.0 pour pouvoir trouver les modules nécessaires au lancement des jeux 3.6+ sur un firmware 3.15 / 3.41 / 3.55.

Si vous ne comprenez toujours pas, alors n'hésitez pas à poser vos questions sur le forum. En attendant, restez connectés pour tout savoir de ce débat sans fin.