Vou começar sendo direto sobre o que esse texto é e o que ele não é.

Esse não é um post sobre moral. Não vou ficar repetindo que pirataria prejudica desenvolvedores, que você deve comprar seus jogos e que a indústria precisa do seu dinheiro. Você provavelmente já sabe disso, e se não sabe, existem textos melhores para essa conversa.

O que vou fazer aqui é diferente: vou explicar um risco técnico concreto, real e documentado que afeta diretamente qualquer pessoa que baixa jogos piratas no computador, especialmente usando os métodos que explodiram em popularidade em 2025 e 2026. Um risco que a maioria das pessoas que está exposta a ele nem sabe que existe.

O Brasil é um dos países com maior índice de pirataria de software e jogos do mundo (isso não é julgamento, é dado) e dentro dessa realidade, um novo método de burlar a proteção anti-pirataria surgiu e se espalhou rapidamente, trazendo junto um conjunto de implicações de segurança que vão muito além de "pode ter vírus".

Para entender o problema de verdade, preciso começar do começo.

O que é o Denuvo e por que ele importa

Se você joga no PC, já ouviu falar do Denuvo. Se você é mais leigo no assunto, provavelmente viu o nome em alguma discussão sobre um jogo travando ou rodando mal ou em algum post reclamando que "o jogo tem Denuvo" como se isso fosse uma doença.

O Denuvo é uma tecnologia de proteção antipirataria desenvolvida pela empresa austríaca Denuvo Software Solutions, hoje parte do grupo Irdeto. Ele não é um DRM (gerenciamento de direitos digitais) standalone. Isso é um ponto técnico importante que muita gente confunde.

DRM é o sistema que controla quem pode usar o software. O Steam tem DRM, a PlayStation tem DRM. O DRM verifica se você tem licença para usar aquele produto.

O Denuvo é diferente, ele é uma camada anti-tamper, ou seja, uma proteção que envolve o DRM existente e impede que alguém o modifique, analise ou remova. Pense assim: o DRM é o cadeado da porta, o Denuvo é o sistema de alarme, as câmeras, o vidro à prova de bala e o cofre dentro do cofre que protege esse cadeado.

Quando o Resident Evil Requiem foi lançado em 2026, ele tinha cinco camadas de proteção simultâneas: o DRM do Steam, o Denuvo, o VMProtect, o anti-tamper próprio da Capcom e o SteamStub. Cinco sistemas diferentes, cada um fazendo uma função específica, todos trabalhando juntos. Remover ou enganar qualquer um deles sem desativar os outros causa falha no jogo.

Mas por que o Denuvo especificamente é tão difícil de remover?

Como o Denuvo funciona por dentro

Para entender o problema de segurança que vou explicar mais adiante, preciso explicar por que o Denuvo é tecnicamente complexo. Não vou entrar em engenharia reversa, mas vou além do superficial porque a profundidade importa aqui.

O Denuvo protege jogos de uma forma que vai muito além de "verificar se você comprou o jogo". Quando um desenvolvedor integra o Denuvo no seu jogo, certas funções do código do jogo são selecionadas para serem "protegidas", essas funções passam a ser executadas dentro de uma máquina virtual interna e um interpretador customizado que só o Denuvo entende.

Para quem não é da área: uma máquina virtual nesse contexto não é o VirtualBox ou VMware que você talvez conheça. É um interpretador de instruções proprietário. O código do jogo naquelas funções protegidas é "traduzido" para um formato que só o Denuvo consegue executar e partes críticas das instruções são removidas do executável e armazenadas em um arquivo de licença gerado especificamente para o seu hardware.

Isso cria algumas características que tornam a pirataria extremamente difícil:

O código aparece como sequências sem sentido para qualquer ferramenta de análise convencional, ferramentas como IDA Pro ou Ghidra, usadas por pesquisadores de segurança e pessoas que tentam entender executáveis, veem sequências sem sentido ao invés de código legível.

As verificações não ficam em um único lugar. São centenas de pontos espalhados por todo o executável do jogo, cada um deles se verifica com os outros e se você modificar um, os outros detectam a inconsistência e o jogo para de funcionar ou trava de forma propositalmente não óbvia.

O sistema é vinculado ao hardware. O arquivo de licença é gerado com base nas características específicas da sua máquina, não dá para copiar a licença de outra pessoa porque ela não vai funcionar no seu hardware.

O próprio código de verificação é encriptado e descriptografado em tempo real durante a execução. Existe até uma situação documentada onde há spin-locks (mecanismos de sincronização) protegendo a descriptografia e esses spin-locks são encriptados por outros spin-locks, que por sua vez podem ter mais camadas de proteção. É ofuscação sobre ofuscação 😂.

O método tradicional de pirataria era encontrar o ponto de verificação no código, entender o que ele fazia e modificá-lo para sempre retornar "verificação aprovada".

Com o Denuvo moderno, isso virou praticamente impossível. Não tem "um lugar" para modificar e mesmo que você encontrasse, a auto verificação do sistema detectaria a mudança.

A linha do tempo: de "inquebrantável" ao burlar o Denuvo em um dia

Entender o histórico ajuda a dimensionar o que aconteceu em 2025 e 2026.

Entre 2014 e 2018, o Denuvo dominava. Jogos com Denuvo demoravam meses ou nunca chegavam a ser pirateados. A empresa vendia isso como ponto principal: você não precisa proteger o jogo para sempre, só precisa proteger a janela de vendas inicial, quando a maior parte do faturamento acontece.

Em 2018 e 2019, surgiu o grupo que ficou mais conhecido nesse cenário: a hacker solitária conhecida como EMPRESS. Ela conseguiu o que parecia impossível: burlar versões recentes e avançadas do Denuvo, incluindo jogos que a indústria considerava protegidos indefinidamente. Os métodos dela eram sofisticados e envolviam análise profunda do comportamento do Denuvo em runtime.

Depois de 2019, o Denuvo continuou evoluindo e a EMPRESS parou de operar publicamente em 2024, outros grupos tentaram, mas as versões mais recentes do Denuvo combinadas com VMProtect (outra camada de ofuscação de código) tornaram o processo de engenharia reversa lento demais para ser viável.

Por um tempo, parecia que o Denuvo tinha finalmente criado uma barreira que a cena de pirataria não conseguia mais superar de forma consistente.

Aí chegou dezembro de 2025.

O primeiro método de burlar o Denuvo via hypervisor apareceu como teste em Persona 5 Royal. Em fevereiro de 2026, Stellar Blade, Assassin's Creed Shadows e Avatar: Frontiers of Pandora foram pirateados pelo mesmo método. Em março de 2026, Resident Evil Requiem foi pirateado em menos de 24 horas após o lançamento, apesar das cinco camadas de proteção simultâneas.

A natureza do problema mudou completamente.

O que é o pirataria via hypervisor, explicado do zero

Antes de falar sobre o método em si, preciso explicar o que é um hypervisor. Porque esse é o centro de tudo, tanto do método de burlar quanto do problema de segurança que ele cria.

Um hypervisor é um software que gerencia recursos de hardware, como processador, memória e armazenamento e os distribui entre sistemas operacionais. É o que permite você rodar o Windows dentro do Mac ou criar uma máquina virtual com Linux dentro do Windows. O hypervisor fica "abaixo" do sistema operacional e controla o que cada sistema pode ou não fazer com o hardware real.

Existem dois tipos principais. O Tipo 2 é o que a maioria das pessoas conhece: VirtualBox, VMware e etc, eles rodam como programas dentro do seu sistema operacional e você abre o VirtualBox como abriria o Chrome.

O Tipo 1, chamado de bare-metal é diferente, ele não roda dentro do sistema operacional, ele roda diretamente no hardware e o sistema operacional é que roda dentro dele. É o tipo usado em servidores de datacenter, onde uma máquina física precisa hospedar dezenas de servidores virtuais com total isolamento entre eles.

A distinção importa porque hypervisors bare-metal têm um nível de controle sobre o sistema que é absoluto.

