Sponsored Links

Sponsored Links

Page 1 of 2 12 LastLast
Results 1 to 10 of 15



  1. #1
    Member einzwei's Avatar
    Sponsored Links

    Arrow PS3 NAND Dump analysis

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

    and here is the report:

    [Register or Login to view code]

    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?

  2. #2
    Toucan Sam CJPC's Avatar
    Sponsored Links
    Sponsored Links
    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!

  3. #3
    Member einzwei's Avatar
    Sponsored Links
    Sponsored Links
    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...

  4. #4
    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.


    [Register or Login to view code]


  5. #5
    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?

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

    [Register or Login to view code]

    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:

    [Register or Login to view code]


  7. #7
    Quote Originally Posted by einzwei View Post
    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

  8. #8
    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

    Quote Originally Posted by ggparallel View Post
    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.

  9. #9
    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".

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

    look at following data:

    [Register or Login to view code]

    where:

    [Register or Login to view code]

    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.

 
Sponsored Links

Page 1 of 2 12 LastLast
Advertising - Affiliates - Contact Us - PS3 Downloads - PS3 Forums - Privacy Statement - Site Rules - Top - © 2015 PlayStation 3 News