Como escolher um script FiveM: 7 verificações antes de pagar

Última verificação: 14 de agosto de 2026. Desde as ondas de sanções da Cfx.re em 2025, comprar o recurso errado já não custa o preço do script. Pode custar o servidor.

A 8 de agosto de 2025, a Cfx.re anunciou “two-week suspensions to all servers who are confirmed to have used leaked assets without authorization”, precisando que qualquer servidor reincidente seria eliminado definitivamente. A 16 de outubro de 2025 veio o balanço: as equipas tinham “suspended hundreds of accounts and servers associated with stolen assets, and permanently banned those confirmed to be in violation”.

Isso desloca a questão. Escolher um script FiveM era uma decisão de orçamento. Passou a ser uma decisão de risco, e a maior parte desse risco é visível antes de pagar, desde que se saiba onde olhar.

Esta página lista sete verificações. Cada uma leva menos de cinco minutos, cada uma acontece antes da transação, e cada uma termina com uma pergunta precisa para o vendedor ou um comando preciso para executar. Nada aqui lhe pede que acredite em nós, e quase tudo pode ser virado contra nós.

Valem para qualquer recurso pago, script, MLO, veículo ou pacote de roupas. Escrevemos “script” porque é a palavra que a comunidade usa, mas o escrow também cifra modelos e as sanções abrangem os assets em geral.

Precisão de vocabulário, porque os três confundem-se constantemente: um script open source deixa-o ler e alterar todo o código; um script escrow é cifrado pelo sistema oficial da Cfx.re e só expõe o que o vendedor decidiu deixar aberto; um leak é uma cópia redistribuída sem autorização, seja qual for o seu estado técnico. Os dois primeiros são escolhas comerciais. O terceiro é o que faz banir um servidor.

Porque “leia as avaliações” não é um método

Todos os guias de compra deste setor acabam nos mesmos três conselhos: leia as avaliações, desconfie do código ofuscado, compre a um vendedor de confiança. O primeiro manipula-se, o segundo é impossível num recurso escrow por construção, e o terceiro anda em círculos. Nenhum é uma verificação. Uma verificação tem uma entrada, um procedimento e um resultado que passa ou falha.

1. O vendedor é um criador acreditado pela Tebex?

A Cfx.re escreve-o sem ambiguidade: apenas os criadores acreditados pela Tebex são revendedores autorizados de assets FiveM e RedM. Não é um selo de qualidade, é uma regra de autorização, e decide se tem algum recurso.

Três coisas a verificar, por esta ordem:

• O pagamento passa pela Tebex. Nem uma transferência por Discord, nem um PayPal entre amigos, nem um endereço cripto.
• A entrega chega ao seu Cfx.re Portal, não num .zip por mensagem privada. Um recurso entregue em arquivo não passou pelo sistema escrow, diga o vendedor o que disser.
• O vendedor tem um tópico de release no forum.cfx.re com um histórico datado. Um vendedor ativo há vários anos deixa um rasto público. Sem rasto, ou está a começar ou mudou de nome depois de um incidente.

Fora desse circuito não há recurso a perder: não existe nenhum

É o ponto que a maioria dos compradores percebe tarde demais, e não exige confiar em ninguém, deduz-se do funcionamento.

Uma compra fora da Tebex não produz nenhuma entrega no Portal, logo nenhum entitlement associado à sua conta Cfx.re. Não tem um recurso mal comprado: tem uma pasta de ficheiros, e nada que ateste que pode executá-la. Não há recurso a invocar porque não existe registo algum da transação do lado da plataforma.

Assume muitas formas. Lojas montadas fora da Tebex. Anúncios em marketplaces generalistas de serviços. E sobretudo servidores de Discord dedicados à revenda, muitas vezes ao lado de cheats e de outras ferramentas ilegais, onde primeiro se paga e depois se espera.

Não vamos fingir medir a frequência das burlas nesse circuito, e desconfiamos dos artigos que o afirmam sem o demonstrar. O raciocínio basta: numa transação sem registo, sem plataforma e sem identidade verificada, a única coisa que garante a entrega é a boa vontade do vendedor. Não se precipite porque uma oferta expira dentro de duas horas. É precisamente o momento em que ninguém verifica nada.

Esta primeira verificação sustenta as seis seguintes. Num recurso escrow não consegue ler o código: tudo o que não puder verificar por si transfere-se para a responsabilidade do vendedor. É por isso que vem em primeiro e não em último.

2. O asset é legítimo, e o que arrisca o seu servidor?

É o capítulo que os guias de compra saltam, porque é incómodo de escrever para um vendedor.