Eles enxergam tudo que o processador faz. Podem interceptar qualquer instrução. Podem modificar o que o sistema operacional vê quando consulta o hardware.

É uma posição de privilégio que fica acima de tudo, incluindo acima do próprio sistema operacional.

Por que o Denuvo não pode ser enganado de dentro do Windows

Para entender por que a pirataria via hypervisor existe, preciso explicar por que os métodos anteriores pararam de funcionar.

Os métodos tradicionais de pirataria funcionavam de dentro do Windows. Ferramentas rodando como programas normais ou no máximo como drivers de kernel, tentavam interceptar as verificações do Denuvo, modificar resultados na memória, simular respostas de hardware específico.

O problema é que o Denuvo evoluiu para detectar exatamente isso. Ele verifica se está sendo analisado, verifica se existe algum software tentando interceptar suas chamadas de sistema, verifica a integridade do próprio ambiente onde está rodando e qualquer tentativa de interferência de dentro do sistema operacional é detectável, porque o Denuvo roda no mesmo nível que os softwares que tentam enganá-lo. É uma briga entre iguais e o Denuvo ganhou essa briga.

A virada conceitual do método hypervisor foi sair dessa briga. Em vez de tentar enganar o Denuvo de dentro do Windows, o método desce um nível e ataca de baixo. De uma posição que o Denuvo não pode inspecionar, porque o Denuvo roda dentro do Windows e o hypervisor fica abaixo do Windows.

A analogia que explica tudo

Tem uma analogia que captura bem a diferença entre os métodos.

Imagine uma câmera de segurança monitorando uma sala, o seu objetivo é entrar na sala sem ser registrado.

O método tradicional tentava cortar os fios da câmera, modificar o software de gravação, colocar um adesivo na lente, ou seja, métodos diretos, que atuam sobre a câmera em si. O problema é que a câmera ficou mais sofisticada: ela detecta quando os fios são cortados, verifica a integridade do próprio software e qualquer adulteração física aciona um alarme.

O método via hypervisor não tenta mais mexer na câmera. Em vez disso, ele instala um sistema que projeta uma imagem falsa diretamente no sensor da câmera, antes que qualquer sinal chegue ao software de gravação, a câmera continua funcionando normalmente, continua gravando, continua verificando sua própria integridade e não detecta nada de errado. Porque do ponto de vista dela, não tem nada de errado, o que ela enxerga é uma sala vazia e tranquila e só que essa imagem foi fabricada.

O Denuvo continua rodando no jogo. Ele continua fazendo todas as suas verificações de hardware, integridade e licença, só que as respostas que ele recebe são fabricadas pelo hypervisor, que fica numa posição que o Denuvo não tem como inspecionar e para o Denuvo, tudo parece normal.

O que esse método faz tecnicamente

O método funciona assim em termos práticos:

Um driver de kernel customizado é instalado no sistema. Esse driver se configura como um hypervisor bare-metal, usando as capacidades de virtualização do processador, as extensões AMD-V no caso de processadores AMD, e Intel VT-x no caso de processadores Intel. Essas são funcionalidades do próprio hardware, projetadas para suportar virtualização eficiente.

Com esse driver ativo, o Windows passa a rodar dentro de um ambiente virtual controlado pelo driver. O sistema operacional não percebe isso. Do ponto de vista do Windows, nada mudou. Mas agora existe uma camada entre o Windows e o hardware que pode interceptar, modificar e fabricar qualquer resposta de hardware.

Quando o Denuvo executa suas verificações de hardware para confirmar que o jogo está rodando na máquina licenciada, essas consultas são interceptadas pelo hypervisor antes de chegarem ao hardware real. O hypervisor devolve as respostas que o Denuvo espera receber, independente do que o hardware real retornaria. O Denuvo fica satisfeito, aprova a execução do jogo, e o jogo roda.

O jogo nunca foi modificado, o Denuvo nunca foi removido e nenhuma linha de código do executável foi tocada.

O ambiente foi fabricado ao redor do Denuvo para que ele chegasse sozinho à conclusão de que tudo está em ordem.

