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

Avec la sortie du nouveau firmware 1.52 pour la PS Vita, tout le monde se demandait si, avec cette mise à jour, Sony avait bloqué les exploits découverts jusqu'à présent sur sa nouvelle console portable. Eh bien c'est via le blog de SKFU que ce dernier vient de nous annoncer que ce n'est pas le cas. Le célèbre hackeur a pu tester la version de HBL en cours de développement et il a confirmé qu'elle est toujours fonctionnelle. Donc pour ceux qui ont une PS Vita entre les mains : pas de souci, vous pouvez mettre à jour vos consoles.

SKFU a aussi mentionné le fait que Sony a la possibilité de bloquer les exploits avec une mise a jour silencieuse qui peut-être intégrée à une application. Aussi, il est conseillé de rester sur ses gardes. Et pour terminer, je vous laisse avec les paroles de SKFU :

Ok guys we tested the possibilities on firmware 1.52 for a few days now. What I can confirm is the following:

 Tech4's exploit still works
 Wololo's HBL still works
 everything I research atm didn't change from 1.50 to 1.52

Nous pouvons l'observer au loin, lentement, qui se rapproche pendant que nous autres restons attendris à la regarder, cette lueur d'espoir releasée sur le très célèbre site d'actualité PS3NEWS. Certains d'entre vous perdent espoir jour après jour, crient au fake car trop déçus par la tournure que prend la scène, qui ne cesse de s'effondrer pour cause d'un nombre trop minimal d'avancées majeures.

Mais c'est aujourd'hui que l'espoir vient de renaître où personne ne l'attendait. Un membre pour le moins inconnu de la scène vient de releaser aujourd'hui en quelque sorte un premier "CFW 4.00", qui malheureusement, à notre grand désespoir, ne peut qu'installer des PKG signés par Sony mais il ne faut pas s'arrêter là car cette découverte pourrait bien mener tout droit vers la mise en place d'un CFW tel que nous le connaissons. Ps3hen, l'auteur de l'exploit, a révélé sa découverte : il a en fait modifié le dev_flash du firmware 4.00 et a modifié des options de sécurité pour débugger l'installation des fichiers PKG.

On peut dire que ce "CFW" ne nous sert pas à grand chose actuellement. De plus, pour l'installer, il vous faudra des qualités de soudeur car il faut modifier le dev_flash de votre console et vous munir de la puce E3 Flasher pour l'installer. Bien entendu, une version publique sortira sans doute mais pour le moment nous ne pouvons pas l'utiliser à proprement dit.

Installation :

1) Downgradez votre console du firmware 4.00 au firmware 3.55 à l'aide de la procédure habituelle de l'E3 Flasher.

2) Vous êtes redirigés sur le XMB, éteignez la console.

3) Placez le firmware officiel 4.00 .PUP au chemin d'accès de votre premier disque dur USB : PS3/UPDATE

Placez le dev_flash modifié de l'archive téléchargée ci-dessous sur votre deuxième disque dur USB.

4) Installez les PKG dev_blind et Blackb0x FTP via le menu "Install Package Files".

5) Lancez Dev_Blind puis Blackbox FTP dans le menu Jeu.

6) Branchez votre première clé USB puis rendez-vous grâce à l'utilitaire Blackbox FTP dans le dossier dev_blind, supprimez tout son contenu et remplacez-le par le dev_flash de l'archive téléchargée ci-dessous.

7) Appuyez sur le Bouton PS, la console va redémarrer et vous demander de réinstaller le firmware, validez puis changer de clé USB (c'est à dire la deuxième).

8) Rallumez votre console et appuyez deux fois sur le bouton PS.

9) Installez l'OFW 4.00 via le menu habituel (Mise à jour système ==> Périphérique USB)

10) Après l'installation votre PS3 redémarre. Votre console est en CFW.

Une vidéo, en guise de démonstration, a été postée par l'auteur :

