Análisis de ingeniería inversa del antitrampas de Call of Duty

 (ssno.cc)
1 puntos por GN⁺ 2025-01-21 | 1 comentarios | Compartir por WhatsApp
  • El TAC (Treyarch Anti-Cheat) de Black Ops Cold War es un antitrampas en modo usuario sin el driver de kernel de Ricochet, pero comparte en gran medida una estructura de código similar con los títulos recientes de Call of Duty
  • La capa de protección usa en conjunto cifrado del ejecutable, checksum, ofuscación con jmp y ofuscación del entry point de Arxan, junto con cifrado de punteros de la línea Treyarch/IW
  • TAC realiza varias detecciones en modo usuario como búsqueda de APIs por hash en tiempo de ejecución, inspección de patrones de hooks de API, verificación de registros de depuración, detección de firmas de prueba de Windows, detección de asignación de consola y detección de DirectX/overlays
  • Los overlays externos recopilan estilo, posición, afinidad de visualización y lista de módulos del proceso de las ventanas, y lo suben al servidor; los escáneres de memoria tipo Cheat Engine pueden detectarse mediante un honeypot de memoria virtual
  • La técnica más distintiva es un stub de syscall personalizado y cifrado, que evade los hooks de ntdll y hace que el origen del syscall parezca venir de otra función de ntdll, dificultando el monitoreo

Objeto y alcance del análisis

  • El objeto analizado es el antitrampas en modo usuario dentro de Black Ops Cold War, llamado TAC (Treyarch Anti-Cheat)
  • Black Ops Cold War no incluye el componente en modo kernel de Ricochet presente en Modern Warfare 2019 y títulos posteriores
  • La gran diferencia frente a los Call of Duty recientes es el driver en modo kernel; la mayor parte del código antitrampas está en modo usuario y es muy similar a TAC
  • El pseudocódigo de las funciones está reconstruido porque el resultado real de la decompilación se complica por la ofuscación y el código de resolución
  • Parte del contenido fue eliminado para evitar promover trampas o bypasses

Arxan y la protección del ejecutable

  • Arxan es una herramienta de ofuscación y protección usada en muchos juegos de Call of Duty desde Black Ops 3
  • Descifrado del ejecutable en tiempo de ejecución
    • El ejecutable del juego está empaquetado y cifrado
    • Arxan inserta código en el proceso de inicio para desempaquetar y descifrar el ejecutable real del juego
  • Checksum del ejecutable
    • Arxan vigila constantemente parches al ejecutable del juego
    • Si detecta un depurador o una discrepancia en el checksum, termina el proceso
  • Ofuscación con jmp
    • Inserta numerosos jmp entre las instrucciones de las funciones para dificultar el análisis estático
    • Si se insertan cientos de saltos en funciones grandes, el análisis de IDA se rompe y hacen falta herramientas externas
  • Ofuscación del entry point
    • El código protegido de Arxan desempaqueta y ejecuta el entry point real
    • Esa sección también puede incluir ofuscación con jmp, lo que dificulta seguir el flujo

Cifrado de punteros

  • Los punteros importantes se cifran y descifran justo antes de usarse
    • el objeto global actual del juego
    • el arreglo de entidades
    • punteros a objetos, etc.
  • El mismo esquema de cifrado tiene 16 variantes, y la dirección actual del PEB determina cuál se usa
  • Este método dificulta el pointer scan de Cheat Engine
    • en los valores globales solo se almacena el valor cifrado
    • el valor descifrado existe solo en la pila
  • Para obtener un puntero descifrado, hace falta usar una herramienta que rastree las instrucciones de descifrado o engancharse a un punto donde el juego ya lo haya descifrado

Resolución de API en tiempo de ejecución y detección de hooks

  • TAC usa una función integrada de resolución de API en tiempo de ejecución
    • recibe el hash del módulo y el hash del nombre de la API
    • recorre la lista de módulos cargados y calcula hash de sus nombres
    • recorre las funciones exportadas del módulo y las compara con hashes calculados en compilación
  • La identificación de hashes se hace usando la lista de módulos cargados del proceso del juego y la función de hash del juego
    • se calcula el hash del nombre del módulo y del nombre exportado
    • se extraen manualmente el base hash y el function hash del resultado decompilado para mapear qué API se está llamando
  • Los hashes no son iguales entre versiones del juego
  • Como los punteros a función se almacenan en variables globales, también se pueden identificar comparando la dirección virtual con las funciones exportadas de los DLL cargados
  • La detección de hooks de API de TAC actualmente solo revisa 7 patrones
    • stubs de tipo push/movabs/xchg/ret
    • push imm seguido de ret
    • call
    • jmp [rip+x]
  • No inspecciona todas las APIs importantes; revisa hooks sobre las APIs que él mismo usa

