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 1: Line 1:
On August 22 2007, Team C+D released the "Pandora's Battery" which was the [[Prometheus]] Project everyone was waiting for. It converted a spare Memory Stick Pro Duo and PSP battery into [[Magic Memory Stick]] and [[JigKick Battery]]. Some people mistake Pandora's Battery for the [[JigKick Battery]], but Pandora's battery is both the [[Magic Memory Stick]] and the [[JigKick Battery]]. The Memory Stick and battery can then be used to downgrade any supported PSP from any FW version or to recover from a brick.
On August 22 2007, Team C+D released the "Pandora's Battery" which was the [[Prometheus]] Project everyone was waiting for. It converted a spare Memory Stick Pro Duo and battery into a "Magic Memory Stick" and "JigKick Battery". Some People mistake Pandora's Battery for the Jigkick Battery, but Pandora's battery is both the Magic Memory Stick and the JigKick Battery. The Memory Stick and battery can then be used to downgrade any PSP of any version or to recover from a brick. To convert the Memory Stick and battery another PSP which is able to run 1.50 homebrew is needed. The Memory Stick can also be converted without using a homebrew PSP by using a Pandora's battery program, such as Pandora Easy GUI. After the downgrade/unbrick service has been completed, the Memory Stick and battery can be restored for normal usage.


= Usage =


