Les payloads ... la grande confusion

KaKaRoTo, le célébre développeur de la scène PS3 à l'origine du PSfreedom et du support pour les FirmWare 3.00 3.10 et 3.15, met les choses au clair sur les payloads via son blog. En effet vous l'avez sans doute remarquer depuis quelques jours règne sur la scène PS3 une confusion totale concernant les payloads. Il en profite également pour critiquer le travail de Hermes ... ce qui ne motivera certainement pas son retour sur le scène.

Traduction de ps3addict

Bonjour à tous,

Je vois beaucoup de gens qui me posent des questions et je constate beaucoup d'ignorance sur le net à propos des différents payloads et le dernier payload PL3. Je veux donc clarifier les choses...
Premièrement, les gens devraient arrêter de parler/demander/utiliser le payload Hermes v3, je n'aime pas son travail, et le payload n'est pas bon, il peut crasher le système dans certains cas, il n'est pas écrit correctement, et Hermes ne semble même pas comprendre comment fonctionne le Git.
Aussi, PL3 inclut déjà (depuis un certain temps) toutes les bonnes choses d'Hermes, il supporte déjà l'installation des mises à jour de jeux, ou le fait de pouvoir faire tourner les jeux sans disque, tout ce que Hermes a rajouté d'autre est inutile et dangereux.

Certains ont pu voir mes tweets à propos de la release de mon nouveau payload, et beaucoup me demandent quelle est la différence entre mon payload et ce qui est déjà disponible.
PL3 ne supporte plus le syscall 36, pour plusieurs raisons; premièrement, c'était du mauvais code, il mappait un chemin vers une seule valeur "hardcodée" (/dev_bdvd ou /app_home ou /dev_flash ou quoi que ce soit qui est "hardcodé" dans le payload) ce qui signifie qu'étant donné que nous (les développeurs du PSGroove et PSFreedom) ne voulons pas supporter la lecture de backups, tous les payloads officiels ne fonctionnaient pas avec le backup manager sans être d'abord patchés. Le syscall 35 que j'ai ajouté dans mon payload est plus générique, c'est la manière correcte de faire les choses. Vous pouvez mapper n'importe quel chemin vers n'importe quel autre nouveau chemin, le prototype ressemble à ça :

Code: Tout sélectionner
syscall_35 (char *old_path, char *new_path);


Ça signifie que le payload ne nécessite pas d'avoir un chemin vers /dev_bdvd codé en dur, ou d'avoir du code supplémentaire pour mapper /app_home vers quelque chose d'autre.; ou d'avoir syscall qui change à la fois /dev_bdvd et /app_home, brisant les homebrews en utilisant un mode sans disque avec un backup manager. Vous n'avez pas besoin non plus d'un payload spécial pour faire tourner le "firmware usb loader"... Tout ça fonctionne juste parce que le choix du mapping du chemin est donné aux applications homebrew elles-même. Ca signifie que les les backups manager vont juste mapper /dev_bdvd vers ce qu'ils veulent et ils fonctionneront par défaut sur mon payload, il n'y aura pas besoin d'une version patchée du payload pour les faire fonctionner.
Ca signifie cependant que les backups managers qui dépendent du syscall 36 ne fonctionneront plus. Pour l'instant, Gaia Manager est le seul backup manager qui est compatible avec mon nouveau payload. Mais je suis sûr que d'autres seront portés pour utiliser le syscall 35.
Les gens ont besoin de comprendre que ce nouveau syscall 35 doit devenir le nouveau standard, c'est ce que tous les payloads devraient utiliser, rien d'autre, et c'est ce que tout le monde devrait utiliser, pas le vieux et foireux syscall 36, spécifique aux backup managers et écrit pour le PSJailbreak.
Nous avons besoin d'une forme de standardisation pour tous les payloads, je suis fatgué de voir une centaine de payloads différents transitant sur Internet, ça n'a pas de sesn. J'ai toujours cru en un seul payload qui fonctionne pour tout le monde, et c'est pourquoi j'ai créé PL3, c'est pourquoi c'est un projet indépendant du PSFreedom (et le PSGroove y a été porté) et c'est là que tous les efforts devraient tendre. De plus, en utilisant PL3, vous gagnerez automatiquement un support, et toutes les mêmes fonctions, pour n'importe quel firmware antérieur que le PL3 supporte déjà (3.01, 3.10, 3.15 et 3.41).