Detección de registros de depuración y firmas de prueba de drivers

  • Los registros de depuración pueden usarse como una forma de hook sin parchear código para evadir la vigilancia de Arxan sobre los parches a .text
  • TAC revisa los valores de DR0~DR3 en el contexto del hilo
    • si hay valores, llama a un callback con mensajes distintos según si pertenecen o no al proceso actual
    • luego el flujo pasa a una función de terminación
  • DR0~DR3 son privileged register, así que no pueden leerse directamente con ensamblador normal; deben obtenerse vía el kernel de Windows o mediante entrega de excepciones
  • El modo de prueba de Windows permite ejecutar drivers en modo kernel sin firma válida
  • TAC usa NtQuerySystemInformation para verificar si la firma de prueba está activada
    • esta detección por sí sola no provoca un ban directo, pero la cuenta queda marcada

Formas de terminar el proceso

  • TAC usa dos métodos para terminar el proceso
  • El primero limpia los registros y luego llama a NtTerminateProcess
    • configura RCX en -1
    • si detecta que NtTerminateProcess está hookeado, no usa este método
  • El segundo limpia los registros y luego salta a 0x0 para hacer crashear el proceso
  • Ambos métodos borran registros importantes, así que la recuperación es difícil

Detección de consola, visualización y overlays

  • Los cheats internos pueden usar AllocConsole para sacar logs o implementar menús
  • TAC detecta asignación de consola revisando la ventana de consola o el ConsoleHandle del PEB
  • La visualización interna suele dibujarse en pantalla mediante hooks a APIs gráficas
    • los Call of Duty modernos usan DirectX 12
    • un objetivo común de hook es IDXGISwapChain::Present
    • en DirectX 12 hace falta una command queue, y ID3D12CommandQueue::ExecuteCommandLists es un punto común para obtenerla
  • OBS Studio, Streamlabs OBS, el overlay de juego de Discord y el overlay de juego de Steam también pueden operar en ubicaciones similares
    • Steam y Discord sí dibujan
    • la familia OBS captura la imagen renderizada al usar game capture
  • TAC actualmente no escanea la función present de DXGI en sí, sino que verifica el puntero a present en la vtable

Cheats externos y detección basada en ventanas

  • Los cheats externos probablemente crean una overlapped window que cubre la ventana del juego
  • TAC recorre todas las ventanas y usa GetWindowLongA para revisar el estilo WS_EX_LAYERED
  • Después compara con GetWindowRect si se superpone con la ventana del juego
    • si la proporción de superposición es de 0.5 o más y la cantidad en caché es menor que 8, guarda ese hwnd
    • aparecen valores que corresponden a una resolución de ejemplo de 1920x1080
  • Las ventanas en caché se investigan más en otra función
    • revisa el texto de la ventana con GetWindowTextW
    • revisa el nombre de clase con GetClassNameA
    • revisa la afinidad de visualización con GetWindowDisplayAffinity
  • TAC también revisa casos donde se usa SetWindowDisplayAffinity y WDA_EXCLUDEFROMCAPTURE para ocultarse de herramientas de grabación o captura de pantalla
  • La información de ventanas se guarda en un buffer cifrado y se sube al servidor
    • texto de la ventana
    • nombre de clase
    • posición y estilo de la ventana
    • display affinity
    • lista de módulos y nombre del exe del proceso de la ventana superpuesta
  • El proceso de la ventana superpuesta se abre con OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION), y se recopilan nombres de módulos con K32EnumProcessModules y K32GetModuleFileNameExW

Detección de escáneres de memoria tipo Cheat Engine

  • Cheat Engine es fácil de detectar por cómo funciona la memoria virtual de Windows
  • Aunque un programa asigne memoria virtual con VirtualAlloc, esta no queda respaldada por memoria física antes del acceso
  • El juego puede asignar memoria y luego no usarla
  • Si Cheat Engine o la pestaña de memoria de Process Hacker escanean esa región, se produce un acceso y la memoria pasa a estado válido
  • Un honeypot al estilo de TAC detecta escáneres de memoria revisando con K32QueryWorkingSetEx si esa dirección virtual fue accedida realmente

