Geohot : je peux faire ce que je veux sur le système PS3

[titus360]

geohot est en 3.10

ok tu sais beaucoup de choses toi a bon il joue aux derniers jeux aussi ? quel risque)

Tu tombes bien, Comment tu affirmes ça et aussi que pcsx2 tourne mieu sous windows.!?

EDITE: xD tikilou tu manques de rien ici !!

Modifié 26 janvier 2010 par titus360

[Miles Prower]

geohot ne joue pas. Il n'a a priori qu'un jeu dans sa collection et pas intéressé.

La "faille RSX", qui n'est pas vraiment une faille, est connue depuis longtemps et déjà bouchée. De plus, elle ne peut pas servir à faire tomber l'hyperviseur.

PCSX2 :

Windows

Linux

Teste, tu comprendras vite. Y'en a un qui démarre des jeux commerciaux et les exécute en pleine vitesse, l'autre ne peut même pas booter le bios de la console.

Modifié 26 janvier 2010 par Miles Prower

[tikilou]

PCSX2 :

Windows

Linux

Teste, tu comprendras vite. Y'en a un qui démarre des jeux commerciaux et les exécute en pleine vitesse sous condition d'avoir du très bon matos, l'autre ne peut même pas booter le bios de la console.

Fixed

En passant Miles, pour la version GNU/Linux, ça ne m'étonne pas... Vu l'état des drivers de cartes graphiques sous nux...

Sans déconner, c'est un comble, en dehors des drivers Nvidia, y'a rien qui poutre, même les drivers Intel sont corrects, sans plus (et offrent de moins bonnes performances que sous Win...), quand à ceux d'ATI... Certes avec le temps, le cru s'améliore, comme un bon vin, mais faut pas être pressé de déguster, surtout avec les cartes récentes...

La frustration va me pousser à acheter du Nvidia le jour ou je me ferais ma config...

[titus360]

geohot ne joue pas. Il n'a a priori qu'un jeu dans sa collection et pas intéressé.

La "faille RSX", qui n'est pas vraiment une faille, est connue depuis longtemps et déjà bouchée. De plus, elle ne peut pas servir à faire tomber l'hyperviseur.

PCSX2 :

Windows

Linux

Teste, tu comprendras vite. Y'en a un qui démarre des jeux commerciaux et les exécute en pleine vitesse, l'autre ne peut même pas booter le bios de la console.

Pour pcsx2 pcsx, il me semblait voir le contraire y'a pas mal de temps. La j'ai bien vu que la version de windows avait rejoint celle de linux. ouais bon, cpas le sujet. ok.

Le rsx était surement une faille si elle a été bouché ! L'hyperviseur doit pas très bien réagir en 3.10.... surtout quand on veux balancer un .elf. Non, il est a jour et il surpasse tous les petits humains.

trop fort

[AhLoliloLhA]

En même temps télécharger un film, une chanson, enregistrer un film à la télé , tous ceux-çi peut-être fait de façon légal!

[SnowLeopard]

Et dire qu'un gars me proposait de m'acheter ma ps3 fat blanche à 400euros, j'ai bien fait de lui dire que j'y réfléchirais, m'enfin c'est surtout que je joue beaucoup en ce moment à la 360, moi je peut pas réfléchir et jouer en même temps

ralala c'est fou ce que l'importance de la ps3 a pris comme envolé depuis ce hack, et les constructeurs s'entêtent encore à croire que hack = backup de jeux.

Quand on voit ce que les gens veulent vraiment avec la ps3, ils auraient vraiment dû penser autrement, sans faire de la ps3 un mini fort knox.

merci à geohot, lui n'a pas eu besoin de réclamer des dons pour palier a des brick de ps3, il a juste beaucoup plus de talent que nous tous

[Shakin]

Salut,

Bah tiens, tu me fais penser.

Vous vous réjouissez tous de que ça soit 95% soft, mais attention aux bricks !

@+

[ryaku]

Update

A Level Playing Field

Right now, I'm playing with the isolated SPEs, trying to get metldr to load from OtherOS. Interesting thing, I am not using the exploit. I always assumed the enable isolation mode register was hypervisor privileged. It's not, it's kernel privileged, which means using hypervisor calls you can all get to it. So, get to hacking. Here is the code I am playing with.

