Bueno acá les vengo a tratar de una forma muy eficaz para sacarte de la cabeza muchos "cheaters".

el truco consiste en tener un contador de paquetes, y usarlo como pw para encriptar/desencriptar todos los paquetes, lo bueno es que esta clave cambia cada ves que sale un paquete desde el cliente, y por eso es 100% dinámica, además de que NO alarga demasiado el string (ojo, yo no hice la encriptación , fué la primera que encontré en google a las 5 am), es corto y funcional.

empezamos .

agregamos TANTO SERVIDOR COMO CLIENTE, un nuevo módulo y lo llenamos con esto




buscan el sub EventoSockRead y lo remplazan por este.



un poco mas arriba está el sub EventoSockAccept

en el mismo buscamos esto



arriba/abajo da igual, agregamos



mas abajo en ese mismo módulo encontramos el sub EventoSockClose

buscamos esto en ese sub



abajo agregamos



bien , ahora buscamos el Type User y en el esto.



abajo agregamos



abajo del End Type o en cualquier otro módulo (preferentemente Modulo declaraciones) ponemos



Pasamos al cliente, y remplazamos el sub SendData por este.



y por último, declaramos



con esto estaría todo , pueden comprobar que el string no se alarga tanto, con 1 ejemplo

SALE DATA : M3
SALE DATA CRYPT : ¿¨q

SALE DATA : RC51,52
SALE DATA CRYPT : ĸ§¦ž§§r

SALE DATA : M3
SALE DATA CRYPT : ¿¨s

SALE DATA : M3
SALE DATA CRYPT : ¿¨t

SALE DATA : M4
SALE DATA CRYPT : ¿©u

Y que ocurre cuando la encriptación da como resultado Char0, que es el carácter de fin de comando
Este es el problema de encriptar TODO... de manera dinámica el error del Char0 siempre estará presente tiene que ser una encriptación inteligente y selectiva.
Si manda 3 o 4 veces el mismo comando, se codifica diferente no?

Es una verga el manejo de paquetes de versiones inferiores a la 12, en un corte patería a todos(Incluidos micro cortes client-side). Cada paquee en el cliente se encripta distinto, sin embargo si al servidor llegan 2 juntos se desencriptan iguales. Y la encriptación esa no alarga ningún paquete :p. Lo que tenés que hacer para procesar los paquetes es desencriptar, buscar el nullchar, copiar hasta ahi y procesarlo, después agarrás lo que te sobró y hacés lo mismo.

Acá lo codee, no testee nada así que no aseguro que funcione, pero estoy casi seguro de que si :p.



En el cliente resetea el packageCount cuando establés conexión, porque sino si relogueas se va a romper todo. En el cliente te recomiendo que en el sendData hagas if logged then packagecount=packagecount+1

Porque así como está creo que es re explosivo, jaja

Increíble matih, pero estos 2 comentarios de arriba me hacen desconfiar .

Saludos!

Un modulo del AODefender de Saturos no hacia esto?

idem

Lekasak escribió:Un modulo del AODefender de Saturos no hacia esto?

If Encriptacion = 1 Then
Lag = Lag * 2
Cpu = Cpu - Lag
Else
Lag = Cpu
End If

Espero que lo entiendan y empiecen a ingeniar nuevas cosas

Saludos!

Lekasak escribió:Un modulo del AODefender de Saturos no hacia esto?

No, era más completo, encriptada server y cliente siempre distinto, pero como dice gs, tambien se fijada en el nullchar para no causar errores.

que es nullchar? capas es el problema que tengo yo perdon por la ignorancia

No se, yo iba a extraer el de revival pero me agarro una paja tremenda y termine dejandolo en la nada

^[GS]^ escribió:Y que ocurre cuando la encriptación da como resultado Char0, que es el carácter de fin de comando
Este es el problema de encriptar TODO... de manera dinámica el error del Char0 siempre estará presente tiene que ser una encriptación inteligente y selectiva.
Si manda 3 o 4 veces el mismo comando, se codifica diferente no?

uh no me percaté del vbnullchar, habría que analizar la cadena y procesarlo distinto , voy a ver como me las ingenio (no tube ningún error cuando lo probé, si alguno sabe cuando se genera el nullChar que me avise), por lo otro, si , siempre es distinto aunquesean 50 veces el mismo paquete.

(se ve en el ejemplo que envia M3 (mover direccion sur) 2 veces y son distintas)

Pato escribió:Es una verga el manejo de paquetes de versiones inferiores a la 12, en un corte patería a todos(Incluidos micro cortes client-side). Cada paquee en el cliente se encripta distinto, sin embargo si al servidor llegan 2 juntos se desencriptan iguales. Y la encriptación esa no alarga ningún paquete :p. Lo que tenés que hacer para procesar los paquetes es desencriptar, buscar el nullchar, copiar hasta ahi y procesarlo, después agarrás lo que te sobró y hacés lo mismo.

