Chargement ELF et SELF
Le chargeur mappe les modules SELF PS5 déchiffrés et les modules ELF64 nus, applique les relocations, et résout les imports contre le registre HLE. Le titre reçoit ensuite des handles stables pour les modules qu'il démarre lui-même.
Notes du dépôt jusqu’au 10 octobre 2026
Images
Un exécutable PlayStation 5 est d'ordinaire un conteneur SELF autour d'une image ELF64. PS5PCEM lit le conteneur aussi bien qu'un ELF nu. Le lecteur collecte les imports, mappe les segments dans l'espace d'adressage invité réservé, et applique les relocations. Les images TLS sont enregistrées auprès des threads qui vont les exécuter.
L'outillage peut inspecter un module, vider un graphe de dépendances relogé, ou désassembler un shader sans démarrer le titre. game-run est le chemin qui charge, initialise HLE et entre dans l'invité. Lorsque l'eboot.bin déchiffré se trouve à l'écart de l'installation, --app0 pointe le montage en lecture seule vers le répertoire de contenu.
Modules que le titre démarre plus tard
Le runtime mappe le graphe de dépendances atteignable, plus tout ce qui est nommé dans PS5_PRELOAD, avant l'exécution du code invité. sceKernelLoadStartModule renvoie ensuite un handle stable pour un module de cet ensemble. Le charger de nouveau ne crée pas une seconde copie relogée. sceKernelDlsym hache le nom passé par le titre et ne cherche que dans le module sélectionné par le handle, de sorte que deux greffons qui exportent le même rappel ne s'aliasent pas.
La correspondance des chemins ignore le sens des barres obliques et la casse. Un titre observé demande Il2CppUserAssemblies.prx et livre Il2cppUserAssemblies.prx. Une correspondance exacte refuserait un fichier que le titre a installé. Le chemin relatif est essayé avant le nom de fichier nu, de sorte que deux modules qui partagent un nom de fichier restent distincts. Un module qui n'était pas dans l'ensemble publié renvoie ENOENT. Il n'est pas mappé pendant que des threads invités s'exécutent déjà.
Greffons Unity
Les greffons Unity peuvent être mappés avec leurs constructeurs différés. sceKernelLoadStartModule les démarre ensuite une seule fois, avec le vrai bloc d'arguments du titre, au lieu d'exécuter ces constructeurs pendant l'initialisation du graphe. Cet ordre fait la différence entre un greffon qui voit ses arguments et un greffon qui démarre trop tôt.
Le chargeur ne déchiffre pas un SELF de vente au détail. L'entrée est une image déchiffrée que l'utilisateur a le droit de charger. Les paquets chiffrés sont l'affaire de l'outil PKG, et le chiffrement de vente au détail est également en dehors de cet outil.
Ce qui est en place
- Mappage ELF64 et SELF déchiffré, relocations, imports et TLS.
- Un graphe de dépendances préchargé et des handles sceKernelLoadStartModule stables.
- Dlsym limité au module sélectionné, avec une correspondance de chemin insensible à la casse.
- Constructeurs différés pour les greffons Unity, afin qu'ils démarrent avec les vrais arguments.
Ce qui manque encore
- Un module qui n'apparaît qu'après le démarrage, et qui n'a pas été préchargé, renvoie ENOENT.
- Les images SELF de vente au détail chiffrées ne sont pas déchiffrées.
- Les builds d'inspection n'exécutent pas l'image chargée sur les hôtes autres que Windows.
Mécanismes liés
Ce que ces pages décrivent