Today a non leaked before 4.25 OFW for DEX console have been leaked by a new team called Mate Team.
It had been tested and verified by a DemonHades and Elotrolado members.

ps3-cex-retail-to-dex-debug-conversion-method-is-released-31582-1.jpg

Also to note: its the last DEX firmware that can be installed to a converted consoles a.k.a CEX2DEX consoles, since a brick reports have been reported about upgrading a converted DEX consoles to a non leaked also 4.30 OFW for DEX.

BTW: Sony had implemented new security checks in 4.30 DEX OFW to check some values in eEID5, so since this part is not converted using leaked CEX2DEX methods then its easly find the non real DEX console and brick it.

Download it here: DEX 4.25 FW

Mirror: PS3 DEX Firmware 4.25 Mirror by PS3SceneFiles

NEWS SOURCE: DemonHades

PS3 LV0 Keys leak explained by scene devs



Media and News sites are reporting that the PS3 LV0 leak/hack may be the 'One That Sony Can’t Stop'. Meanwhile, Scene devs explain it so you can understand the true significance of all this.

We all know about the recent PS3 LV0 Keys leak, and that thanks to it we are already starting to see new CFW based on 4.21 (and probably beyond).

News sites around the world, including the BBC, Digital Foundry/Eurogamer and Kotaku already reported on this, and are calling it "The Final Hack": something that Sony can’t block anymore! From Eurogamer:

The reveal of the LV0 key basically means that any system update released by Sony going forward can be decrypted with little or no effort whatsoever. Options Sony has in battling this leak are limited - every PS3 out there needs to be able to decrypt any firmware download package in order for the console to be updated (a 2006 launch PS3 can still update directly to the latest software). The release of the LV0 key allows for that to be achieved on PC, with the CoreOS and XMB files then re-encrypted using the existing 3.55 keys in order to be run on hacked consoles.

But now, how about an explanation by Scene Developers themselves?

Marcan (Fail0verflow) and Wololo have shared more info and a great Q&A so you can understand the true significance of all this.

From Marcan (Team Fail0verflow):

[...]

Presumably, 18 months later, some other group has finally figured this out and either used our exploit and the hardware assistance, or some other equivalent trick/exploit, to dump bootldr. Once the lv0 decryption key is known, the signing private key can be computed (thanks to Sony’s epic failure).

The effect of this is essentially the same that the metldr key release had: all existing and future firmwares can be decrypted, except Sony no longer has the lv0 trick up their sleeve. What this means is that there is no way for Sony to wrap future firmware to hide it from anyone, because old PS3s must be able to use all future firmware (assuming Sony doesn’t just decide to brick them all…), and those old PS3s now have no remaining seeds of security that aren’t known. This means that all future firmwares and all future games are decryptable, and this time around they really can’t do anything about it. By extension, this means that given the usual cat-and-mouse game of analyzing and patching firmware, every current user of vulnerable or hacked firmware should be able to maintain that state through all future updates, as all future firmwares can be decrypted and patched and resigned for old PS3s. From the homebrew side, it means that it should be possible to have hombrew/linux and current games at the same time. From the piracy side, it means that all future games can be pirated. Note that this doesn’t mean that these things will be easy (Sony can obfuscate things to annoy people as much as their want), but from the fundamental security standpoint, Sony doesn’t have any security leg to stand on now. It does not mean that current firmwares are exploitable. Firmware upgrades are still signed, so you need an exploit in your current firmware to downgrade. Also, newer PS3s presumably have fixed this (probably by using newer bootldr/metldrs as trust roots, and proper signing all along).”

[...]

Can this be used to sign binaries to run homebrew on OFW PS3s (ala the PSP key leak)? Are those private keys sufficient to sign homebrew software such that they will run in unmodified firmware?

No. The keys are used for two purposes: chain of trust and chain of secrecy. The compromise of the keys fully compromises the secrecy of the PS3 platform permanently, as you can just follow the links down the chain (off-line, on a PC) and decrypt any past, current, or future firmware version. Current consoles must be able to use any future firmware update, and we now have access to 100% of the common key material of current PS3s, so it follows that any future firmware decryptable by current PS3s is also decryptable by anyone on a PC.

[...]

