Emulacion de HASP4 Con El Nuevo Driver HASP HL Por Lionel

Descargar como doc, pdf o txt
Descargar como doc, pdf o txt
Está en la página 1de 33

CracksLatinoS!

2006

CracksLatinoS! 2006

-*Emulación de HASP4 con el nuevo


driver HASP HL*-

Programa Istram
Download
Descripción Emulación de mochila HASP
Herramientas OllyDbg v1.10, HASP Edit, Topo, PEditor 1.7
Dificultad No Informa
Compresor/Compilador
Protección Mochila HASP4
Objetivos Hacer funcionar el programa emulando la
mochila
Cracker Lionel Fecha: 31/08/06
Tutorial nº 4

-** Introduccion **-

Aquí estamos de nuevo para enfrentarnos a una mochila HASP. Esta vez parchearemos el
programa para emular su comportamiento. De nuevo disponemos de la mochila para ir
haciendo nuestras pruebas, con lo que todo será más fácil. Esta vez trataré de ser un poco más
claro a la hora de explicar los valores de entrada y retorno de las funciones HASP. Sin más
preámbulos vamos a ponernos a la faena.

-** Explorando el objetivo **-

Si arrancamos el programa sin tener la mochila puesta pasa un rato hasta que nos aparece la
siguiente ventana:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Vemos que ya nos anuncia que necesita una HASP.

No nos queda más remedio que apagar el programa, colocar la mochila a nuestra máquina, y
cargar el programa en Olly para ver cómo se comporta con la mochila puesta. Antes de
continuar tengo que decir que los datos de la HASP que aparecen en el tute están falseados
para proteger a quien me la prestó, he cogido datos al azar de la memoria del programa.

-** Buscando la rutina de acceso al HASP **-

Una vez colocado el dongle y cargado el programa en el Olly pulsamos RUN y vemos que corre
sin problemas:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006
Podemos olvidarnos pues de antidebug y centrarnos totalmente en la emulación de la mochila.
Primero que nada debemos localizar una zona en la que podamos colocar nuestro injerto. Para
ello utilizamos el topo, le introducimos el nombre de nuestro ejecutable:

Y nos dice que hay disponibles 4054 bytes. Esto es más que suficiente por lo que le decimos
que utilizaremos una sección existente manteniendo así invariable el tamaño del ejecutable:

Le decimos que queremos añadir 400 bytes:

Pulsamos Do It!:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Nos anuncia que ha dispuesta para nosotros 400 bytes en la dirección de memoria B8202A.
Guardaremos este dato para más adelante.

Ahora lo que tenemos que hacer es localizar donde se realizan las llamadas al HASP. Para
versiones anteriores del driver bastaba con buscar el comando “cmp bh, 32” pero si lo
hacemos no vamos a encontrar ninguna ocurrencia. Con en nuevo driver HASP HL el nuevo
patrón a buscar es el siguiente:

: 8B4528 mov eax,[ebp+28]


: 50 push eax ; EDX
: 8B4524 mov eax,[ebp+24]
: 50 push eax ; ECX
: 8B4520 mov eax,[ebp+20]
: 50 push eax ; EBX
: 8B451C mov eax,[ebp+1C]
: 50 push eax ; EAX
: 8B4518 mov eax,[ebp+18]
: 50 push eax ; Pwd2
: 8B4514 mov eax,[ebp+14]
: 50 push eax ; Pwd1
: 8B4510 mov eax,[ebp+10]
: 50 push eax
: 8B450C mov eax,[ebp+0C]
: 50 push eax
: 8B4508 mov eax,[ebp+08]
: 50 push eax ; Services
: E8D92E0000 call 010003FB3 ; Call _Hasp
: 83C424 add esp,024 ; Search pattern 83 C4 24 5F 5E
: 5F pop edi
: 5E pop esi
: 5B pop ebx

Con lo que lo que vamos a hacer es buscar la cadena binaria 83 C4 24 5F 5E:

Encuentra 7 u 8 cadenas iguales, pero si miramos arriba de la última que encuentra vemos
esto:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Que es lo que estábamos buscando. Ahora lo que haremos es poner un BP en B320FF, de


