PS3 NAND Dump analysis

[marcob73]

Please also note the samsungk9f1g08uoa_a.bin and samsungk9f1g08uoa_b_usb.bin files are 138,412,032 bytes length.

According to the device datasheet: "flash is 1Gbit with spare 32Mbit capacity."

138,412,032 bytes = 0x42000000 = 0x40000000 (1Gbit data) + 0x2000000 (32Mbit spare)

Write and erase operations on flash devices are always performed using data block to speed-up the operation. The Samsung k9f1g08uo have 0x20000 bytes block (128KByte).

This mean that every data block starting with 0xFF 0xFF 0xFF 0xFF data is unused and fully filled with 0xFF bytes.

ie:
0x00000000..0x0001FFFF - fully filled with 0xFF
0x00020000..0x0003FFFF - data

Just after merging the "samsungk9f1g08uoa_b_usb.bin" with the "samsungk9f1g08uoa_a.bin" you got your 264MBytes (128MBytes+4MBytes * 2) flash image.

Right now it seems that less then 50% of the flash image have valid data.

I will try to check it according to the einzwei's information.

Bye, Marco.

[ggparallel]

marcob73, einzwei , can you both join #ps3news on efnet so we will have a chat about the NAND , we spent much time on that and i'd like to keep both of you alligned on what we are sure and what we are not . Just not to reinvent the wheel.
My nickname is ggparall if you can't find me please speak with CJPC or another dev.
ciao

[ggparallel]

Please also note the samsungk9f1g08uoa_a.bin and samsungk9f1g08uoa_b_usb.bin files are 138,412,032 bytes length.

According to the device datasheet: "flash is 1Gbit with spare 32Mbit capacity."

138,412,032 bytes = 0x42000000 = 0x40000000 (1Gbit data) + 0x2000000 (32Mbit spare)

Write and erase operations on flash devices are always performed using data block to speed-up the operation. The Samsung k9f1g08uo have 0x20000 bytes block (128KByte).

This mean that every data block starting with 0xFF 0xFF 0xFF 0xFF data is unused and fully filled with 0xFF bytes.

ie:
0x00000000..0x0001FFFF - fully filled with 0xFF
0x00020000..0x0003FFFF - data

Just after merging the "samsungk9f1g08uoa_b_usb.bin" with the "samsungk9f1g08uoa_a.bin" you got your 264MBytes (128MBytes+4MBytes * 2) flash image.

Right now it seems that less then 50% of the flash image have valid data.

I will try to check it according to the einzwei's information.

Bye, Marco.

Correct

Please also take in consideration that this specific dump has only the default firmware on it in case of an upgrade the ps3 store the old firmware + the new one for recovery purpose . It is then fine to have just 50/100 ( more or less ) of nand space used.

My opinion is that fixed address ( the DEADBEEF thing ) is used in some way in order to find where the loading must start . It is still not clear ( at least to me ) where is the code to start the bootup process, i can't say this code must be in clear cause I have just few public documentation on the IBM secure loader ( ibm sdk v.3 contains some examples ) , which does not describe with source how the certificate is used , at which stage and if the loader is encrypted too.

As far as i know mainman was working yesterday on some kind of 0xFF blocks management and yes your supposition on 0xFF is indeed correct , in my opinion .

Still the sparse data need to be calculated ;-(

Please also any question or doubt feel free to ask .

[mainman9]

So, quite good that someone is working into this code. My apologies to have posted such incomplete code, but as i see was good startup for many of you. I was really busy last two months so I didn't work into.

einzwei: good work: you understand that you have files trunked, also i did. As i told you before, my code is incomplete and i didn't want to hardcode offset for recostruction. Instead i wanted to know how do "correct loading/remmapping" of the filesystem. Comparing this dump to others I descoverd also that offset of 'secureloader' directory (0x3F80200) is always in the same point but other directory record changes.. so that because i was stopped doing truncated-continues tool.. also we ( i and gg) we have extracted all files by had with hexeditor.

Also I have just started some analysis of files. I was searching for clear executable code. I did that search with very 'dirty' approach:

http://rafb.net/p/Wo65Im51.html

./compiled > test.asm
as test.asm
objdump -D a.out

(used binutils are for linux-ppc on minimac)
I searched for "nop" or "trap" instruction but nothing found...
... all other istruction i think are false-positive.

Ok we can extract files.. but that files are usufull?

if we have filesystem were is the program capable to read it ?
Maybe the bios? Maybe there is in nand ?
is crypted too?

If it is into, it isn't indexed with directory structures we found.

Bye

ps. you will use irc.

[PS3 News]

Recently PlayStation 3 hacker RMS has released some PS3 eEID flash Splitter code for other developers alongside an alternate method from eussNL below, as follows:

For those unaware, the PlayStation 3 eEID contains data including the PS3 system model data, target ID, motherboard revision and per-console values (console id, psid, etc.)

eEID splitter (rmscrypt.wordpress.com/2011/02/24/eeid-splitter/)

[c]#include <stdio.h>
#include <stdlib.h>

void
DumpEidData (FILE * pFile, int iInputSize, int iEidCount)
{
FILE *pOutput;
char szFileName[8];
char *szBuf;
int iRes, iSize;

printf("dumping EID%s from eEID at %p, size %d (%x)..\n",
iEidCount, pFile, iInputSize, iInputSize
);

szBuf = (char *) malloc (iInputSize + 1);

if (szBuf == NULL)
{
perror ("malloc");
exit (1);
};

iSize = fread (szBuf, iInputSize, 1, pFile);
sprintf (szFileName, "EID%d", iEidCount);
pOutput = fopen (szFileName, "wb");
iRes = fwrite (szBuf, iInputSize, 1, pOutput);

if (iRes != iSize)
{
perror ("fwrite");
exit (1);
};

free (szBuf);
}

int
main (int argc, char **argv)
{
FILE *pFile;

pFile = fopen (argv[1], "rb");
if (pFile == NULL)
{
printf ("usage: %s <eEID>\n");
exit (1);
}

fseek (pFile, 0×70, SEEK_SET);

DumpEidData (pFile, 2144, 0);
DumpEidData (pFile, 672, 1);
DumpEidData (pFile, 1840, 2);
DumpEidData (pFile, 256, 3);
DumpEidData (pFile, 48, 4);
DumpEidData (pFile, 2560, 5);
}[/c]

Below is an alternate method courtesy of eussNL via IRC:

[eussNL] commandline argument mk printf ("usage: %s <eEID> <EID name prefix>\n", argv[0]);
[eussNL] I dont really see much use for this tool, it just takes eEID from offset 2f000 NOR / 80800 (NAND) in snippets of 2144, 672, 1840, 256, 48, 2560 bytes and saves them as EID0, EID1, EID2, EID3, EID4, EID5...
[eussNL] http://www.ps3devwiki.com/wiki/Flash#eEID
[eussNL] if you need a specific offset, you can do the very same without a tool
[eussNL] see also http://www.ps3devwiki.com/wiki/Flash#Typical_EID_entry_addresses_and_lengths
[MK_] ahh Thx eussNL
[eussNL] so if EID2 is your target, then taking 0x002FB70 0x003029F would do the same
[eussNL] (NOR example)