SoulHeaven, concepteur des x360glitchip, est heureux de nous livrer aujourd’hui une nouvelle version de son soft baptisé 360gcProg et qui vous permettra de programmer facilement vos CPLD ou puces de glitch. Il est compatible avec toutes les puces basées sur un CPLD xilinx XC2C64A et avec les câbles LPT ainsi que les câbles USB open-source basés sur du FTDI.

Cette nouvelle version ajoute un timing alternatif pour les Slim récalcitrantes.

 RETROUVEZ NOTRE TUTORIEL ICI

Une grose nouvelle dans le monde de la PS3, puisque KaKaRoTo, qui fut l'un des premiers à publier un Custom Firmware 3.55, revient sur le devant de la scène avec des news concernant un CFW 4.00. Suite à une faille découverte avec le firmware 3.73, il s'est aperçu qu'elle était encore sur la version 4.00, et décide donc de s'y attaquer.

Ses avancées sont incroyables, et il publie donc un billet sur ses avancées actuelles. Pour le moment; rien de concret, car KaKaRoTo affirme être en conflit avec certaines personnes qui le soupçonnaient de ne pas avoir accès au lv0. On peut suivre l'avancée de son travail à cette adresse. Il faudra encore un peu de patience pour connaître les débouchés de son travail.

Tout commentaire négatif ou critique envers lui, son travail, ou ses choix résultera d'un ban de LS.

Here’s a “quick” status update on the 4.00 HEN (Homebrew ENabler) for PS3.

Following my clarifications from almost 2 months ago here, there has been a lot of progress. We have not been slacking off, we’re a group of about 10 developers working together for the last 2 months, for sometimes 15 hours everyday in order to bring back homebrew support to the latest version of the PS3.

There are three major parts to the HEN, first, getting the packages to install on the PS3, that part is done, completed, tested, debugged, etc.. the second part is to get the apps to run, that one still has major issues… the last part is something I will not discuss for now (it’s a surprise) but it’s about 60% to 70% done (and it has nothing to do with peek&poke and has nothing to do with backup managers or anything like that. This is and will stay a piracy-free solution for the PS3).

Now, running apps is the biggest challenge that we’ve been working on for the past 2 months. As some of you know, if you’ve been following me on Twitter, we originally had hoped for Mathieulh to give us the “npdrm hash algorithm” that was necessary to run the apps, but he was reluctant, he kept doing his usual whore so people would kiss his feet (or something else) so he’d feel good about himself. But in the end, he said that he refuses to give us the needed “npdrm hash algorithm” to make it work… So what I initially thought would be “this will be released next week” ended up taking a lot more time than expected, and we’re still nowhere near ready to make it work.

Mathieulh kept tossing his usual “riddles” which he thinks are “very helpful for those who have a brain”, and which pisses off anyone who actually does… so he told us that the solution to all our problems was to look in appldr of the 3.56 firmware.. and that it was something lv1 was sending appldr which made the “hash check” verified or not… so we spent one month and a lot of sweat and after killing a few of our brain cells out of exhaustion, we finally concluded that it was all bullshit. After one month of reading assembly code and checking and double-checking our results, we finally were able to confirm that that hash algorithm was NOT in the 3.56 firmware like he told us (at all).

He said that it was an AES OMAC hash, but after tracking all the uses of the OMAC functions in appldr, we found that it was not used for the “hash”… he then said “oh, I meant HMAC“, so we do that again and again come up with the same conclusion, then we’re sure it’s not in appldr, and then he says “ah no, it’s in lv1“.. have a look for yourself to what he decided to write : ps3devwiki.com/index.php?title=Talk:KaKaRoTo_Kind_of_%C2%B4Jailbr eak%C2%B4

