Editing Vulnerabilities

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


== Exploits to sort ==
== Exploits to sort ==
https://www.psdevwiki.com/psp/Homebrew_Enabler


https://en.wikibooks.org/wiki/PSP/Homebrew_History
https://en.wikibooks.org/wiki/PSP/Homebrew_History
Line 23: Line 21:
=== Before PS Vita era ===
=== Before PS Vita era ===


==== Grand Theft Auto: Liberty City Stories UMD (Goofy exploit): PSP 2.00-3.03. Patched 3.30 ====
==== Grand Theft Auto: Liberty City Stories UMD (Goofy exploit): PSP <= 3.03. Patched 3.30 ====
 
Discovered by Edison Carter.
 
The GTA LCS exploit is a classic stack buffer overflow, in the savedata processing. 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.
 
The Exploit was patched in a second batch of UMD prints.
 
Germany version:
* ULES00182 - Unpatched - Contains 2.00 System Software update.
 
Europe (UK/EU) version:
* ULES00151 first batch - Unpatched - Contains 2.00 System Software update.
* ULES00151 second batch - Patched - Contains 2.60 System Software update.
 
North America (US) version:
* ULUS10041 - Unpatched - Contains UPDL 0048501A 5, plus IFPI L332 in very small letters on the UMD.
* ULUS10041 - Patched - Contains UPDL 010050 on the UMD.
 
* ULUS10041 Unpatched, and Patched UMDs look exactly the same... Only the small codes are different.
 
The 18 logo in a red circle is present on the spine on the pre-2.60 UMD, but on the patched 2.60 UMD the 18 red circle logo is not present on the spine.
 
Another indication is the copyright date: if it is 2005 then it is unpatched, else it is 2006 and is patched.


==== Lumines (Illuminati exploit): PSP <= 3.50. Patched 3.51 ====
==== Lumines (Illuminati exploit): PSP <= 3.50. Patched 3.51 ====
Line 223: Line 198:


==== Gladiator Begins Demo (NPEH90050, NPUH90077, NPJH90084) by qwikrazor87: <= 3.18 ====
==== Gladiator Begins Demo (NPEH90050, NPUH90077, NPJH90084) by qwikrazor87: <= 3.18 ====
Discovered around 2014-09-12 by qwikrazor87.


https://wololo.net/talk/viewtopic.php?t=39771
https://wololo.net/talk/viewtopic.php?t=39771
Line 303: Line 276:


== PS1 Game Savedata ==
== PS1 Game Savedata ==
=== Wipeout (NPEE00004, NPUI94301, NPJI00035) by qwikrazor87 and vonjack ===
Discovered around 2014-04-08 by qwikrazor87 and vonjack.
Maybe not exploitable.
=== Pinball Golden Logres (SuperLite 1500 Series) (NPJJ00460) by qwikrazor87 and vonjack ===
Discovered around 2014-04-21 by qwikrazor87 and vonjack.
Maybe not exploitable.
=== Noon (NPJJ00466) by qwikrazor87 and vonjack ===
Discovered around 2014-04-19 by qwikrazor87 and vonjack.
Maybe not exploitable.
=== Harvest Moon: Back To Nature (NPEF00286, NPUJ01115) by qwikrazor87 ===
Discovered around 2015-09-28 by qwikrazor87.
Once you have installed the exploit file, start Harvest Moon: Back To Nature, then after about 20 seconds the screen should flash white.


=== Tekken 2 by qwikrazor87 and Acid_snake ===
=== Tekken 2 by qwikrazor87 and Acid_snake ===


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


https://wololo.net/downloads/index.php/download/8275
https://wololo.net/downloads/index.php/download/8275


https://hackinformer.com/PlayStationGuide/PSV/_exploitgames.html
=== Sports Superbike 2 / XS Moto by qwikrazor87 and Acid_snake ===


=== Sports Superbike 2 (SLES03827) / XS Moto by qwikrazor87, Acid_snake and vonjack ===
Implemented in TN-X by Total_Noob and qwikrazor87.
 
Discovered around 2014-04-07 by qwikrazor87, Acid_snake and vonjack. Released on 2015-03-12 in TN-X by Total_Noob.


https://wololo.net/downloads/index.php/download/8275
https://wololo.net/downloads/index.php/download/8275
https://hackinformer.com/PlayStationGuide/PSV/_exploitgames.html