“Não sabia que era um leak” não é uma categoria reconhecida. As sanções de 2025 visaram servidores confirmados como utilizadores de assets não autorizados, e um recurso decifrado é detetável no servidor independentemente da intenção do comprador. A sua boa-fé não é uma propriedade técnica do ficheiro.

Cinco sinais que desqualificam uma oferta antes mesmo de olhar para o código:

• Um pacote de trinta a quarenta scripts premium por menos de vinte euros. A aritmética não bate certo. Os bundles legítimos existem, mas juntam o catálogo de um único estúdio, não uma amostra dos lançamentos pagos do mercado.
• Uma entrega por arquivo em vez de pelo Portal.
• Um script premium conhecido revendido sob outra marca, muitas vezes com o ficheiro de configuração original intacto.
• Nenhum changelog. Um recurso mantido tem um histórico de versões. Um recurso copiado tem uma data de download.
• Um vendedor que se recusa a indicar a conta Cfx.re à qual a compra será associada.

3. O que poderá ainda modificar depois de pagar?

Num script escrow o código é cifrado pelo sistema oficial da Cfx.re. Mas o programador escolhe o que deixa legível, com a diretiva escrow_ignore do seu fxmanifest.lua.

A consequência é tudo o que importa, e quase ninguém a formula: o que fica aberto é uma decisão do vendedor, não uma propriedade do escrow. Dois scripts escrow ao mesmo preço podem estar separados por um abismo em matéria de adaptação. Se uma definição não estiver exposta num ficheiro de configuração aberto, fica inacessível para sempre, nem por si, nem pelo seu programador.

Daí a pergunta a fazer antes de pagar, a que separa um vendedor sério de um revendedor:

O que contém o seu escrow_ignore?

Quatro coisas deveriam constar dele, e a quarta é a que ninguém reclama:

• A configuração, senão nenhuma definição é ajustável.
• Os ficheiros de tradução, senão não pode adaptar uma única palavra ao seu universo.
• Os ficheiros de bridge, senão não o consegue ligar ao seu framework.
• O esquema SQL de instalação. É ele que lhe diz que tabelas o recurso vai criar na sua base de dados, e portanto o que vai lá fazer. Lê-lo antes de instalar leva dois minutos.

Um vendedor que não sabe responder, ou que responde de forma evasiva, acabou de lhe dizer algo importante.

Não voltamos a explicar aqui o mecanismo do escrow. Mantemos uma página datada sobre o estado do Asset Escrow no FiveM Enhanced, que trata outra questão, a da sua disponibilidade.

4. É possível detetar uma backdoor antes de iniciar o recurso?

Esta verificação só se aplica ao código que consegue ler: os recursos open source e os ficheiros que um vendedor deixou fora do escrow. Num recurso totalmente cifrado não serve de nada, e tudo volta à primeira verificação. Qualquer guia que lhe peça para “inspecionar o código” de um script escrow descreve algo impossível.

Uma backdoor não parte necessariamente nada, e é esse o problema

Imagina-se um script que destrói a base de dados ou esvazia as contas bancárias. Na prática, uma backdoor que se nota falhou. As que duram não partem nada.

Vimos servidores a correr recursos comprometidos, e a frequência é claramente maior em scripts vindos de um leak do que em recursos comprados a um criador com loja oficial. Repetem-se duas famílias.

A recolha de dados. A mais conhecida: o recurso lê a sua base de dados e devolve o que possa ser explorável. Nada falha, nada alerta, e o servidor funciona perfeitamente enquanto os seus dados saem.

Os eventos deixados abertos para permitir o cheat. Esta é menos conhecida e mais manhosa. O recurso traz eventos exploráveis que permitem a um cheat fazer coisas indetetáveis no seu servidor. Nem sempre é negligência: por vezes é feito em colaboração com criadores de cheats, cuja ferramenta parece então mais poderosa do que a da concorrência. O que é vendido não é o script, é a porta.

A consequência prática é simples: a reputação do criador não é um detalhe de conforto. Algumas pesquisas sobre o seu nome, o seu histórico e os seus tópicos públicos costumam bastar para saber com quem está a falar.

Três padrões a procurar no código legível

Um evento de servidor que escreve sem verificar quem o chamou. Qualquer cliente pode desencadear um evento de rede registado. Se o handler confia nos seus argumentos, qualquer jogador lhe pode passar qualquer coisa.

RegisterNetEvent('shop:giveItem', function(item, amount)
  MySQL.update('UPDATE users SET money = money + ?', { amount })
end)

