Transformers-Forged-To-Fight-Offline-Version

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.

Come funziona il boot offline

Ci sono quattro componenti mobili. Insieme fanno sì che il gioco non modificato pensi di parlare con Kabam.

1. 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.

2. 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.

3. 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.

4. 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.

Cosa c'è in questo pacchetto

re_notes/dump.cs è il file più prezioso per il lavoro che rimane. È il modello completo dei tipi del gioco: ogni classe, ogni metodo e, cosa cruciale, ogni campo dati che il client legge dal server. È la tua mappa dell'intera API backend. Quando hai bisogno di sapere quale forma dovrebbe avere una risposta, la risposta è lì.

Cosa non è in questo pacchetto e dove trovarlo

Questi sono stati esclusi appositamente, perché sono grandi, protetti da copyright, segreti, o dovresti generarli tu stesso.

• L'APK stesso (com.kabam.bigrobot, versione 9.2.0). È circa 800 MB. Procurati la tua copia. Il nome del pacchetto e la versione sono in TECHNICAL_NOTES.md.
• Il libil2cpp.so originale e gli asset del gioco. Entrambi provengono direttamente dall'APK. Decomprimi l'APK, la libreria è in lib/arm64-v8a/, gli asset sono in assets/.
• Il certificato TLS e la CA. Non distribuire chiavi private. Esegui server/gen_certs.sh per creare la tua coppia corrispondente, quindi punta il trust store del dispositivo alla nuova CA.
• La libreria patchata. Rigenerala: esegui patches/patch_il2cpp.py contro il libil2cpp.so originale dell'APK.
• Frida server e Il2CppDumper. Entrambi sono strumenti pubblici. Il2CppDumper è ciò che ha prodotto re_notes/dump.cs dalla libreria dell'APK e dai metadati globali.
• L'Android NDK (è stato usato r26) e JDK 21, necessari per compilare l'hook e per eseguire il decompilatore headless di Ghidra.

Come eseguire ciò che esiste oggi

Hai bisogno dell'APK installato su un emulatore in grado di tradurre ARM (è stato usato LDPlayer 9, con root e filesystem scrivibile), Python sul PC e gli elementi della sezione sopra.

1. Genera i certificati una volta: bash server/gen_certs.sh.
2. Compila la libreria patchata una volta: python patches/patch_il2cpp.py percorso/al/libil2cpp.so originale --apply.
3. Compila l'hook una volta se vuoi ricostruirlo, altrimenti usa quello precompilato. Vedi tools/nativehook/deploy.sh.
4. Avvia il finto server sul PC: python server/fakeserver.py. Deve essere raggiungibile sulle porte 443 e 80 dall'emulatore.
5. Provisiona il dispositivo: bash tools/provision_ldplayer.sh <IP-LAN-del-tuo-PC>. Eseguilo di nuovo dopo ogni riavvio dell'emulatore.
6. Aspetta circa 45 secondi, quindi tocca la schermata del titolo per accedere. Dovresti raggiungere la schermata principale.

Se si blocca al login, controlla il primo elemento nella sezione Gotchas prima di qualsiasi altra cosa.

I trabocchetti che ti faranno perdere tempo

Questi sono quelli che mi sono costati ore. Sono scritti in modo che non ti costino lo stesso.

• L'hook runtime viene caricato solo attraverso una voce di dipendenza che la libreria originale non ha. Lo script di patch costruisce dalla libreria originale, quindi senza riaggiungere quella voce l'hook non viene mai caricato silenziosamente e il login si blocca. Lo script di patch ora la re-inietta ad ogni build. Se l'hook sembra morto, la prima cosa da controllare è che la libreria patchata faccia effettivamente riferimento a libdothook.so. I byte e gli offset esatti sono documentati nello script di patch e in TECHNICAL_NOTES.md.
• Frida non funziona se usi LDPlayer9/Bluestacks per i test. L'emulatore traduce ARM in x86 e Frida crasha sotto quella traduzione. L'intera ragione per cui il progetto usa un hook inline con sovrascrittura di byte puro è che sopravvive dove Frida non lo fa. Non perdere tempo a cercare di far funzionare Frida.
• I mount di rete del dispositivo non sopravvivono a un riavvio dell'emulatore. Il reindirizzamento degli host e il trust della CA sono bind mount. Dopo qualsiasi riavvio dell'emulatore devi rieseguire provision_ldplayer.sh o nulla si connetterà.
• All'interno dei payload di errore di Sparx il campo è err, non error. Usare quello sbagliato produce risposte che il client ignora silenziosamente o gestisce male.
• Gli stati del prompt del tutorial interattivo ciclano all'infinito offline. Non cercare di rispondere a una richiesta del tutorial per soddisfarlo. Invece rimuovi la condizione che attiva il tutorial in primo luogo. Il freeze del tutorial dello scudo è stato risolto in questo modo, dando al giocatore la risorsa la cui assenza lo scatenava, piuttosto che rispondendo al tutorial.
• Il rendering di contenuti 3D live nell'emulatore è fragile. I modelli vengono renderizzati, ma questa è l'area più instabile ed è sensibile al backend grafico dell'emulatore e alle impostazioni delle texture. Questo è un problema grafico dell'emulatore, non un problema di dati.

