well now that in the US jailbreaking & rooting is LEGAL!!!!
im sure some really good reverse engineers will be starting to attack this thing....my buddy is part of the military (AF) & he & his group have a ps3 cluster running, so im sure those guys are going to dig into the system now, & crack it since its no longer illegal
Well - there is no way to be sure that your dump is correct. So I wouldn't try to decrypt something that most likely isn't encrypted at all.
If you connected the address or data lines in the wrong order for example, you will still read the correct amount of data but it will be useless garbage.
Since the NAND controller is attached to the SB the same way as the later 16 MiB NOR flash, the file you read from it should look the same as a 16 MiB NOR dump regarding file structure.
If somebody has a disassembled PS3 with a 16 MiB flash handy, it would be interesting to see if the same test points are still there. In this case you could just use a multimeter to map out the connections from the test points to the 16 MiB NOR pins. That should match the correct pin assignment for the NAND controller.
Hrm ... something doesn't add up with the description of the test points. To address 256 MiB with word access you'd need A0..27. With A0..17 you could only address 512 KiB
Last edited by sapperlott; 07-28-2010 at 03:53 PMReason: Automerged Doublepost
AFAIK the CXD4302GB is only the NAND controller. This chip makes the 2x 128MiB NAND flashes look like a single coherent NOR flash to the southbridge (SCC).
Notice how the southbridge didn't change (at least its part number) from the last model with 2x 128 MiB NAND to the first model with 16 MiB NOR flash?
So in theory it should have a somewhat similar pinout to the 16 MiB NOR flashes used in the newer models (Spansion S29GL128N90TFIR2 / Samsung K8Q2815UQB-P14B).
This chip handles all the crazy interleaving and shuffling around of the NAND pages. It is necessary so the SB sees a coherent NOR flash since you can't boot a system from NAND flash (because it doesn't support random access at a byte level). This is the reason why most embedded devices carry a small (expensive) NOR flash for the boot code and a large (inexpensive) NAND flash for data and applications.
So yes - it would make it far easier to tap into this chip with a microcontroller compared to tapping into the NANDs directly because one wouldn't have to mess around with all the interleaving and shuffling (the byte swap will stay, of course). But it's quite unlikely that this chip is another separate flash.
The most elegant solution would be to use the exploit to access the flash from Linux, though (what GeoHot appears to have done). That way you could just access the flash from Linux like any other block device.
No is true,the cxd(starship 2) is the real dev_flash whith partitions into,that flash have a raw is mounted...for it geo needed patch the raw for delete crypto and mount.
Dont is the same nandflash and devflash,devflash store the firmware modules and resources...nandflash loaders,hyper and the engine init system kernel(core_os).
If that were the case, why did the size of the flash change on the newer consoles? If what you believe is true, moving the dev_flash to HDD would only have eliminated the CXD4302GB chip, not shrunk the size of the "other" flash.
Reply With Quote
Originally Posted by sapperlott 
