« Architecture de la PlayStation 2 (index)

Architecture de la PlayStation 2

Chapter 10: Anti-Piratage et Homebrew


Table des matières

  1. Protection contre la copie de DVD
  2. Contournement des protections
    1. Attaque du lecteur DVD
      1. Modchips
      2. Codes de triche
      3. Échange de disques
    2. Départ des modchips
    3. Independence overflow
    4. L'exploit de la signature
    5. La solution universelle
  3. Développements ultérieurs

Il y a beaucoup à dire à ce propos, alors commençons par le lecteur DVD?

Protection contre la copie de DVD

Cette section était particulièrement préoccupante pour les studios de jeux, car cette console utilisait un format de disque très abordable pour distribuer des jeux. Ainsi, le risque de piratage était élevé.

Image
Ce message d'erreur peut apparaitre si le disque est cassé... Ou qu'une copie piratée est insérée.

Quand l'OS charge un jeu, il le fait en envoyant des commandes spécifiques au lecteur DVD. Ces commandes spécifiques lisaient le contenu du jeu d'une manière très différent des commandes DVD standards (i.e pour lire un film DVD). Il apparait que les jeux autorisés contenaient une 'map file' hors de portée dans la section interne du disque, qui indexait le système de fichiers en utilisant le nom, la position et la taille. Quand on demandait au lecteur DVD de lire un disque de jeu, il naviguait toujours dans le disque en utilisant la 'map file', ce qui veut dire qu'une copie piratée d'un jeu, qui n'incluait pas la 'map file' était impossible à lire.

Le tout était complémenté par un système de verrouillage géographique qui empêchait les jeux importés de fonctionner sur une console d'une région géographique différente.

Contournement des protections

Après avoir expliqué les parties les plus critiques de cette console, passons en revue les différentes méthodes découvertes (et commercialisées) qui ont contourné les mécanismes de protection.

Attaque du lecteur DVD

Dès que la PS2 a atteint les magasins, de nombreux produits tiers sont apparus avec la promesse de 'déverrouiller' le lecteur DVD. Ne voyant aucun signe de support pour Homebrew (en dehors de la solution Linux), le piratage était le principal bénéficiaire.

Modchips

Comme pour toute autre console de sa génération (et celles d'avant) utilisant des systèmes basés sur des disques, ce n'était qu'une question de temps avant que des entreprises tierces ne fassent de la rétro-ingénierie sur le sous-système DVD. Le but était de trouver une faille exploitable qui pourrait forcer le pilote à naviguer dans le système de fichiers sans avoir besoin d'un fichier map hors de portée.

Cela s'est finalement matérialisé sous la forme de modchips, qui ont également levé les contrôles de protection contre la copie et les restrictions de verrouillage régional.

Codes de triche

En plus des modchips, qui nécessitaient des compétences en soudure pour être installés, des disques non autorisés mais 'authentiques' sont apparus sur le marché. Ces disques ont patché le Kernel pour supprimer la protection régionale et utiliser des cheats en jeu.

Le plus important, c'est que les disques 'cheat' avaient l'avantage de ne nécessiter aucune modification sur la console. Je suppose que le meilleur exemple à mentionner est le CodeBreaker.

Échange de disques

Au beau milieu des dernières avancées, d'autres astuces apparurent. Cette fois, l'astuce exploitait la gestion des secteurs défectueux par le lecteur. La Swap Magic ressemblait à un autre disque 'authentique', mais son 'jeu' disait au lecteur DVD de lire un exécutable inexistant trouvé sur un secteur défectueux délibéré, arrêtant ainsi complètement le pilote . Cette fenêtre d'opportunité permettait aux utilisateurs de changer ce disque pour un disque non-authentique. Puis, Swap Magic, toujours chargé en mémoire, démarrait l'éxecutable princiapl du disque, chargant un vrai jeu à la fin. Tout ceci se passait pendant que le pilote de périphérique pensait qu'un dique authentique était inséré.

Cela ne demandait pas de modifier la console. Cependant, en fonction du modèle, le boitier extérieur de la PS2 devait être trafiqué pour bloquer les capteurs d'éjection du lecteur de disque. Dans certains modèles, placer des morceaux de coton à certains endroits faisait partie de la méthode.

Départ des modchips

Avec le temps, plus de recherches ont été rassemblées et partagées sur cette console. Par conséquent, de nouvelles découvertes plus sophistiquées ont conduit à une nouvelle vague de développement qui ne dépendait plus du matériel externe, au moins principalement. De plus, le piratage n'était plus le principal objectif. Au lieu de cela, la capacité de faire fonctionner des programmes tiers sans l'approbation de Sony (appelée Homebrew) a rapidement dominé les objectifs.

Independence overflow

La PS2 mémorise sur la carte mémoire un fichier de base de données nommé TITLE.DB, qui contient des informations pour optimiser l'émulation des jeux PS1 . Quand un jeu PS1 est inséré, l'OS charge le fichier de base de données et le copie en mémooire à une adresse prédéterminée (attaque numéro 1). L'analyseur d'informations est implémenté en utilisant strncpy(), une fonction en C qui copie des chaînes (chaînes de caractères) d'un endroit à un autre.

Pour les gens familiers avec le C, vous voyez probablement où je veux en venir. Le truc, c'est que strncpy() ne connait pas la longueur d'une chaine de caractère, donc à moins qu'elle soit terminée (en plaçant \0 à la fin de la chaine), la copie continue 'indéfiniment' (avec des résultats inprévisibles). Heureusement, cette fonction contient un paramètre optionnel qui spécifie le nombre maximal d'octets à copier, protégeant la copie d'un dépassement de tampon. Aussi incroyable que cela puisse paraitre, Sony n'a pas utilisé ce paramètre, alors que chaque entrée de la base de donnée a une taille fixe de 256 octets (attaque numéro 2).

Après une inspection plus poussée dans la RAM, TITLE.DB se trouve copiée à côté d'un registre sauvegardé, $ra, qui indique l'adresse à laquelle revenir après la fin de l'exécution de la fonction en cours (attaque numéro 3), conduisant à The independence exploit : Créez un TITLE.DB avec une grande chaîne, intégrez un exécutable et concevez cette chaîne de manière à ce que $ra soit réécrite pour pointer vers l'exécutable. Si vous parvenez à télécharger ce fichier sur votre Memory Card (grâce à une autre faille de sécurité ou un adaptateur USB pour PC), vous obtenez un simple Homebrew launcher.

La découverte a été publiée en 2003. Par conséquent, avec la révision slim, Sony a expédié une nouvelle révision de la ROM BIOS qui a corrigé cette faille. Curieusement, ce n'était pas la dernière gaffe à exposer du code mal branlé.

L'exploit de la signature

En novembre 2007, un groupe de hackers a commencé à vendre Memor32 , juste une autre Memory Card tierce typique, sauf que pour une raison quelconque, elle contenait un FPGA et un port USB. Il a fallu attendre qu'un firmware appelé Memento apparaisse sur les forums internet pour que la vraie nature du Memor32 devienne claire : exécuter des exécutables non autorisés depuis la Memory Card, tout comme l'exploit Independence.

L'implémentation de Memento s'appuyait sur une faille dans la façon dont la signature du lecteur DVD est vérifiée. Il a été découvert que, bien que les binaires doivent être signés en utilisant les clés de Sony, l'intégrité du binaire n'est pas vérifiée. Ainsi, n'importe qui pouvait remplacer le code exécutable par autre chose (qui s'adapte toujours dans le même espace) et le système d'exploitation l'exécuterait joyeusement. Le firmware Memento utilisait cet exploit pour déguiser sa charge utile au sein du lecteur DVD et intègre quelques utilitaires qui permettent aux utilisateurs de charger des jeux (soit à partir du lecteur de disque, soit à partir du disque dur).

