He sido dev de cheats y contesto a vuestras preguntas

NeV3rKilL

#240 Tengo que hacer "estudio de mercado" pero a priori cualquier juego con cumpla con:

  • No usa wine (posiblemente más complicado de remenar)
  • Singleplayer (no molestar)
  • 2d (rápido iniciar-cerrar-trastear)
  • Juego con consola (debug)

Quizá los BG enhancement edition son un buen comienzo. Si no algo de plataformas. Con leer/encontrar/modificar (vida/nombres personaje/items) Sería feliz. Si no algún plataformas tipo VVVVVV, pero debo buscar literatura online para ver el estado del arte antes de empezar.

2 respuestas
Soltrac

#239 El concepto es el mismo, pero en linux es más fácil porque hay menos protección todavía si cabe. De todas formas, no tengas miedo con el CSGO. Ejecuta el juego siempre en modo insecure y con sv_lan 1 y VAC así nunca carga.

Por cierto, para que veais como es el tema de la lucha cheat/anticheat, una de las cosas que me quedé con ganas de probar para evitar que detectaran que movía el ratón por software, era mover el ratón con una placa arduino para simular un ratón. Es algo que seguramente alguien habrá investigado, pero es cierto que nunca lo he visto por ahí.

AikonCWD

#241 Y lo quieres hacer sobre Linux? Si lo haces sobre Windows, te puedo ayudar en lo que sea, siempre y cuando nos alejemos de juegos multiplayer/online.

1 respuesta
Soltrac

#241 El cheat engine de linux es http://manpages.ubuntu.com/manpages/zesty/en/man1/scanmem.1.html

Pero no es para nada tan user friendly como cheat engine.

1 respuesta
NeV3rKilL

#243 Me apetecía linux por aprender mejor su api y go por lo mismo :(

Quizá sí que para empezar debería ir pasito a pasito. Cuando llegue a casa lo miro, que la semana que viene hay fiesta y puede ser un buen comienzo.

#244 Mirando el man se ve bastante asequible. Merci por el link.

1 respuesta
AikonCWD

#245 Yo te aconsejo que empieces con Windows, más que nada porque te será más facil. Empieza por algo básico y sencillo, como por ejemplo buscar valores/estructuras y modificarlas. Luego métete con los punteros, memoria/funciones compartidas (es super divertido), etc... Tendrás que tocar muchísimo ensamblador.

Empieza por algo sencillo o te vas a agobiar. Aim small miss small. Ah! Y no empieces la casa por el tejado. Puede ser muy goloso eso de bajarse un framework, buscar en internet los offsets d eun juego y compilar un cheat, pero lo corresto es que tú sepas buscar esos offsets por tu cuenta y programes el cheat línea por línea. Sin usar frameworks o modulos/funciones de otras personas.

B

Yo ahora os hago la pregunta desde programador a Cheater coder.

Yo para algunos de mis juegos, habilito desde código, el funcionamiento "God Mode" para cuando quiero trastear elementos sin tener que preocuparme de morir.

Es activar un booleano con GodModeActive: False/True. Podéis modificar esto para activarlo?
En Unity podéis ver el código de como está hecho el juego y adaptarlo a lo que queráis. O trabajáis con lo que se carga en memoria para hacer los chanchullos desde ahí?

1 respuesta
AikonCWD

#247 Si el dev lo implementa en su código, es muy fácil descubrirlo por el dev-cheater. Si encima me dices que es unity, más sencillo todavía. Le paso un Mono-dissector a tu juego y en pantalla recibo prácticamente todo el source del juego, así como el nombre de sus funciones. Aplico JIT y cambio las estructuras a mi gusto.

Cualquier juego en .Net / Unity es muy sencillo de modificar.

B

Ni me molesto en ocultarlo directamente. Como ya pensaba y comentaba, es mejor hacer que el juego sea funcional y limpio a intentar que los cheaters no te rompan el juego, porque hacerlo lo van a hacer si quieren.

Donde se debe tener más protección es en el servidor de datos, que ahí es donde hay que poner toda la atención para que si alguien te lo hackea, no te haga destrozos, se le pille rápido y al resto de jugadores no les afecte.

2 respuestas
AikonCWD

#249 Exacto, pero siempre puedes añadir alguna protección homemade, que suele tocar mucho los huevos y con eso limpias el 90% de "cheaters" de 15 años que han aprendido con tutoriales de youtube.

