Editing Iplloader

<b>iplloader</b> <i>(also known as PRE-IPL or BootROM)</i> — is the first code to run on PSP main [[CPU]].

Its role is to load and decrypt encrypted [[Initial Program Loader]] from the [[NAND_Flash_Memory|NAND]] or [[Memory Stick]]. iplloader contains the routines to boot into service mode.

 

 

 

 

 

 

A few examples of iplloader payload sizes and hashes are listed in the following table.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

bloadp (through tachsm) initializes the 0x1D600000 memory (from /dev/mem or 0x00000000 from /dev/tachsm0 ; /dev/tachsm1 is mapped from 0x1D400000 to 0x1D5FFFFF) on the [http://www.psdevwiki.com/ps3/Communication_Processor Communication Processor] side (0x200000 in size, 0x100000 on the tachsm0 device) which is the DTP-T1000 PSP Shared memory, on the PSP/Tachyon side it is mapped to 0xBFE00000, it then writes the kbooti binary at 0x1D600000, however on SDK 0.5.0 and below dstdb (which bloadp was originally a part of), it was possible to specify the address to which kbooti would be loaded (default address to be specified was 0xbfc00000, the allowed range was 0xbfc00000-0xbfc10000), this in effect would write kbooti to 0x1D600000/0xBFE00000 + the address specific in the range -0xbfc00000, so for instance if 0xbfc02000 was specified, this would write kbooti to 0xBFE02000, keep in mind that the actual 0xBFC00000 memory mirrors itself every 0x1000 segments.

 

 

 

 

// 0.4 iplloader

    // 0xbfc00138

    function_bfc00178(100);

    uint32_t v9 = function_bfc00550(0x8400000, 0x1fe01000); // 0xbfc0014c

    // branch -> 0xbfc00154

    while (v9 < 0) {

        // continue -> 0xbfc00154

    return unknown_88400000(-0x78000000, v8);

// 0.6 iplloader

    function_bfc001b0(100);

    uint32_t v13 = function_bfc006b0(0x8400000, 0x1fe01000); // 0xbfc0017c

    // branch -> 0xbfc00184

    while (v13 < 0) {

        // 0xbfc00184

        // continue -> 0xbfc00184

    // 0xbfc00188

    return unknown_88400000(-0x78000000, v9, v10, v1);

</pre>

=== 0.7.0-2.50 (18-09-2004) ===

The 0.7.0+ iplloader copies its payload from 0xBFC000280 to 0x80010000 i.e. physical address 0xA0010000, and jumps there. Because on DTP-T1000 0xBFC00000 is writable during the iplloader execution, and because 0xBFD00000 is an invalid range on DTP-T1000, the payload uses the 0xBFC00000 memory, which originally contains the whole iplloader as work RAM. However, it does not wipe itself so the payload is dumpable from 0xA0010000, assuming that one has code execution at IPL time.

IPL blocks are then loaded from 0xBFE01000 by the iplloader and copied to 0xBFC00000 where they are decrypted in place and copied to the location of load address specified in the metadata.

Because a hash of the data stored between 0xBFC00040 and 0xBFC002C0 is used in an additional step by 2.60+ IPLs to decrypt main.bin, from 2.60 and onward the iplloader payload overwrites 0xBFC00000 with an identical copy of first 0x2C0 bytes of the original PSP-1000 (01g) iplloader ROM data. This data is stored at 0xBFC00BB0 in the 2.60 and 2.71 kbooti, 0x80010930 in the payload. The iplloader payload memsets 0x1000 bytes at 0xBFC00000 to 0 and writes the chunk there, before jumping to the IPL entrypoint. If bootstrapping the 1.50 firmware using the 2.60/2.71 iplloader part, data from the retail ROM addresses 0xBFC00200 to 0xBFC002C0 are retrievable. Note that this would not have been enough to generate the hash required to decrypt 2.60+ main.bin in any case and dumping using a custom IPL would be required to retrieve enough of the data even on a DTP-T1000.

Please note that starting from the 3.5.0 kbooti, the chunk of data written to 0xbfc00000 (which is hashed to be used as a seed for IPL part 2 decryption) changes and no longer matches any iplloader code. It is no longer code but random data.

The code that copies 0x2C0 bytes from 0x80010930 to 0xBFC0xxxx verbatim from the 2.6.0 iplloader payload:

Note that neither the 0xbfc00000 (on DTP-T1000) nor 0xa0010000 memory locations survive reboots.

=== 3.50 (12-02-2007) ===

The iplloader adds a step using a 0x40 bytes XOR key to decrypt the CMAC hash and data keys from the IPL block headers. As a result you cannot decrypt using Kirk command 1 the IPL blocks meant for the new iplloader.

The XOR key is overwritten early using a memset to 0 whenever the special Jig emulation mode is used (so the IPL block is xored by 0), this makes it impossible to obtain without glitching, knowing the kbooti CBC encryption key, knowing the xor key beforehand or using an IPL Loader exploit.

    if ( MEMORY[0xBFEFFFFC] < 0 )

    sub_800105F0(&unk_8001088C, 0, 64);

The seed for the IPL decryption (as it is used since 2.6.0) has changed to become a pseudo random 0x2C0 sized blob that is copied back from 0x800109B0 to 0xBFC00000 before jumping to the IPL entry point.

 

 

 

 

 

 

 

 

 

 

 

This version of the iplloader is used for Tachyon 0x00140000 to 0x00300000 (ie all versions of 01g except the few last).

if (*0xBC100068 >> 16 != 0) { // Unknown bits

sleep(10); // Wait a bit

int (*ReadBlock)(int blkIndex, void *destination);

if (*0xBE240004 & 0x10 == 0) { // Check GPIO pin 4 to decide if we boot from NAND or MemoryStick (ie jigkick)

u32 iplBlockIdx = 0;

    // Decrypt the block in-place

    if (Kirk1Decrypt(0xBFD00000, 0xBFD00000) < 0) {

        while (1);

    u32 dataSize    = *(u32*)0xBFD00004; // size of the decrypted data (excluding the header)

    u32 entrypoint  = *(u32*)0xBFD00008; // the entrypoint address if this is the last block, 0 otherwise

    u32 prevChecksum = *(u32*)0xBFD0000C; // checksum of the previous block (computed below)

        while (1);

    if (dstAddress != 0) {

        // The checksum is just the XOR of the 32-bit words of the data

        lastBlockChecksum = _memcpy(dstAddress, 0xBFD00010, dataSize);

    if (entrypoint != 0) {

        dcacheWritebackInvalidateAll();

        icacheWritebackInvalidateAll();

    iplBlockidx++;

This version of the iplloader is used by Tachyon versions 0x00400000 to 0x00500000. This corresponds to the last 01g motherboard versions, and all the 02g versions except the last.

It is very close to the original version, only some hardware initialization is modified, probably to improve stability/prevent crashes:

0xBC100058 |= 0x00800000; // (same) Enable GPIO clock

0xBC100050 |= 0x0000008E; // (new ) Re-enable bus clock for AW (RegA, RegB, Edram) and KIRK

sleep(1);                // (same) Wait a bit

There are also similar minor differences in the code to initialize MemoryStick hardware.

=== Third version ===  

This version of the iplloader is present on the last 02g model and all of the 03g+ models.

It adds many security checks to avoid the creation of custom IPLs for these models — all of which have been broken since.

List of changes:  

* IPL load address now blacklists the CPU Scratchpad range (address & 0x1FFF0000 != 0x00010000)

* The mode field of the KIRK headers must have their 16 MSB set to 0, or have their LSB set to 1 (ie mode & 0xFFFF0000 == 0, or mode & 0x00010000 == 1). The second case seems to mean the XOR keys have to be applied. The 16 MSB are erased before the KIRK command is actually ran

* IPL blocks now must have a minimum size of 0x100 bytes (including the 16-byte header)

* ECDSA verification (as specified in the KIRK header) must be enforced on the last KIRK-encrypted block

* The last 0x20 bytes of the block contain a SHA1 hash encrypted with KIRK command 7 and keyseed = 0x6C.

The block hash is calculated using: <pre>sha1(block[8:] + block[:8])</pre>

Which means the first 8 bytes of the payload (containing the first half of the block header) are copied to the end before the block is hashed.

The last block hash remains in memory and is xored in each SHA1 for each block, the result is used for the hash compare in the Kirk command 0x10 ECDSA check.

* The XOR of all the blocks' hashes (as computed in the previous step) is computed, and in the last block (entrypoint != 0), offset 0xFA0 contains a signature of this value, which is verified with KIRK command 0x11 using a custom public key stored inside the ROM (0xbc660611a70bd7f2d140a48215c096d11d2d4112, 0xf0e9379ac4e0d387c542d091349dd15169dd5a87).

* The first 0x10 bytes of IPL blocks are, before decryption, xored using a XOR key, stored in the ROM and selected from a value stored in the NAND spare data (see [[NAND Flash Memory]] for more details), or set to 0 for jigkick boot. If this value is zero, the XOR key step is skipped (probably to allow compatibility of the Jig Memory Stick across all devices). Otherwise, bits 0..4 of that value are used as an index on the XOR key table, and bits 5..11 are used as an additional rotation index. In practice, this value is 1 for all targets except 05g, and 05g uses the value 2.

==== Vulnerabilities ====

Since the KIRK command 1 ECDSA private key & encryption key were known, the main issues for dumping the iplloader were the XOR keys, the hash check, and the additional ECDSA check on the XOR of hashes.

The XOR keys are easy to disable if you can enable jigkick, which had been done for 03g before Davee dumped the iplloader. (Note that now that we know that it can be disabled writing the appropriate data in the NAND spare data, it could also be circumvented that way.)

The hash check would've been easy to solve, but the fact the block was rotated before being hashed was unknown. Davee glitched this check in order to pass.

For the additional check, it could be skipped using a clever trick: if you set 0xBC10004C as the destination address of the IPL block, then the CPU resets and remaps 0xBFD00000 to 0xBFC00000 then runs back at 0xBFC00000. Since 0xBFD00000 is used as a temporary space for the decrypted IPL, it means you can easily achieve code execution. Davee used this method to dump the iplloader payload, which contains all the relevant information.

Now that the code is known, the two first issues are very easy to handle. For the last one, an easy trick is that the signature is on the XOR of the SHA1's, which means if you place your own block twice before a legitimate IPL, the two SHA1's will cancel each other and the signature check will pass.

On PS Vita, PSP iplloader is sent by the <b>Compatibility Security Module</b> (<code>os0:sm/compat_sm.self</code>) to the non-secure ARM kernel, which writes it to <b>0xE8100000</b> (<i>named CompatSharedSram and mapped to the <b>0xBFC00000</b> reset vector on the emulated PSP/Tachyon side</i>).

Then, <code>compat_sm.self</code> sends a specific 0x40-bytes XOR key to be used by the PS Vita's iplloader as a 0x40 bytes XOR mask against the IPL header. The IPL is stored in the <code>pcbc.skprx</code> kernel module.