Transformers-Forged-To-Fight-Offline-Version

Então a situação se divide claramente em duas. A arte e o áudio sobreviveram, porque eles estão embutidos no aplicativo (veja re_notes/ASSET_INVENTORY.txt). Cada personagem é um pacote completo de asset da Unity contendo o modelo, texturas, rig, clipes de animação, controladores de animação, efeitos e áudio. Os ambientes, edifícios, interface, retratos, cenas e diálogos também estão todos lá. O que não sobreviveu foram os dados que diziam ao jogo quais desses assets usar, como montá-los em uma luta ou missão, e quais eram os números reais de cada robô. Todas as peças estão presentes. Só não resta nada que saiba como juntá-las. Reconstruir isso é todo o trabalho que resta.

Como funciona a inicialização offline

Há quatro partes móveis. Juntas, elas fazem o jogo não modificado pensar que está falando com a Kabam.

1. Patches binários nativos. O jogo é Unity IL2CPP, então a lógica vive em uma biblioteca ARM compilada, libil2cpp.so, não em arquivos de script editáveis. patches/patch_il2cpp.py reescreve seis funções nessa biblioteca para passar pelas verificações de servidor morto: ele derrota dois caminhos de pinning de certificado para que nosso próprio certificado TLS seja aceito, força o bloco de registro do gerenciador a ser executado mesmo que a configuração ao vivo seja nula, permite que o login seja bem-sucedido com nossa sessão de dispositivo local e silencia os erros fatais do subsistema que, de outra forma, exibiriam o diálogo "falha ao fazer login". Ele também reinjeta uma única entrada de dependência (veja a seção Gotchas) para que o hook em tempo de execução realmente carregue. A saída é libil2cpp.patched.so.

2. Um servidor Sparx falso. server/fakeserver.py faz o papel do backend da Kabam. Ele escuta nas portas TLS 443 e HTTP 80 simples e responde às chamadas de API do jogo. Respostas pré-definidas ficam em server/responses/, um arquivo por endpoint, nomeado por método e caminho, por exemplo, GET__account_data.json. Alguns endpoints são respondidos dinamicamente em código, em vez de a partir de um arquivo, porque o jogo espera que eles ecoem valores da requisição (os endpoints do tutorial e o endpoint de detalhes do herói). O envelope de resposta é {"error":null,"result": ...}. Note que dentro dos payloads de erro do Sparx, o campo é escrito err, não error. Esse detalhe é importante e fácil de perder.

3. Um hook nativo em tempo de execução. tools/nativehook/ compila libdothook.so, uma pequena biblioteca que é carregada no jogo na inicialização e registra cada chave de dados que o jogo lê, além de alguns ajustes de comportamento direcionados. Este é o ciclo de feedback que tornou todo o resto possível: ele diz exatamente o que o jogo está pedindo para que você possa sintetizar uma resposta e verificar se funciona. É um hook inline de sobrescrita de byte puro instalado antes da execução, porque a ferramenta normal para isso (Frida) trava sob a camada de tradução ARM do emulador.

4. Configuração do dispositivo. O emulador tem que enviar os domínios da Kabam para o PC e confiar no certificado falso. tools/provision_ldplayer.sh faz isso em uma única etapa: ele envia a biblioteca patcheada e o hook, redireciona os hostnames da Kabam para o endereço LAN do PC via arquivo hosts, monta a CA falsa no armazenamento de confiança do sistema e relaxa o SELinux. Execute-o após cada reinicialização do emulador, porque essas montagens não sobrevivem a uma reinicialização.

O fluxo de dados em tempo de execução é: o jogo faz uma chamada HTTPS para um domínio da Kabam, o arquivo hosts a envia para o PC, o servidor falso responde com uma resposta de server/responses/, a biblioteca patcheada aceita o certificado e a resposta, e o hook registra o que foi lido. Esse loop é como cada tela nesta compilação foi trazida à vida.

O que está neste pacote

