Transformers-Forged-To-Fight-Offline-Version

Por lo tanto, la situación se divide claramente en dos. El arte y el audio sobrevivieron porque se envían dentro de la aplicación (consulta re_notes/ASSET_INVENTORY.txt). Cada personaje es un paquete de activos completo de Unity que contiene el modelo, las texturas, el esqueleto, los clips de animación, los controladores de animación, los efectos y el audio. Los entornos, edificios, interfaz de usuario, retratos, escenas cinemáticas y diálogos también están allí. Lo que no sobrevivió son los datos que le decían al juego qué activos usar, cómo ensamblarlos en una pelea o misión y cuáles eran realmente los números de cada bot. Todas las piezas están presentes. Simplemente no queda nada que sepa cómo unirlas. Reconstruir eso es el único trabajo que queda.

Cómo funciona el arranque offline

Hay cuatro partes móviles. Juntas hacen que el juego sin modificar piense que está hablando con Kabam.

1. Parches binarios nativos. El juego es Unity IL2CPP, por lo que la lógica vive en una biblioteca ARM compilada, libil2cpp.so, no en archivos de script editables. patches/patch_il2cpp.py reescribe seis funciones en esa biblioteca para superar las comprobaciones de servidor muerto: derrota dos rutas de fijación de certificados para que se acepte nuestro propio certificado TLS, obliga a que se ejecute el bloque de registro del administrador aunque la configuración en vivo sea nula, permite que el inicio de sesión tenga éxito con nuestra sesión de dispositivo local y silencia los errores fatales del subsistema que de otro modo mostrarían el diálogo de "no se pudo iniciar sesión". También reinyecta una sola entrada de dependencia (consulta la sección Gotchas) para que el hook de tiempo de ejecución realmente se cargue. La salida es libil2cpp.patched.so.

2. Un servidor Sparx falso. server/fakeserver.py actúa como el backend de Kabam. Escucha en TLS 443 y HTTP plano 80 y responde a las llamadas API del juego. Las respuestas predefinidas están en server/responses/, un archivo por endpoint, nombrado por método y ruta, por ejemplo GET__account_data.json. Algunos endpoints se responden dinámicamente en código en lugar de desde un archivo, porque el juego espera que repitan valores de la solicitud (los endpoints del tutorial y el endpoint de detalle del héroe). El sobre de respuesta es {"error":null,"result": ...}. Ten en cuenta que dentro de los payloads de error de Sparx, el campo se escribe err, no error. Ese detalle importa y es fácil pasarlo por alto.

3. Un hook nativo en tiempo de ejecución. tools/nativehook/ construye libdothook.so, una biblioteca pequeña que se carga en el juego al inicio y registra cada clave de datos que el juego lee, además de un par de empujones de comportamiento específicos. Este es el bucle de retroalimentación que hizo posible todo lo demás: te dice exactamente lo que el juego está pidiendo para que puedas sintetizar una respuesta y verificarla. Es un hook inline de sobrescritura de bytes puro instalado antes de la ejecución, porque la herramienta normal para esto (Frida) falla bajo la capa de traducción ARM del emulador.

4. Cableado del dispositivo. El emulador debe enviar los dominios de Kabam a la PC y confiar en el certificado falso. tools/provision_ldplayer.sh hace esto de una sola vez: envía la biblioteca parcheada y el hook, redirige los nombres de host de Kabam a la dirección LAN de la PC mediante el archivo hosts, monta la CA falsa en el almacén de confianza del sistema y relaja SELinux. Ejecútalo después de cada reinicio del emulador, porque esos montajes no sobreviven a un reinicio.

El flujo de datos en tiempo de ejecución es: el juego realiza una llamada HTTPS a un dominio de Kabam, el archivo hosts lo envía a la PC, el servidor falso responde con una respuesta de server/responses/, la biblioteca parcheada acepta el certificado y la respuesta, y el hook registra lo que se leyó. Ese bucle es cómo se levantó cada pantalla en esta compilación.

Qué hay en este paquete