manera que en ese momento tendremos en la pila los parámetros utilizados por la mochila.

-** Servicio 1: IsHasp **-

Arrancamos el programa y enseguida salta el Olly en el BP que pusimos, la apariencia de la


pila y los registros es la siguiente:

Vemos pues que el primer argumento de la pila es el 1, estamos pues, según el manual del
HASP ante el servicio IsHasp:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

En nuestro caso Par1, Par2 y Par3 valen: 12FD44, 12FD48 y 12FD38 respectivamente y
LpNum vale 0 lo que quiere decir que buscará la mochila en todos los puertos.

Si pulsamos F8 veremos el retorno de la función en la pila y los registros:

En 12FD40 devuelve 1 ya que se ha encontrado una HASP.


En 12FD48 devuelve 0, que es el valor que pusimos como parámetro, por tanto sufre ninguna
variación.
En 12FD38 devuelve 0, ya que HaspStatus siempre es 0 cuando la operación se realiza con
éxito.

Además para todos los servicios del HASP:


En EAX se retorna el valor almacenado en la dirección a la que apunta Par3. En este caso en
12FD38 hay 00 00 00 00.
En EDX se devuelve el valor de Par4, que en este caso valía 12FD40
En ECX se retorna el valor almacenado en la dirección a la que apunta ahora EDX. En este
caso EDX ahora vale 12FD40, en esa dirección hay almacenado 0, por lo que en ECX se
devuelve un 0.

Vayamos ahora a la zona que habilitó el Topo y comencemos a escribir nuestro injerto:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Creo que con los comentarios el código está bastante claro.

El ADD ESP,4 sirve para dejar la pila como está después del CALL, ya que vamos a trabajar
con ella. Antes del ret final del injerto volveremos a dejar la pila como estaba haciendo:

SUB ESP, 4.

-** Servicio 5: HaspStatus **-

Recordemos que el programa está parado justo después de la primera llamada a la rutina
HASP. Pulsemos ahora F9 para ver a qué servicio llama a continuación:

Vemos pues que el primer argumento de la pila es el 5, estamos pues, según el manual del
HASP ante el servicio HaspStatus:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

En nuestro caso Par1, Par2, Par3 y Par4 valen: 12FD3C, 12FD48 12FD38 y 12FD40
respectivamente que será donde se recibirán los valores de retorno y LpNum vale 0 lo que
quiere decir que buscará la mochila en todos los puertos.

Por otro lado Password1 y Password2 valen: 0377 y 1D48. Vamos a ver si realmente esa es
nuestra mochila. Arrancamos el programa HaspEdit, elegimos crear sesión usando la llave
conectada:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006
Introducimos 887 y 7496 como contraseñas (valores en decimal):

Y nos dice que no hay una llave con esa contraseña conectada:

Así pues en esta ocasión la función no nos devolverá los valores correctos. Si pulsamos F8
corroboraremos lo que estamos diciendo:

En 12FD3C devuelve 0 ya que se ha encontrado una HASP.


En 12FD48 devuelve 0, ya que se ha encontrado una HASP.
En 12FD38 devuelve 0, ya que se ha encontrado una HASP.
En 12FD40 devuelve 1F40, que es la versión del driver.

Además ya vimos que para todos los servicios del HASP:


En EAX se retorna el valor almacenado en la dirección a la que apunta Par3. En este caso en
12FD38 hay 00 00 00 00.
En EDX se devuelve el valor de Par4, que en este caso valía 12FD40
En ECX se retorna el valor almacenado en la dirección a la que apunta ahora EDX. En este
caso EDX ahora vale 12FD40, en esa dirección hay almacenado 1F40 por lo que en ECX se
devuelve 1F40.

Pulsemos F9 para que el programa continúe con la ejecución y ver si ahora para con la
contraseña correcta. Al parar de nuevo en el BP, la pila y los registros están así:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Podemos ver ahora en la pila que Pw1 y Pw2 valen ahora 1625 y 79F6. Si probamos ahora
estos valores en HaspEdit, podremos entrar y acceder a la memoria de la mochila:

Si pulsamos F8 ahora veremos los valores de retorno de la función:

En 12FD3C devuelve 1 ya que se ha encontrado una HASP4 M1.


En 12FD48 devuelve 1, ya que se ha encontrado una HASP4 M1.
En 12FD38 devuelve 66, que es el puerto al que está conectada la mochila.
En 12FD40 devuelve 1F40, que es la versión del driver.

Además ya vimos que para todos los servicios del HASP:


En EAX se retorna el valor almacenado en la dirección a la que apunta Par3. En este caso en
12FD38 hay 00 00 00 66.
En EDX se devuelve el valor de Par4, que en este caso valía 12FD40
En ECX se retorna el valor almacenado en la dirección a la que apunta ahora EDX. En este
caso EDX ahora vale 12FD40, en esa dirección hay almacenado 1F40 por lo que en ECX se
devuelve 1F40.

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006
Con esto podemos seguir escribiendo nuestro injerto:

-** Servicio 6: HaspID **-

Si ahora pulsamos RUN para de nuevo en el servicio 1 y después 2 veces más en el servicio 5,
pero como ya los tenemos emulados pulsamos RUN cada vez hasta que para en el BP pero
esta vez llamando al servicio 6:

Si vamos a la documentación de que disponemos:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

En nuestro caso Par1, Par2 y Par3 valen: 12FD40, 12FD3C y 12FD44 respectivamente que
será donde se recibirán los valores de retorno y LpNum vale 0 lo que quiere decir que buscará
la mochila en todos los puertos.

Por otro lado Password1 y Password2 valen: 1625 y 79F6 que ya vimos que son los Password
de nuestra mochila.

Lo que obtenemos en la pila y registros tras pulsar F8 es lo siguiente:

En 12FD40 devuelve 8D73 que es el IDLow.

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006
En 12FD3C devuelve 0E5B que es el IDHigh, por lo tanto el ID de la mochila es E5B8D73 que
en decimal vale 240881011.
En 12FD44 devuelve 0, que es el HaspStatus cuando todo ha ido de manera correcta.

Además ya vimos que para todos los servicios del HASP:


En EAX se retorna el valor almacenado en la dirección a la que apunta Par3. En este caso en
12FD38 hay 00 00 00 00.
En EDX se devuelve el valor de Par4, que en este caso valía 12FD40
En ECX se retorna el valor almacenado en la dirección a la que apunta ahora EDX. En este
caso EDX ahora vale 12FD40, en esa dirección hay almacenado 1 por lo que en ECX se
devuelve 1.

Con lo que el injerto podría quedar de la siguiente forma:

-** Servicio 3: ReadWord **-

Si ahora pulsamos RUN para de nuevo en el servicio 1 y después 2 veces más en el servicio 5,
y otra vez en el 6, pero como ya los tenemos emulados pulsamos RUN cada vez hasta que
para en el BP pero esta vez llamando al servicio 3:

Veamos qué nos dice el manual de HASP:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

En nuestro caso Par1, Par2 y Par3 valen: 10ED30, 2C61BF8 y 10ED14 respectivamente.
Vemos que en Par1 está almacenado el valor 35 que será la posición de la memoria HASP que
leerá esta función. En 2C61BF8 almacenará el Word que lea de la memoria y en Par3
devolverá el valor de HaspStatus que cuando la función se realiza con éxito siempre vale 0.
LpNum vale 0 lo que quiere decir que buscará la mochila en todos los puertos.

Por otro lado Password1 y Password2 valen: 1625 y 79F6 que ya vimos que son los Password
de nuestra mochila.

Así si pulsamos F8 podremos confirmar estos valores de retorno:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Vemos que en Par2 (2C61BF8) ha guardado el valor que había en la posición 35 de la memoria
HASP. Recordemos que lo vimos antes:

En Par3 (10ED14) ha devuelto el valor 0 correspondiente a HaspStatus indicando que todo ha


funcionado correctamente.

Además ya vimos que para todos los servicios del HASP:


En EAX se retorna el valor almacenado en la dirección a la que apunta Par3. En este caso en
10ED14 hay 00 00 00 00.
En EDX se devuelve el valor de Par4, que en este caso valía 10ED18
En ECX se retorna el valor almacenado en la dirección a la que apunta ahora EDX. En este
caso EDX ahora vale 12ED18, en esa dirección hay almacenado 10EF31 por lo que en ECX se
devuelve 10EF31.

