Script Extenders (SKSE) et hooking de moteur de jeu : La machine virtuelle Papyrus, l'injection de code nativo et le découplage via Address Library

Introduction : L'architecture du modding chez Bethesda et les limites du moteur

Depuis plus d'une décennie, le Creation Engine de Bethesda Game Studios—moteur emblématique de The Elder Scrolls V: Skyrim et Fallout 4—a vu naître l'un des écosystèmes de modifications (mods) les plus riches et les plus créatifs de l'histoire du jeu vidéo sur PC. Des dizaines de milliers de développeurs communautaires ont métamorphosé le jeu original en un chef-d'œuvre technique moderne, intégrant des combats dynamiques, des éclairages volumétriques en temps réel, des interfaces repensées et des simulations physiques complexes.

Cependant, le moteur de jeu impose par nature de sévères garde-fous aux créations externes. L'outil officiel, le Creation Kit, repose sur un langage de script interprété et isolé dans un bac à sable (sandbox), baptisé Papyrus. Bien qu'il protège efficacement le système contre les corruptions mémoires critiques, Papyrus subit un bridage délibéré de ses cycles d'exécution (time-slicing), n'a aucun accès direct au matériel et ne peut interagir ni avec la mémoire brute, ni avec les périphériques modernes, ni avec les interfaces utilisateur avancées.

Afin de surmonter ces contraintes, la communauté du rétro-ingénierie a conçu le Skyrim Script Extender (SKSE). Agissant comme un injecteur natif en C++, SKSE intercepte l'exécutable du jeu directement en mémoire RAM lors du démarrage, enrichit la machine virtuelle Papyrus de centaines d'instructions en code machine natif et permet l'exécution directe de bibliothèques dynamiques (plugins DLL) externes.

Comprendre les rouages qui unissent SKSE, la machine virtuelle Papyrus et l'adressage dynamique est fondamental pour diagnostiquer les retours inopinés au bureau (Crash to Desktop, CTD), prévenir le gonflement destructeur des sauvegardes et surmonter les mises à jour régulières de l'exécutable officiel.

La machine virtuelle Papyrus : Boucles d'événements, bytecode et bridage des threads

Lors de la conception de Papyrus, Bethesda a érigé la stabilité globale du jeu en impératif absolu, au détriment délibéré des performances brutes :

[Code source du script (.psc)] ──> Compilateur Papyrus ──> Bytecode binaire (.pex)
                                                                 │
                                                                 ▼
[Boucle principale du Creation Engine]                   [Machine virtuelle Papyrus]
   Image 1: Rendu -> Physique -> Logique ─────────> Quota de temps alloué (~1.2 ms)
   Image 2: Rendu -> Physique -> Logique ─────────> Exécute les opcodes de bytecode
                                                    (Mis en pause si dépassement)

1. Bytecode et exécution sandboxée

Les créateurs rédigent leurs scripts dans des fichiers texte .psc, ensuite compilés en bytecode binaire .pex. Le moteur ne confie pas ce code directement au processeur physique ; il l'interprète instruction par instruction au sein d'une machine virtuelle (VM) dédiée :

• Architecture orientée événements : Les scripts s'attachent à des entités précises du monde (personnages, quêtes, sorts) et réagissent aux déclenchements transmis par le moteur (tels que OnHit lors d'un coup, OnEquipped lors de l'équipement d'un objet ou OnTriggerEnter au franchissement d'un volume).
• Protection de la mémoire : Papyrus interdit tout maniement de pointeurs directs ou d'adresses physiques en RAM. Même si un script boucle indéfiniment ou tente une division par zéro, l'erreur est interceptée par la machine virtuelle et consignée dans un journal, sans générer de violation d'accès fatale sous Windows (Access Violation 0xC0000005).

2. Multitâche coopératif et budget temporel par image

Afin d'éviter qu'un script défaillant ne fasse chuter la fréquence d'affichage des images, Papyrus applique un ordonnancement coopératif strict :

