Transformers-Forged-To-Fight-Offline-Version

Die Situation teilt sich also sauber in zwei Teile. Die Kunst und der Ton haben überlebt, weil sie in der App ausgeliefert werden (siehe re_notes/ASSET_INVENTORY.txt). Jeder Charakter ist ein vollständiges Unity-Asset-Bundle, das das Modell, die Texturen, das Rig, die Animationsclips, die Animator-Controller, Effekte und Audio enthält. Die Umgebungen, Gebäude, UI, Porträts, Zwischensequenzen und Dialoge sind ebenfalls alle vorhanden. Was nicht überlebt hat, sind die Daten, die dem Spiel sagten, welche dieser Assets verwendet werden sollen, wie sie zu einem Kampf oder einer Mission zusammengesetzt werden sollen und wie die Zahlen jedes Bots tatsächlich waren. Alle Teile sind vorhanden. Es gibt nur nichts mehr, das weiß, wie man sie zusammensetzt. Das wieder aufzubauen ist die gesamte verbleibende Aufgabe.

Wie der Offline-Start funktioniert

Es gibt vier bewegliche Teile. Zusammen lassen sie das unveränderte Spiel glauben, es spreche mit Kabam.

1. Native Binär-Patches. Das Spiel ist Unity IL2CPP, daher lebt die Logik in einer kompilierten ARM-Bibliothek, libil2cpp.so, nicht in bearbeitbaren Skriptdateien. patches/patch_il2cpp.py schreibt sechs Funktionen in dieser Bibliothek um, um an den toten Serverprüfungen vorbeizukommen: Es besiegt zwei Zertifikat-Pinning-Pfade, sodass unser eigenes TLS-Zertifikat akzeptiert wird, erzwingt, dass der Manager-Registrierungsblock ausgeführt wird, obwohl die Live-Konfiguration null ist, lässt die Anmeldung mit unserer lokalen Gerätesitzung erfolgreich sein und unterdrückt die fatalen Subsystem-Fehler, die sonst den Dialog „Anmeldung fehlgeschlagen“ einblenden würden. Es fügt auch einen einzelnen Abhängigkeitseintrag wieder ein (siehe den Abschnitt Gotchas), sodass der Runtime-Hook tatsächlich geladen wird. Die Ausgabe ist libil2cpp.patched.so.

2. Ein gefakter Sparx-Server. server/fakeserver.py vertritt Kabams Backend. Es lauscht auf TLS 443 und einfachem HTTP 80 und beantwortet die API-Aufrufe des Spiels. Vorgefertigte Antworten befinden sich in server/responses/, eine Datei pro Endpunkt, benannt nach Methode und Pfad, zum Beispiel GET__account_data.json. Einige Endpunkte werden dynamisch im Code beantwortet, anstatt aus einer Datei, weil das Spiel erwartet, dass sie Werte aus der Anfrage widergeben (die Tutorial-Endpunkte und der Helden-Detail-Endpunkt). Das Antwortenvelope ist {"error":null,"result": ...}. Beachten Sie, dass in Sparx-Fehlerdaten das Feld err geschrieben wird, nicht error. Dieses Detail ist wichtig und leicht zu übersehen.

3. Ein nativer Runtime-Hook. tools/nativehook/ baut libdothook.so, eine kleine Bibliothek, die beim Start in das Spiel geladen wird und jeden Datenkey protokolliert, den das Spiel liest, plus ein paar gezielte Verhaltensanpassungen. Dies ist die Rückkopplungsschleife, die alles andere möglich gemacht hat: Sie sagt Ihnen genau, wonach das Spiel fragt, sodass Sie eine Antwort synthetisieren und überprüfen können. Es handelt sich um einen reinen Byte-Overwrite-Inline-Hook, der vor der Ausführung installiert wird, da das normale Werkzeug dafür (Frida) unter der ARM-Übersetzungsschicht des Emulators abstürzt.