Ahora ya podemos seguir escribiendo el injerto. Para simular el contenido del HASP vamos a
rellenar una zona de memoria vacía con los valores de la mochila y de ahí será de donde leerá
el injerto. Esta zona la crearemos a partir de la dirección B82160 y la rellenaremos con los
valores que vemos en la imagen de arriba:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Podemos ahora seguir escribiendo el injerto:

-** Servicio 4: WriteWord **-

Si pulsamos F9 para 4 ó 5 veces más en el servicio 3 pero para leer otras posiciones de
memoria, en concreto la 36, 34, 37 y 30. La siguiente vez que para lo hace en el servicio 4
(WriteWord):

Veamos qué nos cuentan de esta función:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Vemos que el valor almacenado en la dirección a la que apunta Par1 es 36, que será la
posición de la memoria HASP en la que se escribirá el Word almacenado en Par2 (que en este
caso vale 3D60). En Par3 devolverá el valor de HaspStatus que cuando la función se realiza
con éxito siempre vale 0. LpNum vale 0 lo que quiere decir que buscará la mochila en todos los
puertos.

Pulsemos ahora F8 y obtenemos:

En Par3 (10ED18) ha devuelto el valor 0 correspondiente a HaspStatus indicando que todo ha


funcionado correctamente.

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006
Y podemos ver que efectivamente ha escrito 3D60 en la posición 36 de la memoria HASP:

Además ya vimos que para todos los servicios del HASP:


En EAX se retorna el valor almacenado en la dirección a la que apunta Par3. En este caso en
10ED18 hay 00 00 00 00.
En EDX se devuelve el valor de Par4, que en este caso valía 10ED14
En ECX se retorna el valor almacenado en la dirección a la que apunta ahora EDX. En este
caso EDX ahora vale 12ED14, en esa dirección hay almacenado 0 por lo que en ECX se
devuelve 0.

Esta vez con nuestro injerto en lugar de escribir en la memoria HASP escribiremos en la
posición correspondiente de la zona de memoria que creamos antes a partir de B82160. Así
pues podriamos programarlo así:

Si pulsamos F9 ahora vemos que vuelve a parar en servicios que ya hemos visto, así que
seguiremos dando RUN hasta que finalmente el programa arranca.

-** Probando el injerto **-

Es el momento de probar si el injerto efectivamente funciona. Para ello debemos cambiar el


CALL que llama a la rutina HASP a la dirección donde hemos colocado el injerto:

Debemos cambiarlo a:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Es momento de copiar al ejecutable todas las modificaciones que hemos hecho que son toda la
zona del injerto y de la zona de memoria creada (desde B82020 hasta B821D0), y el cambio en
el CALL que está en B320FF. Lo guardaremos todo en un archivo que llamaremos
istrammod.exe.

Ahora solo queda cargar en el Olly nuestro archivo istrammod.exe. No es necesario que
retiremos la pastilla, ya que ahora el programa no va a acceder a ella, siempre irá a nuestro
injerto.

Una vez cargado pulsamos F9 para que arranque y el programa debería arrancar, pero Olly
para por un error de escritura:

El programa aparece parado en la posición B82139, justo cuando en el servicio 4 (WriteWord)


trata de guardar los datos en la zona de memoria que hemos creado simulando la de la pastilla
de protección:

El origen de este error es fácil de ver. Si cogemos el PE Editor, y cargamos nuestro istrammod:

Elegimos la opción sections:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Ahora pulsamos sobre la seccion donde creamos el injerto con el botón derecho:

Elegimos Edit section, y nos aparece la siguiente ventana:

Si elegimos char. Wizard:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Podemos ver que la sección no es writeable. Así que marcamos esa opción (el valor de
características pasa a valer E0000020), y salvamos los cambios con take it:

Y después de dar apply changes en la ventana siguiente nos avisa de que los cambios han
sido realizados:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Ahora salimos de PEditor y volvemos a cargar istrammod en Olly, arrancamos y:

Cuando estaba convencido de todo iba a ir bien vemos que no arranca el programa, nos da un
informe de error de seguridad. Parece que nuestro trabajo todavía no ha terminado. Pero no es
momento de tirar la toalla ahora. Tratemos de averiguar qué es lo que está ocurriendo.

-** Buscando el origen del error **-

¿Qué es lo que está pasando?. Después de darle vueltas y vueltas se me ocurrieron varias
opciones:

1) El injerto no emula la pastilla correctamente. Después de probar varias veces deseché esta
posibilidad ya que los valores que retorna son exactamente iguales que los de la mochila.

2) El programa detecta que se ha modificado. También lo deseché colocando un Memory


Breakpoint on Read en la zona del injerto y solamente para en ese BP por “execution” y no por
“read”.

3) Además de escribir datos en la pastilla por medio del servicio WriteWord, también escribe
datos en el registro o en algún archivo de manera que al leerlos posteriormente pueda detectar
algún tipo de manipulación. Esta parecía la explicación más coherente. Además confirmé esto
cuando arranqué el programa original sin modificar y con la mochila puesta y me dio el mismo
informe de error, cuando la primera vez había arrancado sin problemas.

Como ahora tenemos un programa que no funciona ni con mochila lo que tenemos que hacer
es tratar de hacer que funcione de nuevo. Para ello no se me ocurrió otra solución que
desinstalar todo el programa (haciendo antes una copia del archivo istrammod.exe) y volverlo a
instalar. Volví a arrancarlo con la mochila puesta y ahora sí que funciona de nuevo. Más
adelante veremos que no es necesario desinstalar todo el programa para que vuelva a
funcionar, basta con borrar un archivo y todo volverá a la normalidad.

Así pues tenemos el programa instalado de nuevo, cargado en Olly y con la mochila puesta.
Vamos a comprobar primero si escribe algo en el registro que nos pueda parecer relevante.

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006
Ponemos BP en RegOpenKeyA, pero no parece que escriba nada que pueda parecer
sospechoso. Así que quitamos esos BP y ahora ponemos un BP en WriteFile.

Vemos que el primer parámetro es el handle del archivo al que va a escribir. Eso es lo que nos
interesa. En mi máquina esta API está en la dirección 7C810D87 en la vuestra puede ser otra.
Vamos a poner ahí un Conditional Log Breakpoint para que nos logee el handle del archivo en
que está escribiendo:

Damos RUN, el programa arranca correctamente, y una vez que ha arrancado lo cerramos, así
veremos los archivos que escribe tanto en el arranque como en el cierre del programa. Si ahora
vamos a la ventana del log:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Podemos ver que escribe muchas veces en el archivo que tiene por Handle el 7, sin embargo,
si busco este valor en la ventana de Handles, no aparece. Gracias a la ayuda de Ricardo en la
lista pude ver después que ese handle se obtiene tras una llamada a GetStdHandle y que sirve
ara escribir y leer datos de la consola, por lo que nos olvidaremos de las llamadas a WriteFile
con este handle.

Así que reiniciamos el programa y ahora colocamos el Contitional Log BreakPoint como sigue
para que no pare cuando va a escribir en el proceso con handle = 7:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006
Si ponemos ahora el programa a correr para en el BP con los parámetros de la API como
sigue:

En la ventana Handles del Olly vamos a ver a qué archivo corresponde BC:

Vemos que va a escribir datos en el archivo lang.bin. Si vamos 0DF849A0 veremos los 20
bytes que la API escribirá en ese archivo:

Además ocurre que cada vez que se ejecuta el programa escribe datos distintos en ese
archivo. Esto es muy sospechoso, y empiezo a pensar que le han puesto ese nombre y en ese
directorio para despistar. Pero creo que los hemos pillado. Ahora creo que tengo la clave de por
qué no funciona el archivo injertado.

Cuando el programa funciona con la pastilla el servicio ReadWord escribe datos en la memoria
de la mochila, y también en el archivo lang.bin. En la siguiente ejecución comprueba que tras
desencriptar el contenido de lang.bin, este se corresponde con el contenido de la pastilla, si
esto no es así dará un error.
El problema es que cuando ejecutamos el programa con el injerto, éste escribe los datos del
servicio 4 (WriteWord) en la memoria del programa, por lo que cada vez que ejecutamos el
programa injertado, los datos que lee de la memoria son siempre los mismos.

