Logic-Sunrise : actualités, téléchargements, releases, dossiers et tutoriaux

C'est aujourd'hui que nous apprenons que Popsdeco Extracter passe en version V2. Popsdeco Extracter est un homebrew initialement créé par Xennon et mis à jour par Popsdeco. Il permet de mettre en place les fichiers nécessaires pour faire fonctionner le PopsLoader. Cette application permet de récupérer tous les fichiers nécessaires pour les firmwares 3.00 au 6.60. Pour rappel, le Popsloader permet de faire fonctionner les jeux Playstation 1 sur la console portable.

Installation :

- Copiez le dossier Popsdeco rev2 dans PSP/GAME.

- Téléchargez les firmwares que vous voulez décrypter ;

- Récupérez l'eboot de ces derniers (PSP/GAME/UPDATE/eboot.pbp) ;

- Renommez ces derniers de la façon suivante : xxx.pbp, xxx faisant référence au numéro du firmware écrit sans le point (le firmware 6.20 donnera ainsi 620.pbp, le 4.01 donnera 401.pbp, etc.)

 - Placez ces eboots à la racine de votre memory stick ;

- Veillez à toujours avoir l'eboot du firmware 4.01.

- Lancez Popsdeco Extracter V2

On apprend aujourd’hui via le site EliteModScene, que les développeurs Cancerous et JQE viennent de releaser le premier et tant attendu lecteur vidéo pour la Xbox 360. Ce media player est basé sur les librairies publiés par Ced2911 ainsi que la librairie SDL de lantus.

Les développeurs précisent que la majorité des vidéos se lance en 720p mais que le 1080p reste instable (de toute façon avec la limites des 4Go ce n'est pas très grave), et que le lecteur vidéo intègre un menu permettant de faire pause avance rapide etc ... Les fonctions "avance rapide" et "retour rapide" peuvent néanmoins se montrer instable, cela fera l'objet d'une mise à jour future.

###########################################################

 Welcome to our release of FFPlay. From Cancerous and JQE

 This is using FFmpeg libraries as ported by Ced2911 This is using SDL as ported by Lantus

 This should play allmost all 720p videos. 1080p IS UNSTABLE please don't report it we know about i.

 ###########################################################

 INFO FOR DEVS:

 ##############################################################

 We added launchdata. This means that any app can launch this with a few parameters and play a video.

 The parameters are

 struct LaunchInfo {

 char filename260; char callingapp260;

 };

 here is an example of how to use it.

 LaunchInfo data = (LaunchInfo)malloc(sizeof(LaunchInfo)); memset(data-]filename, 0, MAX_PATH); memcpy(data-]filename, file.c_str(), strlen(file.c_str())); memset(data-]callingapp, 0, MAX_PATH); string expath = getExecutablePath(); memcpy(data-]callingapp, expath.c_str(), strlen(expath.c_str())); XSetLaunchData((PVOID)data, sizeof(LaunchInfo)); XLaunchNewImage("game:\\vid\\default.xex", 0);

 CallingApp is the app you are running, use this to return to the app after launch. filename is the name of the file you want to play.

 INFO FOR USERS:

 ##############################################################3

 A brings up a menu, rewind, Fast Forward, Stop, Play, Pause.

 NOTE: Fast Forward, and Rewind might be unstable. It is know and we are working on it.

 NOW we have our people to thank.

 cOz helped with some coding and solved a issue with running it on JTAGS

 Thanks to testers: Blackwolf, JPizzle, Mattie, Razkar, and Trajik.

 Thanks for direction and assistance: MaesterRo, Anthony, And node21

BestPig, notre codeur national, revient sur la scène 360 pour nous livrer une nouvelle application qui fait suite à la mise en ligne d'un nouveau Hack . Ce soft permettra aux personnes allergiques aux lignes de commandes ou n'ayant pas envie d'installer Python de créer vos images ECC facilement et ceci dans l'interface soigné qui a rendu sa précédente application célèbre.

Son fonctionnement est assez simple : vous choisissez votre modèle de carte mère, le lieu où vous souhaitez que l'image soit créée et sélectionnez votre nand d'origine.

Comme son précedent soft, il intrègre la langue anglaise et suédoise.

Cancerous, [cOz], Ced2911,GliGli, RedLine99 et Tuxuser sont très heureux de vous livrer aujourd'hui la première version officielle du XeLL-Reloaded (nom de code XeLL2Stage) suite à la release du Reset Glitch Hack de GliGli. Pour rappel XeLL, le Xenon Linux Loader est le bootloader des consoles hackées (Jtag, Reset Glitch Hack) et il permet le lancement de linux et des homebrews libXenon (le SDK alternatif à celui de MS). Voici une liste non exhaustive des modifications et correctifs apportés :

