Editing PRE-IPL

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

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:
<b>iplloader</b> <i>(also called PRE-IPL or BootROM, as [[Sony]] calls it internally)</i> — is the first code to run on PSP main [[CPU]].
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 and decrypt encrypted [[Initial Program Loader]] from the [[NAND_Flash_Memory|NAND]] or [[Memory Stick]]. iplloader contains the routines to boot into service mode.


= Location =
= Location =
Line 85: Line 83:
| style="background:#C3F500" | PSP (Retail)
| style="background:#C3F500" | PSP (Retail)
| style="background:#C3F500" | Tachyon 0x00600000-0x00900000
| style="background:#C3F500" | Tachyon 0x00600000-0x00900000
| style="background:#C3F500" | 10-09-2007 (build date in ROM)
| style="background:#C3F500" | 10-09-2007 (build date in the payload)
| style="background:#C3F500" | 0xCE8
| style="background:#C3F500" | 0xCE8
| style="background:#C3F500" | SHA-256: E511D3DC78A209610F5B3EFEA2BC64BF86B9DF14A9C279C4499FECBFD70E6BF9 (ROM)
| style="background:#C3F500" | SHA-256: E511D3DC78A209610F5B3EFEA2BC64BF86B9DF14A9C279C4499FECBFD70E6BF9 (ROM)
|-
|-
| style="background:#FF8B00" | PS Vita
| style="background:#FF8B00" | PS Vita
| style="background:#FF8B00" | 0.920.000 (inside PS Vita's Compatibility security module)
| style="background:#FF8B00" | 0.931.010-0.995.000 (inside PS Vita's Compatibility security module)
| style="background:#FF8B00" | 06-22-2010 (last modified date for compat_sm.self)
| style="background:#FF8B00" | 11-17-2010 (last modified date for 0.940I compat_sm.self)
| style="background:#FF8B00" | 0x60
| style="background:#FF8B00" | SHA-256: 98C8336C136DF901FC4EA38EB371AAF6F5402AC06574F107D3E2029BFC85CCAD (full binary)
|-
| style="background:#FF8B00" | PS Vita
| style="background:#FF8B00" | 0.930.010-0.995.000 (inside PS Vita's Compatibility security module)
| style="background:#FF8B00" | 08-17-2010 (last modified date for compat_sm.self)
| style="background:#FF8B00" | 0x2C0
| style="background:#FF8B00" | 0x2C0
| style="background:#FF8B00" | SHA-256: 6D75EC720739C53228B1CA1AFF6CE073AE542BBB38FCC9B8710EC5EB3889B942 (full binary)
| style="background:#FF8B00" | SHA-256: 6D75EC720739C53228B1CA1AFF6CE073AE542BBB38FCC9B8710EC5EB3889B942 (full binary)
Line 194: Line 186:
== Memory mapping ==
== Memory mapping ==


The PSP iplloader is mapped to <b>0xBFC00000</b>, which is the MIPS reset vector, <i>i.e CPU initial program counter</i>.
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).
* a loader from <b>0xBFC00000</b> to <b>0xBFC0027F</b>
* a payload from <b>0xBFC00280</b> and ending at the size specified at <b>0xBFC000034</b> (<i>2 bytes with little endian order</i>).


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 443: Line 433:
=== Third version ===  
=== Third version ===  


This version of the PRE-IPL is present on the last 02g model and all of the 03g+ models.
Known changes from earlier Tachyon ROM Revisions:


It adds many security checks to avoid the creation of custom IPLs for these models — all of which have been broken since.
* IPL Load address now blacklists the CPU Scratchpad range (0x80010000/0xA0010000)
<pre>
ROM:8001016C                ext    $t0, $a0, 0x10, 0xD
ROM:80010170                xori    $t0, 1
ROM:80010174                beqz    $t0, loc_800101F0
</pre>


List of changes:
* IPL Entrypoint address now blacklists specific ranges (0xBFD00000...)


* IPL load address now blacklists the CPU Scratchpad range (address & 0x1FFF0000 != 0x00010000)
* IPL blocks now must have a minimum size of 0x100 bytes


* 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
* Kirk command 1 ECDSA is now enforced on IPL blocks


* IPL blocks now must have a minimum size of 0x100 bytes (including the 16-byte header)
* The last 0x20 bytes of the block contain a SHA1 hash encrypted with Kirk command 7 0x6C


* Blocks can be encrypted with KIRK commands 0~3 (in practice only command 1 is used)
The block hash is calculated using
 
<pre>
* ECDSA verification (as specified in the KIRK header) must be enforced on the last KIRK-encrypted block
sha1(block[ 8 : ] + block [ : 8])
 
</pre>
* The last 0x20 bytes of the block contain a SHA1 hash encrypted with KIRK command 7 and keyseed = 0x6C.
The first 8 bytes of the payload are copied to the end before the block is hashed.
 
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 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).
* Kirk command 0x11 ECDSA check using a custom public key (stored inside the ROM) and the xored SHA1 sum of all blocks in the hash compare function, signature present in the last IPL block (entrypoint != 0)
 
* 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 PRE-IPL were the XOR keys, the hash check, and the additional ECDSA check on the XOR of hashes.
* The first 0x10 bytes of IPL blocks are xored using a XOR key (stored in ROM and selected from an index written by updater on nand, index 1 is used for all targets except 05g, 05g uses index 2). The XOR step is not performed when Jig/Service Mode is enabled, to allow compatibility of the Jig Memory Stick across all devices.
 
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.
 
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.


== PS Vita Compatibility mode behaviour ==  
== PS Vita Compatibility mode behaviour ==  


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>).
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, <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.
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 actual PSP units, the IPL is decrypting in a single large block, rather than in multiple blocks.
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 [[#Behaviour|(<i>see PSP iplloader section</i>)]].
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, [https://github.com/mathieulh/DTP-T1000-Pre-IPL-dumper it is available on GitHub].
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]


= Trivia =
= See also =


On PSP iplloader versions 0.7 and later, the build number/date/version is copied from 0xBFC00FFC to ctc0  $17
<pre>
lw      $t0, 0xBFC00FFC
ctc0    $t0, $17
</pre>
= See also =
* [[Initial Program Loader]]
* [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]
Please note that all contributions to PSP Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PSP Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)