Obstaculizar el escaneo por firmas

  • Los hackers del juego suelen usar signature scanning para que sus cheats sigan funcionando automáticamente tras las actualizaciones
  • La idea de Treyarch es proteger con PAGE_NOACCESS el área alrededor de la return address en funciones que no se vuelven a llamar
  • Un signature scanner recorre los bytes del ejecutable desde el inicio hasta el final buscando patrones
  • Como consultar la accesibilidad de cada byte sería muy lento, al llegar a una región PAGE_NOACCESS el proceso puede crashear
  • No es una medida de bloqueo total, pero puede dificultar mucho el trabajo a muchos analistas

Antidebugging

  • Las verificaciones antidebug de TAC en sí son simples, pero Arxan también aporta técnicas antidebug aparte
  • TAC recorre todos los hilos del proceso actual
    • usa CreateToolhelp32Snapshot y un snapshot de hilos
    • revisa DbgSsReserved en el TEB de cada hilo para detectar la presencia de un DebugObject
  • También existe una técnica que escribe en memoria inválida para provocar una access violation
    • si el código llega al punto posterior a la excepción, asume que el depurador manejó o evadió la excepción
  • También usa CheckRemoteDebuggerPresent
  • ThreadHideFromDebugger hace que las excepciones se envíen al proceso y no al depurador
    • cuando el depurador intenta detener el proceso, puede generarse una excepción STATUS_BREAKPOINT y el proceso puede terminar
    • en modo usuario no se puede quitar este flag
    • esta táctica se ejecuta en un TLS callback anterior al entry point del ejecutable

Monitoreo del tráfico de red

  • TAC no guarda todas las conexiones activas, sino que busca solo ciertas condiciones
  • El objetivo detectado es el método de crear un servidor de red local dentro del proceso del juego
    • el cheater escribe shellcode en el proceso del juego
    • inicia un servidor de red dentro del proceso del juego
    • una aplicación externa intercambia información con ese servidor local
  • TAC obtiene la tabla TCP con GetTcpTable2 y detecta la condición comparando las conexiones creadas por el proceso actual con la relación de puertos de otros procesos

Stub de syscall personalizado y cifrado

  • Muchas APIs exportadas de ntdll realizan syscalls internamente
  • Usar un stub de syscall personalizado permite evadirlo aunque un cheat en modo usuario haya hookeado funciones de ntdll
  • El syscall puede quedar expuesto al instrumentation callback
    • el instrumentation callback se llama después del syscall
    • la dirección de retorno queda justo después de la instrucción syscall
  • TAC usa un stub de syscall cifrado para dificultar el análisis estático
  • El stub se construye tras proteger como write/execute una gran región asignada en la sección .text
  • Busca la instrucción syscall dentro de NtReadFile y cambia su ubicación usando un valor de tiempo de CPU como elemento aleatorio
  • Para quien monitorea, puede parecer que el syscall se origina en una función aleatoria de ntdll
    • el syscall real puede no ser NtReadFile
    • si no se revisa el índice de syscall en eax, es difícil saber cuál syscall fue
  • Hay ejemplos donde la posición de la instrucción syscall cambia entre ejecuciones

Detección de bypasses al ocultamiento del antidebugger

  • Para establecer ThreadHideFromDebugger debe llamarse a NtSetInformationThread
  • Un cheater puede hookear esta API para que devuelva éxito
    • así el antitrampas cree que la configuración de ocultamiento funcionó aunque en realidad no pase nada
  • TAC verifica resultados de llamadas con argumentos inválidos para atrapar hooks mal implementados
    • si una llamada que debería fallar por tener mal el argumento de longitud devuelve éxito, lo detecta
    • hay ejemplos con valores de retorno distintos entre un depurador y un entorno con ScyllaHide
    • también se observó un hook que devuelve éxito incondicional ante una solicitud ThreadHideFromDebugger con un handle falso