Old PS3s are now in the same boat as an old Wii, and in fact we can draw a direct comparison of the boot process. On an old Wii, boot0 (the on-die ROM) securely loads boot1 from flash, which is securely checked against an eFuse hash, and boot1 loads boot2 but insecurely checks its signature. On an old PS3, the Cell boot ROM securely loads bootldr from flash, which is securely decrypted and checked using an eFuse key, and then bootldr loads lv0 but checks its signature against a hardcoded public key whose private counterpart is now known. In both cases, the system can be persistently compromised if you can write to flash, or if you already have code execution in system context (which lets you write to flash). However, in both cases, you need to use some kind of high-level exploit to break into the firmware initially, particularly if you have up-to-date firmware. It just happens that this is trivial on the Wii because there is no game patch system and Nintendo seems to have stopped caring, while this is significantly harder on the PS3 because the system software has more security layers and there is a game patch system.

From Wololo:

Breaking it down into simple and easy to understand words

Since Marcan’s answers can be a bit difficult to digest, I’ve broken them up into the form of questions and answers with the special help of ViRGE on this. This will clear alot of it up for those less technical.

Q: What exactly has been recovered?
A: The keys used by bootldr to decrypt/verify lv0, and by reversing the process the private keys used by Sony to sign lv0. If we consult our handy 3.60+ chain of trust diagram, we can see that bootldr is at the very root of the chain of trust, with lv0 being the first module it loads.



Q: So what can we do with the lv0 signing key?
A: In short, we can use it to decrypt lv0, modify it to patch out any lv0 security checks, and resign it with a legitimate key that bootldr will accept. With the chain of trust broken and lv0 no longer enforcing the security of the modules that it controls, we can then start modifying lv1ldr, lv2ldr, appldr, isoldr, etc to patch out their security checks and add CFW functionality.

Q: Can Sony “fix” this like they did for the 3.55 exploit?
A: No. With 3.55 the keys metldr used to verify its dependent modules were recovered. So Sony simply stopped using the now-insecure metldr and started using bootldr (which was still secure) to load.. Sony doesn’t have any more secure modules like bootldr left so like I said in my original post they have no options and cant fix anything; without getting too technical, we now have the keys to every “common” hardware module that is able to decrypt Sony-signed modules. The only thing left are the modules that use per-console keys, which are useless for booting common firmware (which must be decryptable by every PS3)

Q: So bootldr is fixed in hardware?
A: Correct. Like metldr, bootldr cannot be software updated by Sony. It’s hard-coded in hardware. As a reminder, bootldr/metldr themselves can’t be exploited, but because of the keys we have recovered we can make them load anything we want, nullifying whatever security they provide.

Q: What about future firmwares?
A: Good news! We can decrypt those too. Sony can use various coding tricks to make the process more difficult (this is called obfuscation), but they can’t stop us by using keys. We will always be able to decrypt lv0, and as long as we can figure out how to navigate lv0 we can figure out how to decrypt and modify its dependent modules. For those of you that follow Sony hardware this is much like how the earlier PSPs were hacked. So we can always decrypt the firmware and will be able to create newer CFWs as long as we can get past any obfuscation by Sony

Q: So the PS3 is utterly and completely broken?
A: To an extant yes, debatable but unlike the 3.55 hack we have mostly everything needed. Sony will never be able to re-secure existing consoles.

Q: What about consoles running firmware newer than 3.55?
A: Because all “old” consoles use the same keys to verify modules like lv0, at a minimum we can decrypt, patch, and resign the firmware. The problem is that we need a way to convince the PS3 to flash our modified firmware. With 3.55 and below that was easy enough to do because of the keys recovered, but 3.56 and later change that so that flashing is more complex than just using the recovered keys. This isn’t an insurmountable problem – hardware flashers will always work – but for easy software flashing we need to find new exploits in the PS3 software stack to convince OFW consoles to flash CFW

Q: What about newer consoles?
A: So there’s the real problem. Remember how we said bootldr and metldr are fixed in hardware? Sony can create new hardware, and update those modules in the process. By using new hardware in conjunction with new firmware for that hardware, Sony could completely change the keys used to secure the system. Without getting too technical, all of this progress comes from the fact that Sony was sloppy and did a poor job of implementing their security on earlier consoles, which is what lead to the first keys being leaked. Sony could always issue new hardware with new keys and a fixed security system at which point we’d be completely locked out of that new hardware. It’s entirely possible they’ll do this (if they haven’t done so already), so much like the PSP we’re going to end up with a limited number of consoles that have hardware-based flaws that can be exploited. Of course we then found new ways of exploiting the PSP anyhow, and ultimately were able to exploit every PSP made in one way or another.

