Editing Iplloader
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 1: | Line 1: | ||
The iplloader, called "Lib-PSP iplloader" internally by Sony, also sometimes called PRE-IPL or BootROM, is the first code to run in PSP MIPS32 main CPU. Its role is to load the [[Initial Program Loader]]. iplloader contains the routines to boot into service mode and loads and decrypts the encrypted IPL from the NAND or Memory Stick. | |||
Its role is to load | |||
= Location = | = Location = | ||
| Line 194: | Line 192: | ||
== Memory mapping == | == Memory mapping == | ||
The PSP iplloader is mapped to | The PSP iplloader is mapped to 0xBFC00000 which is the reset vector of PSP's MIPS R4000 CPU. | ||
0.7.0 iplloader and onward are composed of two parts: | 0.7.0 iplloader and onward are composed of two parts: a loader from 0xBFC00000 to 0xBFC0027F and a payload from 0xBFC00280 and ending at the size specified at 0xBFC000034 (little endian 0x2 bytes). | ||
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. | 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. | ||
| Line 319: | Line 315: | ||
=== The loader === | === The loader === | ||
The loader part is almost the same for all retail | The loader part is almost the same for all retail PRE-IPL versions. | ||
<pre> | <pre> | ||
| Line 341: | Line 337: | ||
jump to 0x80010000; | jump to 0x80010000; | ||
} | } | ||
// image ends with a copyright string, and a build timestamp: 0x20040420, 0x20050104 and 0x20070910 for successive | // image ends with a copyright string, and a build timestamp: 0x20040420, 0x20050104 and 0x20070910 for successive PRE-IPL versions | ||
</pre> | </pre> | ||
=== First version === | === First version === | ||
This version of the | This version of the PRE-IPL 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): | Here is the pseudocode of the payload (not including implementation details, and excluding the information to interface with NAND & MemoryStick): | ||
| Line 419: | Line 415: | ||
=== Second version === | === Second version === | ||
This version of the | This version of the PRE-IPL 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: | It is very close to the original version, only some hardware initialization is modified, probably to improve stability/prevent crashes: | ||
| Line 443: | Line 439: | ||
=== Third version === | === Third version === | ||
This version of the | This version of the PRE-IPL 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. | It adds many security checks to avoid the creation of custom IPLs for these models — all of which have been broken since. | ||
| Line 472: | Line 468: | ||
==== Vulnerabilities ==== | ==== Vulnerabilities ==== | ||
Since the KIRK command 1 ECDSA private key & encryption key were known, the main issues for dumping the | Since the KIRK command 1 ECDSA private key & encryption key were known, the main issues for dumping the PRE-IPL 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 | The XOR keys are easy to disable if you can enable jigkick, which had been done for 03g before Davee dumped the PRE-IPL. (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. | 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 | 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 PRE-IPL 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. | 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. | ||
| Line 484: | Line 480: | ||
== PS Vita Compatibility mode behaviour == | == PS Vita Compatibility mode behaviour == | ||
On PS Vita, PSP iplloader is sent by the | 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). | ||
compat_sm then 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 on actual PSP units, the IPL is decrypted in a single large block rather than in multiple blocks. | |||
The 0x40 bytes key gets updated depending on the firmware version in use. | 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 | A 0x40 bytes XOR mask is also part of the 3.50+ DTP-T1000 security. See PSP iplloader section. | ||
= Dumper = | = Dumper = | ||
As of March 21st 2018, a dumper for DTP-T1000 iplloader has been made by mathieulh | As of March 21st 2018, a dumper for DTP-T1000 iplloader has been made available on github by mathieulh: | ||
* [https://github.com/mathieulh/DTP-T1000-Pre-IPL-dumper] | |||
= | = See also = | ||
* [https://web.archive.org/web/20090826053327/http://silverspring.lan.st/NPSPTD_01.txt iplloader and IPL descriptions by SilverSpring] | * [https://web.archive.org/web/20090826053327/http://silverspring.lan.st/NPSPTD_01.txt iplloader and IPL descriptions by SilverSpring] | ||