Karpoff Spanish Tutor 1999-2002

Programa:

ExeScope 6.3


 

PROTECCION:

Serial

Descripcion:

Utilidad para manipular ejecutables y librerías con bastante facilidad (cuadros de diálogo, cadenas de texto...)

Dificultad:

Protozoo (algo así como 3º de la ESO)

DOWNLOAD:

http://karpoff.redfutura.net/

Herramientas:

Softice W32dasm Editor Hexadecimal

CRACKER:

MacEdu

  FECHA:

22/08/2002

 

 INTRODUCCION

 

  Érase una vez un niño que estaba muyyy aburrido de estudiar Campos Electromagnéticos II y decidió ponerse a hacer algo útil. Por ello se imprimió el documento “Descabezando archivos ejecutables portables” de nuMIT_or (el cuál recomiendo hasta al más pequeño de la familia) y se puso a leer. Cuál fue su sorpresa cuando de repente se recomendaba en dicho texto usar el programa ExeScope. Nada más fácil, buscas un poco por internet y lo bajas. Sin embargo tiene un problema, y es que no te deja realizar más de una modificación en el archivo que abras (compruébalo si no me crees) a no ser que estés registrado.

Solución A: Paga lo que toca y te registras.

Solución B: Utiliza lo que sepas y obtén una maravillosa prueba de evaluación “a tu gusto”, no sé, probarlo durante 70 años y si te convence, comprarlo. En resumen: Ke lo crackees, lexe, k pa eso estamos akí.

 

 AL ATAKE

 

Sin más rollo, vamos a lo que nos interesa. El archivo a elegir para monitorizar no tiene pega alguna ya que hay un archivo enorme (comparado con los demás archivos de este programa) que encima es el ejecutable. Pues nada, lo ejecutamos y todo perfecto hasta que tiramos a registrarnos (en el menú Help) y nos dice “Invalid ID or Name”. Maravilloso, un mensajito diciéndonos que nos hemos equivocado de clave.

En un primer momento la reacción es siempre la misma, irnos al desensamblador (yo he usado el W32Dasm) y buscamos esa cadena con la linternita o en String References. Mierda, la cadena no está, y encima sigo sin novia. Aunque no os lo creáis, la solución a lo primero es más sencilla que la de lo segundo. Dicen, que si todo falla, va siendo hora de que te leas las instrucciones, pero en nuestro caso es “Arranca el SoftICE”. Me encanta este programa, no sé por qué al tenerlo cargado el Kazaa no se me arranca, pero lo primero es lo primero (por cierto, si alguien sabe por qué, que me lo cuente).

 

Pues eso, cargamos el ExeScope con el Symbol Loader y ahora a pensar dónde ponemos el breakpoint. Lo suyo sería en el MessageBeep que debería haber saltado al meter la clave errónea, pero mira por dónde, al autor de ExeScope se le olvidó el detalle del pitidito. Sin desesperar, vamos al desensamblador y miramos las rutinas que carga. Vemos que de user32.dll usa LoadStringA, función que es muy probable que use para leer el nombre y la clave. Pues nada, una vez que ya tenemos arrancado el ExeScope, vamos al SoftICE y ponemos “bpx LoadStringA”. Pulsamos X para volver al programa, escribimos nuestro nombre y pass, le damos a OK y... BINGO, nos salta el SoftICE. Pensemos un poco. El cuadro de diálogo en el que estábamos era bien simple: 2 cuadros de texto, uno para el nombre y otro para la clave. Por ello, lo más probable es que primero se haga una llamada a LoadStringA para leer el nombre, y luego otra llamada a esa misma función para leer la clave. Por tanto, salimos del SoftICE pulsando Ctrl+D, y como era de esperar, nos vuelve a saltar el SoftICE en el otro LoadStringA. Vamos pulsando F10 para ir avanzando por el código y de repente, en la dirección 004587A5, nos salta la ventana de error que ya conocíamos. Pues nada, le damos a OK, con lo que volvemos al SoftICE y podemos ver lo que tenemos. Como ya he adelantado, lo que vemos es que en la dirección 004587A5 tenemos un CALL como una catedral a nuestro mensaje de error.

 

