Logic-Sunrise : actualités, téléchargements, releases, dossiers et tutoriaux
[Switch] Eden v0.0.4 RC1 disponible[PS5] etaHEN fête déjà ses 2 ansHi everyone,
I’m posting this message to inform you that there will be a minor firmware update (v.4.31) released on the evening of Monday, October 29th.
There will not be PlayStation Network maintenance during this time; online play and access to apps will not be affected during the release of this update.
This is not a mandatory update. However, we suggest you keep your systems updated with the latest firmware, as these updates further improve overall system stability and help provide you with the best online entertainment experience possible.
To update to v.4.31, select Settings from your Xross Media Bar (XMB) > System Update > Update via Internet and then follow the on-screen instructions.
More information about PlayStation system updates can be found here: http://us.playstatio.../systemupdates/
Tempest_Fire
Digital Platforms Community Manager
Sony Computer Entertainment America
With Team Xecuter's official annoucement today of the associated products (CR3 Pro and CR3-DGX), we're now able to publicly clarify that, contrary to an earlier statement made by c4eva on 2012-08-19, RGH (Reset Glitch Hack) is in fact required for DVD Key retrieval from all newer drives; Lite-On 1175/1532 DG-16D5S, and Hitachi 0500/0502 DLN10N.
To break it down a bit, these are the DVD Key retrieval RGH requirements:DVD Key retrieval from Lite-On 1175/1532 DG-16D5S on kernel 2.0.14XXX.0 or lower, requires CoolRunner Rev. A/B/C, CR3 Lite, or CR3 Pro (Slim version).DVD Key retrieval from Lite-On 1175/1532 DG-16D5S on kernel 2.0.15XXX.0/2.0.16XXX.0 and higher, requires CR3 Pro (Slim version) + CR3-DGX.DVD Key retrieval from Hitachi 0500/0502 DLN10N on kernel 2.0.14XXX.0 or lower, requires CoolRunner Rev. A/B/C, CR3 Lite, or CR3 Pro (Slim version).DVD Key retrieval from Hitachi 0500/0502 DLN10N on kernel 2.0.15XXX.0/2.0.16XXX.0 and higher, requires CR3 Pro (Slim version) + CR3-DGX.The CR3-DGX is an add-on that connects to the CR3 Pro and aids in CPU/DVD Key retrieval for systems on updated kernels 2.0.15XXX.0/2.0.16XXX.0 and higher. Until now, these systems were unable to have their keys retrieved by normal means due to Microsoft's thwarting of the "XOR hack" as of the 2.0.15572.0 update, which added a new key to the RC4 key hash calculation.
With the new Unlocked DVD Replacement PCB, LT Ultimate, and now Team Xecuter's other newly-introduced products, all 360s can now be RGH'd and all DVD drives can be flashed — a truly momentous point in Xbox 360 scene history!
[2012-10-31 11:45PM UTC] #fw <c4eva> the key originally dumped from 1175 drive is an aes key,but it was not the dvd key as originally thought. This aes key will still be dumped by the flashing process as it is unique per drive!
[2012-10-31 11:53PM UTC] #fw <c4eva> for 1175/1532 the dvdkey and realtime fw checks have been moved into the drive cpu, complicating things a bit!
[2012-10-31 11:59PM UTC] #fw <c4eva> kprobe is ensuring disc is readable, to pass civ reads!
- Mise à jour de la base de données en ligne de jaquettes (jaquettes de fifa 13/maiden/dishonored corrigées)
- Mise à jour de gameDATA3, lastGAME3 et bdRESET3 désormais compatibles CFW 4.30
- Mise à jour de Showtime en version 04.01.208 (PKG standalone et Showtime pour mM)
- Ajout d'une option cachée dans options.bin nommée “kid_protection” (pour définir les règles d'accès aux paramètres et au MMos)
- Re-compilé pour CFW 4.XX
- Changement de la méthode de chargement
- Réparation des bugs liés aux fichiers temporaires.
- Vous pouvez charger des SELFs via le net
- Vous pouvez charger des applications via un disque dur ou une clé USB
- Vous pouvez installer des applications sur un support USB via un fichier .Zip
- Vous pouvez déplacer des applications d'une clé USB à un disque dur.
- Et vous pouvez aussi supprimer des applications facilement.
- Vous pouvez charger des ZIP via le réseau directement, comme pour les SELFs.
- Un dossier "install" sera créé à la racine de votre clé USB/ disque dur. Les dossiers et contenus de l'homebrew se trouveront dans : PSL145310/homebrew/install.
- Le dossier "install" peut être créé facilement par vous-même, si vous ne pouvez pas être en réseau.
- Les programmes seront montrés dans PS3LoadX et les bouttons de commande seront disponibles immédiatement.
Télécharger PS3loadX 4.XX
Ok guys let’s take a big step there is the lv0 4.25 decrypted (elf) you should able to find the keys for the lv2/lv1/appldr
Boot Loader SE Version 4.2.5 …(Build ID: 4859,49406, .Build Date: 2012-09-10_13:48 :01)……..SDK Version
and here some cool info 4.2.5 sys.lv0.version. 4859 sys.lv0.revision sys.lv0.address. sys.lv0.size sys.flash.fmt sys.flash.ext sys.flash.boot sys.wake_source. sys.ac.sd sys.ac.misc sys.qaf.qafen sys.hw.config sys.hw.config_ve rsion sys.hw.model_emu late sys.cellos.flags sys.cellos.spu.c onfigure sys.ac.misc2. sys.sata.param sys.ac.product_c ode sys.boot.gos
Fast Recovery of CPU/DVD Key from 2.0.15572.0 – Tested on Trinity, Corona v1 & Corona v2 (4GB)
Fast Recovery of CPU/DVD Key from 2.0.15574.0 – Tested on Trinity, Corona v1 & Corona v2 (4GB)
Fast Recovery of CPU/DVD Key from 2.0.16197.0 – Tested on Trinity, Corona v1 & Corona v2 (4GB)
Fast NAND Programming
Fast XILINX CR JTAG Programming
Compatible with all CoolRunners inc the new CR3 Pro
Supports Full Post Monitoring
Compatible with both Phat and Slim
Onboard LED's indicate Power & Data
Easy Install System
Compatible with All NAND-X QSB's
Includes Cable For QSB V3 Kit or Wires Install (QSB V3 Kits Sold Separately)
Includes Cable For Xilinx CRJTAG
Includes Cable for Xecuter Sonus 360 (Sonus 360 QSB Sold Separately – Trinity Kit or Corona Kit)
Includes KIOSK option for Remote On
Built-in Programmer For Future Firmware Upgrades
Designed for the latest J-Runner App (Build 283+)
Rock Solid Design – Tested by the J-Runner Team
Supports New QSB V3 Kits (Solder Separately)
Supports Sonus 360 Programming
Affordable – We Provide You With More For Less !
High Quality & Trusted TX Design
- Need.for.Speed.Most.Wanted.EBOOT.PATCH.100.USA.PS3-unSANE [6 MB]
- Madagascar.3.EBOOT.PATCH.100.USA.PS3-unSANE [4.29 MB]
- Dead.Island.EBOOT.PATCH.100.USA.PS3-unSANE [10.21 MB]
- Medal.Of.Honor.Warfighter.EBOOT.PATCH.100.USA.PS3-unSANE [35.6 MB]
- Inversion.EBOOT.PATCH.100.USA.PS3-unSANE [8.09 MB]
- Lego.Batman.2.DC.Super.Heroes.EBOOT.PATCH.100.USA. PS3-unSANE [6.94 MB]
- 007.Legends.EBOOT.PATCH.100.USA.PS3-unSANE [6.28 MB]
- 007.Legends.EBOOT.PATCH.100.EUR.PS3-unSANE [6.28 MB]
- Darksiders.II.EBOOT.PATCH.100.USA.PS3-unSANE [12.29 MB]
- Persona.4.Arena.EBOOT.PATCH.100.USA.PS3-unSANE [3.96 MB]
- WWE.13.Eboot.Patch.PS3-DUPLEX [10.27 MB]
- Sorcery.Eboot.Patch.PS3-DUPLEX [8.18 MB]
- Resident.Evil.6.Eboot.Patch.PS3-DUPLEX [8.93 MB]
- Darksiders.II.Eboot.Patch.PS3-DUPLEX [12.29 MB]
- Adidas.miCoach.Eboot.Patch.PS3-DUPLEX [5.68 MB]
- Rune.Factory.Oceans.Eboot.Patch.PS3-DUPLEX [3.19 MB]
- XCOM.Enemy.Unknown.Eboot.Patch.PS3-DUPLEX [9.71 MB]
- WRC.World.Rally.Championship.3.Eboot.Patch.PS3-DUPLEX [9.82 MB]
- Hunters.Trophy.2.Eboot.Patch.PS3-DUPLEX [7.47 MB]
- Ridge.Racer.Unbounded.Eboot.Patch.PS3-DUPLEX [6.39 MB]
- Sleeping.Dogs.Eboot.Patch.PS3-DUPLEX [7.52 MB]
- Mugen.Souls.Eboot.Patch.PS3-DUPLEX [4.62 MB]
- Assassins.Creed.III.Eboot.Patch.PS3-DUPLEX
Wow... such hostility against me just cause I said that one my future projects was trying to adapt the btldr exploit to hardware so we can hack (ie run unsigned code) on all consoles. I think I deserve the opportunity to explain myself before you start doubting me.
That means releasing the btldr exploit (which it patchable) before the others devs can even check if its remotely possible but it is the only way to get redemption so let's start...
DUMPING THE BOOTLDR
As you know the bootldr is one of the two loaders that are signed per console and it was the only part of the system that haven't been hacked.
Once you load it the same way as metldr (via SigNotify) it would start requesting different addresses that we don't control. You can take a look on my user page to the dma sequence that it produces.
As you see it access a lot of different addresses and we don't have control of any of them so the first objective was to control the input/output.
The sandbox:
The objective was to redirect the flows of data to our controlled buffers so we know what is written or read. To achieve that a driver was created.
This driver performs two functions:
- the first is creating lv1 peek/poke using the patched lv114 that comes with OtherOs++ and other CFW.
- the second is reserve a block of consecutive memory that would be used as an HTAB.
The SPU is told to use our HTAB which in turns redirects to our user buffers. To get the physical address... the user pages are locked on memory and then using an old trick found by geohot their real address is retrieved.
At this point we have control of what the SPU reads BUT if consecutive small accesses are done we have no control if we want to change something in between.
The first exploit:
I'm calling this an exploit but actually is a bad implementation of a feature cause it should be disabled on isolation. The feature is called the MFCLSACMP. Basically is a register on the spu that is checked before doing a dma op.
If the source/target address on the SPU is inside the mask defined by this register then dma is stopped and an interruption is reported. Until this interrupt is cleared the dma is not started.
Great, so we control what it reads and when it is read... the first objective was achieved total control of the I/O. That is what you can see on my user page on wiki.
However this all so allowed me to find the biggest problem on using the booldr as an oracle.... the config ring.
The config ring is a series of bits that syscon sends to the cell before during the power up.... On this cell implementation the config ring is accessible from inside the spu as a read once channel.
So unless I could find a way to refill the channel the bootldr couldn't be used as oracle. Even worse at this point I didn't know how the config ring was read (although an undocumented channel was on top of the list).
I spent a couple weeks trying to figure the problem. Finally I posted the log on the wiki looking for help. Obviously some approach. We exchanged info. I gave then the tools and they gave me means of validating my hypothesis (those on the log)
We worked a lot of time on this. Remember that I was trying to get an oracle not an exploit so filling the config was a must... several thing were tried but none worked.
After a month or so I started checking other projects while thinking of what to do. Then after several months I decided to try to exploit it instead of using it.... given the log the entry point was clear...
The bootldr exploit:
If you see the log you'll see a lot of data exchanging between the spu and the syscon. graf had described it on his bible so it was known... but the log also said that the data was read twice once to read the header and once to read header + data.
On the header was a variable length. So I decided to change the len between both reads.... didn't work until i corrected also the chksum... and then BINGO! unexpected behavior... a possible exploit was found.
The advantage of this exploit is that it gave us a lot of points to test. The info was shared and two of us friendly raced one against the other to find the correct possibility.
I won the race of finding the execution point although I lost the one for dumping. The winner was command 0x20 which is an info message... casually the config error message... so their own protection had given us the bootldr.
That's the story of the exploit... it was then decided that I got the ultimate decision of releasing the exploit and any of us could leak the keys... however they asked me too hold it until SONY has reacted to the dex conversion and I told them that I would not release them until I got the appldr keys by myself.
I suppose they passed the keys to others and them at some point the keys probably arrived to EXETrimAll and N0DRM (I don't think they exploited trublue...). Meanwhile i was in the middle of my holidays and when I come back they were releasing non-stop so I didn't see that it was necessary to leak them.
Unfortunately they also leaked to a scoundrel that sell the key to discblu.
That forced some one that have the key to make it public.
You said that I'm angry cause someone leak the key... nope. I was angry with discblu... and with some hacker that reappeared just to say that he already knew how to do it. As you can see the method is completely software and does not use the signature bug (except for installing the cfw... but then all the apps need to credit them). If you persist I'll tell you that this can also be done on a 3.15 with geohot pulse exploit.
The code:
http://www.sendspace.com/file/wvknol
I have attached the code of a working version for latest exploitable slim. I know that also works on other version but I don't know which ones. It is only valid for NOR consoles cause it expects a full NOR flash as one of the parameters.
It has two programs. One is a kernel module so it must be load with insmod.
The second its a user program that takes as parameter the speID (i recommend using 0 that is normally enabled), the flash file and a debug file with the buffers. the actual dump is WRITTEN TO DUMP.BIN
If the exploit worked you should see the text "Interrup". If it didn't try modifying line 799 correctPacket(0x40, 0, 0); by incresing the first parameter (0x40). Thats the len that is send on the second read.
The dump is shifted by as a side effect of the bug. For me it was 0x800 bytes... but others got different result. The start function must be at 0x400 once shift is corrected
BTW the code is ugly and there is a lot of data that is not used so if someone has questions please ask me (on this or other ps3 related things)... I'll be available until sunday... then I'll definitely leave.
Now I'll explain my idea for the hardware solution.
Improving the exploit
THE FOLLOWING IS ALL THEORETICAL AND IT WILL PROBABLY NOT WORK (I'M NOT A HARDWARE EXPERT AND THAT'S THE MOST DIFFICULT PART)
In this case the objective is not dumping the bootldr but get code execution. Using an small payload a program will be copied to spu. That program will just copy a patched unencrypted lv0 to the memory and tell the PPU that code was loaded successfully.
By achieving that we would have full control of the system. Our patched lv0, will load an original lv1ldr (required to get the ATA keys) which will load an original lv1 but before giving control to level1 our level0 will patch it so we still have control. Same with lv2 and vsh.
As I said basically the bug consist of changing the response len between the first read and the second. That is easily done if you control the buffer where the data is located (exploitable consoles). But we want to do this before anything is loaded
So we need to change the comm between syscon and cell before any software outside the cell is loaded... the only option is a hardware interceptor. This hardware will intercept the communications and change it so the exploit is triggered (This is called a man in the middle attack). The payload will be sent as part of the 0x20 command reply... if the bug is trigger properly we know that our payload will start around 0x3E010.
In addition to this I recommend adding a second flash chip that will contain the patched firmware. That will allow the user to go from patched to official with a switch
As you see the device I propose is not a drm device... it actually triggers an exploit similar to the ODE device that whats announced (BTW that is perfectly done with the info that glevand posted).
The questions is: Is all of this possible?... well from the software part I'm pretty sure but I don't know if the hardware can be build or if the cost will be too much.
In any case if it is possible, there is enough info on this post to make it...
Unfortunately there is also a enough info to patch the bug (if they didn't already). However it would only be patchable on factory...
1- Ce CFW n'a pas les vérifications du LV1 désactivées et ne peut donc être installé sur une PS3 downgradée que si la console a été correctement déhashée, c'est-à-dire que le Reset Syscon a bien été effectué (si vous ne savez pas si votre PS3 est concernée, déhashez-la dans le doute afin d'éviter les mauvaises surprises). Lien ----> Voir "Activation du QA Flag" un peu plus bas.
2- Faites toujours un backup de votre NOR/Nand à l'aide de multiMAN, de memdump, de Preloader Advance, etc. avant d'installer n'importe quel CFW, de façon à avoir un backup à restaurer en cas de brick.
Avoir un dump de NOR/Nand valide est une étape indispensable avant la mise à jour car cela vous permettra d'avoir toujours un moyen de restaurer votre flash (à l'aide de flashers hardware).
** Un flash hardware tout seul, sans dump valide, ne peut pas réparer un brick de PS3**
3- Le QA flag doit toujours être activé sur votre PS3 pour que les opérations de mise à jour ou de downgrade soient plus sûres. Lien ----> toggle_qa.pkg
4- Toujours utiliser le menu Recovery lors de l'installation de ce CFW pour éviter les éventuels bricks (la mise à jour via le XMB fonctionne mais le Recovery est plus sûr).
6- Vérifiez toujours que le MD5 du fichier PUP téléchargé correspond à celui indiqué dans la news avant d'installer n'importe quel CFW, afin d'éviter tout risque de brick.
7- NE LAISSEZ PAS DE DISQUE DANS LA PS3 LORS D'UNE MISE A JOUR FIRMWARE. Pour cause, la PS3 va d'abord chercher la mise à jour sur le disque.
8- Vous avez besoin d'être en 3.55 pour installer ce CFW. Il est tout simplement impossible de le faire depuis n'importe quel autre firmware (à moins d'avoir une base de CFW Rogero 4.21 CEX v1.00).
- Téléchargez le PUP 4.25 downgrader ---> 4.25 Downgrader mirroir --->4.25 Downgrader Taille : 176MB (184,595,263 bytes) MD5 :
49d80e07fc1f5ca1b0840e02e94635db
- Renommez le fichier téléchargé en "PS3UPDAT.PUP" et copiez-le sur votre clé USB de manière à respecter l'arborescence suivante : "USB\PS3\UPDATE\PS3UPDAT.PUP"
- Lorsque vous êtes sur le CFW 4.30 Rogero, allez dans Mise à jour du système sur le XMB et installez le CFW 4.25 downgrader.
- L'installation du CFW de downgrade terminée, vous êtes sur un CFW 3.55 hybride qui va encore vous afficher version 4.21/4.30 dans les paramètres système.
- Activez le QA Flag en suivant ces instructions :
1- Téléchargez le package Rebug QA_Toggle package from here ---> toggle_qa.pkg
2- Mettez le "toggle_qa.pkg" sur votre clé USB et installez-le sur votre PS3.
3- Lancez le "Rebug Toggle QA" depuis le XMB, l'écran va devenir noir et vous allez voir la LED du HDD clignoter. Ensuite, si tout s'est bien passé, vous allez entendre 2 ou 3 bips et la PS3 va redémarrer sur le XMB.
4- Si vous voulez être sur que le QA Flag a été activé, rendez-vous dans "Paramètres réseau" et faites la combinaison de touches suivante (toutes en même temps) :
L1 + L2 + L3 (appuyez sur le stick de gauche) + R1 + R2 + dpad_bas
Vous devriez voir Edy Viewer, Debug Settings et Install Package Files si cela a été fait correctement.
- Maintenant, metttez le CFW Rogero 3.55 CEX v3.7 sur votre clé USB de manière à respecter l'arborescence suivante : "USB\PS3\UPDATE\PS3UPDAT.PUP" ---> CFW Rogero 3.55 CEX v3.7
- Démarrez la PS3 sur le menu Recovery et installez le CFW Rogero 3.55 CEX v3.7 (à faire depuis le menu Recovery, c'est important !)
- Une fois l'installation finie, vous êtes désormais revenu en CFW Rogero 3.55 CEX v3.7.
- Démarrez la PS3 sur le menu Recovery Menu et installez l'OFW/CFW 3.55 de votre choix ou un nouveau CFW 4.21
1- Méthode "propre": ( CFW4.21 --> CFW3.55 --> CFW4.30 )
---- Downgradez vers le firmware 3.55 à l'aide du guide disponible ci-dessus.
---- Une fois en CFW Rogero 3.55 CEX v3.7, vous pouvez mettre à jour une nouvelle fois depuis le menu Recovery vers le nouveau CFW 4.30
2- Méthode alternative #1 ( CFW4.21 --> Mise à jour via le XMB --> CFW4.30 )
---- Vous pouvez d'abord essayer de mettre à jour de votre CFW 4.21 vers le CFW 4.30 en utilisant "Mise à jour système --> Mise à jour depuis un périphérique USB".
---- Si cela ne marche pas, vous aurez ensuite à utiliser la méthode alternative #2
3- Méthode alternative #2 ( CFW4.21 --> Menu Recovery --> CFW4.30 )
---- Vous pouvez d'abord essayer de mettre à jour de votre CFW 4.21 vers le CFW 4.30 depuis le menu Recovery.
---- Si cela ne marche pas, vous aurez ensuite à utiliser la méthode "propre" ( CFW4.21 --> CFW3.55 --> CFW4.30 )
- Le problème de compatibilité avec certains modèles de PS3 a été entièrement corrigé.
- Le problème d'icônes sur le XMB in-game (bouton PS en jeu) est désormais résolu.
- L'accès au PSN/SEN est disponible aussi longtemps que l'actuel "passphrase" reste le même.
- Le chargement des jeux depuis l'icône App_home est maintenant fonctionnel.
- Le CFW a été testé par des centaines de personnes sur tous les modèles de PS3 (FAT et Slim) et aucun problème n'a été rencontré.
- Le CFW peut lancer les jeux signés avec les clés 4.30 maximum sans qu'une modification des Eboot/Sprx soit nécessaire.
- Les jeux peuvent être chargés depuis l'icône disque (avec un jeu original dans le lecteur Blu-Ray) et depuis app_home (sans disque mais cela peut être incompatible avec certains jeux).
- Les homebrews 3.55 actuels ne peuvent être exécutés sur ce CFW, ils doivent être obligatoirement resignés proprement pour le firmware 4.21.
Ce CFW étant encore frais, si vous l'installez, veillez à faire un dump de votre flash et à suivre scrupuleusement le tutoriel d'installation. En outre, le risque de bricks est toujours présent donc soyez prudents. En aucun cas Logic-Sunrise ne pourra être tenu pour responsable des dommages que pourrait subir votre console !
Le CFW 4.30 se comporte bien jusqu'à présent, il a été testé à la fois sur Slim (tous les modèles) et sur Fat (celles ayant brické avec la version 1.09 incluses) sans qu'un quelconque problème se soit présenté. De plus, multiMAN est maintenant prêt et est entièrement compatible avec le CFW 4.30. Il sera publié à peu près en même temps que le CFW.
Il va falloir encore peut-être quelques heures pour tout vérifier et préparer. Puis les beta testeurs qui ont en leur possession un flasher auront accès à ce CFW et si tout se passe bien, il s'en suivra sa publication au grand public.
Amicalement
Après avoir testé un bon nombre de choses, je peux en arriver à la conclusion que les nouveaux CFW (4.21/4.25/4.30) utilisent beaucoup de fichiers hybrides afin de pouvoir être installés depuis un OFW/CFW3.55.
Et ces "coreos packages / .self" patchés utilisés par les CFW 4.21/4.25/4.30 ont une compatibilité aux effets différents sur les consoles FAT et Slim.
Donc chaque CFW supérieur au 3.55 comportera toujours ces risques de bricks et doit être utilisé avec la plus grande précaution.
Je m'apprêtais à publier un nouveau CFW 4.25 v1.2 pour FAT et un autre CFW 4.21 v1.2 pour Slim
(oui, 2 versions, une pour Slim, une autre pour FAT, afin de limiter les risques de bricks) quand j'ai vu que la team E3 avait livré un nouveau CFW 4.30.
Donc je vais encore attendre un peu et que je vais vérifier le coreos et les patchs du nouveau CFW 4.30 et continuer de tester le nouveau multiMAN de Dean afin de le porter aussi sur CFW 4.30.
Plus d'informations seront publiées quand tout sera prêt et que les test seront concluants....
- Added support for 4.30 CFW
- Added support for Standard and Hermes payloads for 4.30 CFW
- Added support for BD-Mirror (External USB HDD) for 4.30 CFW
- Updated 6 language files