Se vuoi davvero ripristinarlo: ricostruzione del backend

Questo è il vero lavoro, ed è grande. Ecco la sua forma e da dove iniziare.

L'obiettivo è ricreare a mano il contenuto lato server che veniva trasmesso al client: le missioni e le quest, le mappe e i loro schieramenti nemici, il roster completo con le statistiche e le abilità di ogni bot, le formule di combattimento e l'economia. Niente di tutto ciò esiste più, quindi tutto deve essere creato da zero, nelle forme esatte che il client si aspetta.

Il metodo che funziona è il ciclo su cui è costruito questo progetto. Esegui il gioco con l'hook attaccato. L'hook registra ogni chiave che il client legge. Quando il client chiede qualcosa che non hai fornito, vedi esattamente cosa voleva. Quindi sintetizzi una risposta nella forma giusta, la inserisci in server/responses/ o la aggiungi al gestore dinamico in fakeserver.py, riavvii e verifichi che il client la accetti e vada avanti. Ripeti. Ogni schermata nella build corrente è stata attivata esattamente in questo modo. re_notes/dump.cs ti dice la forma di ogni struttura prima ancora di eseguire, perché elenca ogni campo che il client legge.

Un ordine sensato per affrontarlo:

1. Fai caricare e funzionare un singolo combattimento completo dall'inizio alla fine. Questo è l'obiettivo di maggior valore perché il combattimento è il cuore del gioco e mette alla prova più dati del server contemporaneamente. Hai bisogno delle definizioni dei partecipanti, delle loro statistiche e abilità e di tutto ciò che il percorso di inizializzazione del combattimento richiede. Il combattimento introduttivo inizia già a caricare, quindi è il posto dove spingere per primo. Decompila i percorsi di inizializzazione del combattimento e dei dati di combattimento (usa decompile_targets.py) e leggi i campi esatti.
2. Ricostruisci completamente il modello dei dati del roster, un bot alla volta, incluse statistiche e abilità. L'arte per ogni bot esiste già nei bundle elencati in ASSET_INVENTORY.txt, quindi stai solo creando numeri e definizioni di abilità, non asset.
3. Ricostruisci le strutture delle quest e delle mappe in modo che la Storia smetta di essere vuota. La struttura di base è già stata parzialmente decifrata, vedi TECHNICAL_NOTES.md per le chiavi.
4. Completa l'economia e la progressione per ultime, una volta che esistono combattimenti e missioni su cui spenderle.

Sii realistico sulla scala. Anche per giochi in cui i fan hanno salvato i dati live del server prima dello spegnimento, allestire un server privato è un progetto lungo. Qui non ci sono dati salvati da cui partire, quindi ogni numero e ogni abilità devono essere ricercati o reinventati e poi verificati rispetto al client. Questo è uno sforzo multi-persona e multi-anno se l'obiettivo è il vero gioco. Detto questo, il percorso non è più un mistero. Il boot è risolto, il ciclo di feedback esiste, il modello di tipo è dumpato e gli asset sono intatti. Ciò che rimane è una grandissima quantità di attenta ricostruzione dei dati, non più reverse engineering dell'ignoto.

Inizia con TECHNICAL_NOTES.md. È il riferimento tecnico più approfondito, con le patch esatte, le forme dei dati recuperati e le scoperte specifiche, in maggiore dettaglio rispetto a questo README. Poi esegui il ciclo.

Buona fortuna. Ora è una macchina reale. Ha solo bisogno che i suoi contenuti vengano ricostruiti.