É tecnicamente elegante e é exatamente isso que o torna perigoso do ponto de vista de segurança.

O Windows também tem um hypervisor e aí começa o problema

Até aqui expliquei o que é o novo método e como ele funciona, agora preciso explicar por que ele cria um problema de segurança sério e isso começa com algo que a maioria dos usuários de Windows não sabe que existe no próprio sistema.

O Windows moderno também usa um hypervisor bare-metal. Ele se chama Windows Hypervisor Platform e é a base de um conjunto de recursos de segurança chamado VBS (Virtualization-Based Security). Antes que alguém confunda: VBS aqui não tem nada a ver com VBScript, a linguagem de scripting antiga da Microsoft, VBS nesse contexto significa literalmente "segurança baseada em virtualização".

A ideia por trás do VBS é simples em conceito, porém sofisticada em execução. Se um hypervisor tem controle absoluto sobre o que o sistema operacional enxerga e faz, então um hypervisor confiável pode criar zonas isoladas dentro do próprio Windows, zonas que nem mesmo um Windows completamente comprometido consegue acessar. Mesmo que um malware tome controle total do sistema operacional, ele não consegue sair dessa caixa para acessar o que está protegido dentro do hypervisor.

É uma mudança de paradigma na segurança de sistemas operacionais de consumidor. Em vez de confiar que o Windows nunca vai ser comprometido, o modelo assume que o Windows pode ser comprometido e cria proteções que sobrevivem a esse cenário.

O que o VBS protege na prática

O VBS é o guarda-chuva. Dentro dele existem vários recursos específicos que dependem dele para funcionar. Vou explicar cada um porque entender o que você perde é essencial para dimensionar o risco.

Memory Integrity, também chamado de HVCI (Hypervisor-Protected Code Integrity)

Esse é provavelmente o mais importante para o contexto desse post. O HVCI monitora o kernel do Windows em tempo real. O kernel é o núcleo do sistema operacional, a parte que tem acesso direto ao hardware e que todos os outros programas dependem para funcionar.

O HVCI garante que apenas código verificado e aprovado pode ser carregado e executado no kernel e qualquer tentativa de injetar código não verificado no kernel, seja por malware, seja por um driver não autorizado, é detectada e bloqueada antes de acontecer.

Para quem trabalha com segurança, o HVCI é uma das proteções mais significativas que a Microsoft adicionou ao Windows nos últimos anos, ele elimina classes inteiras de ataques que antes eram difíceis de defender, especialmente rootkits e malware que tenta se esconder dentro do próprio sistema operacional.

Credential Guard

Senhas são um alvo constante de malware. Mas não necessariamente sua senha digitada em si. Quando você faz login em serviços, o Windows armazena tokens de autenticação, hashes de credenciais e outros dados que provam sua identidade para sistemas que você já autenticou.

Ataques como Pass-the-Hash e Pass-the-Ticket, bem documentados e amplamente usados em ataques reais, funcionam roubando esses tokens sem precisar da sua senha original. Com o token, o atacante se autentica como você em outros sistemas sem precisar digitar nada.

O Credential Guard move esses dados para dentro do ambiente protegido pelo hypervisor e mesmo que o Windows seja completamente comprometido, o malware não consegue acessar esses tokens porque eles estão numa zona que só o hypervisor pode tocar.

Windows Hello

O login com PIN, reconhecimento facial ou leitura de impressão digital que você usa no dia a dia depende do Credential Guard para armazenar seus dados biométricos e de autenticação com segurança. Com o VBS desabilitado, o Windows Hello passa a funcionar em modo degradado ou para de funcionar completamente, dependendo da configuração.

System Guard / Secure Launch

Esse é o mais avançado e o menos conhecido. O System Guard protege o processo de boot do sistema contra rootkits sofisticados que tentam se instalar antes do sistema operacional carregar, num nível tão baixo que ficam invisíveis para qualquer proteção que rode depois.

Apoiado pelo TPM 2.0, ele também permite verificação contínua da integridade do sistema após o boot, incluindo a verificação dos outros componentes de segurança listados acima. É proteção da proteção.

