Análise de engenharia reversa do anti-cheat de Call of Duty

• O TAC (Treyarch Anti-Cheat) de Black Ops Cold War é um anti-cheat em modo de usuário, sem o driver de kernel Ricochet, mas tem uma estrutura de código bastante semelhante à dos títulos mais recentes de Call of Duty
• As camadas de proteção combinam criptografia de executável, checksums, ofuscação de jmp e ofuscação de entrypoint da Arxan com criptografia de ponteiros das famílias Treyarch/IW
• O TAC realiza várias detecções em modo de usuário, como resolução de APIs por hash em runtime, verificação de padrões de hooks de API, checagem de registradores de debug, detecção de assinatura de teste do Windows, detecção de alocação de console e detecção de DirectX/overlays
• Overlays externos coletam estilo da janela, posição, afinidade de exibição e lista de módulos do processo e enviam isso ao servidor; scanners de memória no estilo Cheat Engine podem ser detectados por meio de honeypots de memória virtual
• A técnica mais peculiar são stubs de syscall customizados e criptografados, que desviam de hooks no ntdll e fazem a origem da syscall parecer outra função do ntdll, dificultando o monitoramento

---

Alvo e escopo da análise

• O alvo da análise é o anti-cheat em modo de usuário dentro de Black Ops Cold War, referido como TAC (Treyarch Anti-Cheat)
• Black Ops Cold War não tem o componente em modo kernel do Ricochet presente em Modern Warfare 2019 e títulos posteriores
• A principal diferença em relação aos Call of Duty mais recentes é o driver em modo kernel; a maior parte do código anti-cheat fica em modo de usuário e é muito semelhante ao TAC
• O pseudocódigo das funções foi reconstruído, pois os resultados reais de decompilação são complexos devido à ofuscação e ao código de resolução
• Algumas partes foram removidas para evitar promoção de trapaças ou bypasses

Arxan e proteção do executável

• Arxan é uma ferramenta de ofuscação e proteção usada em muitos jogos Call of Duty desde Black Ops 3
• Descriptografia do executável em runtime
  • O executável do jogo é empacotado e criptografado
  • A Arxan insere código no processo de inicialização para desempacotar e descriptografar o executável real do jogo
• Checksums do executável
  • A Arxan monitora continuamente patches no executável do jogo
  • Se um depurador ou uma divergência de checksum for detectado, o processo é encerrado
• Ofuscação de jmp
  • Insere vários jmp entre as instruções de uma função, dificultando a análise estática
  • Quando centenas de saltos são inseridos em funções grandes, a análise do IDA quebra e ferramentas externas passam a ser necessárias
• Ofuscação do entrypoint
  • O código protegido pela Arxan desempacota e executa o entrypoint real
  • Essa região também pode conter ofuscação por jmp, dificultando o rastreamento do fluxo

Criptografia de ponteiros

• Ponteiros importantes são criptografados e descriptografados imediatamente antes do uso
  • Objeto global atual do jogo
  • Array de entidades
  • Ponteiros de objetos etc.
• O mesmo esquema de criptografia tem 16 variações, e o endereço atual do PEB determina qual será usado
• Esse método atrapalha o pointer scan do Cheat Engine
  • Apenas valores criptografados são armazenados nos globais
  • Os valores descriptografados existem apenas na stack
• Para obter ponteiros descriptografados, é necessário usar uma ferramenta que rastreie as instruções de descriptografia ou instalar um hook no ponto em que o jogo já os descriptografou

Resolução de APIs em runtime e detecção de hooks

• O TAC usa uma função inline de resolução de APIs em runtime
  • Recebe o hash do módulo e o hash do nome da API
  • Percorre a lista de módulos carregados e calcula o hash dos nomes
  • Percorre as funções exportadas do módulo e as compara com o hash calculado em tempo de compilação
• A identificação dos hashes é feita usando a lista de módulos carregados do processo do jogo e a função de hashing do jogo
  • Calcula o hash do nome do módulo e dos nomes exportados
  • Extrai manualmente o base hash e o function hash do resultado de decompilação para correlacionar qual API é chamada
• Os hashes não são iguais entre versões do jogo
• Como os ponteiros de função são armazenados em variáveis globais, também é possível identificá-los comparando o endereço virtual com as funções exportadas das DLLs carregadas
• A detecção de hooks de API do TAC verifica atualmente apenas 7 padrões
  • Stubs das famílias push/movabs/xchg/ret
  • push imm seguido de ret
  • call
  • jmp [rip+x]