re_notes/dump.cs é o arquivo mais valioso para o trabalho que resta. É o modelo de tipos completo do jogo: toda classe, todo método e, crucialmente, todo campo de dados que o cliente lê do servidor. É o seu mapa de toda a API do backend. Quando você precisar saber qual deve ser a forma de uma resposta, a resposta está lá.

O que não está neste pacote e onde obter

Estes foram deixados de fora de propósito, porque são grandes, ou protegidos por direitos autorais, ou secretos, ou você deveria gerar os seus próprios.

• O APK em si (com.kabam.bigrobot, versão 9.2.0). Tem cerca de 800 MB. Obtenha sua própria cópia. O nome do pacote e a versão estão em TECHNICAL_NOTES.md.
• O libil2cpp.so original e os assets do jogo. Ambos saem diretamente do APK. Descompacte o APK, a biblioteca está em lib/arm64-v8a/, os assets estão em assets/.
• O certificado TLS e a CA. Não envie chaves privadas. Execute server/gen_certs.sh para criar seu próprio par correspondente, depois aponte o armazenamento de confiança do dispositivo para a nova CA.
• A biblioteca patcheada. Regere-a: execute patches/patch_il2cpp.py contra o libil2cpp.so original do APK.
• Servidor Frida e Il2CppDumper. Ambos são ferramentas públicas. Il2CppDumper foi o que produziu re_notes/dump.cs a partir da biblioteca do APK e dos metadados globais.
• O Android NDK (r26 foi usado) e JDK 21, necessários para compilar o hook e executar o descompilador headless do Ghidra.

Como executar o que existe hoje

Você precisa do APK instalado em um emulador com capacidade de tradução ARM (LDPlayer 9 foi usado, com root e sistema gravável), Python no PC e os itens da seção acima.

1. Gere certificados uma vez: bash server/gen_certs.sh.
2. Compile a biblioteca patcheada uma vez: python patches/patch_il2cpp.py caminho/para/o/libil2cpp.so/original --apply.
3. Compile o hook uma vez se quiser reconstruí-lo, caso contrário use o pré-compilado. Veja tools/nativehook/deploy.sh.
4. Inicie o servidor falso no PC: python server/fakeserver.py. Ele precisa estar acessível nas portas 443 e 80 a partir do emulador.
5. Provisione o dispositivo: bash tools/provision_ldplayer.sh <seu-IP-LAN-PC>. Execute novamente após cada reinicialização do emulador.
6. Aguarde cerca de 45 segundos, depois toque na tela de título para fazer login. Você deve chegar à tela inicial.

Se travar no login, verifique o primeiro item da seção Gotchas antes de qualquer outra coisa.

Os gotchas que vão consumir seu tempo

Estes são os que me custaram horas. Eles estão escritos para que não custem o mesmo para você.

• O hook em tempo de execução só carrega através de uma entrada de dependência que a biblioteca original não possui. O script de patch compila a partir da biblioteca original, então sem readicionar essa entrada, o hook nunca é carregado silenciosamente e o login simplesmente trava. O script de patch agora a reinjeta em cada compilação. Se o hook parecer morto, a primeira coisa a verificar é se a biblioteca patcheada realmente referencia libdothook.so. Os bytes e offsets exatos estão documentados no script de patch e em TECHNICAL_NOTES.md.
• O Frida não funciona se você estiver usando LDPlayer9/Bluestacks para testes. O emulador traduz ARM para x86, e o Frida trava sob essa tradução. A razão pela qual o projeto usa um hook inline de sobrescrita de byte puro é que ele sobrevive onde o Frida não sobrevive. Não perca tempo tentando fazer o Frida funcionar.
• As montagens de rede do dispositivo não sobrevivem a uma reinicialização do emulador. O redirecionamento de hosts e a confiança da CA são montagens bind. Após qualquer reinicialização do emulador, você deve executar novamente provision_ldplayer.sh ou nada se conectará.
• Dentro dos payloads de erro do Sparx, o campo é err, não error. Usar o errado produz respostas que o cliente ignora silenciosamente ou trata incorretamente.
• Os estados de prompt do tutorial interativo entram em loop infinito offline. Não tente responder a uma requisição de tutorial para satisfazê-lo. Em vez disso, remova a condição que aciona o tutorial em primeiro lugar. O congelamento do tutorial de escudo foi corrigido dessa forma, fornecendo ao jogador o recurso cuja ausência o acionou, em vez de responder ao tutorial.
• A renderização de conteúdo 3D ao vivo no emulador é frágil. Os modelos realmente renderizam, mas esta é a área mais instável e é sensível ao backend gráfico e às configurações de textura do emulador. Isso é um problema gráfico do emulador, não um problema de dados.