Bloqueo de creación de hilos remotos

  • TAC instala un exception handler que llama a TerminateThread sobre el hilo actual ante una excepción STATUS_PRIVILEGED_INSTRUCTION
  • Un DLL con manual mapping necesita una forma de ejecutar shellcode en un proceso remoto, y un método común es CreateRemoteThread
  • El TLS callback de un PE de Windows puede ejecutarse antes del entry point del hilo cuando se crea un hilo
  • TAC revisa la dirección de inicio en el contexto del nuevo hilo
    • obtiene la Win32 start address con NtQueryInformationThread
    • recorre la lista de módulos cargados para verificar si la dirección de inicio cae dentro del rango de algún módulo legítimo
  • Si la dirección de inicio no cae dentro del rango de ningún módulo cargado, guarda la detección y provoca una excepción de privileged instruction para terminar ese hilo

Otras verificaciones y conclusión

  • Hay código de una verificación desconocida que revisa si AllocationGranularity de NtQuerySystemInformation es 0x10000
    • parece marcar máquinas virtuales o versiones personalizadas de Windows
  • TAC depende mucho de la lista de módulos enlazados, por lo que revisa si InMemoryOrderModuleList del PEB está vacía
    • dejarla vacía podría romper el propio proceso
  • En resumen, TAC es un antitrampas en modo usuario con las siguientes funciones
    • resolución de API en tiempo de ejecución
    • detección de hooks mal implementados
    • detección de overlays externos
    • detección de hooks internos de DirectX
    • inspección de hooks sobre APIs en uso
    • verificación de depuradores y rastros de depuración
    • detección de AllocConsole
    • detección de CreateRemoteThread
    • stubs de syscall spoofed y cifrados
  • Arxan complementa a TAC con ofuscación fuerte, obstáculos al análisis estático, técnicas que rompen IDA Pro, vigilancia de modificaciones a .text y funciones antidebug propias
  • Código similar a TAC también se usa en juegos modernos de Call of Duty

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-21
Opiniones en Hacker News

  • En 2021, una cuenta de Linux de CS:GO tuvo un problema con el indicador de confianza: bajó a amarillo y luego a rojo; no era un bloqueo oficial, pero en la práctica funcionaba como una sanción.
    Como resultado, lo emparejaban constantemente con tramposos y era difícil encontrar compañeros de equipo.
    Más tarde se descubrió que otros usuarios de Linux con GPU Radeon y 16 GB o más de VRAM estaban teniendo problemas similares, y se creó un issue en GitHub para dar seguimiento al problema: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630
    Al investigar, parecía que Valve estaba sancionando a usuarios de Linux con ciertas configuraciones de hardware, en especial tarjetas Radeon con 16 GB o más de VRAM, que en ese momento eran bastante recientes.
    Al final, el problema se corrigió después de que un usuario contactara directamente a gaben: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630#...
    Se especula que pudo haber sido resultado de que Valve estaba cuidando la experiencia de usuario en Linux mientras preparaba el lanzamiento de Steam Deck.

    • ¿Y si Gabe Newell simplemente es una buena persona?
    • No entiendo bien cómo sancionar a usuarios de Linux mejora la experiencia de usuario en Linux.
      Pero igual es interesante.
    • Me da curiosidad cómo podían saber que el indicador de confianza había bajado a amarillo o rojo.
      No sé si lo dedujeron porque la calidad de las partidas empeoró, o si había alguna forma de comprobarlo.
      Según entiendo, el indicador de confianza está oculto para evitar abusos.

  • Hacer trampa es, al final, un problema de personas.
    Con las salvaguardas y heurísticas descritas en el artículo se puede filtrar al 90% de los tramposos descarados, y creo que ese tipo de anticheat va en una buena dirección en general.
    Sin embargo, el anticheat debe operar de forma conservadora y, en última instancia, los jugadores y los administradores tienen que resolverlo.
    Los juegos multijugador en línea necesariamente deben correr en servidores administrados por personas, y debe haber administradores presentes durante la mayor parte del tiempo en que los jugadores estén conectados.
    Si es posible, mejor aún si son administradores que los jugadores reconocen; y cuando no haya administradores, deberían existir formas moderadas de intervención como votaciones para expulsar o bloquear.
    No hay una diferencia esencial entre sacar a un tramposo y sacar a alguien que abusa del chat.
    En última instancia, creo que los únicos tipos de servidor viables para juegos multijugador en línea son los servidores privados o comunitarios.
    El proceso de controlar a tramposos y abusadores no debería recibirse mediante un sistema de reportes para procesarlo de forma asíncrona; un administrador del juego debe expulsarlos o bloquearlos rápidamente.
    Si el juego en línea solo es posible mediante servidores de matchmaking del publisher, y la única forma de tratar a tramposos o abusadores del chat es denunciarlos con un formulario web, entonces no hay que comprarlo ni jugarlo: hay que votar con la billetera.

    • La condición de que los juegos multijugador en línea deban correr necesariamente en servidores administrados por personas es bastante disparatada si se piensa en la escala.
    • Suena más bien a proponer que cada partida tenga un árbitro visible para todos y que haga revisión en video cada vez que haya una infracción.
      Incluso podrían crear otra organización separada para vigilar solo a los árbitros, pero también se puede simplemente jugar.
    • No entiendo por qué se considera que la administración humana es la única solución posible.
      Apex Legends funciona bien con un sistema sólido de reportes y anticheat, y en Rocket League la moderación mayormente automatizada también funciona de forma efectiva.
    • En general estoy de acuerdo, pero también hay otros métodos.
      Podrían usarse número de teléfono, verificación manual mediante foto, exigir 10 horas de juego antes de competir, recomendaciones de otros jugadores, o incluso un pase de juego de pago único de 5 dólares sobre esas condiciones.
      Si aún no lo viste, recomiendo la presentación de Valve sobre anticheat con IA.
      El trabajo es bastante interesante y afirman que detecta al 99% de los tramposos.
      Por supuesto, todavía existen métodos de trampa muy sutiles.

  • Hubo una batalla legal de 2 años para revertir un bloqueo permanente falso de Activision, y Activision perdió porque no pudo presentar ni una sola prueba de trampa: https://antiblizzard.win/2025/01/18/my-two-year-fight-agains...

    • Me pasó exactamente lo mismo en League of Legends.
      Nunca hice trampa, pero me bloquearon sin explicación; juego regularmente con tres cuentas y las otras dos no fueron bloqueadas.
      Soporte seguía diciendo solamente “tras la revisión, el bloqueo es correcto”, sin dar ninguna información que me permitiera saber qué había hecho mal y corregirlo.
      Tengo algunas de las skins más raras del juego, he jugado miles de horas desde 2009, y solo juego ARAM; no tiene sentido que arriesgara una cuenta con tanto valor sentimental haciendo trampa en el modo más casual.
      Nunca había tenido una experiencia tan estresante relacionada con un juego, y gracias a que un conocido de la industria hizo una verificación interna, me levantaron el bloqueo sin explicación.
      Todavía juego, pero casi cada vez recuerdo ese bloqueo falso, y creo que League será el último multijugador competitivo al que le dedique tiempo.
      También siento que ya no quiero jugar por miedo a que vuelva a pasar.
    • A mí también me tocó un bloqueo permanente falso.
      En consola es casi imposible hacer trampa, me tomó muchísimo tiempo apenas llegar a un Gold 1 mediocre en ranked, y nunca recibí advertencias ni reportes por ninguna conducta; aun así me bloquearon permanentemente sin explicación.
      En vez de pelear como el autor, decidí no volver a gastar dinero en productos de Activision, y creo que todos deberían hacer lo mismo.
    • La parte de que, si juegas bien, alguien revisa tu perfil para ver tus horas de juego y de inmediato ve una marca roja que dice “soy un tramposo”, me hace preguntarme si esa etiqueta podría considerarse difamación.
      En Estados Unidos probablemente sería más difícil, pero tengo entendido que en Reino Unido o Inglaterra el demandado debe probar que es verdad.
    • Qué horrible haber tenido que pasar por una pelea así.
      Por suerte casi no juego shooters multijugador, y odiaría perder mi enorme biblioteca de Steam.
    • Este artículo por sí solo ya amerita una publicación aparte, y es muy interesante.

  • Tengo mucha curiosidad por la ofuscación de saltos
    Sería bueno que alguien con más experiencia en ingeniería inversa pudiera responder
    Me pregunto si los saltos incondicionales son tan comunes como para que sea difícil filtrarlos con ciertas precondiciones, y si, como el final de una función tiene un retorno y parece fácil de encontrar, sería posible analizar la pila para saber a dónde regresa la función y encontrar la llamada justo antes de la dirección de retorno
    Quizá esté entendiendo mal cómo funciona, porque no he programado mucho en ensamblador x86

    • Hay técnicas muy interesantes para deshacer el aplanamiento del grafo de flujo de control mediante ejecución simbólica con emuladores como angr o https://github.com/cea-sec/miasm
      También se pueden hacer análisis interesantes con el framework PIN de Intel
      Aquí hay artículos que pueden ayudar: https://calwa.re/reversing/obfuscation/binary-deobfuscation-..., https://www.nccgroup.com/us/research-blog/a-look-at-some-rea...
    • Los saltos incondicionales son muy comunes, y el ensamblador x86 después de la optimización suele quedar bastante sucio en general
      Muchas funciones no terminan en ret
    • Este video sobre ingeniería inversa de partes de Guitar Hero 3 podría resultar interesante, porque trata técnicas similares usadas para ofuscar fuertemente el código de un juego: https://www.youtube.com/watch?v=A9U5wK_boYM
    • Hay varios problemas comunes
      Algunos saltos son falsos, y algunos saltos entran en medio de una instrucción
      Los decompiladores no pueden manejar una situación en la que hay dos instrucciones en la misma ubicación
      Por ejemplo, en jmp 0x1234, se salta el opcode de jmp y se asume que 0x1234 es una instrucción válida
      En algunas ramas, la pila está rota, pero podría ser intencional para provocar una excepción
      Por eso se puede corregir la decompilación cambiando una instrucción como lea RAX, [rsp + 0x99999999999] por nop, pero también podrías perder una excepción intencional
      IDA no maneja bien este tipo de cosas, así que uso una licencia de Binary Ninja, y es fácil crear scripts para inlinear funciones para el decompilador
      Creo que IDA tiene dificultades para manejar correctamente situaciones en las que los saltos reutilizan bloques de código entre sí, porque un bloque de código entre saltos solo puede pertenecer a una función
      Parece que Binary Ninja se usa menos porque tuvo bugs con juegos de Blizzard, pero se corrigieron con un reporte de bug hace más o menos un año
    • Estos saltos específicos parecen bastante fáciles de filtrar
      Es una ofuscación pensada para molestar a los usuarios de herramientas comerciales comunes, especialmente IDA Pro
      La mayoría de la ofuscación busca solo ser lo bastante molesta como para que la gente se vaya a otro proyecto

  • Quitar funciones de un producto después de venderlo debería estar prohibido por ley, aunque esté en el contrato o en la EULA
    Un bloqueo no debería quitarte la propiedad del juego en sí, y si lo hace, deberían reembolsarte
    Si hace falta llegar a una sentencia para obligar al reembolso, debería haber daños triples además del costo de la licencia, los honorarios de abogados y los costos judiciales
    Por ejemplo, debería ser legalmente imposible que te bloqueen en Steam y eso invalide todas tus compras
    Aunque te bloqueen el inicio de sesión de la cuenta, los objetos y el inventario deberían poder comerciarse, porque son cosas por las que el cliente pagó y que obtuvo invirtiendo tiempo real
    Si quieren aplicar normas éticas en un juego multijugador, no deberían poder cobrar por el juego, o los usuarios de pago deberían tener derechos frente a los bloqueos
    Los bloqueos deberían seguir el principio de proporcionalidad y contar con un registro y un procedimiento de apelación con intervención humana, cuyo costo esté limitado al precio de la licencia y solo se cobre si se pierde

    • Hacer trampa no hace que te bloqueen en Steam
      En el peor de los casos, te ponen una marca pública de vergüenza en la cuenta para juegos VAC
      La gente juega juegos multijugador para divertirse e interactuar con otros, así que si afectas a otras personas, ya sea haciendo trampa o con otra mala conducta, deberían bloquearte el uso del servicio multijugador
    • No veo en qué se diferencia de exceder el límite de velocidad al conducir
      Si causas molestias a la sociedad, pagar las consecuencias es un principio bastante común
    • Me parece bien que a los tramposos les caiga lo que les toca
      Creo que está bien que pierdan dinero real
      Pero que te bloqueen por error es otro tema
      Y lo que se bloquea no es toda la cuenta de Steam, sino el juego específico que ya no puedes jugar, ¿no?
    • Mejor ponerles una etiqueta de tramposos y hacer que solo jueguen con otros tramposos
    • Si haces trampa o arruinas la partida de otros jugadores, mereces perder el acceso
      Los otros jugadores también pagaron

  • En COD ni siquiera hace falta hacer trampa
    Tiene tantos bugs que el juego lo hace por ti
    A veces carga un arma de fuego en vez de un cuchillo en ranked, y eso es posible porque claramente hay un case o un if-else mal hecho en la verificación del equipo de armas de ranked; parece que si el arma que aparece en el selector de equipo no está permitida, se configura por defecto como XM4
    Es casi el único juego que conozco cuya versión ranked está más rota que la versión casual

  • Me da curiosidad dónde aprendieron este tipo de cosas.
    Quisiera aprender más, al menos lo suficiente como para entender aunque sea la mitad del artículo, pero no sé por dónde empezar.

    • Hace unos 15 años aprendí mucho leyendo el libro Reversing: Secrets of Reverse Engineering, de Eldad Eilam.
      Es un libro viejo, pero excelente, y te guía por varias técnicas y ejercicios prácticos.
      Las herramientas modernas cambiaron un poco desde entonces, pero el conjunto de instrucciones x86 y el ensamblador en general no cambiaron demasiado.
      Uno de los mayores beneficios fue conocer los crackme.
      Son pequeños binarios de desafío creados para aprender ingeniería inversa, algo así como candados de práctica en la comunidad de lockpicking.
      Si mal no recuerdo, el libro traía varios en un CD-ROM, y también hay muchos en línea si los buscas.
      Hacer este tipo de práctica por tu cuenta es la forma de aprender.
      No deberías intentar hacer ingeniería inversa de COD desde el principio; hay que ir construyendo por etapas.
    • Antes se empezaba con los tutoriales de Lena151: https://github.com/kosmokato/Lena151
    • En otros tiempos te habría dicho que fueras a Gamedeception y te mezclaras por ahí, pero parece que desapareció hace unos años.
      Saludos a quienes frecuentaban UnknownCheats, cs.rin.ru y demás.
    • UnknownCheats es uno de los mejores lugares para material de este tipo.
      Yo también participo ahí, y me interesa especialmente el anticheat en espacio de usuario de Linux, sobre todo cómo funciona VAC.
    • https://pwn.college es un excelente recurso educativo.

  • Hice un poco de ingeniería inversa a un MMO popular basado en Horde/Alliance, y seguía casi los mismos pasos, incluido el hash de exportaciones FNV32.
    Al ver que usaba trucos muy parecidos, parece casi el mismo enfoque.
    Me pregunto si estará empaquetado con la misma tecnología de protección.

    • El motor Source 2 también usa fnv para hashear esquemas, es decir, propiedades de entidades.
    • Tendría sentido si, después de la fusión, reutilizaron Warden en propiedad intelectual de Activision.

  • El escaneo de firmas es realmente potente.
    También es la parte de la ingeniería inversa que más adictiva me resulta.
    Es divertido crear una lista de firmas y escribir bindings para un lenguaje de scripting que permitan llamar a esos punteros de función.
    También es la base de muchas plataformas de mods de terceros, porque necesitan ofrecer a los modders APIs significativas que el desarrollador principal no expuso.

    • No sé qué es el escaneo de firmas, pero encontré este recurso para quien tenga curiosidad: https://www.unknowncheats.me/forum/general-programming-and-r...
    • Correcto.
      Tengo entendido que algunos plugins del motor Source también usan este método cuando lo necesitan.
      Aunque parece que la mayoría usa offsets de punteros a tablas de funciones virtuales.

  • Me pregunto si sería posible o tendría sentido firmar digitalmente el estado del juego de forma periódica, o introducir algún tipo de prueba de trabajo para impedir las trampas.
    Empiezo a pensar que hacer trampa es un problema demasiado difícil de evitar.
    Estoy creando un FPS online pequeño y barato, y en lugar de tener software anticheat, estoy considerando que los usuarios confíen entre sí y detecten a los tramposos por su cuenta, o usar IA como Valve.
    Probablemente deje que los jugadores administren y operen sus propios servidores.
    Se podrían poner condiciones como vincular un número de teléfono, puntajes de reputación otorgados por otros jugadores, identificación oficial u otros medios fuertes de autenticación, verificación manual con fotos como en las apps de citas, o jugar 10 horas antes de partidas competitivas.
    Creo que los jugadores hardcore estarían dispuestos a pasar por esos procesos para reducir la cantidad de tramposos.

    • Si has jugado bastante juegos online, sabrás que los jugadores plantean acusaciones de trampa de forma constante incluso con muy poca evidencia.
      También existe el abuso social de denunciar a jugadores que no les caen bien para lograr que los bloqueen.
      En un sistema así habría muchos más falsos positivos que con cualquier anticheat.
    • A alto nivel, bastaría con simular una partida sin trampas, firmarla y procesar los cheats por separado.