O sinal é a ausência de validação de source e a ausência de controlo no servidor sobre a legitimidade do pedido. É também exatamente a forma que assume um evento deixado aberto de propósito.

Uma chamada HTTP para um host que não é o do vendedor. As verificações de licença existem e são normais. Uma verificação de licença para um domínio sem relação com o vendedor, que envia mais do que um identificador, não é.

Uma string descodificada e executada no carregamento. Um recurso legítimo não tem razão nenhuma para construir código em execução a partir de uma string codificada.

Uma varredura rápida da sua pasta resources, antes de arrancar seja o que for:

grep -rn "PerformHttpRequest|load(|assert(load|_G[" resources/

A comunidade descreve ainda um sintoma recorrente que convém saber nomear: código que reaparece no fim de client.lua, config.lua ou server.lua depois de ter sido apagado. Se isso acontecer, o recurso não é para reparar, é para retirar.

5. Quanto custa realmente o script em desempenho?

As fichas de produto anunciam 0.00 ms às dezenas. O número costuma ser verdadeiro e quase sempre irrelevante, porque é medido em repouso: recurso carregado, ninguém lá dentro, nada a acontecer. É o equivalente a anunciar um consumo com o motor desligado.

Um recurso mede-se em três estados:

Estado	O que mede
Em repouso	O script está carregado, ninguém o usa
Em uso	Um jogador interage ativamente com ele
Em pico	O pior caso realista, vários jogadores ao mesmo tempo

As referências, seguindo as convenções de trabalho da comunidade e não uma norma oficial: a 60 Hz, o orçamento de uma frame inteira é de 16,67 ms para tudo o que corre. Um recurso saudável mantém-se entre 0,00 e 0,05 ms em repouso. Acima de 0,10 ms olha-se de perto. Acima de 0,5 ms em repouso, algo está mal, e isso antes de qualquer jogador lhe ter tocado.

Para medir você mesmo: F8, e depois resmon 1.

Como é uma medição honesta

Já que pedimos três estados, aqui estão os nossos sobre avenida_interact, com a bancada de teste correspondente. Sem o protocolo, um número não significa nada.

A bancada: 100 pontos de interação fixos, 100 pontos de interação com NPC e janela de diálogo, e a deteção ligada a 50 modelos de entidade diferentes. É o que representa um servidor já avançado, não uma cena de demonstração.

Situação	Medição	Porquê
Jogador em repouso, nenhuma interação à vista	0,00 ms	Nada a avaliar
Jogador de carro, o cliente avalia se deve mostrar algo	0,01 ms	Durante uma fração de segundo, enquanto verifica
Um ponto de interação mostrado em 3D no mundo	0,08 ms	Custo de renderização, enquanto continuar visível
Janela de diálogo com NPC aberta	0,06 ms	O ponto 3D é libertado na abertura em vez de continuar visível

Este último número é o mais instrutivo, e é uma decisão de conceção mais do que uma medição: abrir um diálogo liberta o ponto 3D em vez de o deixar vivo por trás da janela. O custo desce no momento em que o jogador olha para outro lado. É o tipo de compromisso que uma medição em três estados torna visível, e que um 0.00 ms em repouso esconde por completo.

Um ponto cego que quase todos os guias partilham: um script pode ser leve do lado do cliente e ainda assim esmagar a sua base de dados. Conte também as queries SQL por ação. Um recurso que consulta a base a cada frame de uma interação não aparecerá no número do cliente, e é esse que dói com sessenta jogadores. É também por isso que o esquema SQL aberto, na verificação 3, não é um detalhe.

6. A compatibilidade com frameworks é real ou apenas anunciada?

“Compatível com ESX e QBCore” não quer dizer nada por si, porque nenhum dos dois é uma coisa única.

Quatro perguntas a fazer:

• Qual ESX? Legacy e 1.2 não são intercambiáveis.
• Qual QBCore? qb-core e Qbox divergiram, e a resposta depende da versão.
• E o vRP? A pergunta parece secundária quando vista da Europa, mas não é. O Brasil é o maior mercado de FiveM fora do mundo anglófono em número de jogadores, e a maioria dos servidores brasileiros roda em vRP, não em ESX nem em QBCore. Um vendedor que nunca ouviu essa pergunta não olhou além do próprio mercado.
• Os exports e os eventos estão expostos num ficheiro não cifrado?

A quarta é o verdadeiro teste. Um vendedor que expõe o bridge está a dizer-lhe que espera que adapte. Um vendedor que não o expõe está a pedir-lhe que adapte o seu servidor às escolhas dele.

E a boa pergunta seguinte é a do recuo: o que faz o recurso quando não há nenhum framework conhecido? Uma compatibilidade séria prevê um modo autónomo que não depende de nada, e não apenas dois ramos para os dois frameworks mais difundidos.

Sobre a pergunta que as pessoas escrevem mesmo antes de clicar em comprar, se um script QBCore corre em Qbox, a resposta honesta é: em grande parte sim, não sistematicamente. As dependências e alguns exports diferem. Quem responde sim sem nuances está a vender, não a aconselhar.

7. O que acontece depois da compra?

Três armadilhas de pós-venda que nenhuma página costuma reunir.

O erro de entitlement. Mais cedo ou mais tarde vai encontrar You lack the required entitlement to use this resource, e é muito frequente. Significa que a chave de servidor em uso foi gerada por uma conta Cfx.re diferente da que fez a compra. Um servidor corre com uma só chave, e pode verificar qual com sv_licenseKey na consola. A forma clássica de cair nisto é a precipitação: compra-se com a conta que se tem à mão, não com a que gerou a chave. A boa notícia é que tem remédio: uma transferência de propriedade a partir do Portal Cfx.re corrige o erro. Mas essa transferência normalmente só é possível uma vez, por isso vale a pena não a gastar por distração.

O reembolso. Para um conteúdo digital, o direito de retratação extingue-se assim que a execução começa com o seu acordo, o que para um script significa o primeiro download. As políticas observadas neste mercado vão de catorze dias sem justificação a estritamente não reembolsável. O que importa é que a política esteja escrita e lida antes de pagar.

A subscrição. Num recurso vendido por subscrição, a expiração retira o asset da conta e o script deixa de arrancar. Nada se parte, nada é apagado, simplesmente para.

O que observámos no terreno

Não escrevemos esta página a partir de um gabinete de estudos. Escrevemo-la porque cometemos praticamente todos os erros que descreve.

A nossa equipa começou por montar o seu próprio servidor, entre amigos. Nenhum de nós sabia realmente como funcionava um servidor FiveM, e muito menos o que se arriscava. Aprendemos como toda a gente, com tutoriais de arranque encontrados online.

Comprámos para ganhar tempo

A comunidade cresceu mais depressa do que a nossa capacidade de desenvolver. Cada semana trazia pedidos para os quais não tínhamos horas. Comprar scripts não era um conforto, era a única forma de aguentar o ritmo sem fazer os nossos jogadores esperar.

É exatamente a situação em que menos se verifica. É também exatamente aquela em que mais se deveria verificar.

O que acabámos por perceber

Três coisas, que voltavam com tanta regularidade que acabaram por estruturar esta página.

Desempenhos que nada tinham a ver com o anunciado. Recursos vendidos como os mais otimizados do mercado custavam-nos milissegundos que não podíamos permitir-nos. O número anunciado não era falso. Era medido em condições que não se pareciam com nada.

Scripts anunciados como adaptáveis a qualquer servidor, e impossíveis de adaptar ao nosso. Muitas vezes sem má vontade do vendedor: nada estava exposto em configuração. Quando pedíamos uma alteração, não estava prevista, e não tínhamos forma de a fazer nós próprios.

Recursos publicados e depois abandonados. Esses não se partem no dia da compra. Partem-se mais tarde, quando o FiveM evolui e já ninguém mantém nada do outro lado. Nessa altura não comprou um script, alugou um prazo.

O que isso mudou na nossa forma de construir

Os nossos scripts expõem a sua configuração, as suas traduções, os seus bridges e o seu esquema SQL em claro. Não é um favor comercial, é a resposta direta ao que sofremos: não queríamos vender aquilo que odiámos comprar.

Não escrevemos esta página para vender. Escrevemo-la porque ninguém no-la deu.

A checklist em sete linhas

1. O pagamento passa pela Tebex, com entrega no Cfx.re Portal? É imperativo.
2. O vendedor tem um histórico de releases datado no forum.cfx.re? Tem de existir.
3. O preço é plausível face ao que é vendido? Um pacote de trinta scripts premium por vinte euros não é.
4. O que contém o escrow_ignore? Config, locales, bridges e o esquema SQL.
5. Existem medições de resmon em três estados, com o protocolo? Peça as três e a bancada de teste.
6. Que versões exatas de framework, que recuo sem framework, e o bridge é legível? Números de versão, não nomes.
7. Que conta Cfx.re será proprietária do asset, e qual é a política de reembolso escrita? Antes de pagar, não depois.

Perguntas frequentes