=== Castlevania Chronicles (NPUJ01384) by ChampionLeake ===
=== Castlevania Chronicles (NPUJ01384) by ChampionLeake ===
Line 350: Line 295:
https://github.com/socram8888/tonyhax/issues/39
https://github.com/socram8888/tonyhax/issues/39


https://alex-free.github.io/tonyhax-international/save-game-exploit.html
=== Brunswick Circuit Pro Bowling 1 or 2 by ChampionLeake ===


=== Crash Bandicoot 2: Cortex Strikes Back by qwikrazor87, Acid_snake and ?alex-free? ===
Not available on PS Store for PSP.


Discovered in 2014 by qwikrazor87 and Acid_snake. Disclosed on 2015-09-16 by Acid_snake.
=== Tony Hawk Pro Skater 2 by ChampionLeake ===


https://alex-free.github.io/tonyhax-international/save-game-exploit.html
Not available on PS Store for PSP.


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


=== Crash Bandicoot 3: Warped by qwikrazor87, Acid_snake and ?alex-free? ===
=== libtiff exploit #1 (TIFF Exploit 2.00) <=2.00 ===


Discovered in 2014 by qwikrazor87 and Acid_snake. Disclosed on 2015-09-16 by Acid_snake.
Discovered on 2005-09-23.


https://alex-free.github.io/tonyhax-international/save-game-exploit.html
Implemented in downgraders (like MPH downgrader to 1.50) and eLoader by Fanjita.


https://wololo.net/2015/09/16/playstation-20th-anniversary-psx-exploits-work/
https://en.wikibooks.org/wiki/PSP/Homebrew_History#The_TIFF_Exploit


=== Doki Oki (Japanese: 土器王紀) (NPJJ00560) by ?alex-free? ===
=== libtiff exploit #2 (TIFF Exploit 2.71) <=2.71 ===


https://alex-free.github.io/tonyhax-international/save-game-exploit.html
Discovered in 2006-09.


=== Exploitable PS1 games not available officially on PSP ===
Implemented in Kriek eLoader and xLoader by Team N00bz.


