Miles Prower

Avec PMS, ton film est envoyé compressé à la console. Le film n'est jamais compressé lorsqu'il est envoyé vers l'écran, l'écran ne fait aucun travail de décodage.

Triple boot ? Selon ta version de Win7, XP n'a probablement pas vraiment d'intérêt vu qu'il peut être virtualisé dans le système (et si tu ne le fais pas dans le système avec le « Mode XP », tu peux toujours installer VirtualBox et bricoler avec le mode Seamless - possible aussi de mette VirtualBox sur Ubuntu d'ailleurs). Sauf peut-être pour quelques jeux ? Dans le cas d'un multiboot, je conseille d'installer toujours Ubuntu en dernier - généralement, il va s'occuper très bien tout seul de détecter les autres systèmes disponibles et configurer GRUB directement. Du coup, la seule prise de tête est vraiment de déterminer comment partitionner le disque dur.

Je crois que la première personne qui trouve LA solution pour laisser une ouverture totale et illimitée au matériel (impliquant par exemple, la possibilité de charger des jeux PS3 depuis son disque dur interne sans avoir l'original dans le lecteur) et qui arrive à faire en sorte que personne n'en profite pour pirater risque de devenir riche, très riche…

De ce que je comprends, cette chose n'utilise pas la lecture à distance type PSP mais un boitier émetteur vidéo collé derrière la console (visiblement en SD composite, notez aussi le mauvais ratio d'écran sur le LCD) ?

Le NTFS est une propriété intellectuelle de Microsoft. Point. Oubliez le NTFS (encore), réclamez donc du EXT, du Reiser, du BTR, du Z, même du DECtape si vous voulez, mais oubliez le NTFS foutrebleu.

Oulah… Révise vite l'histoire des jeux vidéo, tu mélanges complètement tout là.

<_facku> now you have the exploit.. <_facku> you can r/w <_facku> modify lv1 calls.. <_facku> if you want. <_facku> . <_facku> dump hypervisor.. <_facku> search for a bug <_facku> you only need a pic <_facku> or microcontroller <_facku> and pulses the line down for 40ns.. <_facku> i dont think you will ned an FPGA for this

Non, l'accès est encore très loin d'être total, mais on est devant les portes d'entrée de la console. Ce qui est con, c'est qu'on a perdu la clé en route.

Réponse rapide : rien. Question rapide : mais que devient Lulu ?

Je sens que des cartes-mère vont souffrir dans les jours à venir.

geohot: well actually it's pretty simple geohot: i allocate a piece of memory geohot: using map_htab and write_htab, you can figure out the real address of the memory geohot: which is a big win, and something the hv shouldn't allow geohot: i fill the htab with tons of entries pointing to that piece of memory geohot: and since i allocated it, i can map it read/write geohot: then, i deallocate the memory geohot: all those entries are set to invalid geohot: well while it's setting entries invalid, i glitch the memory control bus geohot: the cache writeback misses the memory :) geohot: and i have entries allowing r/w to a piece of memory the hypervisor thinks is deallocated geohot: then i create a virtual segment with the htab overlapping that piece of memory i have geohot: write an entry into the virtual segment htab allowing r/w to the main segment htab geohot: switch to virtual segment geohot: write to main segment htab a r/w mapping of itself geohot: switch back geohot: PWNED geohot: and would work if memory were encrypted or had ECC geohot: the way i actually glitch the memory bus is really funny geohot: i have a button on my FPGA board geohot: that pulses low for 40ns geohot: i set up the htab with the tons of entries geohot: and spam press the button geohot: right after i send the deallocate call

On peut déjà le faire, techniquement. À condition de pousser Mesa3D à progresser.

Ç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.

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)

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.

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

Je viens de voir le topic. Comment dire… Le HDMI fait passer un signal de 10,2GBits/s ; si jamais tu trouves des boitiers CPL capables de ça (et pour "pas cher"), préviens-moi direct.

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.

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.

geohot est en 3.10

Très bonne traduction. ASM pour PPC. → sais

Est-ce qu'un processus en cours d'exécution te bouffe 100% du temps CPU ?

Perso, je ne crois plus à ce leak. J'avais lu un magnifique article, clair et bien détaillé, qui expliquait en termes compréhensibles pourquoi Sony bloquait sur l'émulation soft de la PS2 sur la PS3. Mais impossible de le retrouver En gros, le problème était là encore au niveau du RSX. Sony avait des sacrées bonnes idées sur la PS3, mais a sorti sa console trop tôt (car Microsoft était déjà présent sur le marché). On a donc le droit à une prématurée : le RSX est arrivé en cours de route et n'est pas à la hauteur du CELL, la console manque de RAM, etc. Le hardware est très bon, ceci dit, mais aurait pu être largement meilleur s'il n'était sorti qu'en 2008 plutôt que 2007 (et on n'aurait pas autant eu à attendre que les jeux arrivent après la sortie de la console : ça vaut aussi pour les annonces sur Gran Turismo 5).

L'article de PS3Gen est, euh, très fortement romancé. Le retrait de l'OtherOS n'est pas lié à cette potentiel faille trouvée par geohot. Sony avait juste l'impression que cette fonction ne servait à rien pour toucher le grand public - le but de la Slim était de reconquérir le marché ! - et donc qu'il était inutile de continuer à adapter cette fonction sur les nouvelles révisions hardware : ça aurait demandé du temps et de l'argent. Pas grand chose d'intéressant n'a été fait avec le OtherOS jusque là pour le grand public, mais y'a quand même eu pas mal de monde pour bidouiller dans leur coin avec. On n'a pas de distro bien userfriendly comme un XBMC standalone, par exemple. Mais il semble clair que Sony risque de ne pas aimer, et de restreindre encore davantage l'OtherOS des FAT - certains disent que Sony ne peut pas supprimer complètement l'OtherOS de ces consoles pour des raisons légales, mais je ne vois pas bien pourquoi personnellement. Dans le pire des cas, juste sur un point technique, on pourrait imaginer que Sony retire l'OtherOS de toutes les consoles dans une mise à jour. EDIT Pour ceux qui ont été refroidis par Linux sur PS3, c'est normal. C'est bâclé. Tentez Linux sur votre PC, vous verrez, c'est pas du tout la même chose. PC ≠ OS. PC ≠ Windows. D'ailleurs, Linux ≠ Windows (et ≠ Mac, ≠ Solaris, ≠ BSD, ≠ UNIX, ≠…). PC ↔ windows ↔ linux ↔ mac. Un iMac est un PC comme n'importe quel autre. (Je pensais qu'en 2010, c'était bon, on avait arrêté d'opposer "PC" et "Mac" là où il faudrait dire "Windows" et "MacOS". Dommage ).

Ce qui est déjà possible dans un OtherOS, en fait. Il faudrait surtout qu'on laisse tomber l'idée d'un tel hack et qu'une communauté plus sérieuse se forme autour des possibilités offertes par OtherOS - et non plus se contenter de faire tourner des versions PPC mal adaptées de Linux par ce biais. Un travail titanesque. Seul le noyau Linux est actuellement réellement optimisé pour le CELL. Le reste autour (le GNU/ dans GNU/linux) ne l'est pas. Les nombreuses distro disponibles pour OtherOS montrent la faisabilité de la chose : on sait démarrer un système complet, on sait exploiter les SPU (largement meilleurs que le RSX… Un jeu comme MGS4 ne repose pratiquement pas sur le RSX !) et on sait qu'il y a un accès limité à certaines fonctions du RSX pour simplifier quelques tâches (on ignore juste comment, et lesquelles). On sait que l'OtherOS peut récupérer des données du GameOS, comme la résolution d'écran, pour avoir une expérience fluide. On sait aussi synchroniser des DualShock3 dans Linux depuis même le démarrage du système (voir PDAxROM qui permet de naviguer dans le bootloader à la manette). On sait faire tourner du 1080p à haut débit dans MPlayer, grâce à une version retravaillée pour utiliser réellement le CELL et non pas juste son cœur PPE. On a déjà des émulateurs MAME, Megadrive, (S)NES, Saturn, Dreamcast, N64, PS2, etc. sous Linux, mais mal portés pour les architectures CELL (ou, pour la plupart, pas portés du tout, et même pas packagés correctement ou à jour pour la "bête et méchante" architecture x86). On a juste découvert que c'était pas simple. Qu'il fallait du temps. Et que les mecs qui sortent des jeux sur la console, effectivement, souffrent. Je partage donc complètement l'idée de Ouasse comme quoi il nous faudrait déjà un support de base OtherOS unifié, et reprendre du développement "propre" là-dessus. (Et je ne sais même pas coder) Maintenant, ce hack n'est pas inintéressant, mais pour d'autres raisons. Dont l'exploration du fonctionnement au réel de la console.