La richiesta più semplice possibile
Conservato così come era stato scritto prima che i server chiudessero il 30 giugno 2026. Le richieste qui sotto, e le scadenze che presuppongono, sono rimaste com’erano.
L’insieme minimo di cose che Bethesda potrebbe fare per permettere alla community di mantenere Blades funzionante su ogni piattaforma dopo il 30 giugno 2026, senza alcun coinvolgimento continuativo di Bethesda o Microsoft.
Tutto ciò che segue si riduce a un solo concetto: un’ultima build del client adatta alla conservazione, più un breve documento tecnico di passaggio di consegne. Le ragioni strategiche per cui un editore potrebbe accogliere questa richiesta sono nella pagina strategia; questa pagina riguarda i dettagli tecnici.
Una build iOS senza FairPlay.
Un’ultima build del client iOS senza la cifratura FairPlay, pubblicata apertamente. Senza questa, conservare la versione iOS è impossibile.
I binari dell’App Store sono cifrati con FairPlay; per decifrarli serve un dispositivo con jailbreak e una versione di iOS dell’epoca giusta. Senza un IPA pulito, strumenti di sideloading come AltStore e Sideloadly non possono aiutare. Da sola, la community non ha modo di ottenere un binario iOS pulito.
Un’ultima build, esportata senza FairPlay e pubblicata in un posto duraturo (una pagina di conservazione di Bethesda, un partner della community, un unico link d’archivio), mantiene vivo iOS dopo la rimozione dall’App Store.
Endpoint del server configurabili nella build di conservazione.
La build di conservazione per iOS (e quella equivalente per Android) legge i nomi host dei server da una risorsa che l’utente può sovrascrivere: Servers.plist su iOS, una risorsa equivalente su Android.
Un breve elenco di endpoint con nome (autenticazione, gioco, matchmaking e così via), ciascuno associato a un nome host o a un IP. Di default puntano agli attuali host di produzione di Bethesda; chi rifirma l’app per la community li sostituisce al momento della firma.
Effetto collaterale: più community indipendenti possono gestire i propri server senza coordinarsi, e una singola installazione del client può essere puntata su server diversi nel corso della sua vita.
Su Android: la community ha già prodotto un APK modificato che oggi fa proprio questo. Una build Android ufficiale con questa funzione sarebbe una cortesia (meno zone grigie legali, più fiducia degli utenti), non un ostacolo da superare. La conservazione su Android funziona anche senza; è su iOS che questa richiesta conta di più.
Fidarsi dei certificati installati dall’utente nella build di conservazione.
La build considera attendibili le CA installate dall’utente, così il client può comunicare con un server della community che usa un certificato TLS firmato dalla community.
iOS: rimuovere NSPinnedDomains (o qualunque certificate pinning personalizzato) dalla build di conservazione. Senza pinning, l’app usa l’archivio attendibile standard del sistema, che su iOS include già i profili di configurazione installati dall’utente.
Android: includere nel manifest di produzione un network_security_config che consideri attendibili le CA dell’utente. Senza, da Android 7 in poi le CA installate dall’utente vengono rifiutate di default.
Senza questa richiesta, gli endpoint configurabili della Richiesta 2 sono inutili: il client rifiuta il certificato TLS del server della community prima che passi qualsiasi traffico.
Un breve passaggio di consegne tecnico sui dettagli non ovvi del protocollo.
Un documento (qualche pagina di testo, non un rilascio di codice) che copra le parti del sistema che un emulatore del server non può ricostruire facilmente dal solo traffico osservato.
- Token di autenticazione e di sessione. Formato, durata, se qualcosa lato client è più di un ID di sessione opaco, eventuali segreti incorporati nel client che il server si aspetta.
- Autorità sullo stato di salvataggio. Quali sottosistemi sono autorevoli lato server (città, inventario, statistiche del personaggio) e quali lato client; regole di riconciliazione; risoluzione dei conflitti.
- Cifratura UDP dell’arena. Derivazione delle chiavi, scelta dei parametri AEAD di libsodium, numerazione delle sequenze, struttura dei pacchetti. Al momento la community estrae le chiavi in fase di esecuzione tramite hook Frida; una documentazione permetterebbe di sostituire questo approccio con una reimplementazione pulita.
- Firme anti-manomissione. Eventuali schemi HMAC o di firma delle richieste sui loro contenuti, e i segreti usati.
- Convalida delle ricevute degli acquisti in-app. Il processo con cui i server di Bethesda convalidano le ricevute Apple/Google, e cosa dovrebbe fare un server della community per gli acquisti ripristinati.
- Qualsiasi altra cosa che secondo gli ingegneri di Bethesda sfuggirebbe altrimenti a chi reimplementa il server.
Questa pagina descrive la richiesta concreta più semplice da fare a Bethesda. Il contesto strategico più ampio (perché è importante, perché un editore potrebbe aderire, quali alternative esistono) si trova nella pagina strategia del sito. Non affiliato a Bethesda Softworks, ZeniMax Media o Microsoft Corporation. The Elder Scrolls è un marchio registrato di ZeniMax Media Inc.