Compare with the [https://www.psdevwiki.com/ps1/index.php?title=Vulnerabilities list of PS vulnerabilities on the PS1 dev wiki].
https://en.wikibooks.org/wiki/PSP/Homebrew_History#The_TIFF_Exploit


== POPS ==
=== libtiff exploit #3 (TIFF Exploit 4.20) by wololo <=4.20 ===


=== POPS memory card manager buffer overflow exploit by qwikrazor87 and Acid_snake ===
Discovered in 2008-08. Released on 2009-03-15.


Discovered around 2014-04-03 by qwikrazor87 and Acid_snake. Never implemented.
https://wololo.net/2009/03/15/so-what-about-the-libtiff-vulnerability/


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.
https://www.youtube.com/watch?v=RUJnXADjxsw


This vulnerability only affects PSP's PS1emu memory card manager, not PS1, PS2, PS3 or PS4' PS1emu memory card managers.
https://web.archive.org/web/20111226013924/http://secunia.com/advisories/31610/


=== POPS sandbox escape by qwikrazor87 and Acid_snake (TN-X) ===
=== libtiff exploit #4 (eggsploit) by Malloxis, Matiaz and davee <=5.05 ===
 
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 ==
 
=== PsOneLoader by TheFloW ===
 
https://bitbucket.org/TheOfficialFloW/psoneloader/src/master/
 
== System ==
 
=== libtiff exploit #4 (eggsploit) by Malloxis, Matiaz and davee: PSP <= 5.05 ===


Discovered in 2009-03-15 by Malloxis. Released on 2009-04-12 by Matiaz and davee.
Discovered in 2009-03-15 by Malloxis. Released on 2009-04-12 by Matiaz and davee.
Line 414: Line 341:
https://www.youtube.com/watch?v=wV21QqQmX_o
https://www.youtube.com/watch?v=wV21QqQmX_o


=== libtiff exploit #3 (TIFF Exploit 4.20) by wololo: PSP <= 4.20 ===
=== Old System PRX allowed ===
 
Discovered in 2008-08. Released on 2009-03-15.
 
https://wololo.net/2009/03/15/so-what-about-the-libtiff-vulnerability/
 
https://www.youtube.com/watch?v=RUJnXADjxsw
 
https://web.archive.org/web/20111226013924/http://secunia.com/advisories/31610/
 
=== libtiff exploit #2 (TIFF Exploit 2.71): PSP <= 2.71 ===
 
Discovered in 2006-09.
 
Implemented in Kriek eLoader and xLoader by Team N00bz.
 
https://en.wikibooks.org/wiki/PSP/Homebrew_History#The_TIFF_Exploit
 
=== libtiff exploit #1 (TIFF Exploit 2.00): PSP <= 2.00 ===
 
Discovered on 2005-09-23 by Niacin, Skylark and Toc2rta.
 
The exploit involves using a wallpaper and a TIFF image file containing a buffer overflow. Since the data from the wallpaper is in a known location (VRAM), one can use the TIFF overflow to jump to the known VRAM location and execute userode code.
 
Implemented in downgraders (like MPH downgrader from 2.00 to 1.50) and eLoader by Fanjita.
 
https://en.wikibooks.org/wiki/PSP/Homebrew_History#The_TIFF_Exploit
 
[https://web.archive.org/web/20060130220231/http://sunkone.cja.net/psp/loader2/README.txt] -> cjb
 
https://repo.zenk-security.com/Magazine%20E-book/EN-Hacking%20PSP.pdf
 
=== Unsigned System PRX allowed: PSP <= 6.20 ===
 
Discovered in 2011 by kgsws.
 
When the PS3 was hacked and a selection of PSP encryption keys were released, this allowed one to sign his own usermode applications. HEN/CFW can be loaded much faster through a signed application rather than loading of a game. We can now sign our own vshmain and replace a step in the bootchain.
 
kgsws first demonstrated this bootchain injection back in 2011 and lead to the creation of 6.20 permanent custom firmware. Sony did patch this up in later firmware by applying an ECDSA signature to PRX files in the bootchain which we cannot forge.
 
Fixed: since PSP System Software version 6.30.
 
=== Old System PRX allowed: PSP any version ===


Discovered around 2005.
Discovered around 2005.
Line 478: Line 363:
Fixed: no.
Fixed: no.


=== Fixed syscall numbers: PSP <= ?6.50? ===
=== Unsigned System PRX allowed ===


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.
Discovered in 2011 by kgsws.


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.
When the PS3 was hacked and a selection of PSP encryption keys were released, this allowed one to sign his own usermode applications. HEN/CFW can be loaded much faster through a signed application rather than loading of a game. We can now sign our own vshmain and replace a step in the bootchain.


=== qwikTrick (or Perfect Syscalls) by qwikrazor87: PSP/PS Vita any version ===
kgsws first demonstrated this bootchain injection back in 2011 and lead to the creation of 6.20 permanent custom firmware. Sony did patch this up in later firmware by applying an ECDSA signature to PRX files in the bootchain which we cannot forge.


Discovered by qwikrazor87 around 2013 but independently discovered by others before, probably in 2011. Released by Acid_snake on 2023-10-15.
Fixed: since PSP System Software version 6.30.
 
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.
 
This exploit was very useful since most Minis games (main attack vector back in time) had limited imports. Team OILIX never released it because they wanted to keep it in case they came across a kernel exploit on some obscure function that not a lot of games import. Also because by then VHBL was already abandoned and everyone wanted eCFW (ARK, TN) instead so making VHBL have perfect syscalls for better compatibility was a waste for this hack. In hindsight it was a bad decision since Team OILIX never actually used the function because soon after was figured out how to craft PBOOT.PBP for PS Vita with any desired imports.
 
https://github.com/PSP-Archive/ARK-4/blob/add6c946b4bab17ed7488114ccda3357ea42e0f2/common/utils/imports.c#L91


= Kernel =
= Kernel =


== UID planting Type Confusion kexploits by qwikrazor87 and TheFloW ==
== kernel execution using encrypted UID planting Type Confusion kexploit by qwikrazor87 (Trinity, ARK-4): PS Vita <= 3.74 ==
 
Exploiting this bug is straightforward:
1) Plant a fake UID object into kernel.
2) Encode this UID object.
3) Delete the UID object.
 
Basically, what you can do with this primitive is overwriting a function pointer in kernel and make it pointing to some function in usermode instead. Then, we can invoke it and run our code in kernel mode.
 
https://theofficialflow.github.io/2019/06/18/trinity.html#type-confusion
 
