PlayStation Portable (PSP) Architecture

Just because this is a portable console doesn't mean it should have weaker security than the PS2. It's quite the opposite in all senses - the security system implemented on the PSP is very diverse, with some parts still remaining a mystery to this day.

Of course, we all know by now that its implementation contained pitfalls that eventually opened the door to Homebrew and piracy. Yet, considering that this was a console from 2004, certain design decisions can be considered ahead of time, especially when you compare them with the competition.

Physical security

I'm going to describe the three main chips responsible for security-related operations. The algorithms involved can be pretty complicated for first-timers, but I will try to provide a quick overview. Don't forget to consult the bibliography if you find the topic interesting, as this writing is primarily focused on the PSP itself.

KIRK

To start with, we've got KIRK, another component residing inside Tachyon. KIRK is the hardware implementation of the following cryptographic algorithms (think of it as an accelerator) :

• Advanced Encryption Standard (AES) encryption and decryption: a symmetric encryption system that operates with a given key. KIRK also provides a key vault of 128 keys and a master key, both 128 bits long, to encrypt and decrypt data.
• ECDSA: another asymmetric encryption system. It includes two functions:
  • Public-private key generation: used for encrypting and decrypting user data, such as save files.
  • Signature verification: validates and decrypts data encrypted by Sony. KIRK also stores Sony's public key for this purpose.
• SHA-1: generates a hash value from data. ECDSA depends on SHA during signature verification to ensure that the original data hasn't been tampered with.
• Cipher-based Message Authentication Code (CMAC): another algorithm used to decrypt and verify the integrity of the encrypted data (whether it comes from Sony or not) using a shared key. It relies on AES for decryption.
• Pseudo-random number generation: as the name indicates, it attempts to generate an unpredictable number for cryptographic use.

In short, the CPU issues commands to KIRK (for instance, "encrypt this string with algorithm x and key y"). KIRK can behave like a bus master as well, writing the results directly into main RAM.

Lepton

As you know, UMD discs are not easily duplicated, but their contents are also stored in encrypted form. Users never notice this, however, since the decryption process is handled by hardware too.

Alongside Tachyon sits another System-on-Chip known as Lepton, which controls the UMD drive and acts as a middleman between the main CPU and disc's contents.

Lepton contains an enormous amount of circuitry - you may even consider it another computer living inside the PSP. This component includes its own CPU, a DSP for decoding, 480 KB of memory (as buffer), and 384 KB of ROM for storing its firmware.

The main CPU communicates with Lepton using the ATAPI protocol, an interface traditionally used for plugging conventional CD/DVD drives into PCs. The critical difference, however, is that Lepton only decrypts data from a UMD if the disc is identified as authentic.

SPOCK

In addition to the encryption handled by Lepton, the sectors of an UMD are encrypted using AES. SPOCK is another block located next to KIRK that focuses on decrypting each sector of the UMD disc.

Inside the NAND Flash, IDStorage contains an encrypted key known as the 'master key'. SPOCK includes a hardwired key used to decrypt it. The decrypted master key is then used by SPOCK to decrypt another key found on the UMD, and that second key is finally used to read each sector. Easy-peasy!

By the way, even though SPOCK resides within Tachyon, it is operated by Lepton.

To sum up, having these routines in hardware allows the system to execute games without consuming general-purpose resources on encryption and decryption tasks.

Software security

The operating system uses the provided hardware to compose a security architecture. Overall, the software is protected using the following principles:

• Chain of trust: Pre-IPL, the first stage of the boot process, is a read-only piece of code written by Sony and embedded during manufacturing. Anything that Pre-IPL approves is deemed trustworthy, and this trust extends to all subsequent stages it loads.
• Signed executables: executables are not only encrypted, but also signed with keys that only Sony knows, ensuring that tampered data cannot be re-signed.
• Obscure hardware: KIRK, SPOCK, and Lepton are undocumented, obfuscated blocks of silicon that don't expose which algorithms are applied and how.
• Developer-proof security: the MMU's privilege modes restrict access to sensitive memory locations, protecting against the presence of user-level exploits in retail games (which lead to arbitrary code execution).

Defeat

Despite all these protections, hackers never gave up on this console. Maybe because the amount of functionality made it very attractive for Homebrew development.

The amount of work uncovered in this area is outstanding, so I've had to draw a line somewhere. Thus, only major breakthroughs are covered here. But, for those interested in the full picture, playstationdev.wiki keeps a good archive of every single discovery.

Early blunders

After the release of the PSP in Japan, it was only a matter of time before user-land exploits began to emerge. Some relied on multiple security flaws found in early versions of the firmware:

• The game 'Wipeout' embedded a web browser to access downloadable content. It wasn't protected against DNS attacks (domain hijacking), allowing users to browse any URL on the wider internet.
  • Later on, it was discovered that the browser's URL field didn't verify the input. So, entering file:///disc0:/ as URL would list the contents of the UMD, already in decrypted form. This gave hackers an opportunity to inspect PSP executables and reverse-engineer them.
• The first revision of the system didn't check for signatures on executables stored in the Memory Stick, allowing to run custom user modules (but not kernel ones).
  • This was probably accidental, as it's common practice for development units to skip signature checks. It seems Sony may have rushed the retail firmware and forgotten to re-enable the checks, like Microsoft.
• After this was patched, hackers discovered a flaw in the file system implementation that enabled to run unsigned code. In a nutshell, the user had to duplicate the folder containing the executable, append % to the name of the second folder, and strategically reorganise the contents of both folders.

These early blunders helped to build a knowledge base of the inner workings of the PSP, which led to more attack vectors and custom software that interacted with the hardware directly (remember, only game studios had access to the official SDKs and documentation).

As in any cat-and-mouse game, Sony responded with more system updates (which were required by new games). Meanwhile, newer discoveries, such as the so-called 'TIFF' and 'GTA' exploit continued to appear . It's worth mentioning that these early developments were only considered 'Homebrew launchers', as full kernel access had not yet been achieved.

Downgrading

The Chronoswitch downgrader, a modern downgrade tool.

As Sony gained momentum with stronger firmware updates (incorporating security patches next to attractive features, such as a web browser), old versions became some sort of promised land, where advanced users enjoyed the ability to run their Homebrew. However, finding a PSP with an exploitable system version became increasingly challenging. As a result, downgrading quickly grew in popularity. Downgrading is the opposite of upgrading: it involves replacing the firmware installed with an earlier (and better exploited) version.

A common approach for downgrading relied on executing an exploit that tricked the system into installing an older update file. This wasn't easy, as it depended on an ever-shrinking pool of exploits in the latest firmware releases.

Eventually, two 'modchips' reached the market: 'Undiluted Platinum' and 'PSP-Devolution'. Both shipped with a separate NAND chip used as secondary NAND storage, enabling the user to boot a secondary (and exploitable) firmware, or replace the primary one. This technique only supported the PSP model '1000', as later ones integrated Tachyon with NAND and DDR SDRAM into a single package.

Pandora

The cat-and-mouse game was the order of the day, until August 2007, with the arrival of Pandora .

The 'Pandora battery method' is a popular (and respected) collection of achievements. It managed to bypass most of the security layers, and focused on the only area Sony could not react quickly: Pre-IPL. This is what Pandora succeeded in :

1. Find a way of entering 'Service Mode': by tampering with the PSP's removable battery, which had some circuitry attached for identification purposes, hackers discovered that overriding its serial number value to 0xFFFFFFFF triggered Service Mode at boot time. In this state, Pre-IPL would look for a secondary system in the Memory Stick. The modified battery became known as JigKick or 'Pandora' Battery.
   • Users could craft a Jigkick battery using a hacked PSP, or by desoldering the ground pin of the battery's EEPROM. The latter was far riskier, considering casual users were disassembling a Lithium battery! Unsurprisingly, some third-parties began selling 'Pandora battery' makers.
   • Functionally speaking, a Jigkick battery behaves like any normal battery. However, when inserted, the PSP will always boot from the Memory Stick.
2. Trick 'Service mode' into loading a fake/unsigned firmware: the next step required to find a way to load a fake IPL in Service Mode. The main challenge was that the executable still had to be encrypted and signed to work. Well, hackers found a way to bypass this. Essentially, the process worked as follows:
   1. Even though IPL is encrypted in batches of 1 KB of code, hackers found out that KIRK could be instructed to decrypt smaller sizes, leaving the rest of the code untouched.
   2. With the use of brute force, a special binary could be crafted so, when KIRK decrypts it, it only contained an instruction similar to 'jump 100 bytes down'.
   3. Combining the two above, hackers crafted a binary that contained the encrypted jump instruction along with unencrypted code. All in all, this enabled arbitrary code execution with maximum privileges in Service Mode.
   4. The custom IPL code in the Memory Stick could only reside at specific sectors. Consequently, special programs were developed to assist with this. A Memory Stick with a custom IPL installed to this location is called Magic Memory Stick.

After this, all that remained was to embed a useful payload. Popular options included:

• A de-bricker, which reinstalled a clean official firmware, repairing consoles with corrupted NANDs.
• A downgrader, now enjoying greater permissions.
• A custom firmware installer, which I explain more in a bit.

It's important to mention this was a tremendous discovery, especially considering that KIRK had not yet been fully reverse-engineered, and the encrypted block that made Pre-IPL 'jump' had to be brute-forced.

CFW and beyond

Some CFWs include special modules to operate low-level options.

The Pandora method dealt a big blow to Sony - it was an effective bootrom exploit, and much like the case of the Nintendo DS, fixes could only ship in the form of new hardware revisions.

One of the main applications of Pandora were Custom Firmwares (CFW). A CFW is an official firmware modified to include additional functionality, such as homebrew modules. These customisations enjoyed kernel privileges and had complete control of the console. Examples of new modules included ISO loaders, signature disablers, low-level CPU management, a 'plugin' loader (allowing further customisations without reinstalling the firmware), and many, many more. Various groups packaged their own variants, such as M33, PRO, and ME.

A CFW needs to be installed first, and the installer depends on a kernel-level exploit. Well, thanks to Pandora, this was no longer a challenge. However, Sony eventually fixed the vulnerabilities leading to Pandora, meaning later PSP shipments were limited to the traditional software-based exploit methods.

Ultimately, the last straw came when the security system of the PlayStation 3 was compromised. The PS3 stored the private keys used to decrypt PSP executables (as its operating system includes a PSP emulator). Once they were extracted, it allowed anyone to sign user-land software and embed a kernel exploit, for instance, to bootstrap a CFW installer or a CFW loader.

As of 2021, it was recently discovered that the latest firmware contains a kernel-level vulnerability during the boot process, which can then be used to kickstart a CFW of choice. This was packaged in a solution called Infinity 2 .

Homebrew encouragement

Breaking security was not the only goal from the Homebrew community; there were also groups committed to providing necessary tools to build software without legal repercussions. For instance, the pspdev group published an open-source SDK called PSPSDK that replicated many of the official interfaces, while removing restrictions previously imposed by Sony.

PSPSDK also includes a toolkit to handle the compilation and packaging process, just like the official SDK, but designed for PSPs running a CFW instead.