PS3 NAND Dump analysis

[einzwei]

ok, I've looked through those 150.000 dumps with a mainman's tool.

and here is the report:

File: sdk_version size: 08 offset 0x9803C0;
File: lv1ldr size: 023B34 offset 0x00040400;980420
File: lv2ldr size: 01BA34 offset 0x00063f80;9A3FA0
File: isoldr size: 014174 offset 0x0007fa00;9BFA20
File: appldr size: 01F958 offset 0x00093b80;
File: default.spp size: 1D20 offset 0x000b34d8
File: lv0 size: 047318 offset 0x000b5200
File: lv1.self size: 161DC8 offset 0x000fc580
File: lv2_kernel.self size: 179720 offset 0x0025e348;F21E368- TRUNCATED;
File: spu_pkg_rvk_verifier.self size: 01A41C offset 0x003d7a68
File: spu_token_processor.self size: B75C offset 0x003f1e84
File: sc_iso.self size: 022DB8 offset 0x003fd5e0;2EFD600- TRUNCATED;0
File: aim_spu_module.self size: 9A68 offset 0x00420398;E603B8;
File: spp_verifier.self size: EFCC offset 0x00429e00;E69E20;
File: mc_iso_spu_module.self size: F050 offset 0x00438dcc;?????TRUNCATED?
File: me_iso_spu_module.self size: 0118FC offset 0x00447e1c;1207E3C;
File: sv_iso_spu_module.self size: 018CB8 offset 0x00459718;1219738;
File: sb_iso_spu_module.self size: CE98 offset 0x004723d0;12323F0;

there are two offsets on some files lines. First offset is what reported by tool. and second is what I'm sure is it's real offset in a merged dump file.

some of files appear to be truncated. - and that is strange! may be dump extractor does something wrong interleaving source files?

mainman, could you reply regarding some tech details of what's going on while merging those two files together?

Maybe we'll figure out something?

[CJPC]

The issue is that the tool,for the moment moves around some data in the flash to obtain a dump. It is not 100% perfect yet, and that may be the issue.

For tech details, just check the attached SRC, near the footer, it has all the code you need. The data is first byteswapped in each nand (in 512kb blocks) then interleaved If I recall!

[einzwei]

CJPC that's what I understood already, but studying other's source code is cumbersome
Cause If I got a tech Idea behind those swapping/interleaving I could build the tool myself...

[CJPC]

Well, nothing personal, theres a fully functional tool here, if you have any improvements, we would be glad to hear.

But the basic technical details are what I said, it interleaves the dumps (takes 512kb from A, then B, puts in the outfile, and repeats), and while its doing that it does a simple byteswap.

The bulk of the interleave/byteswap code is only a few lines, I've pasted them below, the rest in that function is file access for the most part.

		fread(intbuf,1,INTERLBYTECOUNT,nand1);
		fread(intbuf+INTERLBYTECOUNT,1,INTERLBYTECOUNT,nand2);
 
		// byteswapping
		for (i=0;i<(INTERLBYTECOUNT*2);i+=2) {
			tmp = intbuf[i];
			intbuf[i] = intbuf[i + 1];
			intbuf[i + 1] = tmp;
		}
 
		fwrite(intbuf,1,INTERLBYTECOUNT*2,output);

[einzwei]

Thanks CJPC. I've read the code already. Actually It does byteswapping and interleaving - only by 512 Bytes but not 512kb.
Sorry if I did not make my self clear.
But what I wanted to know - is what idea was behind those interleaving of files?
Why are these? Was it some kind of guess from your devs? Or was it found in datasheets on NAND flash ICs?
What information these 512 byte swaps are based on?

I'm asking this because I think there might be more necessary swaps - if for example there is an addressing bus scrambling on the ps3 mobo....
I can be wrong with this thow....
What do you think?

btw, I'd like to join #Ps3news. May be there we can chat with you devs on this subject?

[einzwei]

Here are my current findings
Most interesting parts so far are these:

1)
03F80200   00 00 00 01 00 00 00 09  00 00 00 00 00 EB FE 00   .............ëþ.
03F80210   00 00 00 00 00 00 06 00  00 00 00 00 00 04 00 00   ................
03F80220   61 73 65 63 75 72 65 5F  6C 6F 61 64 65 72 00 00   asecure_loader..
03F80230   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F80240   00 00 00 00 00 04 06 00  00 00 00 00 00 01 00 00   ................
03F80250   65 45 49 44 00 00 00 00  00 00 00 00 00 00 00 00   eEID............
03F80260   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F80270   00 00 00 00 00 05 06 00  00 00 00 00 00 00 08 00   ................
03F80280   63 49 53 44 00 00 00 00  00 00 00 00 00 00 00 00   cISD............
03F80290   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F802A0   00 00 00 00 00 05 0E 00  00 00 00 00 00 00 08 00   ................
03F802B0   63 43 53 44 00 00 00 00  00 00 00 00 00 00 00 00   cCSD............
03F802C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F802D0   00 00 00 00 00 05 16 00  00 00 00 00 00 00 20 00   .............. .
03F802E0   74 72 76 6B 5F 70 72 67  00 00 00 00 00 00 00 00   trvk_prg........
03F802F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F80300   00 00 00 00 00 05 36 00  00 00 00 00 00 00 20 00   ......6....... .
03F80310   74 72 76 6B 5F 70 6B 67  00 00 00 00 00 00 00 00   trvk_pkg........
03F80320   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F80330   00 00 00 00 00 05 56 00  00 00 00 00 00 02 A8 00   ......V.......¨.
03F80340   63 72 65 73 65 72 76 65  64 5F 30 00 00 00 00 00   creserved_0.....
03F80350   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F80360   00 00 00 00 00 07 FE 00  00 00 00 00 00 E0 00 00   ......þ......à..
03F80370   72 6F 73 00 00 00 00 00  00 00 00 00 00 00 00 00   ros.............
03F80380   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F80390   00 00 00 00 00 E7 FE 00  00 00 00 00 00 04 00 00   .....çþ.........
03F803A0   63 76 74 72 6D 00 00 00  00 00 00 00 00 00 00 00   cvtrm...........
03F803B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
2)
03F80800   00 00 00 01 00 00 00 01  00 00 00 00 00 04 00 00   ................
03F80810   00 00 00 00 00 00 00 40  00 00 00 00 00 00 ED E0   .......@......íà
03F80820   6D 65 74 6C 64 72 00 00  00 00 00 00 00 00 00 00   metldr..........
03F80830   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
3)
01A40020   00 00 00 01 00 00 00 13  00 00 00 00 00 6F FF E0   .............oÿà
01A40030   00 00 00 00 00 00 03 A0  00 00 00 00 00 04 00 00   ....... ........
01A40040   63 72 65 73 65 72 76 65  64 5F 30 00 00 00 00 00   creserved_0.....
01A40050   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A40060   00 00 00 00 00 04 03 A0  00 00 00 00 00 00 00 08   ....... ........
01A40070   73 64 6B 5F 76 65 72 73  69 6F 6E 00 00 00 00 00   sdk_version.....
01A40080   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A40090   00 00 00 00 00 04 04 00  00 00 00 00 00 02 3B 34   ..............;4
01A400A0   6C 76 31 6C 64 72 00 00  00 00 00 00 00 00 00 00   lv1ldr..........
01A400B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A400C0   00 00 00 00 00 06 3F 80  00 00 00 00 00 01 BA 34   ......?€......º4
01A400D0   6C 76 32 6C 64 72 00 00  00 00 00 00 00 00 00 00   lv2ldr..........
01A400E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A400F0   00 00 00 00 00 07 FA 00  00 00 00 00 00 01 41 74   ......ú.......At
01A40100   69 73 6F 6C 64 72 00 00  00 00 00 00 00 00 00 00   isoldr..........
01A40110   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A40120   00 00 00 00 00 09 3B 80  00 00 00 00 00 01 F9 58   ......;€......ùX
01A40130   61 70 70 6C 64 72 00 00  00 00 00 00 00 00 00 00   appldr..........
01A40140   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A40150   00 00 00 00 00 0B 34 D8  00 00 00 00 00 00 1D 20   ......4Ø....... 
01A40160   64 65 66 61 75 6C 74 2E  73 70 70 00 00 00 00 00   default.spp.....
01A40170   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A40180   00 00 00 00 00 0B 52 00  00 00 00 00 00 04 73 18   ......R.......s.
01A40190   6C 76 30 00 00 00 00 00  00 00 00 00 00 00 00 00   lv0.............
01A401A0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A401B0   00 00 00 00 00 0F C5 80  00 00 00 00 00 16 1D C8   ......Å€.......È
01A401C0   6C 76 31 2E 73 65 6C 66  00 00 00 00 00 00 00 00   lv1.self........
01A401D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A401E0   00 00 00 00 00 25 E3 48  00 00 00 00 00 17 97 20   .....%ãH......— 
01A401F0   6C 76 32 5F 6B 65 72 6E  65 6C 2E 73 65 6C 66 00   lv2_kernel.self.
01A40200   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A40210   00 00 00 00 00 3D 7A 68  00 00 00 00 00 01 A4 1C   .....=zh......¤.
01A40220   73 70 75 5F 70 6B 67 5F  72 76 6B 5F 76 65 72 69   spu_pkg_rvk_veri
01A40230   66 69 65 72 2E 73 65 6C  66 00 00 00 00 00 00 00   fier.self.......
01A40240   00 00 00 00 00 3F 1E 84  00 00 00 00 00 00 B7 5C   .....?.„......·\
01A40250   73 70 75 5F 74 6F 6B 65  6E 5F 70 72 6F 63 65 73   spu_token_proces
01A40260   73 6F 72 2E 73 65 6C 66  00 00 00 00 00 00 00 00   sor.self........
01A40270   00 00 00 00 00 3F D5 E0  00 00 00 00 00 02 2D B8   .....?Õà......-¸
01A40280   73 63 5F 69 73 6F 2E 73  65 6C 66 00 00 00 00 00   sc_iso.self.....
01A40290   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
01A402A0   00 00 00 00 00 42 03 98  00 00 00 00 00 00 9A 68   .....B.˜......šh
01A402B0   61 69 6D 5F 73 70 75 5F  6D 6F 64 75 6C 65 2E 73   aim_spu_module.s
01A402C0   65 6C 66 00 00 00 00 00  00 00 00 00 00 00 00 00   elf.............
01A402D0   00 00 00 00 00 42 9E 00  00 00 00 00 00 00 EF CC   .....Bž.......ïÌ
01A402E0   73 70 70 5F 76 65 72 69  66 69 65 72 2E 73 65 6C   spp_verifier.sel
01A402F0   66 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   f...............
01A40300   00 00 00 00 00 43 8D CC  00 00 00 00 00 00 F0 50   .....C�Ì......ðP
01A40310   6D 63 5F 69 73 6F 5F 73  70 75 5F 6D 6F 64 75 6C   mc_iso_spu_modul
01A40320   65 2E 73 65 6C 66 00 00  00 00 00 00 00 00 00 00   e.self..........
01A40330   00 00 00 00 00 44 7E 1C  00 00 00 00 00 01 18 FC   .....D~........ü
01A40340   6D 65 5F 69 73 6F 5F 73  70 75 5F 6D 6F 64 75 6C   me_iso_spu_modul
01A40350   65 2E 73 65 6C 66 00 00  00 00 00 00 00 00 00 00   e.self..........
01A40360   00 00 00 00 00 45 97 18  00 00 00 00 00 01 8C B8   .....E—.......Œ¸
01A40370   73 76 5F 69 73 6F 5F 73  70 75 5F 6D 6F 64 75 6C   sv_iso_spu_modul
01A40380   65 2E 73 65 6C 66 00 00  00 00 00 00 00 00 00 00   e.self..........
01A40390   00 00 00 00 00 47 23 D0  00 00 00 00 00 00 CE 98   .....G#Ð......Θ
01A403A0   73 62 5F 69 73 6F 5F 73  70 75 5F 6D 6F 64 75 6C   sb_iso_spu_modul
01A403B0   65 2E 73 65 6C 66 00 00  00 00 00 00 00 00 00 00   e.self..........

