Transformers-Forged-To-Fight-Offline-Version

Forged to Fight était entièrement piloté par le serveur. L'application sur le téléphone n'est essentiellement qu'un écran avec des commandes. Presque rien du jeu ne résidait dans l'application. Chaque mission, chaque combat, chaque alignement d'ennemis, l'intégralité des statistiques et capacités du roster, l'économie et tout l'équilibrage vivaient sur les serveurs de Kabam et étaient diffusés vers l'appareil à chaque session. Lorsque les serveurs ont été arrêtés début 2020, cette base de données de contenu a disparu avec eux, et elle n'a jamais été publiée ni archivée publiquement là où je puisse l'atteindre.

La situation se divise donc clairement en deux. L'art et l'audio ont survécu, car ils sont livrés dans l'application (voir re_notes/ASSET_INVENTORY.txt). Chaque personnage est un bundle Unity complet contenant le modèle, les textures, le squelette, les clips d'animation, les contrôleurs d'animateur, les effets et l'audio. Les environnements, les bâtiments, l'interface utilisateur, les portraits, les cinématiques et les dialogues sont également tous présents. Ce qui n'a pas survécu, ce sont les données qui disaient au jeu quels assets utiliser, comment les assembler en un combat ou une mission, et quels étaient les chiffres réels de chaque bot. Toutes les pièces sont là. Il ne reste plus rien qui sache comment les assembler. Reconstruire cela est l'intégralité du travail qui reste.

Comment fonctionne le démarrage hors ligne

Il y a quatre parties mobiles. Ensemble, elles font croire au jeu non modifié qu'il communique avec Kabam.

1. Correctifs binaires natifs. Le jeu est en Unity IL2CPP, donc la logique vit dans une bibliothèque ARM compilée, libil2cpp.so, et non dans des fichiers de script modifiables. patches/patch_il2cpp.py réécrit six fonctions dans cette bibliothèque pour contourner les vérifications de serveur mort : il neutralise deux chemins d'épingle de certificat pour que notre propre certificat TLS soit accepté, force l'exécution du bloc d'enregistrement du gestionnaire même si la configuration en direct est nulle, permet à la connexion de réussir avec notre session de périphérique local, et fait taire les erreurs fatales des sous-systèmes qui autrement afficheraient la boîte de dialogue « échec de la connexion ». Il réinjecte également une seule entrée de dépendance (voir la section Pièges) pour que le hook d'exécution se charge effectivement. La sortie est libil2cpp.patched.so.

