DisidentS Team

Hola a todos, estoy nuevamente para mostrarles lo sencillo que puede ser crackear un componente para el entorno de desarrollo Delphi.

Las otras noches, nos juntamos en la casa de un amigo a comer unos canelones, después de comer, charlar y reirnos un rato, sacamos nuestras notebooks… fue ahí cuando me dije, ¿porque no crackear estas compos que hacen muy lindas interfaces a nuestras aplicaciones delphi?

No diré el nombre de estas componentes, ya que obviamente son pagas, sino no sería necesario crackearlas , no? xD

Pero sí daré una pista, empiezan con estas dos letras VGS y las que le siguen, sin espacios son 4 letras, muy conocida palabra en el “ambiente” en el que nos solemos mover. a alguien le gusta la demoscene? xD

Bien, no doy mas pistas, si no lo han agarrado dedíquense a otra cosa… xD

La protección es muy, pero muy sencilla, pero molesta, como todas.

Una pequeña NAG Screen, cuando se instala el componente en Delphi, aparecerá, si arrancamos el entorno, aparecerá, porque Delphi carga todas sus librerías al comienzo… si compilamos un proyecto de ejemplo que viene en el paquete, saldrá el NAG de nuevo, y obviamente si corremos el EXE generado aparte, también… en algún lugar más? xD

Lo que haremos serán dos parcheos simples y no aparecerán nunca más en ningún lado, solo con parchear un fichero. Hay que ir a la fuente, delphi compila y reconvierte todo a varios formatos para que todo en “su mundo” salga bien.

Podemos rompernos la cabeza parcheando 3 o 4 archivos, o 1 solo simplemente.

De que se trata todo esto

Bueno, como ya expliqué es un simple NAG molesto, las demás funcionalidades parecen completas, así que les mostraré el mensajito:

Bien, como les dije, este cartelito, todas las veces que les comenté aparece, ahora vamos a sacarnóslo de encima

Si miramos la carpeta de los componentes estos, veremos que tenemos la carpeta packages, dentro hay archivos con estas extensiones dpk, dcu, res, bpl y dcp.

Los DPK son Delphi Package, los DCU son Delphi Compiled Unit, los BPL son Borland Package Library y los DCP son Delphi Component Package.

Cuando abrimos un DPK, compilamos e intalamos, éste contiene las DCU compiladas, y la DPK utilizada se guardara en la carpeta de proyectos de Borland.

Con esto quiero decir, que si crackeamos lo que genera un DPK que es un BPL, no lo crackearemos del todo…

Miremos primero lo más facil.

Donde atacar

Si compilamos un ejemplo y lo abrimos con el IDA, buscaremos una parte del string del NAG, por ej, “trial”.

Encontraremos la parte de código como la siguiente:

CODE:004F4704                 mov     eax, offset _str_This_applicatio.Text

CODE:004F4709                 call    unknown_libname_164 ; BDS 2005-2006 and Delphi6-7 Visual Component Library

CODE:0050BED0                 mov     eax, offset _str_Resources.Text

CODE:0050BED5                 call    sub_4F7E78

CODE:0050BEDA                 call    nullsub_13

Ok, entonces, podemos parchear el segundo CALL.

Si miramos el código en hexa, será el siguiente: E8 C1 87 FE FF deberíamos NOPearlo, y listo, lo tenemos arreglado.

Pero!, siempre hay un pero, no nos conviene parchear cada EXE que compilamos, o si? sería muy tedioso, deberíamos correr el parche por cada ejemplo o aplicación que utilice estas librerías, entonces deberíamos parchear la fuente, donde se genera la cuestión, no creen?…

Buscando la fuente

Ok, busquemos lo mismo en el BPL que si lo abrimos es un PE armado por Delphi. En cambio no podremos hacerlo con un DPC.

Encontramos esto:

CODE:004560C1                 call    @Vg_scene@RegisterVGObjects$qqrx17System@AnsiStringpxpx17System@TMetaClassxi ; Vg_scene::RegisterVGObjects(System::AnsiString,System::TMetaClass **,int)

CODE:004560C6                 call    @Vg_version@ShowVersion2$qqrv ; Vg_version::ShowVersion2(void)

Con esto lograremos que Delphi 7 no sea interrumpido por la molesta NAG, pero al compilar los ejemplos, y al ejecutarlos saldrá nuestro NAG…

Entonces, donde está la magia de esto? nos queda una de las extensiones que expliqué antes: DCU.

Las DCU NO son PE’s así que tendremos que ver como los “atacamos”, la mejor idea creo que es con DEDE.

Mirando en la carpeta fuera de packages, vemos tooodos los DCU,  así que encontraremos uno de ellos que es vg_version.dcu

Podemos abrir el DEDE y hacer lo siguiente:

Como vemos, abrimos DEDE, y en el menú dumpers, podemos elegir la opcion Dumpeador de DCU. Si hacemos click en esa opción se abrirá la siguiente pantalla, donde elegimos el archivo vg_version.dcu y hacemos click en procesar.

Obtendremos lo siguiente:

Obtendremos el código de nuestra DCU, entonces ahí veremos lo siguiente:

procedure ShowVersion2;

const

  AboutText = 

    000: ÿÿÿÿP...This app|FF FF FF FF 50 01 00 00 54 68 69 73 20 61 70 70|

    010: lication uses a |6C 69 63 61 74 69 6F 6E 20 75 73 65 73 20 61 20|

    020: trial version of|74 72 69 61 6C 20 76 65 72 73 69 6F 6E 20 6F 66|

    030:  VGScene.....Ple|20 56 47 53 63 65 6E 65 2E 0D 0A 0D 0A 50 6C 65|

    040: ase contact the |61 73 65 20 63 6F 6E 74 61 63 74 20 74 68 65 20|

    050: provider of the |70 72 6F 76 69 64 65 72 20 6F 66 20 74 68 65 20|

    060: application for |61 70 70 6C 69 63 61 74 69 6F 6E 20 66 6F 72 20|

    070: a registered ver|61 20 72 65 67 69 73 74 65 72 65 64 20 76 65 72|

    080: sion.....%s..Cop|73 69 6F 6E 2E 0D 0A 0D 0A 25 73 0D 0A 43 6F 70|

    090: yright (C) 1998-|79 72 69 67 68 74 20 28 43 29 20 31 39 39 38 2D|

    0A0: 2009 by Eugene K|32 30 30 39 20 62 79 20 45 75 67 65 6E 65 20 4B|

    0B0: ryukov....For co|72 79 75 6B 6F 76 0D 0A 0D 0A 46 6F 72 20 63 6F|

    0C0: nditions of dist|6E 64 69 74 69 6F 6E 73 20 6F 66 20 64 69 73 74|

    0D0: ribution and use|72 69 62 75 74 69 6F 6E 20 61 6E 64 20 75 73 65|

    0E0: , see LICENSE.TX|2C 20 73 65 65 20 4C 49 43 45 4E 53 45 2E 54 58|

    0F0: T.....Visit our |54 2E 0D 0A 0D 0A 56 69 73 69 74 20 6F 75 72 20|

    100: web site for the|77 65 62 20 73 69 74 65 20 66 6F 72 20 74 68 65|

    110:  latest versions|20 6C 61 74 65 73 74 20 76 65 72 73 69 6F 6E 73|

    120:  of VGScene:....|20 6F 66 20 56 47 53 63 65 6E 65 3A 0D 0A 0D 0A|

    130: http://www.ksdev|68 74 74 70 3A 2F 2F 77 77 77 2E 6B 73 64 65 76|

    140: .com/..support@k|2E 63 6F 6D 2F 0D 0A 73 75 70 70 6F 72 74 40 6B|

    150: sdev.com.       |73 64 65 76 2E 63 6F 6D 00|;

var

Aquí vemos que está el mensaje de nuestra NAG, tenemos nuestro objetivo en la mira.

Como veremos, tenemos 2 procedimientos ShowVersion y ShowVersion2.

Lo que haremos será sencillo, en vez de parchear DENTRO, parchearemos solamente y PUSH EBP:

begin

   00000000 : 55                            PUSH EBP

   00000001 : 8B EC                         MOV EBP,ESP

   00000003 : 83 C4 F4                      ADD ESP,-12

   00000006 : 53                            PUSH EBX

   00000007 : 56                            PUSH ESI

   00000008 : 33 C0                         XOR EAX,EAX

   0000000A : 89 45 FC                      MOV DWORD PTR [EBP-4],EAX

   0000000D : 33 C0                         XOR EAX,EAX

   0000000F : 55                            PUSH EBP

   00000010 : 68(95 00 00 00                PUSH ShowVersion2{0x26}+149

Justamente el PUSH EBP, podemos cambiarlo por un RETN, entonces no entrará directamente a nuestra función, es decir, entrará y luego se irá y no habrá pasado nada.

Entonces tendremos que cambiar el 55 que es el código de operación del PUSH EBP, por un RETN que es un C3.

Parcheando

La pregunta que tendremos inmediatamente, es ¿cómo podemos interceptar ese PUSH EBP, en realidad los dos por las dudas…?

Lo mejor, es buscar el patrón de bytes, así nos aseguraremos que estamos en el lugar indicado..

El patrón que utilicé yo para buscar en ShowVersion2 es: 55 8B EC 83 C4 F4, será el mismo en ShowVersion, ya que es la “cabecera” de la función, y siempre es igual, idéntica.

Así que cambiaremos el 55 por un C3, y san se acabó la maldita NAG.

Conclusión

No hay mucho más que decir, son buenos componentes, si los utilizarán con fines lucrativos, cómprenlos, pero la forma en que está protegido esto, es… deplorable.

Luego podremos recompilar nuestro DPK y reemplazar los nuevos por los viejos, la NAG no aparecerá nunca más ni en Delphi, ni en ningún lado.

Espero que les haya gustado.

Nos vemos en la próxima.

convert this post to pdf.

En la lección de este mes, les traigo un amigable crackme, que según el autor (  y con razón) es un tutorial, si lo desensamblamos, así que les pegaré el código y eso es todo… jeje , era broma, lo iremos descubriendo de a poco, y aprenderemos juntos.

Nos encontramos con una protección que no habíamos analizado aun, esta proteccion, es parecida a las utilizadas en los keymes, donde necesitamos un fichero clave para que el programa este registrado, este fichero clave contiene ciertas caracteristicas muy importantes que hacen, que se este registrado o no.

Bueno, este crackme no es un keyme, pero al principio actua como un keyme, nada mas que chequea un par de cosillas distintas, que ya veremos.

Reglas de Juego

Cuando ejecutamos el Crackme , tenemos en la pantalla principal de este, dos botones, y a la izquierda de estos, dos labels, que dicen Shareware y Unregistered.

Miremos en el boton About/Rules, donde nos dice, que hay tres caminos para crackear el crackme, y luego como les comente al principio del articulo, si lo desensamblamos, este crackme, es un tutorial por si mismo, tenemos permitido usar desensamblador y parchear; y por ultimo dice que si somos mejores con SoftIce, lo hagamos con SoftIce, pero nosotros no usaremos SoftIce, usaremos Olly Debugger, asi que no lo desensamblaremos, ni lo parchearemos fisicamente, solo en memoria.

Un poco de teoría

Desensamblemos el crackme, y veremos la pantalla principal de debugger, con el codigo ensamblador mostrandonos como es nuestra victima, debo decirles, que es un poco enradada, pero no nos asusteis, esta todo controlado…

Comenzamos en la dirección 401000, con un recibimiento poco comun en los crackmes (lo he  visto en algunos programas y juegos comerciales, y bastantes nuevos), nada mas ni nada menos que un “Hi Reverser”,

¿ pero quien es el reverser aquí ?, SI! Nosotros, o eso creo….

Luego otro PUSH ( que lo que hace es cargar con una direccion de memoria la cual apuna al string, el string propiamente dicho) que nos dice “Here Starts the test for the Versión” (Aquí empieza el chequeo por la versión).

Nueve instrucciones mas abajo encontramos otro texto que es PUSHeado a la memoria diciendo: “Here end the test for the Versión” (Aquí termina el chequeo por la verision).

Con razon el creador dijo que esto era un tutorial, miren, si nos marca el sector donde hace el chequeo para decirnos si esta registrado o no el programa, nosotros debemos conseguir que en esos dos labels que hay al ejecutarlo en la pantalla principal diga que esta registrado.

Bien, veamos que podemos hacer aquí tenemos lo siguiente:

En la direccion 0040100B  , la instrucción MOV [DWORD DS:40300C],1 y en la direccion 00401015 , la instrucción MOV [DWORD DS:403008],1 ;  analicemos para que sirven y porque las nombro de entre todas las demas, ¿ ustedes piensan que tienen coronita ? pues no, no la tienen, o de algun modo si…

Los dos MOV’s mueven un 1 en decimal, a dos direcciones de memoria diferentes…. Anotemos la direccion 403008.

Más abajo en la dirección 00401021 , tenemos la instruccion  LEA EAX,[DWORD DS:403010], que carga el valor que esta en la zona de memoria 403010 a  EAX, y luego la instrucción de la direccion 00401029 que nos dice:

CMP EAX,X-LOCK~1.00403012

Luego viene nuestro push querido indicandonos el fin del programa, un pop eax, y un salto JE, que nos lleva  a la direccion 401040….

Algo muy notorio

Muy bien, ¿que es lo notorio?, ese salto a 401040 nos lleva a continuar el flujo del programa normalmente, ¿pero que sucede si este salto no se realiza?, veamos:

00401036   MOV [DWORD DS:403008],0

¿Pero que sucede aquí?, en 403008, la que yo les dije que recordaran , pone un 0!!!, ¿porque? Sigamos mirando y deduzcamos si ese 0 es necesario para estar registrados o no…

Mas adelante en el programa , carga la ventana principal, en la direccion 401077 chequea , por si se ha clickeado un boton, y si es asi, pregunta cual de ellos, etc, etc. Esta rutina es comun en todos los programas, ya que es la rutina principal que chequea por cada opcion, o boton , si fue presionado o no, y en caso afirmativo se deriva el flujo del programa a la direccion correspondiente a la accion solicitada por el usuario.

Lo bueno comienza en la direccion 0040109D, donde nos encontramos el push identico, al primero que vimos en la apertura del programa desensamblado, y unas lineas de codigo mas abajo el otro push que nos indica que finaliza la seccion de registro, tal cual en el principio.

¿ Se acuerdan de los mirror checks que yo les habia explicado en articulos anteriores ?, bien, aquí lo tienen, la proteccion se repite en dos zonas de memoria distintas, o sea, que si nosotros parcheamos solamente la primera, o encontramos la segunda y parcheamos solamente esta, la otra seguira actuando normalmente y no nos dejara el programa registrado, por supuesto todo esto depende de cómo el programa este implementado, porque en nuestro caso, con modificar el segundo chequeo , nuestro crackme ya esta completamente funcional.

Fijense que en la direccion 0040109D vuelve a hacer lo mismo que antes.

Carga en EAX, lo que contiene la direccion 403010 y lo compara con lo que hay en la direccion 403012, si no llegan a ser iguales en la direccion 004010AD salta a la direccion 004010B9, pero la instrucción MOV [DWORD DS:40300C],0 de la linea anterior no es ejecutada, si se produce el salto, pero miren atentamente moveria un 0 decimal a la direccion 40300C, es otra zona!, es un doble chequeo, pero chequea dos zonas distintas de memoria, miremos mas,

miremos mas…..

En la direccion 004010A2  tenemos un  LEA EAX,[DWORD DS:403010], 403010 tiene un 31 en hexa (1 en decimal), lo que al compararlo en 4010A8 con el valor de 00403012 que contiene un 30 en decimal (0 en decimal), hara que no salte y entonces el mov de la direccion 004010AF pondra a 40300C en  0 y no estaremos registrados.

A partir de la direccion de memoria 4010E6 hasta 4010EE tenemos lo siguiente:

MOV EAX,[DWORD DS:403008]   ;  mueve lo que contiene 403008 a EAX

CMP EAX,1 ; lo compara con 1

JNZ SHORT X-LOCK~1.00401105 ; y luego si no es igual salta a 401105

Mas abajo miremos, las strings cargadas…

004010F6  |. 50             PUSH EAX                                 ; /Text => “Fullversion”

00401115  |. 50             PUSH EAX                                 ; /Text => “Registered”

Necesitamos que estas strings se carguen, para que nuestro crackme funcione correctamente!!!, pero como podemos hacerlo??? Bien, el salto de la direccion 4010EE no nos lleva a poder ejecutar esas strings, por lo menos la de Fullversion no, pero sin embargo salta a una direccion anterior a la de la string “Registered”, salta a 401105, y “Registered”, esta en 401115, o sea que algo debe haber en el medio..  >: \

Perfecto, en la dirección 401105 tenemos lo mismo que en la direccion 4010E6 nada mas que el MOV EAX,[DWORD DS:403008]  , cambia por MOV EAX,[DWORD DS:40300C]  , aquí sucede lo mismo que antes, si no se cumple la misma condicion, o sea en la direccion 40300C no esta el valor 1 decimal, tampoco carga la string “Registered”, y nuestro programa no estaria ni completo (Fullversion) ni registrado (Registered).

Alternativas de Cracking:

Hay muchas alternativas, para hacer que nuestro pequeño funcione, podemos modificar los saltos de las direcciones 401034 y 4010EE, entonces como los valores de las direccion 403008 y 40300C seran 0 saltara, y nos hara registrar, simplemente cambiar los JNZ por JZ y listo, o sino por JMP y estos se transformaran en saltos INcondicionales, o sea, no importa si son iguales o no los valores, el salto se realiza igual.

Otra alternativa mas “elite”, y menos sucia que cambiar saltos y forzar el flujo del programa, es modificar la instrucción LEA de la direccion 00401021  , donde mueve lo que contiene 403010 a EAX, como lo que contiene 403010 es un 1 en decimal, siempre no saltara y nos pondra en 403008 el valor 0 con lo que no estaremos registrados nunca, entonces ¿por cual valor podemos moficar el operando de la instrucción LEA? Por una direccion de memoria como por ejemplo 403012, que contiene 0, entonces cuando llegue al CMP EAX, 403012, simplemente comparara el valor que contiene 403012 con el que contiene 403012, ¿resultado?, se produce el salto, y asi nuestro soldadito atrapado en  403008 (el 1), seguira vivo y no sera machacado….

Otra alternativa seria cambiar el CMP EAX,403012 por 403010, ya que, sera lo mismo, nada mas que en 403010 hay un 1 y no un 0 decimal como en 403012.

Luego en 004010A2 podemos modificar la instrucción LEA , por 403012, o inclusive podemos hacer un MOV EAX,0  y seria suficiente porque 403012 contiene un 0 decimal, y debemos hacer que el salto se produzca, y como el salto se produce cuando son iguales, pues ya lo tenemos

Tambien podemos modificar el CMP, como en la zona de chequeo anterior o el salto JNZ.

Triunfadores:

Hemos  triunfado de nuevo, como podemos ver, nos aparece una ventanita, diciendonos, que hemos craqueado exitosamente el crakme, y que esperemos el segundo que sera mas difícil de crackear, ¿lo sera? Quizas si…. Quizas no….

¡Hasta la próxima!

convert this post to pdf.

CuTedEvil CrackMe #1

Análisis y Parcheo.

Buenas, a todos los lectores de @rroba, soy SparK, del team DisidentS, y les ofrezco mis nobles y humildes conocimientos en este arte de la Ingeniería Inversa.

Espero que se diviertan tanto como yo lo he hecho con este crackme, en realidad no es nada difícil, pero a veces es lindo acorralar fácilmente a una víctima o no?

Quizás algunos de ustedes sean avezados Reverser’s y piensen al leerme, ¿pero que es esto? ¿El abecedario una y otra vez?, quizás otros novatos newbies, o simplemente lectores interesados en este arte digan: “mmmm, interesante”, quiero que sepan todos ustedes, intentaré darles siempre pensamientos frescos e ideas nuevas, por eso es bello este arte, es muy diverso.

Pero, vamos por partes, dijo Jack el Destripador, ¿Qué es un Crackme?

Ok, para los que no lo saben, un crackme es un programita que sirve para ejecitarse en el arte de la ingeniería inversa, en pocas palabras, es un “ejercicio de aplicación”.

¿ Que lograremos crackeando un crackme?

Pues, muchísimas cosas, primero, hay crackmes con las mas diversas protecciones y ocurrencias, en síntesis sirve para poder aprender, concentrarse en ese código difícil de aprender e interpretar a simple vista llamado Ensamblador, para poder memorizar técnicas, rutinas, y luego, en otro momento cuando miremos otro código digamos, “ah!, es mas o menos parecido a…” , en fin, ejercitas, la lógica, la memoria, y a la vez si no sabes o no entiendes ni medio de lo que pasa en ese maldito crackme, aprendes, que es lo más importante que te puede suceder aquí.

Les daré mas pistas, existen muchos tipos de ejercicios de aplicación, algunos de ellos son los Reverse me’s, los Tool me’s y demás, los primeros debes conocer ensamblador a fondo, y reprogramar la aplicación, o inclusive agregar código faltante, ¿ interesante no ? , ya veremos algunos, no desesperéis….

Este Crackme, lo he bajado de www.crackmes.de , y hasta hoy no tenía solución.

El crackme, tiene un aspecto como una caja de registro típica de cualquier programa, deberemos ingresar Nombre de Usuario, Serial, y luego click en Check.

Si hacemos click en Read the Rulez!, nos dirá que debemos programar un keygen, ok, ¿que es eso? Un programa que genere seriales aceptables para el crackme, ingresandole cualquier nombre de usuario, para poder hacer esto debemos conocer y entender que sucede dentro del crackme y como se calcula el serial a partir de un nombre de usuario dado.

Ok, empecemos parcheándolo, ¿porque? , pues porque no tenemos que analizar mucho para parchearlo, aunque no este permitido en las reglas del juego, lo haré para explicarles a los más novatillos como se debe hacer.

Les comento algo a todos, parchear es nocivo para la mente del cracker, se dice que es un sucio crack, aquel que pudiendo aplicar técnicas mas “finas”, parchea, ¿ porque ?, porque aquí queremos aprender, y el facilismo nos lleva a la mediocridad, entonces, si parcheamos, es fácil crackearlo, como verán solo cambiando uno o dos bytes, pero si hacemos un serial fishing, y aún muchísimo mejor , programamos una keygen, estamos demostrandonos sobre todo, que sabemos bien lo que sucede en nuestra querida pc, y que podemos entender tarde o temprano, lo que sea. Aunque si no está a nuestros alcances hacer un keygen aún, paciencia, parchear es divertido

Carguemos el Olly, (¿que porque olly?, porque me anda muy bien en mi win xp), y ejecutemoslo, presionando F9, ¿que sucede?, aparece nuestro programilla, ponemos un nombre de usuario, SparK, ahora un serial, 0123456, y click en Check, que sucede?……… NADA!

Ok, se dice en el Zen Cracking, que todo cracker necesita una referencia para penetrar en el código de un programa, los seres humanos, tenemos referencias, los objetos los identificamos con los sentidos, son distintos, son reconocibles, en el cracking sucede lo mismo, el cracker necesita un punto de referencia, al principio los novatos necesitan puntos de referencia mas “humanos”, pero luego, te acostumbras al lenguaje interno de las máquinas y empiezas a encontrar referencias que antes no veías, esto , se llama práctica.

Nuestro punto de referencia, aquí sería un cartel, llamado messagebox que diga “Incorrect Serial” o algo por el estilo, entonces, nosotros desensamblaríamos el programa, y buscaríamos donde se llama a ese messagebox y un poco antes encontraríamos el salto que nos lleva al cartel exitoso o al fracaso, simplemente invertirlo y PUM!, “You are registered”.

Pero no, no soñemos mas, enfrentemos la realidad, no hay messagebox, no nos dice nada, pero tampoco nos registra y eso nos pone mal, muy mal.

Ok, busquemos en el Olly, por alguna referencia de strings, miremos un poquito más abajo y encontramos algo como esto:

Perfecto!, algunas referencias hemos encontrado, miren esta, “Congratulations, you cracked this program ”, miremos mas arriba de esta referencia, y encontramos este salto:

004012E8 |. 74 0F |JE SHORT CuTedEvi.004012F9

Bien, si invertimos ese salto, tendríamos que estar registrados, probemos cambiar el 74 por un 75 (JNE), hagamos click sobre la instrucción de salto, presionemos la tecla espaciadora, y ahora, cambiemos el JE por un JNE, y listo, apretemos F9, ¿¿que pasa?? nada, sigue haciendo lo mismo, ¿pero que pasa aqui?

Seguramente existe lo que se llama, mirror check, es un chequeo primario o secundario, que se hace en otra parte del código, que seguramente chequea longitud del nombre de usuario, del serial ingresado, o algun cálculo con ellos posterior, miremos un poco más, ¿ven porque no es bueno parchear a lo bruto?, si no conoces el código y lo haces mecánicamente, puedes quedar mal parado ante una demostración ;oD

¿Pero, como encontrar el otro chequeo?, miremos, observermos, debugiemos el código, una y otra vez, pongamos breakpoints, haber, ¿ que sucede generalmente en estas rutinas a nivel interno para obtener los textos introducidos por el usuario?, una pista, referencia, aparentemente oculta, pero existe, generalmente se llama a la API GetDlgItemText, o GetDlgItemTextA, para obtener el texto, pues ¿que hace?, obtiene el texto del editbox del nombre de usuario por ejemplo, y pone en el registro EAX la longitud del texto introducido.

Busquemos la/las llamadas a esta hermosa API…..

Aquí hay algo interesante:

Ok, tenemos en 0040115B que carga el ID de uno de los editbox, seguramente el del nombre de usuario, y en

0040117E, el ID del serial, ahora 00401166 y en 00401191 es llamada la API mencionada.

Fijense algo curioso, luego de llamarlas a las APIs encontramos lo siguiente:

0040118E CMP EAX,0

00401191 JE CuTedEvi.0040132B

Recuerden que les conté en secreto que GetDlgItemTextA, devuelve en EAX la longitud del texto extraído de una editbox, entonces, aquí compara la longitud con 0 y si es 0, salta a otro lado, con lo que no iría por buen camino, ya que nosotros debemos ingresar un serial y un nombre de usuario, sino no chequeará nada y seguirá su rumbo…..

Existe otra API llamada lstrlenA, que justamente obtiene la longitud de una string. ¿ pero porque esta llamada aquí ?, si ya sabemos cuanto tiene cada string… quiere decir, que debe necesitarlo, miremos:

PUSH CuTedEvi.0040332B ; /String = “”

CALL <JMP.&KERNEL32.lstrlenA> ; \lstrlenA

CMP EAX,0

JE SHORT CuTedEvi.004012F7

De nuevo un chequeo por 0, y salta a donde el otro chequeo lo hace, 004012F7, como podemos ver, ese salto, es por donde NO debemos ir.

Bien, pensemos ahora, que sucede, ¿si no salta a 004012F7?, algo hace, algo debe hacer, y de hecho lo hace…

ROL es una instrucción de cálculo, rota los bits hacia la izquierda, hagamos de cuenta que multiplicamos por 5 (en decimal) un valor.

SUB resta 123 (en hexadecimal).

ADD suma 321 (en hexa también)

CMP compara con un valor, en este caso 2FE.

Luego si, no es EAX ese valor esperado, salta al famoso salto del fracaso.

Apliquemos Ingeniería Inversa:

el valor esperado en eax como resultado de los cálculos es 2FE (33 en decimal), en EAX, tenemos la longitud de la cadena serial luego de llamar a lstrlenA, entonces, hagamos el cálculo inverso para ver, que longitud necesitamos tener en el editbox serial.

Tomemos 2FE, restemosle 321, esto nos da un número negativo FFFFFFFFFFFFFFDD, ahora sumemos 123, y nos da 100 (siempre en hexadecimal, no se confundan), ahora ROL multiplica por 5, ahora DIVIDAMOS por 5, ¿¿ y que obtenemos ?? un lindo y hermoso 33.

Esa, esa cifra señores, es la longitud que el programa necesita que tenga el serial, para poder seguir chequeando.

Ahora , modifiquemos el valor del serial, y miremos, que pasa: 012345678901234567890123456789012 , ese serial introduje yo, 33 valores cualquiera ni más, ni menos…

Ahora miremos que estamos muy cerca de los cartelitos de antes, ¿se acuerdan?, ok, les muestro que pasa antes:

Ok, tenemos el salto que habíamos parcheado hoy, pero, con la diferencia que sabemos que pasa antes, ahora solamente lo que podemos hacer son dos cosas, o introducir un número cualquiera de 33 caracteres, y luego parchear ese salto, o sino, parchear los dos saltos:

Primero: CMP EAX,2FE

JNZ SHORT CuTedEvi.004012F7

Segundo: CMP BL,0

JE SHORT CuTedEvi.004012F9

y Listo!, felicidades lo has logrado.

convert this post to pdf.

Hola a todos, el otro día buscando un FlashFXP para bajar algo , encontré la última versión….la bajé….al ejecutarla, me pidió número de serie… utilicé el keygen que lo acompañaba.

Cuando puse el serial el programa siguió su camino, me apareció una ventanita que decía c:\windows\system32 ….

Me pareció muy raro y sospeché de un virus… obviamente seguí utilizando el programa, y NOD me avisó que “algo” se quería conectar… algo con nombre como qsyrjrwes.exe en la carpeta Datos de Programa de mi usuario en Windows XP.

Obviamente, escribí en arroba sobre ese EXE, para ver de que se trataba, era un simple downloader, definido como downloader.Win32… Ya postearé el artículo explicando de qué se trata…

Bueno obviamente, el EXE de flashfxp estaba “envuelto” por un dropper, éste sacaba el downloader, y después hacía ejecutar al flashfxp normalmente…

Empezando a mirar el EXE, encontramos algunas strings que se cargan, y mirándolas por arriba, pienso que son strings encriptadas que desencripta en tiempo de ejecución…

Seguramente para evitar que los AV’s detecten el proceso…

Cuando debuggeemos por las strings “.dll” y “.exe”, más precisamente en las direcciones 408D03 y 408D15 veremos estas cosas en la pila:

0012FFAC   01141C30  0
 ASCII “C:\WINDOWS\system32\niksr.dll”

y luego,

0012FFA8   01141CA4  ¤
 ASCII “C:\DOCUME~1\SPARKR~1\CONFIG~1\Temp\setup.exe”

Luego de eso, en estas direcciones podremos ver que el ejecutable creado en la carpeta temporal de nuestro windows, posee un icono de flashfxp… es raro..

00408D39  |. A1 C8A94000    MOV EAX,DWORD PTR DS:[40A9C8]

00408D3E  |. E8 BDFDFFFF    CALL setup-pr.00408B00

En estas dos líneas se ejecuta el EXE liberado en la carpeta temporal de Windows. Igualmente no es el EXE final.

Veremos que entrando al CALL mencionado dos líneas más arriba, y mirando un poco más, se crea un objeto Mutex.

Veamos para que sirve un mutex (una definición de la red…):

“Un mutex funciona exactamente del mismo modo que las secciones críticas. La única diferencia en las implementaciones Win32 es que la sección crítica esta limitada para ser usada con solamente un proceso. Si tienes un programa que usa varios hilos, entonces la sección crítica es liviana y adecuada para tus necesidades. Sin embargo, cuando escribes una DLL, es muy posible que diferentes procesos usen la DLL en el mismo momento. En este caso, debes usar mutexes, en lugar de secciones críticas.”

Veremos en la imagen, que genera un código único, que se utiliza como nombre del mutex, para crearlo, con la API CreateMutexA.

Seguido de esto, parece que nuestro troyano necesita descomprimir una dll denominada bcdsa.dll, veamos:

EAX apunta al string C:\WINDOWS\system32\bcdsa.dll.

El ejecutable busca el archivo bcdsa.dll y si no existe, lo crea.

Luego de crear la DLL, descomprime el segundo EXE como hemos visto que el path estaba en memoria y crea el Thread finalmente con la DLL deseada. Capturemos la DLL, para futuro análisis.

Si vamos a buscar la DLL y vemos propiedades encontraremos una descripción extraña:

O es una librería que necesitará el flashfxp final o es algo más…

Luego de que el Thread es creado, nos aparecerá la ventanita con el mensaje: “c:\windows\system32″, esto es lo que me hizo sospechar de la actividad de este ejecutable. Es una falla de programación importante, ya que se da a conocer muy sencillamente, parece que el programador tenía pocos recursos para poder darse cuenta cuando la DLL estaba cargada en memoria…

Ahora veremos el segundo ejecutable.

Una vez que nuestro amigo está descomprimido veremos que al cargarlo está hecho en C, por eso mismo carga nuestra DLL, que se trata nada más ni nada menos de las MFC, librerías runtime necesarias.

Este EXE, descomprimirá el FlashFXP final, pero además agregará la descompresión de un downloader… para fines non santos…

El ejecutable de FlashFXP será descomprimido en c:\windows\ bajo el nombre de setup.exe

En esta imagen, podemos ver como ejecuta a FlashFXP original y a su vez, descomprime y crea el downloader, cuyo nombre es aleatorio.

Finalmente, tratará de ejecutar el Downloader, como veremos acá:

Por último el proceso termina, llamando a ExitProcess.

Entonces si queremos nuestro EXE final de FlashFXP, directamente lo buscamos en la carpeta Windows de nuestro sistema.

Nos damos cuenta que el EXE es el original, porque al hacer botón derecho y propiedades, veremos los datos originales de la aplicación. Lo cuál ante un usuario atento, se dará cuenta que los otros ejecutables no son los originales.

Es importantísimo poder tener firmado los ejecutables de nuestras aplicaciones, además de poder tener la información guardada como propiedades del ejecutable, de manera que un usuario puede verificar la autenticidad de varias maneras.

Siempre hay que estar atento a actividades extrañas, como por ejemplo la ventana que sale a modo de información avisando que la DLL ya fue creada, para poder continuar la descompresión…. como lo vimos anteriormente.

Eso es todo, espero que les haya servido y gustado.

Nos vemos la próxima.

convert this post to pdf.

  En el presente escrito se abordará la resolución del CrackME de hispasec, llamado a partir de ahora crackme o reto, detallando las siguientes partes.

•  ¿Qué se pretende?
•  Encontrando la zona de interés.
•  Análisis del algoritmo.
•  Generación de un fichero válido.
•  Fallos de diseño.
•  Despedida y cierre.

  El crackme y el fichero de licencia lo podeis encontrar en el siguiente enlace.

• CrackME!

  El objetivo de este reto, es generar un fichero de licencia válido y explicar los fallos de diseño encontrados en los hilos. Quiero comentar que en este documento encontraremos lo que a mi juicio son fallos de diseño, no tienen porque coincidir con los criterios de los autores del reto. Para la resolución de este reto se ha utilizado un depurador y un editor hexadecimal, en mi caso he optado por Ollydbg y por Hex Workshop.    

  Para llegar a la zona que nos interesa analizar, y sabiendo de antemano que necesitamos un fichero de licencia, tenemos varia maneras de abordar nuestro cometido; explicaré un par de ellas.

•  Localizando la función de chequeo mediante referencias a cadenas.

Nada más cargar nuestro reto en el depurador, parados en el oep, buscamos referencias a cadenas con search for > All referenced text strings. Obtenemos esto.

Podemos ver las cadenas “crackem.lic”, “Good job!” y “Keep trying”, es evidente que nuestro objetivo es “Good job”. Seguimos la cadena y caemos en este punto.  

En función de un par de comparaciones carga una de las cadenas. Seguimos el código hacia arriba, para ver donde se inicia esta función.

Aquí encontramos el inicio de la función, en la dirección 004010B0, vamos a fijarnos un momento que llama a la API CreateFileA, pero el atributo Mode es OPEN_EXISTING. Esto es importante para el siguiente punto.

•  Localizando la función de chequeo utilizando la API de Windows.

Ahora vamos a utilizar la API de Windows para llegar al mismo punto. Nada más cargar nuestro reto en el depurador, parados en el oep, buscamos referencias a APIs cargadas con search for > Name (label) in current module. Obtenemos esto.

Vamos a poner un BP en cada API específica de ficheros.

KERNEL32.CreateFileA

KERNEL32.GetFileSize

KERNEL32.GetFileType

KERNEL32.ReadFile

KERNEL32.WriteFile

Ejecutamos varias veces y vemos unas cuantas paradas antes de llegar a este BP en la dirección 004010CB, tal como vemos en esta imagen.

Seguimos el código hacia arriba, para ver donde se inicia esta función. Encontramos el inicio en la dirección 004010B0.

Como ya hemos localizado la función de chequeo, ahora vamos a centrarnos en analizarla.

La función comprueba que existe el fichero “crackme.lic” , mira el tamaño del fichero, crea un buffer para guardar los datos, vuelca el contenido del fichero en el buffer creado, lanza los hilos que comprueban si los datos que hemos volcado son válidos y analiza el resultado de los hilos para decidir que cadena muestra. Esto corresponde al siguiente esquema.

Bueno, lo realmente interesante esta en los hilos de ejecución, así que vamos a ver que es lo que hacen los mismos. Vamos a fijarnos en el argumento Thread Function, vemos que tiene el parámetro 00401000, este es el inicio de la función que ejecuta el hilo.

Los bytes del fichero llave deben ser menores de 0Ah, es decir menores de 10d, si el hilo encuentra un byte igual a FFh, termina el análisis. Si nos fijamos, la función tiene dos salidas, una en la que realiza un “XOR EAX,EAX” o lo que es lo mismo, poner EAX a 0; y otra que realiza un “MOV EAX,1″ o lo que es lo mismo, poner EAX a 1.

¿Cómo conseguimos poner EAX a 1?, si solucionamos esta pregunta, tenemos solucionado el problema; para conseguir la ejecución de ese salto, debemos lograr que el resultado de AL tras la ejecución del código sea igual a 09h. Veamos más claramente la ejecución.

El proceso le el primer byte del fichero, carga otro byte que utiliza para los cálculos, vamos a llamarlo byte auxiliar o aux; este byte, al principio va a estar a 0. Tras esto realiza una operación con este byte, aux = aux + 4*aux, esto lo guarda en edx. Carga en bl el dato leído del fichero y este dato junto con aux, lo utiliza para acceder a una tabla de bytes; el calculo es el siguiente desplazamiento = dato + aux * 2.

En nuestro caso necesitamos un desplazamiento de 48h, si no conseguimos cargar el 09h, el byte apuntado se convierte en el nuevo aux. Y esto se repite hasta encontrar FFh.

Bueno, conociendo el algoritmo, es fácil generar un fichero válido, solo necesitamos conocer la tabla de bytes que hemos comentado anteriormente. Es la siguiente (las cabeceras de la tabla están representadas en decimal.).

1 .- Bytes hexadecimales.

Necesitamos conseguir un desplazamiento de 72d bytes. Para ello vamos a realizar las siguientes operaciones.

Aux = 0 (la primera pasada del algoritmo).

Data = 06 (Primer byte del fichero).

0 + 0*4 = 0.

6 + 0*2 = 6.

Cargamos el byte que hay con desplazamiento 6; el 04.

No es 09, por tanto lo usamos como nuevo aux.

Aux = 04.

Data = 07 (Segundo byte del fichero).

4 + 4*4 = 20.

7 + 20*2 = 47.

Cargamos el byte que hay con desplazamiento 46; el 08.

No es 09, por lo tanto lo usamos como nuevo aux.

Aux = 08.

Data = 01 (Tercer byte del fichero).

8 + 8*4 = 40.

1 + 40*2 = 81

Cargamos el byte que hay con desplazamiento 81; el 07;

No es 09, por lo tanto lo usamos como nuevo aux.

Aux = 07.

Data = 02 (Cuarto byte del fichero).

7 + 7*4 = 35.

02 + 35*2 = 72.

Cargamos el byte que hay con desplazamiento 72; el 09.

Es 09, por lo tanto terminamos en el return que nos interesa.

Si nos fijamos, el segundo hilo, utiliza exactamente la segunda función, además, la tabla de bytes no es modificada, por tanto, sólo tenemos que duplicar la cadena de bytes obtenida anteriormente y replicarla. Al final, añadimos el byte de fin que utiliza el programa, el FFh.

La cadena de bytes que necesitamos escribir para generar un fichero válido es la siguiente: “0607010206070102FF”. Esto lo podemos hacer con nuestro editor hexadecimal preferido. Una vez realizado esto, tenemos solucionado este reto.

A continuación, comento lo que a mi juicio son fallos de diseño en el algoritmo.

•  Existe un fragmento de código, que no es necesario para la resolución del reto,

00401070   .  68 CE070000   push 7CE

00401075   .  FFD6                call esi                                 ;  kernel32.Sleep

00401077   .  EB 04               jmp short crackme.0040107D

0040107D   > \E8 67010000  call crackme.004011E9

00401082   .  99                     cdq

00401083   .  B9 32000000   mov ecx,32

00401088   .  F7F9                idiv ecx

0040108A   .  52                    push edx

0040108B   .  FFD6               call esi                                 ;  kernel32.Sleep

Si se ha utilizado a modo de código basura, debería de repartirse más por la función o diseñarse de alguna otra manera ya que es muy obvio comprobar que no es necesario analizarlo para la resolución del reto.

•  Los dos hilos que se lanzan para comprobar el fichero llave, utilizan la misma función y esta hace exactamente lo miso. Podríamos haber solucionado esto utilizando por ejemplo dos puntos de entrada para la función o una modificación de la misma. Otra opción hubiese sido utilizar otra función que comprobase otras propiedades del los bytes del fichero.

•  Al utilizar el segundo hilo para chequear los bytes del fichero, si no hemos modificado la función ni hemos utilizado otra función distinta, al menos deberíamos haber cambiado la tabla de bytes para forzar un nuevo cálculo de la segunda parte de los bytes del fichero.

Un Saludo a los miembros de Disidents.org, al canal #crackers, a thEpOpE, a NoMuRyTo y a toda la gente que me dejo pero sabe que puede darse por saludada. Espero que no seais muy duros en las críticas de mi primera publicación.

convert this post to pdf.