Editing Pandora

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 28: Line 28:


== PSP-N1000 ==
== PSP-N1000 ==
See [[Psp Go Jigkick|PSP Go Jigkick]]
On the PSP GO, the battery emulator connects to the Baryon K Line on PIN 5 on the MULTI OUT Connector.


== PSP-E1000 ==
== PSP-E1000 ==
Line 62: Line 62:
= Custom IPL =
= Custom IPL =


[[JigKick Battery]] and [[Magic Memory Stick]] allow loading [[IPL]] from [[Memory Stick]] instead of NAND, which is useful for unbricking. But the [[IPL]] still has to be encrypted and signed to be accepted by the [[iplloader]]. This was first solved by Bruteforce attack (?2005? ?2007?). Then in 2011 [[KIRK Crypto Engine]] command 1 key got retrieved thanks to PS3 hack, and allowed properly encrypting and signing IPL, as demonstrated by mathieulh in 2018.
[[JigKick Battery]] and [[Magic Memory Stick]] allow loading [[IPL]] from [[Memory Stick]] instead of NAND, which is useful for unbricking. But the [[IPL]] still has to be encrypted and signed to be accepted by [[PRE-IPL]]. This was first solved by Bruteforce attack (?2005? ?2007?). Then in 2011 [[KIRK Crypto Engine]] command 1 key got retrieved thanks to PS3 hack, and allowed properly encrypting and signing IPL, as demonstrated by mathieulh in 2018.


== IPL Bruteforce Attack ==
== IPL Bruteforce Attack ==


See [https://events.ccc.de/congress/2007/Fahrplan/attachments/1040_psphacking.odp 24C3 Talk by Tyranid (2007)]. [http://uofw.github.io/upspd/docs/SilverSpring_Blog/my.malloc.us/silverspring/pandora-exploit/index.html iplloader exploit writeup by SilverSpring]
See [https://events.ccc.de/congress/2007/Fahrplan/attachments/1040_psphacking.odp 24C3 Talk by Tyranid (2007)]. [http://uofw.github.io/upspd/docs/SilverSpring_Blog/my.malloc.us/silverspring/pandora-exploit/index.html PRE-IPL exploit writeup by SilverSpring]


The fake encrypted data is bruteforced to decrypt into your chosen data (to be able to exploit the [[iplloader]]). And the signature for your fake encrypted data is bruteforced again to make it appear valid in the eyes of the crypto engine so that it will will go ahead and decrypt your fake encrypted data.
The fake encrypted data is bruteforced to decrypt into your chosen data (to be able to exploit the [[PRE-IPL]]). And the signature for your fake encrypted data is bruteforced again to make it appear valid in the eyes of the crypto engine so that it will will go ahead and decrypt your fake encrypted data.


The [[iplloader]] exploit works like this:
The [[PRE-IPL]] exploit works like this:


<pre>
<pre>
Line 90: Line 90:
Which means load 0xF50-byte data to 0x040F1EA0. 0xB71C6EBA is the checksum of the previous block. Then entry address is 0 since it hasn't reached the end yet and there are more blocks to load. Once it has loaded all the IPL blocks, the very last block will have entry address of where the whole IPL has been loaded (typically 0x040F0000). And will then jump to that address.
Which means load 0xF50-byte data to 0x040F1EA0. 0xB71C6EBA is the checksum of the previous block. Then entry address is 0 since it hasn't reached the end yet and there are more blocks to load. Once it has loaded all the IPL blocks, the very last block will have entry address of where the whole IPL has been loaded (typically 0x040F0000). And will then jump to that address.


iplloader pseudocode for loading and decrypting the IPL:
PRE-IPL pseudocode for loading and decrypting the IPL:


<pre>
<pre>
Line 130: Line 130:
</pre>
</pre>


As the iplloader loads the first IPL block (the fake one), it decrypts the block in-place, ie. the decrypted block just overwrites your encrypted block. The fake block only decrypts into four bytes of all 0's so it ends up only overwriting the first four bytes of your fake block (with four 0's) after decryption.
As the PRE-IPL loads the first IPL block (the fake one), it decrypts the block in-place, ie. the decrypted block just overwrites your encrypted block. The fake block only decrypts into four bytes of all 0's so it ends up only overwriting the first four bytes of your fake block (with four 0's) after decryption.


The fake signed block:
The fake signed block:
Line 156: Line 156:
A slight flaw in the crypto engine allowed bruteforce to be performed on a magnitude-times smaller scale than normally required.
A slight flaw in the crypto engine allowed bruteforce to be performed on a magnitude-times smaller scale than normally required.


After decryption, the iplloader thinks the data is now a decrypted IPL block.
After decryption, the PRE-IPL thinks the data is now a decrypted IPL block.


So note the first 0x10 bytes:
So note the first 0x10 bytes:
Line 296: Line 296:
</pre>
</pre>