If you are on anything higher than 3.55 it doesn’t mean you are out, there are ways to downgrade if your model is one thats able, otherwise you are just not able to do anything right now until more dev work is done. So sit tight and hold on. Again stay tuned, more info and news will be definitely coming.

There you have it. Stay tuned for more scene news in relation to this massive leak/hack in the upcoming days!

* UPDATE:

Scene dev 'KaKaRoTo' has also shared more info regarding this leak in an interview via PlayStationLifeStyles.net:

On today’s Daily Reaction, we have a very special guest, Youness ‘KaKaRoTo’ Alaoui, developer of the first “Modified Firmware” for the PlayStation 3, to help us discuss the news that the PS3 has once again been hacked. Should the hackers have worked on finding the keys as it’s their device, or should they have expected the leak? And what does the hack really mean for Sony? Seb, Dan and Youness discuss.

Disclaimer: KaKaRoTo was not involved in the current hack or CFW.

Seb: I’d like to think that I’ve been pretty open minded about hacking in previous interviews I’ve held, but you have to wonder what ‘The Three Musketeers’ were thinking when they shared the keys with other people. You can’t trust anyone on the internet, and it was sadly naive to believe that one of the people they gave it to wouldn’t try to sell it. Now, they’re probably worrying whether Sony is looking for them, preparing to sue them.

I’m all for being able to do what you want with your own technology, you bought it, do what you want with it. But, just like when I buy a pen I shouldn’t pour the ink all over my face, individuals need to be responsible for what they do with the tech. Hack it, crack it, turn it into a toaster, whatever – but if letting people know what you did and how you did it could lead to piracy, then don’t release it, don’t share it.

Youness: There is no denying that there is a part of responsibility in what is being done by the hackers, but to be honest, you can’t really predict what will happen in the future, and you can’t be responsible for what others do. Don’t forget that this release of the lv0 keys doesn’t add such a huge advantage to the hacking community, but the keys were never meant to be released, because it was still somehow opening up potential piracy which is something the true hackers are absolutely against. The secret of the keys was well guarded, but somehow it got leaked (after many many months), and the reason for the release was to prevent some greedy company (dongle manufacturer) from profiting from the piracy it could have enabled. In the end, it happened, it’s unfortunate, but I wouldn’t sweat (or rejoice) too much over it. The release wasn’t about the fame or the “being first”, it was about countering an immoral act.

You can read the full interview on this link.

NEWS SOURCE #1: lv0 keys leak explanied scene developers (via) PSX-Scene
NEWS SOURCE #2: Digitalfoundry PS3 the final hack (via) EuroGamer

Our thanks to 'Gauss' for this news item!

Handy tool for those getting into CFW 4.21

This Script for SCETool allows you to resign EBOOT's and run CFW 3.55 homebrew apps on the newly released CFW 4.21.

As its name suggests, this 4.21 EBOOT Resigner by Chinese developer 'Rain fish' (aka JjKkYu), is a script for SCEtool that allows you to resign 3.55 or decrypted EBOOT.BIN files for use with 4.21 CFW.

Here's the translated info:

This is a script of sectool to resign the 3.55- or decrypted EBOOT.BIN for 4.21CFW use.

Tutorial:
1. Extract the 4.21 EBOOT Resigner.zip.
2. Put EBOOT.BIN into the extracted folder.
3. Run resigner.bat to resign EBOOT, you may need to choose encrypt type.
4. If you chose NPDRM type, you need to enter Content-ID.
5. The original EBOOT.BIN will be renamed to EBOOT.BIN.BAK.

This script is tested on BD4.21 CFW, and it should work on Rogero 4.21.
Some game also contains decrypted self or sprx file, you need to resign them manually.

Credit to badzbb.

Download Link:

- CFW4.21 EBOOT Resigner.zip

* UPDATE.

In a related note, the guys over at PSX-Scene have compiled a neat list of Homebrew compatible (and already re-signed) with the new 4.21 CFW, from different scene sites. You can check it out HERE!

NEWS SOURCE #1: CFW 421 eboot resigner script for scetool released (via) DashHacks
NEWS SOURCE #2: 4.21 eboot resigner (via) PSX-Scene

Our thanks to 'Gauss' for this news item!