Cependant, la popularité du Memor32 et du Memento fut rapidement éclipsée une fois qu'une alternative gratuite (au départ open-source) est arrivée : FreeMCBoot.

La solution universelle

Une fois que Memento a été rétro-ingénieré, une alternative qui ne nécessitait pas le Memor32 est apparue sur Internet. FreeMCBoot a exploité la même vulnérabilité sauf qu'il pouvait être installé sur n'importe quelle carte mémoire MagicGate. Le seul inconvénient est qu'un autre exploit (par exemple l'échange de disques) était encore nécessaire pour démarrer l'installateur.

Assez curieusement, l'interface utilisateur de FreeMCBoot emprunte des éléments de OSDSYS, fournissant ainsi un menu familier pour lancer d'autres Homebrews. Il modifie également le noyau pour ajouter des API afin d'accéder aux dispositifs de stockage de masse dans les ports USB 1.1, dont de nombreuses applications homebrew dépendaient pour localiser des fichiers supplémentaires.

De plus, l'installateur offre deux options : installer uniquement les fichiers nécessaires pour la console actuelle, ou installer une configuration globale pour toutes les variantes de la PS2. Fait curieux, cette dernière option a été difficile à réaliser . Initialement, l'installateur modifiait la table de partition de la carte mémoire pour éviter de manquer d'espace, ce qui n'était pas particulièrement sûr.

Comme par chance, en 2011, le système de sécurité de la PlayStation 3 venait d'être compromis, révélant de nombreux secrets cachés à l'intérieur. Parmi eux, une collection de clés MagicGate utilisées globalement pour la compatibilité descendante PS2. À partir de ce moment, il n'était plus nécessaire de recourir à l'astuce de la signature binaire limitée du DVD pour fabriquer des exécutables PS2. Et donc, depuis la version 1.8b, FreeMCBoot a maintenu sa position comme la méthode la plus sûre et la plus populaire pour exécuter tout type de Homebrew sur une PlayStation 2.

Développements ultérieurs

Une fois qu'il est devenu plus facile d'exécuter du Homebrew, les progrès ont continué sous la forme de polissage des exploits précédents et du développement d'applications Homebrew. Certains de ces derniers ont finalement facilité certaines fonctionnalités liées au piratage, mais ils ont également étendu les capacités limitées du système d'exploitation (c'est-à-dire en fournissant des correctifs sur les jeux), je suppose que cela dépendait finalement des intentions de ses utilisateurs.

Pour nommer quelques exemples notables de développements liés aux homebrews :

Les années suivantes verront également de nouveaux exploits découverts :


Previous: 9. Jeux

Next: 11. C'est tout pour le moment


Rodrigo Copetti © 2026 RSS Feed

Basculer vers l'édition moderne

Accueil · Articles · Support · À propos de l'auteur · À propos du site