TRANSFORMERS: Forged to Fight est un jeu de combat en 3D où vous prenez le contrôle de certains des soldats les plus charismatiques de l'univers Transformers. On parle de grands noms comme Optimus Prime, Megatron, Bumblebee, Ratchet, Soundwave et Grindor – ni plus ni moins. Oui, vous avez bien lu. Vos personnages préférés de n'importe quel Transformers
Ce paquet contient un démarrage hors ligne fonctionnel de Transformers: Forged to Fight, ainsi que tous les outils, correctifs et notes d'ingénierie inverse utilisés pour y parvenir. Il est destiné à être repris par quelqu'un qui a le temps et l'énergie pour franchir la prochaine étape, bien plus vaste, qui consiste à reconstruire le contenu serveur du jeu à partir de zéro. Tout ici est documenté pour que vous n'ayez pas à repartir de zéro comme je l'ai fait.
Lisez l'intégralité de ce fichier avant de toucher à quoi que ce soit. La section « Pièges » en particulier vous fera gagner des jours.
Le jeu démarre complètement hors ligne et atteint son écran d'accueil interactif réel sans aucun serveur en ligne. Depuis l'écran d'accueil, les menus naviguent sans planter : la base, le roster des bots (avec un bot possédé présent dans le compte), la sélection du mode de combat, l'écran des cristaux, ainsi que les popups et astuces habituels. Le flux de connexion complet s'effectue, chaque sous-système en ligne se connecte, et l'expérience de première fois et les tutoriels sont passés. Le combat scripté d'introduction (Optimus contre Starscream) va même assez loin pour commencer à charger la bataille, et les modèles 3D des personnages s'affichent et s'animent.
C'était la partie difficile et elle est résolue. Le client lui-même est à nouveau vivant hors ligne.
Le gameplay réel ne fonctionne pas. L'histoire n'affiche aucune mission, et les combats ne peuvent pas se charger complètement. Ce n'est pas un bug et ce n'est pas quelque chose qu'un correctif peut résoudre.
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.
Il y a quatre parties mobiles. Ensemble, elles font croire au jeu non modifié qu'il communique avec Kabam.
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.
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.
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.
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.