• Ele não verifica todas as APIs importantes, mas sim hooks nas APIs que ele próprio usa

Registradores de debug e detecção de assinatura de teste de drivers

• Registradores de debug podem ser usados como uma forma de hook sem patch de código para contornar o monitoramento de patches em .text da Arxan
• O TAC verifica os valores de DR0~DR3 no contexto da thread
  • Se houver um valor, ele chama um callback com mensagens diferentes dependendo de estar dentro do processo atual ou não
  • Depois disso, o fluxo passa para uma função de encerramento
• DR0~DR3 são privileged registers, então não podem ser lidos diretamente por assembly comum; é preciso obtê-los pelo kernel do Windows ou por entrega de exceções
• O modo de teste do Windows permite executar drivers em modo kernel sem uma assinatura normal
• O TAC verifica se a assinatura de teste está ativada usando NtQuerySystemInformation
  • Essa detecção por si só não gera ban direto, mas a conta é marcada

Método de encerramento do processo

• O TAC encerra o processo de duas maneiras
• O primeiro método limpa os registradores e depois chama NtTerminateProcess
  • Define RCX como -1
  • Se NtTerminateProcess for detectado como hookado, esse método não é usado
• O segundo método limpa os registradores e depois salta para 0x0, fazendo o processo crashar
• Em ambos os métodos, registradores importantes são limpos, dificultando a recuperação

Detecção de console, visualização e overlays

• Cheats internos podem usar AllocConsole para saída de logs ou implementação de menus
• O TAC detecta alocação de console verificando a janela de console ou o ConsoleHandle no PEB
• Visualizações internas geralmente são desenhadas na tela por hooks de APIs gráficas
  • Call of Duty recentes usam DirectX 12
  • Um alvo comum de hook é IDXGISwapChain::Present
  • No DirectX 12, uma command queue é necessária, e ID3D12CommandQueue::ExecuteCommandLists é um ponto comum para obtê-la
• OBS Studio, Streamlabs OBS, overlay de jogo do Discord e overlay de jogo da Steam também podem operar em locais semelhantes
  • Steam e Discord fazem renderização
  • A família OBS captura a imagem renderizada ao usar captura de jogo
• Atualmente, o TAC não escaneia a própria função DXGI present, mas verifica o ponteiro de present na vtable

Cheats externos e detecção baseada em janelas

• Cheats externos tendem a criar uma overlapped window que cobre a janela do jogo
• O TAC percorre todas as janelas e verifica o estilo WS_EX_LAYERED com GetWindowLongA
• Em seguida, compara com GetWindowRect se ela se sobrepõe à janela do jogo
  • Se a taxa de sobreposição for 0.5 ou maior e houver menos de 8 itens em cache, o respectivo hwnd é armazenado
  • Aparece um valor correspondente a 1920x1080 como exemplo de tamanho de tela
• As janelas em cache são investigadas adicionalmente por outra função
  • Verifica o texto da janela com GetWindowTextW
  • Verifica o nome da classe com GetClassNameA
  • Verifica a afinidade de exibição com GetWindowDisplayAffinity
• O TAC também verifica casos em que SetWindowDisplayAffinity e WDA_EXCLUDEFROMCAPTURE são usados para esconder a janela de ferramentas de gravação ou screenshot
• Informações relacionadas à janela são armazenadas em um buffer criptografado e enviadas ao servidor
  • Texto da janela
  • Nome da classe
  • Posição e estilo da janela
  • Display affinity
  • Lista de módulos e nome do exe do processo da janela sobreposta
• O processo da janela sobreposta é aberto com OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION), e os nomes dos módulos são coletados com K32EnumProcessModules e K32GetModuleFileNameExW

Detecção de scanners de memória do tipo Cheat Engine

• O Cheat Engine é fácil de detectar devido ao comportamento da memória virtual do Windows
• Mesmo que um programa aloque memória virtual com VirtualAlloc, ela não recebe backing em memória física antes de ser acessada
• O jogo pode alocar memória e depois não usá-la
• Quando o Cheat Engine ou a aba de memória do Process Hacker escaneia essa região, ocorre um acesso e a memória passa a um estado válido
• O honeypot no estilo do TAC detecta scanners de memória verificando com K32QueryWorkingSetEx se aquele endereço virtual foi de fato acessado

Obstrução de signature scanning

• Hackers de jogos usam signature scanning com frequência para que cheats continuem funcionando automaticamente após atualizações
• A ideia da Treyarch é proteger com PAGE_NOACCESS a região ao redor do return address em uma função que não será chamada novamente
• Um signature scanner lê os bytes do executável do começo ao fim procurando padrões
• Consultar se cada byte é acessível seria muito lento, então o processo pode crashar ao alcançar uma área PAGE_NOACCESS
• Esse método não é uma barreira completa, mas pode dificultar a vida de muitos analistas

Antidepuração

• As verificações antidebug do próprio TAC são simples, mas a Arxan também fornece técnicas antidebug separadas
• O TAC percorre todas as threads do processo atual
  • Usa CreateToolhelp32Snapshot e um thread snapshot
  • Verifica DbgSsReserved no TEB de cada thread para detectar a existência de um DebugObject
• Também há uma técnica que provoca access violation escrevendo em memória inválida
  • Se o código chegar ao ponto posterior à exceção, ele considera que o depurador tratou a exceção ou houve bypass
• CheckRemoteDebuggerPresent também é usado
• ThreadHideFromDebugger faz as exceções serem enviadas ao processo, não ao depurador
  • Quando o depurador tenta pausar o processo, uma exceção STATUS_BREAKPOINT pode ocorrer e encerrar o processo
  • Em modo de usuário, não é possível unsetar essa flag
  • Essa tática é executada em um TLS callback antes do entrypoint do executável

Monitoramento de tráfego de rede

• O TAC não armazena todas as conexões ativas; ele procura apenas condições específicas
• O alvo de detecção é um método que cria um servidor de rede local dentro do processo do jogo
  • O cheater escreve shellcode no processo do jogo
  • Inicia um servidor de rede dentro do processo do jogo
  • Um aplicativo externo troca informações com esse servidor local
• O TAC obtém a tabela TCP com GetTcpTable2 e detecta a condição comparando as conexões criadas pelo processo atual com a relação de portas de outros processos

Stubs de syscall customizados e criptografados

• Muitas APIs exportadas pelo ntdll executam uma syscall internamente
• Ao usar um stub de syscall customizado, é possível contornar hooks em funções do ntdll feitos por cheats em modo de usuário
• A syscall pode ficar exposta a instrumentation callback
  • O instrumentation callback é chamado após a syscall
  • O endereço de retorno passa a ser logo após a instrução de syscall
• O TAC dificulta a análise estática com stubs de syscall criptografados
• O stub é construído depois que uma grande região alocada na seção .text é protegida como write/execute
• Ele encontra a instrução de syscall em NtReadFile e usa o valor de tempo da CPU como elemento aleatório para mudar a posição
• Para quem monitora, a syscall pode parecer ter ocorrido em uma função aleatória do ntdll
  • A syscall real pode não ser NtReadFile
  • Se não for possível verificar o syscall index em eax, é difícil saber qual syscall é
• Há exemplos em que a posição da instrução de syscall muda a cada execução

Detecção de bypass do ocultamento de antidebugger

• Para configurar ThreadHideFromDebugger, NtSetInformationThread precisa ser chamado
• Um cheater pode hookar essa API para que ela retorne sucesso
  • Assim, o anti-cheat acredita que a configuração de ocultamento foi bem-sucedida, mas nada pode ter acontecido de fato
• O TAC verifica o resultado da chamada usando argumentos inválidos para capturar hooks mal implementados
  • Se uma chamada que deveria falhar devido a um argumento de tamanho incorreto retornar sucesso, há detecção
  • Há exemplos de valores de retorno diferentes em ambientes com depurador e ScyllaHide
  • Também verifica hooks que sempre retornam sucesso para solicitações ThreadHideFromDebugger usando um handle falso

Bloqueio de criação de threads remotas

• O TAC instala um handler de exceção que chama TerminateThread na thread atual em uma exceção STATUS_PRIVILEGED_INSTRUCTION
• Uma DLL manualmente mapeada precisa de uma forma de executar shellcode no processo remoto, e um método comum é CreateRemoteThread
• TLS callbacks de um Windows PE podem ser chamados quando uma thread é criada, antes do entrypoint da thread
• O TAC verifica o endereço inicial no contexto da nova thread
  • Obtém o Win32 start address com NtQueryInformationThread
  • Percorre a lista de módulos carregados e verifica se o endereço inicial está dentro do intervalo de um módulo normal
• Se o endereço inicial não estiver dentro do intervalo de nenhum módulo carregado, ele armazena a detecção e gera uma exceção de privileged instruction para encerrar a thread

Outras verificações e conclusão

• Há um código de verificação desconhecido que checa se AllocationGranularity de NtQuerySystemInformation é 0x10000
  • Parece marcar máquinas virtuais ou versões customizadas do Windows
• Como o TAC depende bastante da lista de módulos vinculados, ele verifica se InMemoryOrderModuleList no PEB é uma lista vazia
  • Se ela for esvaziada, é provável que o próprio processo quebre
• Em última análise, o TAC é um anti-cheat em modo de usuário com os seguintes recursos
  • Resolução de APIs em runtime
  • Detecção de hooks mal implementados
  • Detecção de overlays externos
  • Detecção de hooks internos de DirectX
  • Verificação de hooks nas APIs usadas
  • Verificação de depuradores e rastros de depuração
  • Detecção de AllocConsole
  • Detecção de CreateRemoteThread
  • Stubs de syscall spoofed e criptografados
• A Arxan auxilia o TAC com ofuscação forte, obstrução de análise estática, técnicas que quebram o IDA Pro, monitoramento de modificações em .text e recursos próprios de antidebug
• Código semelhante ao TAC também é usado em jogos modernos de Call of Duty

[GN⁺]

Opiniões no Hacker News

• Em 2021, uma conta de CS:GO no Linux teve problemas com o índice de confiança, caindo para amarelo e depois para vermelho; não era um banimento oficial, mas na prática funcionava como uma punição.
  Como resultado, a pessoa continuava sendo pareada com trapaceiros e tinha dificuldade para encontrar colegas de equipe.
  Mais tarde, descobriu que outros usuários de Linux com GPUs Radeon e 16 GB ou mais de VRAM estavam passando por problemas parecidos, e criou uma issue no GitHub para rastrear o problema: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630
  Ao investigar, parecia que a Valve estava punindo usuários de Linux com determinadas configurações de hardware, especialmente placas Radeon com 16 GB ou mais de VRAM, que na época eram bem recentes.
  No fim, depois que um usuário entrou em contato diretamente com gaben, o problema foi corrigido: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630#...
  Especula-se que isso talvez tenha sido resultado da Valve se preocupar com a experiência de usuários de Linux enquanto preparava o lançamento do Steam Deck.

  • Talvez Gabe Newell seja simplesmente uma boa pessoa?
  • Não entendo muito bem como punir usuários de Linux melhora a experiência de usuários de Linux.
    Ainda assim, é interessante.
  • Fico curioso para saber como dava para perceber que o índice de confiança tinha caído para amarelo ou vermelho.
    Foi uma dedução pela piora na qualidade das partidas, ou havia alguma forma de confirmar?
    Pelo que entendo, o índice de confiança fica oculto para evitar abuso.

• Trapaça, no fim das contas, é um problema de pessoas.
  As salvaguardas e heurísticas descritas no texto conseguem filtrar 90% dos trapaceiros descarados, e esse tipo de anti-cheat é, basicamente, uma boa direção.
  Ainda assim, o anti-cheat precisa agir de forma conservadora, e a solução final deve vir dos jogadores e administradores.
  Jogos multiplayer online precisam necessariamente rodar em servidores administrados por pessoas, e deve haver um administrador presente durante a maior parte do tempo em que os jogadores estiverem conectados.
  Se possível, é ainda melhor que seja um administrador reconhecido pelos jogadores; quando não houver administrador, também deve ser possível algum tipo de moderação atenuada, como votação para expulsar ou banir.
  Não há diferença essencial entre expulsar um trapaceiro e expulsar alguém que abusa do chat.
  No fim, a única forma viável de servidor em jogos multiplayer online parece ser servidores privados ou da comunidade.
  O processo de controlar trapaceiros e abusadores não deveria ser recebido por um sistema de denúncias e tratado de forma assíncrona; administradores do jogo precisam expulsar ou banir rapidamente.
  Se um jogo só permite jogar online por meio dos servidores de matchmaking da publisher e o tratamento de trapaceiros ou abusadores do chat se resume a denúncias por formulário web, então não compre nem jogue; vote com a carteira.

  • A exigência de que jogos multiplayer online necessariamente rodem em servidores administrados por pessoas é bastante absurda quando se pensa em escala.
  • Parece mais uma proposta de colocar um árbitro visível para todos em cada partida e fazer revisão de vídeo a cada infração.
    Dá até para criar uma organização separada só para fiscalizar os árbitros, mas aí é só jogar o jogo.
  • Não entendo por que a administração por pessoas seria vista como a única solução possível.
    Apex Legends funciona bem com um sistema forte de denúncias e anti-cheat, e em Rocket League a moderação majoritariamente automatizada também funciona de forma eficaz.
  • Concordo em linhas gerais, mas também há outros métodos.
    Número de telefone, verificação manual por foto, exigir 10 horas de jogo antes do competitivo, recomendações de outros jogadores, ou ainda um passe de jogo de pagamento único de 5 dólares sobre essas condições.
    Se ainda não viu, recomendo a apresentação da Valve sobre anti-cheat com IA.
    O trabalho é bem interessante, e eles afirmam pegar 99% dos trapaceiros.
    Claro, ainda existem métodos de trapaça muito sutis.

