Custom IPL Released

by Mike Bendel August 26, 2007 @ 1:57 pm

Moonlight has released the very first custom IPL. It is an extension of the firmware 1.5 IPL and provides numerous features for programmers, as well as bypassing the TA-082+ key check.

What does it mean for end users? At this point, not so much. However, it does mean that in the future we could see a custom firmware independent of the 1.5 kernel.

Note: This program is intended for developers. Only run it if you know what you’re doing.

Download Custom IPL

Custom IPL sample [PS2Dev]

Feature for user:

– It bypasses ta-082+ brick, so you can have a ta-082+ without any key patched running 1.50 kernel based firmwares.

Feature for programmer:

– It dumps 0xbfc00000, the psp boot code prior to ipl, to the address 0x883e0000 (which is not touched by 1.50 kernel). To get the boot code in a 1.50 original firmware, just run kdumper, and extract 0x3e0000-0x3effff from the kmem.bin file -> that’s the psp boot code. If you are in a cfw, you will have to execute the kdumper as a recovery or autoboot, because the 3.XX kernel overwrites the 0x883e0000 memory.

Note that this ipl is flashed to the nand, not written to the ms.

Some info about the ipl, etc.

– The first instruction executed by the PSP at boot is 0xbfc00000. This memory address is not the same than the 0xbfc00000 that can be accesed when the system has booted.

– The memory is read only, so variables cannot be written. Because of this, the psp boot code copies code from itself to the scratchpad memory (0x80010000).

– There is memory section 0xbfd00000-0xbfd01000. This is the one that will be converted later in the 0xbfc00000 that programmers usually know.

– One of the first things SCE ipl’s do is to reset the main cpu. In the 1.50 ipl, this happen at address 0x040f0070-0x040f0084. When the cpu is reseted, what 0xbfc00000 memory was cannot be accesed anymore. The 0xbfd00000 memory gets remapped as 0xbfc00000, and 0xbfd00000 is now an invalid memory address.

– Since 2.60, SCE aproached that fact to encrypt their ipl’s: they used as a seed for a prng the 0xbfc00000 memory before the reset, to decrypt main.bin (main.gz), knowing that it would be impossible to dump it after the reset. They also played with the two meanings of 0xbfc00000 to cause confussion.
While it appeared to be an intelligent move to hide their ipl’s, it wasn’t really that intelligent: they made us to have much curiosity for that memory, and we didn’t stop until we dumped it :) That curiosity ended in service mode. If they hadn’t hidden their ipl’s… maybe Pandora wouldn’t exist today, who knows.

Follow this author on .