2. Un faux serveur Sparx. server/fakeserver.py se fait passer pour le backend de Kabam. Il écoute sur TLS 443 et HTTP simple 80 et répond aux appels API du jeu. Les réponses préfabriquées se trouvent dans server/responses/, un fichier par endpoint, nommé par méthode et chemin, par exemple GET__account_data.json. Quelques endpoints sont répondus dynamiquement dans le code plutôt que depuis un fichier, car le jeu s'attend à ce qu'ils renvoient des valeurs de la requête (les endpoints du tutoriel et l'endpoint des détails du héros). L'enveloppe de réponse est {"error":null,"result": ...}. Notez que dans les charges utiles d'erreur Sparx, le champ est orthographié err, et non error. Ce détail compte et est facile à manquer.

3. Un hook d'exécution natif. tools/nativehook/ compile libdothook.so, une petite bibliothèque chargée au démarrage du jeu qui enregistre chaque clé de données que le jeu lit, ainsi que quelques ajustements comportementaux ciblés. C'est la boucle de rétroaction qui a rendu tout le reste possible : elle vous dit exactement ce que le jeu demande, afin que vous puissiez synthétiser une réponse et la vérifier. Il s'agit d'un hook inline pur par réécriture de byte installé avant l'exécution, car l'outil normal pour cela (Frida) plante sous la couche de traduction ARM de l'émulateur.

4. Câblage du périphérique. L'émulateur doit envoyer les domaines de Kabam vers le PC et faire confiance au faux certificat. tools/provision_ldplayer.sh fait cela en une seule fois : il pousse la bibliothèque corrigée et le hook, redirige les noms d'hôte Kabam vers l'adresse LAN du PC via le fichier hosts, monte l'AC fictive dans le magasin de confiance système et assouplit SELinux. Exécutez-le après chaque redémarrage de l'émulateur, car ces montages ne survivent pas à un redémarrage.

Le flux de données à l'exécution est le suivant : le jeu effectue un appel HTTPS vers un domaine Kabam, le fichier hosts l'envoie au PC, le faux serveur répond avec une réponse de server/responses/, la bibliothèque corrigée accepte le certificat et la réponse, et le hook enregistre ce qui a été lu. C'est cette boucle qui a permis d'afficher chaque écran de cette version.

Ce qui se trouve dans ce paquet

re_notes/dump.cs est le fichier le plus précieux pour le travail qui reste. C'est le modèle de type complet du jeu : chaque classe, chaque méthode, et surtout chaque champ de données que le client lit depuis le serveur. C'est votre carte de l'API backend entière. Lorsque vous avez besoin de connaître la forme d'une réponse, la réponse s'y trouve.

Ce qui n'est pas dans ce paquet, et où l'obtenir

Ces éléments ont été volontairement omis, car ils sont volumineux, ou protégés par des droits d'auteur, ou secrets, ou vous devriez générer les vôtres.

• L'APK lui-même (com.kabam.bigrobot, version 9.2.0). Il fait environ 800 Mo. Procurez-vous votre propre copie. Le nom du paquet et la version sont dans TECHNICAL_NOTES.md.
• Le libil2cpp.so original et les assets du jeu. Les deux proviennent directement de l'APK. Dézippez l'APK, la bibliothèque se trouve sous lib/arm64-v8a/, les assets sous assets/.
• Le certificat TLS et l'AC. Ne distribuez pas les clés privées. Exécutez server/gen_certs.sh pour créer votre propre paire correspondante, puis pointez le magasin de confiance du périphérique vers la nouvelle AC.
• La bibliothèque corrigée. Régénérez-la : exécutez patches/patch_il2cpp.py contre le libil2cpp.so original de l'APK.
• Le serveur Frida et Il2CppDumper. Ce sont des outils publics. C'est Il2CppDumper qui a produit re_notes/dump.cs à partir de la bibliothèque et des métadonnées globales de l'APK.
• Le NDK Android (r26 a été utilisé) et JDK 21, nécessaires pour compiler le hook et exécuter le décompilateur headless Ghidra.

Comment exécuter ce qui existe aujourd'hui

Vous avez besoin de l'APK installé sur un émulateur capable de traduction ARM (LDPlayer 9 a été utilisé, avec root et système inscriptible), Python sur le PC, et les éléments de la section ci-dessus.

1. Générez les certificats une fois : bash server/gen_certs.sh.
2. Compilez la bibliothèque corrigée une fois : python patches/patch_il2cpp.py chemin/vers/libil2cpp.so/original --apply.
3. Compilez le hook une fois si vous voulez le reconstruire, sinon utilisez le précompilé. Voir tools/nativehook/deploy.sh.
4. Démarrez le faux serveur sur le PC : python server/fakeserver.py. Il doit être accessible sur les ports 443 et 80 depuis l'émulateur.
5. Provisionnez le périphérique : bash tools/provision_ldplayer.sh <votre-adresse-IP-LAN-PC>. Réexécutez après chaque redémarrage de l'émulateur.
6. Attendez environ 45 secondes, puis appuyez sur l'écran titre pour vous connecter. Vous devriez atteindre l'écran d'accueil.

Si cela bloque à la connexion, vérifiez le tout premier élément de la section Pièges avant toute autre chose.

Les pièges qui vous feront perdre du temps

Ce sont ceux qui m'ont coûté des heures. Ils sont écrits pour qu'ils ne vous coûtent pas la même chose.

• Le hook d'exécution ne se charge que via une entrée de dépendance que la bibliothèque d'origine ne possède pas. Le script de correctif compile à partir de la bibliothèque d'origine, donc sans réajouter cette entrée, le hook n'est jamais chargé silencieusement et la connexion bloque simplement. Le script de correctif la réinjecte désormais à chaque compilation. Si le hook semble mort, la première chose à vérifier est que la bibliothèque corrigée référence effectivement libdothook.so. Les octets et offsets exacts sont documentés dans le script de correctif et dans TECHNICAL_NOTES.md.
• Frida ne fonctionne pas si vous utilisez LDPlayer9/Bluestacks pour les tests. L'émulateur traduit ARM en x86, et Frida plante sous cette traduction. La raison pour laquelle ce projet utilise un hook inline pur par réécriture de byte est qu'il survit là où Frida ne survit pas. Ne perdez pas de temps à essayer de faire fonctionner Frida.
• Les montages réseau du périphérique ne survivent pas à un redémarrage de l'émulateur. La redirection des hôtes et la confiance de l'AC sont des montages bind. Après tout redémarrage de l'émulateur, vous devez réexécuter provision_ldplayer.sh sinon rien ne se connectera.
• Dans les charges utiles d'erreur Sparx, le champ est err, pas error. Utiliser le mauvais produit des réponses que le client ignore ou traite mal silencieusement.
• Les états de sollicitation du tutoriel interactif bouclent indéfiniment hors ligne. N'essayez pas de répondre à une demande de tutoriel pour le satisfaire. Supprimez plutôt la condition qui déclenche le tutoriel en premier lieu. Le blocage du tutoriel du bouclier a été corrigé de cette manière, en donnant au joueur la ressource dont l'absence le déclenchait, plutôt qu'en répondant au tutoriel.
• Le rendu de contenu 3D en direct sous l'émulateur est fragile. Les modèles s'affichent bien, mais c'est le domaine le plus instable et il est sensible au backend graphique et aux paramètres de texture de l'émulateur. C'est un problème graphique de l'émulateur, pas un problème de données.

Si vous voulez vraiment le relancer : reconstruire le backend

C'est le vrai travail, et il est vaste. Voici sa forme et par où commencer.

L'objectif est de recréer, à la main, le contenu serveur qui était autrefois diffusé vers le client : les quêtes et missions, les cartes et leurs alignements ennemis, le roster complet avec les statistiques et capacités de chaque bot, les formules de combat et l'économie. Rien de tout cela n'existe plus, donc tout doit être créé à nouveau, dans les formes exactes attendues par le client.

La méthode qui fonctionne est la boucle autour de laquelle ce projet est construit. Exécutez le jeu avec le hook attaché. Le hook enregistre chaque clé que le client lit. Lorsque le client demande quelque chose que vous n'avez pas fourni, vous voyez exactement ce qu'il voulait. Vous synthétisez ensuite une réponse dans la bonne forme, la placez dans server/responses/ ou l'ajoutez au gestionnaire dynamique dans fakeserver.py, redémarrez, et vérifiez que le client l'accepte et avance. Répétez. Chaque écran de la version actuelle a été affiché de cette manière exacte. re_notes/dump.cs vous indique la forme de chaque structure avant même d'exécuter, car il liste tous les champs que le client lit.

Un ordre raisonnable pour l'attaquer :

1. Faire qu'un seul combat complet se charge et s'exécute de bout en bout. C'est la cible la plus précieuse car le combat est le cœur du jeu et il exerce le plus de données serveur à la fois. Vous avez besoin des définitions des participants, de leurs statistiques et capacités, et de tout ce que le chemin d'initialisation du combat demande. Le combat d'introduction commence déjà à se charger, c'est donc là qu'il faut pousser en premier. Décompilez les chemins d'initiation du combat et des données de combat (utilisez decompile_targets.py) et lisez les champs exacts.
2. Reconstruire entièrement le modèle de données du roster, un bot à la fois, statistiques et capacités incluses. L'art de chaque bot existe déjà dans les bundles listés dans ASSET_INVENTORY.txt, donc vous ne créez que des chiffres et des définitions de capacités, pas des assets.
3. Reconstruire les structures des quêtes et des cartes pour que l'Histoire cesse d'être vide. La structure de base a déjà été partiellement déchiffrée, voir TECHNICAL_NOTES.md pour les clés.
4. Remplir l'économie et la progression en dernier, une fois que les combats et les missions existent pour y dépenser.

Soyez réaliste quant à l'ampleur. Même pour les jeux où les fans ont sauvegardé les données du serveur en direct avant l'arrêt, mettre en place un serveur privé est un long projet. Ici, il n'y a pas de données sauvegardées pour commencer, donc chaque nombre et chaque capacité doit être recherché ou réinventé puis vérifié contre le client. C'est un effort multi-personne et multi-années si l'objectif est le vrai jeu. Cela dit, le chemin n'est plus un mystère. Le démarrage est résolu, la boucle de rétroaction existe, le modèle de type est extrait et les assets sont intacts. Ce qui reste est une très grande quantité de reconstruction minutieuse de données, et non plus de l'ingénierie inverse de l'inconnu.

Commencez par TECHNICAL_NOTES.md. C'est la référence technique plus approfondie, avec les correctifs exacts, les formes de données récupérées et les découvertes spécifiques, plus détaillées que ce README. Ensuite, exécutez la boucle.

Bonne chance. C'est maintenant une vraie machine. Il faut juste reconstruire son contenu.