Transformers: Forged to Fight, transferência de reavivamento offline

Este pacote contém uma inicialização offline funcional de Transformers: Forged to Fight, além de todas as ferramentas, patches e notas de engenharia reversa usadas para chegar lá. Ele foi feito para ser pego por alguém que tenha tempo e energia para dar o próximo e muito maior passo, que é reconstruir o conteúdo do lado do servidor do jogo do zero. Tudo aqui está documentado para que você não precise começar do zero como eu fiz.

Leia este arquivo inteiro antes de mexer em qualquer coisa. A seção "Gotchas" em particular vai te poupar dias.

O que realmente funciona agora

O jogo inicializa completamente offline e atinge sua tela inicial interativa real sem nenhum servidor ao vivo por perto. A partir da tela inicial, os menus navegam sem travar: a base, a lista de robôs (com um robô presente na conta), a seleção de modo de luta, a tela de cristais, e os pop-ups e dicas habituais. O fluxo completo de login é concluído, todos os subsistemas online se conectam, e a experiência inicial e os portões do tutorial são limpos. A luta introdutória roteirizada (Optimus vs Starscream) até chega ao ponto de começar a carregar a batalha, e os modelos 3D dos personagens renderizam e animam.

Esta foi a parte difícil e está resolvida. O cliente em si está vivo novamente offline.

O que não funciona e porquê

A jogabilidade real não funciona. A história não mostra missões, e as lutas não conseguem carregar completamente. Isso não é um bug e não é algo que um patch possa corrigir.

Forged to Fight era totalmente autoritativo no servidor. O aplicativo no telefone é essencialmente uma tela com controles. Quase nada do jogo vivia no aplicativo. Cada missão, cada luta, cada escalação inimiga, as estatísticas e habilidades de todo o elenco, a economia e todo o equilíbrio viviam nos servidores da Kabam e eram transmitidos para o dispositivo a cada sessão. Quando os servidores foram desligados no início de 2020, esse banco de dados de conteúdo foi junto, e nunca foi liberado ou arquivado publicamente em nenhum lugar que eu possa alcançar.

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