Escrow FiveM: o que é e o que muda para quem compra

Se você já abriu a pasta de um script comprado e encontrou um arquivo .fxap ao lado de código que não dá para ler, conheceu o asset escrow do FiveM. Vale deixar uma coisa clara desde o início: o escrow existe para proteger o autor do script, não é um seguro para quem compra. Para você ele tem efeitos úteis, porém indiretos, e aqui explicamos com precisão o que ele protege, o que traz para o comprador, quais arquivos você pode mexer e quando o código aberto serve melhor para a sua cidade.

O que é o asset escrow do FiveM?

O asset escrow é o sistema oficial da Cfx.re para criptografar o código de um recurso e proteger o trabalho do autor. O desenvolvedor envia o recurso, o código é criptografado e só roda em servidores cuja conta Cfx.re tenha a permissão correspondente. É uma proteção pensada para quem vende, não uma garantia para quem compra.

Quando um desenvolvedor publica um script protegido, o código é criptografado e distribuído junto de um arquivo .fxap, que faz parte do sistema. Esse conteúdo criptografado não pode ser lido nem executado por conta própria.

A autorização chega por outro caminho: o Keymaster. Ao comprar o script em uma loja com checkout do Tebex, você recebe um asset grant vinculado à sua conta Cfx.re. Quando o seu servidor inicia, ele se identifica com a licença, o sistema confere se a sua conta tem o grant e só então o runtime descriptografa e executa o recurso. Sem grant, não há execução.

Por dentro, a pasta de um recurso protegido tem um aspecto reconhecível: o fxmanifest.lua continua legível, você vê arquivos abertos como a configuração e as traduções em texto simples, e ao lado deles os arquivos criptografados e o .fxap. A instalação é igual à de qualquer outro recurso, com a sua pasta e o ensure no server.cfg.

Duas consequências práticas desse desenho:

• A proteção não depende de ofuscadores caseiros nem de “licenças” por IP que consultam servidores do vendedor. É infraestrutura oficial da plataforma e não exige que o vendedor mantenha nenhum serviço próprio ligado para o seu script funcionar.
• A descriptografia acontece ao carregar o recurso. No dia a dia o código roda como qualquer outro; não existe uma camada de criptografia permanente pesando em cada função.

O que o escrow protege e quem ele protege

O escrow protege o desenvolvedor contra cópias e revendas não autorizadas: o código criptografado só funciona com o grant da conta que o comprou. Ele não garante qualidade, suporte nem compatibilidade do script. Essas garantias dependem do vendedor, não da criptografia, e convém avaliá-las separadamente antes de pagar.

Sem escrow, qualquer comprador poderia subir o script inteiro em um fórum de leaks no mesmo dia do lançamento, e o autor deixaria de ganhar pelo trabalho. Com escrow, redistribuir os arquivos do jeito que estão não adianta nada: falta a autorização do Keymaster. Não é uma barreira infalível, mas encarece muito a cópia e mantém viável o modelo de venda para quem desenvolve.

O ponto que você precisa ter claro: um script usar escrow não prova que ele é bom, que está bem mantido nem que o vendedor vai atender você. É uma peça de infraestrutura, não uma certificação de qualidade.

O que o comprador ganha com um script com escrow?

Como comprador você leva quatro coisas concretas: uma licença associada à sua conta Cfx.re por meio dos asset grants do Keymaster, acesso às atualizações legítimas do autor, arquivos de configuração que continuam editáveis e um motivo claro para evitar cópias vazadas, que costumam vir adulteradas e podem esconder backdoors ou malware.

Detalhando cada ponto:

• Licença vinculada à sua conta. O grant fica registrado na sua conta Cfx.re, não depende de IP nem de serviço do vendedor. Se você trocar de servidor ou montar um de testes, gerencia a permissão pelo seu próprio Keymaster.
• Atualizações legítimas. As novas versões do autor chegam a quem tem o grant. O escrow ser a base do modelo comercial ajuda o criador a continuar mantendo o produto, mas a política de atualizações concreta é definida por cada loja: pergunte.
• Configuração editável. Um bom empacotamento deixa aberto tudo o que você precisa ajustar, como veremos na próxima seção.
• Um motivo para não usar leaks. A cópia pirata não tem nada do que está acima.

Quais arquivos você pode editar em um script com escrow

Em um script bem empacotado você pode editar a configuração, as traduções e, muitas vezes, a interface. O desenvolvedor decide quais arquivos são criptografados e quais ficam abertos, e declara isso no manifesto do recurso com escrow_ignore. A lógica interna é o que permanece criptografado.

fx_version 'cerulean'
game 'gta5'

escrow_ignore {
    'config.lua',
    'locales/*.lua',
    'html/**/*'
}

Tudo o que está listado em escrow_ignore é distribuído como texto simples editável. Em um script bem empacotado isso inclui, no mínimo:

• A configuração (config.lua ou equivalente): preços, posições, permissões, tempos, ativar ou desativar funções.
• As traduções (locales): para adaptar os textos à sua comunidade.
• Muitas vezes a interface (html): para ajustar estilos e encaixá-la na identidade visual da sua cidade.

Um bom vendedor desenha o script para que tudo o que o dono de servidor precisa ajustar fique fora da criptografia. Se um produto protege até o arquivo de configuração, o empacotamento está mal feito e isso é um sinal para desconfiar.

Há outra via de personalização que o escrow também não fecha: a integração com o resto do seu servidor. Um script protegido bem desenhado expõe exports e eventos documentados, de modo que os seus próprios recursos conversam com ele sem ler uma linha do código fechado. Por isso a documentação pesa tanto: ela define quais pontos de conexão você tem disponíveis.

Escrow ou código aberto?

Depende de quanta personalização profunda e auditoria você precisa. O escrow combina com scripts de gameplay prontos, em que você ajusta a configuração e o autor mantém a lógica. O código aberto é melhor para bibliotecas, bases de framework e servidores com programadores próprios que querem auditar e modificar cada sistema.

Vamos ser justos com a postura aberta, que tem argumentos sólidos. Muitos desenvolvedores de servidor preferem código 100% aberto: querem auditar o que rodam na própria máquina, adaptar a lógica a sistemas próprios e não depender da infraestrutura de ninguém. Um recurso criptografado, além disso, não pode ser revisado linha a linha, então a confiança precisa ser colocada na reputação do vendedor.

• Se o seu servidor tem desenvolvedores próprios e precisa integrar cada sistema a fundo, procure produtos open source ou versões sem criptografia quando existirem.
• Para bases de framework, bibliotecas e utilitários compartilhados, o aberto é o padrão do ecossistema. No nosso guia de scripts grátis para FiveM listamos os imprescindíveis desse mundo.
• Para scripts de gameplay prontos (empregos, sistemas de economia, mecânicas completas), o escrow com configuração aberta atende a maioria das comunidades.

Não são lados irreconciliáveis. Muitos servidores maduros combinam os dois, incluindo recursos standalone que funcionam com qualquer framework.

Por que evitar cópias vazadas de scripts com escrow?

Porque uma cópia vazada não tem licença, atualizações nem suporte, e para funcionar alguém precisou adulterar o recurso. Essas versões alteradas com frequência trazem backdoors ou malware que dão a terceiros acesso ao seu servidor e ao seu banco de dados. Economizar o preço do script pode sair muito caro.

Considere três efeitos:

• Sem grant legítimo, sem respaldo. Não há Keymaster, nem nota fiscal, nem vendedor a quem reclamar.
• Sem atualizações. A cópia fica congelada na versão vazada e se degrada a cada mudança do seu framework.
• Risco para a sua comunidade. Código que você não consegue auditar e que alguém modificou é exatamente o cenário que um atacante procura. Além disso, usar conteúdo pirateado coloca você em conflito com as regras da plataforma.

Como saber o que é editável antes de comprar

Antes de pagar, confira na página do produto e na documentação quais arquivos ficam fora da criptografia e pergunte ao suporte se algo não estiver claro. Como as vendas pelo Tebex são finais, essa verificação precisa acontecer antes do pagamento. Cinco checagens rápidas:

1. Leia a página do produto. Uma loja séria informa quais arquivos estão abertos: procure menções a “config aberta”, “locales editáveis” ou “UI aberta”.
2. Veja a documentação pública. Se você consegue ler o guia de configuração antes de comprar, sabe exatamente quais parâmetros existem e qual margem de personalização tem.
3. Pergunte ao suporte. Um vendedor com suporte de verdade responde em minutos o que o escrow_ignore do produto inclui. O silêncio também é uma resposta.
4. Confirme a compatibilidade. Verifique se o script suporta o seu framework (QBCore, ESX, Qbox ou standalone) sem edições no código fechado, porque essas você não vai conseguir fazer.
5. Teste em desenvolvimento antes de produção. Os grants pertencem à sua conta Cfx.re, então você pode gerar uma segunda licença com a mesma conta e montar o script primeiro em um servidor de testes.

Na Cube Resources, todos os scripts protegidos são entregues com a configuração, os locales e a interface fora do escrow, com documentação pública e suporte 24/7 por Discord e tickets para resolver qualquer dúvida antes e depois da compra.

Resumo: o que levar do escrow

O escrow, bem usado, protege o criador e dá a você uma licença limpa, atualizações legítimas e configuração editável. O resto, qualidade e suporte, você precisa verificar na loja. Se procura scripts protegidos com configuração realmente aberta e testados no nosso próprio servidor de roleplay, explore o catálogo completo ou vá direto à seção do seu framework, como QBCore.