The official usage by SCE services is PSP unbrick. It also implicitely allows downgrade. See [[#Official JigKick]].


The unofficial usage, permitted by Prometheus Project, is [[#Custom IPL|Custom IPL]] loading, for unbrick, downgrade, CFW installation, CFW boot and more.
= [[JigKick Battery]] =


= Installation =
This is a battery with its serial changed to 0xFFFFFFFF. When a psp's battery serial number is changed to 0xFFFFFFFF the PSP boots the ipl from sector 16 on the physical drive (the Magic Memory Stick). This unlocks the service mode of the PSP and launches the IPL from the Memory Stick (instead of from flash0). You can either Hardmod a battery or Softmod it.


Refer to [[Magic Memory Stick]] and [[JigKick Battery]] for their installation and usage.
Hardmod is when you you make a JigKick Battery by opening it up and and removing a pin, this can be done to any battery.


To wikify: [https://forums.exophase.com/threads/using-the-universal-unbricker-to-unbrick-downgrade-restore-any-psp-to-5-00-m33-4.3780/].
Softmod is when you make a JigKick Battery by using a program. But it has to be suitable. New Batteries cannot be softmodded.


For custom IPL see below.
Click here to find out more!
= [[Magic Memory Stick]] =


= Uninstallation =
A Magic Memory Stick refers to any memory stick that has been converted to boot, and work with a JigKick Battery. Depending on the method of creation, a Magic Memory Stick can either downgrade or boot PSPs to 1.50 FW (Phat), upgrade any PSP to 3.71/3.80 M33, and their counterparts, or be able to launch various homebrew. But it has to be suitable. The Memory sticks can be made into Magic Memory Sticks only if they are Pro Duo, and below 4GB.


After the downgrade/unbrick service has been completed, the Memory Stick and battery can be restored for normal usage.
= In-depth Technological Details =


= Official JigKick =
The fake encrypted data is bruteforced to decrypt into your chosen data (to be able to exploit the preipl). 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 official Jigkick is running as a battery emulator which communicates to the PSP's System Controller using the Baryon k line., it passes an authentication using special key IDs set during the challenge when the battery serial is 0xFFFFFFFF if it passes, the GPIO that sets service mode is enabled.
The preipl exploit works like this:
 
== PSP-1000/PSP-2000/PSP-3000 ==
 
The battery emulator connects to the Baryon K Line (middle pin (PIN 2) on the battery connector)
 
== PSP-N1000 ==
See [[Psp Go Jigkick|PSP Go Jigkick]]
 
== PSP-E1000 ==
 
On the PSP-E1000, the battery emulator connects to the Baryon K Line on the ID PIN of the Mini USB connector.
 
 
Button combo:
 
To initiate the Jigkick challenge, Hold down LTrigger + RTrigger + Left + Circle when the k line and DC 5V are connected;
Turn on Power on console without letting go of buttons.
 
 
== DTP-T1000/Development Tool JIG Test/emulation Mode ==
 
Starting from kbooti 0.7.0, a special JIG test mode exists, it will read an IPL block at 0x2000 on the Memory Stick instead of address 0xBFE01000 if the specific condition is met:
 
    if ( MEMORY[0xBFEFFFFC] < 0 ) use MS
 
Writing 0xFFFFFFFF at 0xBFEFFFFC does indeed enable the pseudo service mode and reads the 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 at0xBFEFFFFC 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 only 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 (overwrites the xor key with 00s in the scratchpad) on the kirk header, allowing to use a regular IPL block to achieve code execution and dump the payload (without the xor key).
 
== DTP-H1500/Testing Tool JIG Mode ==
 
The Battery emulator will simulate a Pandora battery (serial 0xFFFFFFFF) when the P24 switch on the S3503 DIPSW is set to 1.
 
= 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.
 
== 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]
 
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 [[iplloader]] exploit works like this:


<pre>
<pre>
First a decrypted IPL block:
First a decrypted ipl block:
0x00: load address
0x00: load address
0x04: data size
0x04: data size
Line 88: Line 38:
</pre>
</pre>


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


Preipl pseudocode for loading & decrypting the ipl:
Code:
<pre>
<pre>
int iplBlockNumber = 0;
int iplBlockNumber = 0;
Line 128: Line 78:
iplBlockNumber++;
iplBlockNumber++;
}
}
</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 preipl 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 148: Line 99:
000000A0: 00 00 00 00 00 00 00 00 00 00 00 01 C6 5F 74 12
000000A0: 00 00 00 00 00 00 00 00 00 00 00 01 C6 5F 74 12
</pre>
</pre>


The most important parts to note:
The most important parts to note:
Line 154: Line 106:
0x70-0x73 is the size of the decrypted data (only 4 bytes)
0x70-0x73 is the size of the decrypted data (only 4 bytes)


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 the 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 preipl thinks the data is now a decrypted ipl block.
So note the first 0x10 bytes:
So note the first 0x10 bytes:
<pre>
<pre>
Line 165: Line 116:
0x00000000 (checksum)
0x00000000 (checksum)
</pre>
</pre>
It passes the checksum test (with 0x00000000), it skips the loading of any data (since the loadaddr has been faked to 0x00000000), see's the entry address of 0xBFD00100 and thinks it has reached the end of the ipl and so goes jumps to that address (which is where your unsigned code will be).


It passes the checksum test (with 0x00000000), it skips the loading of any data (since the loadaddr has been faked to 0x00000000), sees the entry address of 0xBFD00100 and thinks it has reached the end of the IPL and so goes jumps to that address (which is where your unsigned code will be).
So that's essentially it in a nutshell. But dont let a quick 5 min. summary of the exploit underestimate the enormous effort involved in bringing it to fruition (as the final product known as Pandora).


So that's essentially it in a nutshell. But dont let a quick 5 minutes summary of the exploit underestimate the enormous effort involved in bringing it to fruition (as the final product known as Pandora).
= Properly encrypted Pandora compatible IPL blocks =


== Properly encrypted Pandora compatible IPL blocks ==
On March 10th 2018, Developer Mathieulh released properly encrypted Pandora hack compatible IPL blocks using kirk cmd 0x01 key.


On March 10th 2018, Developer Mathieulh released properly encrypted Pandora compatible IPL blocks using KIRK command 1 key.
[https://twitter.com/Mathieulh/status/972475508612050944]
[https://twitter.com/Mathieulh/status/972476883802689537]


* [https://twitter.com/Mathieulh/status/972475508612050944]
Here are a few of those:  
* [https://twitter.com/Mathieulh/status/972476883802689537]
* [https://web.archive.org/web/20180325190510/https://pastebin.com/UVW5cBTp]
* [https://pastebin.com/fiixCeNw]


Here are a few of those custom IPLs:


* Retail flagged IPL block with entrypoint set to 0xBFD00100:
* Retail flagged IPL block with entrypoint set to 0xBFD00100:
Line 203: Line 152:
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
</pre>
</pre>


* Devkit flagged IPL block with entrypoint set to 0xBFD00100:
* Devkit flagged IPL block with entrypoint set to 0xBFD00100:
Line 226: Line 176:
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
</pre>
</pre>


* Devkit flagged IPL block with entrypoint set to 0xBFE01100 (only works on DTP-T1000/DEM-1000!, does not work on 2.6.0+ Kbooti):  
* Devkit flagged IPL block with entrypoint set to 0xBFE01100 (only works on DTP-T1000/DEM-1000!, does not work on 2.6.0+ Kbooti):  
Line 249: Line 200:
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
</pre>
</pre>


* Retail flagged IPL with entrypoint set to 0xBFE01100 (only works on DTP-T1000/DEM-1000!, does not work on 2.6.0+ Kbooti):  
* Retail flagged IPL with entrypoint set to 0xBFE01100 (only works on DTP-T1000/DEM-1000!, does not work on 2.6.0+ Kbooti):  
Line 274: Line 226:


* Retail flagged IPL with entrypoint set to 0xBFC00100 (only works on DTP-T1000/DEM-1000!, does not work on 2.6.0+ Kbooti):  
* Retail flagged IPL with entrypoint set to 0xBFC00100 (only works on DTP-T1000/DEM-1000!, does not work on 2.6.0+ Kbooti):  


<pre>
<pre>
Line 296: Line 249:
</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) Lib-PSP 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 Lib-PSP iplloader instead jumps to 0x88400000 as an hardcoded entrypoint address) :
<pre>
<pre>
.set noreorder
.set noreorder
Line 306: Line 259:
   .end start
   .end start
.set reorder
.set reorder
</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 all the time you need to test a new build.
 
<br>
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>
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
Line 333: Line 286:
</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) Lib-PSP iplloader, 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


<pre>
<pre>
Line 357: Line 310:
</pre>
</pre>


All these IPL blocks have been properly tested and are confirmed to be working (the Devkit blocks have been successfully tested on kbooti 0.7.0 and 0.9.0, only the last one with using the jr instruction works up to kbooti 2.7.1).
All these blocks have been properly tested and are confirmed to be working (the dev blocks have been successfully tested on kbooti 0.7.0 and 0.9.0, only the last one with using the jr instruction works up to kbooti 2.7.1)
 
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.
These are available in binary format here:  


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).
[https://mega.nz/#F!MlFi1QqZ!fGo2pkCEmjFiPynKtDC0Hg]


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 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, not the NAND devices are initialized by the DTP-T1000 Lib-PSP 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). 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)
Retrieved from "http://www.psdevwiki.com/psp/Pandora"