Por que os dois hypervisors não podem coexistir

Aqui está o nó central do problema técnico.

O método via hypervisor precisa ser o hypervisor que controla o hardware. É só de lá que ele consegue interceptar as instruções do processador que o Denuvo usa para suas verificações. Sem estar nessa posição, o método não funciona.

Mas o Windows já tem o seu próprio hypervisor nessa posição, sustentando todos os recursos de segurança que listei acima.

A solução óbvia seria colocar o hypervisor do método "em cima" do hypervisor do Windows, criando camadas. Tecnicamente isso existe e se chama nested virtualization, virtualização aninhada. Em ambientes de datacenter controlados isso é usado para certas situações específicas.

O problema é que a Microsoft deliberadamente não permite isso para hypervisors de terceiros no contexto do Windows de consumidor. O Windows Hypervisor simplesmente não repassa as capacidades de virtualização do hardware para ninguém mais. Do ponto de vista do processador, o hardware já está ocupado.

Outros softwares de virtualização sofreram com isso antes mesmo do Denuvo ser uma discussão. O VMware foi forçado a usar o hypervisor do Windows em vez do próprio. O VirtualBox, que tentou operar sem virtualização de hardware, ficou extremamente lento como resultado e até para software legítimo de virtualização, o conflito entre o hypervisor do Windows e outros hypervisors é um problema conhecido e sem solução elegante.

Para o método do Denuvo, isso significa uma escolha binária: ou o hypervisor do Windows fica ativo com todos os recursos de segurança funcionando ou ele é removido do caminho para o método funcionar.

Não tem meio termo.

O que precisa ser desabilitado e o que isso significa

Para que o método via hypervisor funcione, o usuário precisa passar por uma sequência de desativações. Vou listar cada uma e explicar o que ela representa em termos de segurança real.

Secure Boot

O Secure Boot é uma funcionalidade da UEFI, o firmware moderno que substituiu o BIOS. Ele garante que cada componente carregado durante o processo de boot do computador, desde o próprio firmware até o bootloader do Windows, tem uma assinatura criptográfica válida de uma fonte confiável.

Sem o Secure Boot, qualquer código pode ser executado durante o boot sem verificação. Isso é a porta de entrada para bootkits, malware que se instala num nível tão baixo que fica ativo antes do Windows carregar, tornando-se praticamente indetectável e extremamente difícil de remover, mesmo com uma reinstalação do sistema operacional. Uma formatação normal não remove um bootkit porque ele vive fora da partição do Windows.

HVCI (Memory Integrity)

Como expliquei acima, o HVCI é o guardião do kernel do Windows. Com ele desabilitado, a porta do kernel fica aberta. Drivers não verificados, código não assinado, modificações de memória em nível de kernel: tudo passa sem verificação.

Driver Signature Enforcement (DSE)

O Windows normalmente só aceita drivers com assinatura criptográfica aprovada pela Microsoft. Conseguir essa aprovação exige que uma empresa real passe por verificações de identidade extensas, assine contratos e submeta drivers para análise. É um processo deliberadamente difícil porque drivers rodam em Ring 0.

Com o DSE desabilitado, qualquer driver, de qualquer origem, sem nenhuma verificação de identidade ou intenção, pode ser carregado no kernel. É o equivalente a remover a verificação de identidade na entrada de um prédio de segurança máxima.

O que é Ring 0 e por que importa

Processadores modernos operam em níveis de privilégio chamados rings (anéis). Ring 3 é onde seus programas normais rodam, o Chrome, o Word e os jogos. Eles têm acesso limitado ao hardware e precisam pedir permissão ao sistema operacional para fazer qualquer coisa sensível.

Ring 0 é onde o kernel do sistema operacional roda. Código em Ring 0 tem acesso irrestrito a toda memória do sistema, a todos os dispositivos de hardware e pode fazer literalmente qualquer coisa. Não existe nível de privilégio acima de Ring 0 no contexto do sistema operacional. O hypervisor tecnicamente opera num nível ainda mais privilegiado chamado Ring -1, mas para fins práticos, Ring 0 é o teto de privilégio que qualquer software de usuário jamais deveria alcançar.

