Editing Vulnerabilities

==== Grand Theft Auto: Liberty City Stories UMD (and the Goofy exploit): PSP 2.00-3.03. Patched 3.30 ====

Discovered by Edison Carter, Fanjita and n00bz in 2006.

There is a stack buffer overflow in the savedata processing of GTA LCS. In essence, the savedata mostly consists of a large structure, with an element indicating the total size. GTA LCS allocates a statically-sized buffer for this to be read into, on the stack - presumably using sizeof(savestruct) or similar. But it copies the number of bytes given by the .size element from the savedata into the stack buffer. By editing the .size element in the saved data, we can therefore force a buffer overflow. The .size element is at offset 0004 in the DATA.BIN file, in the savedata folder. Note that the DATA.BIN is encrypted, so you need to use something like the savedata sample from the pspsdk in order to modify it.

Sony quickly patched this vulnerability with a firmware update, and released a "new" version of the game that required to install the patched System Software. People wanting to hack their PSP had to be careful not to buy an updated version of the UMD. This is the only time in the PSP history that an exploited game got a UMD update.

On 2007-06-23, Noobz, with the help of Archaemic, found an exploit in the game Lumines. Called illuminati, the exploit was apparently found by pure luck, when Archaemic was trying to feed random data to the game.

https://web.archive.org/web/20080115210003/http://www.noobz.eu/joomla/news/beware-of-the-illuminati.html

==== Gripshift by MaTiaZ: PSP <= 5.02?-5.03?. Patched 5.05 ====

 

 

 

 

* second version (does not require online) of the exploit for Medal of Honor Heroes (ULUS-10141) released by kgsws on 2009-07-09

 

==== Skate Park City by freakler: <= 3.15. Patched 3.18 ====

 

==== Patapon: <= 3.18 ====

 

 

 

 

 

 

 

 

==== Puzzle Scape by sockse and qwikrazor87: <= 3.52 ====

 

==== Field Commander by sockse: <= ? ====

Discovered in 2014 by sockse.

 

* https://gist.github.com/173210/d086cf9074c714c1b737

* https://gist.github.com/173210/e8f8119534f1fc87a89d

 

 