Now working on both 3.55 & 4.21!

Comgenie is back with an update for his Filemanager, with added compatibility for the just released 4.21 CFW!

Comgenie's Awesome Filemanger has received an update, also following with the recent CFW 4.21 'madness'.

The newest build has been tested on Rogero CEX-4.21 CFW.

Here's the changelog for the new v0.06 for CFW 4.21:

0.06 for 4.21!
The most awesome filemanager is now available for the 4.21 CFW!
Click on the download link below. 4.21 CFW is required (Tested with Rogero CEX-4.21 CFW)

Release Log 0.06
- Added move support for faster moving files/directories instead of copy/delete.
- Added very basic LUA support (only string/math libs + echo function). Expect much more functions to be supported in next releases
- Several fixes for (again) people with different screens

You can get more info on the official Comgenie website below. And, be sure to download the newest version from HERE!

NEWS SOURCE #1: FileManager (via) ComGenie
NEWS SOURCE #2: Comgenies awesome filemanger for cfw 421 (via) DashHacks

Our thanks to 'Gauss' for this news item!

A nice contribution by 'JuanNadie'

Check out a this really neat guide by 'JuanNadie', in which he fully explains a bootldr exploit, and so, how to dump it...

In more of the recent LV0 leak and the CFW 4.21 mayhem, PS3 dev 'JuanNadie' has now shared a tutorial on How to Dump the bootldr, which could be really useful for more future scene developments. In this one, he fully explains the exploit found and he even shares a piece of code of it!

Here is it:

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 the output file.
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...

You can find more info about this on the source link below!

NEWS SOURCE: Thread #459578 (via) PS3Hax

Our thanks to 'Gauss' for this news item!

With all the leaking of keys it's now possible to decrypt new games and make them available for CFW 3.55. This is for the people that can't or won't make the jump to Rogero's 4.21 CFW. A new group that call themselves unSANE took up the challenge and made a few new games available.

First few:

Wanted.Corp.EBOOT.PATCH.100.EUR.PS3-unSANE22
Silent.Hill.HD.Collection.EBOOT.PATCH.100.EUR.PS3-unSANE
Disney.Pixar.Brave.EBOOT.PATCH.100.EUR.PS3-unSANE22
Risen.2.Dark.Waters.EBOOT.PATCH.100.EUR.PS3-unSANE22
Madagascar.3.EBOOT.PATCH.100.EUR.PS3-unSANE
Bejeweled.3.EBOOT.PATCH.100.EUR.PS3-unSANE
Lollipop.Chainsaw.EBOOT.PATCH.100.EUR.PS3-unSANE
Silent.Hill.HD.Collection.EBOOT.PATCH.100.USA.PS3-unSANE

Mirrors:
Silent.Hill.HD.Collection.EBOOT.PATCH.100.EUR.PS3-unSANE [4.78 MB] - Mirror on PS3SceneFiles
Disney.Pixar.Brave.EBOOT.PATCH.100.EUR.PS3-unSANE [4.41 MB] - Mirror on PS3SceneFiles
Risen.2.Dark.Waters.EBOOT.PATCH.100.EUR.PS3-unSANE [8.51 MB] - Mirror on PS3SceneFiles
Wanted.Corp.EBOOT.PATCH.100.EUR.PS3-unSANE [4.48 MB] - Mirror on PS3SceneFiles
Silent.Hill.HD.Collection.EBOOT.PATCH.100.USA.PS3-unSANE [4.49 MB] - Mirror on PS3SceneFiles
Madagascar.3.EBOOT.PATCH.100.EUR.PS3-unSANE [4.29 MB] - Mirror on PS3SceneFiles
Lollipop.Chainsaw.EBOOT.PATCH.100.EUR.PS3-unSANE [10.2 MB] - Mirror on PS3SceneFiles
Bejeweled.3.EBOOT.PATCH.100.EUR.PS3-unSANE [8.87 MB] - Mirror on PS3SceneFiles

We now have a CFW 4.xx - 3.55 Eboot release thread -> http://www.ps3crunch.net/forum/threa...release-thread

Source: PSX-Scene

Support for Custom Firmware 4.21!

multiMAN has once again been updated by DeanK, this time adding full support for the -just released- CFW 4.21, along with more bug fixes, additions and improvements!

Since the flood of news about 4.21 we been swamped with traffic, so just getting on top of the latest and hottest releases. Enjoy!