• Houve uma batalha judicial de 2 anos para reverter um banimento permanente falso da Activision, e a Activision perdeu por não apresentar nenhuma prova de trapaça: https://antiblizzard.win/2025/01/18/my-two-year-fight-agains...

  • Passei exatamente pela mesma coisa em League of Legends.
    Nunca trapaceei, fui banido sem explicação, e jogo regularmente em três contas, mas as outras duas não foram banidas.
    O suporte ao cliente só repetia “após análise, o banimento está correto” e não fornecia nenhuma informação que me permitisse corrigir o que eu supostamente tinha feito de errado.
    Tenho algumas das skins mais raras do jogo, jogo há milhares de horas desde 2009 e só jogo ARAM; não faz sentido eu arriscar uma conta de enorme valor sentimental trapaceando no modo mais casual.
    Nunca passei por algo mais estressante relacionado a jogos, e o banimento foi removido sem motivo graças a um conhecido da indústria que conseguiu verificar internamente.
    Ainda jogo, mas quase toda vez lembro daquele banimento falso, e acho que League será o último jogo multiplayer competitivo em que vou investir tempo.
    Também há uma parte de mim que não quer mais jogar por medo de aquilo acontecer de novo.
  • Eu também sofri um banimento permanente falso.
    Em console é quase impossível trapacear, levei tempo demais só para chegar a um medíocre Ouro 1 nas ranqueadas, e nunca recebi aviso nem denúncia por qualquer comportamento, mas fui banido permanentemente sem explicação.
    Em vez de brigar como o autor, decidi nunca mais gastar dinheiro com produtos da Activision, e acho que todos deveriam fazer o mesmo.
  • A parte em que, se você joga bem, alguém olha seu perfil para conferir o tempo de jogo e vê imediatamente um aviso vermelho dizendo “sou trapaceiro” me faz pensar se esse rótulo poderia ser considerado difamação.
    Nos EUA provavelmente seria mais difícil, mas pelo que entendo, no Reino Unido ou na Inglaterra o réu precisa provar que a afirmação é verdadeira.
  • É horrível que alguém tenha precisado travar uma batalha dessas.
    Ainda bem que quase não jogo shooters multiplayer, e eu realmente odiaria perder minha enorme biblioteca do Steam.
  • Esse texto, por si só, já mereceria uma submissão separada, e é muito interessante.

• Tenho muita curiosidade sobre a ofuscação por saltos
  Seria ótimo se alguém que já fez mais engenharia reversa pudesse responder
  Fico me perguntando se saltos incondicionais são comuns a ponto de ser difícil filtrá-los por algum pré-requisito específico; como o fim de uma função tem um retorno, parece fácil de encontrar, mas será que seria possível analisar a stack para saber para onde a função retorna e encontrar a chamada logo antes do endereço de retorno?
  Talvez eu esteja entendendo mal como funciona, já que não fiz muita programação em assembly x86

  • Existem técnicas legais que usam execução simbólica com emuladores como angr ou https://github.com/cea-sec/miasm para desfazer o achatamento do grafo de fluxo de controle
    Também dá para fazer análises interessantes com o framework PIN da Intel
    Textos que podem ajudar estão aqui: https://calwa.re/reversing/obfuscation/binary-deobfuscation-..., https://www.nccgroup.com/us/research-blog/a-look-at-some-rea...
  • Saltos incondicionais são muito comuns, e assembly x86 depois de otimização geralmente é bem bagunçado
    Muitas funções não terminam com ret
  • Este vídeo sobre engenharia reversa de partes de Guitar Hero 3 pode ser interessante, porque aborda técnicas parecidas usadas para ofuscar fortemente o código do jogo: https://www.youtube.com/watch?v=A9U5wK_boYM
  • Há alguns problemas comuns
    Alguns saltos são falsos, e alguns saltos entram no meio de instruções
    Decompiladores não conseguem lidar com uma situação em que há duas instruções no mesmo local
    Por exemplo, em jmp 0x1234, eles pulam o opcode de jmp e assumem que 0x1234 é uma instrução válida
    Em alguns ramos, a stack fica corrompida, mas isso pode ser intencional para provocar uma exceção
    Então dá para trocar uma instrução como lea RAX, [rsp + 0x99999999999] por um nop e consertar a decompilação, mas você também pode deixar passar uma exceção intencional
    O IDA não lida bem com esse tipo de coisa, por isso uso uma licença do Binary Ninja, e é fácil criar scripts para inlinear funções para o decompilador
    Pelo que vejo, no IDA, blocos de código entre saltos só podem pertencer a uma única função, então ele tem dificuldade para lidar corretamente com situações em que os saltos reutilizam blocos de código entre si
    Acho que as pessoas usam menos o Binary Ninja porque ele tinha um bug em jogos da Blizzard, mas isso foi corrigido por meio de um bug report cerca de um ano atrás
  • Esses saltos específicos parecem ser fáceis o bastante de filtrar
    É uma ofuscação feita para incomodar usuários de ferramentas prontas comuns, especialmente do IDA Pro
    A maioria das ofuscações tem como objetivo apenas tornar tudo incômodo o suficiente para que as pessoas passem para outro projeto

• Tirar funcionalidades de um produto depois da venda deveria ser impedido por lei, mesmo que esteja no contrato ou na EULA
  Um banimento não deveria retirar a propriedade do jogo em si; se retirar, deveria haver reembolso
  Se for preciso chegar a uma decisão judicial para forçar um reembolso, deveria haver indenização tripla além dos custos de licença, honorários advocatícios e custas judiciais
  Por exemplo, uma situação em que você é banido da Steam e todas as suas compras são anuladas deveria ser legalmente impossível
  Mesmo que o login da conta seja bloqueado, os itens e o inventário deveriam continuar negociáveis, porque foram obtidos por um cliente pagante que investiu tempo real neles
  Se um jogo multiplayer quiser aplicar um código de conduta, então não deveria poder cobrar pelo jogo, ou usuários pagantes deveriam ter direitos em relação a banimentos
  Banimentos deveriam seguir o princípio da proporcionalidade, com registro e um processo de apelação arbitral com participação humana, cujo custo seja limitado ao preço da licença e pago apenas em caso de derrota

  • Trapacear não faz você ser banido da Steam
    Na pior das hipóteses, sua conta ganha uma marca pública de vergonha em jogos VAC
    As pessoas jogam multiplayer para se divertir e interagir com outras pessoas, então, se trapaça ou qualquer outro mau comportamento afeta os outros, o uso do serviço multiplayer deve ser bloqueado
  • Não vejo como isso é diferente de exceder a velocidade ao dirigir
    Se você causa incômodo à sociedade, pagar o preço é um princípio bastante universal
  • Acho certo que cheaters sofram as consequências
    Acho aceitável que percam dinheiro de verdade
    Mas banimentos por engano são outro problema
    E o que é banido não é a conta Steam inteira, e sim o jogo específico que você não pode mais jogar, certo?
  • Talvez fosse melhor simplesmente rotulá-los como cheaters e fazê-los jogar apenas com outros cheaters
  • Se você trapaceia ou estraga o jogo de outros jogadores, merece perder o acesso
    Os outros jogadores também pagaram

• Em COD nem é preciso trapacear
  O jogo tem tantos bugs que faz isso por você
  Às vezes ele carrega uma arma em vez de uma faca no modo ranqueado; isso é possível porque claramente há um case ou if-else errado na verificação de equipamento das armas ranqueadas, e parece que, se a arma exibida no seletor de equipamento não for permitida, ele usa a XM4 como padrão
  É praticamente o único jogo que conheço em que a versão ranqueada é mais quebrada que a versão casual

• Fico curioso para saber onde se aprende esse tipo de coisa.
  Queria aprender mais, o bastante para entender pelo menos metade do texto, mas não sei por onde começar.

  • Há cerca de 15 anos, aprendi bastante lendo o livro Reversing: Secrets of Reverse Engineering, de Eldad Eilam.
    É um livro antigo, mas excelente, e faz você acompanhar várias técnicas e exercícios práticos.
    As ferramentas modernas mudaram um pouco desde aquela época, mas o conjunto de instruções x86 e assembly em geral não mudaram tanto.
    Um dos maiores ganhos foi conhecer os crackme.
    São pequenos binários de desafio feitos para aprender engenharia reversa, algo como os cadeados de treino da comunidade de lockpicking.
    Pelo que lembro, o livro vinha com vários em CD-ROM, e também há muitos para encontrar online.
    Fazer esses exercícios na prática é o caminho para aprender.
    Não dá para tentar fazer engenharia reversa de COD logo de início; é preciso ir construindo por etapas.
  • Antigamente, eu começava pelos tutoriais Lena151: https://github.com/kosmokato/Lena151
  • Em outros tempos eu diria para você ir ao Gamedeception e interagir por lá, mas parece que ele desapareceu alguns anos atrás.
    Saudações a quem frequentava UnknownCheats, cs.rin.ru e afins.
  • O UnknownCheats é um dos melhores lugares para esse tipo de material.
    Eu também participo lá, e tenho mais interesse especialmente em anti-cheat no espaço de usuário do Linux, em particular em como o VAC funciona.
  • https://pwn.college é um excelente material educacional.

• Fiz um pouco de engenharia reversa em um MMO popular baseado em Horde/Alliance, e ele seguia praticamente as mesmas etapas, incluindo hashes de exportação FNV32.
  Como vi truques muito parecidos, parece quase o mesmo método.
  Fico pensando se foi empacotado com a mesma tecnologia de proteção.

  • O motor Source 2 também usa fnv para fazer hash de schemas, isto é, de propriedades de entidades.
  • Se, depois da fusão, eles reutilizaram o Warden em propriedades intelectuais da Activision, faz sentido.

• Signature scanning é realmente poderoso.
  Também é a parte da engenharia reversa que mais me vicia.
  É divertido montar uma lista de signatures e escrever bindings para uma linguagem de script de modo que seja possível chamar esses ponteiros de função.
  Também é a base de muitas plataformas de mods de terceiros, porque elas precisam oferecer aos modders APIs úteis que o desenvolvedor original não expôs.

  • Não sei o que é signature scanning, mas encontrei um material para quem tiver curiosidade: https://www.unknowncheats.me/forum/general-programming-and-r...
  • Sim.
    Sei que alguns plugins do motor Source também usam esse método quando precisam.
    Mas a maioria parece usar offsets de ponteiros de tabelas de funções virtuais.

• Fico pensando se não seria possível ou se faria sentido assinar digitalmente o estado do jogo periodicamente, ou inserir algum tipo de prova de trabalho para impedir trapaças.
  Estou começando a achar que cheating é um problema difícil demais de impedir.
  Estou criando um FPS online pequeno e barato, e penso mais em deixar os usuários confiarem uns nos outros e identificarem cheaters por conta própria, ou em usar IA como a Valve, em vez de ter um software anti-cheat.
  Acho que vou deixar os próprios jogadores administrarem e operarem servidores.
  Poderia haver requisitos como vincular número de celular, pontuação de reputação dada por outros jogadores, documento de identidade ou outro meio forte de autenticação, verificação manual por foto como em apps de namoro, ou 10 horas de jogo antes de partidas competitivas.
  Acredito que jogadores hardcore aceitariam passar por esses procedimentos para reduzir cheaters.

  • Se você já jogou online em alguma medida, sabe que jogadores levantam suspeitas de cheating sem parar com pouquíssima evidência.
    Também há abuso social, como denunciar jogadores de quem não gostam para tentar bloqueá-los.
    Num sistema desses, haveria muito mais falsos positivos do que em qualquer anti-cheat.
  • Em alto nível, bastaria simular uma partida sem cheats, assiná-la e tratar os cheats separadamente.