Por ejemplo, el juego español Unepic, un juego singleplayer; tiene implementado un anticheat casero (sí, un puto anticheat en un juego offlie/sigleplayer) muy divertido... Si intentas modificar alguna variable, el jugador explota y muere xddddddddddddddd.

2 respuestas
Soltrac

#249 Coge tu juego compilado y busca la carpeta Managed. Ahí busca el Assembly-CSharp.dll, ábrelo con cualquier decompiler de .NET y ahí tendrás tu código listo para que todo el mundo lo vea.

B

#250 Quiero saber más sobre eso.
Porque así a bote pronto es crear un archivo con un checksum para ver si ha sido alterado y cargar la función de matar o mandar el mensaje de "cheater scum!!!!" :D

En el tema del DLL, estoy trabajando con el Ofuscador, pero ya con ello, no se si es suficiente para poner en problemas a los cheaters.

En el tema de las variables, pues usar intermedias para hacer los cálculos y los hackers podrían modificar los valores que ven en pantalla, pero no los que están en memoria. Ellos podrían ponerse 1000 de vida, en vez de 100, pero seguirán teniendo los 100 porque no han podido tocar eso.

1 respuesta
AikonCWD

#252 Tienes que entender que, hagas lo que hagas, se lo podrán saltar si quieren. La idea simplemente es dificultar un poco el camino y ventilarte a scriptkiddies quinceañeros. Cualquier ofuscación es reversible.

Crea una función interna que encripte y desencripte los valores importantes del juego (por ejemplo almacenar los valores en negativo, y que tu función multiplique el valor * -1 para sacar el valor correcto). Así si el juego te dice que tienes 55 punto de vida, internamente la variable valdrá -55, y eso dificulta un poco la búsqued ainicial. Paralelamente crea una variable inutil que sí almacene el valor mostrado por pantalla (55) y si detectas que lo modifican, mata al jugador.

Un cheater buscará el valor 55 (el falso), lo modificará y explotará. Mientras que la variable real del jugador está multiplicada por -1 para mantenerla lejos de ojos fisgones.

Otra opción es crear comprobaciones de integridad. Con un proceso externo, busca en tu memoria del juego la zona crítica (por ejemplo la función que calcula la subida de experiencia), haces un checksum y compruebas ese checksum cada 2 segundos. Si un cheater inyecta o modifica la función, mata al jugador xD.

Otra opción es usar ofuscadores para .Net/C#, pero intenta usar ofuscadores no conocidos, y si te lo curras, créate tu propio ofuscador (hay ejemplos en github).

Otras opciones que tienes es intentar "atacar" las herramientas típicas. Meter funciones que busquen si el cheatengine/ollydbg/ida/x64dbg están instalados en el sistema, luego mata al jugador o impide la ejecución del juego hasta que las desinstalen.

Pero recuerda, cualquier cosa de esas será siempre franqueable, si se dedica el tiempo y esfuerzo necesario. Pero realmente aplicando un par de "anticheats" caseros te follas a más de la mitad de noobs.

B

Yo lo que he pensado es en los valores numéricos, meter un offset random. De esta manera, al crear el número tendrás 100 de vida +/- el offset. De esta manera el que busque 100, verá que aparece -546 o 984.

Ya se que el que te quiera pillar lo hará, pero al menos que no sea fácil para los novatos y si los entendidos.

2 respuestas
AikonCWD

#254 Exacto, hay muchas formas de implementar "dificultades" para los cheaters. Pero creo que deberíamos abrir un hilo a parte. Una cosa que toca mucho los cojones es que uses funciones compartidas (shared memory) y que implementes un sistema aleatorio y dinámico para almacenar las variables importantes. Me explico:

Supongamos que en tu juego tienes al jugador y a los enemigos... pues haz una única función llamada fRestarVida(jugador, vida) que sirva tanto para restar la vida del jugador (cuando te peguen) como para restar la vida del enemigo (cuando les pegues tú). Para un cheater es algo un poco complejo, pues no pueden modificar a saco la función fRestarVida(), pues cualquier modificación afectará también a los enemigos. De ahí que algunas veces, haciendo el cheat de godmode termine metiendo a los enemigos invulnerables también xD.

Es algo fácil de saltar también, pero hay mucho niñato que no sabe diseccionar estructuras y son incapaces de hacer tramas cuando la función es compartida.


Otra cosa que jode mucho es que almacenes una variable importante en un array muy grande, y que cada vez que modifiques esa variable, la almacenes en otro lugar random del array. Para los cheaters es dificil crear un cheat que modifique la vida del jugador si ésta está constantemente dando saltos por la memoria RAM.