Para evitar esto se me ocurren 2 soluciones:

1) Que el injerto escriba los datos del servicio 4 en istrammod.exe mediante la API
WriteFile, de esta manera en cada ejecución partiríamos con los datos de la mochila
actualizados. Esta sería la solución más elegante. Sin embargo tiene un inconveniente.
Me contó un usuario del programa que cuando éste se ejecuta un número determinado
de veces nos pide una clave para poder seguir ejecutándolo. Yo no he sido capaz de
encontrar esa zona caliente, por lo que descartaremos esa opción.
2) Que no se actualice el archivo lang.bin, de esta manera, y dado que la memoria del
HASP simulado tampoco se actualiza el programa creerá que no se ha ejecutado, por
lo que nunca nos pedirá la clave antes mencionada. Esto va a ser lo que haremos.

Para ello reiniciemos istrammod.exe y pongamos un BP en B76C6A que es donde se produce


la llamada a WriteFile cuando va a escribir en lang.bin:

Pulsamos F9 y el Olly salta al llegar a esa posición. Vemos en la pila que se dispone a escribir
los 20 bytes en el archivo:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Lo que haremos es cambiar el 20 por un 0, para que no escriba nada:

Y POR FIN el programa arranca tras parar un par de veces más en el BP que pusimos aunque
esta vez para escribir en otros archivos. Sólo nos falta pues que nuestro injerto arregle este
problemilla.

-** Parcheando la llamada a WriteFile **-

Hemos visto que lo que hay que hacer es que cuando WriteFile vaya a escribir en lang.bin
hacer que en lugar de escribir 20 bytes, escriba 0 bytes. La única dificultad es que el programa
pasa por B76C6A para escribir no sólo en lang.bin, sino también para escribir en otros archivos:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006
Lo que haremos para que pase 0 como parámetro sólo cuando vaya a escribir en lang.bin y no
en otros será comprobar que el valor del buffer sea DF849E8 y que el número de bytes a
escribir sea 20.

Así el injerto quedará:

Solo falta cambiar el push [EBP+3B0]:

Por un salto a la zona del injerto que hemos creado:

Copiamos todos los cambios al ejecutable y:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

El programa funciona correctamente.

-** Rematando la faena **-

Bien, ya lo hemos hecho funcionar, pero hay 2 pequeños detalles que se me clavan.

Por qué no cambiar el nombre que aparece en propietario por CracksLatinos, por ejemplo?.
Además vemos que no disponemos de licencia para Fotorrealismo ni Información Geográfica.

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006
Para esto lo primero que hice fue preguntarme ¿Cómo narices sabe que el propietario de la
licencia es APINSA? Si en el proceso de instalación no pide ni un solo dato. La respuesta se
me ocurrió enseguida: La mochila.

Lo que hice fue, con el programa injertado ya funcionando, fui al mapa de memoria y busqué la
cadena “APINSA”:

Apareció aquí junto con una serie de nombres más y todos con la misma estructura (Nombre,
Procesador, Sistema Operativo, número de 10 cifras). No aparece ese nombre en más
ocasiones, ni siquiera en la zona del programa. Así que anoto la dirección 115FF9, reinicio y
trato de poner un memory BP on Write, para ver cuando escribe el nombre en esa posición,
pero resulta que en el arranque todavía no existe esa posición de memoria. Traceando, ví que
esa zona se creaba en el CALL que hay en 5167E5:

Así que lo pasamos con F8 y ya podemos colocar el Memory Breakpoint on Write en 115FF9.
Damos RUN y el programa para en 516835, un poco más abajo del CALL anterior:

Si traceamos con F8 vemos que va desencriptando los nombres a partir de una sección del
ejecutable, además si seguimos traceando, antes de terminar ese ciclo del bucle desencripta
en otra zona de memoria el siguiente número:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Que después me daría cuenta que coincide con el HaspID de la mochila en decimal.