I'm not that opposed to releasing the exploit, but I think the majority of you are going to be disappointed, even if you do get it working. Unless you have pushed the HV to it's limits, this exploit really isn't going to do much for you...yet. So install OtherOS and start playing around. If people start coming up with convincing reasons why they need the exploit to go further, I'll release it. It's just a waste to release if people can't make use of it.

As far as the GPU goes, I have full access to the GPU memory space 0x2800... But without a driver, it's useless. 3D video card drivers are notoriously hard to write, look at the ATI and NVIDIA ones for linux. The best are still the closed source manufacturer ones. I'm not even sure I believe that the HV restricts video card access, just that the OtherOS driver is 2D. If someone skilled in video card driver development comes forward, and they can explain in detail what the HV is restricting, I'll send them the exploit.

And something has to be done about the comments. Theres a couple of good ones, mixed in with tons of trash. Please, if you don't have something technical and useful to say, don't say it. This is not the place for congratulations(go back to the hello hypervisor post), debates about piracy(go somewhere else, the internet is big), or trying to convince me to do X.

Source : Blog Geohot ps3

Et apparemment SKFU a la dent dur contre Geohot

Altough it's nice to capture all these HV calls and stuff from a plain (not encrypted) lv1 binary, but this will never lead to a hacked PS3.

Let's have a look.

The major security architecture on the PS3 is called the "Secure Processing Vault" and is the most important thing regarding "hacking" the PS3.

There is NO WAY for the PPU or even the HV to gain access to the SPU, which is an application running inside of an isolated SPU.

Well you can kick out the isolated SPU, like geohot mentioned, but this gives you nothing, as ALL the encryption and execution of applications (HDD encryption, app encryption, decryption, executing, signature checking, root key extraction) happens inside the isolated SPU.

To run homebrew on the PS3 you would have to reassemble the whole functionality from the SPU inside a binary running on the PPU.

For this you will need the root key. The root key is stored in hardware (not even close to the things on the iPhone). The root key cannot be extracted by any software or hardware means and is essential to ALL encryption/decryption, executing and checking routines.

The only way to get the root key is inside of an isolated SPU, as it is kick-starting the hardware encryption facility. There is no other way to do that !

Let's just assume that geohot or some other guys are able to break into the local store of the isolated SPE. There they will just find some encrypted binaries.

The key for decryption is encrypted by the root key !

You won't get anywhere without the root key.

Let's assume that someone managed to do all those stuff from the isolated SPU on the PPU and creates a CFW.

There is still a secure booting environment. The first module loaded/bootet is integrity checked by the hardware crypto facility utilizing the root key. So you have also to address this booting stuff. Again, no root key, no booting.

So there's always runtime patching you might ask ? Not possible on the PS3 because the hardware crypto facility is able to check the signatures whenever it wants to. And which part is responsible for this ? Exactly, the isolated SPU.

So if you kick out the isolated SPU the system will not boot/run anymore.

The PS3 is neither an PSP nor an iPhone. It's the most secure system architecture of this time !

The girl behind this stuff, Kanna Shimizu, is not somebody. Messing around with this is not like saying Bruce Schneier is a n00b.

Btw.: forget about all those stories, that certain hackers are or will be employed by SONY. That's nothing more than another urban legend.

@geohot It is OBVIOUS that the HV is PPC. The Cell BE is a PPC architecture, you know ;-) Better read those IBM papers in first place

Source : Blog SKFU

Modifié 26 janvier 2010 par ryaku

[kozeck]

En effet, Kanna Shimizu, ce n'est pas n'importe qui :

Kanna Shimizu

AUSTIN, TX US

1. 20090089579 Secure Policy Differentiation by Secure Kernel Design 04-02-2009

2. 20090086974 Support for Multiple Security Policies on a Unified Authentication Architecture 04-02-2009

3. 20080301469 Cryptographically-enabled Privileged Mode Execution 12-04-2008

4. 20080301468 Cryptographic Secure Program Overlays - method computer program product and data processing system for executing larger-than-physical-memory 12-04-2008