4. Geräteverkabelung. Der Emulator muss Kabams Domänen an den PC senden und dem gefälschten Zertifikat vertrauen. tools/provision_ldplayer.sh erledigt dies auf einmal: Es schiebt die gepatchte Bibliothek und den Hook, leitet die Kabam-Hostnamen über die Hosts-Datei auf die LAN-Adresse des PCs um, mountet die gefälschte CA in den Systemvertrauensspeicher und lockert SELinux. Führen Sie es nach jedem Emulator-Neustart aus, da diese Mounts einen Neustart nicht überleben.

Der Datenfluss zur Laufzeit ist: Das Spiel tätigt einen HTTPS-Aufruf an eine Kabam-Domäne, die Hosts-Datei leitet ihn an den PC weiter, der gefälschte Server antwortet mit einer Antwort aus server/responses/, die gepatchte Bibliothek akzeptiert das Zertifikat und die Antwort, und der Hook protokolliert, was gelesen wurde. Diese Schleife ist, wie jeder Bildschirm in diesem Build zum Laufen gebracht wurde.

Was in diesem Paket enthalten ist

re_notes/dump.cs ist die mit Abstand wertvollste Datei für die verbleibende Arbeit. Es ist das vollständige Typmodell des Spiels: jede Klasse, jede Methode und entscheidend jedes Datenfeld, das der Client vom Server liest. Es ist Ihre Karte der gesamten Backend-API. Wenn Sie wissen müssen, wie eine Antwort aussehen soll, finden Sie die Antwort darin.

Was nicht in diesem Paket enthalten ist und wo Sie es bekommen

Diese wurden absichtlich weggelassen, weil sie groß, urheberrechtlich geschützt oder geheim sind, oder weil Sie Ihre eigenen generieren sollten.

• Die APK selbst (com.kabam.bigrobot, Version 9.2.0). Sie ist etwa 800 MB groß. Besorgen Sie sich Ihre eigene Kopie. Der Paketname und die Version sind in TECHNICAL_NOTES.md.
• Die originale libil2cpp.so und die Spiel-Assets. Beide stammen direkt aus der APK. Entpacken Sie die APK, die Bibliothek befindet sich unter lib/arm64-v8a/, die Assets unter assets/.
• Das TLS-Zertifikat und die CA. Versenden Sie keine privaten Schlüssel. Führen Sie server/gen_certs.sh aus, um Ihr eigenes Paar zu erstellen, und richten Sie dann den Gerätevertrauensspeicher auf die neue CA.
• Die gepatchte Bibliothek. Regenerieren Sie sie: Führen Sie patches/patch_il2cpp.py gegen die originale libil2cpp.so aus der APK aus.
• Frida-Server und Il2CppDumper. Beides sind öffentliche Werkzeuge. Il2CppDumper hat re_notes/dump.cs aus der Bibliothek und den globalen Metadaten der APK erstellt.
• Das Android NDK (r26 wurde verwendet) und JDK 21, die benötigt werden, um den Hook zu bauen und den Ghidra Headless-Decompiler auszuführen.

So führen Sie das aus, was heute existiert

Sie benötigen die APK, installiert auf einem ARM-Übersetzungs-fähigen Emulator (LDPlayer 9 wurde verwendet, mit Root und beschreibbarem System), Python auf dem PC und die Elemente aus dem obigen Abschnitt.

1. Zertifikate einmal generieren: bash server/gen_certs.sh.
2. Die gepatchte Bibliothek einmal bauen: python patches/patch_il2cpp.py path/to/original/libil2cpp.so --apply.
3. Den Hook einmal bauen, wenn Sie ihn neu bauen möchten, ansonsten den vorgebauten verwenden. Siehe tools/nativehook/deploy.sh.
4. Starten Sie den gefälschten Server auf dem PC: python server/fakeserver.py. Er muss vom Emulator aus auf den Ports 443 und 80 erreichbar sein.
5. Stellen Sie das Gerät bereit: bash tools/provision_ldplayer.sh <Ihre-PC-LAN-IP>. Führen Sie dies nach jedem Emulator-Neustart erneut aus.
6. Warten Sie etwa 45 Sekunden, tippen Sie dann auf den Titelbildschirm, um sich anzumelden. Sie sollten den Startbildschirm erreichen.

