Pour beaucoup d'entre nous, les différentes versions de payloads publiés parfois en quelques jours peuvent prêter à confusion, sans compter certaines versions/mods d'Open Manager qui intègrent de nouveaux patch, qui sont retirés ensuite afin d'être intégré au Payloads.
Bref, difficile de si retrouver au milieu des versions Hermes et KaKaRoTo.
Ce dernier a décidé de s'exprimer à propos du Payload d'Hermes. Ces explications se sont tenues en deux temps avec l'avantage de comprendre un peu mieux les coulisses des payloads.
Installez-vous confortablement, prenez un café, c'est parti :
Le 15 octobre : The Payload mess...
Beaucoup de questions se posent concernant les différents Payload dont le dernier PL3 (le mien) et je remarque que peu de gens savent vraiment de quoi ils parlent.
Je vais donc essayer de clarifier le sujet.
Tout d'abord , je conseille à tout le monde d'oublier le payload v3 Hermes. Je ne soutiens pas son travail , et d'après moi, ce payload n'est pas un produit correctement développé . Il peut entrainer des crash système et n'est pas correctement écrit . Pour finir, il semble ne pas avoir compris le principe du Git et son fonctionnement.
De plus, PL3 contient déjà depuis un certain temps toute la partie de travail que je qualifierai de correct venant d'Hermes. Il prend en charge l'installation des mises à jour de jeu ou encore le lancement des backups sans BR. Le reste, présent dans le payload Hermes ne sert à rien et amène même à des plantages dans certain cas.
Certain d'entre vous ont pu voir et tester ma version , et beaucoup me demandent en quoi elle diffère des versions actuelles.
PL3 n'est pas basé, lui, sur l'appel système 36 pour diverses raisons en commençant par le fait que ce n'est pas le bon code à utiliser . Il mappe en effet (en dur) un dossier complet vers une valeur (/dev_bdvd ou /app_home ou /dev_flash ou encore toute valeur codée dans le payload). Ce qui veut dire que si nous ( j'entends par là les développeurs PSGROOVE ou PSFreedom) ne voulons pas gérer le support des backups , aucun payload actuel ne fonctionnera avec backup manager sans devoir le patcher auparavant.
J'utilise donc l'appel système 35 car plus logique . Dans ce cas , vous pouvez mapper n'importe quel nom de chemin et lui en donner un autre . Le principe de fonctionnement étant : syscall 35 (char *ancien_chemin, char *nouveau_chemin).
Il devient donc inutile dans ce payload de coder en direct le chemin /dev_bdvd , ou meme de mapper /app_home en autre chose directement dans le code. Ni même d'avoir un syscall 36 qui va modifier /dev_bdvd et /app_home et par là même bloquer les homebrews qui voudraient utiliser la fonction diskless du backup manager. Ainsi, plus la peine d'utiliser un payload patché pour le "firmware usb loader" . Ca fonctionnera tout simplement car le choix de mappage des chemins sera directement inclus dans le homebrew lui même. Ce qui veut dire que les backup managers vont directement mapper le /dev_bdvd vers le chemin de leur choix et cela fonctionnera sans soucis avec mon payload , nul besoin d'un payload patché pour ce type d'application.
En conclusion, les backups managers dépendant du syscall36 ne fonctionneront donc plus. Seule la version Gaia est aujourd'hui compatible avec PL3 mais je ne doute pas que d'autres seront modifiés pour supporter le syscall35
Il faut bien comprendre que cette fonction est amenée à devenir un standard . C'est ce que tout futur payload devrait utiliser . La solution développée pour le PSJAilbreak à base de syscall36 sera naturellement abandonnée.
Il est temps que les payloads soient développés selon un nouveau standard , découvrir une centaine de payloads différents sur le net est une aberration. J'ai toujours cru en un payload unique qui fonctionnerait pour tous, et c'est pourquoi j'ai développé le PL3. C'est la raison pour laquelle celui ci est totalement indépendant du PSfreedom , (le PSGroove ayant été porté il y a peu pour s'appuyer sur PL3) et à mon avis , c'est dans ce sens que tous les futurs développements devraient se diriger. De plus , grâce au PL3 vous accédez directement au support des firmwares antérieurs (3.01, 3.10, 3.15 et 3.41).
Un nouveau Payload vient de faire son apparition , celui , créé par Rancid , qui fusionne "le meilleur des 3 solutions existantes" (Hermes, Waninkoko et Mathieulh) et je ne peux comprendre comment tant de gens peuvent s'en féliciter. Ces personnes ne comprennent pas que ce type de payload est totalement inutile . le PL3 contient déjà depuis un moment toutes ces fonctionnalités . Alors pourquoi perdre du temps à refaire ce qui existe déjà ?
Si je réagis aujourd'hui, c'est pour faire comprendre à tout le monde qu'il ne sert plus à rien aujourd'hui d'attendre de nouveaux payloads et que vous pouvez dès à présent vous baser sur PL3 car il contient déjà toutes les fonctions utiles.
C'est après avoir reçu un P3Hub et testé dessus PSGroove que j'ai modifié le code (basé sur la version jevinskie) et que je l'ai depuis optimisé pour PL3.
Ce qui veut dire que PL3 est aujourd'hui totalement fonctionnel pour tous ceux qui veulent utiliser aussi bien PSFreedom que PSGroove.
Vous n'avez donc plus aucune excuse pour continuer à utiliser des produits obsolètes ou mal codés tels que les premiers payloads disponibles jusqu'à présent.
Je n'ai pas parlé du "peek&poke". Laissez moi vous donner mon point de vue là dessus.
Au niveau du PL3, cette fonctionnalité est désactivée tout simplement car totalement inutile et obsolète !!!!
J'ai jeté un oeil sur le code de différents backup managers et il semblerait que tous ont recours au "poke" pour modifier "quelque chose" en mémoire parce que les développeurs pensent que c'est son rôle de faire cela . Il n'en est rien .
Pour faire simple ... si vous développez un homebrew , ne lui laissez faire que ce qu'il est sensé faire et laissez le soin au payload de patcher le kernel. De la même façon que le rôle du PL3 n'est pas de mapper /dev_bdvd vers /dev_usb000/Mon_jeu et de l'inscrire en dur.
Patcher un kernel par ce moyen n'est pas la bonne solution car l'offset utilisé dans ce cas est dépendant du firmware , et donc diffèrent pour chacun d'eux.
Cette fonction est donc totalement inutile et d'ailleurs absente des versions linux sur pc .. pourquoi voudriez vous l'inclure dans un payload ?
Les seules personnes susceptible d'utiliser cette fonction sont les vrais développeurs qui souhaiteraient analyser et modifier un kernel à la volée , voir de créer un driver pour un kernel précis.
PS : J'ai mis à disposition un script capable de créer le .hex de tout matériel compatible PSGROOVE pour tout firmware ( <= 3.41) . Vous pourrez le trouver sur ma page de projet (PSGroove+PL3)
Ces fichiers viennent d'être mis à jour suite à quelques retours de plantage au lancement de certains backups.
Le 16 octobre : Pourquoi je n'aime pas le Payload Hermes :
Avant toute chose, le titre dit « pourquoi je n'aime pas le Payload d'Hermès ». Cela n'a donc rien à voir avec Hermès lui même. Je ne le connais pas, je ne lui ai jamais parlé, je ne sais pas quel genre de personne il est, et donc je n'ai aucune opinion sur ça personnalité.
Maintenant je voudrais clarifier quelques points. J'ai vu beaucoup de personnes m'attaquer pour avoir tapé sur Hermès, et bon nombre semble penser que je dis être meilleur que lui, ou quelque chose du genre. On dirait donc que j'ai créé une certaine confusion avec mes commentaires, dans mon ancien posr de blog. Je veux donc m'excuser, et être sûr qu'il n'y aura plus aucune confusion.
Quand je dis que le payload d'Hermes est « dangereux », les gens ne me comprennent pas. Non ce n'est pas dangereux pour votre PS3, pas de risque de brick ou autre. Le seul « danger » étant (dans certains cas) le crash...et donc le besoin de redémarrer la console...c'est tout. N'ayez donc pas peur que son travail puisse abimer (votre console) ou autre parce que, de ce que j'en sais, c'est faux.
Plusieurs personnes m'ont aussi dit « respecte ce qui a été fait », et je veux le faire. J'ai toujours respecté les gens, à chaque fois que j'ai terminé un travail, j'ai remercié ceux qui m'ont aidé à y arriver. Je ne recherche pas la notoriété ici (sinon j'aurais annoncé la release de PL3 il y a 3 semaines, quand je l'ai commencé). Je prend simplement du plaisir à faire ça dans mon temps libre. Hermes a contribué à de très belles choses et j'apprécie ce qu'il a fait, principalement quand il a réussi à régler le problème des contrôleurs avec certains jeux. C'était quelque chose de très difficile à corriger et j'ai été surpris de la rapidité avec laquelle il a trouvé une solution intelligente que je peux qualifier de « bon travail ». le reste de son travail sur le Payload, je n'apprécie pas trop et c'est ce que je veux développer dans ce message.
Pour ceux qui ne veulent pas connaître les détails techniques, laissez moi conclure en disant que si le Payload Hermes fonctionne pour vous, alors utilisez le. Je ne dis pas aux gens d'arrêter son utilisation. Je ne dis pas non plus que le PL3 fonctionne mieux. Peut être le fait il dans certaines situations, peut être pas. Le choix de l'utilisateur devrait toujours être « ce qui fonctionne pour vous ».
Le but du PL3 est de fournir un standard, et d'avoir une base de code commune pour tous ceux qui travaillent sur des payloads. De ce fait, PL3 devrait évoluer plus vite et avoir plus d'options...ou pas. Notez que c'est mieux pour les développeurs de payloads de baser ler travail sur le PL3. Mais encore une fois, cela n'a pas de sens pour les utilisateurs, si ce n'est clarifier la confusion autour de tous ces lanceurs, personne ne sachant lequel utiliser.
Je parle donc du PL3 comme un tronc commun pour les contributeurs. Les gens semble l'avoir baptisé « le payload de kakaroto », mais je n'ai jamais dit que c'était mon payload. PL3 est PL3, ce n'est pas uniquement mon travail et si vous regardez les logs, vous verrez que je ne suis pas l'unique contributeur. Le PL3 lui même intègre des patchs de Hermes, Wanikoko, Mathieulh. J'en ai amélioré quelques uns pour être sur que cela fonctionnerait mieux avec des firmwares différents du 3.41, mais il s'agit toujours de leur travail. PL3 n'est pas mon payload. PL3 est un payload partagé avec tous. De plus, PL3 en tant que projet contient de nombreux payloads (par défaut, pour développeurs, diump LV2, dump elfs, etc...)
PL3 n'est pas parfait, rien dans ce monde n'est parfait, donc il y aura des bugs. Cela ne fonctionnera pas pour certaines personnes. Qui sait ce qui arrivera. Mais je n'ai jamais dit que c'était parfait, les gens devraient arrêter de penser que j'ai dit ça. C'est écrit plus proprement, c'est une meilleure infrastructure, mais c'est la seul chose que je peut affirmer.
Pour ceux qui se plaignent du bouton de donation que j'ai ajouté au blog, je ne trouve pas cela recevable. Je ne mendie pas de l'argent (je n'ai rien reçu en 3 semaines pour ceux que ça intéresse). Si vous ne voulez pas donner, il n'y a aucune raison d'insulter à ce sujet. J'ai mis ce bouton pour que ceux qui apprécient le travail et veulent donner quelque chose puisse le faire. J'ai demandé des dons avant car j'avais besoin d'une PS3 de développement. J'ai déjà réuni assez d'argent pour l'acheter, je n'ai donc plus besoin de donations supplémentaires. Je ne demande donc plus d'argent, c'est aussi simple que ça.
Quand bien même, voici les explications techniques détaillées importantes des raisons pour lesquelles je n'aime pas son payload.
D'abord, le code n'est pas propre. On ne peut le maintenir. Le fait est qu'il donne son code source en fichier .rar plutôt qu'un format propre est certainement le défaut principal que je lui trouve. Oui cela ne change rien pour l'utilisateur, cela ne compte que pour le développeur. Le problème avec cette méthode de partage, est que vous n'avez aucun moyen de savoir sur quoi est basé le code. Il est donc difficile de savoir ce qui a changé. Et si vous y arrivez, à trouver cette base, et faite un écart, vous obtenez un écart gigantesque qui vous oblige à faire un reverse engineering pour comprendre ce qu'il a modifié. C'est compliqué et gênant pour les développeurs!
Pour ceux qui suivent mon twitter, vous pouvez voir combien de commentaires je poste. J'ai toujours préféré avoir de courts commentaires car chaque commentaire devient indépendant, s'explique de lui même, et facile à retrouver. Cela permet aussi de mieux intégrer, s'il ne vous faut qu'une section spécifique, vous ne prenez que ce qu'il vous faut, au lieu de copier coller tout le code et de l'éditer pour enlever le clutter. L'autre raison pour laquelle j'aime git c'est que s'il l'avait utilisé et que j'y aurais apporté une amélioration, le code lui serait encore crédité dans le log. Ca me permet d'avoir le code sans lui prendre ses droits d'auteur. Cela à permet à tous d'être crédité pour ce qui a été fait et je pense que c'est la meilleur solution pour un projet open source et communautaire.
La raison pour laquelle j'ai dit que son code pouvait crasher, c'est que son payload est devenu trop gros, et ne loge plus dans la mémoire du kernel, (1296 bytes). Il a donc décidé de déplacer le code à une position aléatoire (0x7fff000 je pense). Cela veut dire que son Payload ne fonctionnera que tant qu'aucune application, jeu ou kernel, n'utilisera de placement aléatoire, qui pourrait atterrir dans cette zone. Si cela arrive, alors le Payload sera écrasé et le kernel crashera. La bonne manière de faire (PL3 le fait), c'est d'allouer la mémoire durant l'initialisation du payload, de copier les fonctions voulues dans cette mémoire que nous avons et de faire en sorte que ces fonctions aient une position indépendante. De ce fait elles fonctionneront où qu'elles soient placées dans la RAM.
Une autre raison est la façon dont son syscall8 fonctionne. J'ai essayé de lire un assemblage et de faire un reverse engineering, et j'étais complètement perdu sans comprendre ce qui se passait. Il n'y a pas de commentaire (vous remarquerez que mon payload a un commentaire pour chaque instruction)...je vous demande comment je peux intégrer son syscall si je ne sais même pas ce qu'il fait. Si finalement il avait été sur git, j'aurais pu voir les commentaires et comprendre ce que chaque partie du code faisait...mais il n'a pas utilisé git alors...
La façon dont il a réparé le problème du contrôleur n'était pas non plus si bonne. Il a patché deux offset pour passez à une fonction qui décide à partir d'une certaine énumération quelle réponse donner. Et vous auriez contrôlé ça avec son propre sys call 8....pourquoi faire une telle chose? Cela rend le fix dépendant des personnes qui utilisent ce nouveau syscall et c'est inutile quand vous pouvez patcher directement la bonne valeur.
Je n'ai pas non plus aimé le fait que son code devienne un bordel indépendant du 3.41, et qu'il faudrait un boulot monstre pour essayer de le faire fonctionner sur le 3.15. J'ai déjà passé beaucoup de temps à nettoyer le payloads et les faire fonctionner avec d'autres anciens firmware, alors pourquoi s'écarter et écrire du code qui n'intègre pas cela, ça rend la collaboration plus difficile.
BIG RESUME 
en plus, bonjour les kikoos 
envoyer un message a RMC 