That happened after the huge twitter fight I had with him for being his usual arrogant ass and claiming that he “shared” something (For your information, the code that he shared was not his own, I have proof of that too (can’t show you the proof because even if I don’t respect him, I gave him my word to not share what he gave me, and I respect my word) since he forgot to remove the name of the original developer from one of the files… also it was completely useless and was not used at all, just made me waste a day reading the crappy undocumented code. So why is he still trying to force his “advice” through these riddles even after we had that fight? Well to sabotage us and make us lose all those months of hard work!

So anyways, we had all accepted that Mathieulh was full of shit (we knew before, but we gave him the benefit of the doubt) and decided to continue working without considering any of his useless riddles. So we then tried to exploit/decrypt the 3.60+ firmware in order to get the algorithm from there.

Now, a few more weeks later, we finally have succeeded in fully understanding that missing piece from the “npdrm hash algorithm”, and here it is for everyone’s pleasure with some prerequisite explanation :

A game on the PS3 is an executable file in a format called a “SELF“file (kind of like .exe on windows), those “self” files are cryptographically signed and encrypted.. For PSN games (games that do not run from a bluray disc), they need to have an additional security layer called “NPDRM”. So a “npdrm self” is basically an executable that is encrypted and signed, then re-encrypetd again with some additional information. On 3.55 and lower, we were able to encrypt and sign our own self files so they would look like original (made by sony) “npdrm self” files, and the PS3 would run them without problem. However, it wasn’t really like an original file.. a real NPDRM self file had some additional information that the PS3 simply ignored, it did not check for that information, so we could put anything in it, and it worked. Since the 3.60 version, the PS3 now also validates this additional information, so it can now differentiate between NPDRM self files created by sony and the ones that we create ourselves for homebrew. That’s the “npdrm hash algorithm” that we have been trying to figure out, because once we can duplicate that information in the proper manner, then the PS3 will again think that those files are authentic and will let us play them.

Another important point to explain, I said a few times that the files are “signed”.. this means that there is an “ECDSA signature” in the file which the PS3 can verify. The ECDSA signature is something that allows the PS3 to verify if the file has been modified or not.. it is easy to validate the signature, but impossible to create one without having access to the “private keys” (think of it like a real signature, you can see your dad’s signature and recognize it, but you can’t sign it exactly like him, and you can recognize if your brother tried to forge his signature). So how were we able to sign the self files that were properly authenticated on 3.55? That’s because this “ECDSA signature” is just a very complicated mathematical equation (my head still hurts trying to fully understand it, but I might blog about it in the future and try to explain it in simple terms if people are interested), and one very important part of this mathematical equation is that you need to use a random number to generate the signature, but Sony had failed and used the same number every time.. by doing that, it was easy to just find the private key (which allows us to forge perfectly the signature) by doing some mathematical equation on it. So to summarize, a “signed file” is a file which is digitally signed with an “ECDSA signature” that cannot be forged, unless you have the “private key” for it, which is impossible to obtain usually, but we were able to obtain it because Sony failed in implementing it properly.

Now, back on topic.. so what is this missing “npdrm hash algorithm” that we need? well it turns out that the “npdrm self” has a second signature, so it’s a “encrypted and signed self file” with an additional layer of security (the NPDRM layer) which re-encrypts it and re-signs it again. That second signature was not verified in 3.55 and is now verified since the 3.60 version of the PS3 firmware.

One important thing to note is that Sony did NOT make the same mistake with this signature, they always used a random number, so it it technically impossible to figure out the private key for it. To be more exact, this is the exact same case as the .pkg packages you install on the PS3, you need to patch the firmware (making it cfw) so that those .pkg files can be installed, and that’s because the .pkg files are signed with an ECDSA signature for which no one was able to get the private key. That’s why we call them “pseudo-retail packages” or “unsigned packages”.

The signature on the NPDRM self file uses the exact same ECDSA curve and the same key as the one used in PS3 .pkg files, so no one has (or could have) the private key for it. What this means is that, even though we finally figured out the missing piece and we now know how the NPDRM self is built, we simply cannot duplicate it.

The reason we wasted 2 months on this is because Mathieulh lied by saying that he can do it.. remember when the 4.0 was out and I said “I can confirm that my method still works” then he also confirmed that his “npdrm hash algorithm” still works too? well he didn’t do anything to confirm, he just lied about it because there is no way that he could have verified it because he doesn’t have the private key.

I said I will provide proof of the lies that Mathieulh gave us, so here they are : he said it’s in 3.56, that was a lie, he said it’s an AES OMAC, that was a lie, he said it’s an HMAC, that was a lie, he said it’s in appldr, that was a lie, he said it’s in lv1, that was a lie, he said that he can do it, that was a lie, he said that “it takes one hour to figure it out if you have a brain”, that was a lie, he said that he verified it to work on 4.0, that was a lie, he said that he had the algorithm/keys, that was a lie, he said that once we know the algorithm used, we can reproduce it, that was a lie, he kept referring to it as “the hash”, that was wrong. The proof ? It’s an ECDSA signature, it’s not a hash (two very different terms for different things), it was verified by vsh.self, it was not in lv2, or lv1, or appldr, and the private key is unaccessible, so there is no way he could build his own npdrm self files. Now you know the real reason why he refused to “share” what he had.. it’s because he didn’t have it…

So why do all this? was it because his arrogance didn’t allow him to admit not knowing something? or was it because he wanted to make us lose all this time? To me, it looks like pure sabotage, it was misleading information to steer us away from the real part of the code that holds the solution…. That is of course, if we are kind enough to assume that he knew what/where it was in the first place. In the end, he wasn’t smart enough to only lie about things that we could not verify.. now we know (we always knew, but now we have proof to back it) that he’s a liar, and I do not think that anyone will believe his lies anymore.

...

Enough talking about liars and drama queens, back to the 4.0 HEN solution… so what next? well, we now know that we can’t sign the file, so we can’t run our apps on 3.60+ (it can work on 3.56 though). What we will do is look for a different way, a completely new exploit that would allow the files we install to actual run on the PS3. We will also be looking for possible “signature collisions” and for that we will need the help of the community, hopefully there is a collision (same random number used twice) which will allow us to calculate the private key, and if that happens, then we can move forward with a release.

When will the “jailbreak” be released? If I knew, I’d tell you, but I don’t know.. I would have said in last november, then december, then before christmas, then before new year, etc… but as you can see, it’s impossible to predict what we will find.. we might get lucky and have it ready in a couple of days, or we may not and it will not be ready for another couple of months.. so all you need to do is : BE PATIENT (and please stop asking me about an estimated release date)!

I would like to thank the team who helped on this task for all this time and who never got discouraged, and I’d like to thank an anonymous contributor who recently joined us and who was instrumental in figuring it all out. We all believe that freedom starts with knowledge, and that knowledge should be open and available to all, that is why we are sharing this information with the world. We got the confirmation (by finding the public key used and verifying the signatures) yesterday and since sharing this information will not help Sony in any way to block our efforts in a future release, we have decided to share it with you. We believe in transparency, we believe in openness, we believe in a free world, and we want you to be part of it.

If you want to know more about this ECDSA signature algorithm, read this interesting paper that explains it in detail, and you can also watch Team Fail0verflow’s youtube.com/watch?v=5E0DkoQjCmI that first explained Sony’s mistake in their implementation, which made custom firmwares possible.

Thanks for reading,

KaKaRoTo

XFlak, créateur de ModMii, nous propose aujourd'hui une nouvelle version de son programme qui passe en v5.2.0. Ce programme vous permettra de télécharger des IOS, des cIOS, des firmwares que vous voulez installer, des thèmes, etc. Il vous suffira de répondre à des questions simples et il téléchargera les fichiers nécessaires dans un dossier que vous devrez mettre dans votre carte SD et à installer à l'aide d'un installateur de WAD (PMW, WAD Manager...). Disponible en plusieurs langues (anglais, italien, français, allemand et espagnol), cet outil est indispensable à toute personne voulant modifier sa Wii. Changelog :

Added a DML rev selector and updated DML build process to support DML rev12+.

DML was also moved from Download Page 1 to Download Page 4.

I want to extend a big thank you to crediar for continuing to work on DML

and addressing the issues that DML was facing when running from bootmii IOS.

Your solution to install DML on the real NAND to slot 257 solved a lot of

problems and the scene thanks you. I also want to recognize WiiPower who

has become increasingly involved in the DML project.

Added an option to build DML with debug\logging mode enabled.

Updated NeoGamma on ModMii's Download Page 2 from R9 beta50 to R9 beta56.

This version of NeoGamma is able to use DML to play gamecube game backups

from an SD Card without requiring NEEK or an emulated NAND.

Added support to build d2x cIOSs with base IOS60, IOS70 and IOS80.

ModMii's SD\USB Forwarder creator was updated from v11b to v11c.

ModMii's other forwarder channels were also updated to v11c.

neek2o rev70+ now uses SNEEKInstallerv0.7a instead of SNEEKInstallerv0.6c.

Now when PC programs are downloaded with local save settings (or possibly Auto)

they will be saved to a Program Files folder wherever ModMii is saved instead

of always being saved to C:\ModMii\Program Files.

Other minor changes.

**MAJ 20/01/12** : par Yoann-95

ModMii vient de passer en version 5.2.1. Changelog :

**MAJ 26/01/12** : par gerome5

ModMii vient de passer en version 5.5.1. Changelog :

Après avoir publié comme à l'accoutumée son Fileset pour le LT+ V3.0 dédié aux Lite-On Slim, la Team Maximus nous propose une nouvelle version du Lizard Toolbox, une mise à jour du pack "SD Files" ainsi qu'une nouvelle révision pour le "cœur" du Lizard, le Gecko.

Pour ceux le souhaitant, il est possible depuis quelques versions de mettre à jour le Toolbox directement via le logiciel à l'aide du bouton "Get Lizard Updates" dans l'onglet "Settings". Pour le reste, il faudra le faire vous-même en téléchargeant les fichiers nécessaires pour le mode Standalone disponibles ci-dessous et en mettant à jour le firmware du Lizard via le programme prévu à cette effet : Lizard Firmware Updater.

Changelog :

- Lizard Toolbox V1.51 :

* Ajout configuration Clé Wifi pour le XK3Y

* Support du LT+ V3.0 Slim

- SD Files V3.00b :

* Support du LT+ V3.0 pour LiteOn Slim

N'oubliez pas que le 360 Lizard est disponible sur le LSstore, au prix de 73,90 € et livré en 24H !

Si vous avez suivi les récentes actualités, vous n'êtes probablement pas sans savoir que les Anonymous ont déclaré leur retour il y a deux semaines en annonçant de nouvelles attaques contre SONY et Nintendo qui approuvaient la loi SOPA (Stop Online Piracy Act). Cependant, la tribu des masques blancs avait remporté la bataille car ces deux dernières firmes s'étaient retirées plutôt discrètement de la liste des approbateurs.

Le temps, quant à lui, a passé et la décision finale du Sénat se déroule le 24 janvier, soit dans très peu de temps.

Ainsi, de nombreux organismes internationaux ont décidé de passer à la vitesse supérieure en censurant, publiant et annonçant. Les moyens sont divers et variés mais semblent être intelligemment utilisés :

- Google censure la bannière de la loi SOPA, et redirige ceux qui tentent d'y accéder vers un article au slogan particulier : Stopper le piratage, c'est détruire la liberté.

- Wikipédia propose lui une solution plus directe en coupant ses services durant 24 heures.

- Anonymous enfin, appelle les utilisateurs du réseau social Twitter à ne pas tweeter entre 8 heures et 20 heures.

Il n'y a pas à dire, si personne ne fait rien et laisse la loi censurer l'Internet et mettre en danger des entreprises comme bon lui semble, le monde joyeux et musical de l'Online pourrait très vite changer la face du monde et transformer celui-ci en monde désert, désolé et fourbe.

Quoi qu'il en soit, il en va de la liberté mondiale internautique et pour la protéger, nous vous invitons à vous rendre sur ces différents site pour réagir : à savoir ici, ici ou ici.

Et comme des images valent toujours mieux que de vulgaires mots, une vidéo a été postée pour décrire la loi SOPA, qui est même disponible pour les anglophobes grâce à une nouvelle fonction mise en place sur YouTube (sélectionnez "Sous-Titres", "transcrire la piste audio" puis "traduire les sous-titres en Français") :

Note : pour utiliser cette fonction, il faut se rendre directement sur le site officiel.

C'est sur le forum de GBAtemp que l'on apprend aujourd'hui l'information. Il semblerait que certaines WiiMote équipées du WiiMotion Plus (Pack Zelda par exemple) ne fonctionnent pas avec quelques homebrews, mais marchent sans aucuns souci avec les chaînes dites officielles (Chaîne disque ou navigation sur le système menu). Apparemment, Nintendo s'accroche toujours et essaie tant bien que mal de défendre sa console de salon.

Les principaux homebrews n'étant pas compatibles pas avec la nouvelle WM+ actuellement sont : l'Homebrew Channel (sûrement ce qui est le plus ennuyeux), USB Loader GX, WiiFlow, DevKitPro, qui est utilisé par la plupart des homebrews, ainsi que Dolphin.

Mais bonne nouvelle, un patch correctif non-officiel a été publié pour le dernier programme cité ci-dessus et il semblerait que la team USB Loader GX travaille sur une alternative à ce problème. La meilleure solution reste pour le moment d'utiliser une WiiMote simple et d'ajouter un WM+.

Pour voir si votre WiiMote Plus est compatible, il suffit de regarder le code sous le cache des piles  :

Voici une liste des codes ne fonctionnant pas :

LMA-RVL-WR/C C4
LMA-RVL-WR/Z-C4
LMB-RVL-WR/Z-C4
LMB-RVL-WR/Z-C6

Ceux fonctionnant :

LMA-RVL-WR/M-C2
LMB RVL WR/H-C0
LMB-RVL-WR/M-C0
LMA-RVL-WR/M C2
LMB-RVL-WR/Z-C2
LMC-RVL-WR/M-C2

Et vous, avez-vous été touché par ce problème ?

C'est sur le site tortuga-cove que Coveman vient de releaser un utilitaire qui va sans aucun doute en réjouir plus d'un car il est attendu depuis l'annonce même du hack PS3. Pour tous ceux qui trépignaient impatiemment de voir l'émulation PS2 sur nos chères consoles PS3 non-rétrocompatibles PS2, sachez que c'est désormais chose faite avec un utilitaire (fichier ISO) nommé "Open PS2 Loader" qui ne fonctionne malgré tout que si l'utilisateur en question dispose du dongle Cobra.

Nous pouvons tout de même crier de joie, les légendes tels que Jak and Daxter, God Of War, Sly, HitMan ou encore Ratchet et Clank ne sont plus une lueur s'éloignant lentement de la lumière et sont réellement jouables pour les heureux possesseurs de dongles Cobra.

Installation :

1) Téléchargez l'archive et extrayez le contenu en FTP ou grâce à un file manager tel que le très connu multiMAN vers le chemin d'accès : /dev_hdd0/PS2ISO

