Comment faire un HEN (Homebrew Enabled) sur PS Vita ?

Wololo très actif sur la scène PSP nous délivre une sorte de tutoriel pour savoir comment faire un HEN, un "activateur d'homebrew", pour ainsi faire un lanceur d'homebrew sur PS Vita.


Voici son article en anglais... Quelqu'un pourrait faire une traduction (sans utiliser de traducteur automatique ^^) :
Quote:
I believe everybody who visits this blog at least knows what a homebrew is, and knows that the only way to launch certain homebrews on his PSP is using a Homebrew Enabler (HEN). So, what exactly is a HEN? Most of you will probably answer “a homebrew that allows me to launch other homebrews”, correct, but how does it work exactly? It may look like black magic, but it’s not, in fact, most of the time spent coding a HEN is updating patches since big part of the mechanism is pretty much always the same. To understand better how a homebrew enabler works, we have to split it in three parts: the exploit, the payload, and systemctrl.

– Part 0 – Modules? –

To understand this, you first need to understand what a module is. A module is basically an executable. The PSP system is made by a lot of modules, each one of them accomplishes different tasks. A module can run in three different levels: user, vsh and kernel.

User level is the level of homebrews, it can’t do nothing special, just normal tasks. Vsh level (also known as updater mode) is the level of the VSH (you don’t say?), it is like user level, but has some “extra” permissions, it can load modules and reassign flashes for writing. Kernel level is the highest, it has no limits, a module running in kernel mode can do anything.

With HBL we can load homebrews that run only in user level, while a HEN allows you to run executables that require any permission level. All official modules are signed, you may know we can “sign” usermode homebrews (it’s a dirty trick, but works great, props to the guys who figured this out!), especially kernel modules, the system checks signatures of all executables, if one isn’t valid, the system will refuse to execute it. That’s exactly what a HEN does: modifies the system to make our executables look “valid” even if they’re not signed.

– Part 1 – The Exploit –

Let’s say you’re a hacker, you have found a kernel exploit (I assume you already know what a kernel exploit is, in case you don’t, I will give just a brief explanation: it’s a vulnerability in the PSP kernel that allows you to execute code with kernel permissions a.k.a. you can do whatever you want in the system) and you can run your own code (a homebrew), this is all you need to start working on a Homebrew Enabler.

The first thing a HEN does, is acquiring kernel permissions with the kernel exploit. Once you have kernel permissions you can write to kernel memory (the part of protected RAM where the “important stuff” is).

What exactly do we want to write to kernel memory and why? We want to write a few “patches” to loadexec. LoadExec a the part of the system responsible for many important tasks, like launching executables, it is also responsible of exiting an application. The process of exiting and executing an application is pretty simple:

LoadExec is told to execute/exit from an application
LoadExec loads in memory a raw binary executable called “reboot.bin” and jumps to it, leaving all the control to reboot (if it’s told to launch an application, it loads it in memory first)
reboot.bin parses a file called pspbtcnf, which contains a list of modules that need to be loaded
All the modules in the list are loaded, reboot gives control back to the system

– Part 2 – The Payload –

Why is this so important to us? Well, to keep our HEN alive in memory, we have to hack this simple process. After patching LoadExec in memory, this is what the process looks like:

LoadExec is told to execute/exit from an application
LoadExec loads in memory TWO raw binaries “reboot.bin” and “rebootex” (which is injected by us) and jumps to rebootex
Rebootex injects a module called “systemctrl” (the core of our HEN) in pspbtcnf, and patches reboot to allow loading of our unsigned module, then it jumps to reboot
reboot.bin parses pspbtcnf and loads all the modules, including our systemctrl, then gives control back to the system.

What is rebootex? Rebootex is our payload, nothing more than a raw binary that needs to accomplish two easy tasks: inject an entry in pspbtcnf that points to our systemctrl and patch the system in order to load systemctrl, even if it’s not signed.

– Part 3 – Systemctrl –

Systemctrl, finally, is the core of a Homebrew Enabler, it’s a module always running in kernel mode (as long as the HEN is loaded, of course) that does a lot of different things: takes care of the vshmenu, allows you to load plugins and many others, but most important: it patches the system.