re_notes/dump.cs es el archivo más valioso para el trabajo que queda. Es el modelo de tipo completo del juego: cada clase, cada método y, crucialmente, cada campo de datos que el cliente lee del servidor. Es tu mapa de toda la API del backend. Cuando necesites saber qué forma debe tener una respuesta, la respuesta está ahí.

Qué no está en este paquete y dónde conseguirlo

Estos se omitieron a propósito, porque son grandes, o tienen derechos de autor, o son secretos, o deberías generar los tuyos.

• El APK en sí (com.kabam.bigrobot, versión 9.2.0). Ocupa unos 800 MB. Consigue tu propia copia. El nombre del paquete y la versión están en TECHNICAL_NOTES.md.
• El libil2cpp.so original y los activos del juego. Ambos salen directamente del APK. Descomprime el APK, la biblioteca está en lib/arm64-v8a/, los activos en assets/.
• El certificado TLS y la CA. No incluyas claves privadas. Ejecuta server/gen_certs.sh para crear tu propio par correspondiente, luego apunta el almacén de confianza del dispositivo a la nueva CA.
• La biblioteca parcheada. Regenerala: ejecuta patches/patch_il2cpp.py contra el libil2cpp.so original del APK.
• El servidor Frida y Il2CppDumper. Ambas son herramientas públicas. Il2CppDumper es lo que produjo re_notes/dump.cs a partir de la biblioteca del APK y los metadatos globales.
• El NDK de Android (se usó r26) y JDK 21, necesarios para compilar el hook y ejecutar el descompilador headless de Ghidra.

Cómo ejecutar lo que existe hoy

Necesitas el APK instalado en un emulador con capacidad de traducción ARM (se usó LDPlayer 9, con root y sistema escribible), Python en la PC y los elementos de la sección anterior.

1. Genera los certificados una vez: bash server/gen_certs.sh.
2. Compila la biblioteca parcheada una vez: python patches/patch_il2cpp.py ruta/al/libil2cpp.so/original --apply.
3. Compila el hook una vez si quieres reconstruirlo, de lo contrario usa el precompilado. Consulta tools/nativehook/deploy.sh.
4. Inicia el servidor falso en la PC: python server/fakeserver.py. Debe ser accesible en los puertos 443 y 80 desde el emulador.
5. Aprovisiona el dispositivo: bash tools/provision_ldplayer.sh <tu-IP-LAN-PC>. Vuelve a ejecutarlo después de cada reinicio del emulador.
6. Espera unos 45 segundos, luego toca la pantalla de título para iniciar sesión. Deberías llegar a la pantalla de inicio.

Si se queda colgado en el inicio de sesión, verifica el primer elemento de la sección Gotchas antes que nada.

Los gotchas que te devorarán el tiempo

Estos son los que me costaron horas. Están escritos para que no te cuesten lo mismo.

• El hook de tiempo de ejecución se carga solo a través de una entrada de dependencia que la biblioteca prístina no tiene. El script de parche construye a partir de la biblioteca prístina, por lo que sin volver a agregar esa entrada, el hook nunca se carga silenciosamente y el inicio de sesión simplemente se cuelga. El script de parche ahora la reinyecta en cada compilación. Si el hook parece muerto, lo primero que hay que verificar es que la biblioteca parcheada realmente haga referencia a libdothook.so. Los bytes exactos y los desplazamientos están documentados en el script de parche y en TECHNICAL_NOTES.md.
• Frida no funciona si estás usando LDPlayer9/Bluestacks para pruebas. El emulador traduce ARM a x86, y Frida falla bajo esa traducción. Toda la razón por la que el proyecto usa un hook inline de sobrescritura de bytes puro es que sobrevive donde Frida no lo hace. No pierdas tiempo tratando de que Frida funcione.
• Los montajes de red del dispositivo no sobreviven a un reinicio del emulador. La redirección de hosts y la confianza de la CA son montajes bind. Después de cualquier reinicio del emulador, debes volver a ejecutar provision_ldplayer.sh o nada se conectará.
• Dentro de los payloads de error de Sparx, el campo es err, no error. Usar el incorrecto produce respuestas que el cliente ignora silenciosamente o maneja incorrectamente.
• Los estados de indicación del tutorial interactivo se repiten para siempre sin conexión. No intentes responder a una solicitud de tutorial para satisfacerlo. En su lugar, elimina la condición que activa el tutorial en primer lugar. La congelación del tutorial del escudo se solucionó de esta manera, dándole al jugador el recurso cuya ausencia lo desencadenó, en lugar de responder al tutorial.
• La representación de contenido 3D en vivo bajo el emulador es frágil. Los modelos se renderizan, pero esta es el área más inestable y es sensible al backend gráfico y la configuración de textura del emulador. Esto es un problema de gráficos del emulador, no un problema de datos.

