It comes with a Windows and Linux binary as well as source code, and those without an Infectus Mod can still experiment with it using the following 'dumpable dumps' files (via PS3 Infectus) available in irc://irc.blessed.net/ps3news when merged:
From the ReadMe file: This tool is used to interleave, then byteswaps both dumps of the PS3 NAND. Upon completion, it creates a 'user readable' file.
This file is then scanned by the tool, and the flash files are extracted to a folder. This folder is named PS3Nand-XXX.XXXX, where XXX.XXXX is the SDK Version magic in the flash (usually the version number of the firmware)
.B .A usually works, however in some cases .A .B order is required.
To clarify : Address of the FS is still hardcoded in this release so if you want to use a different dump I suggest to compile from source with different OFFSET that can be easy found reading the documentation in the source code. Relocation and FF blocks are not handled in this release.
CJPC : i'd like to add few informations for the community , fell free to delete it if it is not on topic.
The dump we took in consideration is a dump of a PS3 EU 1.5 . We did also analyze how an update gets written on the NAND FLASH using the 1.5 Firmware Update Package.
What we discover is that RL_FOR_PACKAGE.img and RL_FOR_PROGRAM.img are just copied as they are on NAND . No signing with a specific key , while CORE_OS_PACKAGE is instead kind of decompressed on NAND . Each Firmware Update contain a unique a specific header per file that describe date in which the file is created , header and file number in the case of the dev_flash_002.tar.aa* .
Files in both case are still encrypted ( on FW update and NAND to be clear ) so what you are dumping are encrypted files , key used is the cell cpu key that's why restoring a DUMP on a different PS3 console won't work.
Secure Design of the PS3 allows on boot decryption ( from NAND(?) to RAM ) of the first stage loader . Key store is probably accessible only dumping memory during on-boot sequence , before the spu got insolated from the rest of the system or ( speculation ) with a device that speaks directly with the cell processor in our case only RSX got such privilege.
Rambus and flex-io connection with the system is not documented at all ( apart brochure ) so man in the middle attacks / timing attacks are just a theory for now it will take a lot of time to understand better how the system works and how to setup such environment.
Also I'd like to remind that this works took all the PS3 News's DEVs few months in testing , bug fixing , and open mind sharing of ideas so if you have a contribution to make in terms of findings , ideas that make sense or documentations you want to share with us , please contact CJPC it will be very appreciated and of course smart people are always welcome in the team! :-)