=== sceKernelAllocPartitionMemory UID plant kexploit by TheFloW (Trinity, ARK-4): PS Vita <= 3.74 ===


https://theofficialflow.github.io/2019/06/18/trinity.html#type-confusion
https://theofficialflow.github.io/2019/06/18/trinity.html#type-confusion
Line 519: Line 385:
It involves AES enc/dec (using sceChnnlsv buffer in kernel RAM for fake thread UID) for it to work with the sceKernelDeleteThread UID kexploit.
It involves AES enc/dec (using sceChnnlsv buffer in kernel RAM for fake thread UID) for it to work with the sceKernelDeleteThread UID kexploit.


=== sceKernelDeleteThread UID plant kexploit by qwikrazor87: PS Vita <= 3.50 ===
== kernel arbitrary read using sceNpCore_8AFAB4A0 double-fetch race condition kexploit by qwikrazor87 (Trinity, ARK-4): PS Vita <= 3.70 ==
 
Discovered around 2014-10-20 by qwikrazor87.
 
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.
 
https://github.com/GuidoAlessandroMenichetti/kxploits/blob/master/(3.50)%20sceKernelDeleteThread/explanation.txt
 
=== Stack Pointer UID plant kexploit by qwikrazor87: PS Vita <= ?3.50? ===
 
Discovered around 2014-01-29 by qwikrazor87.
 
The exploit steps are:
1) Execute assembly that does saves context.
2) Execute assembly that writes the evil UID 0x05FEF601 and the hijacked function _sceKernelLibcTime address to address 0x88000000.
3) Create a dummy thread whose name is at address 0x88000000, using sceKernelCreateThread.
4) Execute assembly that does something.
5) Free the evil UID 0x05FEF601 at using sceKernelFreePartitionMemory.
6) Execute assembly that restores context.
7) Call the hijacked function _sceKernelLibcTime.
 
=== sceKernelFreePartitionMemory UID plant kexploit by qwikrazor87: PS Vita <= ?3.50? ===
 
Discovered around 2014-01-03 by qwikrazor87.
 
Call sceIoOpen many times to corrupt an UID then free the UID using sceKernelFreePartitionMemory.
 
=== sceKernelClearEventFlag UID plant (project OILIX) kexploit by qwikrazor87: PS Vita <= ?3.50? ===
 
Discovered around 2013-10-15 by qwikrazor87.
 
== Kernel arbitrary read using sceNpCore_8AFAB4A0 double-fetch race condition kexploit by qwikrazor87 (Trinity, ARK-4): PS Vita <= 3.70 ==


https://theofficialflow.github.io/2019/06/18/trinity.html#double-fetch-race-condition
https://theofficialflow.github.io/2019/06/18/trinity.html#double-fetch-race-condition
Line 558: Line 393:
https://github.com/PSP-Archive/ARK-4/blob/main/loader/live/kernel/kxploit/vita360/kxploit.c
https://github.com/PSP-Archive/ARK-4/blob/main/loader/live/kernel/kxploit/vita360/kxploit.c


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


[https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/sceVpl/kxploit.c 3.00-3.35 from PROCFW]
[https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/sceVpl/kxploit.c 3.00-3.35 from PROCFW]
Line 564: Line 399:
https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/vpl/kxploit.c 3.51-3.52 from TN-V]
https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/vpl/kxploit.c 3.51-3.52 from TN-V]


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


Discovered around 2015-02-11 by qwikrazor87. Released on 2015-04-18 by anonymous (probably qwikrazor87).
https://github.com/GuidoAlessandroMenichetti/kxploits/blob/master/(3.50)%20sceKernelDeleteThread/explanation.txt
 
== _sceG729EncodeTermResource kexploit by Total_Noob: PS Vita <= 3.50 ==


A good hijacked function is _sceG729EncodeTermResource but other functions can be hijacked.
Released on 2015-04-18 by anonymous.


https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/sceG729/kxploit.c
https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/sceG729/kxploit.c
Line 574: Line 411:
https://pastebin.com/Sdz0XPRg
https://pastebin.com/Sdz0XPRg


== _sceUsbGpsGetData kernel write kexploit by qwikrazor87 and Acid_snake: PS Vita <= ?3.20? ==
== sceVideocodec race condition kexploit by qwikrazor87: PS Vita 3.30-3.36 ==
 
