Iplloader

iplloader (also known as PRE-IPL or BootROM) — is the first code to run on PSP main CPU.

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

Location

On retail PSP units, the iplloader is read from the Tachyon's Allegrex MIPS R4000 based SOC boot ROM. On DTP-T1000, the iplloader is loaded externally. See also #Behaviour.

The PSP main CPU is a custom-made Sony CPU with a MIPS32 core and has an embedded mask rom device (like most embedded systems do) which is exactly 4KB in size. This device holds the iplloader. This iplloader mask rom device is mapped to physical address 0x1FC00000 which is the address of reset exception vector on MIPS CPUs, and this is where the MIPS CPU starts executing from coldboot.

Structure

The BootROM is made up of two parts, the "bootstrap", and the "loader". It is located at physical address 0x1FC00000 and is accessed via non-cached kseg1. The ROM is accessed upon hardware reset, software reset, or NMI. When this occurs, the Status flags are set in the COP0 Status register with following bits set: Boot Exception Vector=1 and Error Level = 1. If its a hardware reset, Software Reset (SR) = 0, or if NMI or software reset it is 1. At this point the PC is set to 0xBFC00000 and it begins to execute instructions. Since this is currently in ROM mode, only registers can be modified.

Versions

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

Target	SDK Version / Tachyon Revision	Date (DD-MM-YYYY)	Payload Size	Hash
PSP (Retail/Testing Tool)	Tachyon 0x00140000-0x00300000	20-04-2004 (build date in ROM)	0xAF8	SHA-256: 48F4F11C383621C8569EC07273AE0AF6AD79681CF5B77263A69CF908EEFE4A53 (ROM)
PSP (Development Tool)	0.4.0	23-07-2004 (or older/last modified date for kbooti.bin)	n/a	SHA-256: 18B5BF7AEFE956D99B397AAAAC94DC965ADFDBC2BE0532096BBC1F8F8C5B7C34 (Full Binary)
PSP (Development Tool)	0.6.0	08-09-2004 (or older/last modified date for kbooti.bin)	n/a	SHA-256: 5CDEDDEBE11807DDAEB17BAC03945A0B828E8057C9587652CA207E3BB959AC96 (Full Binary)
PSP (Development Tool)	0.7.0	18-09-2004 (build date in the payload)	0x894	SHA-256: 351ECD64C945489999D477ECAFBFBB8FE769C2484636D2F7323557F7EEFD54A2 (payload only) SHA-256: 388FA1DB87973A2A37D576AAAB785D840CA4D883AB5111781DA2D0AF59CFE667 (Full rebuilt binary)
PSP (Development Tool)	0.9.0	15-10-2004 (build date in the payload)	0x894	SHA-256: 4F794E4FF32D5267AEAEDBA362D005EF0B7E93E29CF7C8209E0D9DBB0144F4DB (payload only) SHA-256: E415198C16E29D96C9232FF78272EE639D0630A56E370ED18A33D358FEF7CA95 (Full rebuilt binary)
PSP (Retail)	Tachyon 0x00400000-0x00500000	04-01-2005 (build date in ROM)	0xB30	SHA-256: 41B2578F84BDE33E09356F0170FF99E2417EA7B1D02BD9163A41AE61FE74C3A5 (ROM)
PSP (Development Tool)	2.6.0	22-10-2005 (build date in the payload)	0xBF4	SHA-256: 8821D96F5FB35C55DF649A97F5703F8A705362C2F54665B5EE4221E686B5578A (payload only) SHA-256: 0A83CB36F1FE7C2A9A53BD46E6FFD915D4D1BB97EED3D1EF336960DB752C3446 (Full rebuilt binary)
PSP (Development Tool)	2.7.1	14-02-2006 (build date in the payload)	0xBF4	SHA-256: F9160C03EC6174F54F1C1EB645CFBBDB65B3DA47DA1A5478BE30E5EB2B0852B4 (payload only) SHA-256: 7DDFF7093906C10BA11D7402E9939763173F1ADEA59A38B4006484FD18EA21EA (Full rebuilt binary)
PSP (Development Tool)	3.5.0	12-02-2007 (build date in the payload)	0xC74	SHA-256: AAF6F3CF0D7E028F43BE6FB788018F7A6F49B140A2591937B5C3A8373D2186A5 (payload including xor key) SHA-256: 5066E257EC43DA37788535C331E5A01955F5F498B103C340903409649BCB5046 (full rebuilt binary)
PSP (Retail)	Tachyon 0x00600000-0x00900000	10-09-2007 (build date in ROM)	0xCE8	SHA-256: E511D3DC78A209610F5B3EFEA2BC64BF86B9DF14A9C279C4499FECBFD70E6BF9 (ROM)
PS Vita	0.920.000 (inside PS Vita's Compatibility security module)	06-22-2010 (last modified date for compat_sm.self)	0x60	SHA-256: 98C8336C136DF901FC4EA38EB371AAF6F5402AC06574F107D3E2029BFC85CCAD (full binary)
PS Vita	0.930.010-0.995.000 (inside PS Vita's Compatibility security module)	08-17-2010 (last modified date for compat_sm.self)	0x2C0	SHA-256: 6D75EC720739C53228B1CA1AFF6CE073AE542BBB38FCC9B8710EC5EB3889B942 (full binary)
PS Vita	0.996.070-0.996.090 (inside PS Vita's Compatibility security module)	07-22-2011 (last modified date for compat_sm.self)	0xD34	SHA-256: E09B36DE655A441D2C94D39EF7BBC505EAB1722E9380EBE73E9E6A7DC88D9731 (full binary)
PS Vita	1.000.041-1.06 (inside PS Vita's Compatibility security module)	08-30-2011 (last modified date for compat_sm.self)	0xDB4	SHA-256: C2AE6939BC4B06CB4A81415E27EB1E7129C561B9C16C3AAFF6FDEBBAB48EBD09 (Full Binary)
PS Vita	1.50-1.81 (inside PS Vita Compatibility Security Module)	12-14-2011 (last modified date for compat_sm.self)	0xE34	SHA-256: 522851781DD82F89D69EBFE0F25C3E7CFE5899A53E850F2F979AD1B0E53376F9 (full binary)
PS Vita	2.00-2.05 (inside PS Vita's Compatibility security module)	11-16-2012 (last modified date for compat_sm.self)	0xE34	SHA-256: A9A097ED8925B83A210202AA4C943011C05FE48028BA6E05E85E1494143B0100 (full binary)
PS Vita	2.06-2.12 (inside PS Vita's Compatibility security module)	02-22-2013 (last modified date for compat_sm.self)	0xE34	SHA-256: 25E22C1D988609AA948F103E1312297F9533CA689B3C1BDC2CECBBC43997D566 (Full Binary)
PS Vita	2.50-3.01 (inside PS Vita Compatibility Security Module)	06-27-2013 (last modified date for compat_sm.self)	0xE34	SHA-256: 187DD28ADAD4167F3849392D570CA5A56DEEC608156D0EC6F2453958B1DB9672 (Full Binary)
PS Vita	3.10-3.20 (inside PS Vita's Compatibility security module)	12-05-2013 (last modified date for compat_sm.self)	0xE34	SHA-256: EF7D498295E416CCBD79FED78656E683DA1DCBC7B88C521DF0A1E00F5EC450FE (Full Binary)
PS Vita	3.30-3.35 (inside PS Vita's Compatibility security module)	09-25-2014 (last modified date for compat_sm.self)	0xE34	SHA-256: 7DF591C05BF66292B6868CE4331A1DC11B7A0E421D082971E9CA65C7236B6843 (Full Binary)
PS Vita	3.36-3.50 (inside PS Vita's Compatibility security module)	01-09-2015 (last modified date for compat_sm.self)	0xE34	SHA-256: 7E66976C311F5D3797A30B09DC608A0FA2E67EAA060097423CFD2E5FC89A57D9 (full binary)
PS Vita	3.51-3.55 (inside PS Vita's Compatibility security module)	05-12-2015 (last modified date for compat_sm.self)	0xE34	SHA-256: 6E869E08CCE41E0AA0D386DE8936F81F66CABB20B964C3EF2159548852F39F30 (full binary)
PS Vita	3.57-3.63 (inside PS Vita's Compatibility security module)	11-25-2015 (last modified date for compat_sm.self)	0xE34	SHA-256: 047366634210449C62FD813B3BFDA6267A1FA8683BA17901A214FC32E473A35F (full binary)
PS Vita	3.65-3.74 (inside PS Vita's Compatibility security module)	03-17-2017 (last modified date for compat_sm.self)	0xE34	SHA-256: B5EF4FB2C84D629B2BDC9A70A4B8E5A7EC31CD9EA330E309361C80A9A96B65C5 (full binary)

Behaviour

iplloader Boot Sequence

Part 1 (iplloader loader)

Because the BootROM is stored in non-volatile read-only memory, it cannot use any variable, so the bootstrap of the BootROM copies the loader BootROM (the payload) to the CPU's scratchpad RAM. It is the only RAM available at this time, along with another 4KB block of RAM and the 2MB EDRAM — normal DDR SDRAM has not been initialised yet.

The first thing checked is the 0xBC100000 value, if non-zero, it typically means a NMI exception and it either jumps to the exception vector in COP0 Control Register $9, or if that is not set, to the exception vector in COP0 Status Register $25. On a normal reset (hardware or software), the loader code of the ROM is copied to scratch pad at physical address 0x10000 in cached mode (0x80010000). At this point, it jumps to the real BootROM loader at 0x80010000. A stack is created at 0x80013FF0 as the top of the stack. This allows to the loader to use more typical local variables and memory in addition to registers.

Part 2 (iplloader payload)

The CPU is now executes the iplloader payload from the scratchpad RAM. The iplloader payload initializes the NAND hardware and reads the IPL NAND-block-table which is a table with the physical block numbers of the encrypted IPL's location on the NAND. That table is located at the 4th physical block of the NAND i.e. at offset 0x10000, and is repeated for the next 7 blocks. This is made so that if a bad block is met, the table can still be read. However, if all 8 blocks become bad blocks, it is a non-recoverable brick because the iplloader can no longer locate the IPL. The only solution to this problem is to either boot from Memory Stick instead, or use a custom IPL to patch the iplloader to remap the table. Both solutions require a Pandora battery.

If the SysCon has set 0xBE240004's 0x10 bit, the Memory Stick is used instead of the NAND for IPL loading.

The entire raw IPL is stored on the NAND encrypted. The iplloader payload uses a 4KB RAM as a temporary location to load and decrypt each encrypted IPL block. This RAM is mapped to physical address 0x1FD00000, but is later remapped to 0x1FC00000 to be used as the ME CPU reset exception vector. Because this RAM is only 4KB in size, the encrypted IPL is organised as 4KB blocks on the NAND. As the iplloader decrypts each of the 4KB IPL blocks, it loads the decrypted blocks to the IPL entry address 0x040F0000. This address is located in the 2MB EDRAM which is normally used as VRAM. Normal DDR RAM has not been initialised yet. When the iplloader has finished decrypting and loading all the encrypted IPL blocks, it jumps to the IPL entry address.

Memory mapping

The PSP iplloader is mapped to 0xBFC00000, which is the MIPS reset vector, i.e CPU initial program counter.

0.7.0 iplloader and onward are composed of two parts:

• a loader from 0xBFC00000 to 0xBFC0027F
• a payload from 0xBFC00280 and ending at the size specified at 0xBFC000034 (2 bytes with little endian order).

The PSP iplloader distributed in PS Vita System Software version 0.996 and onward has its payload starting at 0xBFC00180, rather than at 0xBFC00280 on previous PS Vita software and PSP hardware versions.

DevKit behaviour

bloadp

bloadp is used to send kbooti binaries (encrypted iplloader data from 0x0 to 0x1000 and IPL blocks at 0x1000) to the DTP-T1000.

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

If bloadp is never invoked, 0x1D700000 to 0x1D7FFFFF is uninitialized memory. It is cleared out as soon as bloadp is invoked.

Prototype 0.4.0-0.6.0 (23-07-2004 or older)

The prototype iplloader reads the IPL blocks in place from 0xBFE01000 and decrypts them to 0x88400000 before jumping there. Prototype IPL blocks do not contain metadata. Instead iplloader uses 0x88400000 as a hardcoded entry point (see code samples below). In fact the IPL payload, nested inside current IPL revisions and loaded by main.bin are using the prototype format, so the prototype iplloader loads the IPL payload directly.

It is also worthy of note that the prototype iplloaders for DEM-1000 (for 0.4.0 and 0.6.0 firmwares) do not make use of physical address 0xA0010000 as their payload location. The iplloader payload is instead executed in place at 0xBFC00000. As such the iplloader data is not wiped and can be dumped in its entirety using a custom IPL. Note that the IPL format is different than later revision IPLs: prototype IPLs are loaded in a single raw Kirk commmand 1 block.

// 0.4 iplloader
    }
    // 0xbfc00138
    function_bfc00178(100);
    uint32_t v9 = function_bfc00550(0x8400000, 0x1fe01000); // 0xbfc0014c
    // branch -> 0xbfc00154
    while (v9 < 0) {
        // 0xbfc00154
        // continue -> 0xbfc00154
    }
    // 0xbfc00158
    return unknown_88400000(-0x78000000, v8);
}

// 0.6 iplloader
    // 0xbfc00168
    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);
}

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.

2.60+ (22-10-2005)

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.

2.6.0 kbooti also appears to fix one of the iplloader flaws that allowed to load the Pandora time attacked block. It checks for the entrypoint not to be in the 0xb* range. However, it does not check for the data size of the block.

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

0x800100c4:   19 00 20 13   	beq 0x8001012c <entry_point+0x12c>, $zero, 0x8001012c <entry_point+0x12c>
0x800100c8:   00 00 00 00   	sll $zero, $zero, 0x0
0x800100cc:   8f 40 00 0c   	jal 0x8001023c <function_8001023c>
0x800100d0:   00 00 00 00   	sll $zero, $zero, 0x0
0x800100d4:   81 40 00 0c   	jal 0x80010204 <function_80010204>
0x800100d8:   00 00 00 00   	sll $zero, $zero, 0x0
0x800100dc:   c0 bf 04 3c   	lui $a0, 0xbfc0
0x800100e0:   21 28 00 00   	addu $a1, $zero, $zero
0x800100e4:   00 10 06 24   	addiu $a2, $zero, 0x1000
0x800100e8:   5a 41 00 0c   	jal 0x80010568 <function_80010568>
0x800100ec:   00 00 00 00   	sll $zero, $zero, 0x0
0x800100f0:   c0 bf 04 3c   	lui $a0, 0xbfc0 #0xbfc000000
0x800100f4:   01 80 05 3c   	lui $a1, 0x8001
0x800100f8:   30 09 a5 24   	addiu $a1, $a1, 0x930 #0x80010930
0x800100fc:   00 00 06 3c   	lui $a2, 0x0
0x80010100:   c0 02 c6 24   	addiu $a2, $a2, 0x2c0 #size of the data (0x2C0)
0x80010104:   50 41 00 0c   	jal 0x80010540 <function_80010540>

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. SHA-256: 1E6FC02124901F6F5A3F1BB02F065064C63E423D759A131BA1086EA8FC2D90AA

Development Tool Jig Memory Stick Emulation Mode

Starting from kbooti 0.7.0, a special Jig test mode exists. It reads an IPL block at 0x2000 on the Memory Stick instead of address 0xBFE01000 if the following condition is met:

   if ( MEMORY[0xBFEFFFFC] < 0 ) use MS

Indeed, writing 0xFFFFFFFF at 0xBFEFFFFC enables the pseudo service mode and reads the IPL block from the Memory stick. This mode is used by Sony engineers to debug Jig Memory Sticks by writing a kbooti using bloadp and then using reset parameters to set the flag at 0xBFEFFFFC using the sbootp param/arg from the reset command of either dstdb or bsreset (dspreset) such as follows: /usr/local/sony/bin/bootdispi/dspreset 80000000 (FFFEFFFF for example sets all boot flags to 0xFF), to set the DTP-T1000 into Jig emulation mode.

Because flags are incremental, the only way to clear the Jig flag using official SDK tools is to run the bloadp command again as this clears the whole tachsm0 memory including the flags.

Kbooti remains loaded in memory until the main unit is turned off or bloadp has ran again, allowing then to power cycle through different memory stick.

In kbooti revision 3.5.0, this mode skips the XOR step on the Kirk header. It overwrites the XOR key with zeroes in the scratchpad. That allows one to use a regular IPL block to achieve code execution and dump the iplloader payload.

Retail behaviour

The full reverse engineered assembly code can be found in uOFW: https://github.com/uofw/uofw/tree/master/src/preipl.

The loader

The loader part is almost the same for all retail iplloader versions.

ctc0($4, $v0); // save $v0
if (*0xBC100000 != 0) { // NMI interrupts enabled
    if (cfc0($9) != 0) { // NMI handler
        jump to $9;
    } else {
        $v0 = cfc0($4); // restore $v0
        // disable the BEV bit (on R4400, it moves the non-reset and NMI interruption handling to 0x80000000 instead of 0xBFC00200, but it may have a different behavior here)
        mtc0(Status, mfc0(Status) & 0xFFBFFFFF);
        jump to mfc0(EBase);
    }
} else {
    ctc0($9, 0); // reset NMI handler
    sceKernelL1IcacheInvalidateAll();
    sceKernelL1DcacheInvalidateAll();
    memcpy(0xA0010000, preipl_payload, preipl_payload_size);
    $sp = 0x80013FF0;
    sync();
    jump to 0x80010000;
}
// image ends with a copyright string, and a build timestamp: 0x20040420, 0x20050104 and 0x20070910 for successive iplloader versions

First version

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

Here is the pseudocode of the payload (not including implementation details, and excluding the information to interface with NAND & MemoryStick):

0xBC100058 |= 0x00800000; // Enable GPIO clock
0xBC100050 |= 0x0000608E; // Enable bus clock for AW (which is GE) (RegA, RegB, Edram), KIRK, NAND (EMCSM) and APB (for syscon?)
0xBC10004C &= ~0x408;     // Clear reset for AW and KIRK
0xBC100078 |= 2;          // IO enable NAND (EMCSM)
0xBE240000 &= ~0x10;      // Disable GPIO pin 4 output
0xBE240040 |= 0x10;       // Enable GPIO pin 4 input
sleep(1);                 // Wait a bit
0xBD500010 = 1;           // Initialize GE Edram
while (*0xBD500010 & 1 != 0) {} // Wait for the Edram to be initialized
0xBD500040 = 1;           // Finish initializing GE Edram

if (*0xBC100068 >> 16 != 0) { // Unknown bits
    *0xBC100078 |= 0x800; // Enable audio clock out??
} else {
    *0xBC10007C |= 0x10; // Enable GPIO pin 4 (used for jigkick)
}
sleep(10); // Wait a bit
int (*InitStorage)(void);
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)
    InitStorage = InitNand;
    ReadBlock = ReadNandBlock;
} else {
    InitStorage = InitMemoryStick;
    ReadBlock = ReadMemoryStickBlock;
}

u32 iplBlockIdx = 0;
u32 lastBlockChecksum = 0;

while (1) {
    // Read one IPL block (size 0x1000) from the NAND or MemoryStick
    if (ReadBlock(iplBlockIdx, 0xBFD00000) < 0) {
        while (1); // infinite loop
    }

    // Decrypt the block in-place
    if (Kirk1Decrypt(0xBFD00000, 0xBFD00000) < 0) {
        while (1);
    }

    // Read the decrypted block header
    u32 dstAddress   = *(u32*)0xBFD00000; // destination address for the decrypted data
    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)

    if (lastBlockChecksum != prevChecksum) {
        while (1);
    }

    if (dstAddress != 0) {
        // Copy the rest of the block at the specified address
        // The checksum is just the XOR of the 32-bit words of the data
        lastBlockChecksum = _memcpy(dstAddress, 0xBFD00010, dataSize);
    }

    if (entrypoint != 0) {
        dcacheWritebackInvalidateAll();
        icacheWritebackInvalidateAll();
        jump to entrypoint;
    }

    iplBlockidx++;
}

Second version

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 |= 0x0000608E; // (same) Enable bus clock for AW (which is GE) (RegA, RegB, Edram), KIRK, NAND (EMCSM) and APB (for syscon?)
0xBC100050 &= ~0x8E;      // (new ) Disable bus clock for AW (RegA, RegB, Edram) and KIRK
0xBC10004C &= ~0x408;     // (same) Clear reset for AW and KIRK
0xBC100050 |= 0x0000008E; // (new ) Re-enable bus clock for AW (RegA, RegB, Edram) and KIRK
0xBC100078 |= 2;          // (same) IO enable NAND (EMCSM)
0xBE240000 &= ~0x10;      // (same) Disable GPIO pin 4 output
0xBE240040 |= 0x10;       // (same) Enable GPIO pin 4 input
for (i = 0; i < 0x800; i++) { (void)*0xBC100040; } // (new) Read 0xBC100040 2048 times (unsure why)
sleep(1);                 // (same) Wait a bit
0xBD500010 = 1;           // (same) Initialize GE Edram
while (*0xBD500010 & 1 != 0) {} // (same) Wait for the Edram to be initialized
0xBD500040 = 1;           // (same) Finish initializing GE Edram

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)

• Blocks can be encrypted with KIRK commands 0~3 (in practice only command 1 is used)

• 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:

sha1(block[8:] + block[:8])

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.

PS Vita Compatibility mode behaviour

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

Then, compat_sm.self 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 pcbc.skprx kernel module.

Kirk command 1 is then used on the result. Unlike actual PSP units, the IPL is decrypting in a single large block, rather than in multiple blocks.

The 0x40 bytes key gets updated depending on the firmware version in use.

A 0x40 bytes XOR mask is also part of the 3.50+ DTP-T1000 security (see PSP iplloader section).

Dumper

As of March 21st 2018, a dumper for DTP-T1000 iplloader has been made by mathieulh, it is available on GitHub.

Trivia

On PSP iplloader versions 0.7 and later, the build number/date/version is copied from 0xBFC00FFC to ctc0 $17

lw      $t0, 0xBFC00FFC
ctc0    $t0, $17

See also

• Initial Program Loader
• iplloader and IPL descriptions by SilverSpring