? Division en deux niveaux

- Le premier stage initialise le Hardware, décompresse et exécute le 2nd niveau (2nd stage)

- Le second (basé sur libXenon) charge les drivers requis et les "tâches du XeLL".

? XeLL est maintenant basé sur Libxenon

? XeLL fonctionne avec tous les CPU cores activés

? Optimisation de l'utilisation du CPU.

? TinyEHCI est utilisé permettant le support du USB2.0

? La gestion du réseau lwip a été mise à jour avec la version V1.4RC2 pour un gain en rapidité

? Support de l'accès au lecteur DVD via DMA, la lecture est plus rapide.

? Possibilité de recharger XeLL lorsque vous êtes dans une application libXenon

? Réécriture du code pour le lancement des ELF, il ne devrait plus y avoir de problème avec XellLaunch dorénavant.

? Nouveau design pour l'interface Web (voir screen en dessous)

? Meilleurs initialisation/arrêt du hardware avec XeLL Launch

? Possibilité de mettre à jour le 2nd niveau du XeLL avec une clé USB et un fichier nommé "updxell.bin"

? Chaine de boot redondante pour les ELF à exécuter.

? Lecture/décryptage du KV avec la clé CPU.

Seul bémol, pour l'instant le Nand Flasher n'est pas 100% opérationnel et n'est donc pas intégré, ceci fera l'objet d'une mise à jour dans les semaines à venir.

Pour les utilisateurs de consoles JTAG souhaitant mettre à jour leur bootloader, vous pouvez utiliser XeLL Updater de Tuxuser.

The french developer and hacker, GliGli, is proud to release via XboxHacker forums, what most of us are waiting for since more than one year : a new exploit for the Xbox 360. This new Hack is called "Reset Glitch Hack" and needs the installation of a chip. The Reset Glitch Hack is compatible with most 360 models: all the Xbox Slims models and for FAT, Zephyr and Jasper are working for now (Falcon will be released when the devs will have one at hand).

To explain it (very) simply, the chip sends little pulses to the processor in order to distabilize the console and make it believe a modified CB is correctly hashed and signed. This operation doesn't succeed every time, but it is repeated till it works. Once the modified/hacked CB is validated by the console, it has enough rights to launch unsigned code and in our case, XeLL, the Xenon Linux Loader. For full details, read GliGli's explanation of his hack, you can also have a look at the source code of Hack available HERE.

Advantages of this Hack :

- All the 360 expect the Xenons will be compatible.

- It's unpatchable, in fact the CB is involved so early in the console boot process that it can't be revoked

Drawbacks:

- A chip is needed.

- The boot time varies and it can take up to a few minutes to run unsigned code.

Here is the full explanation of the Hack by GliGli :

***************************************
* The Xbox 360 reset glitch hack *
***************************************

Introduction / some important facts
===================================

tmbinc said it himself, software based approaches of running unsigned code on the 360 mostly don't work, it was designed to be secure from a software point of view.

The processor starts running code from ROM (1bl) , which then starts loading a RSA signed and RC4 crypted piece of code from NAND (CB).

CB then initialises the processor security engine, its task will be to do real time encryption and hash check of physical DRAM memory. From what we found, it's using AES128 for crypto and strong (Toeplitz ?) hashing. The crypto is different each boot because it is seeded at least from:
  - A hash of the entire fuseset.
  - The timebase counter value.
  - A truly random value that comes from the hardware random number generator the processor embeds. on fats, that RNG could be electronically deactivated, but there's a check for "apparent randomness" (merely a count of 1 bits) in CB, it just waits for a seemingly proper random number.

CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it.

Basically, CD will load a base kernel from NAND, patch it and run it.

That kernel contains a small privileged piece of code (hypervisor), when the console runs, this is the only code that would have enough rights to run unsigned code.
In kernel versions 4532/4548, a critical flaw in it appeared, and all known 360 hacks needed to run one of those kernels and exploit that flaw to run unsigned code.
On current 360s, CD contains a hash of those 2 kernels and will stop the boot process if you try to load them.
The hypervisor is a relatively small piece of code to check for flaws and apparently no newer ones has any flaws that could allow running unsigned code.

On the other hand, tmbinc said the 360 wasn't designed to withstand certain hardware attacks such as the timing attack and "glitching".

Glitching here is basically the process of triggering processor bugs by electronical means.

This is the way we used to be able to run unsigned code.

The reset glitch in a few words
=======================

We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences". memcmp is often used to check the next bootloader SHA hash against a stored one, allowing it to run if they are the same. So we can put a bootloader that would fail hash check in NAND, glitch the previous one and that bootloader will run, allowing almost any code to run.

Details for the fat hack
=================

On fats, the bootloader we glitch is CB, so we can run the CD we want.

