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:
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 :-)
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:
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.###
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 :-)
Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!
Well, the encrypted filesystem part of the flash is, in the PS3, labeled as /dev_flash , /dev_flash2 , /dev_flash3 (assumption on 2/3)
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.
Idea struck me now when replying post in other section: this tool was able to recover part of the flash's filesystem. The other part remained encrypted and was resisting attempts to break in. The question is: now when we have a way to decrypt the HDD - has anyone tried to decrypt that encrypted flash partition as if it was part of the HDD? I know chances are slim the same encryption is used for both HDD and flash but what if ...???
So NDT, your clarification, makes me wonder about that:
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