242w ago - Since today all the owners of a PS3 with
infectus could begin to experiment with the firmware patching.
Please share ideas questions and feedbacks in this thread comments, it would be appreciated.
Download:
PS3 NAND Flow Rebuilder v3.50 BETA
NDT ;-)
From ReadMe: PS3 NAND FLOW REBUILDER v3.50 (including ECC Algo by RPS).
This tool allows to unscramble the blocks of a PS3 dumps ordering them in a way that the dumps become readable and extractable!
It also allow you to re-scramble back to the original order once you modified the data you wants, then from now on it include the ECC recalculation algorithm that was private until today.
It's for study and tests purposes, for experienced people only (devs) that this way can manage the files inside the flashes and patch sensible areas.
In this updated version you'll find some good news:
1) You can now re-scramble back a modified dump in order to flash it in your console (ECC regeneration is now included).
2) Analyzer has some more informations (it's still alpha, i use it for debug, it's complete only for versions 2.40/2.41).
3) It automatically extract EID file in its own modules.
4) It show the (eventual) differences between the 2 bootloaders files
5) Save Console Attributes log file in the Log dump folder.
6) Support the 80 Gb Nand Dump extraction for study purpose (nand model is different and is one chip only).
USAGE:
- UNSCRAMBLE & INTERLEAVE FLASHES / RESCRAMBLE & DEINTERLEAVE FLASHES -
First of all select if you want to unscramble or re-scramble your dump.
The first option is the first you have to use, it unscramble your flashes and interleave them in order to obtain a readable and extractable dump.
Once you modified the unscrambled dump (you can swap files or change some data) the second one allow you to deinterleave the flashes rescrambling them as the original ones are (otherwise dump won't work).
- BYTE REVERSE AND EXTRACT AN 80GB DUMP FILE -
Our very own Courier dumped a 80Gb Flash yet! It's completly different from a 40/60 Gb dump, it's already interleaved.
With this option you can extracte the kernel files from this kind of dumps.
- FILE SELECTION -
"Flash 0" (TOP): Is the flash0 dump file, warning, many USA dumps use the way around names, so if your dump is USA you should try to load Flash1 here instead.
"Flash 1" (BOTTOM): Is the flash1 dump file, warning, many USA dumps use the way around names, so if your dump is USA you should try to load Flash0 here instead.
OUTPUT (INTERLEAVED) file: It's the interleaved file that the tool produce using the UNSCRAMBLE option.
INPUT (INTERLEAVED) file: It's the modified interleaved file from witch the tool rebuild the new flashes (0/1) that you need reflash on PS3.
- ANALYZER -
It's the option that add to the log what's contained in the flashes blocks, the info is in this format:
0000000000.00.01.120.15140.00000#0249 | 00000000.0.1.78.3B24.0000 ==> File-System Root
On the Left there is the OOB block unique data, on the right (after the ==>) there is the analysis, so what the block contains.
It's fully working only for dump versions 2.40/2.41 and it's very slow, it's an alpha debug option.
- GENERATE NEW ECC -
Using the Option "Re-scramble modified dump then de-interleave it into two new flashes." you can enable this flag, so the new modified and rescrambled flashes will have ECC fixed (thanks to RPS for the Algo).
- FORCE BAD BLOCKS ECC CALCULATION -
This option shouldn't be checked unless you know what you're doing!
PS3 don't expect the ECC of a bad block to be good, it's safer to keep it as it is.
- GENERATE AMOXIFLASH DIFF FILE -
Bushing is working on a feature for Amoxiflash (a tool to flash nands fo Wii, XBOX360 and PS3) that will allow you to flash only the differences from the original flash file.
This will allow you to save time while trying some ps3 hacks attempts :-)
INSTALL NOTE:
This tool need the .net framework 2.0 in order to work: most computers should have it installed yet, by the way here is the link in case you wonder where to get it:
microsoft.com/downloads/details.aspx?familyid=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en
NOTE:
ECC calculation (Algo by our very own RPS *you mate rocks!* ), is included in the tool this time, have fun pathing your firmware.
Stand-Alone tool (PS3NANDECC v1.30) was included in order to be used separately if you wish; The Algorithm is the same for Debug and Retail consoles.
###BEWARE: you need the external power addition to your Infectus mod in order to use it! Otherwise it's to risky, if you patch something bad your console won't boot anymore.###
GREETINGS:
I'd like to greet all the ppl that helped me in this work: ggparallel, RPS, Ein, CJPC, Courier and all the PS3News.com staff :-)
NDT ;-)
Removed more posts, will start issuing infractions with no further warning for people posting help questions in this thread. It's been mentioned nume...
Now, in an older ps3, all of the dev_flash was actually, on the flash (it was big enough)
However, on the NEW PS3's, that only have 16MB of Flash, 90% of that data is stored right on the HDD, so we can access it.
However (again), we have already accessed most (/dev_flash) of this data, with a TEST. It may help to compare Test->Retail differences, but that is about it.
The "Goodies" come in at dev_flash 2/3. But, since there is still 16MB of data on the flash (holding the bootloader, etc), the 2/3 of dev flash could just be reserved space for that - its all mostly speculation.
1. 2.10 (or maybe even below but I can't confirm that) introduces some kind of security that prevents flashing untouched previous dump
2. 2.10 can be downgraded by sdk version modification and fake upgrade to a lower fw
3. 2.17 can't be downgraded by sdk version modification and fake upgrade to a lower fw
It looks like after upgrade to 2.10 some kind of hash of system files is made and its written somewhere (but not in the NAND). When console boots, calculates such hash again and compares it with the saved one. If calculated one is different that saved one, console turns in panic mode. It prevents from flashing previous dump because hash of system files of lower fw is different that saved one calculated on 2.10.
But in 2.10 this hash calculation does not include the sdk version file, so it allows downgrade by modification of its contents. 2.17 includes sdk version file in hash calculation, so it prevents both of downgrade methods.
I think this aproach is more secure than saving only version of installed firmware. I also agree that calculated hash saving could be made by blowing an efuse.
It's only theory and needs more testing, but it looks logically consistent
When the devs say that 2.10 is ok to downgrade they say that it's ok using the sdkversion downgrade procedure and NOT restoring the previous dump with infectus.
It was one of the first hack attempt ggparallel tried, he downgraded just the sdk version in the dump then he tried a fake upgrade to a lower fw version and it worked.
I never tried this hack on my console because i had already updated it when i knew bout it