cjak found that by asserting the CPU_PLL_BYPASS signal, the CPU clock is slowed down a lot, there's a test point on the motherboard that's a fraction of CPU speed, it's 200Mhz when the dash runs, 66.6Mhz when the console boots, and 520Khz when that signal is asserted.

So it goes like that:
 - We assert CPU_PLL_BYPASS around POST code 36 (hex).
 - We wait for POST 39 start (POST 39 is the memcmp between stored hash and image hash), and start a counter.
 - When that counter has reached a precise value (it's often around 62% of entire POST 39 length), we send a 100ns pulse on CPU_RESET.
 - We wait some time and then we deassert CPU_PLL_BYPASS.
 - The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error AD, the boot process continues and CB runs our custom CD.

The NAND contains a zero-paired CB, our payload in a custom CD, and a modified SMC image.
A glitch being unreliable by nature, we use a modified SMC image that reboots infinitely (ie stock images reboot 5 times and then go RROD) until the console has booted properly.
In most cases, the glitch succeeds in less than 30 seconds from power on that way.

Details for the slim hack
==================

The bootloader we glitch is CB_A, so we can run the CB_B we want.

On slims, we weren't able to find a motherboard track for CPU_PLL_BYPASS.
Our first idea was to remove the 27Mhz master 360 crystal and generate our own clock instead but it was a difficult modification and it didn't yield good results.
We then looked for other ways to slow the CPU clock down and found that the HANA chip had configurable PLL registers for the 100Mhz clock that feeds CPU and GPU differential pairs.
Apparently those registers are written by the SMC through an I2C bus.
I2C bus can be freely accessed, it's even available on a header (J2C3).
So the HANA chip will now become our weapon of choice to slow the CPU down (sorry tmbinc, you can't always be right, it isn't boring and it does sit on an interesting bus

So it goes like that:
 - We send an i2c command to the HANA to slow down the CPU at POST code D8 .
 - We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
 - When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
 - We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
 - The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.

When CB_B starts, DRAM isn't initialised so we chose to only apply a few patches to it so that it can run any CD, the patches are:
 - Always activate zero-paired mode, so that we can use a modified SMC image.
 - Don't decrypt CD, instead expect a plaintext CD in NAND.
 - Don't stop the boot process if CD hash isn't good.

CB_B is RC4 crypted, the key comes from the CPU key, so how do we patch CB_B without knowing the CPU key?
RC4 is basically:
  crypted = plaintext xor pseudo-random-keystream
So if we know plaintext and crypted, we can get the keystream, and with the keystream, we can encrypt our own code. It goes like that:
  guessed-pseudo-random-keystream = crypted xor plaintext
  new-crypted = guessed-pseudo-random-keystream xor plaintext-patch
You could think there's a chicken and egg problem, how did we get plaintext in the first place?
Easy: we had plaintext CBs from fat consoles, and we thought the first few bytes of code would be the same as the new CB_B, so we could encrypt a tiny piece of code to dump the CPU key and decrypt CB_B!

The NAND contains CB_A, a patched CB_B, our payload in a custom plaintext CD, and a modified SMC image.
The SMC image is modified to have infinite reboot, and to prevent it from periodically sending I2C commands while we send ours.

Now, maybe you haven't realised yet, but CB_A contains no checks on revocation fuses, so it's an unpatchable hack !

Caveats
======

Nothing is ever perfect, so there are a few caveats to that hack:
 - Even in the glitch we found is pretty reliable (25% success rate per try on average), it can take up to a few minutes to boot to unsigned code.
 - That success rate seems to depend on something like the hash of the modified bootloader we want to run (CD for fats and CB_B for slims).
 - It requires precise and fast hardware to be able to send the reset pulse.

Our current implementation
=====================

We used a Xilinx CoolRunner II CPLD (xc2c64a) board, because it's fast, precise, updatable, cheap and can work with 2 different voltage levels at the same time.
We use the 48Mhz standby clock from the 360 for the glitch counter. For the slim hack, the counter even runs at 96Mhz (incremented on rising and falling edges of clock)
The cpld code is written in VHDL.
We need it to be aware of the current POST code, our first implementations used the whole 8 bits POST port for this, but we are now able to detect the changes of only 1 POST bit, making wiring easier.

Conclusion
========

We tried not to include any MS copyrighted code in the released hack tools.
The purpose of this hack is to run Xell and other free software, I (GliGli) did NOT do it to promote piracy or anything related, I just want to be able to do whatever I want with the hardware I bought, including running my own native code on it.

Credits
=====

GliGli, Tiros: Reverse engineering and hack development.
cOz: Reverse engineering, beta testing.
Razkar, tuxuser: beta testing.
cjak, Redline99, SeventhSon, tmbinc, anyone I forgot... : Prior reverse engineering and/or hacking work on the 360.

This Hack as explaned by the author was not done to promote piracy or anything related, but only to launch free/open source code (libXenon homebrew, linux etc...).

We would appreciate if you could respect author's works and will, so if you don't feel concerned by this hack please be on your way. This kind of messages "it's useless", "backup launch needed" will be removed and your account banned.

Thanks for your understanding

FIND OUR FULL SLIM TUTORIAL HERE

Update :

FAT Tutorial available

  FIND OUR FULL FAT TUTORIAL HERE

Useful links :

- http://gligli360.blogspot.com/

- http://libxenon.org/
- http://sourceforge.n...rojects/free60/
- http://free60.git.so...itweb-index.cgi
- http://www.free60.org/Main_Page

Le développeur et hacker français, GliGli, est fier de vous livrer aujourd'hui, via les forums Xbox-Hacker.org, ce que la majorité des fans de homebrews attendait depuis plus d'un an : un nouvel exploit sur Xbox 360. Cet exploit baptisé "Reset Glitch Hack" nécessite l'installation d'une puce et est compatible avec tous les modèles Slims et certaines FAT : Zephyr et Jasper (le support des carte mère Falcon viendra ultérieurement lorsque l'auteur en aura une sous la main).

Pour faire (très) simple, la puce envoi une série d'impulsions électriques au processeur, afin de déstabiliser la console et lui faire croire qu'un CB modifié est authentique (correctement hashé et signé). Cette opération ne réussit pas à chaque fois, mais elle se répète jusqu’à son succès. Une fois que le CB modifié/hacké est validé par la console, il possède les droits suffisants pour lancer du code non signé, dans notre cas XeLL, le Xenon Linux Loader. Si vous voulez plus de détails, vous pouvez lire l'explication de l'auteur ci-dessous et voir les sources du hack disponible ICI.

Les avantages de ce Hack :

? Toutes les consoles seront compatibles sauf les Xenons

? Il n'est pas patchable, en effet le CB intervient tellement tôt dans le processus de boot de la console qu'il ne peut être révoqué.

Ses Inconvénients:

? Nécessite l'installation d'une puce.

? Le temps de boot est variable et peut aller jusqu'a 2-3 minutes.

Voici l'explication complète du Hack par GliGli et traduit par nos soins :

***************************************
* The Xbox 360 reset glitch hack *
***************************************

Introduction / quelque faits importants
=============================

Tmbinc l'a dit lui même, les approches logicielles pour lancer du code non signé sur la 360 ne marchent pas dans la plupart des cas, elle a conçue pour être sûre d'un point de vue logiciel.

Le processeur commence par lancer du code à partir de la ROM (1bl), qui ensuite charge du code signé en RSA et crypté en RC4 à partir de la NAND (CB).

Le CB initialise ensuite le moteur de sécurité du processeur, sa tâche sera d'encrypter et vérifier le hash de la mémoire physique DRAM en temps réel. De ce que nous avons trouvé, il utilise l'AES128 pour le cryptage et un hachage (Toeplitz?) robuste. Le cryptage est différent à chaque démarrage, car il dépends d'au moins :
- Un hash du fuseset entier
- La valeur du compteur de temps du CPU (timebase)
- Une valeur totalement aléatoire générée par une partie hardware dédiée du processeur. Sur les FAT, ce RNG peut être électriquement désactivé, mais il y a une vérification sur "l'apparence aléatoire" (un comptage des bits à 1 en fait) dans le CB, il attends jusqu'à avoir ce qui lui semble être une valeur aléatoire correcte.

Le CB peut ensuite lancer un moteur logiciel basé sur une sorte de "bytecode" simple qui aura pour tâche d'initialiser la DRAM, le CB peut alors charger le bootloader suivant (CD) depuis la NAND, et le lancer.

Pour faire simple, le CD chargera alors un kernel à partir de la NAND, le patchera et le lancera.

Ce kernel contient une petite partie de code privilégiée (hyperviseur), quand la console tourne, c'est le seul code qui aura assez de droits pour lancer du code non signé.

Dans les kernels 4532/4548, une faille critique est apparue, et tous les hack 360 connus nécessitent d'utiliser un de ces kernels et d'exploiter cette faille pour lancer du code non signé.

Sur les 360s actuelles, le CD contient un hash de ces 2 kernels et arrêtera le processus de boot si vous essayez de charger l'un d'eux.

L'hyperviseur est une relativement petite partie de code à vérifier pour trouver une faille et apparemment aucune nouvelle version n'en contiens qui pourraient autoriser le lancement de code non signé.

D'un autre coté, Tmbinc a dit que la 360 n'avait pas été conçue pour résister à certaines attaques hardware tel que le timing attack et le "glitching".

Le Glitching ici est essentiellement l'action de cibler certains bugs processeur de manière électronique.

C'est la manière que nous avons utilisée pour pouvoir lancer du code non signé.

Le glitch du reset en quelques mots
===========================

Nous avons découvert qu'en envoyant de petites impulsions de reset au processeur pendant qu'il était ralenti ne le remettait pas à zéro, mais changeait plutôt la manière dont le code tournait. Il semble que ceci soit très efficace pour que les fonctions comparatrices de mémoires des bootloaders renvoient toujours l'information "pas de différence". Les fonctions comparatrices de mémoires sont utilisées entre-autres pour comparer le hash SHA du bootloader suivant avec celui stocké, et permettant s'ils sont identiques de le lancer. Nous pouvons ainsi mettre un bootloader qui ne passera pas la vérification de hash dans la NAND, glitcher le précédent et ce bootloader se lancera permettant le lancement de presque tout code.

Détails pour le hack des fats
=====================

Sur les FAT, le bootloader que nous faisons glitcher est le CB, afin de pouvoir lancer le CD que nous voulons.

Cjak a découvert qu'en activant le signal CPU_PLL_BYPASS, l'horloge du CPU ralentissait beaucoup, il y a un point de test sur la carte mère qui est une fraction de la vitesse du CPU, il est a 200Mhz lorsque le Dashboard est lancé, 66.6Mhz lorsque la console démarre et 520Khz lorsque le signal est activé.

Nous procédons donc de cette manière:
 - Nous activons CPU_PLL_BYPASS autour du code POST 36 (hex).
 - Nous attendons que le POST 39 démarre (le POST 39 est le comparateur de mémoire entre le hash stocké et le hash de l'image), et démarrons un compteur.
 - Lorsque le compteur atteint une valeur précise (c'est souvent autour de 62% de la longueur totale du POST 39), nous envoyons une pulsation de 100ns sur le CPU_RESET.
 - Nous attendons un moment et ensuite nous désactivons CPU_PLL_BYPASS.
 - La vitesse du CPU redevient normale, et avec un peu de chance, à la place d'obtenir une erreur POST AD, le processus de boot se poursuit et le CB lance notre CD modifié.

La NAND contient un CB "zero-paired", notre payload dans un CD modifié et une image SMC modifiée également.
Un glitch n'est, par nature, pas fiable, nous utilisons une image SMC modifiée qui reboot infiniment (en comparaison l'image d'origine redémarre 5 fois et ensuite la console est RROD) jusqu'à ce que la console aie démarrée correctement.
Dans la majorité des cas, la console boot en moins de 30 secondes après le démarrage.

Détails pour le hack des slims
======================

Le bootloader que nous faisons glitcher est le CB_A, de cette manière nous pouvons lancer le CB_B que nous voulons.

Sur les slims, nous n'avons pas été capables de trouver une piste sur la carte mère pour CPU_PLL_BYPASS.
Notre première idée a été de retirer le cristal 27Mhz maître et générer notre propre horloge à la place, mais il s'agissait d'une modification complexe, et qui n'a pas donné de résultats probants.
Nous avons ensuite regardé sur d'autres moyens de ralentir l'horloge du CPU et nous avons découvert que la puce HANA possède des registres PLL configurables pour l'horloge 100Mhz fournissant les paires différentielles CPU et GPU.
Apparemment ces registres sont écrits par le SMC au travers du bus I2C.
Le bus I2C est accessible librement, il est même accessible depuis un header (J2C3).
Ainsi la puce HANA devient notre arme de choix pour ralentir le CPU (désolé tmbinc, tu ne peux pas toujours avoir raison, elle n'est pas ennuyeuse et il s'agit bien d'un bus intéressant

Nous procédons donc de cette manière :
 - Nous envoyons une commande i2c vers l'HANA afin de ralentir le CPU au code POST D8 .
 - Nous attendons que le POST DA démarre (POST DA est le comparateur de mémoire entre le hash stocké et le hash de l'image), et nous démarrons un compteur.
 - Lorsque le compteur atteint une valeur précise, nous envoyons une pulsation de 20ns sur le CPU_RESET.
 - Nous attendons un moment et ensuite nous envoyons une commande i2c en direction de l'HANA afin que l'horloge du CPU revienne à son état normal.
 - La vitesse du CPU redevient normal, et avec un peu de chance, à la place d'obtenir une erreur POST F2, le processus de boot se poursuit et le CB_A lance notre CB_B modifié.

Lorsque le CB_B démarre, la DRAM n'est pas initialisée, nous avons donc décidé de n'appliquer que les patchs suivants pour qu'il puisse lancer n'importe quel CD :
 - Activation permanente du mode "zero-paired" afin de pouvoir utiliser une image SMC modifiée.
 - Non-décryptage du CD, et attente d'un CD en clair dans la NAND.
 - Pas d'arrêt du processus de boot si le hash CD n'est pas correct.

Le CB_B est crypté en RC4, la clé provient de la clé CPU, alors comment patcher le CB_B sans connaitre la clé CPU?
Le cryptage RC4 c'est en gros:
  crypté = texte-clair xor flux-de-clé-pseudo-aléatoire
  Ainsi si nous connaissons le texte clair et crypté, nous pouvons connaitre le flux de clés, et avec lui, nous pouvons encrypter notre propre code. Cela fonctionne ainsi :
flux-de-clé-pseudo-aléatoire-supposé = crypté xor texte-clair
nouvelle-encryption = flux-de-clé-pseudo-aléatoire-supposé xor patch-texte-clair
Vous pouvez penser qu'il s'agit d'un problème du style de l'oeuf et la poule, c'est à dire comment obtient-on le texte clair en premier lieu?
Facile: nous connaissons le texte en clair des CB provenant des consoles FAT, et nous avons supposé que les premiers bytes du code seraient les même que le nouveau CB_B, nous avons ainsi pu encrypter une petite partie de code pour dumper la clé CPU et décrypter le CB_B!

La NAND contient le CB_A, un CB_B patché, notre payload dans un CD en clair (non crypté) modifié, et une image SMC modifiée.
L'image SMC est modifiée pour avoir un nombre de reboot infini, et pour l'empêcher d'émettre périodiquement de commandes I2C pendant que nous envoyons les nôtres.

Vous n'avez peut-être pas encore réalisé, mais le CB_A ne contient pas de vérification sur les EFUSEs de révocation, ce hack est donc non patchable.

Bémols
======

Rien n'est parfait, il y a donc quelques bémols sur ce hack :
 - Même si le Glitch trouvé est plutôt fiable (Taux de réussite de 25% par essai en moyenne), il se peut que la console prenne quelques minutes pour lancer du code non signé.
 - Ce taux de succès est lié au hash du bootloader modifié que nous souhaitons lancer (CD pour les FAT et CB_B pour les slims).
 - Il requiert un matériel rapide et précis permettant d'envoyer la pulsation de reset.

Notre intégration actuelle
===================

Nous utilisons un CPLD Xilinx CoolRunner II (xc2c64a), parce qu'il est rapide, précis, reprogrammable, pas cher et fonctionne avec deux niveaux de tension différents en même temps.
Nous utilisons l'horloge standby 48Mhz de la 360 pour le compteur du glitch. Pour le hack Slim, le compteur tourne même à 96Mhz (incrémenté sur les fronts montants et descendants de l'horloge)
Le code du CPLD est écrit en VHDL.
Nous avons besoin de connaître le code POST actuel, notre première mise en application utilisait l'intégralité des 8 bits du port POST à cet usage, mais nous sommes maintenant capables de détecter les changements d'un seul bit du POST rendant le montage plus simple.

Conclusion
========

Nous avons essayé de ne pas inclure de MS copyrighté dans le pack de hack diffusé.
Le but de ce hack est de lancer XeLL et d'autres logiciels libres, je (GliGli) NE promeus EN AUCUN CAS le piratage ni quoi que soit qui s'en rapproche, je veux juste avoir la possibilité de faire ce que je veux avec le matériel que j'achète, y compris lancer mon propre code natif dessus.

Crédits
=====

GliGli, Tiros: Reverse engineering et développement du hack
cOz: Reverse engineering, beta test.
Razkar, tuxuser: beta test.
Cjak, Redline99, SeventhSon, tmbinc, tous ceux que j'ai oubliés... : Précédent reverse engineering et/ou du travail de hack sur la 360.

Ce hack, comme l'a expliqué l'auteur n'a pas vocation à promouvoir le piratage, qui n'est d’ailleurs pas possible actuellement puisqu'il ne permet que le lancement de XeLL, lui même offrant la possibilité de lancer du code libre comme les  homebrews libXenon, Linux etc ....

Nous vous serons gré de bien vouloir respecter le travail et la volonté de l'auteur, si vous ne vous sentez pas concerné par ce hack, merci de passer votre chemin. Les messages du style "ça sert à rien", "vivement le lancement des backups" seront supprimés et votre compte placé en prévisualisation, voire banni.

Merci de votre compréhension.

RETROUVEZ NOTRE TUTORIEL COMPLET POUR LES SLIM ICI

*MAJ*

Ajout du tuto pour les consoles FAT

RETROUVEZ NOTRE TUTORIEL COMPLET POUR LES FAT ICI

Liens utiles :

? http://gligli360.blogspot.com/

? http://libxenon.org/
? http://sourceforge.n...rojects/free60/
? http://free60.git.so...itweb-index.cgi
? http://www.free60.org/Main_Page

Souvenez-vous, il y a de cela quelques mois déjà, un exploit permettant de charger n'importe quel homebrew grâce a un jeu DSIWare nommé Sudoku avait vu le jour. Malheureusement, Nintendo avais vite réagi et avait retiré le jeu quelques heures seulement après. Aujourd'hui, ce n'est pas un nouvel exploit, mais trois nouveaux exploits. Il s'agit de Guitar Rock Tour, Legends of Exidia ainsi que Fieldrunners. Tous les trois sont disponibles pour les versions EUR/AU ainsi qu’USA tandis que pour la région JAP, seul l'exploit du jeu Legends of Exidia est disponible.

- Guitar Rock Tour (Grtpwn)  :

Après le lancement de Guitar Rock Tour, descendez et allez dans High-Scores-> Drums-> Easy. Puis l'exploit se lance et charge le fichier boot.nds

- Legends of Exidia (Exidiahax) :

Après avoir appuyé sur le bouton A ou commencé , sélectionnez la première sauvegarde et appuyez sur continuer.  Puis l'exploit se lance et charge le fichier boot.nds

- Fieldrunners (Fieldrunhax) :

Toucher le bouton «scores» dans le menu principal, boot.nds sera alors chargé.

Frostegater, auteur du Patch permanent pour le 6.20TN-E, ainsi que du support du CXMB pour Firmware 6.60 entre autres, nous propose aujourd'hui une nouvelle application destinée aux CFW & LCFW PRO.  XMB Control permet d'avoir les fonctions présentes sur le Recovery Menu sur le XMB et d'autres fonctionnalités. Malheureusement, cette application est incompatible avec le plugin Game categories light 1.4 et si vous n'arrivez pas à l'installer sur le Firmware 6.60, il faudra installer SensMe Channel.

Changelog :

- Fixed translate XMB Control in PSPgo.

- Added "Use usbversion.txt from ../seplugins/" item in "Configuration" menu.

- xx_prosettings.txt reading from seplugins/xmbcontrol if this folder exists.

**MAJ29/08/2011** : par Yoann-95

Changelog : XMB Control V1.2

- Fixed crashing on PSPgo (ME).

- Added ME Freecore xmbctrl

- Visual fixes.

**MAJ05/09/2011** : par Yoann-95

Changelog : XMB Control V1.3

- Added "OSK Limit Increase" function.

- Fixed xmbctrl ME translate path (ef(ms)0:/seplugins/xmbcontrol/xx_mesettings.txt). "ms0:/" priority.

- Added custom translate "On" "Off" context in "Plugins" menu.

- Added firmware version and MAC address spoof functions.

- Fixed ME&PRO compatibility in second config.

- Added custom translate "On" "Off" context.

- Compressing PRX`s.

- Fixed bug if you use more than 18 plug-ins in 6.20 (80108302 error).

- Fixed IBID. You can use plugin in 6.60 without SensMe™.

**MAJ26/09/2011** : par Yoann-95

Changelog : XMB Control V1.4.1

[ME] Fixed compatibility with 6.39 ME (spoofer).

[PRO] Fixed text patching.

[ME] Fixed spoof text reading.

[PRO] Fixed problem in select "Hide UMD Update" item.

[ALL] Added support special symbols in built-in translates.

[ALL] Added built-in translates: Russian.

[ALL] Fixed freezing if you select other language.

[ALL] Fixed bugs in translate items: "Slim Colors" (all), "Use ISO Cache".

[ME] Added "Use UMD-Video Patch" option on PSPgo.

[ALL] Increased number characters in translate (one line) = 64.

[ALL] Added Extended OSK plugin function.

[ALL] Fixed bug in last icon in "Settings" bar on PSPgo.

[ALL] Integrate "System settings" ("Standart" context item).

[PRO] Uncompressed plug-in, because of bug in procfw.

[ME] Remaked "Game Folder Homebrew" => "Flash Protect".

[ME] Blocked MAC spoof in PSP-1000.

**MAJ10/10/2011** : par Yoann-95

Changelog : XMB Control V1.4.2

- Ajout de l'option 199/99 dans l'horloge CPU.

Peu de temps après la sortie du CFW PS3ULTIMATE, RazorX est de retour pour nous faire part de son projet, le PS3 Ultimate store. Actuellement disponible via votre PC ou votre PS3, ce store se présente comme un store alternatif au Playstation Store, malgré sa forte ressemblance. Si cela vous intéresse, vous pouvez même apporter une pierre à l'édifice en lui donnant un petit coup de pouce car RazorX a besoin d'aide. Il aimerait créer un pkg pour son projet.

Bien sûr, toutes les recommandations au sujet du contenu de ce store sont les bienvenues donc n’hésitez pas à lui en faire part. Actuellement, vous pouvez y trouver par exemple quelque jeux psn, paintown ou encore multiman etc... Mais aussi des thèmes, un accès à une shoutbox ou au forum et bien d'autres encore.

Hi all, I am here to unveil my new site to you all, for the PS3. It is still in the early stages, but I think it is ready for release. I hope you all like it and appreciate the work I have put in on it, and I really hope with help, I can make or have someone make, this into an application, to make it easier and better to use with a built in pkg installer. Also, any help or ideas towards content just let me know. I think the site still could do with some improving. I made this on my own in my spare time, so dont be cruel, lol.

Anyway here it is! Enjoy...

Traduction : Dr. Charlatan

Salut à tous, je suis ici pour vous dévoiler mon nouveau site pour la PS3. Il est encore en cours de développement, mais je pense qu'il est prêt à sortir. J'espère que vous apprécierez le travail que j'ai fait, et j'espère vraiment avec de l'aide, de faire de ce store un store accessible directement sur le XMB sous forme de PKG. Toutes idées ou aides venant de votre part sont les bienvenues.  Je pense que le site aura toujours besoin d'améliorations... J'ai fait cela durant mon temps libre, donc ne soyez pas cruels, lol.

Quoi qu'il en soit c'est ici ! Profitez ...

La Team PRO, créatrice des Light Custom Firmware et Custom Firmware pour PSP en 6.XX (6.60/6.39/6.20/6.35), nous propose une nouvelle version du POPSLoader qui passe en version 3.0. Dans celle-ci, on y retrouve le support des Firmwares 6.60 de la Team PRO et de Neur0n (ME) ainsi que la correction de certains bugs. Pour rappel, ce célèbre plugin permet de jongler entre les différentes versions des émulateurs PSX officiels Sony pour PSP, alias Playstation One Portable Station, ou POPS (chaque firmware officiel contient un pops qui lui est propre).

Et si les jeux vendus sur le PSN sont pris en charge par les derniers pops sans soucis, cela s'avère très utile, voire même indispensable pour jouer à des jeux PSX dumpés dans un format adapté à la PSP car les derniers pops ne permettent pas forcement de jouer aux mêmes dumps que leurs prédécesseurs.

Changelog :

- Ajout du support du CFW PRO 6.60
- Ajout du support des fichiers POPS 6.60
- Correction de certains bugs

Tantric et rodries nous proposent une nouvelle version de leur fameux WiiMC (Wii Media Center), le lecteur multimédia (Audio, Vidéo, Image) de votre Wii. Il est en français et en open source. Vous trouverez dans l'archive la nouvelle chaîne, l'update et l'installer (utile seulement) si c'est la première fois que vous installez Wiimc. En plus de nombreuses améliorations, de nouvelles fonctionnalités ont été ajoutées. On peut dorénavant reprendre la lecture d'un fichier là où elle a été arrêtée.

Fonctionnalités :

- Possibilité de jouer une vidéo ou une musique.

- Lancer des DVDs.

- Voir des photos.

- Support media online.

- Support des SD, USB 2.0, SMB, HTTP, et FTP.

- Interface soignée basée sur libwiigui.g

Changelog : WiiMC V1.1.9

- Synchronisé avec MPlayer r34002.

- Nouveau code pour YouTube  (thanks jhb50!).

- Correction d'un problème avec certain sous-titres ne s'affichant pas.

- Ajout du support des sous-titres via FTP.

- Ajout du support de la mise en paquet dans le protocole HTTP.

- Ajout du langage Bulgare.

- Correction de problèmes divers.

**MAJ05/09/2011** : par Yoann-95

Changelog : WiiMC V1.2.0

- Synchronisé avec MPlayer r34053 et libav 5938e0218543

- Détection de l'ID de lecteur DVD ajustée

Aujourd'hui, BitsBubba propose une nouvelle version de son custom firmWare, le CFW Newbie Friendly Ware 3.55 V3. Il intègre déjà depuis un moment le patch Cinavia et lr patch Kmeaw (voir la news) mais dans cette nouvelle version, il intègre en plus le dongle USB "cobra" (support des jeux PS1/PS2, ...).

Attention: Le cobra USB est requis pour l'utilisation de jeux PS1/PS2 et bien sûr, tous les modèles de PS3 ne sont pas compatibles avec les jeux PS2, cela ne concerne que les PS3 rétro-compatibles.

Installation :

- Avoir un disque amovible usb en FAT32

- Créer un dossier PS3 à la racine de la clé (respecter les majuscules)

- Créer un dossier UPDATE dans le dossier PS3 (respecter les majuscules)

- Placer le PS3UPDAT.pup dans le dossier UPDATE

- Installer via le XMB.

Changelog: