Escrevo este artigo porque estou cansado de ver comunidades de DMA vendendo sonhos e ilusões. Sou desenvolvedor na área de game hacking desde 2016 e já vi diversas ondas de tecnologias surgirem e morrerem.
Com o tempo, a popularização do DMA cresceu demais e muitas pessoas passaram a acreditar que esse método era “100% seguro”. Como desenvolvedor de P2C, quero deixar claro: não é bem assim.
O DMA no Passado
No passado, o único vetor de detecção para DMA era o firmware. Se ele fosse bem feito, passava por qualquer anticheat.
A grande vantagem do DMA estava em escapar das análises manuais de memory dump — quando o anticheat varre todo o computador, registra tudo que foi feito e acessado, e analisa esses dados depois.
É justamente nesse ponto que a maioria dos cheats em nível de kernel cai. Mesmo que passem no anticheat em tempo real, um dump manual pode expor todo o funcionamento. Além disso, verificações de EPT/NPT também eliminam muitos projetos.
Durante anos, os anticheats permaneceram “confortáveis” com essa situação, já que poucos tinham um firmware realmente decente. Se apenas 1% da base de jogadores usasse, não era um problema. O problema surgia quando essa base crescia demais.
A Chegada do HPTT/Heino2
Foi nesse cenário que surgiu o HPTT/Heino2, representando um desafio real: um dispositivo impossível de detectar, porque é literalmente um hardware legítimo.
O mercado asiático passou a adotar em grande escala — onde a cena de cheating é muito mais ativa — e isso se espalhou rapidamente.
O que muda na prática
Antes: O IOMMU não era configurado de forma restritiva e, na prática, qualquer dispositivo podia ler regiões amplas de memória física sem controle granular.
Agora: Com o novo modelo de implementação, cada dispositivo recebe um range de memória específico que pode acessar — e nada além disso.
Implicações técnicas
- Um USB hub, placa de rede ou outro periférico não tem mais permissão para acessar áreas onde está a memória do jogo
- Qualquer tentativa de leitura fora do intervalo permitido é registrada pelo sistema
- Esses registros (métricas) permitem identificar rapidamente dispositivos que se comportam de forma anômala
Parte técnica — Como funciona
🔧 Implementação Técnica
Não se trata apenas de uma tradução ou realocação de CR3.
O IOMMU (Intel VT-d) intercepta as requisições de leitura/escrita de memória feitas por dispositivos DMA.
Processo de detecção
- Análise da DMAR table — Esse funcionamento pode ser comprovado analisando a DMAR table
- Contador de exceções — Quando um dispositivo DMA tenta acessar uma região fora do range permitido, um contador é incrementado
- Interpretação — Isso pode ser interpretado como uso de DMA para trapaça
CR3 Encryption
O CR3 encryption entra apenas como suporte a esse esquema, permitindo modificar temporariamente a page table do jogo para monitorar acessos via DMA.
Dependências e Limitações
Esse método de detecção depende de um conjunto de tecnologias combinadas:
Intel
- VT-x ativado
- VT-d ativado
AMD
- SVM ativado
- IOMMU ativado
Isso é o fim?
Não é correto dizer que isso representa o “fim” absoluto do DMA, mas sem dúvida é um grande problema.
Ainda existem formas de contornar:
- Bootkits EFI para emular o VT-d e inserir o dispositivo na whitelist
- Módulos SMM carregados para manipular o IOMMU
- Modificação de BIOS para ajustar o comportamento de mapeamento
- DMA no pré-boot para emular o próprio VT-d e configurar permissões antes do sistema iniciar
Conclusão
O novo modelo de uso do IOMMU representa um avanço significativo no bloqueio de métodos baseados em DMA.
Pontos principais:
- O método tradicional de leitura direta de memória via DMA está morrendo
- O hardware DMA em si continuará existindo
- O jogo mudou — e a adaptação será obrigatória para quem quiser continuar nessa área
💡 Reflexão Final
Como sempre acontece na área de segurança, é um jogo de gato e rato. Novas tecnologias de proteção surgem, e novos métodos de bypass são desenvolvidos. A diferença agora é que o nível de complexidade aumentou significativamente.