En fin, manos a la obra. Tras descargar el programa de la web de Allaire
o buscarlo en los CD que haya por casa ( mi versión la saqué
del CD Shareware que venía en Pc Actual de Abril de 2000) lo instalamos,
vemos cómo funciona y lo que trae de protección: en principio
nada del otro mundo, un par de nags amarillas con una cuenta atrás
de los días que quedan para que caduque y poco más. Adelantamos
el reloj 60 días y es cuando aparece la ventana que nos dice que
seguir usándolo violaría el contrato de licencia. Ok, tres
nags que hay que eliminar.
PRIMER PROBLEMA:
Vamos a echarle un vistazo al código. Cargamos el W32Dasm,
abrimos homesite45.exe y la hemos cagao, se queda colgado y no sale nada.
Seguimos como al principio. Con el W32Dasm no podemos hacer nada (de momento..
;-p).
SEGUNDO PROBLEMA:
Si no se puede hacer nada con el programa fiambre, le hacemos
una biopsia y listo. Pues tampoco. Al cargarlo con el loader de SoftIce
este no salta y nos quedamos con cara de tontos mirando para la pantalla.
De momento hay que seguir estudiando el ejecutable para ver por donde entrarle.
APROXIMÁNDONOS A LA VÍCTIMA:
Para este paso necesitaremos la herramienta GetType, o en
su defecto el ExeScan, ambos disponibles en muchos sitios. El comando a
utilizar con el GetType sería:
C:> GTW homesite45.exe /ZE (los path serán
los que tu tengas en el ordenador)
y obtenemos lo siguiente:
- --- # GetTyp 2.52 # ----------------- # Copyright
(c) 1997-99 by PHaX # ---
- --- # phax@writeme.com # ----------------------
# http://surf.to/phax # ---
- ------------------------------------------------------
# free edition # ---
- [C:\Herramientas\home.exe] -----
DOS executable file - 1457152 bytes
Portable executable (starting at 256 for 1456896
bytes)<- Es un archivo PE
Compiler: Borland Delphi 3/4 (heuristic)
Calculated entrypoint: 1432577 / 0015DC01h
(RVA: 004D4001h)
Required CPU type: 80386
Requires any version of Win32
Flags:
File is executable
Line numbers stripped from file
Local symbols stripped from file
32 bit word machine
Linker version: 2.25
Objects (object align = 00001000h):
Name Virt size RVA Phys size Phys Ofs
CODE 00305000h 00001000h 0010CA00h 00000400h
DATA 00021000h 00306000h 00003000h 0010CE00h
BSS 00007000h 00327000h 00000000h 0010FE00h
.idata 00004000h 0032E000h 00001600h 0010FE00h
.tls 00001000h 00332000h 00000000h 00111400h
.rdata 00001000h 00333000h 00000200h 00111400h
.reloc 0002F000h 00334000h 00000000h 00111600h
.rsrc 00171000h 00363000h 0004C600h 00111600h
.aspack 00006000h 004D4000h 00006000h 0015DC00h
<- Y está comprimido con Aspack v??
.rsrc 00001000h 004DA000h 00000000h 00163C00h
- Files identified: 1 of 1 (100.00%)
- Total time: 60.0 ms (60.0 ms/file)
Bueno, ya sabenos que tenemos entre manos un archivo comprimido
con Aspack... del que hay varias versiones pero esta no la detecta.(la versión
4.0 estaba comprimida con Shrink... tutorial de D.A en la página
de Karpoff)
Con esta información podríamos acudir al ProcDump
y descomprimirlo con el script adecuado para Aspack , pero como no se la
versión y no voy a probarlas todas , me conformaré con que
lo carge el loader del SiCe para la biopsia.(De todas formas mi versión
del P.D. no fué capaz de desempacarlo cuando conseguí saber
la versión).
La otra solución es bajarse de Protoolz el descompresor
específico para Aspack , que lo identifica como comprimido con Aspack2000.
No sirve de nada porque tras preparar el ejecutable para el W32Dasm no aparecen
los strings que nos interesan y que posiblemente estarán en una librería
como los iconos. Eso sí , obtenemos un ejemplar descomprimido que
nos facilitará las cosas más adelante al trazarlo con el SoftIce..
El procesado del ejecutable para que se carge en el W32Dasm
y en el loader del debugger es el siguiente:
Con el ProcDump cargado vamos a PE Editor -> Sections y
clickeamos con el botón derecho del ratón sobre la sección
CODE del ejecutable, y nos aparece la siguiente pantalla:

Si quieres saber más sobre los datos que aparecen ahí,
lee los tutoriales sobre el ProcDump que hay en el ECD. A nosotros nos interesa
Section Characteristics y su valor. El C0000040 lo cambiamos por E0000060,
que activa las características IMAGE_SCN_CNT_CODE y IMAGE_SCS_MEM_EXECUTE
para la sección CODE del ejecutable (más información
en los otros tutoriales sobre archivos PE), de forma que podamos cargarlo
con el Loader para ver cómo funciona. Prueba ahora y verás,
¿a que ya salta el SoftIce?... ;-), pués ahora empieza la
diversión....
LA ESTRATEGIA:
Recordemos que necesitamos deshacernos de dos nags amarillas
exactamente iguales que aparecen al principio y la que anuncia que ha caducado.
Para ello utilizaremos mi comando favorito para cargarme ventanas HWND.
Seguramente no descubra nada nuevo, pero son pocos los tutoriales sobre
nags que hablan de esta función, mucho más eficaz y versátil
que las típicas MessageBoxa y similares que se suelen mencionar siempre.
Cuando escribimos el comando hwnd nos aparece una lista
con todas las ventanas y componentes de estas (botones, cajas de texto...),
con su handle, programa al que pertenece, dirección y nombre (muchas
veces muy ilustrativo). Lo único que hay que hacer es elegir la que
nos interesa (suele ser la primera que aparece con el nombre del programa
que estamos trazando), poner un bmsg (el mejor complemento a un buen
hwnd) y trazar hacia atrás hasta la función madre que hace
que se cree la nag para nopearla o buscar el salto condicional que hace
que caigamos en ella. La sintaxis del comando bmsg es:
bmsg wm_<opción> (para la lista de opciones
escribe wmsg en el SiCE, las más comunes son bmsg wm_destroy y wm_enable..)
y normalmente en unos cuantos F10 estaremos en el lugar adecuado
para poner unos cuantos 90 y olvidarnos de la pantalla.
MANOS A LA OBRA:
Con el archivo ejecutable (comprimido o descomprimido) ya
preparado parar el loader, lo cargamos y vamos siguiendo con F10 cómo
se comporta el programa. Si estamos usando el archivo comprimido, habrá
que esperar a que esté totalmente desplegado en memoria para poder
ver el código original ; si usamos el descomprimido, que es lo más
adecuado ya vemos el código desde el principio, y tras unos cuantos
F10 caeremos en la rutina que crea las nags amarillas, que está en
007057EC. Lo que hay que hacer a continuación no es necesario explicarlo
ya que el código es lo suficientemente ilustrativo.
:007057DE cmp byte ptr [0072d658], 00
:007057E5 je 7057fd
:007057E7 mov ....
:007057EC call 452624 <-
Llamada que genera las nags amarillas
Hacemos un bpx en la posición de memoria que hallamos
elegido para parchear, lanzamos de nuevo el programa y cambiamos los bytes
oportunos. Perfecto, ya no salen las nags: ahora a por la pantalla de la
fecha de caducidad.
Corremos el programa hasta que aparezca la pantalla de caducidad,
y en ese momento hacemos CTRL-D y escribimos en SoftIce hwnd tras
lo que nos sale una lista de las ventanas y objetos que tenemos en pantalla,
bajamos hasta las que corresponden con Homesite y vemos una una que se llama
TEvalNotice seguida de dos Buttons.... más claro agua... Nos fijamos
en su handle (izquierda de la pantalla) y le damos la orden :
bmsg <handle> wm_<opción>
En este caso podemos utilizar dos opciones: wm_destroy
o wm_enable
Si optamos por la primera, el debugger saltará en el
momento que desaparece la ventanita de nuestro monitor al pulsar el botón
de continuar. Si usamos la segunda deberemos tomar el handle del botón
de continuar, que está deshabilitado, y el debugger saltará
cuando el botón reciba la orden de activarse. En cualquiera de los
dos casos caeremos en el mismo código, que habrá que trazar
hasta encontrar alguna llamada precedida de un salto condicional, hacemos
un breakpoint con un doble click sobre la línea y seguimos. Por lo
general las primeras líneas de código que aparecen se corresponden
con la formación de la ventana, caption, tamaño, colores...
y no son de gran utilidad, pero las que aparecen al final ( última
y precedentes antes de que F10 deje de hacer saltar el SI ) son a las que
más hay que prestar atención pues suele ser ahí donde
se toma la decisión de formarla. Hay que ser especialmente cuidadoso
al parchear aquí porque podemos hacerlo en alguna rutina común
a otros procedimientos. Una vez puestos los breakpoints se vuelve a lanzar
el programa y eliminando los que saltan continuamente llegamos al que nos
interesa, que está en 006A2C6F. Ya sabéis lo que hay que hacer
¿no?.
:006A2C6B cmp byte ptr [ebp-09], 00 <-
¿han pasado los 30 días?
:006A2C6F jne 006a2c76 <-
Si [ebp-09] no es 0 sigue el período de evaluación y salta
la llamada a la Messageboxa
:006A2C71 call 64bad8 <-
Llamada a la formación de la pantalla de caducidad.
De nuevo poneemos un breakpoint, corremos el programa. parcheamos
en memoria y comprobamos que funciona.
En estos momentos nos hemos cargado las nags del principio
y la ventana de caducidad, con lo que el programa ya estaría preparado
para una evaluación más prolongada y libre de incordios. Lo
único que nos quedaría sería buscar las cadenas de
bytes con el UEdit32 y cambiarlas por lo que corresponda.
ATENCIÓN: Este método sólo
sirve para el archivo descomprimido
Si lo que deseamos es crear un crack para su distribución,
no podemos envíar el ejecutable, ya que es muy grande (1.5 Mb comprimido
o 4.3 Mb descomprimido) , y como estamos tratando con un archivo "encogido"
no nos sirve el típico parche porque que el código no está
expuesto. Lo que nos hace falta es algo que haga el parcheo "on the
fly" tras la descompresión. Esto es lo que se conoce como loader
o cargador, que no es más que un programa que está atento
a la descompresión y cambia los bytes cuando están expuestos
( como un bandolero que espera detrás de una roca a que aparezca
su víctima... ). Veremos una forma sencilla de crear uno más
adelante.
Bueno, ya tenemos el HomeSite sin nags, pero todavía
quedan restos de su pasado como versión de evaluación: en
el título de la ventana pone *Evaluation Version* y la pantalla del
About aún nos recuerda que los 30 días han pasado. Lo que
trataremos de hacer es cambiar el título por otra cosa ( *Registered
Version* o tu apodo...) que ocupe los mismos bytes y deshabilitar la pantalla
de About.
DE PESCA:
Recordemos que con el W32Dasm no conseguíamos ver los
strings del programa, de modo que no podemos buscar así la línea.
Una pasada del Search and Replace buscándola tampoco sirve de mucho
. La solución es buscarla en memoria con el SoftIce y parchearla
como hacíamos antes. Para buscarla utilizamos el comando s de
la siguiente manera:
s 0 lffffffff'EVALUATION'
que le indica que busque la
cadena EVALUATION en toda la memoria. Una vez localizado el punto exacto
con varios bpm en las posiciones obtenidas, sólo hay que escribir
(click sobre la cadena) lo que queramos manteniendo la misma longitud en
bytes. Copiar el valor hex de la cadena nueva y parchear con el editor hexadecimal
o con el loader.
El procedimiento para eliminar
la ventana del About es el mismo que utilizamos para la de caducidad:
hwnd
bmsg <handle> wm_destroy
y trazar hasta dar con la rutina en 006B58B6. Aquí
no hay saltos condicionales (porque siempre que pulses about va a salir),
con lo que la solución es anular la llamada con los NOP necesarios.
Ahora sí que tenemos el HomeSite preparado para su
evaluación sin ningún tipo de trabas :-) .
PRESENTACIÓN : RPP ( R!SC's Process Patcher)
Rpp es un creador de parcheadores en tiempo real (loader)
que crea un ejecutable win32 a partir de un script. El ejecutable carga
un proceso, espera a que se descomprima / desproteja y despúes lo
parchea en memoria para corregir los bugs que el autor ha dejado en él
( Nags, evaluaciones de 30días...) y además es el único
de este tipo (que crea un ejecutable win32 independiente). (Traducción
libre de la presentación original).
Se puede bajar desde la página de Karpoff, en Protoolz,
en Sudden Discharge...
La forma de utilizarlo es ejecutándolo y seleccionando
el script que queremos compilar o arrastrando el script sobre el ejecutable
(mú fácil). También desde la línea de comandos
como:
rpp.exe <script.rpp>
-Sintaxis del Script:
; <- No le hace caso a lo que vaya delante de esto
(comentarios y similar)
T= <- Número de intentos de parchearlo que
va a hacer hasta darlo por imposible. (8000 por defecto)
F= <- Nombre del proceso a cargar (importante que
sea el nombre original del ejecutable)
O= <- Nombre del cargador (el que tú quieras)
P= <-bytes a parchear ( dirección de memoria
/ bytes originales / bytes nuevos ).
Los bytes van separados por comas y su número es igual
a ambos lados de la barra.
: <- Fin de la instrucción
$ <-Fin del script
Nuestro cargador:
Abrimos el Notepad y escribimos el script:
------------------------------------------ CORTAR POR AQUÍ
------------------------------------------
; Cargador para Homesite 4.5 por CRaCX 28 Mayo de 2000
<- Información para identificarlo con el tiempo :-)
; Creado con R!SC's Process Patcher
; Incluído a efectos didácticos. Su
empleo con software que no hayas obtenido legalmente es delito.
T = 10000:
; Veces que va a intentar parchear. Mejor empezar con 10000
e ir bajando hasta que falle
;.Depende de las características del ordenador. A mí
me funciona siempre así...
O= Homesite_loader.exe: ; Nombre del ejecutable de
salida
F= Homesite45.exe: ; Nombre del proceso a parchear
P=006a2c6f/75,05,e8,62/eb,05,e8,62: ;Cuarto parche
de la nag de 30 días superados
P=006afdc7/45,56,41,4C,55,41,54,49,4f,4e/52,45,47,49,53,54,45,52,45,44:
;Tercer parche de EVALUATION VERSION a REGISTERED VERSION
P=006b58b6/ff,92,cc,00,00,00/90,90,90,90,90,90: ;Segundo
parche de la nag de About
P=007057e5/74,16/eb,16:;Primer parche de las nag del
inicio
$
------------------------------------------ CORTAR POR AQUÍ
------------------------------------------
Ahora lo guardamos como Homesite_script.rpp en el directorio
donde tengamos el RPP instalado y lo arrastramos encima de rpp.exe. Si todo
va bien nos sale un mensaje parecido a este:

