TRANSFORMERS: Forged to Fight è un gioco di combattimento 3D in cui prendi il controllo di alcuni dei più carismatici soldati direttamente dall'universo di Transformers. Parliamo di grandi nomi come Optimus Prime, Megatron, Bumblebee, Ratchet, Soundwave e Grindor–niente di meno. Sì, hai letto bene. I tuoi personaggi preferiti da qualsiasi Transformers
Questo pacchetto contiene un boot offline funzionante di Transformers: Forged to Fight, insieme a tutti gli strumenti, le patch e le note di reverse engineering utilizzati per arrivarci. È pensato per essere raccolto da qualcuno che abbia il tempo e l'energia per compiere il passo successivo, molto più grande, ovvero ricostruire da zero il contenuto lato server del gioco. Tutto qui è documentato in modo che tu non debba partire da zero come ho fatto io.
Leggi tutto questo file prima di toccare qualsiasi cosa. La sezione "Gotchas" in particolare ti farà risparmiare giorni.
Il gioco si avvia completamente offline e raggiunge la sua vera schermata principale interattiva senza alcun server live in funzione. Dalla schermata principale i menu navigano senza crash: la base, il roster dei bot (con un bot posseduto presente nell'account), la selezione della modalità di combattimento, la schermata dei cristalli e i soliti popup e suggerimenti. Il flusso di login completo viene eseguito, ogni sottosistema online si connette e l'esperienza iniziale e i gate del tutorial vengono superati. Il combattimento introduttivo scriptato (Optimus vs Starscream) arriva persino abbastanza avanti da iniziare a caricare la battaglia, e i modelli 3D dei personaggi vengono renderizzati e animati.
Questa era la parte difficile ed è risolta. Il client stesso è di nuovo vivo offline.
Il gameplay effettivo non funziona. La storia non mostra missioni e i combattimenti non possono caricarsi completamente. Questo non è un bug e non è qualcosa che una patch possa risolvere.
Forged to Fight era completamente server-authoritative. L'app sul telefono è essenzialmente uno schermo con controlli. Quasi nulla del gioco risiedeva nell'app. Ogni missione, ogni combattimento, ogni schieramento nemico, le statistiche e le abilità dell'intero roster, l'economia e tutto il bilanciamento vivevano sui server di Kabam e venivano trasmessi al dispositivo in ogni sessione. Quando i server sono stati spenti all'inizio del 2020, quel database di contenuti è scomparso con loro, e non è mai stato rilasciato o archiviato pubblicamente in nessun luogo che io possa raggiungere.
Quindi la situazione è nettamente divisa in due. L'arte e l'audio sono sopravvissuti, perché sono inclusi nell'app (vedi re_notes/ASSET_INVENTORY.txt). Ogni personaggio è un bundle di asset Unity completo che contiene modello, texture, rig, clip di animazione, controller di animazione, effetti e audio. Anche gli ambienti, gli edifici, l'interfaccia utente, i ritratti, le cutscene e i dialoghi sono tutti lì. Ciò che non è sopravvissuto sono i dati che dicevano al gioco quali asset utilizzare, come assemblarli in un combattimento o in una missione, e quali fossero i numeri effettivi di ogni bot. Tutti i pezzi sono presenti. Non è rimasto nulla che sappia come metterli insieme. Ricostruire quello è l'intero lavoro che rimane.
Ci sono quattro componenti mobili. Insieme fanno sì che il gioco non modificato pensi di parlare con Kabam.
Patch binarie native. Il gioco è Unity IL2CPP, quindi la logica risiede in una libreria ARM compilata, libil2cpp.so, non in file script modificabili. patches/patch_il2cpp.py riscrive sei funzioni in quella libreria per superare i controlli dei server morti: sconfigge due percorsi di certificate pinning in modo che il nostro certificato TLS sia accettato, forza il blocco di registrazione del manager a eseguirsi anche se la configurazione live è nulla, permette al login di riuscire con la nostra sessione del dispositivo locale e silenzia gli errori fatali dei sottosistemi che altrimenti farebbero apparire il dialogo "accesso fallito". Inietta anche una singola voce di dipendenza (vedi la sezione Gotchas) in modo che l'hook runtime venga effettivamente caricato. L'output è libil2cpp.patched.so.
Un finto server Sparx. server/fakeserver.py fa da backend per Kabam. Ascolta su TLS 443 e HTTP normale 80 e risponde alle chiamate API del gioco. Le risposte predefinite si trovano in server/responses/, un file per endpoint, nominato per metodo e percorso, ad esempio GET__account_data.json. Alcuni endpoint sono gestiti dinamicamente nel codice anziché da un file, perché il gioco si aspetta che echoino i valori della richiesta (gli endpoint del tutorial e l'endpoint dei dettagli dell'eroe). L'involucro della risposta è {"error":null,"result": ...}. Nota che all'interno dei payload di errore di Sparx il campo è scritto err, non error. Questo dettaglio è importante e facile da perdere.
Un hook runtime nativo. tools/nativehook/ costruisce libdothook.so, una piccola libreria caricata nel gioco all'avvio che registra ogni chiave di dati letta dal gioco, più un paio di suggerimenti comportamentali mirati. Questo è il ciclo di feedback che ha reso possibile tutto il resto: ti dice esattamente cosa sta chiedendo il gioco in modo da poter sintetizzare una risposta e verificarla. È un hook in-line puro con sovrascrittura di byte installato prima dell'esecuzione, perché lo strumento normale per questo (Frida) crasha sotto il layer di traduzione ARM dell'emulatore.
Cablaggio del dispositivo. L'emulatore deve inviare i domini di Kabam al PC e fidarsi del certificato falso. tools/provision_ldplayer.sh fa tutto in un colpo solo: carica la libreria patchata e l'hook, reindirizza gli hostname di Kabam all'indirizzo LAN del PC tramite il file hosts, monta la CA falsa nel trust store di sistema e rilassa SELinux. Eseguilo dopo ogni riavvio dell'emulatore, perché questi mount non sopravvivono a un riavvio.
Il flusso di dati in runtime è: il gioco effettua una chiamata HTTPS a un dominio Kabam, il file hosts la invia al PC, il finto server risponde con una risposta da server/responses/, la libreria patchata accetta il certificato e la risposta, e l'hook registra ciò che è stato letto. Quel ciclo è il modo in cui ogni schermata in questa build è stata attivata.
