Mensajes

y recuerdo haber hecho uno en PDF sobre esto:
http://foro.elhacker.net/ingenieria_inversa/me_kedan_10_dias_o_no_se_si_devolverlo-t246629.0.html;msg1191695#msg1191695
Si lo encuentro te lo paso por privado.

Hola PeterPunk77, si lo encuentras me gustaria leerlo, me acuerdo que por falta de tiempo y de conocimientos  ) no terminé aquel tema de mochila y drivers de impresión, y me quedé con las ganas de ver el final del partido en el que ganastes por 1 a 0 

Muchisimas gracias, esto se era necesario desde hace un tiempo.

PD: En los casos de las versiones superiores, no quedaria mas q improvisar si no hay source superior al 1.4? Y si es asi... algun consejo para ello?

De antemano muchas gracias, se los agradezco

pues como parece que no hay source para versiones superiores, y crackeando en la forma que te pongo mas arriba en la version 1.4 si parece que funciona, pero haciendo lo mismo en las versiones superiores tenemos el problema de falta de memoria reservada, porque al cambiar el salto de lectura paraa cantidades superiores, resulta que la lectura de todos los cheat si se producen, pero a continuación da un error de lectura de memoria, porque no tendrá reservada la suficiente para dichos datos.
Asi que aprovechando el source de la versión 1.4, y el nuevo ejecutable compilado para 3000 cheat, si karmany aporta otra compilación con una cantidad distinta de cheat, podemos comparar ambos ejecutables creados con el mismo compilador, y creo se puede obtener las diferencias para la reserva de memoria suficiente en consonancia con el aumento del limite de los cheat.

Y despues con las versiones superiores es cuestion de buscar las referencias y probar hasta conseguir el objetivo.

PD. Buena idea LSL. El principal problema que veo es la reserva de memoria para los Cheats porque si se modifica los saltos es posible que pise zonas necesarias para otras cosas u otras variables.

es verdad, a veces puede ocurrir.  precisamente eso pasa en las versiones superiores.

se nota que no soy programador  , es cuestión de seguir aprendiendo a base de tropezones. 

en la version 1.4 el limite no esta en 500 cheat..., son 300 cheat, tal como se muestra en el codigo fuente puesto por karmany

Código [Seleccionar] Expandir

#define MaxCheats 300


partiendo de dicho dato, si cargamos el ejecutable en olly, y bucamos todas las constantes cuyo valor decimal es 300 (en hexadecimal 0000012C), encontramos varias comparaciones con dicho valor, si probamos a cambiar el valor 12C por el valor 3E8 (equivalente a 1000 en formato decimal), el emulador en la ventana Cheat nos muestra algunas mas que antes (las que no muestre puede ser problema de estar mal definida en el archivo Project64.cht, que ese ya es otro tema para los expertos).

algunas imagenes:

con limite en 300 cheat








con aumento de limites de cheat
 antes ->

Muchas gracias +NCR, la añado a herramientas favoritas.
Buen trabajo.

de nada.

Caso solucionado.

gracias Eraser, por el aporte.
ahí hay tema de estudio

cocoupn, tal como aconseja tena, que de esto sabe un montón, para no tener que meter un serial cada vez que inicias el programa, lo mejor es parchearlo para que no pida serial, y ahorras tiempo (siempre hay que ir a lo facil).

En este caso, según veo el serial se introduce solo con el fin de habilitar el botón "Aceptar", que te lleva al formulario de conexión. Y si solo se trata de habilitar dicho botón, se puede hacer simplemente con un editor de recursos, en este caso de "Visual Basic" que es el lenguaje en el que está programado.

si utilizas un editor de recursos como el VisualReformer, haces los cambios oportunos y luego comparas dos versiones del programa con el recurso del botón Aceptar "Habilitado" y "Deshabilitado", comprobarás que solo cambia un valor, que es el de la imagen de abajo, por lo que si no quieres hacer la modificación con el editor de recursos, lo puedes hacer con el ollydbg ó directamente con un editor hexadecimal, modificando dicho byt con el valor 00 por el valor FF, (ver imagen de abajo).



Tambien puedes saltarte el formulario de Autenticación e ir directamente al formulario de Conexión, cambiando el salto a la dirección 004286A0 por un salto a 004280E0, con esto ya te ahorras hasta pulsar en el botón aceptar.

En los programas en los que he conseguido hacerlos funcionar, lo que he hecho ha sido únicamente cambiar el salto condicional, en vez de entra en el call previo y cambiar el valor por "2" para que después la comparación sea la correcta. ¿Por qué tú has profundizado más para saber de dónde trae el valor?

a veces hay que profundizar en la raiz del valor para no tener que hacer o controlar muchas modificaciones, imaginate un programa en que para cada operación que va a realizar en otras partes del codigo compruebe este mismo valor y tome la decision de saltar o no, tendriamos que buscar y forzar muchos saltos, y si encontramos ese punto identico para todas las comprobaciones relacionada, nos ahorramos mucho trabajo.

Por ejemplo en tu programa cuando estas en el inicio del call donde se debe mover el valor 02 al registro EAX, en la ventana de información del desensamblado te informa que ese call se llama desde 2 lugares distintos, mira la imagen de abajo.



Entonces o cambias los 2 saltos que existiran despues de las 2 llamadas, o aqui fuerzas para que siempre mueva el valor correcto, y asi nos aseguramos que se llame desde donde se llame siempre va a dar el valor correcto, y con ellos nos aseguramos que las demas decisiones posteriores serán las correctas.
.............
En cuanto a la direccion de memoria de mi ordenador [011377F8] equivale en el tuyo a la de [00DE77F8], cuando pares con un breakpoint en 0062F3EA, en el Dump de la memoria tendras en 00DE77F9 el valor 02, y mira en ese momento que valor tienes en 00DE77F8, que tambien puede ser decisivo en otras partes del programa.

Seria interesante que mirases también dichos datos con la versión registrada, a ver que valores guarda en dichas direcciones y en la de [011377F8] que equivale a [EAX+388] que se me ha quedado la duda de para qué y cuando se utiliza posteriormente.

Saludos.