They are some kind of "file directory" records.
Let's see in more detail their structure

First goes 00 00 00 01- 32 bit value - some flag possible?
next goes 00 00 00 09 - number of directory entries, 9, 1, 19 respectively.
next goes 00 00 00 00 00 EB FE 00 - seemingly 64 bit relative pointer to next free memory area
after this there are file entries

00 00 00 00 00 00 03 A0 - 64 bit relative pointer to the file data
00 00 00 00 00 04 00 00 - 64 bit file size
63 72 65 73 65 72 76 65 64 5F 30 00 00 00 00 00 'creserved_0'..... - ASCII file name padded with 0's to 32 bytes

actual files seem to be 4 byte aligned

It is very likely that those relative pointers are computed as an offset from start of 'directory structure' - that is seemingly correct with 2).
- at 0x40 offset there is some data of exact 0xEDE0 length.

the thing is, currently our dump needs additional block swapping to correspond to my speculation

also there is one very interesting data:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

08580000   53 43 45 49 56 54 52 4D  00 00 00 00 00 00 00 E8   SCEIVTRM........
08580010   00 00 00 00 00 E8 02 00  00 00 00 00 00 00 00 28  
08580020   00 00 00 00 56 54 52 4D  00 00 00 00 00 00 00 04  ....VTRM........
08580030   8A 32 2E 89 73 09 DD 11  EE 11 CC AC D3 F0 B4 
08580040   F6 F8 40 63 00 00 00 00  00 00 00 00 00 E8 02 28  
08580050   00 00 00 00 00 00 00 18  00 00 00 00 00 00 04 90   
08580060   00 00 00 00 00 00 09 20  00 00 00 00 00 00 00 01 
08580070   00 00 00 00 00 E8 17 30  00 00 00 00 00 00 00 08 
08580080   00 00 00 00 00 00 09 20  00 00 00 00 00 E8 27 20  
08580090   00 00 00 00 00 00 00 60