Drivers rodam em Ring 0. Com o DSE desabilitado e o HVCI desligado, qualquer driver que alguém queira te convencer a instalar tem acesso completo e irrestrito a tudo no seu computador. E como opera abaixo do sistema operacional, é invisível para antivírus e qualquer outra ferramenta de segurança que rode em Ring 3.

O risco real: sem exagero e sem minimização

Tudo que expliquei até aqui é técnico e abstrato. Agora vou tornar concreto.

Quando você desabilita Secure Boot, HVCI e DSE para rodar o método de pirataria via hypervisor, você não está "ajustando uma configuração". Você está removendo as camadas de defesa mais profundas do seu sistema operacional antes de executar um arquivo de origem desconhecida com privilégios absolutos sobre o seu hardware.

Existem dois riscos distintos aqui e é importante não misturá-los.

Risco 1: o método de pirataria em si

Vamos assumir o melhor cenário possível: O grupo que desenvolveu o método de pirataria é sério, o código é aberto, você conseguiu verificar a origem. Mesmo nesse cenário, um driver rodando em Ring 0 com as proteções do kernel desabilitadas representa uma superfície de ataque enorme. Um único bug de segurança nesse driver, sem má intenção de ninguém, oferece a qualquer outro software malicioso que esteja no sistema um caminho direto para privilégio máximo e com HVCI desligado, nada vai detectar isso acontecendo.

Risco 2: a cadeia de distribuição

Esse é o risco que afeta a grande maioria das pessoas, porque quase ninguém baixa diretamente da fonte original.

O caminho real é: grupo original publica o método de pirataria, repackers pegam e reembalam, sites de terceiros hospedam, agregadores linkam e o arquivo que chega até você passou por quatro ou cinco mãos que você não conhece e não tem como verificar.

Em cada etapa dessa cadeia existe oportunidade para inserção de código malicioso. E o detalhe que torna isso especialmente grave com o método hypervisor é que você já desabilitou todas as proteções antes de executar qualquer coisa. O antivírus não consegue inspecionar drivers de kernel quando o DSE está desabilitado. O HVCI que detectaria modificações maliciosas do kernel está desligado. Você literalmente abriu todas as portas antes de deixar o visitante entrar.

Pesquisas de segurança de 2025 e 2026 documentaram campanhas ativas espalhando mineradores de criptomoeda, stealers de credenciais e loaders através de jogos piratas e arquivos de pirataria (chamados de cracks). Alguns se disfarçavam de torrents de jogos populares, outros como arquivos de cracks aparentemente normais e funcionais. O jogo rodava perfeitamente. O malware também.

Para os pais que chegaram até aqui

Se você não entendeu metade do que foi explicado acima mas tem um filho que baixa jogos no computador, essa seção é para você.

Um computador que rodou o método via hypervisor com as proteções desabilitadas potencialmente expôs: todas as senhas salvas em qualquer navegador instalado, cookies de sessão que permitem acesso a contas sem precisar de senha, credenciais bancárias digitadas naquele computador, e dependendo da configuração da rede doméstica, outros dispositivos conectados ao mesmo Wi-Fi.

Tudo isso é exportado silenciosamente em segundos, sem janela visível, sem lentidão perceptível e sem nenhum sinal de que algo aconteceu, o jogo abre normalmente.

Se o computador que seu filho usa para jogos é o mesmo onde você acessa internet banking, verifica e-mail corporativo ou armazena documentos importantes, o risco não está isolado naquele usuário.

Conclusão: não é pregação, é matemática

Não existe posição moral nesse post.

O problema é que a maioria das pessoas que baixa esses arquivos não sabe o que é HVCI, não entende o que significa desabilitar o Driver Signature Enforcement e não faz ideia de que Secure Boot desabilitado não é "só uma configuração chata que o arquivo precisa".

Essas pessoas estão tomando uma decisão de segurança séria sem informação suficiente para tomar essa decisão.