2) Lancez l'utilitaire grâce au Cobra Manager ou grâce à multiMAN et sélectionnez votre jeu.

3) Le jeu se lance !

Notes diverses :

- Il n'y a pas besoin du SWAP MAGIC

- Il n'y a besoin d'aucun disque optique dans le lecteur de la PS3

- Fonctionne sur les PS3 non-rétrocompatibles (testé sur une Slim)

- Les backups de vos jeux PS2 en ISO sont à placer dans le dossier de l'utilitaire (voir ci-dessus)

Sur le site GBAtemp est releasé aujourd'hui, par le développeur giantpune déjà connu pour ses nombreux exploits, l'utilitaire Casper dans sa première version, la 0.1. Tout d'abord, non, cet homebrew ne fait en aucun cas allusion au célèbre fantôme Casper et ne permettra donc en aucun cas de fantômifier votre Nintendo Wii.

En revanche, il peut être très intéressant car il permet en fait de lancer Bootmii depuis votre carte SD sur les différents utilitaires tels que Sneek qui empêchaient de le lancer ou encore grâce aux différents exploits ou même avec le Priiloader si la fonction "Lancer Bootmii" venait à être endommagée. Giantpune nous livre donc ce qui pourrait, utilisé à bon escient, un véritable couteau suisse de débriquage. L'utilitaire est cependant uniquement compatible avec les Wii 4.2 et 4.3. Il nécessite l'IOS 53 v5663 propre et sans patch.

