Dom, 09 Ene 2011
Re: Anti Chit si o no
Siempre me interesó el tema anticheat, pero nunca nos ponemos de acuerdo en los métodos y/o forma de implementarlo.
El tema es, los clientes son lo ultimo a modificar. O sea, el anticheat ideal, funciona via server-side.
En el caso puntual del urban, donde, el cliente es cerrado e inalterable, la única forma sería, o corriendo un programa en "paralelo" que monitoree el ejecutable, o inyectándole código (cosa que los cheats hacen).
A tener en cuenta, que todo lo que el cliente corra, esta en manos de cualquiera y mas crakeable que eso...
Programa en paralelo: mucho sentido no tiene, ya que es un programa mas que se puede monitorear e incluso alterar sin mucho esfuerzo.
Inyección de código: no es mala, pero el problema persiste. El usuario puede alterarlo y... (me refiero a usuario al mismo hdp que hace los hacks)
Mi opinión, es que hay que lograr algo 100% server side.
Ventajas:
Los clientes no necesitan modificar ni correr nada, usan el ejecutable estándar.
Podes, por ejemplo, usar el sistema que usa GTV, donde te loguea a un server con un "lobby" y habría que ver si te puede, luego de autenticarte, pasarte a otro.
Desventajas: Imposible saber el detalle de que esta corriendo.
Pero como ya tenes un filtro y registro de usuario, podes manejar los accesos a donde vos quieras.
Esa es mi "visión" de un anticheat, donde por medio de un solo server modificado, y los demás servers "en comunicación" a este, podes autenticar usuarios y filtar a que servers los dejas entrar.
Habría que analizar mejor como funciona GTV para ver que capacidades tiene, y sino, analizar el ioquake (que si es 100% open) y modearlo para llegar a lograr algo como lo que planteo. Con esto, solo modificas server sides, sin generar exceso de banda, ni necesidad de que los users bajen nada especial ni corran nada mas que el cliente puro.
Salú
PD: @fercba... me vino a la mente una frase tuya.. "corro 40 ejecutables de urban en mi windows 7 y tengo un super server!!!"
El tema es, los clientes son lo ultimo a modificar. O sea, el anticheat ideal, funciona via server-side.
En el caso puntual del urban, donde, el cliente es cerrado e inalterable, la única forma sería, o corriendo un programa en "paralelo" que monitoree el ejecutable, o inyectándole código (cosa que los cheats hacen).
A tener en cuenta, que todo lo que el cliente corra, esta en manos de cualquiera y mas crakeable que eso...
Programa en paralelo: mucho sentido no tiene, ya que es un programa mas que se puede monitorear e incluso alterar sin mucho esfuerzo.
Inyección de código: no es mala, pero el problema persiste. El usuario puede alterarlo y... (me refiero a usuario al mismo hdp que hace los hacks)
Mi opinión, es que hay que lograr algo 100% server side.
Ventajas:
Los clientes no necesitan modificar ni correr nada, usan el ejecutable estándar.
Podes, por ejemplo, usar el sistema que usa GTV, donde te loguea a un server con un "lobby" y habría que ver si te puede, luego de autenticarte, pasarte a otro.
Desventajas: Imposible saber el detalle de que esta corriendo.
Pero como ya tenes un filtro y registro de usuario, podes manejar los accesos a donde vos quieras.
Esa es mi "visión" de un anticheat, donde por medio de un solo server modificado, y los demás servers "en comunicación" a este, podes autenticar usuarios y filtar a que servers los dejas entrar.
Habría que analizar mejor como funciona GTV para ver que capacidades tiene, y sino, analizar el ioquake (que si es 100% open) y modearlo para llegar a lograr algo como lo que planteo. Con esto, solo modificas server sides, sin generar exceso de banda, ni necesidad de que los users bajen nada especial ni corran nada mas que el cliente puro.
Salú
PD: @fercba... me vino a la mente una frase tuya.. "corro 40 ejecutables de urban en mi windows 7 y tengo un super server!!!"