Así cuando sale del bucle en 5168E3, están desencriptados todos los nombres y lo que parece
todos los HaspID a que corresponden esos nombres.

Si ahora pongo un Hardware BP on acces tanto en la zona del número desencriptado


(10EFAD) y otro en la zona del nombre desencriptado (115FF9) y quito el memory BP que
había puesto. Al dar F9 Olly parará aquí.

Estamos en medio de una rutina que es llamada desde 516981:

Cuando llega a 5169A3 tiene en ESI almacenado el número de licencia, que en la pantalla de la
consola vimos que era 39. y en base a este número es cuando localiza el nombre asociado en
las siguientes líneas y lo escribe en la consola.

Resumiendo, lo que hace es hallar el HaspID de la mochila mediante el servicio 6, y en base a


eso obtiene el nombre del propietario de la licencia. Lo que haremos será una vez que ha
desencriptado los nombres y HaspID en la memoria, insertaremos un HaspID nuevo que nos
inventaremos entonces veremos a qué zona de memoria va a buscar el nombre del propietario
de la licencia y allí escribiremos el nombre que queremos que aparezca. Antes tendremos que
modificar el injerto para que emulemos una mochila con ese HaspID:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Hemos inventado un HaspID= 1234567890d = 4996 02D2h

Así que copiamos los cambios al ejecutable, reiniciamos y quitamos todos los BP y ponemos
uno en 5168E3. Damos RUN y cuando para vamos a la zona donde desencriptó los números y
buscamos un lugar vacío:

Y lo cambiamos por el número del HaspID que hemos puesto en el injerto pero ahora en
decimal:

Ponemos otro BP en 5169A3 y cuando para traceamos hasta llegar a 5169B2:

En ese punto va a pasar a BL el byte bao de la dirección en la que debería estar el nombre del
propietario de la licencia que en este caso es 118E00:

Vemos que efectivamente en esa posición también hay un espacio con guiones:

Así que lo rellenamos de la siguiente forma, siempre respetando la posición de las cadenas
“PENTIUM” “WINXX” y la cadena de números (lo mejor es hacer un bynary paste de cualquier
otro texto y editarlo).

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Pulsamos RUN y el programa arranca correctamente, además podemos ver que ya tenemos el
nombre que queriamos:

Nos falta solucionar el problema de las licencias, pero si nos damos cuenta, los 3 primeros
módulos tienen licencia, y se corresponden con los 3 primeros “1” que hay en el número que
hay después de “WINXX”:

Si reiniciamos, repetimos los pasos anteriores y al llegar aquí ponemos:

Veremos nuestro objetivo cumplido:

Para conseguir que el injerto haga esto pondremos habrá que hacer un jmp a nuestro injerto
justo después que se haya desencriptado todo:

www.crackslatinos.hispadominio.net
CracksLatinoS! 2006

Cambiamos el mov dword [3FB54F0] por el jmp:

Y ahí programaremos nuestro injerto:

Previamente habremos guardado en B82250 la cadena “1234567890” y en B82260


“CRACKSLATINOS PENTIUM WINXX 1111100090”:

Si guardamos todos los cambios, el programa ya funciona correctamente con todas las
opciones activadas.

Ha costado, pero al fin se acabó.

-** Saludos y/o Agradecimientos **-

Por supuesto desde aquí quiero saludar a toda la lista de CracksLatinos sin cuya ayuda no
hubiera podido escribir ni una sola línea, y por supuesto a los tutes de Ricardo sobre esta
mochila que me ayudaron mucho.

Espero que se haya entendido algo, y que esto sirva al menos a una persona a enfrentarse a
este nuevo driver para la mochila HASP.

Yo voy a descansar un poco, ya que aunque esto pueda leerse más o menos rápido a mí me
costó más de una semana conseguir destripar todo el programa, pero el resultado creo que ha
merecido la pena, ya que hemos visto todos los entresijos de la protección, que es de lo que se
trata.

Por supuesto, tengo que decir que este documento se ha hecho para fines puramente
educativos, no me hago responsable del mal uso que de él pueda hacerse.

www.crackslatinos.hispadominio.net

También podría gustarte