5. 20080301440 Updateable Secure Kernel Extensions - method, computer program product, and data processing system for providing an updateable encrypted operating 12-04-2008

6. 20080298581 Application-Specific Secret Generation - method, computer program product, and data processing system for protecting sensitive program code and data 12-04-2008

7. 20080244612 METHOD, SYSTEM, AND COMPUTER PROGRAM PRODUCT FOR INVOKING EXTERNALLY ASSISTED CALLS FROM AN ISOLATED ENVIRONMENT 10-02-2008

Je trouve quand même SKFU un peu dur (j'ai dit jaloux ???) avec GeoHot...

Modifié 26 janvier 2010 par kozeck

[Stan.lee]

J'ai confiance a Geohot, apparemment les système coriace c'est sont terrain de jeu, et il ne lâchera pas l'affaire le bougre, il a déjà entre-ouvert une petite porte

Les critiques on s'en br..le, il y en aura toujours quoiqu'on fasses.

Ce qu'il a fait et déjà une prouesse, par le passer aussi...

Geohot ou autre doivent et vont la craqué cette satanée PS3, c'est une guerre contre la Capitalisme ( métaphore ).

Vive la Liberté, Vive Gueux ( bon je m'emporte, OK je sort ).

Modifié 26 janvier 2010 par Stan.lee

[toys3d]

. I'm not even sure I believe that the HV restricts video card access, just that the OtherOS driver is 2D.

il n'y va pas un peu fort là? il suffirait d'ajouter une partie 3D au driver et bcp de choses seraient possibles

j'espère que qqn va se proposer pour programmer.

ca me semble bizarre quand même.

Modifié 26 janvier 2010 par toys3d

[Miles Prower]

Il a raison, puisque Linux utilise bel et bien des drivers graphiques sous sa forme actuelle. En 2D, oui. Ce sont juste les drivers MESA (si je ne me plante pas), ce qui correspond à un rendu… logiciel. Le calcul graphique n'est pas fait sur le RSX mais sur le CELL, et en particulier le PPE puisque jusqu'ici personne n'a tenté de porter VESA vers les SPU (et l'architecture de Vesa est telle que cela ne suffira probablement pas à avoir de la 3D. Quoique, je m'avance sans doute trop, tout dépend de comment les SPUs seront utilisés pour cette tâche).

Les explications de SKFU sont également très bonnes, je pense. La PS3 utilise un système de cryptographie assez démentiel. J'en suis plutôt admiratif, là. J'ai l'impression en lisant ça que tout a été réfléchi dès la conception sans erreurs, et que le système est suffisamment tordu pour ne pas se laisser maltraiter comme ça - en gros, une faille "simple" ne sera jamais suffisante car la console s'en protégera elle-même par son design. Peut-être qu'en trouvant plusieurs angles d'attaque ?

En tout cas, si geohot (ou un autre) arrive à mettre la main sur cette clé root, bingo.

Mais bon. L'OtherOS dans sa forme actuelle n'a pas montré le tiers du quart de ses possibilités. Il y a un travail titanesque à faire dessus, encore une fois, mais le CELL et le reste du système ont énormément de punch encore à l'heure actuelle. Je me demande d'où en sont les gars de XBMC à ce niveau, c'est peut-être encore eux qui ont le projet le plus réaliste.

Modifié 26 janvier 2010 par Miles Prower

[sushy18]

je suis " un peu " d'accord avec SKFU

En même temps c'est vrai que plus le temps passe plus j'ai l'impression qu'il a crié "J'ai hacké la PS3 " un peu tôt...

Pour ceux qui suivent un peu les echanges sur le Chan PS3dev me corrigerons si necessaire , mais bcp de choses qu'il decrit comme des decouverte etaient déja

utilisés par d'autres pointures. ( Utilisation de DECHA, utilisation F@h, modification de Self,... )

que les choses soient bien clair, s'il l'on me donnait tout le matos qu'as Geohot chez lui je ne saurais toujours pas quoi et où chercher pourfaire faire avancer le hack PS3 ;-)

( au passage c'est de vrais extraterrestres sur le chan PS3dev... ils parlent plus ou moins tous le Lv0, Lv1,Lv2 et HV couramment )

ça n'enleve rien aux qualités de GH ... et je reste quand même persuadé qu'il a reussit...enfin j'espere.

au pire il aura mis un grand coup de pied dans la fourmiliere.... c'est ce que je me dit

[toys3d]

miles, ce que j'ai compris c'est qu'il dit qu'il n'est pas certain que l'hyperviseur bloque l'accès au RSX ....juste que l'other OS n'a qu'un driver qui fait 2d uniquement

Un driver approprié et hop...RSX!

il existe des drivers mesa pour nvidia http://tldp.org/HOWTO/Nvidia-OpenGL-Configuration/x134.html

Modifié 26 janvier 2010 par toys3d

[ouasse]

SKFU, une fois de plus tente de se rendre intéressant en disant n'importe quoi.

Certes on sait qu'un SPU est en mode isolé, et est chargé d'effectuer tout ce qui est décryptage d'exécutables. SKFU prétend donc qu'il est impossible de lancer un exécutable sans ce SPU. Mais à partir du moment où on a pris le contrôle du système, rien à cirer de lancer des exécutables cryptés ! On charge le code non crypté et on l'exécute, point barre.

[sushy18]

SKFU, une fois de plus tente de se rendre intéressant en disant n'importe quoi.

Certes on sait qu'un SPU est en mode isolé, et est chargé d'effectuer tout ce qui est décryptage d'exécutables. SKFU prétend donc qu'il est impossible de lancer un exécutable sans ce SPU. Mais à partir du moment où on a pris le contrôle du système, rien à cirer de lancer des exécutables cryptés ! On charge le code non crypté et on l'exécute, point barre.

... les prochains jours donneront raison a l'un ou l'autre... mais c'est pas completement con ce que dit SKFU... (sans root key, qui au passage est stocké en hard )

Modifié 26 janvier 2010 par sushy18

[Miles Prower]

Je n'ai rien d'autre à proposer que la réponse rapide de Mathieul, je n'y comprends plus rien pour ma part.

<Mathieulh> well Ouasse is right except that he is forgetting the part in where he is gonna get the decrypted code in the first place

[ryaku]

ce qui veut dire ?

[Miles Prower]

miles, ce que j'ai compris c'est qu'il dit qu'il n'est pas certain que l'hyperviseur bloque l'accès au RSX ....juste que l'other OS n'a qu'un driver qui fait 2d uniquement

Un driver approprié et hop...RSX!

il existe des drivers mesa pour nvidia http://tldp.org/HOWTO/Nvidia-OpenGL-Configuration/x134.html

Oui, c'est ce que je dis : c'est le driver VESA qui est en cours. On pourrait faire tourner MESA3D, qui est également un driver software MAIS avec les extensions OpenGL 3D (qui sont souvent utilisées également pour des rendus 2D dans les interfaces, XBMC en tire profit pour quelques effets je crois par exemple). On reste sur le CELL tout ce temps. L'idéal serait donc de se concentrer sur le développement de MESA3D pour que celui-ci

1. fonctionne correctement

2. fonctionne correctement sur PPC

3. tire profit des SPUs du CELL (pas de tous : laissons-en pour les autres logiciels) ! Sinon, ça sera incroyablement lent.

En gros, faut réinventer la roue. Et il s'agit bien d'un driver software. Mais avec ça, théoriquement, toutes les applications 3D fonctionneront immédiatement (sans forcément être assez optimisées pour être utilisables… ce n'est que la première partie du boulot).

Il y en a pour quelques années de développement, l'équipe qui planche sur ce type de projet ne compte pas grand monde car ce projet n'est pas assez fédérateur…

Et le RSX reste bien non-accessible, il EST bloqué, geohot se plante sur ce point à mon avis (c'est d'abord une politique de Sony, pour obliger les développeurs à souscrire à leurs procédures de développement et publication de jeux sur le PSN. Si le RSX était laissé libre, n'importe quel développeur pourrait envoyer Sony bouler et décider de créer un LiveCD Linux démarrant directement son jeu… il n'aurait alors pas à payer de royalties pour utiliser le système !)

Comme vu sur le blog de Séphi, on a eu accès pendant un moment au RSX dont certaines parties étaient laissées volontairement accessibles. Dès que Sony s'est rendu compte que l'accès limité était déjà suffisant pour lancer quelques trucs, et que ça devenait simple à faire pour le "grand public" (après tout, c'est juste un .deb pour l'installation des drivers), ils l'ont bloqué complètement.

Imagine si jamais les gens pouvaient lancer UltraStar sans soucis sous Linux et que c'était userfriendly… Hop, Singstar coule.

Modifié 26 janvier 2010 par Miles Prower

[sushy18]

Je n'ai rien d'autre à proposer que la réponse rapide de Mathieul, je n'y comprends plus rien pour ma part.

<Mathieulh> well Ouasse is right except that he is forgetting the part in where he is gonna get the decrypted code in the first place

Traduction:

"Bon, Ouasse a raison , excepté qu'il oublie la partie où il doit obtenir le code décrypté dans un premier temps."

[ryaku]

Donc pour faire clair et afin que tout le monde comprenne entre les avancées de Geohot et le poste de Skfu,

Il semblerait que Skfu n'ait pas tout à fait tord dans le forme mais sur le fond Geohot peut quand même aller plus loin si il arrive a decrypter le fonctionnement de la machine etant donné qu'il a accès au systeme ?

[Miles Prower]

Pas "obtenir" pour moi, puisque de toutes façons, ce code, c'est à nous de l'écrire. Je le comprends comme : on ne sait pas vraiment où le placer pour l'exécuter (les accès actuels sur la console ne sont pas suffisants ? J'en sais rien).

EDIT → Il faut que le code transite par le SPU isolé avant d'être lancé par le PPE apparemment, ça fait partie de la chaine de sécurité de la console. Donc, si on garde ce SPU hors jeu, impossible de lancer du code sans que la console ne se coupe dès que le système lance d'autre check. Si on tente de récupérer ce SPU, on se retrouve avec de nouveau tout le système de sécurité qui empêchera le code non-signé de se lancer. Si on veut utiliser le PPE pour lancer directement le code, il faut simuler le passage par un SPU sur celui-ci (en l'émulant) ce qui n'est possible que si on commencer par dumper le code de ce SPU, ce qui est impossible sans clé.

C'est en tout cas ce que je comprends de l'affaire depuis le blog de SKFU.

Dans mes essais sur Mesa3D, j'en étais resté ici :

Pas terrible. Tout bleu sur la 3D, et 30 fois trop lent par rapport au minimum de performances attendues.

Il faut donner un coup de boost au développement sous OtherOS, pas chercher un hack. Oubliez les isoloaders, concentrez-vous sur la partie media - XBMC est accessible sur la console à condition d'en faire les longs et chiants efforts !

C'est déjà compliqué de convaincre les gens que Linux EST réel et utile, alors pour le reste (dev sur PPC), je pense que ça risque d'être quasi mission impossible là.

(cherchez pas, moi, je sais pas coder)

Modifié 26 janvier 2010 par Miles Prower

[Arkeur]

"GeoHot: Je peux faire ce que je veux..." (avec mes cheveux )

OK je sors, mais il a quand meme une touffe énorme le gars

++

Arkeur

[toys3d]

130fps pour 30 polygones sans texture diffuse, Normalmap, ni éclairage HDRI.,etc...

on ne vas pas aller loin

il me semble que Ouasse est un bon programmeur.

il me semble que j'avais lu qu'il travaillait sur un moteur 3d qui calculait par le cell:

ah oui c'est mieux 200000tri en 60fps mais pas de texture ni de shadow map

si qqn peut t'aider en prog c'ets bien ouasse

Modifié 26 janvier 2010 par toys3d

[Miles Prower]

Ça tombe bien, personnellement je ne suis pas allé plus loin

Mais des travaux comme les démos de ouasse montrent que ce n'est pas qu'une théorie, y'a ce qu'il faut dans le système pour avoir un bon rendu 3D en software sur la console. Les

aussi (je crois que c'était IBM, ça - raytracing en temps réel). Et même des logiciels existants, comme Blender, capable de s'exécuter de façon fluide sous PS3/Linux en montrant des scènes 3D en software. Modifié 26 janvier 2010 par Miles Prower