More patches? Yes, more patches, systemctrl patches loadexec again to load rebootex (otherwise the HEN would be lost every time you launch an application), and other parts of the system to allow you to run unsigned code (homebrews and plugins) that otherwise wouldn’t be loaded, as I explained earlier.
Conclusion

Of course, this is just a general explanation of how a Homebrew Enabler works; this does not apply to every HEN, some developers may design it differently, but these are the core concepts of every enabler. I tried to keep this explanation as simple as possible for normal users, if you’re a dev, you may find some parts “too easy”, I know, but again, you’re not a normal user, aren’t you? ;) — Freddy

http://wololo.net/wagic/2012/05/28/how-does-a-homebrew-enabler-work/Source : http://wololo.net/wagic/2012/05/28/how-does-a-homebrew-enabler-work/

11 comments

31
mai

sa veut dire qu'on pourrait mettre un hombrew sans vhbl

31
mai

Portrait de Attila

"– Part 1 – The Exploit –

Let’s say you’re a hacker, you have found a kernel exploit "

si tu as un exploit oui ...

31
mai

Portrait de lienju53

c'est pas mal, faut il encore avoir un exploit et être un hacker ^^

24
juin

Voici la traduction de l'introduction:

Je crois que tous ceux qui visitent ce blog savent ce qu’est un homebrew, et savent que le seul chemin pour lancer certains homebrews sur sa psp est d’utiliser un homebrew loader (HEN). Mais qu’est –ce qu’un HEN ? La plupart d’entre vous répondront probablement « Un homebrew qui m’autorise à lancer d’autre homebrews » . C’est vrai, mais comment fonctionne-t-il exactement ? Cela peut ressembler à de la magie noir, mais ce n’en est pas. En réalité, la plupart du temps passé au codage d’un HEN est la mise à jour des correctifs, car le reste du mécanisme est à peu près toujours le même.
Pour mieux comprendre comment fonctionne un homebrew enabler, nous avons à le découper en trois parties : l’exploit, le payload [maintien en mémoire ?] et le systemctrl.

24
juin

Voici la traduction de la partie 0:

- Partie 0 : des modules ?
Pour comprendre cela, vous devez d’abord comprendre ce qu’est un module. Un module – d’un point de vue basique – est un exécutable. La psp est faite de plein d’exécutable. Chacun d’entre eux accomplissent différentes taches. Un module peut s’exécuter à trois niveau : au niveau user [ utilisateur ], vsh et noyau.
Le niveau user est le niveau des homebrews. Il ne fait rien de spécial [le niveau], juste les taches normales.
Le niveau vsh ( aussi connu comme étant le mode « mises à jours ») est le niveau du VSH. C’est comme le niveau user, mais il a quelque permissions en plus : il peut charger des module et réassigner la mémoire flash pour une réécriture [ comprendre : mise à jour des modules].
Le niveau noyau est le plus haut : il n’a pas de limite. Un module qui est exécuté en mode noyau peut tout faire.
Avec HBL, nous pouvons exécuter des homebrews qui fonctionnent seulement dans le niveau user., tandis qu’un HEN vous autorise à lancer des exécutables qui peuvent nécessiter n’importe quel niveau de permission. Tous les modules officiels sont signés. Vous savez peut-être que l’on peut signer des homebrews en mode user (c’est un sale tour, mais ça marche bien, c’est un accessoire pour celui qui l’a compris !). Les modules du noyau sont eux aussi signés. Le système va vérifier les signatures de tous les exécutables, et si certains ne sont pas valide, il refusera de les lancer. C’est exactement ce qu’un HEN fait, il modifie le système pour lui faire croire que nos exécutables sont valides, même s’ils ne sont pas signés.

24
juin

Voici la traduction de la partie 1:

- Partie 1 : l’exploit
Disons que vous êtes un hacker et que vous avez trouvé une faille au niveau du kernel ( je considère le fait que vous saviez déjà ce qu’est une faille kernel, dans le cas où vous ne le sauriez pas, je vais juste vous donner une brève explication : c’est une vulnérabilité dans le noyau de la PSP qui vous autorise à exécuter du code avec les permission noyau – aussi connu comme « Vous pouvez faire ce que vous voulez dans le système »- ) et vous pouvez lancer votre propre code ( un homebrew), c’est tous ce dont vous avez besoin pour travailler sur un HEN [Homebrew Enabler].
La première chose qu’un HEN fait, c’est d’obtenir la permission avec la faille du noyau. Une fois que l’on a les permissions noyau, on peut écrire dans la mémoire du noyau (la partie de la RAM où sont stockées les « choses importantes »).
Que veut-on écrire dans la mémoire du noyau et pourquoi ? On veut écrire quelques « correctifs » à loadexec. LoadExec est une part du système responsable des taches importantes, comme le lancement d’exécutables. LoadExec est aussi responsable des fin d’applications [ au sens de quitter une application]. Le processus de la fin d’application et de l’exécution d’application est assez simple :
On demande à LoadExec d’exécuter / de quitter une application
LoadExec charge dans sa mémoire un exécutable binaire nommé « reboot.bin » et va jusqu’à lui, lui laissant tous les pouvoir pour redémarrer (s’il est demandé de lancer une application, il la charge d’abord en mémoire). reboot.bin analyse un fichier appelé « pspbtcnf », qui contient une liste de modules qui ont besoin d’être chargés [ou exécutés]. Quand tous les modules de la listes sont chargés, reboot.bin redonne les pouvoir au système.

26
juin

Portrait de Attila

merci pour la traduction

27
juin

Voici la traduction de la partie 2:

-Partie 2 – Le chargement –
Pourquoi est-ce tellement important pour nous ? Eh bien, pour garder notre HEN vivant en mémoire [= rester chargé], nous devons hacker se simple processus. Après avoir patché LoadExec en mémoire, voici ce que devrait faire le processus :
On demande à LoadExec d’exécuter / de quitter une application
LoadExec charge en mémoire deux exécutables binaires nommés « reboot.bin » et « rebootex » (que nous avons injecté) et saute vers rebootex.
Rebootex injecte un module appelé « systemctrl » (le cœur de notre HEN) dans pspbtcnf, et patche le redémarrage pour autoriser [la console] à exécuter des modules non signés, puis il saute à « reboot ».
Reboot.bin analyse pspbtcnf et charge tous les modules, incluant notre systemctrl, qui rend les pouvoir au système.
Qu’est-ce que rebootex ? C’est notre playload, rien de plus qu’un fichier binaire qui doit accomplir de taches facile : injecter un entrée dans pspbtcnf qui pointe vers notre systemctrl et patcher le système dans le but de charger systemctrl, même s’il n’est pas signé.

27
juin

Voici la traduction de la partie 3:

-Partie 3 : Systemctrl
Systmctrl est le cœur de notre HEN. C’est un module qui s’exécute toujours en mode kernel [avec toutes les permissions](tant que le HEN est chargé, bien sûr) et qui fait beaucoup de choses différentes : il s’occupe du vshmenu, qui autorise le chargement des plugins et d’autre choses, mais le plus importants et qu’il patche le système.
Plus de patches ? Oui, plus de patches, systemctrl patche loadexec une nouvelle fois pour charger rebootex (s’il ne le faisait pas, le HEN serait perdu à chaque fois que l’on lancerait une application), et d’autres parties du system qui nous autorise à exécuter du code non signer (Hombrews et plugins) qui autrement ne pourrait être chargé, comme je l’ai expliqué plus tôt.

27
juin

Voici la traduction de la conclusion:

Conclusion :
Bien sûr, ceci n’est qu’une explication générale de comment fonctionne un Homebrew Loader ; ceci ne s’applique pas à tous les HEN, certains développeurs peuvent le concevoir différemment, mais c’est le cœur du concept de tons les enablers [activateurs, dans le sens de HEN]. J’ai essayé de garder cette explication aussi simple que possible pour les utilisateurs normaux, mais si vous êtes un développeur, vous avez peut-être trouvé quelques parties « trop faciles », je sais, mais encore une fois, vous n’êtes pas un utilisateur normal, n’est-ce pas ? ;) - Freddy

11
jui

Portrait de Attila

merci