Posso ser banido por um leak comprado de boa-fé? As sanções de 2025 visaram servidores confirmados como utilizadores de assets não autorizados. A intenção não é uma propriedade técnica de um ficheiro, e é por isso que a verificação tem de ser feita antes da compra e não depois da suspensão.

É possível modificar um script escrow? Apenas as partes que o programador deixou fora da cifragem através de escrow_ignore. Todo o resto está fechado definitivamente. Pergunte o que contém essa diretiva antes de comprar, não depois.

Existe um script a 0,00 ms? Em repouso, muitos. Em uso, não. Um número sem estado de medição nem protocolo anunciados não lhe diz nada.

Como saber se um script tem uma backdoor? Em código legível, procurando os três padrões descritos acima. Num recurso escrow é impossível, e a pergunta passa a ser a reputação do criador. Saiba também que uma backdoor não parte nada: recolhe dados, ou deixa uma porta aberta a um cheat.

Os scripts gratuitos são compatíveis com todos os frameworks? Não mais do que os pagos. A pergunta é idêntica nos dois casos: que versão de framework, que recuo sem framework, e se o bridge é legível.

A Tebex reembolsa? A Tebex cobra o pagamento, o vendedor define a política. Vai de catorze dias a absolutamente nada, e o direito de retratação sobre um conteúdo digital extingue-se no primeiro download.

Onde encontrar scripts gratuitos fiáveis? As verdadeiras organizações de referência, no GitHub: esx-framework, qbcore-framework, overextended para ox_lib e ox_inventory, e citizenfx. Começar noutro sítio para um recurso gratuito é a forma mais comum de acabar com uma backdoor.

O que estas verificações dão nos nossos próprios scripts

Esta página só vale se puder ser virada contra nós. Aqui está portanto onde cada critério se verifica na Avenida, e o que ainda não cumprimos.

O que está aberto. O nosso escrow_ignore expõe a configuração, as traduções, os bridges, o changelog e o esquema SQL de instalação. Pode assim ler o que o recurso vai criar na sua base de dados antes de o instalar, e ajustar o comportamento sem nos pedir autorização. Só a lógica interna fica protegida. Um caso concreto: as 368 correções de zona do estúdio de tatuagem vivem num ficheiro de config que pode continuar a corrigir.

A compatibilidade. Os nossos scripts detectam ESX, QBCore e vRP, e recuam para um modo autônomo quando nenhum framework está presente, apoiando-se nas natives do jogo. Um modo personalizado liga tudo o resto, e os sistemas de inventário, notificação e interação mais difundidos vêm pré-configurados. Os ficheiros de bridge são legíveis, portanto esta afirmação é verificável e não apenas declarativa: a ficha da barbearia lista os seus sete bridges e diz o que cada alvo lhe custa, vRP incluído.

O reembolso. A nossa política está escrita, e é estrita: sem reembolso por norma, com uma exceção se o script não for funcional e o problema não for resolvido em sete dias úteis. Assumimo-la em vez de a esconder. Um produto digital entregue, funcional e usado durante semanas não se devolve, e a energia que não gastamos a arbitrar pedidos improcedentes gastamo-la a fazer evoluir os scripts.

O desempenho. Cada ficha de produto passou a trazer a sua medição em repouso e as condições em que foi feita, que era exatamente a lacuna que este artigo apontava na publicação. O que ainda falta são os estados em carga e sob pressão no mesmo sítio: peça-nos para qualquer recurso, e exija-nos isso enquanto não estiverem nas fichas.

Ver como estes critérios se verificam no catálogo.

Histórico desta página

• 19 de agosto de 2026. Duas afirmações da última secção estavam desatualizadas e foram corrigidas: o vRP é um alvo detetado e não um ramo personalizado, e a medição em repouso passou a ser publicada em cada ficha de produto.
• 14 de agosto de 2026. Publicação inicial. Verificação dos anúncios da Cfx.re de 8 de agosto e de 16 de outubro de 2025, e da documentação Asset Escrow.

Fontes oficiais

Todas as afirmações factuais desta página provêm da documentação e das comunicações oficiais da Cfx.re, a editora do FiveM. As medições de desempenho são nossas, com o respetivo protocolo.

• Asset Security Update, fórum Cfx.re: os anúncios de sanções de 8 de agosto e de 16 de outubro de 2025.
• Documentação Asset Escrow: formatos cifrados e diretiva escrow_ignore.
• What’s a leaked asset then?: a discussão de referência sobre a definição.

---

Uma dúvida sobre um script antes de comprar, nosso ou de outrem? O mais simples é juntar-se ao nosso Discord. Também respondemos sobre scripts que não vendemos.