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 the versatility of the DVD meant the risk of piracy was high.
PS2 Logo showing after a valid PS2 game is inserted.
This error screen could appear if the drive is faulty... or a pirated copy was inserted.
When the operating system (OSDSYS) loads a game, it does so by executing PS2LOGO from the disc . This program displays the iconic 'PlayStation 2' logo and then proceeds to boot the game executable.
In a genuine pressed disc, PS2LOGO is stored in the first 12 sectors of the disc and encrypted with a unique per-disc key . MechaCon derives the key by reading the Title ID information from the Absolute Time in Pregroove (ATIP) location on the inner part of the disc . Sony altered its standard application using a proprietary frequency based on the region.
MechaCon then decrypts the executable and uses the previous information to authenticate it and validate its region. This process is abstracted away from OSDSYS, which relies on the CDVDMAN IOP driver to communicate with the DVD subsystem .
Circumventing protections
Having explained the most critical parts of this console, let's take a look at multiple discovered (and commercialised) methods that defeated its protection mechanisms.
Attacking the DVD drive
As the PS2 was selling in stores, numerous third-party products started appearing with the promise to 'unlock' the DVD drive. With no sign to support Homebrew (outside the Linux solution), piracy was the primary beneficiary.
Modchips
As with any other console of its generation (and previous ones) using disc-based systems, it was only a matter of time before third-party companies managed to reverse-engineer the DVD subsystem. The goal here was to find a way of tricking MechaCon into believing the pirated copy was genuine, and then executing it.
This eventually materialised in the form of modchips, which lifted the copy protection checks and region-locking restrictions.
The earliest variants, such as Neo 2, treated MechaCon as a black box, relying instead on mimicking the PS1's Wobble Groove to play pirated PS1 discs. They could also be combined with a swap trick (explained later) to boot PS2 discs. Later modchips, like Messiah, tampered directly with MechaCon and BIOS buses. In doing so, they bypassed decryption and forced the subsystem to approve the inserted disc.
Disc swapping
Amidst these advancements, yet another trick emerged. This time, it exploited the DVD drive's handling of faulty sectors. Swap Magic resembled a 'genuine' disc, but its 'game' instructed the drive to read a non-existent executable located on a deliberately faulty sector, causing the driver to halt altogether . This window of opportunity allowed users to replace the disc with a non-genuine one. Then, Swap Magic, still loaded in memory, bootstrapped the main executable of the new disc.
This did not necessarily require altering the console. However, depending on the model, the external case of the PS2 had to be altered to block the drive's eject sensors. For some models, placing cotton wool in certain places was part of the walkthrough.
Departing from modchips
As time passed, more research about this console was gathered and shared. Consequently, new and more sophisticated discoveries led to a new wave of development that no longer relied on external hardware, 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 on the Memory Card, 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 (sequences of characters) from one place to another.
Those familiar with C have likely guessed where I'm going. The thing is that strncpy() doesn't know how long a string is; therefore, unless it's terminated (by placing \0 at the end of the sequence), the copy goes on indefinitely (with unpredictable results!). Luckily, this function accepts 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 to after the currently executing function finishes (strike three), leading to the independence exploit : Craft a TITLE.DB with a large string, embed an executable within it, and structure the string so that $ra is overridden to point to the executable. If you manage to upload that file to your Memory Card (via 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 to expose clumsy code.
The signature exploit
In November 2007, a hacking group began 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 true nature of Memor32 became clear: it was designed to run unauthorised executables from the Memory Card, much like the Independence exploit.
The implementation of Memento relied on a flaw in how the signature of the DVD player is checked. It was discovered that, while binaries had to be signed using Sony's keys, the integrity of the binary was not verified. So, anyone could replace the executable code with an alternative payload (provided it still fitted within the same allocated space), and the operating system would happily run it. The Memento firmware used this exploit to disguise its payload within the DVD player, and bundled a couple of utilities that allowed users to load games (either from the disc drive or the HDD).
However, the popularity of Memor32 and Memento was soon eclipsed once a free (and initially open-source) alternative arrived: FreeMCBoot.
The universal solution
Once Memento was reverse-engineered, an alternative that didn't require Memor32 appeared on the internet. FreeMCBoot exploited the same vulnerability, except that it could be installed on any MagicGate Memory Card. The only drawback was 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 via the USB 1.1 ports, something many homebrew apps relied on to locate additional files.
Additionally, the installer provides two options: either to install only the files needed for the current console, or to 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 them was a collection of MagicGate keys globally 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 for games). I guess it ultimately depended on the intentions of its users.
To name a few notable examples of homebrew-related developments:
- FreeHDBoot: A variant of FreeMCBoot that instead installs on the HDD, from which the system will also try to boot.
- ps2sdk by the ps2dev group : The de facto unofficial SDK for writing PS2 Homebrew without risk of copyright infringement. The project dates back to 2000, when it was only available in the form of loose libraries for accessing particular components , and was, over time, unified into a single package for the benefit of Homebrew developers.
- LaunchELF by multiple authors : A file manager with extra utilities. It was later succeeded by 'uLaunchELF' and, finally, 'wLaunchELF'.
- Open USB Loader (OPL) by multiple authors : Enables to boot disc images from multiple sources (HDD, USB, i.Link, and even SMB and NMB over Ethernet) with patching capabilities.
- ESR by ffgriever : Originally called 'Vast CDVDV', this is an application that tricks the whole system (including the DVD drive) into running a burned copy of a game without hardware modification. The original game content must be patched to disguise itself as a DVD movie (so the DVD drive doesn't reject it), while ESR takes control of the Emotion Engine and IOP to redirect execution to the actual game.
- PSBBN Definitive Project by CosmicScale : A large suite containing PSBBN with numerous patches and enhancements for seasoned Homebrew users. Not only does it make the original PSBBN interface accessible to international audiences by including English translations, but it also unlocks its limitations by incorporating many Homebrew modules that improve the experience of each area of PSBBN.
Later years also saw new exploits uncovered:
- Fortuna by krat0s : An alternative Homebrew launcher published in 2019 that relies on a completely different exploit. This time, it's a buffer overflow in the icon parser of the saves manager (part of
OSDSYS) . Its main advantage is compatibility with late PS2 models that removed support for externalOSDSYSupdates (i.e. the models FreeMCBoot left out). - OpenTuna by alexparrado : An open-source alternative to Fortuna originating from reverse-engineering the latter.
- FreeDVDBoot by cturt : A modern vulnerability published in 2020. It consists of a new buffer overflow in the DVD player that can be exploited to perform arbitrary code execution. Users only need to burn a DVD with FreeDVDBoot to execute any binary they wish, including the FreeMCBoot installer or even ESR (Sony was very lucky that this hadn't been discovered many years earlier! as others weren't).
- MechaPwn by balika011 et al. : The
SCPH-500XXrevision (2003) stores encrypted MechaCon firmware updates in the EEPROM. 18 years later, MechaPwn emerged to exploit theWriteConfigroutine in MechaCon to inject crafted firmware update files into the EEPROM. These disable a significant portion of the CD/DVD anti-piracy measures and region locking.- MechaCon uses a DES encryption system to store firmware updates. Thus, MechaPwn brute-forced the key to install its custom firmware.