Vulnerabilities

Lib-PSP iplloader (PRE-IPL)

NMI Backdoor

Found by: Mathieulh, Proxima, C+D/Prometheus - Earliest discovery: 2007-04-04

Introduced: Tachyon 0x00140000 bootrom

Fixed: Never

Vulnerable: Lib-PSP iplloader (all bootrom Versions, 0.7.0 and newer Kbooti versions, PSVita's PSP emulator 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

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:

ROM:BFC00004                 lw      $v0, 0xBC100000             # store 0xBC100000 to $v0
ROM:BFC0000C                 bnez    $v0, loc_BFC00064           # if $v0 (0xBC100000) is not equal to zero, jump to 0xBFC00064

ROM:BFC00064                 cfc0    $v0, $9                     # store coprocessor $9 to $v0
ROM:BFC00068                 beqz    $v0, loc_BFC00078 $         # if $v0 (coproc $9) is equal to 0 jump to 0xBFC00078
ROM:BFC0006C                 nop
ROM:BFC00070                 jr      $v0                         # jump to register $v0 (value initially set in coproc $9)

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

Arbitrary Load Address

Found by: C+D/Prometheus - Earliest discovery: 2007-04-04

Introduced: Tachyon 0x00140000 bootrom

Fixed: Partially in Tachyon 0x00600000 (03g) The CPU scratchpad (0xa0010000 uncached; 0x80010000 cached) range is now blacklisted, all other addresses are still allowed.

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 1, KIRK 1 ECDSA, KIRK 0x6C SHA1 (on 03g+), ...). This allows to potentially write a payload at arbitrary locations.

Arbitrary Entrypoint Address

Found by: C+D/Prometheus - Earliest discovery: 2007-04-04

Introduced: Tachyon 0x00140000 bootrom

Fixed: Lib-PSP iplloader 2.6.0

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.

No minimum IPL block size

Found by: C+D/Prometheus - Earliest discovery: 2007-04-04

Introduced: Tachyon 0x00140000 bootrom

Fixed: Tachyon 0x00600000 (03g)

Lib-PSP iplloader will not control the block size, this allows crafting a small, easier to time attack, IPL block (used in the Pandora hack).

On Tachyon 0x00600000 (03g) and newer, bootrom now requires a minimum IPL block size of 0x100.

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

Found by: C+D/Prometheus - Earliest discovery: Q4 2006

Introduced: Tachyon 0x00140000 bootrom

Fixed: indirectly since 03g as no IPL that run on 03g 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 Lib-PSP iplloader.

3.5.0 Lib-PSP iplloader and later (applicable to 03g+ retail systems) do not perform the XOR step when running in JIG/Service mode

Found by: Mathieulh - Earliest discovery: Q1 2019

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, 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 1, KIRK 1 ECDSA, KIRK 0x6C SHA1 (on 03g+), ...) are passed.

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

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

Introduced: Lib-PSP iplloader 3.5.0

Fixed: unknown (probably never) (this is the last known Lib-PSP iplloader revision for Development Tool.)

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.

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

Faulty ECDSA Hash compare implementation

Found by: Davee - Earliest discovery: 2021-02-12

Introduced: Tachyon 0x00600000 (03g)

Fixed: never

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 2 identical blocks in the chain will cancel the XOR change and the signature will remain valid.