J'ai seulement vu récemment ce nouveau payload dont tout le monde est tellement heureux et qui inclut "toutes les bonnes choses des 3 mondes", celui créé par Rancid, et qui inclut des choses de Hermes, Waninkoko et Mathieulh... et j'ai été choqué de voir combien les gens étaient heureux de ça... Les gens ne semblent pas vraiment comprendre que ce n'était pas tout à fait nécessaire? PL3 a tous ces patches depuis un moment maintenant, alors pourquoi Rancid a-t-il même pris la peine de faire ce payload qui inclut les patches de Hermes, Waninkoko et Mathieulh? Pourquoi vouloir perdre votre temps à faire quelque chose qui est déjà disponible!

Ce blog post est fait pour cesser toute cette ignorance et que les gens sachent qu'ils n'ont pas besoin d'un payload spécial, utilisez simplement PL3 et vous aurez tout ce dont vous avez besoin. Il est aussi fait pour expliquer à tout le monde ce qui est différent à propos de mon payload.

A côté de ça, j'ai reçu un PS3Hub, qui m'a été gentiment donné par les gens de r4king.com, et j'ai maintenant essayé le PSGroove pour la première fois! J'ai aussi créé un fork du portage du PSGroove de jevinskie qui est maintenant amélioré et mis à jour afin de supporter la dernière version du PL3. Ca signifie que le payload PL3 est maintenant disponible pour tous, tant ceux qui utilisent le PSFreedom que ceux utilisant le PSGroove, il n'y a donc maintenant plus d'excuse pour ne pas l'utiliser ou se reposer sur des payloads mal écrit et développés par des gens qui savent à pein comment coder (ou, utiliser Winrar au lieu de Git est un bon signe de ça).

MAJ: j'ai oublié de râler sur le peek&poke!!! Alors allons-y... Eh bien, le payload par défaut du PL3 a le peek&poke désactivé, pour une simple raison: personne n'en a besoin! et, plus important, il est mal utilisé! J'ai regardé le code des différents backups manager, et il semble que tous utilisent le poke pour patcher la mémoire pour "réparer quelque chose" car ils pensent que c'est leur boulot de faire ça... Non, ça ne l'est pas! Si vous avez un patch qui fonctionne, soumettez-le à PL3 et si les gens se plaignent, dites-leur "utilisez le bon payload", n'essayez pas de prendre avantage du peek&poke pour modifier les instructions du kernel! La raison est simple... Vous êtes une application hombrew qui fait X, puis fait X, laissant le patchage du kernel aux payloads! Tout comme le PL3 ne mappe pas /dev_bdvd vers /dev_usb000/I.Like.This.Game/ et le bloque! Aussi, je suis en firmware 3.15, donc quand vous décidez de poker et patcher le kernel avec un offset codé en dur, vous foutez juste en l'air mon kernel car l'offset dépend du firware! Ce n'est pas le même en fonction du firmware que vous utilisez, et je ne veux pas que vous jouiez avec. Donc... peek&poke ne sont ps vraiment utiles pour qui que ce soit, ils ne sont même pas disponibles sur un PC normal sous Linux, pourquoi en voudriez-vous donc dans votre payload par défaut, d'accord?! Les seules personnes qui devraient utiliser un payload avec ces syscalls activés sont les vrais développeus, les gens qui veulent analyser et patcher le kernel à la volée pendant qu'ils font du vrai développement de, peut-être, un driver pour le kernel! C'est tout. De toute façon, j'ai assez râlé pour aujourd'hui!

PS: dans ma branche du PSGroove, j'ai écrit un script qui compile les fichiers .hex pour tous les périphériques supportés (selon le README) pour chaque firmware supporté. Vous trouvez tous les hex ici: PSGroove+PL3 hex files

MAJ: grâceà evilsperm, j'ai mis à jour l'archive avec les hex de ces périphériques: Blackcat, Xplain, Olimex, UsbTinyMkII, Bentio et OpenKubus.
MAJ 2: certaines personnes ont reporté des crashes avec mon payload quand ils faisaieht tourner des backups sur lesquels ils avaient installé des mises à jours. J'ai trouvé la cause et l'ai réparée sur le Git. Les hex ci-dessus ont également été mises à jour.

Merci de m'avoir lu.
KaKaRoTo