Discovered around 2014-01-29 by qwikrazor87 and Acid_snake.
 
Simply call <code>_sceUsbGpsGetData(0x10000, sw_address);</code> where <code>sw_address</code> is the address of the function to hijack, usually _sceKernelLibcTime.
 
== _sceWlanSetHostDiscover kernel write kexploit by qwikrazor87 and Acid_snake: PS Vita <= ?3.15? ==
 
Discovered around 2014-01-19 by qwikrazor87 and Acid_snake.
 
In sceWlanDrv_lib library, the _sceWlanSetHostDiscover function allows arbitrary write to kernel.
 
== 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 ==
 
Discovered around 2013-12-13 by qwikrazor87 and Acid_snake.
 
The following functions can be used to provoke the race condition: _sceVideocodecOpen, _sceVideocodecStop and _sceVideocodecDecode, _sceVideocodecSetMemory.


https://github.com/GuidoAlessandroMenichetti/kxploits/blob/master/(3.36)%20sceVideocodecStop/explanation.txt
https://github.com/GuidoAlessandroMenichetti/kxploits/blob/master/(3.36)%20sceVideocodecStop/explanation.txt
Line 600: Line 417:
https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/sceVideocodec/kxploit.c
https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/sceVideocodec/kxploit.c


== _sceSdGetLastIndex race condition kexploit by qwikrazor87 and Acid_snake (TN-X, TN-V): PS Vita <= 3.20 ==
== _sceSdGetLastIndex kexploit by qwikrazor87 (TN-X, TN-V): PS Vita 3.18-3.20 ==
 
Discovered around 2013-10-21 by qwikrazor87 and Acid_snake. Implemented in TN-V4 by Total_Noob around 2013-12-12. Implemented in TN-X by Total_Noob around 2014-04-22.


There is a time-of-check to time-of-use exploit in chnnlsv.
There is a time-of-check to time-of-use exploit in chnnlsv.
Line 620: Line 435:
https://github.com/PSP-Archive/ARK-4/blob/main/loader/live/kernel/kxploit/vita320/kxploit.c
https://github.com/PSP-Archive/ARK-4/blob/main/loader/live/kernel/kxploit/vita320/kxploit.c


== _sceSdRemoveValue race condition kexploit by qwikrazor87 and Acid_snake: PS Vita <= ?3.20? ==
== _sceLoadCertFromFlash kexploit by Total_Noob (TN-V): PS Vita <= ?3.15? ==
 
Discovered around 2013-10-21 by qwikrazor87 and Acid_snake.
 
There is a time-of-check to time-of-use exploit in chnnlsv.
 
== __sceSasConcatenateATRAC3 kexploit by qwikrazor87 and Acid_snake: PS Vita <= ?3.20? ==
 
Discovered around 2013-12-13 by qwikrazor87 and Acid_snake.
 
== _sceLoadCertFromFlash kexploit by by qwikrazor87 and Acid_snake (ARK, TN-V): PS Vita <= ?3.15? ==
 
Discovered around 2013-10-22 by qwikrazor87 and Acid_snake. Implemented in TN-V by Total_Noob.


https://github.com/GuidoAlessandroMenichetti/TN-Rev/blob/master/loader/main.c
https://github.com/GuidoAlessandroMenichetti/TN-Rev/blob/master/loader/main.c
Line 640: Line 443:
https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/sceLoadCertFromFlash/kxploit.c
https://bitbucket.org/Acid_Snake/ark-4/src/master/kxploit/sceLoadCertFromFlash/kxploit.c


== sceRegRemoveCategory buffer overflow kexploit by Freddy_156 and some1: PS Vita <= ?2.11? ==
== sceRegRemoveCategory buffer overflow kexploit by Freddy_156 and some1 (no implementation): PS Vita <= ?2.11? ==


Dicovered in 2011 by Freddy_156 and some1. Released on 2013-06-02 by Freddy_156.
Dicovered in 2011 by Freddy_156 and some1. Released on 2013-06-02 by Freddy_156.
Line 687: Line 490:
== kermit_inet_socket kexploit by yosh, TheCobra and Frostegater (ARK, TN-A, TN-C): PS Vita <= 2.01 ==
== kermit_inet_socket kexploit by yosh, TheCobra and Frostegater (ARK, TN-A, TN-C): PS Vita <= 2.01 ==


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


kermit_inet_socket (sceWlanDrv_lib_51B0BBB8) does not require an active WiFi connection.
kermit_inet_socket (sceWlanDrv_lib_51B0BBB8) does not require an active WiFi connection.
Line 699: Line 502:
== sceWlanGetEtherAddr kexploit by yosh, TheCobra and Frostegater (VHBL, ARK): PS Vita 1.61-1.80 ==
== sceWlanGetEtherAddr kexploit by yosh, TheCobra and Frostegater (VHBL, ARK): PS Vita 1.61-1.80 ==


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


In PSP System Software 6.60 sceWlanGetEtherAddr function is k1-checked but in PS Vita System Software <= 1.80 PSPemu it is not.
In PSP System Software 6.60 sceWlanGetEtherAddr function is k1-checked but in PS Vita System Software <= 1.80 PSPemu it is not.
Line 735: Line 538:
TBD: implementation by CelesteBlue
TBD: implementation by CelesteBlue


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


https://github.com/uofw/uofwinst/blob/master/PXE/Launcher/kxp_660.c
https://github.com/uofw/uofwinst/blob/master/PXE/Launcher/kxp_660.c
Line 745: Line 548:
https://github.com/PSP-Archive/ARK-4/blob/main/loader/live/kernel/kxploit/psp660/kxploit.c
https://github.com/PSP-Archive/ARK-4/blob/main/loader/live/kernel/kxploit/psp660/kxploit.c


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


https://wololo.net/talk/viewtopic.php?t=6612
https://wololo.net/talk/viewtopic.php?t=6612
Line 769: Line 570:
https://wololo.net/2013/05/04/kernel-exploits-how-they-work-and-why-they-are-scarce/
https://wololo.net/2013/05/04/kernel-exploits-how-they-work-and-why-they-are-scarce/


== sceNetMFree race condition (named ifhandle 5.70) kexploit by davee: PSP 5.00-5.70, patched on PSP 6.20 ==
== ifhandle 5.70 race condition kexploit by davee: PSP 5.00-5.70, patched on PSP 6.20 ==
 
https://wololo.net/talk/viewtopic.php?p=147730#p147730
 
https://wololo.net/talk/viewtopic.php?p=147732#p147732


== GEN/M33 contested Wlan kexploit: PSP <= 5.50 ==
https://wololo.net/talk/viewtopic.php?f=5&t=11877&start=10
 
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.
 
https://wololo.net/talk/viewtopic.php?p=147642#p147642


== sceDRMInstallGetFileInfo memset anywhere kexploit (psheet 5.03) by davee (ChickHEN): PSP <= 5.03 ==
== sceDRMInstallGetFileInfo memset anywhere kexploit (psheet 5.03) by davee (ChickHEN): PSP <= 5.03 ==
Line 786: Line 579:


https://wololo.net/talk/viewtopic.php?p=2022
https://wololo.net/talk/viewtopic.php?p=2022
https://wololo.net/talk/viewtopic.php?p=2022#p2022


https://wololo.net/talk/viewtopic.php?f=5&t=242
https://wololo.net/talk/viewtopic.php?f=5&t=242


http://www.kingx.de/forum/showthread.php?tid=15275
http://www.kingx.de/forum/showthread.php?tid=15275
https://github.com/DaveeFTW/ChickHEN/blob/main/Launcher/main.c


This exploit clobbers 16 bytes of kernel memory, so it is needed to read kernel memory before exploiting and restore the other 12 after.
This exploit clobbers 16 bytes of kernel memory, so it is needed to read kernel memory before exploiting and restore the other 12 after.


This kernel exploit requires some modules that are not loaded by the Gripshift game. This is why WhickHEN works with the libtiff XMB bug, but was never ported to the Gripshift exploit.
== registry error store: PSP <= 2.80 ==
 
== Registry error store: PSP <= ?2.80? ==
 
According to davee, this registry vulnerability is pretty cool. There is an error condition that writes 0xFFFFFFFF to a user controlled address. Exploitation path is modifying the 0xBC000000 memory permission to allow usermode read/write to kernel.
 
https://wololo.net/talk/viewtopic.php?p=147642#p147642
 
== Registry write access from usermode: PSP <= 2.60 ==
 
Since the registry is placed on flash1, it can be accessed by usermode.


== sceKernelLoadExec buffer overflow by hitchhikr / Neural: PSP 2.01-2.60 ==
== sceKernelLoadExec buffer overflow by hitchhikr / Neural: PSP 2.01-2.60 ==
There is a subroutine in loadexec.prx that takes a path as an argument. It looks for the character ":" in that path, and calculates the length of the drive name from that (e.g. "ms0:"). It then copies the drive name onto the stack with strncpy.
The exploit is located in a subroutine in the loadexec.prx file. It is at address 0x88064C94 (game mode) in System Software version 2.60. The purpose of this procedure (used in other functions like "sceKernelLoadExec") is to check that the drive part of a filename is valid and legit. It allocates 48 bytes of stack and the return address to the calling function is stored at the end of it (from 44th to 47th bytes). It starts by checking the first char of the string to see if it is an empty drive name, if it is not the routine extracts the part of the filename that contain the drive name and copies it into the allocated stack. It only stops when it encounters a ':' char. Since it does not check any string length during the copy, if the drive name supplied by user is big enough, then it will overwrite the rest of the stack based values, like the return address for example. Hence why a drive name of 48 chars (+ an extra ':' char to let the loop ends) containing an address to an arbitrary position in memory (pointing to a function of ours for example) located from the 44th to 47th chars in the filename will allow us to run any code we want in the context of the executing routine (kernel mode) as when it ends, it reloads the return address from the stack and directly jumps to it.
In later System Software versions, loadexec checks if the drive name is longer than 0x1F bytes. If it is, it returns an error. Look at sub_21E0 in 6.60 loadexec_01g.prx.


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


https://www.hitchhikr.net/Exploit_2.6.zip
https://www.hitchhikr.net/Exploit_2.6.zip
https://github.com/mathieulh/3.90-M33/blob/master/experiments/iplreboot/experiments/experiments/kernel/GTA%20stub/loader.c
https://github.com/mathieulh/3.90-M33/blob/master/experiments/iplreboot/experiments/experiments/kernel/dump_reboot_v2.6/copy.c


== reused index.dat key: PSP 2.00, 2.01 ==
== reused index.dat key: PSP 2.00, 2.01 ==


== swaptrick/kxploit: PSP <= 1.50 ==
== swaptrick/kxploit: PSP <= 1.50 ==
This exploit involved either swapping memory stick after loading a valid ELF with one that contained an unsigned one or using the path hack.


== kernel flagged ELF: PSP <= 1.00 ==
== kernel flagged ELF: PSP <= 1.00 ==
Line 849: Line 616:
Fixed: since PSP System Software version 6.35.
Fixed: since PSP System Software version 6.35.


= iplloader =
= Lib-PSP iplloader =


== NMI Backdoor ==
== NMI Backdoor ==
Line 861: Line 628:
Applicable to: None
Applicable to: None


Vulnerable: iplloader (all PSP bootrom versions, 0.7.0 and newer PSP DevKit Kbooti versions, PS Vita's PSP emulator bootrom)
Vulnerable: Lib-PSP iplloader (all bootrom versions, 0.7.0 and newer 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.
The Lib-PSP iplloader bootrom (present within Tachyon's IC package) as well as Lib-PSP 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.


This backdoor allows anyone in control of the memory location address 0xBC100000 to perform a jump to an arbitrary location defined in coprocessor register $9
This backdoor allows anyone in control of the memory location address 0xBC100000 to perform a jump to an arbitrary location defined in coprocessor register $9


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.
If value at address 0xBC100000 is not equal to 0 and coprocessor register $9 is set, Lib-PSP 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.


Below are the relevant pieces of code:
Below are the relevant pieces of code:
Line 882: Line 649:
</pre>
</pre>


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


== Arbitrary IPL Load Address ==
== Arbitrary IPL Load Address ==
Line 894: Line 661:
Fixed: Partially in Tachyon 0x00600000. The CPU scratchpad (0xA0010000 uncached; 0x80010000 cached) range is now blacklisted, whilst all other addresses remain allowed.
Fixed: Partially in Tachyon 0x00600000. The CPU scratchpad (0xA0010000 uncached; 0x80010000 cached) range is now blacklisted, whilst all other addresses remain allowed.


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.
Lib-PSP 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.


== Arbitrary IPL Entrypoint Address ==
== Arbitrary IPL Entrypoint Address ==
Line 904: Line 671:
Applicable to: IPL time code execution on 01g and 02g, used in Pandora
Applicable to: IPL time code execution on 01g and 02g, used in Pandora


Fixed: iplloader 2.6.0
Fixed: Lib-PSP 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.
Lib-PSP 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.


Note: The vulnerability is also present on Tachyon 0x00600000 and later, but cannot be exploited by itself due to an ECDSA signature (Kirk cmd 17) check.
Note: The vulnerability is also present on Tachyon 0x00600000 and later, but cannot be exploited by itself due to an ECDSA signature (Kirk cmd 17) check.
https://web.archive.org/web/20100409005536/http://my.malloc.us/silverspring/pandora-exploit/


== No minimum IPL block size ==
== No minimum IPL block size ==
Line 922: Line 687:
Fixed: Tachyon 0x00600000. Bootrom now requires a minimum IPL block size of 0x100.
Fixed: Tachyon 0x00600000. Bootrom now requires a minimum IPL block size of 0x100.


iplloader will not control the block size. This allows to craft a small, favorable for time-attack, IPL block.
Lib-PSP iplloader will not control the block size. This allows to craft a small, favorable for time-attack, IPL block.
 
https://web.archive.org/web/20100409005536/http://my.malloc.us/silverspring/pandora-exploit/


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


Found by: C+D/Prometheus - Earliest discovery: 2006 Q4
Found by: C+D/Prometheus - Earliest discovery: 2006 Q4
Line 936: Line 699:
Fixed: indirectly since Tachyon 0x00600000 as no IPL that run on Tachyon 0x00600000 and onwards have a block that uses a previous block checksum of 0 other than block #0 itself.
Fixed: indirectly since Tachyon 0x00600000 as no IPL that run on Tachyon 0x00600000 and onwards have a block that uses a previous block checksum of 0 other than block #0 itself.


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.
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 Lib-PSP iplloader.


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


Found by: Mathieulh - Earliest discovery: 2019 Q1
Found by: Mathieulh - Earliest discovery: 2019 Q1


Introduced: iplloader 3.5.0
Introduced: Lib-PSP iplloader 3.5.0


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


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


This is not so much a vulnerability as a poor design implementation.  
This is not so much a vulnerability as a poor design implementation.  


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.
To allow service centers to use a unique Memory Stick for multiple PSP models during servicing, Lib-PSP 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.


This allows a potential attacker with the ability to enable Jig mode on a targeted PSP to bypass the XOR step and thus not requiring to know the XOR key to gain execution at IPL time assuming that all other checks (Kirk cmd 1, Kirk cmd 1 ECDSA, Kirk cmd 0x6C SHA1 (on Tachyon 0x00600000 and later), ...) are passed.
This allows a potential attacker with the ability to enable Jig mode on a targeted PSP to bypass the XOR step and thus not requiring to know the XOR key to gain execution at IPL time assuming that all other checks (Kirk cmd 1, Kirk cmd 1 ECDSA, Kirk cmd 0x6C SHA1 (on Tachyon 0x00600000 and later), ...) are passed.


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


Found by: Proxima - Earliest discovery: 2020-01-27
Found by: Proxima - Earliest discovery: 2020-01-27


Introduced: iplloader 3.5.0
Introduced: Lib-PSP 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
Applicable to: Dumping the Lib-PSP 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
Fixed: probably never as 3.5.0 is the last known Lib-PSP 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.
3.5.0 Lib-PSP 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.


In Jig mode execution, the key is cleared much earlier, however resulting in the cache being synced once the key is already gone. This allows to easily retrieve the key using a XORed IPL block loaded at address 0xBFE01000.
In Jig mode execution, the key is cleared much earlier, however resulting in the cache being synced once the key is already gone. This allows to easily retrieve the key using a XORed IPL block loaded at address 0xBFE01000.


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)
While it may be possible that Tachyon 0x00600000 and later Lib-PSP iplloader fix this issue, it is irrelevant because the code should remain accessible as part of the Tachyon bootrom at address 0xBFC00000)


== Faulty ECDSA Hash Comparison ==
== Faulty ECDSA Hash Comparison ==
Line 980: Line 743:
Fixed: never
Fixed: never


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


This means that inserting two identical blocks in the chain will cancel the XOR change and the signature will remain valid.
This means that inserting two identical blocks in the chain will cancel the XOR change and the signature will remain valid.
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/Vulnerabilities"