[ggparallel]

btw, I'd like to join #Ps3news. May be there we can chat with you devs on this subject?

yes we usually meet in a specific channel , ask CJPC for details , for which regard the tool remember that we are not taking in cosideration atm the FF blocks which in my opinion is part of the puzzle; sparse management is another point too . Interleaving and byteswapping is just fine as it is , PS3 read the NAND in that way , all work is done with reverse enginering no magic guide :-( and we released the code for having more devs working on it , so any addition to it please add specific comment per instruction of what it does and reference in order to make everyone alligned .

ciao

[einzwei]

Here is my current progress in dump research.
Directory reconstruction:

Directory record at 0x1A40020.

!File: creserved_0 size: 040000 offset 0x000003a0;1A403c0; -filled with 0xFF
!File: sdk_version size: 08 offset 0x0403A0;0x9803C0; "150.000"
!File: lv1ldr size: 023B34 offset 0x00040400;980420
!File: lv2ldr size: 01BA34 offset 0x00063f80;9A3FA0
!File: isoldr size: 014174 offset 0x0007fa00;9BFA20-truncated at 9C0000;-continues at 2A00000
!File: appldr size: 01F958 offset 0x00093b80;2A13BA0;
!File: default.spp size: 1D20 offset 0x000b34d8;2A334f8;
!File: lv0 size: 047318 offset 0x000b5200;2A35220;-truncated at 2A40000;-continues at 4A80000;
***File: lv1.self size: 161DC8 offset 0x000fc580;4ABC5A0; -truncated at 4AC0000 ; continues at ,, last part at F200000;
***File: lv2_kernel.self size: 179720 offset 0x0025e348;F21E368;- truncated at F240000; - continues at ,, last part at 2EC0000;
!File: spu_pkg_rvk_verifier.self size: 01A41C offset 0x003d7a68;2ED7A88;
!File: spu_token_processor.self size: B75C offset 0x003f1e84;2EF1EA4;
!File: sc_iso.self size: 022DB8 offset 0x003fd5e0;2EFD600;- Truncated at 2f00000; continues at E40000;
!File: aim_spu_module.self size: 9A68 offset 0x00420398;E603B8;
!File: spp_verifier.self size: EFCC offset 0x00429e00;E69E20;
!File: mc_iso_spu_module.self size: F050 offset 0x00438dcc;E78DEC;- Truncated at E80000; continues at 1200000;
!File: me_iso_spu_module.self size: 0118FC offset 0x00447e1c;1207E3C;
!File: sv_iso_spu_module.self size: 018CB8 offset 0x00459718;1219738;
!File: sb_iso_spu_module.self size: CE98 offset 0x004723d0;12323F0;

*** - File needs additional reconstruction - some 256Kb segments missed.

Directory record at 0x3F80200.

!File: asecure_loader size: 0x40000 offset 0x00000600;3F80800; - this is actually a directory structure- not a file.
!File: eEID size: 10000 offset 0x040600;4480800;
!File: cISD size: 0800 offset 0x050600;4490800;
!File: cCSD size: 0800 offset 0x050E00;4491000;
!File: trvk_prg size: 2000 offset 0x051600;4491800;
!File: trvk_pkg size: 2000 offset 0x053600;4493800;
!File: creserved_0 size: 2A800 offset 0x055600;4495800; - filled with 0xFF
****File: ros size: E00000 offset 0x07FE00; ----------------- realtime OS??
!File: cvtrm size: 40000 offset 0x0E7FE00;8580000;

**** - File is too big and fragmented to be found easy

Directory record at 0x3F80800 - asecure_loader
!File: metldr size: EDE0 offset 0x40;3F80840; the rest of reserved space is zeroed.

I see that there must be some 256Kb block swapping. Maybe you've already see some pattern in this layout.
It should be possible to find other files as well knowing that pattern

yes we usually meet in a specific channel , ask CJPC for details ...............the FF blocks which in my opinion is part of the puzzle; sparse management is another point too . Interleaving and byteswapping is just fine as it is , PS3 read the NAND in that way , all work is done with reverse enginering no magic guide :-( and we released the code for having more devs working on it , so any addition to it please add specific comment per instruction of what it does and reference in order to make everyone alligned .

I tryed to DCC Chat CJPC - no success

As to FF blocks - I think they are for alignment purposes - it's clearly seen at directory #2 - creserved_0 - perfectly aligns ROS on 512k boundary.

regarding source - currently I have no any compiler set up to write code....
all my research was done solely with WinHex for now.

[CJPC]

My mistake on the KB, a habit i suppose. Furthermore, I got your message, but you were offline when I replied, Drop me another message!

About the interleave, call it smart developers. We knew since it was not in the clear, and it made sense that many consumer electronics with multiple flashes tend to interleave there data, and it helps with the whole "security through obscurity".

[marcob73]

Hi guys,
not sure you already got this...

look at following data:

03F80210   00 00 00 00 00 00 06 00 00 00 00 00 00 04 00 00   ................
03F80220   61 73 65 63 75 72 65 5F  6C 6F 61 64 65 72 00 00   asecure_loader..
03F80230   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F80240   00 00 00 00 00 04 06 00  00 00 00 00 00 01 00 00   ................
03F80250   65 45 49 44 00 00 00 00  00 00 00 00 00 00 00 00   eEID............
03F80260   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................


03F80210   aa aa aa aa aa aa aa aa  bb bb bb bb bb bb bb bb   ................
03F80220   61 73 65 63 75 72 65 5F  6C 6F 61 64 65 72 00 00   asecure_loader..
03F80230   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
03F80240   cc cc cc cc cc cc cc cc dd dd dd dd dd dd dd dd   ................
03F80250   65 45 49 44 00 00 00 00  00 00 00 00 00 00 00 00   eEID............
03F80260   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

where:

cc cc cc cc cc cc cc cc = aa aa aa aa aa aa aa aa + bb bb bb bb bb bb bb bb

it seem "cc cc cc cc cc cc cc cc" is offset while "bb bb bb bb bb bb bb bb" is len.

Hope this help,
Ciao, Marco.