Si sale cualquier otra cosa es que hay un error se sintaxis
y tienes que revisar el script. Además crea el archivo Homesite_loader.exe
de 5.50Kb. Copiamos este ejecutable al directorio del programa a
parchear y ejecutamos el cargador.
En el momento que ejecutamos, este indica al Homesite45.exe
que se ejecute, y mientras esto ocurre, hace un ataque a las posiciones
de memoria indicadas parcheando lo que corresponda. El loader no sabe cuando
el objetivo está descomprimido, pero como ataca continuamente las
posiciones cumple su misión. Si no es capaz de parchear al programa
o en las posiciones de memoria no encuentra lo que le dijimos, saca un mensaje
de error y el programa transcurre normalmente.
Estos mensajes pueden aparecer por cuatro causas principales:
1. Que haya errores de sintaxis. Comprueba el valor de F,
que el número de bytes a cambiar es igual que el de originales y
que los separas por comas y barras
2. Que el valor de T sea muy bajo, en cuyo caso hay que aumentarlo
(10000 da buenos resultados, menos depende del ordenador que tengas)
3. Que lo estes ejecutando en un directorio que no es el de
la aplicación o que esta tenga el nombre cambiado.
4. El número de bytes a parchear es superior a 180h
(limitación del programa)
RESUMIENDO:
El trabajo que tenemos que hacer con el Homesite 4.5 es:
1. Deshacernos de las nags amarillas.
2.Deshacernos de la pantalla de caducidad.
3.Corregir el título de la ventana principal
4.Anular la ventana About.
5. Crear un cargador que haga todos los cambios anteriores
durante el arranque del programa comprimido o parchear con el editor hexadecimal
si nos sirve el ejecutable descomprimido.
La mayor dificultad es que no disponemos de un listado muerto
útil donde buscar strings, y que todo el proceso de rastreo se hace
"in vivo".
LA SEGUNDA PUERTA:
Si recordáis, había hecho una búsqueda
con el Search and Replace de la línea *EVALUATION VERSION* y no la
había encontrado. Pues bien, sinembargo aparecieron unas claves del
registro de Windows muy curiosas:

Si utilizamos el Regedit para ver que llamadas hace mientras
se ejecuta, vemos que antes de que aparezcan las nags se hacen varias a
LocalStatusRS232\HEv (¿Homesite Evaluation quizá?),
igual que antes de que se cree la ventana de caducidad. Curioso ¿no?.
Vamos a borrarla a ver qué pasa (primero exporta la clave por si
acaso). Pues ocurre que volvemos a tener 30 días de prueba. Si volvemos
a la clave del registro, aparece de nuevo HEv y en ella un nuevo valor de
cadena llamado dtst que vale 36677. A medida que avanzamos la fecha del
ordenador el valor cambia hasta llegar a 0, momento en el que el programa
empieza a sacar la ventana de caducidad. Si probamos a cambiar el valor
por 9999999 por ejemplo, nos da 9963352 días de evaluación
:-). Si no queremos liarnos con el loader hacemos un parche para el registro
como el que sigue a continuación y listo :
REGEDIT4
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\LocalStatusRS232\HEv]
"dtst"="9999999"
con lo que la molesta pantalla de caducidad no sale nunca.
Si quieres busca la rutina que llama a la clave y parchea
la comprobación, pero esto es más fácil.
En fin......
ADIOS...
Bueno, espero no haberme liado demasiado al explicar cómo
se desprotege este programa y que la lectura haya sido amena. Sobre archivos
empaquetados hay muchos tutoriales y muy buenos en el ECD y otros sitios.
En vez del loader se podría haber hecho un recorte con el Snippet
Creator e inyectárlo al ejecutable original, ya que el E.P original
ya lo sabemos gracias al archivo descomprimido y sólo habría
que buscar dónde meterlo y dirigir la llamada a él para que
tomara el control, pero eso es ya otra historia... Saludos a todos y hasta
la próxima.
Todo lo mostrado en este tutorial es para uso educativo
y no para fomentar la piratería. Si tienes pensado utilizar este
programa más de los 30 días de evaluación cómpralo.
No me hago responsable del mal uso de los contenidos
de este documento.
|