Ya parece que estamos situados en la parte del código que nos interesa. Pues nada, volvemos al desensamblador y vamos a esa dirección mediante “Goto Code Location”. Con ello nos situamos en la línea donde llamamos al cuadro de error, pero lo que nos interesa es no llegar ahí (porque eso ya es la rutina que nos avisa del error, y lo que queremos es llegar a donde decide que la clave es errónea), por lo que miramos varias líneas más arriba y vemos lo siguiente:

 La línea del asterisco nos indica que el programa salta a la dirección 004587A0 desde 00458790 y 00458794. Todos hemos visto las películas de Indiana Jones, lo que hace que nuestro espíritu aventurero nos obligue a ir a esas dos líneas a ver esos saltos de los que nos habla. Pues sí, vale, saltos al error, pero ninguno que salte fuera del error (con lo que saltaría a la parte del código que se ejecutaría en caso de que metiésemos la clave correcta). Pues akí la cosa está clara, seguimos mirando hacia arriba, y vemos que hay una referencia de un CALL.

Esto nos lleva a suponer que todo el código que hemos estado viendo es en sí la rutina de error, por que la comprobación de la clave ha de estar en otro punto del código que cuando detecta que no es correcta, salta aquí. Como es lógico, esa otra parte del código ha de estar en 0045871A. Nos vamos a esa línea y vemos lo siguiente:

De nuevo sin saltos. Sin embargo hay un par de referencias a esta función. Elegimos cualquiera de ellas (porque el que haya dos tan solo significa que en dos puntos del programa se comprueba la clave), por ejemplo 004A61F4 y llegamos a esto:

Como se puede apreciar, en 004A60F5 y en 004A61D7 hay saltos incondicionales que saltan la llamada a nuestra rutina de error (es decir, saltan a donde debería continuar el programa en caso de que acertásemos con la clave), por lo tanto ha de haber otros saltos que eviten estos y dejen que el programa llegue a la rutina de error. Como podemos ver en las referencias, estos saltos están en 004A6146 y en 004A615A.

Efectivamente, tenemos un JE y un JLE que nos hacen saltar a nuestra función de error. El primer salto que encontramos es el del JE, que por lo que veo, la rutina de comprobación se realiza mediante “CALL 004AE21C” y si devuelve el registro AL=0, salta a nuestra función de error. Después está el JLE, pero primero vamos a ver si parcheando tan solo este ya nos vale y si no, pues ya miraremos el otro. Recuerdo de nuevo que prefiero mirar el JE antes que el JLE porque es el primer salto al que llego (es decir, a ese voy a llegar siempre, mientras que al otro puede que llegue o puede que no). Pues dado que lo que necesitamos es que la llamada a la subrutina ubicada en 004AE21C nos devuelva AL distinto de cero, vamos a ver qué hay en esa subrutina. Así que nada, nos vamos a la línea de código 004AE21C. Vemos que hay bastante para leer en esa subrutina, pero a nosotros lo único que nos interesa es que nos devuelva AL distinto de cero. Por tanto, bajamos hasta encontrar su RET y vemos esto:

Muchos saltos, muchas instrucciones, ojos rasgados... pero el caso es que de todo, lo único que queremos es que nos devuelva AL con un valor distinto a cero. Sin embargo vemos una cosa curiosa, y es que antes del RET hay un CALL, no un montón de POPs que es lo que suele haber siempre. Por ello, se nos ocurre volver a tracear el ExeScope con el SoftICE poniendo un bpx en 004AE21C, es decir, en la llamada a la subrutina. Una vez nos salte el softICE en ese punto vamos traceando con F10 y cuál es nuestra sorpresa al comprobar que mediante algún chanchullo raro del CALL situado antes del RET, tras el RET no vuelve a la línea posterior a la llamada a 004AE21C, sino que continúa por 004AE2C5, código situado justo debajo de nuestro RET:

En 004AE2C5 vemos que se asigna a EAX el valor de EBX y que si seguimos traceando, el RET que hay cuatro líneas más abajo (en 004AE2CA) nos lleva a donde nos debía haber llevado el RET anterior.

Bien, pues tras nuestro paseo por la CALL 004AE21C, estamos ya donde nos interesa, en 004A6144, donde se comprueba que AL tenga un valor distinto de cero para así no saltar al error.

Ahora es cuestión de juntar las piezas, que son bastante pocas. El caso es que queremos que AL no valga cero. Eso lo queremos justo al volver del CALL que hay en 004A613F. Por tanto, lo lógico sería que antes del RET de ese CALL dejásemos de alguna forma a AL valiendo algo que no fuese cero. Sin embargo, hemos visto que no terminamos en el RET de ese CALL, que es el situado en 004AE2BD, sino que regresamos por el RET que hay en 004AE2CA justo después de asignar (en 004AE2C5) a EAX el valor de EBX. Por tanto, lo que se me ha ocurrido para poner a un valor distinto de cero el registro AL antes del RET de 004AE2CA es modificar:

004AE2C5     8BC3            mov eax, ebx

por:

004AE2C5     B001             mov al, 01

con lo que todos contentos. Vale, ahí queda nuestra hipótesis, que hay que probar, así que nada, a cogerse el editor hexadecimal que tengas más a mano (yo suelo usar el UltraEdit) y a cambiar ese código.

Bueno, sustituimos el 8BC3 por B001 y ejecutamos el ExeScope. Nos vamos a Help-Regist y mira por dónde, ahora nos aparecen asteriscos donde la clave y si ponemos un nombre nos lo acepta, pero al volver a intentar registrarnos vemos que nuestro nombre no aparece. Sin embargo lo que queríamos, que es poder realizar más de una modificación en los archivos que abramos, vemos que podemos hacerlo sin problemas. Qué ocurre aquí? Es acaso un Expediente X? De repente el programa se ha vuelto bueno y nos deja hacer lo que queramos? Quizá es que el fín del mundo está cerca? Que va, mucho más sencillo. Lo que ocurre es que no hemos reventado las comprobaciones tras la rutina de comprobación de la clave, sino que hemos reventado la rutina de comprobación de la clave en sí, es decir, dicha rutina siempre nos devuelve que tenemos una clave válida. Es por ello que al arrancar el programa, acude a la rutina de comprobación de la clave y directamente supone que tenemos una clave válida. En resumen: ExeScope 6.3 CRACKEADO!

Si por lo que sea, alguien quiere que al meterse en lo de registrarse le aparezca su nombre, basta con añadir en el archivo exescope.ini las siguientes líneas:

[Reg]

Name=MacEdu

sustituyendo “MacEdu” por el nombre que quiera.

Un detalle interesante es que en lugar de ver dónde acaba la rutina de comprobación y poner ahí que AL valga 1, podríamos haber cambiado directamente la llamada a la rutina de comprobación por la sentencia que pone AL a 1. Sin embargo, poniéndolo al final de la rutina y no en la llamada a la rutina, nos curamos en salud por si acaso en algún otro punto del programa se vuelve a llamar a dicha rutina que por tanto daría un AL=0, es decir, descubriría que nuestra clave es falsa.

Y con esto acabo mi maravilloso manual sobre el crackeo de este interesante programa. Si alguien tiene alguna duda, más abajo indico mi mail. Una última cosa que me gustaría comentar es que hay por ahí un manual sobre el crackeo de la versión 6.0 del ExeScope escrito por “Caos reptante” que en vez de ir a lo fácil como he hecho yo (es que soy más vago que mear sentao) que es directamente cargarte la rutina de comprobación, él hace un minucioso estudio del algoritmo de comprobación de claves obteniendo al final una fórmula que le da todas las claves correctas posibles (amos, que ha hecho lo que se debería hacer si quisieras hacer un KeyGen). La verdad es que está interesante. Es una lástima que en la versión 6.3 el algoritmo no sea exactamente igual que en la 6.0, porque siempre queda más curioso encontrar una clave correcta que reventar la protección, así que si alguien quiere estudiarse el algoritmo de la 6.3 para sacar sus claves, adelante.

Por último agradecer a mi gente (akél que piense que lo es, que imagine que se da por aludido) por aguantarme durante todos estos años, a Klod por enseñarme a tocar la guitarra, a Toni, y de nuevo a Klod, por esas fabulosas noches de pintas y mariscos, a mi abuela (k hace unos canelones...), a mi padre (que me aguanta aunque yo no razone), a mi hermano (aunque a veces hay que ver que pesao se pone....) y por supuesto a Karpoff, a Estado+Porcino, y todos aquellos que comparten sus conocimientos de forma desinteresada, sin cuya ayuda aún estaría creyéndome un genio por bajarme un crack de astalavista y crackear el mIRC.

 

Un saludo: MacEdu (yoga444@hotmail.com)

 

Karpoff Spanish Tutor: Pagina dedicada a la divulgacion de informacion en Castellano, sobre Ingenieria Inversa y Programacion. Email "Colabora con tus Proyectos"

 

www.000webhost.com