Se você quiser realmente revivê-lo: reconstruindo o backend

Este é o trabalho real, e é grande. Aqui está a forma dele e por onde começar.

O objetivo é recriar, manualmente, o conteúdo do lado do servidor que costumava ser transmitido para o cliente: as quests e missões, os mapas e suas escalações inimigas, o elenco completo com as estatísticas e habilidades de cada robô, as fórmulas de combate e a economia. Nada disso existe mais, então tudo tem que ser criado do zero, nas formas exatas que o cliente espera.

O método que funciona é o loop em torno do qual este projeto foi construído. Execute o jogo com o hook anexado. O hook registra cada chave que o cliente lê. Quando o cliente pede algo que você não forneceu, você vê exatamente o que ele queria. Você então sintetiza uma resposta na forma correta, coloca em server/responses/ ou adiciona ao manipulador dinâmico em fakeserver.py, reinicia e verifica se o cliente aceita e avança. Repita. Cada tela na compilação atual foi trazida exatamente dessa forma. re_notes/dump.cs informa a forma de cada estrutura antes mesmo de você executar, porque ele lista todos os campos que o cliente lê.

Uma ordem sensata para atacar:

1. Faça uma única luta completa carregar e executar de ponta a ponta. Este é o alvo de maior valor porque o combate é o núcleo do jogo e exercita a maior parte dos dados do servidor de uma só vez. Você precisa das definições dos participantes, suas estatísticas e habilidades, e tudo o que o caminho de início da luta pede. A luta introdutória já começa a carregar, então esse é o lugar para forçar primeiro. Descompile os caminhos de início da luta e dados de combate (use decompile_targets.py) e leia os campos exatos.
2. Reconstrua totalmente o modelo de dados do elenco, um robô de cada vez, incluindo estatísticas e habilidades. A arte para cada robô já existe nos pacotes listados em ASSET_INVENTORY.txt, então você está apenas criando números e definições de habilidades, não assets.
3. Reconstrua as estruturas de quest e mapa para que a História pare de ficar vazia. A estrutura base já foi parcialmente quebrada, veja TECHNICAL_NOTES.md para as chaves.
4. Preencha a economia e a progressão por último, uma vez que existam lutas e missões para gastar.

Seja realista sobre a escala. Mesmo para jogos onde os fãs salvaram os dados do servidor ao vivo antes do desligamento, montar um servidor privado é um longo projeto. Aqui não há dados salvos para começar, então cada número e cada habilidade tem que ser pesquisado ou reinventado e então verificado contra o cliente. Este é um esforço de várias pessoas e vários anos se o objetivo for o jogo real. Dito isso, o caminho não é mais um mistério. A inicialização está resolvida, o ciclo de feedback existe, o modelo de tipos foi extraído e os assets estão intactos. O que resta é uma grande quantidade de cuidadosa reconstrução de dados, não mais engenharia reversa do desconhecido.

Comece com TECHNICAL_NOTES.md. É a referência técnica mais aprofundada, com os patches exatos, os formatos de dados recuperados e as descobertas específicas, em mais detalhes do que este README. Depois execute o loop.

Boa sorte. Agora é uma máquina real. Só precisa que seu conteúdo seja reconstruído.