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.
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.
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.
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 .
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:
Below is an alternate method courtesy of eussNL via IRC:
[eussNL] commandline argument mk printf ("usage: %s <eEID> <EID name prefix>\n", argv);
[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] [Register or Login to view links]
[eussNL] if you need a specific offset, you can do the very same without a tool
[eussNL] see also [Register or Login to view links]
[MK_] ahh Thx eussNL
[eussNL] so if EID2 is your target, then taking 0x002FB70 0x003029F would do the same
[eussNL] (NOR example)