Wenn es bei der Anmeldung hängt, überprüfen Sie als erstes den allerersten Punkt im Abschnitt Gotchas.

Die Fallstricke, die Ihre Zeit fressen werden

Dies sind diejenigen, die mich Stunden gekostet haben. Sie sind niedergeschrieben, damit sie Sie nicht dasselbe kosten.

• Der Runtime-Hook lädt nur über einen Abhängigkeitseintrag, den die unberührte Bibliothek nicht hat. Das Patch-Skript baut aus der unberührten Bibliothek, daher wird der Hook ohne erneutes Hinzufügen dieses Eintrags stillschweigend nie geladen und die Anmeldung hängt einfach. Das Patch-Skript fügt ihn jetzt bei jedem Build wieder ein. Wenn der Hook jemals tot zu sein scheint, überprüfen Sie als erstes, ob die gepatchte Bibliothek tatsächlich auf libdothook.so verweist. Die genauen Bytes und Offsets sind im Patch-Skript und in TECHNICAL_NOTES.md dokumentiert.
• Frida funktioniert nicht, wenn Sie LDPlayer9/Bluestacks zum Testen verwenden. Der Emulator übersetzt ARM in x86, und Frida stürzt unter dieser Übersetzung ab. Der ganze Grund, warum das Projekt einen reinen Byte-Overwrite-Inline-Hook verwendet, ist, dass er dort überlebt, wo Frida es nicht tut. Verschwenden Sie keine Zeit damit, zu versuchen, Frida zum Funktionieren zu bringen.
• Die geräteseitigen Netzwerk-Mounts überleben einen Emulator-Neustart nicht. Die Hosts-Umleitung und das CA-Vertrauen sind Bind-Mounts. Nach jedem Neustart des Emulators müssen Sie provision_ldplayer.sh erneut ausführen, sonst verbindet sich nichts.
• In Sparx-Fehlerdaten ist das Feld err, nicht error. Die Verwendung des falschen erzeugt Antworten, die der Client stillschweigend ignoriert oder falsch behandelt.
• Interaktive Tutorial-Eingabeaufforderungszustände laufen offline endlos weiter. Versuchen Sie nicht, eine Tutorial-Anfrage zu beantworten, um sie zu befriedigen. Entfernen Sie stattdessen die Bedingung, die das Tutorial überhaupt auslöst. Das Einfrieren des Schild-Tutorials wurde auf diese Weise behoben, indem dem Spieler die Ressource gegeben wurde, deren Fehlen es auslöste, anstatt das Tutorial zu beantworten.
• Live-3D-Inhalts-Rendering unter dem Emulator ist instabil. Modelle rendern zwar, aber dies ist der instabilste Bereich und empfindlich gegenüber dem Grafik-Backend des Emulators und den Textureinstellungen. Dies ist ein Emulator-Grafikproblem, kein Datenproblem.

Wenn Sie es tatsächlich wiederbeleben möchten: Wiederaufbau des Backends

Dies ist die eigentliche Arbeit, und sie ist umfangreich. Hier ist ihre Form und wo Sie beginnen sollten.

Das Ziel ist es, von Hand den serverseitigen Inhalt nachzubilden, der früher an den Client gestreamt wurde: die Quests und Missionen, die Karten und ihre Gegneraufstellungen, das vollständige Roster mit den Statistiken und Fähigkeiten jedes Bots, die Kampfformeln und die Wirtschaft. Nichts davon existiert mehr, daher muss alles von Grund auf neu erstellt werden, in der genauen Form, die der Client erwartet.