Si quieres reactivarlo realmente: reconstruyendo el backend

Este es el trabajo real, y es grande. Aquí tienes la forma y por dónde empezar.

El objetivo es recrear, a mano, el contenido del lado del servidor que solía transmitirse al cliente: las misiones y tareas, los mapas y sus alineaciones enemigas, la lista completa con las estadísticas y habilidades de cada bot, las fórmulas de combate y la economía. Nada de esto existe ya, por lo que todo debe crearse desde cero, en las formas exactas que el cliente espera.

El método que funciona es el bucle en torno al cual se construyó este proyecto. Ejecuta el juego con el hook adjunto. El hook registra cada clave que el cliente lee. Cuando el cliente pide algo que no has proporcionado, ves exactamente lo que quería. Luego sintetizas una respuesta en la forma correcta, la colocas en server/responses/ o la agregas al manejador dinámico en fakeserver.py, reinicias y verificas que el cliente la acepte y avance. Repite. Cada pantalla en la compilación actual se levantó exactamente de esta manera. re_notes/dump.cs te indica la forma de cada estructura incluso antes de ejecutar, porque enumera cada campo que el cliente lee.

Un orden sensato para atacarlo:

1. Conseguir que una sola pelea completa se cargue y se ejecute de principio a fin. Este es el objetivo de mayor valor porque el combate es el núcleo del juego y ejercita la mayor cantidad de datos del servidor a la vez. Necesitas las definiciones de los participantes, sus estadísticas y habilidades, y lo que sea que pida la ruta de inicio de la pelea. La pelea introductoria ya comienza a cargarse, por lo que ese es el lugar por el que presionar primero. Descompila las rutas de inicio de la pelea y datos de combate (usa decompile_targets.py) y lee los campos exactos.
2. Reconstruir completamente el modelo de datos de la lista, un bot a la vez, incluyendo estadísticas y habilidades. El arte para cada bot ya existe en los paquetes enumerados en ASSET_INVENTORY.txt, por lo que solo estás creando números y definiciones de habilidades, no activos.
3. Reconstruir las estructuras de misiones y mapas para que la Historia deje de estar vacía. La estructura base ya se descifró parcialmente, consulta TECHNICAL_NOTES.md para las claves.
4. Completar la economía y la progresión al final, una vez que existan peleas y misiones en las que gastarlas.

Sé realista sobre la escala. Incluso para juegos donde los fanáticos guardaron los datos del servidor en vivo antes del cierre, montar un servidor privado es un proyecto largo. Aquí no hay datos guardados para empezar, por lo que cada número y cada habilidad debe investigarse o reinventarse y luego verificarse contra el cliente. Esto es un esfuerzo de varias personas y varios años si el objetivo es el juego real. Dicho esto, el camino ya no es un misterio. El arranque está resuelto, el bucle de retroalimentación existe, el modelo de tipo está volcado y los activos están intactos. Lo que queda es una cantidad muy grande de reconstrucción cuidadosa de datos, no más ingeniería inversa de lo desconocido.

Comienza con TECHNICAL_NOTES.md. Es la referencia técnica más profunda, con los parches exactos, las formas de datos recuperadas y los hallazgos específicos, con más detalle que este README. Luego ejecuta el bucle.

Buena suerte. Ahora es una máquina real. Solo necesita que se reconstruya su contenido.