Publié le : 23 juin 201515 mins de lecture
Nous vous l’avions annoncé puis expliqué, le « Kind of Jailbreak » du développeur KaKaRoTo (officiellement renommé « HEN » par son auteur, les lecteurs qui suivent le hack PSP y verront une référence évidente) qui permettra de lancer des homebrews sur les firmwares supérieurs au 3.56 revient sur le devant de la scène.
En effet, après quelques mois de développement et de rétro-ingénierie menés par KaKaRoTo et l’équipe de développeurs anonymes qui le supporte, le constat des avancées sur le HEN (contraction de l’expression « Homebrew Enabler » qui peut être traduite par « Activateur d’Homebrew » dans la langue de Molière) est mitigé.
Voici le message que veut faire passer KaKaRoTo à ce sujet par l’intermédiaire de son blog :
Voici un « rapide » constat à propos du 4.00 HEN (« Homebrew ENabler ») pour la PlayStation 3.
Depuis mes explications faites il y a deux mois, il y a eu beaucoup de progrès. Nous n’avons pas chômé, nous sommes un groupe d’à peu près dix développeurs travaillant depuis deux mois, parfois quinze heures par jour dans le seul but de permettre de lancer des homebrews sur les derniers firmwares de la console PlayStation 3.
Il y a trois piliers majeurs permettant l’accomplissement du HEN.
Premièrement, installer l’application sur la console (le fichier .pkg contenant l’homebrew). Cette partie là du travail est complètement terminée, tous les tests et débogages ont été réalisés avec succès.
Dans un second temps, il faut pouvoir lancer l’application homebrew fraîchement installée sur la console, c’est notre problème majeur.
La troisième composante du HEN est quelque chose que je ne divulguerai pas pour l’instant (c’est une surprise), mais elle est pratiquement terminée elle aussi, environ 60% à 70% du travail est fait (cela n’a rien à voir avec le peek&poke, les backup-managers ou d’autres choses dans le genre. Cela est et restera une solution pour la PlayStation 3 entièrement exempte de liens avec le piratage).
À présent, arriver à lancer les applications installées est la plus grosse partie du travail qui reste à accomplir, c’est sur cela principalement que nous avons potassé ces deux derniers mois. Comme certains d’entre vous le savent, si vous suivez mon compte Twitter, nous comptions à la base obtenir de l’aide de la part de Mathieulh par le biais de ses travaux sur « l’algorithme NPDRM hash » qui est nécessaire pour lancer des applications.
Mais Mathieulh étant réticent, il a continué à faire son show comme d’habitude afin que les gens lui lèchent les bottes (ou autre chose). Au final, il a refusé de partager cet « algorithme NPDRM hash » qui aurait permis au HEN de fonctionner. Ce qui aurait pu être mis à disposition de tout le monde en une semaine a terminé au point mort et nous sommes toujours loin d’arriver à destination.
Mathieulh est resté dans son délire « d’aider » via des « énigmes », ce qu’il pense être « très utile pour ceux qui ont un cerveau », mais qui casse les coui**** de ceux qui en ont vraiment un…
xDonc, il nous a dit que la solution à notre problème était cachée dans le appldr du firmware 3.56… que c’était quelque chose que le lv1 envoyait à l’appldr afin d’accomplir la « vérification du hash » et sa validation…
Nous avons alors passé un mois complet à faire tourner nos méninges, à suer autour de cette problématique jusqu’à épuiser nos neurones, pour finalement conclure que c’était que des conner***. Après un mois de rétro-ingénierie, d’étude de code ASM et de vérifications et re-vérifications de nos résultats : nous étions désormais sûrs que cet « algorithme NPDRM hash » n’était PAS dans le firmware 3.56 comme Mathieulh nous l’avait clairement affirmé à tous.
Il disait que c’était un hash « AES OMAC », mais après avoir repéré toutes les fonctions utilisant le système OMAC dans l’appldr nous avons découvert qu’il n’était pas impliqué dans le système de hash… il a enchaîné en disant « oh, je voulais dire que c’était un système de hash HMAC ». Donc nous avons recommencé le reverse et les vérifications, etc., avec la même conclusion. Nous sommes donc sûrs que la solution ne se trouve pas dans l’appldr.
Il a renchéri avec un « ah non, c’est dans le lv1 », pour plus de détails sur les bêtises qu’il a dites à ce propos,
Cela s’est déroulé juste après la dispute que j’ai eu avec lui (avec son arrogance usuelle) sur Twitter à propos du code qu’il avait « partagé » (pour votre information, le code qu’il a « partagé » n’était pas de lui, il a oublié de retirer le nom du développeur originel, j’ai les preuves de cette affirmation aussi, mais je ne peux pas publier le code. J’ai promis de ne pas le divulguer publiquement, j’ai donné ma parole et je ne compte pas revenir dessus, même si cela concerne quelqu’un que je ne respecte plus… de plus ce morceau de code était complètement inutile et m’a fait perdre une journée à lire ce fichier caduc non commenté/documenté).
Ce qui nous amène à nous demander pourquoi il insiste à donner des « conseils » via ses « énigmes » même après la dispute sur Twitter. Eh bien pour saboter notre travail et nous faire perdre du temps sur des pistes qui se révèlent fausses. Des mois de travail acharné perdus pour rien.
De toute façon, nous avons tous assimilé le fait que Mathieulh est un menteur doublé d’un imbécile (nous le savions déjà avant, mais nous lui avions donné le bénéfice du doute). Nous avons continué de travailler sans suivre ses « conseils/énigmes » inutiles. Nous nous sommes mis à tenter d’exploiter/décrypter le firmware 3.60+ afin d’obtenir « l’algorithm NPDRM hash ».
À présent, après quelques semaines de recherches, nous avons finalement réussi à comprendre complètement cette pierre manquante, « l’algorithme NPDRM hash », et voici pour tout le monde le résumé de ces recherches avec quelques pré-requis à savoir :
Un jeu PlayStation 3 est un fichier exécutable au format .SELF (une sorte de .exe si vous voulez un équivalent avec Windows), ces fichiers .SELF sont signés et encryptés. Pour les jeux PSN (qui ne se lancent pas depuis un disque Blu-Ray donc), il faut un système de sécurité additionnel appelé « NPDRM » (Network Platform Digital Rights Management environment). Donc un « .SELF NPDRM » est un exécutable encrypté et signé puis re-encrypté avec des informations additionnelles.
Sur les firmwares 3.55 ou antérieurs, nous sommes capables d’encrypter et signer nos propres fichiers .SELF pour qu’ils aient l’air d’être des « .SELF NPDRM » officiels (produits par SONY), ce qui amène le firmware à les exécuter sans souci. Cependant, ces « .SELF NPDRM » n’avaient pas exactement la structure des .SELF officiels de SONY. En effet, un vrai « .SELF NPDRM » contient des informations que la PlayStation ignore tout simplement, elle ne vérifie pas ces données, donc nous pouvions mettre n’importe quoi à cet emplacement, cela importait peu.
Depuis le firmware 3.60, le système vérifie et valide ces informations additionnelles, donc il peut faire la différence entre les fichiers « .SELF NPDRM » de SONY et les nôtres. C’est « le fameux « algorithme NPDRM hash » que nous essayons de reverser et reproduire, parce que dès que nous pourrons réaliser cette étape en produisant ces « informations additionnelles » valides, le système pensera de nouveau que nos « .SELF NPDRM » sont officiels et produits par SONY, ce qui nous permettra de lancer les applications que nous voulons.
Un autre point important à expliquer, j’ai parlé plusieurs fois de fichiers « signés », cela signifie qu’il y a une « signature ECDSA » dans le fichier que le système vérifie. La « signature ECDSA » est quelque chose qui permet à la PlayStation 3 de vérifier si le fichier a été modifié ou pas. C’est facile de valider cette signature, mais impossible de la créer sans les clés privées du système (vous pouvez faire la comparaison avec une vraie signature, vous pouvez voir la signature de votre père et la reconnaître, mais vous ne pouvez pas l’imiter parfaitement et vous êtes directement capables de détecter la tentative d’imitation de votre petit frère).
Donc, comment étions-nous capables de signer nos .SELF proprement en 3.55 ? Parce que cette « signature ECDSA » est juste une équation mathématique très compliquée (j’en ai encore des maux de tête à force d’avoir étudié ce système, je ferai sûrement un billet sur mon blog à ce propos, histoire d’expliquer dans des termes simples le fonctionnement de cette équation mathématique). Cette équation est basée sur un nombre généré aléatoirement pour pouvoir produire la signature. C’est là que SONY avait foiré son coup (pour le firmware 3.55 et antérieurs), ils utilisaient le même nombre constant à chaque fois, ce qui nous a permis de récupérer les clés privées (pour le firmware 3.55 et antérieurs) et de générer proprement nos signatures.
Pour résumer, un fichier « signé » est un fichier sur lequel nous avons implémenté la « signature ECDSA » qui ne peut pas être produite sans les clés privées qui sont elles-mêmes impossibles à trouver en temps normal, ce que nous avons pu faire au temps du firmware 3.55 ou antérieurs grâce à la grossière erreur de SONY.
Mais revenons à nos moutons. Donc, ce qui nous manque c’est « l’algorithme NPDRM hash » qui signe une deuxième fois le fichier, cette signature n’était pas vérifiée dans les firmwares précédents, mais depuis le firmware 3.60 cette faille a été bouchée et la signature NPDRM avec les « informations additionnelles » est bel et bien vérifiée par le système.
Maintenant que SONY utilise systématiquement un nombre aléatoire pour générer ses signatures, il est impossible de trouver les clés privées (en tous cas de la façon dont nous les avons trouvées par le passé).
En gros, pas de clés privées, pas de signature ECDSA. Pas de signature ECDSA, pas d’algorithme NPDRM. Pas d’algorithme NPDRM, pas de possibilité de lancer nos homebrews.
La raison pour laquelle nous avons perdu notre temps là dessus pendant deux mois, c’est que Mathieulh a menti en nous disant qu’il avait réussi à reproduire l’algorithme NPDRM. Rappelez-vous quand j’avais annoncé que mon HEN était réalisable sur le firmware 4.0, il avait « confirmé » que « sa méthode fonctionnait toujours et que l’algorithme NPDRM fonctionnait ». Eh bien il n’a rien fait et dit pour le prouver, il a juste menti à ce sujet, il n’y a aucun moyen qu’il ait pu reproduire l’algorithme NPDRM puisqu’il n’a pas les clés privées.
J’ai dit que j’allais fournir des preuves que Mathieulh est un menteur, les voici : il a dit que la solution se trouvait dans le firmware 3.56, c’était un mensonge. Il a dit que c’était un système hash AES OMAC, c’était un mensonge. Il a dit que c’était un système de hash HMAC, c’était un mensonge. Il a dit que c’était dans l’appldr, c’était un mensonge. Il a dit que c’était dans le lv1, c’était un mensonge. Il a dit qu’il pouvait reproduire cet algorithme, c’était un mensonge. Il a dit que cela « prenait une heure pour trouver la solution si vous avez un cerveau », c’était un mensonge. Il a dit qu’il avait vérifié que cela marchait sur 4.0, c’était un mensonge. Il a dit qu’il avait les clés privées, c’était un mensonge. Il a dit qu’une fois l’algorithme compris, nous pouvions le reproduire, c’était un mensonge. Il n’arrête pas d’appeler cela un « hash » alors que c’est faux, c’est une signature ECDSA (deux choses radicalement différentes dans leur définition et leur usage). La vérification est faite pas le vsh.self, ce n’est pas dans le lv2, ni dans le lv1, encore moins dans l’appldr. De plus, les clés privées étant inaccessibles, il ne peut pas créer ses propres .SELF NPDRM.
Vous avez maintenant la réelle raison de son refus de « partager ». C’est parce qu’il n’a rien à partager.
Pourquoi avoir fait tout cela ? À cause de son arrogance qui l’empêchait d’admettre qu’il n’y connaissait rien ou parce qu’il voulait nous mettre des bâtons dans les roues ? Pour moi, c’est du pur sabotage, ce n’était que des fausses pistes pour nous éloigner de la réelle solution, en admettant qu’il savait quelle partie du code il fallait reverser.
Il n’a pas été assez intelligent pour mentir sur des choses que nous ne pouvions pas vérifier, tant pis pour lui. Maintenant nous savons que c’est un menteur et j’espère que plus personne ne croira à ses mensonges.
Trêve de bavardages à propos de ce menteur et « m’as-tu-vu », revenons sur le 4.0 HEN, donc que va-t-il se passer ? Nous savons maintenant que nous ne pouvons pas signer les exécutables en firmware 3.60+, donc nous ne pourrons pas les lancer.
Ce que nous allons faire c’est aborder le problème d’une manière différente, une faille indépendante qui nous permettra de lancer nos homebrews installés. Nous essaierons aussi de trouver un exploit au niveau de la signature ECDSA, d’ailleurs nous aurons besoin de l’aide de la communauté pour cela. Avec un peu de chance, SONY a encore raté son système de signature ECDSA, par exemple en générant deux nombres aléatoires identiques, ce qui nous amènerait à trouver les clés privées.
Quand est-ce que le « jailbreak » sortira ? Si je le savais je vous le dirais, cela peut être dans une semaine comme dans trois mois. Tout dépend de la chance que nous avons ou pas. La seule chose que vous pouvez faire pour l’instant c’est être patients (et arrêter de me harceler sur Twitter à propos d’une date de release).
J’aimerais remercier l’équipe de développeurs qui m’aide à accomplir ce travail titanesque et qui ne se décourage jamais. J’aimerais aussi remercier un contributeur anonyme qui nous a rejoins récemment et qui a été un élément majeur dans le reverse du système (ce qui nous a permis de prouver que Mathieulh mentait).
Nous pensons tous que la liberté commence avec le savoir et que le savoir doit être accessible à tout le monde. C’est pourquoi nous partageons toutes ces informations, nous avons eu la confirmation de tous mes dires à peine hier (en trouvant la clé publique utilisée par le système et en vérifiant la signature) et puisque cette information n’aidera pas SONY à bloquer cette faille, nous avons décidé de la partager avec vous.
Nous croyons en la transparence, en l’ouverture d’esprit, nous croyons en un monde libre, et nous voulons en faire partie.
Si vous voulez en savoir plus sur la signature ECDSA, lisez cet article très intéressant qui explique tout en détail. De même, je vous invite à (re)regarder la présentation faite par la Team Fail0verflow qui a expliqué pour la première fois l’erreur béante de SONY sur la signature ECDSA, ce qui nous a amené les custom firmwares.
Merci de votre attention.
