Autor
|
Tema: [TUTORIAL]Creación de trainers con OllyDBG y Cheat engine (Leído 62,204 veces)
|
[NelSito*]
Desconectado
Mensajes: 12
|
Sinceramente es muy bueno el conocimiento compartido, pero si me permites yo tambien hare una publicacion del hacking para juegos online sobre hallar pointers & offsets, simplemente usare CheatEngine & MHS5.
Muy buen tutorial.
|
|
|
En línea
|
|
|
|
|
Wildseba
Desconectado
Mensajes: 40
|
Saludos .:UND3R:. , queria decirte que el trainer no lo puedo abrir porque se subio mal, por favor arregla el problema.
Saludos
|
|
|
En línea
|
|
|
|
.:UND3R:.
|
Gracias por el LINK lo agrego al post y resubo el trainer saludos EDIT:aquí el trainer resubido http://www.mediafire.com/?s1uw3hkpc2fisai
|
|
« Última modificación: 25 Octubre 2011, 02:24 am por .:UND3R:. »
|
En línea
|
Solicitudes de crack, keygen, serial solo a través de mensajes privados (PM)
|
|
|
isidora
Desconectado
Mensajes: 8
|
Muy buen tutorial, explica claramente. Agrego que con CE también es posible realizar una inyección de código sin necesidad de utilizar OllyDBG, una vez que tengamos el valor de las vidas en la lista, presionamos con el secundario sobre el valor y buscamos la opción “Find out what accesses this address”, los mostrara al igual que OllyDBG una lista con las direcciones que acceden al valor.
|
|
|
En línea
|
|
|
|
.:UND3R:.
|
Muy buen tutorial, explica claramente. Agrego que con CE también es posible realizar una inyección de código sin necesidad de utilizar OllyDBG, una vez que tengamos el valor de las vidas en la lista, presionamos con el secundario sobre el valor y buscamos la opción “Find out what accesses this address”, los mostrara al igual que OllyDBG una lista con las direcciones que acceden al valor.
efectivamente pero preferí realizarlo de manera más manual pero más segura. Saludos
|
|
|
En línea
|
Solicitudes de crack, keygen, serial solo a través de mensajes privados (PM)
|
|
|
$Edu$
Desconectado
Mensajes: 1.842
|
Ya entendi el tutorial y todo lo que me explicaste por privado UND3R los otros dias. Pero como siempre tengo otras dudas mas especificas que la puede contestar el que sepa, no necesariamente vos.
La duda es.. que el trainer lo que hace es modificar esta address ahora: 0041E844 , la de la instruccion, para cambiarla por otra instruccion que quieramos, en este caso solo la invertimos. Pero esa address porque no cambia nunca? asi como cambiaba la address del valor. Es porque una address esta dentro del ejecutable y la otra fuera? o que?
Es decir.. vieron como lo del funcionamiento de la IAT? algo asi se hace para que siempre que leamos la direccion 0041E844 en realidad estamos leyendo otra en la memoria RAM?
Otro ejemplo seria de que la mayoria de los programas empiezan en su OEP en el address 00401000, pero no esta haciendo referencia a la memoria RAM porque sino cuando cargo 2 programas en el Olly me dicen q los 2 empiezan en esa address, cosa q no seria posible..
Espero que alguien me entienda xD
Iba a crear un tema a parte sobre esto pero si pueden contestarme aca le queda la respuesta a otro que venga por este tema..
Yo he leido sobre esto pero no he entendido bien aun lo que es la ImageBase y que es un Offset, no llego a entenderlo bien aun, me cuesta horrores esto jaja.
|
|
|
En línea
|
|
|
|
Иōҳ
Desconectado
Mensajes: 563
|
Hola Edu, haber si te resuelvo las dudas.... La duda es.. que el trainer lo que hace es modificar esta address ahora: 0041E844 , la de la instruccion, para cambiarla por otra instruccion que quieramos, en este caso solo la invertimos. Pero esa address porque no cambia nunca? asi como cambiaba la address del valor. Es porque una address esta dentro del ejecutable y la otra fuera? o que?
Es decir.. vieron como lo del funcionamiento de la IAT? algo asi se hace para que siempre que leamos la direccion 0041E844 en realidad estamos leyendo otra en la memoria RAM?
Eso depende si la dirección que haces referencia es una estática o dinámica, si es dinámica necesitas encontrar el BasePointer que hace referencia a tu address dinámica, en ocasiones pueden haber muchos punteros de punteros, o multilevelpointer como lo llama el CheatEngine (buen nombre por cierto). Como sabes que es estática o no?, pues mi experiencia en el gamehacking de hace años (estoy en retiro momentaneo del gamehacking ojo! xD) me dice que todo esto depende, primero el game usa librerías, entonces como se cargan estas librerías?, cuál es la ImageBase de ellas?, aveces son programas de tal manera que la ImageBase sea fija y así al cargarlas las direcciones de esa librearía sean estáticas. Ejemplo: DLL1 ImageBase = 03500000h DLL2 ImageBase = 03600000h DLL3 ImageBase = 03700000h . . . DLLn ImageBase = 0XX00000h Pero no siempre se cumple, entonces en ese casi las direcciones serían "dinámicas". Es algo que se crea en juego?, un stage o una misión por ejemplo?, pues es dinámica en la gran mayoría de los casos pero como siempre puede haber excepciones. Otro ejemplo seria de que la mayoria de los programas empiezan en su OEP en el address 00401000, pero no esta haciendo referencia a la memoria RAM porque sino cuando cargo 2 programas en el Olly me dicen q los 2 empiezan en esa address, cosa q no seria posible..
Nop, en los sistemas de 32 bits hay 4gb de direccionamiento en MEMORIA (ojo, no significa que ese sea su peso en disco), 2gb asignados a usermode, y los otros 2gb a kernel, cada proceso tiene un ÚNICO espacio de memoria, un ejemplo es que en memoria de tu target en la dirección ficticia 0B4DC0D3h tienes la vida de tu personaje, en tu trainer NO puedes hacer esto mov [0B4DC0D3h] , -1 Por que estás haciendo refencia a tu trainer no al target. Recuerda que el modelo de memoria NO es FLAT, como en ms-dos. Saludos, Nox.
|
|
« Última modificación: 19 Mayo 2012, 05:47 am por Иōҳ »
|
En línea
|
|
|
|
$Edu$
Desconectado
Mensajes: 1.842
|
Creo que le has dado en tu ultima frase "Recuerda que el modelo de memoria NO es FLAT, como en ms-dos". Lo demas no lo entendi bien pero es algo que aprendere luego, yo por ahora quiero saber lo basico basico y con tu frase me hizo pensar distinto sobre la RAM.
A ver, ya vengo voy a ver el libro que estoy leyendo como es que dice algo ahi...xD ya vine jajajaja, no entiendo bien lo que pasa. Pero pone la RAM como un edificio y cada piso tiene una altura, lo que seria el tamaño u offset. Algo asi:
RAM
FFFF
2000
1000
0000
Yo entiendo a la RAM como eso, como un edificio empezando desde la address 0000 hasta FFFF por ejemplo, entonces pienso que cada programa se carga en el lugar que entre, que no este ocupado, por ejemplo a partir del address 2000, y entonces pensaba que esa tendria que ser la ImageBase y luego entonces cuando en ese programa cargado se ve en el olly algo como:
2100 Add BX... 2200 MOV ...
En el medio de 2100 y 2200 estan los offsets, que serian los que se muestran en el Dump por columnas.
Pero se arruina todo lo que pensaba, al ver que la mayoria de los programas tienen la misma ImageBase, por lo que entonces no se cumple lo que digo, porque significaria que cargan en la misma direccion de la RAM y no se puede...
Pero.. tal vez eso de que la memoria RAM no es FLAT, quiere decir que no es asi como tenia pensado que era y entonces espero que me puedan explicar, asi de la misma forma que intente yo recien, solo que esta bien me diran como es de verdad xD
|
|
|
En línea
|
|
|
|
Иōҳ
Desconectado
Mensajes: 563
|
Creo que aquí está tu respuesta: Nop, en los sistemas de 32 bits hay 4gb de direccionamiento en MEMORIA (ojo, no significa que ese sea su peso en disco), 2gb asignados a usermode, y los otros 2gb a kernel, cada proceso tiene un ÚNICO espacio de memoria, un ejemplo es que en memoria de tu target en la dirección ficticia 0B4DC0D3h tienes la vida de tu personaje, en tu trainer NO puedes hacer esto
mov [0B4DC0D3h] , -1
Por que estás haciendo refencia a tu trainer no al target.
Recuerda que el modelo de memoria NO es FLAT, como en ms-dos.
Si no entiendes alguna parte dímelo y te lo explico mejor, el libro que estás leyendo cuando fue editado? no será en sistemas de 16bits? cuando el modelo de memoria ERA FLAT? Saludos, Nox.
|
|
|
En línea
|
|
|
|
|
Mensajes similares |
|
Asunto |
Iniciado por |
Respuestas |
Vistas |
Último mensaje |
|
|
[Tutorial] Usar Cheat Engine para modificar juegos + inyección de código
« 1 2 ... 28 29 »
Ingeniería Inversa
|
Mad Antrax
|
285
|
428,545
|
23 Mayo 2021, 05:02 am
por Dark Lesser
|
|
|
[Videotutoriales] Hacking de juegos (Online/Local, Cheat Engine, OllyDbg...)
« 1 2 ... 6 7 »
Ingeniería Inversa
|
blipi
|
64
|
84,722
|
21 Febrero 2016, 18:55 pm
por blipi
|
|
|
¿Cheat Engine o Ollydbg?
Ingeniería Inversa
|
Meta
|
5
|
5,798
|
25 Marzo 2014, 12:50 pm
por Shaddy
|
|
|
[TUTORIAL] Cheat Engine nivel avanzado. Tutorial completo
« 1 2 ... 7 8 »
Ingeniería Inversa
|
Mad Antrax
|
74
|
116,537
|
23 Mayo 2022, 05:27 am
por enthimir
|
|
|
[Tutorial] Inyección de código en C++, Cheat Engine y OllyDBG
Ingeniería Inversa
|
Carlos D. Alvarez
|
3
|
5,640
|
13 Noviembre 2015, 16:03 pm
por Kaxperday
|
|