L'auteur annonce également travailler sur une version améliorée qui permettra de lancer de jeux Virtual Console et Wiiware à la manière de postLoader dans une future version.

SoulHeaven, de notre forum et de Librasoft, est heureux d'annoncer aujourd'hui la sortie d'une nouvelle version de sa puce, la X360Glitchip, qui revient en V2.0.

Principale nouveauté, l'ajout d'un oscillateur sur le PCB afin de pouvoir se passer de la liaison avec le point clk_stby (le point à coté de l'HANA), ce qui fait donc une soudure de moins à faire et qui est toujours bon à prendre, d'autant plus que certains la considèrent comme étant difficile. C'est la même technologie utilisée par la team Rebug et initiée par nice69 sur les forums XBH.

Voici une vidéo de démonstration :

Soulheaven annonce sa puce comme Corona Ready, ce qui est vrai si l'on s'arrête au fait que le chip HANA n'est plus visible sur la carte mère Corona (il est intégré au northbridge) et que si un hack "glitch like" voit le jour sur Corona, la partie hardware ressemble à ce qui se fait déjà. De plus, comme SoulHeaven l'explique, cela ne veut pas pour autant dire que la Corona peut être glitchée. Il faut mettre à jour le fichier build.py ainsi que les patchs du SMC, du CB_B et probablement modifier le jed également. Enfin, les dernières versions de Corona ont la NAND associée à un eMMC (embedded MultiMediaCard) phison rendant impossible actuellement le dump de la NAND. La route avant un glitch sur Corona et une compatibilité toute Corona est donc encore longue.

Voici le communiqué disponible sur son site web :

Pendant que d'autres teams se contentent de copier et/ou de ne faire QUE du fric avec leur puce sans rien apporter de plus et/ou de faire des annonces qui n'annoncent rien, la team x360Glitchip vous apporte la première puce mondiale Corona Ready.

Comme vous le savez certainement, les corona (nouvelle version de carte mère Slim après la Trinity) n'étaient plus compatibles Glitch suite au retrait du chip HANA servant de timing via le point CLK_STBY.

La x360Glitchip v2 est la première puce mondiale ne nécessitant plus ce point là, et devient donc Corona Ready.

Bien entendu, il faudra une mise à jour du build.py du hack Glitch permettant la prise en charge du nouveau CB des corona, le CB 13121.

D'autres fonctionnalités de la v2 seront présentées bientôt, car cela ne s'arrêtera pas là. :-)