Soltrac

#254 No te compliques, eso no arregla nada. Nadie q trabaja con Unity se complica en buscar variables con cheat engine porque tenemos acceso al código fuente, por lo tanto, lo que hagas, vamos a saltárnoslo.

Si tu juego es online, lo que tienes que hacer es lo siguiente, que son las cosas básicas.

1) Ofusca el código. No es lo mismo leer Posición = 100 que a = ea2u323829.
2) Server sided lo máximo que puedas. Vidas, armor, munición, etc. Nunca creas en la vida que dice que tiene el cliente, siempre en la q dice q tiene el servidor.
3) Intenta guardar la integridad de tus archivos. Cada X tiempo, comprueba que la integridad no ha sido modificada. Casi todo lo que se trabaja con Unity suele ser mediante inyección de código porque es muy cómodo por ser Mono.

Te voy a decir lo que hace Albion Online:

AppDomain.CurrentDomain.AssemblyLoad += (sender, args) => TUFUNCION();

Que hace esto? cada vez q alguien cargue un assembly en tu cliente, sube un hash al servidor para marcarla.

Además, cada X tiempo hace:

foreach (var assembly in AppDomain.CurrentDomain.GetAssemblies()) {
             var fileStream = new FileStream(assembly.Location, FileMode.Open, FileAccess.ReadWrite, FileShare.Read);
            var binaryReader = new BinaryReader(fileStream);
         ...............
}

Y hace lo mismo.

Es una mierda, pero puedes evitar inyectores estándard si haces algo parecido. Evita siempre que haya una assembly que no esté en tu whitelist. Y comprueba el hash de tus assemblies para que nadie los modifique.

¿Esto es hackeable? Sí, parcheando las funciones "AppDomain.CurrentDomain.GetAssemblies()" y "AppDomain.CurrentDomain.AssemblyLoad" pero ya tienes que preocuparte de saber como se hace.

Luego, cosas como estas son básicas:

https://msdn.microsoft.com/es-es/library/windows/desktop/ms680345(v=vs.85).aspx

Si alguien quiere debuguear tu juego que al menos sepa parchearlo. Desde .NET puedes hacerlo con: System.Diagnostics.Debugger.IsAttached eso cada X tiempo y mata el proceso.

Otro ejemplo, sabes como detecta Albion Online los zoom hack? Lo que hacen es subir al servidor donde clickean los jugadores, si están clickeando fuera de la pantalla "normal"............BAN.

PaCoX

#250 Tienes que centrarte en el cifrado, ten en cuenta que la generación y el almacenamiento de la clave debe ser igual de fuerte que el propio cifrado.
Debes pensar como un hacker haciendo un ransomware...
Si quieres ir a lo basico pues ofusca que es gratis y implementa codigo para detectar alteración de memoria. Basicamente tienes que implementar un observador de tus vars y comprobar su integridad (checksum de variables, guardar los datos en varias posiciones de memoria,etc)

ANG

Me gustaría saber la opinión de alguien que ha hecho este tipo de cheats acerca de estos momentos.

1 respuesta
B

Eso son ratonazos y gente que tiene más de 1k horas al CS:GO. Quién se jugaría su cuenta y prestigio por usar cheats? Me lo han dicho ellos.

Soltrac

#258 Ya te explico yo, q se como funcionan los de CSGO.

Hay 2 funciones para comprobar si al jugador lo estás viendo o no. Una es un poco rollo porque tarda un segundo en activarse, por lo q no vale a nivel competitivo. La otra se basa en coger el archivo .bsp del mapa y guardártelo entero. Es decir, saber donde están las puertas , paredes, etc. en memoria. De esta manera, es muy rápido saber si un jugador lo puedes ver o no. Lo que haces aquí es coger , leer el mapa que vas a jugar en la memoria del juego (sabemos la posición donde está) y sabemos en que carpeta se guarda (tb en memoria). A partir de ahí, como conocemos la estructura del BSP, simplemente es jugar con ello.

En este caso, hay ejemplos que no me cuadran. Voy a suponer que el jugador lleva cheats y se los ha programado alguien q sabe. Nadie en su sano juicio haría un lock a través de una pared (como el del min 1:38). Ahí se q es jodido, pero es q es pura casualidad porque voy a suponer que va en lan y no lleva ESP.

Es posible hacer aimlock a través de paredes? Sí, pero yo al menos no lo haría para evitar estas cosas.