Discovered by sockse (see [https://web.archive.org/web/20230429162635/https://wololo.net/talk/viewtopic.php?t=39756 writeup by sockse (2014-09-16)]) then patched on PSP but exploited in a different way later by ChampionLeake.

https://github.com/ChampionLeake/scrabblehax

Discovered around 2014-02-10 by qwikrazor87 and Acid_snake. Released on 2015-03-12 in TN-X by Total_Noob.

=== Sports Superbike 2 (SLES03827) / XS Moto by qwikrazor87, Acid_snake and vonjack ===

Discovered around 2014-04-07 by qwikrazor87, Acid_snake and vonjack. Released on 2015-03-12 in TN-X by Total_Noob.

=== Crash Bandicoot 2: Cortex Strikes Back by qwikrazor87, Acid_snake and ?alex-free? ===

 

 

=== Crash Bandicoot 3: Warped by qwikrazor87, Acid_snake and ?alex-free? ===

 

== POPS ==

=== POPS memory card manager buffer overflow exploit by qwikrazor87 and Acid_snake ===

Discovered around 2014-04-03 by qwikrazor87 and Acid_snake. Never implemented.

There is a buffer overflow vulnerability in POPS (PSP's PS1emu) memory card manager that potentially affects any PS1 game. One can overflow it with any PS1 game's name. qwikrazor87 and Acid_snake never went with this vulnerability as they were looking for an exploit compatible with PS Vita at the time.

This vulnerability only affects PSP's PS1emu memory card manager, not PS1, PS2, PS3 or PS4' PS1emu memory card managers.

Discovered around 2014-04-03 by qwikrazor87 and Acid_snake. Implemented around 2014-04-03 in cef_psx and TN-X by Total_Noob. Released on 2015-03-12 in TN-X by Total_Noob.

Due to the dynamic recompilation of POPS, any buffer overflow in a PS1 game that usually lets you control $ra is translated to native PSP code that lets you control parts of a register. This register contains a pointer where the system later <code>jalr</code> to. Because we do not control the entire register (due to memory address translations done by the dynarec), we can only address a fixed 4MB of RAM. Within these 4MB of RAM, you can find the pointer to the virtual memory card, that is loaded as a whole into RAM. VMC are plain text and there is no integrity check done to it at all. So you can read that pointer and jump to it, executing the VMC as a binary payload. Now the magic (never better said) comes from the fact that the VMC's magic number (first 4 bytes) are interpreted as a MIPS positive branch instruction (and the delay slot is effectively a NOP). This makes PSP (PSPemu) execute code well in the middle of the VMC, where you can inject your PSP usermode code payload.

On the PSP, if you save the game, then the address for the Memory Card you saved are stored in 0x09FFE550 which is in that range (0x09C00000 to 0x0A000000) and in 0x09FFE560 on PS Vita. But on the PS Vita, it is also always there in some other address so no need to save the game. What we did was jump to the start of the memory card. One would normally guess that the header file for .vmc would produce bad instructions, but guess again, it actually produces a positive branch with a delay slot that has no effect (basically a nop). So the system branches further into the VMC where there is absolutely nothing, so we happily injected a normal binloader there.

https://wololo.net/2015/09/16/playstation-20th-anniversary-psx-exploits-work/

== Unclassified usermode vulnerabilities ==

The Japanese version of Puzzle Bobble was compiled in debug mode, allowing hackers to retrieve some interesting information, such as function names, that were later on used in the scene’s PSP SDK. In 2005, this was one of the first steps to getting homebrews on the PSP.

https://forums.ps2dev.org/viewtopic.php?t=2081

 

https://bitbucket.org/TheOfficialFloW/psoneloader/src/master/

 

=== Old System PRX allowed: PSP any version ===

=== Fixed syscall numbers: PSP <= ?6.50? ===

On PSP System Software version below 6.60, you could guess the syscall number for any kernel export, allowing you to call any syscall without having the resolved stub readily available.

Fixed on PSP System Software version 6.60 or just before. On PSP System Software version 6.60, SCE developers randomized syscall numbers so you could not guess them anymore.

 

 

Discovered by qwikrazor87 around 2013 but independently discovered by others before, probably in 2011. Released by Acid_snake on 2023-10-15.

 

On PSP System Software version 6.60, SCE developers randomized syscall numbers so you could not guess them anymore. Therefore hackers became restricted to the functions imported by the application they exploited. This led to limited kernel function access (less chances of triggering a kernel bug) and it also drastically reduced V/HBL compatibility.

 

If you load a utility module, which loads a prx in user space, you can have a background thread that changes the PRX's stubs table to whichever imports you want. It relies on a race condition so you have to run the code a few times until it works. Eventually you can resolve whatever kernel export even if the original game did not have it.

 

 

https://github.com/PSP-Archive/ARK-4/blob/add6c946b4bab17ed7488114ccda3357ea42e0f2/common/utils/imports.c#L91

== UID planting Type Confusion kexploits by qwikrazor87 and TheFloW ==

 

 

 

 

=== sceKernelAllocPartitionMemory UID plant kexploit by TheFloW (Trinity, ARK-4): PS Vita <= 3.74 ===

=== sceKernelDeleteThread UID plant kexploit by qwikrazor87: PS Vita <= 3.50 ===

 

 

After qwikrazor87 released this exploit, Sony of course could not just change their whole design. Instead, they added a few mitigations like XOR’ing uid->uid with a random seed, or detecting that the UID object was within the heap region. These mitigations were quite effective. As you’d have to plant 2^32 different UID object’s to successfully guess the random seed. Furthermore, planting data within this heap region was not quite obvious, as that was only used by kernel internals.

 

 

 

 

 

 

 

 

 

 

== Kernel arbitrary read using sceNpCore_8AFAB4A0 double-fetch race condition kexploit by qwikrazor87 (Trinity, ARK-4): PS Vita <= 3.70 ==

== VPL kexploit by qwikrazor87 or Total_Noob: PS Vita <= 3.52 ==

== _sceKernelFreeMemoryBlock kexploit by qwikrazor87: PS Vita <= 3.50 ==

Discovered around 2015-02-11 by qwikrazor87. Released on 2015-04-18 by anonymous (probably qwikrazor87).

A good hijacked function is _sceG729EncodeTermResource but other functions can be hijacked.

== _sceUsbGpsGetData kernel write kexploit by sockse, qwikrazor87 and Acid_snake: PS Vita <= ?3.20? ==

 

 

 

 

 

 

== sceGeList kexploit by qwikrazor87 and Acid_snake: PS Vita <= ?3.20? ==

 

Discovered around 2013-10-21 by qwikrazor87 and Acid_snake.

 

== sceVideocodec race condition kexploit by qwikrazor87 and Acid_snake: PS Vita <= 3.36 ==

 

 

== _sceSdGetLastIndex race condition kexploit by qwikrazor87 and Acid_snake (TN-X, TN-V): PS Vita <= 3.20 ==

 

 

 

 

 

 

== _sceLoadCertFromFlash kexploit by by qwikrazor87 and Acid_snake (ARK, TN-V): PS Vita <= ?3.15? ==

 

== sceRegRemoveCategory buffer overflow kexploit by Freddy_156 and some1: PS Vita <= ?2.11? ==

Discovered by yosh, TheCobra and Frostegater in 2012. Released on 2013-01-12 by yosh.

Discovered by Yosh, TheCobra and Frostegater in 2012-07. Released (leaked) on 2012-11-01 by anonymous.

== sceNetMPulldown (named ifhandle 6.60) kexploit by davee (PROCFW, ME, Chronoswitch, Infinity 2): PSP <= 6.61 ==

== sceHttpStorageOpen kexploit, 0xFFFFFFFFailSploit, write 0xFFFFFFFF to anywhere by some1 and liquidzigong (ME, Chronoswitch): PSP 6.20-6.61 ==

 

== sceNetMFree race condition (named ifhandle 5.70) kexploit by davee: PSP 5.00-5.70, patched on PSP 6.20 ==

== GEN/M33 contested Wlan kexploit: PSP <= 5.50 ==

Davee does not remember much about this kexploit. GEN 5.50 source code is not public so decompilation is required in order to potentially find this exploit.

= iplloader =

Vulnerable: iplloader (all PSP bootrom versions, 0.7.0 and newer PSP DevKit Kbooti versions, PS Vita's PSP emulator bootrom)

The iplloader bootrom (present within Tachyon's IC package) as well as iplloader versions 0.7.0 and onward feature a NMI/Interrupt handler backdoor (most likely used internally for debugging purposes) in its loader part at the very first instructions of the bootrom.

If value at address 0xBC100000 is not equal to 0 and coprocessor register $9 is set, iplloader will jump to the address set in the register very early in the code (by the 8th instruction). Else (if value at address 0xBC100000 is equal to 0), coprocessor register $9 will be reset back to 0.

This backdoor may allow an attacker performing a hardware based attack to set those values and gain iplloader time code execution.

iplloader will not control the location at which it will load/copy the block. It will happily attempt to perform a memcpy (at a rate of 1 DWORD per cycle) to whatever load address is specified in the IPL header, assuming that the header passes the checks (Kirk cmd 1, Kirk cmd 1 ECDSA, Kirk cmd 0x6C SHA1 (on Tachyon 0x00600000 and later), ...). This allows to write a payload at arbitrary locations.

Fixed: iplloader 2.6.0

iplloader will jump to any location specified in the last IPL block's entrypoint. This allows arbitrary execution. This was used in conjunction with the Kirk time-attack to craft a block and gain execution from at address 0xBFD00100 in the Pandora hack, and thus allowed to craft a "valid" block in a more timely fashion.

iplloader will not control the block size. This allows to craft a small, favorable for time-attack, IPL block.

== iplloader assumes a block with the checksum 0 is the first IPL block ==

This implementation fault has been exploited to create a memory hole in VRAM that could be filled with our own payload to gain execution and dump iplloader.

== iplloader do not perform the XOR step when running in Jig/Service mode ==

Introduced: iplloader 3.5.0

Applicable to: Code execution on 3.5.0 iplloader without previous knowledge of the XOR key.

Fixed: probably never as 3.5.0 is the last known iplloader revision for Development Tool

To allow service centers to use a unique Memory Stick for multiple PSP models during servicing, iplloader deliberately disables the XOR step, allowing a non XORed IPL to run from Memory Stick. This is done so that the IPL can run on all systems from 01g to 11g. This is also presumably done because XOR keys may differ in between Tachyon revisions.

== iplloader clears the XOR key after doing a cache sync during normal execution ==

Introduced: iplloader 3.5.0

Applicable to: Dumping the iplloader 3.5.0 XOR key from Jig mode execution when used in conjunction with the arbitrary load address vulnerability

Fixed: probably never as 3.5.0 is the last known iplloader revision for Development Tool

3.5.0 iplloader clears the XOR key after doing a cache sync during normal execution. This allows to retrieve the key from the uncached memory at address 0xA001088C.

While it may be possible that Tachyon 0x00600000 and later iplloader fix this issue, it is irrelevant because the code should remain accessible as part of the Tachyon bootrom at address 0xBFC00000)

Starting with Tachyon 0x00600000, iplloader XORs each IPL block hash as they are loaded, and then uses this final XOR to verify the signature.