* IPL Block for Prototype (0.4 and 0.6) iplloader, containing the following MIPS assembly instructions (the jal instruction is not used because of the address length, instead the address is stored to a register using the load immediate instruction, then the jump register instruction is used to jump to it, assembly is used to artificially make the jump because older IPL blocks cannot contain an entrypoint value, the old iplloader instead jumps to 0x88400000 as an hardcoded entrypoint address):
* IPL Block for Prototype (0.4 and 0.6) PRE-IPL, containing the following MIPS assembly instructions (the jal instruction is not used because of the address length, instead the address is stored to a register using the load immediate instruction, then the jump register instruction is used to jump to it, assembly is used to artificially make the jump because older IPL blocks cannot contain an entrypoint value, the old PRE-IPL instead jumps to 0x88400000 as an hardcoded entrypoint address):
<pre>
<pre>
.set noreorder
.set noreorder
Line 308: Line 308:
</pre>
</pre>


This block will jump to 0xBFE01100 so you can use this block as if you were using a Pandora IPL block on the prototype iplloader, which saves you time from encrypting new IPLs every time you need to test a new build.
This block will jump to 0xBFE01100 so you can use this block as if you were using a Pandora IPL block on the prototype PRE-IPL, which saves you time from encrypting new IPLs every time you need to test a new build.


Note: There is no 0xBFC00100 IPL block for the prototype iplloader because they do not load IPL blocks there and you cannot use that address as it would overwrite the iplloader code itself which does not use a payload section/address and runs entirely from 0xBFC00000.
Note: There is no 0xBFC00100 IPL block for the prototype PRE-IPL because they do not load IPL blocks there and you cannot use that address as it would overwrite the PRE-IPL code itself which does not use a payload section/address and runs entirely from 0xBFC00000.


<pre>
<pre>
Line 333: Line 333:
</pre>
</pre>


* IPL Block for 0.7.0 and later (up to 2.7.1) iplloader, containing the previously mentioned jr MIPS assembly instruction to address 0xBFE01100  
* IPL Block for 0.7.0 and later (up to 2.7.1) PRE-IPL, containing the previously mentioned jr MIPS assembly instruction to address 0xBFE01100  
This IPL block has been tested successfully on 2.6.0 and 2.7.1 kbooti.
This IPL block has been tested successfully on 2.6.0 and 2.7.1 kbooti.


Line 361: Line 361:
These are available in binary format here: [https://mega.nz/#F!MlFi1QqZ!fGo2pkCEmjFiPynKtDC0Hg download link].
These are available in binary format here: [https://mega.nz/#F!MlFi1QqZ!fGo2pkCEmjFiPynKtDC0Hg download link].


The 0xBFD00100 version of these blocks work as-is by replacing the time attacked forged block with the properly encrypted ones supplied. The 0xBFE01100 and 0xBFCD00100 version (which only works on Development Tool units), may require you to rebuild/recompile your custom IPLs using 0xBFE01100 or 0xBFCD00100 as the entrypoints respectively, as well as using a modified iplboot because the one used by retail custom IPLs uses iplloader hardcoded addresses. It may be wiser to rebuild it as a fully valid IPL instead using ipltool [https://github.com/zecoxao/ipltool], although using the Pandora compatible IPL block instead would allow you to port retail custom IPL projects on devkit with minimal efforts.
The 0xBFD00100 version of these blocks work as-is by replacing the time attacked forged block with the properly encrypted ones supplied. The 0xBFE01100 and 0xBFCD00100 version (which only works on Development Tool units), may require you to rebuild/recompile your custom IPLs using 0xBFE01100 or 0xBFCD00100 as the entrypoints respectively, as well as using a modified iplboot as the one used by retail custom IPLs uses PRE-IPL hardcoded addresses. It may be wiser to rebuild it as a fully valid IPL instead using ipltool [https://github.com/zecoxao/ipltool], although using the Pandora compatible IPL block instead would allow you to port retail custom IPL projects on devkit with minimal efforts.


Keep in mind that under normal circumstances neither the Memory Stick nor the NAND devices are initialized by the DTP-T1000 iplloader. Reading or writing to and from either of these devices will require you to add the initialization routine to your IPL (most likely within your iplboot binary).
Keep in mind that under normal circumstances neither the Memory Stick nor the NAND devices are initialized by the DTP-T1000 PRE-IPL. Reading or writing to and from either of these devices will require you to add the initialization routine to your IPL (most likely within your iplboot binary).


The IPL SDK (available here: [https://github.com/mathieulh/PSP_IPL_SDK]) contains full low-level driver implementation for both devices which you can use in your projects.
The IPL SDK (available here: [https://github.com/mathieulh/PSP_IPL_SDK]) contains full low-level driver implementation for both devices which you can use in your projects.
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)