Sponsored Links

Sponsored Links

Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15



  1. #11
    Contributor marcob73's Avatar
    Join Date
    Sep 2007
    Posts
    11
    Sponsored Links
    Sponsored Links
    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.

  2. #12
    Banned User ggparallel's Avatar
    Join Date
    Nov 2007
    Posts
    13
    Sponsored Links
    Sponsored Links
    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

  3. #13
    Banned User ggparallel's Avatar
    Join Date
    Nov 2007
    Posts
    13
    Sponsored Links
    Sponsored Links
    Quote Originally Posted by marcob73 View Post
    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 .

  4. #14
    Registered User mainman9's Avatar
    Join Date
    Oct 2007
    Posts
    1
    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:

    [Register or Login to view links]

    ./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.

  5. #15
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    28,109

    PS3 eEID PlayStation 3 Flash Splitter by RMS is Released

    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/)

    [Register or Login to view code]

    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] [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)

 

Sponsored Links

Page 2 of 2 FirstFirst 12
Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News