Results 1 to 5 of 5

Thread: some questions about pre-IPL

  
  1. #1
    Nightmare-Rex is offline -Hacks Smarty
    Join Date
    Aug 2009
    Posts
    172
    Rep Power
    10

    Default some questions about pre-IPL

    ok I know pre-IPL is wats stopping the PSP 3000, 2000 V3, and Go! from being hacked.
    is the pre-ipl an acoual code like sony 19403 in a text document? or is it wired .PRX and .RCO files? how was the pre ipl dumped for the phat? how was it domped for slim? how was pandora discoverd?


  2. #2
    Rob S.'s Avatar
    Rob S. is offline Senior Member -Hacks Titan
    Join Date
    Jan 2006
    Location
    41° 11' 3" N / 73° 8' 1" W
    Posts
    7,695
    Rep Power
    50524

  3. #3
    Nightmare-Rex is offline -Hacks Smarty
    Join Date
    Aug 2009
    Posts
    172
    Rep Power
    10

    Default

    ok thanks for the pandora. but I allready know that about the pre-IPL I want to know what the acual "pre-IPL" file looks like. and how was it dumped on the 2000 and 1000?

  4. #4
    Rob S.'s Avatar
    Rob S. is offline Senior Member -Hacks Titan
    Join Date
    Jan 2006
    Location
    41° 11' 3" N / 73° 8' 1" W
    Posts
    7,695
    Rep Power
    50524

    Default

    Quote Originally Posted by Nightmare-Rex View Post
    how was it dumped on the 2000 and 1000?

    I believe it was originally dumped on the 1000 using UP (Dual nand mod).


    For the 2000, devs found a multitude of flaws in the pre-ipl and kirk engine (hardware used to make cryptographic operations in the PSP), which allowed them to launch their own IPL.

    Quote Originally Posted by Nightmare-Rex
    I want to know what the actual "pre-IPL" file looks like.

    preipl is the boot code implemented within the processor.

    It is 100% plaintext.

    See an example of Preipl pseudocode below:






    Quote Originally Posted by SilverSpring View Post
    How the decryption works is this, the data is first encrypted and then the encrypted data is signed. When passed to the crypto engine, first it checks the signature and if it's valid it will decrypt the data (algorithms for both the encryption & signature are unknown, not that I know of anyway, maybe someone knows...or not :p).

    The fake encrypted data is bruteforced to decrypt into your chosen data (to be able to exploit the preipl). And the signature for your fake encrypted data is bruteforced again to make it appear valid in the eyes of the crypto engine so that it will will go ahead and decrypt your fake encrypted data.

    The preipl exploit works like this:

    First a decrypted ipl block:
    0x00: load address
    0x04: data size
    0x08: entry address
    0x0C: checksum of previous block
    0x10: data

    A typical example might be
    0x040F1EA0
    0x00000F50
    0x00000000
    0xB71C6EBA
    ...data...

    Which means load 0xF50-byte data to 0x040F1EA0. 0xB71C6EBA is the checksum of the previous block. Then entry address is 0 since it hasnt reached the end yet and there are more blocks to load. Once it has loaded all the ipl blocks the very last block will have entry address of where the whole ipl has been loaded (typically 0x040F0000). And will then jump to that address.

    Preipl pseudocode for loading & decrypting the ipl:
    Code:
        int iplBlockNumber = 0;
        u32 checksum = 0;
    
        // load/decrypt all encrypted ipl blocks
        while(1)
        {
            // copy an encrypted ipl block to 0xBFD00000-0xBFD01000 (4KB embedded cpu ram)
            if (LoadIplBlock(iplBlockNumber, block) < 0)
                while(1);
    
            // decrypt the ipl block in place (uh oh...)
            if (DecryptIplBlock(block, block))
                while(1);
    
            // first block will have zero as its checksum since there is no previous block (another uh oh...)
            if (block->checksum != checksum)
                while(1);
    
            // load the 'data' section of the ipl block to the specified address (0x040Fxxxx range)
            if (block->loadaddr)
                checksum = memcpy(block->loadaddr, block->data, block->blocksize);
    
            // reached the end of the ipl, jump to the entry address (0x040F0000)
            if (block->entry)
            {
                // clear caches
                Dcache();
                Icache();
    
                // jump to ipl - do not return
                block->entry();
            }
    
            iplBlockNumber++;
        }
    As the preipl loads the first ipl block (the fake one), it decrypts the block in-place, ie. the decrypted block just overwrites your encrypted block. The fake block only decrypts into four bytes of all 0's so it ends up only overwriting the first four bytes of your fake block (with four 0's) after decryption.

    The fake signed block:

    Code:
    00000000: 00 00 00 00 00 00 00 00 00 01 D0 BF 00 00 00 00
    00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00000020: 52 A1 05 CD 3A 52 59 28 0A D1 31 F1 BD 87 2E CC
    00000030: 14 DA 02 2F 77 88 C7 66 F3 32 07 BD 1A 08 9E 4C
    00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00000060: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00000070: 04 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
    00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    000000A0: 00 00 00 00 00 00 00 00 00 00 00 01 C6 5F 74 12
    The most important parts to note:
    0x20-0x3F is the bruteforced hash signatures
    0xA0-0xAF is the bruteforced encrypted data
    0x70-0x73 is the size of the decrypted data (only 4 bytes)

    A slight flaw in the crypto engine allowed the bruteforce to be performed on a magnitude-times smaller scale than normally required.

    After decryption, the preipl thinks the data is now a decrypted ipl block.
    So note the first 0x10 bytes:
    0x00000000 (load address which was faked to four 0's when decrypted)
    0x00000000 (size of the block to load, none)
    0xBFD00100 (the entry address, the most important part, where your unsigned code is located)
    0x00000000 (checksum)

    It passes the checksum test (with 0x00000000), it skips the loading of any data (since the loadaddr has been faked to 0x00000000), see's the entry address of 0xBFD00100 and thinks it has reached the end of the ipl and so goes jumps to that address (which is where your unsigned code will be).

    So that's essentially it in a nutshell. But dont let a quick 5 min. summary of the exploit underestimate the enourmous effort involved in bringing it to fruition (as the final product known as Pandora).

  5. #5
    Nightmare-Rex is offline -Hacks Smarty
    Join Date
    Aug 2009
    Posts
    172
    Rep Power
    10

    Default

    does that mean hackers can try random codes in that format foe 2000V3/3000V1/go!v1?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •