Que tanto sabemos de un Anti-Cheat


#1

This post was flagged by the community and is temporarily hidden.


#2

Los hackers son como las cucarachas. Ni siquiera un arma nuclear puede hacerse cargo de ellos.


#3

No hay forma alguna de detener por completo a los exploiters,solo poner varios limites.


#4

Si puede leer en inglés, recomiendo consultar este post, ya que aclara algunos conceptos erróneos comunes sobre los exploiters. Si tiene problemas para leerlo, recomiendo ver si DevRel puede ofrecer una versión traducida en esta categoría.


#5

Primero que todo el término “hacker” está mal dicho, lo que existe son exploiters que usan programas que rompen la estructura del cliente de ROBLOX, lógicamente no dejarán de existir porque por cada actualización al Cliente, los creadores de los exploits actualizarán o crearán nuevos exploits.

No se puede evitar que un exploiter con conocimientos básicos-intermedios deje de ver lo que pasa en SU cliente, por eso la mejor opción es encontrar formas personalizadas de evitar que alguien pueda controlar nuestro juego. Una forma es comprendiendo qué información entregamos al servidor o envíamos cuando hacemos un Fire, otro consejo sería dejar de poner Scripts, Local Scripts dentro de las partes en el Workspace, ¡para nada es recomendable!. Todos los scripts/local scripts deben estar en sus respectivos lugares que son ServerScriptService y PlayerScripts.

Otro consejo es complicar la comprensión de nuestros Scripts locales, con la declaración de variables que hostiguen la vista del exploiter, ejemplo, en vez de poner

local Pato = Workspace.Pato;

pongamos:

local auewwh7784y4i44ui = Workspace.Pato;

Eso es una cosa que molesta demasiado a los exploiters. :joy:

Una última recomendación es saber cómo tenemos nuestro juego y evitar así la corrupción de datos, o sea, saber en dónde tenemos los datos importantes para que el juego no falle y entonces no sean fáciles de ver por el exploiter

Por último, los exploiters como dije, nunca van a dejar de existir, porque siempre van a actualizar sus programas que atentan contra la estructura del programa, más tarde podría hacer un post totalmente de cómo evitar los exploits personalizadamente para cada juego, ya que lo que le funciona a unos, a otros NO.

  • NeutralMind

#6

Mí anticheat favorito consiste en tus localscripts luego de guardar en variables, partes importantes del gui o lo que ocupes, ocultarlo con un script.Parent=nil en cuando se inicialice todo

no sé si vivo bajo la falsa creencia de que haciendo eso ocultas tus códigos y con ello los métodos por los cuales pueden acceder a tus remote events y remote functions y con ello, supongo que se reduciría la posibilidad de ser hackeado


#7

Los exploiters pueden encontrar objetos entre los padres y nulos y, de hecho, tienen herramientas específicamente diseñadas para buscar objetos entre los padres y los nulos, por lo que hacer esto solo hace que las partes sensibles de su juego destaquen más.


#8

El termino hacker es todo aquel que entra en el sistema de programación de algún juego/programa/http en particular, ahora los hackers son los que entran en el sistema para poder obtener los códigos primarios de roblox, una vez que los obtienen hacen sus llamadas herramientas o programa con la cual actualizaran o crearan a lo que se le llama exploit de ahí viene el termino de las personas que utilizan los exploit, son llamados exploiters ya que ellos no fueron el creador de aquel programa/herramienta, para los llamados hackers e visto uno que otro incluso tratando de echar competencia para ver quien actualiza su programa/herramienta primero, ya que cada que actualizan roblox y patchean el código que ellos usan en su programa se esmeran en buscar el nuevo código en el.

Últimamente 4 de cada 10 servidores de roblox contiene un exploiter lo que significa que el indice de exploiters a ido aumentando conforme al tiempo, esto debido a una API que te permite crear tu propio programa/herramienta, lo que e oído de esta API es que la actualizan cada que roblox es actualizado.

Ahora no hay manera de ocultar los eventos remotos o funciones remotas debido a que un exploiter puede ejecutar un GUI que pueda ver todos los archivos tanto como de los leaderstats, como los del ReplicatedStorage, un exploiter sólo podrá ver lo que un localscript pueda recibir.

Últimamente e estado trabajando en una carpeta de nombre multiple y remotos de cambio de nombre, esto quiere decir que cada servidor tendrá una carpeta determinada con un nombre diferente y que los remotos puedan tener diferente nombre al ser disparados desde un local, esto probablemente detenga un poco a los exploiters ya que entre ellos se pasan los codigos que están dentro de un juego, tambien a poner una función de detección si hay un cambio brusco entre monedas no programado que este kicke al jugador del juego.

En conclusión los exploiters y hackers últimamente son indetenibles y si esto sigue así puede que el indice pueda ser que 7 de cada 10 servidores tengan un exploiter dentro.


#9

Ir cambiando el nombre de un remoto no es una solución eficaz, ya que para firear ese remoto será necesario obtener el nombre mediante alguna función, lo único que hará el exploiter es seguir tus pasos y hacer lo mismo.


#10

No exactamente, lo que intento hacer es que los exploiters no puedan pasarse el código entre si y asi erradicar por lo menos en un 30% o 40% el numero de exploiters en un juego ya que no todos disponen de el mismo script, mi proyecto es que este pueda detectar el nuevo nombre cambiándolo por un valor en el scriptlocal primario del jugador, algo así como que el script al que esta conectado, cambie el nombre del remoto del jugador y se lo envié de vuelta al local primaro como un valor.


#11

La mejor manera de alejar a los exploiters que sé hasta ahora es verificando si el cliente tiene el permiso de dar Fire al Remote, o condicionando la función, por ejemplo, un arma;

  • La posición desde la que se disparó la bala.
  • La dirección en que se disparó la bala.
  • El personaje que supuestamente fue golpeado.
  • La posición del punto de golpe.

Si estas condiciones son erroneas al compararlas con el server, entonces le da kick.
Y si hablamos de seguridad, nunca confíes en el cliente, los exploiters pueden ver los locals y sacar los datos.