* NEWS UPDATE 2:

Once again, 'Deank' and 'andbey0nd' have updated multiMAN, this time adding support for Hermes payload (SC-8) for Rogero's new 4.21 CFW v1.0, and more!

Here's the full changelog, info and download links for multiMAN 04.08.00 (3.41-4.21)

04.08.00

* Added proper support for [Hermes] for 4.21CEX ROGERO (SC-8)
* Fixed issue with loading split games from external USB HDD
* Improved support in lastGAME, gameDATA and bdRESET applications
========

multiMAN ver 04.08.00 BASE (20121023).rar (27.81MB)
Download Link --> http://http//www.sendspace.com/file/ek6smp

- For 3.41-4.21 CFW (CEX)
* multiMAN ver 04.08.00 BASE
* Showtime 4.1.200
* bdRESET
* gameDATA
* lastGAME
* stDISC

multiMAN ver 04.08.00 BASEPLUS (20121023).rar (107.39MB)
Download Link --> http://www.sendspace.com/file/zljl4k

- For 3.41-4.21 CFW
* multiMAN ver 04.08.00 BASE (CEX/DEX)
* Showtime 4.1.200 (CEX/DEX)
* bdRESET
* gameDATA
* lastGAME
* stDISC
* RetroArch (CEX)
* PC Applications

multiMAN ver 04.08.00 FULL (20121023).rar (280.68MB)
Download Link --> http://www.sendspace.com/file/gx7dup

- For 3.41-4.21 CFW
* multiMAN ver 04.08.00 FULL (CEX/DEX)
* Everything as in BASEPLUS + 8700 game covers + 2 motion backgrounds

Enjoy!
andbey0nd

p.s. Supported firmwares:

3.41 OFW + JB DONGLE
3.41 CFW HERMES
3.41 CFW REBUG
3.55 OFW DEX
3.55 CFW DEX
3.55 CFW KMEAW
3.55 CFW REBUG
3.55 CFW ROGERO
3.55 CFW TB
3.55 CFW COBRA
4.21 OFW DEX
4.21 CFW DEX
4.21 CFW CEX (all flavors)

* NEWS UPDATE:

Deank has already released multiMAN v04.07.01!!

Check out the full info below:

multiMAN ver 04.07.01 FULL (20121021) (280MB) --> *See below for DL Link*

* Includes all content from previous 04.07.00 FULL release (CEX+DEX)
+ New game covers
+ Updated gameDATA and lastGAME apps

+ multiMAN 04.07.01:
--- Updated 11 of the translations
--- Added support for Hermes payload for 4.21CEX CFW (SC-10)
--- Updated lastGAME app to version 3.00 (with Hermes support)
--- Updated gameDATA app to version 3.00

multiMAN and the accompanying tools now support all of the following firmwares:

3.41 OFW + JB DONGLE
3.41 CFW HERMES
3.41 CFW REBUG
3.55 OFW DEX
3.55 CFW DEX
3.55 CFW KMEAW
3.55 CFW REBUG
3.55 CFW ROGERO
3.55 CFW TB
3.55 CFW COBRA
4.21 OFW DEX
4.21 CFW DEX
4.21 CFW CEX

Enjoy and good luck...

DOWNLOAD LINK:

- multiMAN v04.07.01 FULL (20121021) (280MB)

* Original multiMAN v04.07.00 story:

multiMAN has received an update on both its CEX and DEX versions.

v04.07.00 brings additional support for the yet unreleased PS3 4.21 CFW, plus a couple of fixes in some features. Here's the full changelog:

- Added full support for BD - Mirror for games on internal HDD for 4.21 CFW
- Added support for 4.21 CFW CEX spoofed to 4.25
- Fixed an issue with loading PS1 disc backups
- Fixed some text typos and translation for "temperature" strings

Download Links:

- multiMAN v04.07.00 (CEX) - MIRROR 1 - MIRROR 2

- multiMAN v04.07.00 (DEX)

NEWS SOURCE #1: multiman 4.07.00 DEX released (via) PSX-Scene
NEWS SOURCE #2: multiMAN v04.06.02 & 4.06.03 DEX now available! (via) PS3Crunch

For more info and direct support remember to check our multiMAN support thread found right here on PS3Crunch!

Our thanks to 'Gauss' for keeping us update while we were busy handling the extra server traffic!