$ USD
Como o sistema de custódia do FiveM foi descriptografado — Uma explicação técnica clara&#…
Resumo curto: Você não quebrou a criptografia. Os invasores capturaram o momento em que o próprio FiveM descriptografou os arquivos protegidos e se apropriaram dessas saídas descriptografadas ou das chaves temporárias. Essa falha está na implementação e no tempo de execução, não na matemática.
Por que isso é importante
Se você vende ou administra recursos pagos do FiveM (scripts, mapas, modelos), o escrow promete manter seu trabalho privado e vinculado a servidores licenciados. Quando o escrow falha, vazamentos se espalham rapidamente. Você perde receita e controle, e seu servidor corre o risco de ser banido por usar ativos vazados.
Este artigo explica em linguagem simples como os invasores contornaram o depósito em garantia da FiveM, os dois principais caminhos técnicos que eles usaram e o que você pode fazer para proteger os recursos.
O escrow não falhou porque o AES é fraco. Ele falhou porque os invasores capturaram os dados descriptografados ou as chaves enquanto o próprio FiveM os utilizava.
Como o escrow deve funcionar (simples)
- Um criador carrega um ativo no serviço de custódia. O ativo é enviado em um pacote criptografado.
- Um servidor ou cliente licenciado solicita o ativo. O serviço de custódia verifica a licença e emite uma etapa de descriptografia de curta duração.
- O cliente ou servidor descriptografa o ativo na memória e o utiliza. O ativo nunca deve ser armazenado em formato legível fora do processo.
O sistema assume que o cliente e o servidor executam códigos confiáveis e que os segredos (chaves) desaparecem rapidamente da memória.
A fraqueza fundamental
Qualquer sistema que descriptografe na máquina de um usuário deve expor texto simples ou chaves em tempo de execução. Se um invasor controlar ou inspecionar esse tempo de execução, ele poderá copiar o texto simples ou obter as chaves.
Resumidamente: você pode proteger dados em repouso e em trânsito, mas não enquanto um processo confiável mantém o texto simples.
Dois caminhos de ataque reais usados pelos invasores
Os invasores utilizaram duas abordagens eficazes. Ambas se baseiam na mesma ideia básica: capturar o ativo no momento em que o FiveM já o descriptografou.
1) Binário do servidor modificado -> despejar bytecode Lua descriptografado
O que eles fizeram, simplesmente:
- Eles criaram um binário de servidor FiveM personalizado e modificaram o carregador de recursos Lua.
- O carregador modificado interceptou o script logo após o FiveM descriptografá-lo e gravou o bytecode descriptografado no disco.
- Eles executaram um descompilador Lua naquele bytecode para obter scripts utilizáveis.
Por que funcionou:
- O FiveM deve entregar o bytecode executável para a VM Lua. O servidor modificado substituiu ou conectou o carregador e extraiu esse bytecode.
- O carregador é executado no servidor, e o proprietário do servidor pode compilar e executar um binário personalizado, para que invasores possam alterar seu comportamento.
Limitações:
- O dump produziu bytecode compilado, não o código-fonte original com nomes de variáveis ou comentários. Os descompiladores reconstroem código funcional, não o estilo de criação original.
- Este método tinha como alvo scripts Lua. Ele não expunha trivialmente todos os ativos transmitidos, como mapas ou modelos complexos.
Evidências técnicas e implementações de referência:
- Várias postagens da comunidade e um repositório público de prova de conceito mostram como corrigir
CarregarArquivoInternono componente de script para escrever o bytecode descriptografado. Consulte o repositório PoC em GitHub para obter detalhes.
2) Captura do lado do cliente -> capturar arquivo criptografado + chave de sessão -> descriptografar offline
O que eles fizeram, simplesmente:
- Eles registraram o download de ativos do cliente ou observaram o tráfego de rede.
- Eles inspecionaram a memória do processo FiveM para encontrar a chave de sessão temporária que o cliente usou para descriptografar o ativo.
- Eles combinaram o arquivo criptografado capturado e a chave para descriptografar o ativo em sua máquina.
Por que funcionou:
- O cliente precisa receber ou derivar uma chave de descriptografia para usar o ativo. Se essa chave permanecer na memória por tempo suficiente, os invasores poderão encontrá-la.
- A interceptação de rede (proxy local, captura de pacotes ou interceptação de APIs de rede) pode capturar o arquivo criptografado enquanto ele é transmitido.
O que isso dá aos invasores:
- Recursos completos, não apenas scripts Lua. Isso inclui mapas, modelos, texturas e outros conteúdos transmitidos, caso o invasor capture os arquivos e chaves corretos.
Principal fraqueza da implementação:
- As chaves permaneceram na RAM por mais tempo do que o necessário ou não foram apagadas imediatamente. Os invasores leram a RAM e as encontraram.
Por que a criptografia em si não é o problema
Os invasores não quebraram o AES ou qualquer cifra padrão. Eles quebrou o meio ambiente onde chaves e texto simples devem residir para executar o jogo. Essa é uma classe comum de falhas em DRM ou proteções do lado do cliente.
Pense assim: você tranca uma caixa, mas alguém abre a fechadura quando realmente precisa do conteúdo e tira uma foto da caixa aberta. A fechadura ainda funciona. O invasor explorou o fato de a caixa ter aberto em um local observável.
Como os invasores transformaram bytecode em código legível e utilizável
O bytecode despejado é de baixo nível. Não possui nomes de variáveis, mas contém a lógica e a estrutura da função. Os invasores usaram ou adaptaram descompiladores Lua para reconstruir código legível. O resultado é executado da mesma maneira e revela a lógica do autor.
A descompilação introduz ruído (variáveis renomeadas, formatação diferente), mas fornece um script utilizável e editável.
O que o FiveM e os criadores mudaram após os vazamentos
A FiveM respondeu de várias maneiras:
- Eles rastrearam e baniram servidores que usavam ativos vazados ou pirateados.
- They changed parts of the loader and key manuseio to make the original PoC ineffective.
- Eles reforçaram as verificações de licenças e reduziram a vida útil das chaves.
Essas medidas elevam o nível de exigência. Elas não tornam a execução do lado do cliente magicamente segura, mas reduzem os caminhos fáceis de ataque.
Recomendações práticas para criadores e administradores de servidores (o que você pode fazer)
Você precisa tratar a execução do lado do cliente como não confiável. Diminua os vazamentos e limite os danos.
Para criadores
- Lógica dividida: Coloque lógica crítica ou sensível no servidor sempre que possível. Mantenha o código do cliente mínimo. Se um recurso não exigir lógica do lado do cliente, mova-o para verificações do lado do servidor.
- Vida útil curta das chaves: Garanta que qualquer chave de descriptografia exista apenas pelo menor tempo possível e depois seja apagada com segurança da memória.
- Ofuscação mais custódia: Utilize proteções em camadas. Escrow, ofuscação e controles legais reduzem vazamentos casuais. A ofuscação retarda a engenharia reversa, mas não detém invasores determinados.
- Verificações de integridade do navio: Adicione verificação de integridade e revogação remota. Se detectar um vazamento, revogue o recurso e invalide as licenças rapidamente.
- Uso e relatórios de instrumentos: Registre quais servidores solicitam quais ativos para que você possa detectar downloads em massa suspeitos.
Para operadores de servidores
- Não execute binários modificados: Binários de servidor personalizados podem executar conteúdo vazado. Use compilações oficiais para evitar se tornar inadvertidamente um ponto de distribuição.
- Monitorar arquivos e permissões do servidor: Evite o despejo automatizado restringindo o acesso de gravação e verificando as alterações no tempo de execução.
- Relatar vazamentos: Se você encontrar um ativo vazado, denuncie ao provedor de custódia para que ele possa agir contra os abusadores.
O que os defensores não podem impedir completamente (seja realista)
- Não é possível impedir que um invasor determinado, com controle total da máquina de um usuário, capture texto simples. Se o cliente puder executá-lo, alguém com controle local poderá copiá-lo.
- Você não pode confiar somente na criptografia para impor o licenciamento se a descriptografia ocorrer em um dispositivo de usuário que você não controla.
A abordagem correta mistura controles técnicos, medidas legais e monitoramento ativo.
Um exemplo curto e simples (sem código)
- O servidor envia criptografado
script.fxappara o jogador. - O cliente do jogador recebe o arquivo e a chave de curta duração.
- O cliente descriptografa o arquivo na memória e passa o bytecode para a VM Lua.
- Um invasor conecta o carregador do cliente ou do servidor e copia esse bytecode enquanto ele é executado.
- O invasor executa um descompilador Lua no bytecode e reconstrói scripts legíveis.
Essa sequência é exatamente o que aconteceu em vários casos vazados.
Questões legais e de execução da plataforma
Provedores de custódia podem banir servidores e usuários que utilizem ativos vazados. Isso elimina o incentivo econômico para a pirataria casual. No entanto, ações judiciais e proibições não podem deter todos os invasores motivados.
Resumo — a única frase que você pode usar em seu artigo
O depósito em garantia falhou não porque a criptografia era fraca, mas porque os invasores capturaram o momento em que o próprio sistema descriptografou os ativos e pegaram o texto simples ou as chaves resultantes.
Links internos (leitura adicional neste site)
Veja nossos recursos do QBCore e notas de implantação segura
Fontes e leituras adicionais
- Fórum Cfx.re — “Abordando a recente exploração de custódia de ativos”: https://forum.cfx.re/t/addressing-recent-asset-escrow-exploit/4879802
- Fórum Cfx.re — “Atualização da Comunidade” (explica o despejo de bytecode Lua): https://forum.cfx.re/t/cfx-re-community-update-july-2022-edition/4878784
- Fórum Cfx.re — “Apresentando o Asset Escrow para seus recursos”: https://forum.cfx.re/t/introducing-asset-escrow-for-your-resources/4777151
- GitHub PoC (exemplo de patch LoadFileInternal): https://github.com/zickzackhd/FivemEscrowPOC
- Referências de bytecode StackOverflow / Lua — noções básicas de descompilação: https://stackoverflow.com/questions/52356120/how-do-i-decompile-this-lua-bytecode
- Discussões da comunidade e páginas de ferramentas (exemplos de ferramentas e serviços de descriptografia): https://vag.gg/tags/decrypted/
- Discussão sobre captura de memória/rede e tópicos de exploração: https://www.unknowncheats.me/forum/alternative-online-mods/657822-decrypting-fivem-escrow-aka-fxap.html
