Hacking NAND dump through multiman? How?

[codezer0]

Okay, so I see that Rogero put out a 4.30 CFW now... which has me interested. Thing is, so I was getting things ready to prepare to finally break down and update my CECHA ps3 from 3.55 kmeaw to this one, right? and one of the steps listed how I should "make a NAND/NOR dump through multiman". Only problem is, I don't see this option anywhere in multiman; I'm using 4.08.00 if that's any indication.

Needless to say, I am wondering where in the hell this ability to make a backup of my NAND is. And further, has anyone made a flasher that can freely backup and up/downgrade for the firmware of these BC systems? Only one I'm really aware of is the E3 flasher, and it seems to only be a no-solder solution for the neutered units.

 

[DinohScene]

Isn't there a homebrew that can dump the NAND of a PS3?
I know that for the 360 there is a NAND dumper that can dump 16MB NANDs + BB and SB Jaspers and Corona v2's (and possibly v3's)

 

[codezer0]

That's what I'm looking for. But it's strange because the instructions from Rogero regarding 4.30 CFW say rather explicitly that you can make your NAND(or NOR) dump through multiman. And I'm like "wait, really?" and looking everywhere in the app for said option to do so.

 

[pubert09]

I did a search and found this:

To dump NAND/NOR: mmOS->Select any file->Open in HEX viewer->[SELECT]->[START]->DUMP LV2(NO)->DUMP LV1(NO)->DUMP FLASH(YES)

 

[BadBBilly]

I did a search and found this:

To dump NAND/NOR: mmOS->Select any file->Open in HEX viewer->[SELECT]->[START]->DUMP LV2(NO)->DUMP LV1(NO)->DUMP FLASH(YES)

This method worked for me also, make sure you save this baby away safely....Never know when u may need it!!! Hopefully never will!!! *X fingers*

 

[codezer0]

Sorry to necro this thread up, but I just finally had time and the moment to take some time to give this a go. Finally updated multiman to 04.16.03 (interested in this stealth option, though that apparently can wait until such time I go beyond 3.55).

Given that the CECHA's were a 256MB NAND... wouldn't it make sense for the backup of the FLASH be 256MB's as well? because according to the dumper once it was done, that dump was only 239MB's.

 

[Twiffles]

To quote the PS3devwiki:

Masking by hypervisor on NAND consoles

software dumps: dump size = 239 MB (251,396,096 bytes)
bootldr not at 0x000000 on NAND :

00000000   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00000010   00 00 00 00 0F AC E0 FF  00 00 00 00 DE AD BE EF   .....¬à ÿ....Þ¾ï

reason:

addi    %r12, %r4, 0x200 # r4 = start sector

256MB NAND consoles have a hidden section of size 0x40000 (0x200 * 512 byte sector = 0x40000) hidden by the hv. The hv hides it at address 002786E8

To be able to dump that section, it needs to be unmasked, using poke

Original code : 0x39840200f8010090
Change to : 0x39840000f8010090

 

[Cyan]

I have few questions regarding NAND Dump by software:

Is it fine to bakup/restore that software dump with missing bootldr?

Or does it always require peek/poke before fully dumping/writing to NAND to prevent a brick?

The bootloader can change, right? so it's better to include it in dumps too.
Of course, you need to unmask it before restoring or you'll mess the data positions.

Is the dump with missing bootldr corectly validated by Flashtools? (Restoring a non valid dump is a very bad idea)


the wiki has a big warning, but it's only when modifying the lv1 physically, right? not when patching the memory with peek/poke?

How to peek/poke a specific addresses (which homebrew to use?) and be sure it's correctly patched before restoring the NAND?

After dumping (with Peek/poke) I guess you better shutdown the console, or poke the value back to prevent any indesirable effect as starting offset is different?

 

[codezer0]

Okay, but I thought I had peek/poke enabled in order to even be able to run multiman and stuff in the first place?

So how would I then get the full NAND backup?

 

[Cyan]

Having "peek/poke" means that you have access to "search/replace" functions to change a value in memory. (it's just different name for the same action).
to unhide that bootldr you need to search for the string 0x39840200f8010090 and replace the 0x02 by 0x00

doing so will set the starting sector at the right position (0x0000 instead 0x0200)
But by the look of the wiki, it seams it's a dangerous process.

So, if dumping/restoring an incomplete dump is fine it would prevent touching that memory value.
If someone can explain better than the Wiki, that will be great

 

[Madridi]

From what I understand, the incomplete dumps are just what's necessary to unblock your console if bricked. It's not a complete restore.