Lo que sí puede llevar es un trigger como el del min 2:00. Para un trigger puede usar un avisador acústico y hacerlo manual o hacerlo automático (con un delay random). Es verdad que apunta muy raro a las paredes en 2:35 y en online te diría que obviamente lleva un aimbot muy malo. Esos aimlock a través de paredes son fácilmente evitables en CSGO por lo q te he dicho y además estamos suponiendo que él no ve nada, por lo que es su ratón automáticamente el que lo está haciendo.

Y bueno, sigo viendo y lo único q veo es un aimbot que es una puta mierda. Si yo fuera un pro player y jugara viéndome medio mundo haría un aimassist muy disimulado y muy humanizado. No lockearme en la cabeza de nadie que encima está detrás de una pared.

B

Esos aimlocks son externos metidos en el driver del ratón. No son una puta mierda realmente, ya lo dije antes son builds customizadas para el comprador y al ser externas no tienen la precisión de un código injectado en el juego.

Bugs del programa leyendo el bsp, etc... Pero nada detecta esos cheats.

1 respuesta
Soltrac

#261 Con los pcs de hoy en día no necesitamos inyectar en el juego para hacer un aimlock sin problemas.

1 respuesta
B

#262 Como que no? Y que tiene que ver el pc con eso?

1 respuesta
Soltrac

#263 Pues que un hack externo en teoría es más lento porque estamos fuera del proceso, pero hoy en día, leer la memoria de un proceso externo es fácil y muy rápido.

No necesitamos inyectar en ningún momento, podemos hacerlo desde fuera todo con drivers por ejemplo. Desde kernel tenemos acceso a la memoria de un proceso sin tener q estar dentro de él. Es fácil.

1 respuesta
B

#264 Pero me refería a que los cheats externos leen la posición desde el bsp y eso a mi me parece un mapeado pobre.

1 respuesta
Soltrac

#265 No no, no es así.

Se lee desde la memoria. El BSP se usa para saber si alguien está visible o no, para no ir haciendo aimlock por todo el mapa.

Es decir, si yo estoy en una posición y el jugador objetivo en otra, puedo saber con el BSP que tengo cargado en memoria si hay una pared de por medio. Y no es culpa del BSP, el problema es que CSGO es un juego modeable, se pueden crear mapas para él, el motor es semipúblico. Esta información es pública.

1 respuesta
B

#266 Sí ya por eso se todo esto, pero en el bsp una vez que abrí uno no hay puertas ni ventanas y pasa esto:

1 respuesta
Soltrac

#267 Ahora mismo no estoy 100% seguro porque hace tiempo que no edito, pero yo estoy casi seguro q yo no hacía aimlock por puertas....pero ahora me pones en duda.

De todas formas, en ese vídeo el problema que tiene el cheat es el FOV, que lo tiene demasiado alto para hacer un lock. Por eso se le gira demasiado.

vincen

Entiendo que es muy fácil inyectar código ya que en se encarga el cliente de manejar la información...

Pero si en un futuro cuando tengamos conexiones a internet con un máximo de 1ms de punta a punta de Europa (Conexiones 5G,6G,7G etc xD)
Se podría desarrollar haciendo que el servidor se encargue de procesar/verificar toda la información, entonces ya no habrían chetos, no?

Vamos como en el POKER, al cliente no le mandan la información las cartas de los demás, de eso se encarga el servidor y solo las muestra a final de la partida.

Si en los FPS solo mandas la información del enemigo solo cuando tu puedes verlo (El servidor se encargaria de decidir si el jugador puede ver al otro jugador) entonces ya está, no? Si quitamos el problema del LAG, entonces ya no habria chetos, no?

Ya que estoy vamos a lo loco..
Para el tema del AIMBOT seria necesario 0ms de conexión para poder mandar los movimientos del raton al servidor y que el servidor se encargue de mover al jugador del cliente.

Pero vamos.. si en lan tienen 3-5 ms, habria que mejorar tambien las tarjetas de red y tiempo de respuesta de los servidores.. vamos una puta locura xD

Es viable en 2050? xD

2 respuestas
AikonCWD

#269 Suponiendo que en 2050 todo dios tenga ordenadores cuánticos impulsado por plutonio, y nuestras conexiones de internet sean de 1 millon de YottaBits/seg... sí, podríamos tener un juego tipo PUBG cuyo el 100% de las variables de los 100 jugadores sea administrada por el servidor. Pero siendo francos, eso no sucederá ni en 2050 ni en el año 4000.

Pero eso no quita que la inyección de tráfico TCP se pueda seguir usando para hacer cheats.

Usuarios habituales