« PlayStation 2 Architecture (index)

PlayStation 2 Architecture

Chapter 10: Anti-Piracy and Homebrew


Table of Contents

  1. DVD copy protection
  2. Circumventing protections
    1. Attacking the DVD drive
      1. Modchips
      2. Cheats
      3. Disc swapping
    2. Departing from modchips
    3. Independence overflow
    4. The signature exploit
    5. The universal solution
  3. Follow-up developments

There's quite a lot to talk about here, so let's start with the DVD reader, shall we?

DVD copy protection

This area was particularly concerning for game studios, since this console used a very affordable disc format to distribute games. Thus, the risk of piracy was high.

Image
This error screen could appear if the drive is faulty... or a pirated copy was inserted.

When the OS loads a game, it does so by sending specific commands to the DVD reader. The commands specifically used to read the content of a game behave very differently from standard DVD commands (i.e. to read a DVD movie). It turns out authorised games contain an out-of-reach 'map file' in the inner section of the disc that indexes the filesystem by name, position and size. When the DVD is asked to read a game disc, it will always navigate through the disc using the map file, meaning that a pirated copy of a game, which could not include the map file, will be impossible to read.

This was complemented by a region lock system that prevented imported games from working in a console from a different region.

Circumventing protections

Having explained the most critical parts of this console, let's take a look at multiple methods discovered (and commercialised) that defeated the protection mechanisms.

Attacking the DVD drive

As soon as the PS2 reached the stores, multiple third-party products appeared with the promise to 'unlock' the DVD drive. With no sign to support Homebrew (outside the Linux solution), piracy was the biggest beneficiary.

Modchips

As with any other console of its generation (and previous ones) using disc-based systems, it was a matter of time before third-party companies reversed-engineered the DVD subsystem. The goal here was to find a usable exploit that could force the driver to navigate through the file system without needing an out-of-reach map file.

This eventually materialised in the form of modchips, which lifted the copy protection checks and region-locking restrictions as well.

Cheats

Along with the modchips, which required soldering skills to install them, unauthorised but 'genuine' discs appeared in the market. These patched the Kernel to remove the region protection and use in-game cheats.

Most importantly, 'cheat discs' had the advantage of not requiring any modification on the console. I guess the best example to mention is CodeBreaker.

Disc swapping

In the middle of the latest advancements, yet another trick appeared. This time, exploiting the reader's handling of faulty sectors. Swap Magic looked like another 'genuine' disc, but its 'game' tells the DVD to read a non-existent executable found on a deliberately faulty sector, halting the driver altogether . This window of opportunity allowed users to swap the disc for a non-genuine one. Then Swap Magic, still loaded in memory, bootstrapped the main executable of the new disc, loading a real game at the end. All of this is carried out while the driver is still thinking a genuine disc is inserted.

This doesn't necessarily require altering the console. However, depending on the model, the external case of the PS2 will have to be tampered with to block the eject sensors of the drive. In some models, placing pieces of cotton in certain places was part of the walkthrough.

Departing from modchips

As time passed, more research was gathered and shared about this console. Consequently, new and more sophisticated discoveries led to a new wave of development that didn't rely on external hardware anymore, at least primarily. Furthermore, piracy wasn't the main focus anymore. Instead, the ability to run third-party programs without the approval of Sony (called Homebrew) quickly topped the goals chart.

Independence overflow

The PS2 stores a database file called TITLE.DB in MemoryCard which contains information used to optimise the emulation of PS1 games . When a PS1 game is inserted, the OS fetches the database file and loads the whole file in memory at a fixed address (strike one). The information parser is implemented using strncpy(), a function in C that copies strings (chains of characters) from one place to another.

For people familiar with C, you probably guessed where I'm going. The thing is that strncpy() doesn't know how long is a string, so unless it's terminated (by placing \0 at the end of the chain) the copy goes on 'forever' (with unpredictable results!). Luckily, this function contains an optional parameter that specifies the maximum number of bytes to be copied, protecting the copy from buffer overflows. As ludicrous as it may seem, Sony didn't use this parameter, even though each database entry has a fixed size of 256 bytes (strike two).

Upon closer inspection in RAM, TITLE.DB happens to be copied next to a saved register, $ra, which states the address to return after the current function being executed finishes (strike three), leading up to The independence exploit : Craft a TITLE.DB with a large string, embed an executable in it and design that string so $ra will be overridden to point to the executable. If you manage to upload that file to your Memory Card (through another exploit or a PC USB adapter) you got yourself a simple Homebrew launcher.

The discovery was published in 2003. Consequently, with the slim revision, Sony shipped a new BIOS ROM revision that patched this exploit. Curiously enough, it wasn't the last blunder that exposed clumsy code.

The signature exploit

In November 2007, a hacking group started selling Memor32 , just another typical third-party Memory Card, except that for some reason it housed an FPGA and a USB port. It wasn't until a firmware called Memento appeared on internet forums that the real nature of Memor32 became clear: To run unauthorised executables from the memory card, just like the Independence exploit.

The implementation of Memento relied on a flaw in the way the signature of the DVD player is checked. It was discovered that, while binaries have to be signed using Sony's keys, the integrity of the binary is not checked. So, anyone could replace the executable code with something else (that still fits in the same space) and the operating system will happily run it. The Memento firmware used this exploit to disguise its payload within the DVD player, and bundles a couple of utilities that would allow users to load games (either from the disc drive or the HDD).

However, the popularity of Memor32 and Memento was soon displaced once a free (and initially open-source) alternative arrived: FreeMCBoot.

The universal solution

Once Memento got reverse-engineered, an alternative that didn't require Memor32 appeared on the internet. FreeMCBoot exploited the same vulnerability except it could be installed on any MagicGate Memory Card. The only drawback is that another exploit (e.g. disc swapping) was still required to bootstrap the installer.

Interestingly enough, FreeMCBoot's user interface borrows assets from OSDSYS, thereby providing a familiar menu to launch other Homebrew. It also patches the Kernel to add APIs to access mass storage devices in the USB 1.1 ports, something many homebrew apps relied on to locate additional files.

Additionally, the installer provides two options: to install only the files needed for the current console, or install a global setup for all PS2 variants. Curiously enough, the latter option was challenging to accomplish . Initially, the installer would fiddle with the partition table of the Memory Card to avoid running out of space, something that wasn't particularly safe.

As luck would have it, in 2011, the security system of the PlayStation 3 had just been compromised, exposing many secrets hidden within. Among others, a collection of MagicGate keys globaly used for PS2 backwards compatibility. From then on, it was no longer needed to resort to the limited DVD binary signature trick to craft PS2 executables. And so, since version 1.8b, FreeMCBoot has maintained its position as the safest and most popular method for running any type of Homebrew on a PlayStation 2.

Follow-up developments

Once the avenue for running Homebrew became more accessible, progress continued in the form of polishing previous exploits and developing Homebrew applications. Some of the latter ultimately facilitated piracy-related functionality, but they also expanded the limited capabilities of the operating system (i.e. by providing patches on games), I guess it ultimately depended on the intentions of its users.

To name a few notable examples of homebrew-related developments:

Later years will also see new exploits uncovered:


Previous: 9. Games

Next: 11. That's all folks


Rodrigo Copetti © 2026 RSS Feed

Switch to modern edition

Home · Writings · Support · About author · About website