Salut je voulais juste vous faire part d'une idée que j'ai pour la conception d'une puce pour la PSP.
L'analyse de l'architecture de la PSP montre que celle-ci est tres bien concu pour ce qui est de la gestion des DRM avec la possibilité d'ajouter dans chaque nouveau firmware un nouveau modèle d'authentification pour les jeux et programme executer.
Ainsi, la console effectue plusieurs opérations:
- au demarrage elle charge un boot chiffrer qui est , cf psp-hacks.com, verifier par le CPU a l'aide de fonction DRM intégrer à celui-ci;
- Elle loade ensuite les différents drivers en verifiant de ceux-ci sont signer ( voir chiffrer) , puis les decode et les execute en mémoire;
- C'est ensuite au tour des applications d'etre charger ( le dashboard, etc...) puis decoder avant execution suivant le meme processus de vérification;
Ce process est donc , d'un point de vu architecture , hyper carré voir inviolable.
La seule possibilité et de passer par un bug au niveau logiciel.
Une méthode baser sur la modification des binaires présent dans les dossiers flash0 et flash1 est donc tres fortement voué a l'echec.
L'analyse de l'architecture matériel montre également que SONY a fait un tres bon boulot au niveau de l'intégration des composants matériels:
- Ainsi le CPU intégre plusieurs unités, calcul, DRM, controleur mémoire, etc... au sein d'un seul composants;
- La mémoire vive ( la DDR mobile) ainsi que la mémoire flash sont intégrer au sein d"un seul composant MCP concu par SAMSUNG;
A mon sens il n'y a qu'une seule modification possible pour que l'on puisse disposer d'un loader pour les homebrews, et cette modification porte sur la conception d'un module ( un bridge) qui viendrait s'interfacer entre la carte mere et le MCP Samsung;
les PIN associés a la mémoire devront etre cabler vers un CPU externe ( un ARM par exemple) qui disposera d'un peu de mémoire interne ainsi que d'un peu de ROM pour pouvoir executer un programme simple. Ce composant devra etre cabler au port série du port casque et etre l'un de ces GPIO devra etre cabler sur l'un le switch hold et un autre sur l'un des boutons de la console.
Je m'explique:
- Vue que le processus de chargement et d'execution des programmes est "blinder" il faut attaquer le seul endroit ou le code est "en clair", a savoir la RAM;
- Il faut donc pouvoir ecrire dessus et à mon avis le seul moment possible est lorsque la console est en veille;
- Celle-ci doit , en toute logique, passer la RAM en self Refresh, desactiver les unités inutiles a savoir proc graphique, ecran , MS, etc.., et passer le CPU dans un mode base consommation ( du genre 1Mhz);
- Il doit donc etre possible a ce moment la d'utiliser un CPU externe pour ce connecter a la RAM.
Ce module externe devrait disposer des fonctions suivantes:
- pouvoir être mis a jour depuis une connection effectuer sur le port série de la prise casque;
- executer un code effectuant un parcours de la mémoire a la recherche d'un pattern identifier comme pointant sur le code verifiant les PBP;
- Modifier cette adresse afin de la faire pointer sur un segment externe;
- Ecrire un code dans un segment connu comme non affecter de la mémoire;
- puis se desactiver;
Ainsi le deroulement fonctionnel serait le suivant:
- On allume sa console;
- On attends le démarrage;
- On la passe en Hold, afin de patcher la mémoire;
- On la "dehold";
- On lance ces homebrew;
Il reste cependant une inconnu a savoir verifier si les echanges entre le CPU et la mémoire ne sont pas codé.
Il est fort probable que ce soit le cas mais je pense que le contenu de la mémoire est plutot scrambler, a savoir que les donnée ont subit des permutations, de facon cabler, plutot que crypter.
Il devrait donc logiquement être possible de trouver la méthode utilisé en faisant un dump mémoire depuis la console puis un parcours mémoire depuis le CPU bridgé.
Cela risque d'être nécessaire a plus ou moins long terme dans la mesure où SONY maitrise completement son processus de conception de mise à jour et que nous autre utilisateurs n'exploitont pour le moment que des trous oubilié pour pouvoir faire tourner ce que l'on veut.
Je tiens également à signaler que l'architecture de la console permet logiquement de d'interdir l'execution d'un jeu sur lequel un trou de sécurité aurait été trouvé et dont la signature et consigner dans son firmware , en proposant alors ( par exemple) au client de ramener son jeu chez son revendeur afin que celui-ci lui fournissent un exemplaire non buggé, voir en proposant de télécharger un PBP sur le net permettant d'executer le jeu depuis une MS.
Voila donc ce que je propose.