Voici une vidéo, d'une x360Glitchip v1.4, modifiée pour être Corona Ready, sur une Trinity.

Vous noterez l'absence du point B (Celui-ci n'est plus utile), et les temps de boot impressionnants. (10s, 15s, 7s et 12s).

Nous vous annoncions dans cette news que la Team RGLoader travaillait sur un nand builder permettant de créer des nand DevKit pour une console équipée du Reset Glitch Hack. La team RGLoader nous livre aujourd'hui la deuxième version publique et destinée uniquement aux consoles RGH ; une version compatible Jtag devrait voir le jour prochainement.

Comme nous l'expliquions dans la précédente news, avec ceci, vous aurez accès à la majorité des fonctionnalités d'une DevKit sur votre console retail :

- Support de Neighborhood : lancement de xex depuis le PC, screenshot, reboot de la console, transfert de fichier simplifié...
- Possibilité de débugger avec xBWatson ...
- Possibilité de faire des enregistrements vidéo avec XBMovie
- Etc.

Attention, vos profils et sauvegardes retail (console d'origine/jtag/glitch) ne seront pas reconnus/compatibles lorsque vous serez en DevKit.

Voici les nouveautés de cette version :

0v170

  -Added KV editing to the GUI
  -Xell dual boot (xell-gggggg.bin)
  -Bad block support
  -Added font files to nand image to fix fsd (thanks cOz)
  -No need to run image through nandpro anymore
  -More error handling, builder doesn't say successful build every time

Vous pourrez retrouver un tutoriel complet ici