Idée D'architecture Pour Une "puce" Pour La Psp

[Canope]

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.

Modifié 8 octobre 2005 par Canope

[sangoku_dragon]

Et bien je crois que c'est claire non?

C'est bien ce que je pensais, comme Johnny citant aragon au lieu de platon : "tout ce que je sais c'est que je ne sais rien".

Non sans déconné, tu as bien expliqué le processus, mais une question me taraude: as tu étudié toi même le fonctionnement de la machine ou l'as tu lu quelque part ? parceque là c'est très complet et si tout ce que tu dis est vrai il n'y a plus qu'à passer à l'action, mais ne serait ce pas ça le plus dur ? Comme disait Morpheus il y a une différence entre connaitre le chemin et arpenter le chemin. En tout cas c'était pas mal.

Modifié 8 octobre 2005 par sangoku_dragon

[Canope]

Passer a l'action est justement le plus difficile à cause des points suivants:

- Il faut concevoir un module compatible avec de la mobile DDR;

- Il faut que quelqu'un ecrive un code , certainement en assembleur, qui puissent tenir dans la mémoire interne du CPU de la puce qui aura été retenu ( en clair au max 256k de ram et peut etre 80k de ROM) qui puissent gérer un port série , effectuer des opération su la mémoire de la PSP, et qui puissent ce mettre a jour;

- Il faut que le PCB de ce module soit nickel , il faut que chacune des liaisons qui relit le bridge au entrée du controleur mémoire du CPU de notre "puce" soit de meme longueur;

- Ces liaisons doivent également supporter des échanges a 166Mhz ( vitesse de la ram);

- Il faut également disposer d'une méthode simple pour déssouder le MCP, celui-ci est poser sur la carte mere et n'as pas de broche !!!;

- Il faut que ce module soit tres compact !!!, ce qui va etre difficile vue les éléments nécessaire....;

En clair, il faut qu'un industriel de la puce ce décide et tente le coup.

Il faut également s'attendre a ce que ce genre de puce soit tres chere et tres difficile a mettre en place.

Je vois donc le circuit comme suit:

- Un controleur mémoire mobile DDR;

- Un proc de type ARM;

- un bridge qui permette d'effectuer une dérivation avec un mécanisme de diode pour éviter que les informations envoyer par le proc de la puce ne soit renvoyer vers la PSP;

- certainement un composant de mémoire flash le loader ( qui gere le port série) ainsi que pour le prog de parcours et de patch de la DDR;

Tout cela n'est pas simple....

Et bien je crois que c'est claire non?

C'est bien ce que je pensais, comme Johnny citant aragon au lieu de platon : "tout ce que je sais c'est que je ne sais rien".

Non sans déconné, tu as bien expliqué le processus, mais une question me taraude: as tu étudié toi même le fonctionnement de la machine ou l'as tu lu quelque part ? parceque là c'est très complet et si tout ce que tu dis est vrai il n'y a plus qu'à passer à l'action, mais ne serait ce pas ça le plus dur ? Comme disait Morpheus il y a une différence entre connaitre le chemin et arpenter le chemin. En tout cas c'était pas mal.

530472[/snapback]

[InSomni4]

je peux rien avancé au problème , mais ça fais plaisir de lire des posts comme celui ci !(et surtout pas un post anglais !!)

avec des gens comme toi y a de forte chance que la scene fr reprenne du service ...

tchuss

[jiceher]

c'est très bien tout ça mais ça demande beaucoup de matos et de compétences, tu as une idée ou c'est justement le but de ton post : une bouteille à la mer ?

[Garbit]

Salut à toi,

- Il faut concevoir un module compatible avec de la mobile DDR;

A mon avis tu dois pouvoir trouver des "cartes de dev" (mini systèmes embarqués, ex la carte TS7200 qui peut tourner sous NetBSD) qui fonctionnent avec ça, donc en particulier les chips tout intégrés que proposent ces cartes de dev doivent etre compatibles.

- Il faut que quelqu'un ecrive un code , certainement en assembleur, qui puissent tenir dans la mémoire interne du CPU de la puce qui aura été retenu ( en clair au max 256k de ram et peut etre 80k de ROM) qui puissent gérer un port série , effectuer des opération su la mémoire de la PSP, et qui puissent ce mettre a jour;

Je pense que c'est faisable. Pour le port série, tu veux faire quoi ? si j'ai bien compris, il y a un port GPIO accessible de l'extérieur de la PSP ?

Au pire tu peux bricoler un peu les MMU de l'ARM et rajouter de la mémoire sur la puce, si tu es juste en mémoire.

- Il faut que le PCB de ce module soit nickel , il faut que chacune des liaisons qui relit le bridge au entrée du controleur mémoire du CPU de notre "puce" soit de meme longueur;

- Ces liaisons doivent également supporter des échanges a 166Mhz ( vitesse de la ram);

La c'est carrément du suicide...le moindre fil que tu va mettre va avoir une impédance terrible (ex : un fil de 1 µH va avoir une impédance complexe d'environ j*1 kohm). Pour peu que la résistance du circuit soit du même ordre de grandeur que l'impédance de l'inductance, ca va déphaser dans tous les sens... J'imagine que ça se fait mais il faut faire du travail de pro (avec du matériel de pro donc)

- Il faut également disposer d'une méthode simple pour déssouder le MCP, celui-ci est poser sur la carte mere et n'as pas de broche !!!;

C'est du BGA, non ? (article sur Wikipédia

The shorter an electrical conductor, the lower its inductance, a property which causes unwanted distortion of signals in high-speed electronic circuits. BGAs, with their very short distance between the package and the PCB, have low inductances and therefore have far superior electrical performance to leaded devices.

BGAs find some use in security-sensitive applications, especially where it is impossible to prevent physical access to the chip. For instance, a ROM chip with a BGA configuration is considerably more difficult to access than one in a DIP or TSOP layout. Tracing circuit paths to the BGA chip is limited by the contact points being obscured by the chip itself.

Bref, ...

En tous cas, ca peut se déssouder avec un "fluide de soudure à phase vapeur", qui quand il chauffe, se condense sur les soudures et les fait fondre (c'est comme ça que ce genre de composants est soudé). Problème : ça coute cher, et ça n'est pas vendu aux particuliers.

- Il faut que ce module soit tres compact !!!, ce qui va etre difficile vue les éléments nécessaire....;

Tu veux dire, pour pouvoir être un truc commercialisable ? ça a mon avis ça viendra plus tard

En tout cas bravo pour ton taf, bon courage pour trouver des partenaires. Essaies peut être de contacter les "grosses" team de hack, ça marchera peut être.

++