Die Methode, die funktioniert, ist die Schleife, um die dieses Projekt herum aufgebaut ist. Führen Sie das Spiel mit dem angehängten Hook aus. Der Hook protokolliert jeden Key, den der Client liest. Wenn der Client nach etwas fragt, das Sie nicht bereitgestellt haben, sehen Sie genau, was er wollte. Sie synthetisieren dann eine Antwort in der richtigen Form, legen sie in server/responses/ ab oder fügen sie dem dynamischen Handler in fakeserver.py hinzu, starten neu und überprüfen, ob der Client sie akzeptiert und fortfährt. Wiederholen. Jeder Bildschirm im aktuellen Build wurde auf diese genaue Weise zum Laufen gebracht. re_notes/dump.cs sagt Ihnen die Form jeder Struktur, bevor Sie überhaupt laufen, weil es jedes Feld auflistet, das der Client liest.

Eine vernünftige Reihenfolge, um es anzugehen:

1. Bringen Sie einen einzigen vollständigen Kampf dazu, von Anfang bis Ende zu laden und zu laufen. Dies ist das Ziel mit dem höchsten Wert, da der Kampf der Kern des Spiels ist und die meiste Serverdaten auf einmal beansprucht. Sie benötigen die Teilnehmerdefinitionen, ihre Statistiken und Fähigkeiten und alles, was der Kampf-Initialisierungspfad verlangt. Der Einführungskampf beginnt bereits mit dem Laden, also ist dies der Ort, um zuerst zu pushen. Dekompilieren Sie die Kampf-Initialisierungs- und Kampfdatenpfade (verwenden Sie decompile_targets.py) und lesen Sie die genauen Felder ab.
2. Rekonstruieren Sie das Roster-Datenmodell vollständig, einen Bot nach dem anderen, einschließlich Statistiken und Fähigkeiten. Die Kunst für jeden Bot existiert bereits in den in ASSET_INVENTORY.txt aufgeführten Bundles, sodass Sie nur Zahlen und Fähigkeitsdefinitionen erstellen, keine Assets.
3. Bauen Sie die Quest- und Kartenstrukturen wieder auf, damit die Story nicht mehr leer ist. Die Basisstruktur wurde bereits teilweise geknackt, siehe TECHNICAL_NOTES.md für die Schlüssel.
4. Füllen Sie die Wirtschaft und den Fortschritt zuletzt aus, sobald Kämpfe und Missionen existieren, für die man sie ausgeben kann.

Seien Sie realistisch hinsichtlich des Umfangs. Selbst bei Spielen, bei denen Fans die Live-Serverdaten vor der Abschaltung gespeichert haben, ist das Aufsetzen eines privaten Servers ein langes Projekt. Hier gibt es keine gespeicherten Daten, von denen man ausgehen kann, also muss jede Zahl und jede Fähigkeit erforscht oder neu erfunden und dann gegen den Client verifiziert werden. Dies ist eine Mehrpersonen-, mehrjährige Anstrengung, wenn das Ziel das echte Spiel ist. Das heißt, der Weg ist kein Geheimnis mehr. Der Start ist gelöst, die Rückkopplungsschleife existiert, das Typmodell ist ausgelesen und die Assets sind intakt. Was bleibt, ist eine sehr große Menge sorgfältiger Datenrekonstruktion, nicht mehr Reverse Engineering des Unbekannten.

Beginnen Sie mit TECHNICAL_NOTES.md. Es ist die tiefere technische Referenz, mit den genauen Patches, den wiederhergestellten Datenformen und den spezifischen Erkenntnissen, detaillierter als diese README. Führen Sie dann die Schleife aus.

Viel Glück. Es ist jetzt eine echte Maschine. Sie muss nur noch ihren Inhalt wieder aufbauen.