La demande la plus simple
Conservé tel qu’écrit avant la fermeture des serveurs le 30 juin 2026. Les demandes ci-dessous, et les échéances qu’elles supposent, restent dans leur état d’origine.
Le plus petit ensemble de gestes que Bethesda pourrait faire pour permettre à la communauté de garder Blades en vie sur toutes les plateformes après le 30 juin 2026 — sans implication continue de Bethesda ou Microsoft.
Tout ce qui suit tient en une idée : une dernière version client pensée pour la préservation, plus un court document de passation technique. Le cadrage stratégique expliquant pourquoi un éditeur pourrait répondre à cette demande se trouve sur la page stratégie ; celle-ci détaille le volet technique.
Une version iOS sans FairPlay.
Une dernière version du client iOS débarrassée du chiffrement FairPlay, publiée librement. Sans cela, la préservation sur iOS est impossible.
Les binaires de l’App Store sont chiffrés avec FairPlay ; les déchiffrer nécessite un appareil jailbreaké sur la bonne génération d’iOS. Sans IPA propre, des outils comme AltStore et Sideloadly ne peuvent rien faire. La communauté n’a aucun moyen d’obtenir seule un binaire iOS propre.
Une dernière version, exportée sans FairPlay et publiée à un endroit durable (page de préservation Bethesda, partenaire communautaire, lien d’archive unique), garderait iOS vivant après la disparition de la fiche App Store.
Des points d’accès serveur configurables dans la version de préservation.
La version de préservation iOS (et la version Android équivalente) lit les noms d’hôtes des serveurs depuis une ressource modifiable par l’utilisateur — Servers.plist sur iOS, une ressource équivalente sur Android.
Une petite liste nommée de points d’accès (auth, jeu, matchmaking, etc.), chacun pointant vers un nom d’hôte ou une IP. Les valeurs par défaut embarquent les hôtes de production actuels de Bethesda ; les personnes qui re-signent l’app côté communauté les remplacent à ce moment-là.
Effet secondaire : plusieurs communautés indépendantes peuvent faire tourner leurs propres serveurs sans coordination, et une même installation client peut pointer vers différents serveurs au cours de sa vie.
Sur Android : la communauté produit déjà aujourd’hui un APK modifié qui fait ça. Une version Android officielle avec cette fonction serait un geste appréciable — moins de flou juridique, plus de confiance des utilisateurs — mais pas un prérequis. La préservation Android fonctionne sans elle ; c’est sur iOS que cette demande compte le plus.
Faire confiance aux certificats installés par l’utilisateur dans la version de préservation.
La version fait confiance aux AC installées par l’utilisateur, pour que le client puisse parler à un serveur communautaire utilisant un certificat TLS signé par la communauté.
iOS: retirer NSPinnedDomains (ou tout épinglage de certificat personnalisé) de la version de préservation. Sans épinglage, l’app utilise le magasin de confiance standard du système, qui sur iOS inclut déjà les profils de configuration installés par l’utilisateur.
Android : inclure dans le manifeste de production un network_security_config qui fait confiance aux AC utilisateur. Sans ça, Android 7+ rejette par défaut les AC installées par l’utilisateur.
Sans cette demande, les points d’accès configurables de la Demande 2 ne servent à rien : le client rejette le certificat TLS du serveur communautaire avant le moindre échange.
Une courte passation technique sur les détails de protocole non évidents.
Un document — quelques pages de texte, pas une publication de code — couvrant les parties du système qu’un émulateur de serveur ne peut pas facilement reconstruire à partir du seul trafic observé.
- Authentification et jetons de session. Format, durée de vie, existence éventuelle d’autre chose qu’un ID de session opaque côté client, secrets client embarqués attendus par le serveur.
- Autorité de l’état de sauvegarde. Quels sous-systèmes font autorité côté serveur (villes, inventaire, stats de personnage) ou côté client ; règles de réconciliation ; résolution des conflits.
- Chiffrement UDP de l’Arena. Dérivation des clés, choix de paramètres AEAD libsodium, numérotation de séquence, tramage des paquets. La communauté extrait actuellement les clés via des hooks Frida à l’exécution ; une documentation remplacerait ça par une réimplémentation propre.
- Signatures anti-altération. Tout schéma HMAC ou de signature des corps de requête, et les secrets utilisés.
- Validation des reçus IAP. Le flux utilisé par les serveurs Bethesda pour valider les reçus Apple/Google, et ce qu’un serveur communautaire devrait faire pour les achats restaurés.
- Tout autre point que les ingénieurs de Bethesda pensent qu’un réimplémenteur côté serveur risquerait de manquer.
Cette page décrit la demande concrète la plus simple adressée à Bethesda. Le contexte stratégique plus large — pourquoi c’est important, pourquoi un éditeur pourrait s’y intéresser, quelles alternatives existent — est sur la page stratégie. Non affilié à Bethesda Softworks, ZeniMax Media ou Microsoft Corporation. The Elder Scrolls est une marque de ZeniMax Media Inc.