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!
Yeah. I am starting to realize that sony was always like this about drm and restricting freedom of use. Its not that they went extreme with the ps3, they were always like this. They just never got it this right before.
The firmware has its own encryption system its not the same as the hdd i have already tried this.. also you can decrypt the hdd on newer consoles but the firmware is still written the same as it was on the old flash chips identical to the infectus dumps still worthless.
The question was: has anyone tried to decrypt /dev_flash[2|3] using HDD decryption method? I have seen data descrambled and rebuilt with this tool - /dev_flash was nicely readable but from certain point it was scrambled (encrypted)? What I propose is to take those scrambled data and have the PS3 they were taken from attempt to decrypt them as if it was part of the HDD.
Also on another topic: it seems (almost) every storage place has been made readable but nobody found where BD-J is implemented (so far no traces of java, jre, bd-j, *.jar, ...) . Any guess?