• Le moteur accorde à la machine virtuelle un infime budget de calcul par image rendue (généralement compris entre 1.2 et 2.0 millisecondes).
• Dès qu'une boucle dépasse cette enveloppe, la VM suspend le thread en cours et remet la suite de son exécution aux images ultérieures.
• Le goulot d'étranglement des scripts : Si ce mécanisme garantit la fluidité du jeu de base, l'accumulation de mods complexes (survie, météo dynamique, arbres comportementaux d'IA) engorge la file d'attente. Il en résulte un "script lag" prononcé, où les touches pressées et les déclencheurs mettent plusieurs secondes à produire leur effet en jeu.

Les rouages de SKSE : Injection de processus, interception mémoire et fonctions natives

SKSE s'affranchit de ces limites en modifiant en temps réel la structure en mémoire de l'exécutable SkyrimSE.exe (format Windows PE - Portable Executable).

[skse64_loader.exe Chargeur externe]
       │
       ├─ 1. Crée le processus en état suspendu (CREATE_SUSPENDED)
       ├─ 2. Injecte skse64.dll dans l'espace mémoire via un appel LoadLibraryW distant
       ├─ 3. Lève les protections en écriture (VirtualProtect) et patche la VTable
       └─ 4. Relance le thread principal du jeu (ResumeThread)
               │
               ▼
[Espace mémoire du processus SkyrimSE.exe]
   ├── Code natif du moteur (Moteur de rendu DirectX, physique Havok, audio)
   ├── Machine virtuelle Papyrus
   │     └── [Table VTable modifiée]: Registre des fonctions natives C++ (Code machine)
   └── Gestionnaire de plugins SKSE
         └── Charge les DLL tierces depuis "Data/SKSE/Plugins/"

1. Le chargeur et l'injection par thread distant

Lors du lancement du jeu via skse64_loader.exe, une succession précise d'appels système s'opère :

1. Le chargeur appelle l'API Windows CreateProcess avec le paramètre CREATE_SUSPENDED, générant le processus dans la mémoire mais immobilisant son thread principal avant la moindre instruction en assembleur.
2. Il réserve de la mémoire avec VirtualAllocEx, y écrit le chemin de skse64.dll, puis déclenche CreateRemoteThread pour exécuter LoadLibraryW, forçant le binaire de Skyrim à charger le cœur de SKSE.
3. SKSE fait appel à VirtualProtect pour convertir la section de code initialement protégée en lecture seule (PAGE_EXECUTE_READ) en zone inscriptible (PAGE_EXECUTE_READWRITE), place des crochets de déviation (trampolines) sur les fonctions maîtresses, puis libère l'exécutable avec ResumeThread.

2. Enregistrement de fonctions natives en code machine C++

Une fois implanté, SKSE intercepte la table d'association de fonctions de la machine virtuelle Papyrus. Lorsqu'un mod fait appel à une instruction étendue SKSE (comme la détection absolue du curseur ou l'inspection d'inventaires non compressés), la VM délaisse l'interprétation lente du bytecode et saute instantanément vers une routine C++ précompilée dans skse64.dll, exécutée à la vitesse pure du processeur.

La crise de la compatibilité binaire : Mises à jour officielles et Address Library

Pendant de nombreuses années, le cauchemar récurrent des utilisateurs de mods résidait dans les micro-patchs officiels. La moindre mise à jour mineure déployée par Bethesda entraînait le dysfonctionnement immédiat de tous les plugins DLL à travers le monde.

Le problème des décalages d'adresses (offsets)

Dès lors que Bethesda retouche quelques lignes de code source et recompile SkyrimSE.exe :

• Le compilateur réagence l'ensemble des instructions, décalant l'adresse mémoire de chaque fonction interne.
• Une fonction située à l'offset 0x005A3210 en version 1.5.97 se retrouve déplacée à 0x005B48F0 en version 1.6.640.
• Les anciens plugins DLL contenant des adresses codées en dur tentent d'écrire ou de sauter vers l'ancien emplacement désormais invalide, provoquant un arrêt immédiat pour violation d'accès (CTD).

[Skyrim Version 1.5.97]                          [Skyrim Version 1.6.640]
Offset 0x005A3210: GetPlayerCamera() ──Recompilation─> Offset 0x005B48F0: GetPlayerCamera()
       ▲                                                    ▲
       │ (Pointeur fixe erroné -> Plantage immédiat !)      │
[Ancien plugin DLL à offset fixe] ────────────────── (Access Violation 0xC0000005)

Le paradigme d'Address Library et de CommonLibSSE

Pour éradiquer cette vulnérabilité, la communauté a établi le système Address Library for SKSE Plugins :

1. Base de données universelle d'identifiants : Un répertoire recense l'ensemble des fonctions clés du moteur sur toutes les versions parues, en leur attribuant un identifiant numérique fixe et permanent (ID numérique).
2. Résolution dynamique à l'exécution : Les plugins DLL modernes n'inscrivent plus d'adresses en dur ; ils interrogent la base de données au démarrage par le biais de CommonLibSSE :

   // Le plugin demande l'adresse en mémoire de la caméra au démarrage
   uintptr_t targetAddress = AddressLibrary::GetAddress(52147);
   

3. Pérennité face aux mises à jour : Lorsqu'un nouveau patch officiel est publié, seule la base de données centrale d'Address Library doit être actualisée. Les centaines de plugins DLL existants demeurent pleinement opérationnels sans exiger de recompilation par leurs créateurs.

Architecture des fichiers de sauvegarde, scripts orphelins et vidages de pile Papyrus

Une spécificité technique déterminante du format de sauvegarde de Skyrim (.ess) est que l'état dynamique complet de la machine virtuelle Papyrus est directement sérialisé à l'intérieur du fichier lors de chaque sauvegarde.

[Structure interne d'un fichier de sauvegarde .ess]
  ├── État mondial global (Enregistrements FormID, climat, horloge interne)
  ├── Inventaire du joueur et progression des quêtes
  └── [Instantané figé de la machine virtuelle Papyrus]
        ├── Toutes les instances de scripts en cours d'exécution
        ├── Valeurs des variables et pointeurs d'objets du monde
        └── Piles d'appels des threads suspendus en attente de temps de calcul

Le risque critique de désinstaller des mods scriptés en pleine partie

Lorsqu'un mod comportant des scripts est supprimé d'une partie entamée :

1. Les fichiers .pex sont retirés du disque dur, mais le fichier .ess garde en mémoire l'intégralité des instances actives et des événements programmés de ce script.
2. À chaque chargement ultérieur, la machine virtuelle tente de restaurer ces entités. Ne trouvant plus le fichier .pex adéquat, elle multiplie les alertes d'erreurs dans Papyrus.0.log.
3. Ces routines privées de leurs fichiers sources deviennent des scripts orphelins (Orphaned Scripts) que la machine virtuelle ne peut jamais purger. Ils engendrent avec le temps un gonflement destructeur du fichier de sauvegarde (Save Bloat), des ralentissements et la corruption irrémédiable de la partie.

Vidages de pile (Stack Dumps) et congestion de la machine virtuelle

Si un script entre dans une boucle récursive infinie ou se fige en attendant un objet supprimé par un autre mod, son thread refuse de céder son temps d'exécution. Dès que les tâches accumulées dépassent le seuil de tolérance interne de la VM, le moteur déclenche un Vidage de Pile (Stack Dump) dans les journaux, signal formel d'un effondrement imminent de la file de scripts débouchant sur un retour forcé au bureau.

Matrice de diagnostic : Extenseurs de scripts, conflits DLL et plantages (CTD)

La maîtrise des mécanismes de hooking et de virtualisation de scripts transforme la résolution des conflits de mods en une véritable démarche d'ingénierie logicielle. Grâce aux analyses détaillées disponibles sur 365Finds, les passionnés et les créateurs peuvent aborder sereinement les problématiques d'injection mémoire, d'interfaçage binaire et de pérennité des sauvegardes pour concevoir des configurations riches et d'une remarquable stabilité.

Références

• Skyrim Script Extender (SKSE) Official Archive - Silverlock
• Dynamic-Link Libraries - Win32 apps | Microsoft Learn
• Applicable PE Format Specifications - Win32 apps | Microsoft Learn
• VirtualProtect Function (memoryapi.h) - Win32 apps | Microsoft Learn