Acá lo codee, no testee nada así que no aseguro que funcione, pero estoy casi seguro de que si :p.

Mostrar Todo el Código | Numero de Linea | Ocultar/Mostrar | Seleccionar todo

1. Public Sub EventoSockRead(ByVal Slot As Integer, ByRef Datos As String)
2. #If UsarQueSocket = 1 Then
3. Dim packet As String
4. Dim pos As Integer
5. Dim originalData As String
6.  
7. originalData = UserList(Slot).RDBuffer & Datos
8.  
9. Do While LenB(originalData) > 0
10.     ' ########## Sumo el contador
11.     If UserList(Slot).flags.UserLogged Then
12.         UserList(Slot).security.Count = UserList(Slot).security.Count + 13
13.     End If
14.    
15.     ' ########## Desencripto!.
16.     Datos = UnEncryptStr(originalData, CStr(UserList(Slot).security.Count))
17.    
18.     pos = InStr(1, Datos, ENDC)
19.     If pos > 0 Then
20.         packet = mid$(Datos, 1, pos - 1)
21.        
22.         If UserList(Slot).ConnID <> -1 Then
23.             Call HandleData(Slot, packet)
24.         End If
25.        
26.         originalData = mid$(originalData, pos + 1)
27.     Else
28.         ' ########## El paquete no llego completo asi que restamos otra vez...
29.         If UserList(Slot).flags.UserLogged Then
30.             UserList(Slot).security.Count = UserList(Slot).security.Count - 13
31.         End If
32.        
33.         Exit Do
34.     End If
35. Loop
36.  
37. UserList(Slot).RDBuffer = originalData
38. #End If
39. End Sub

En el cliente resetea el packageCount cuando establés conexión, porque sino si relogueas se va a romper todo. En el cliente te recomiendo que en el sendData hagas if logged then packagecount=packagecount+1

Porque así como está creo que es re explosivo, jaja

concuerdo en varios puntos, sobre todo en el manejo de paquetes que es una mierda, en el setconnected abría que poner un packageCount = 0.

Luuq escribió:idem

Lekasak escribió:Un modulo del AODefender de Saturos no hacia esto?

la verdad no se como era por que cuando me lo quise bajar me tardaba horas y cancelé todo, esto lo hice yo y por lo que verán ni la encriptación codié por que eran las 5 am.

Mannakia escribió:If Encriptacion = 1 Then
Lag = Lag * 2
Cpu = Cpu - Lag
Else
Lag = Cpu
End If

Espero que lo entiendan y empiecen a ingeniar nuevas cosas

Saludos!

que flashaste? hace algún checkeo de cuanto sube el rendimiento del cpu y cuanto lag te puede causar esto, lag * 2????????????????????????

SaturoS escribió:

Lekasak escribió:Un modulo del AODefender de Saturos no hacia esto?

No, era más completo, encriptada server y cliente siempre distinto, pero como dice gs, tambien se fijada en el nullchar para no causar errores.

esto también es SIEMPRE DISTINTO, no veo la diferencia salvo el del caracter nullchar.

una pregunta para alguno , nullChar es el separator de > 12.x no ?

EDIT: Estube aproximadamente 30 minutos mandando comandos caminando , agarrando , equipando y hasta hora ningun error , voy a seguir a ver si sale el problema del nullchar

No miré mucho el code, pero si vos encriptas, mandás y después desencriptas y separas los paquetes no importa lo del NullChar.

EDIT: Lo que puede joder es cuando salen o recibe dos paquetes juntos creo .

El null char es simplemente 0 casteado a void*.
Hice una prueba de la funcion de encriptado y encripta bien de 0 a 255 siendo biyectiva, asique no deberías tener problemas si hiciste el resto bien.

Eso del ao defender no te lo bajes, directamente bajate server-cliente de revival dark dawn.

Y concuerdo que el manejo de paquetes es mucho mejor de 12.0 en adelante, hay que pulir mucho estas cosas en 11.5, es algo super importante a la hora de crear un ao...

Estube toqueteando algo el código y me dí cuenta que todos los paquetes tienen nullChar al final, hasta ahora no tiene problemas con todo lo que probé.

para buscar el nullchar usé esto por si alguien lo necesita.



con eso analize cada paquete y todos llevan nullChar al final.

Encontré un lindo error al apretar "lanzar" , se envian 2 paquetes juntos y manda cualquier gilada, ahora veo como lo arreglo.