Este es un crackme de la web de Karpoff programado por Sotanez y realizado en Delphi. Como máximo nos deja meter nombres de 10 dígitos.
El algoritmo
Es un algoritmo muy sencillo pero veremos que nos tendremos que fijar en el DUMP de Olly para saber que demonios hace. Como de costumbre abrimos Olly y en las «Referenced Strings» localizamos la palabra «Registrado«, pinchamos en ella y localizamos la porción de código que nos interesa. Vamos a analizarla.
Vemos 3 bucles, el primero pone la memoria (Dump) a cero, el segundo guarda nuestro nombre (errata en la imagen) en el Dump y el tercero realiza la suma de los valores ascii del nombre. Hasta aquí todo bien, pero vamos a hacer una prueba para el nombre deurus.
Nombre: deurus
Serial: 64+65+75+72+75+73 = 298 (664 en decimal)
Probamos el serial en el programa y nos da error, vale, vamos a analizar más a fondo los bucles.
El primer bucle hemos dicho que pone la memoria a 0, en concreto desde «45BC60» y de 4 en 4 (fíjate en el Add 4), es decir, pone a 0 los offsets 45BC60, 45BC64, 45BC68, 45BC6C, 45BC70, 45BC74, 45BC78, 45BC7C, 45BC80, 45BC84, ya que el bucle se repite 10 veces. En la imágen queda claro.
El segundo bucle se repite 11 veces y lo que hace es guardar en el dump el valor ascii de las letras de nuestro nombre. En la imagen lo vemos.
A primera vista ya vemos un valor extraño en la posición 45BC80, y es que cuando debiera haber un 0, hay un 12. Vamos a ver como afecta esto al serial final.
El tercer bucle se repite 10 veces y lo que hace es sumar los valores que haya en el DUMP en las posiciones anteriormente citadas.
En concreto suma 64+65+75+72+75+73+0+0+12+0 = 2AA (682 en decimal). Probamos 682 como serial y funciona. Realizando más pruebas vemos que para nombres con un tamaño inferior a 5 letras se ocupan las posiciones 45BC70 y 45BC80 con valores extraños, el resto de posiciones se mantienen a 0. En las imágenes inferiores se pueden apreciar más claramente los valores extraños.
Nombre de tamaño < 5.
Nombre de tamaño >5 y <9
Nombre de tamaño = 10
En resumen:
Nombre de tamaño < 5 –> Ascii SUM + 14h Nombre de tamaño >5 y <9 –> Ascii SUM + 12h Nombre de tamaño =10 –> Ascii SUM
Con esto ya tenemos todo lo que necesitamos para nuestro keygen.
char Nombre[11];
GetWindowText(hwndEdit1, Nombre, 11);
char Serial[20];
int len = strlen(Nombre);
int suma = 0;
for(int i = 0; i <= len; i = i + 1)
{
suma += Nombre[i];
}
if(len < 5){
suma +=0x14;
}
if(len > 5 && len < 9){
suma +=0x12;
}
wsprintf(Serial,"%d",suma);
SetWindowText(hwndEdit2, TEXT(Serial));
Warning: This challenge is still active and therefore should not be resolved using this information. Aviso: Este reto sigue en activo y por lo tanto no se debería resolver utilizando esta información.
Few years ago, I made the tool ART (Android Reverse Engineering) for automate the process of reverse android program, but I have to admit that APK Studio is a great tool or just a great alternative. This crackme is for the challenge Mobile 1 of canyouhack.it.
Decompiling
The crackme is given at Google Play, so the first step is to install and recover the APK for decompiling. The latter, I leave to you. Open the victim with APK Studio and view the content of Mobile1.java
Analyzing the code, we view that the correct password is “The*********r”.
Aviso: Este crackme forma parte de una serie de pruebas de Yoire.com que todavía está en activo. Lo ético si continuas leyendo este manual es que no utilices la respuesta para completar la prueba sin esfuerzo. 😉
Analizando…
Cargamos el crackme en Ollydbg y vamos a las «Referenced Strings«. Vemos una referencia muy interesante que se llama «checkkey«.
Pinchamos sobre ella y aparecemos aquí:
Vemos una referencia a «GetDlgItemTextA» y depués un Call también interesante, vamos a explorarlo.
Entendiendo la rutina de comprobación del serial
Dentro del Call hay dos bucles, uno realiza una operación con nuestro serial (bucle nombre) y el otro comprueba nuestro serial con «3d34273130276a» dígito a dígito (bucle comprobación).
MOV EDX,10006000 --> EDX = "3d34273130276a"
...
MOV AL,BYTE PTR DS:[ECX] --> AL = 1ºdígito serial xoreado
CMP AL,BYTE PTR DS:[ECX+EDX] --> AL = 1ºdígito de EDX?
JNZ SHORT 1000105A --> Si no son iguales bad boy
INC ECX
TEST AL,AL
JNZ SHORT 1000104A --> bucle
Ejemplo para «deurus».
Nombre: d e u r u s Ascii hex: 64 65 75 72 75 73 XOR 55: 31 30 20 27 20 26
Serial XOReado para deurus sería = 313020272026 que obviamente se aleja bastante de 3d34273130276a.
Por suerte XOR es una función reversible por lo que si revertimos 3d34273130276a nos dará el serial correcto.
Serial correcto XOReado: 3d 34 27 31 30 27 6a
XOR 55: 68 61 72 64 65 72 3F Valor ascii: h a r d e r ?
Os comparto un reto stego que me gustó cuando lo hice hace unos años. En realidad se tarda pocos minutos en resolverlo pero depende de tus recursos es posible que se te atragante.
Procesando a la víctima
Cuando te has enfrentado a unos cuantos retos stego lo normal es que tengas un arsenal de herramientas por las que vas a pasar a la víctima. En mi caso cuando se trata de imágenes, mi fondo de armario está formado por steganabara y stegsolve. Si con esas dos herramientas no lo veo claro ya empiezo a mirar en sus entrañas y en este caso es justo lo que hace falta, mirar en su interior.
La víctima
imagen original del reto
Estamos ante una imagen GIF de 6,36KB (6513 bytes) cuya resolución es 236×42. Debido a la extensión tenderemos a analizar los frames por si se trata de una animación. Una vez desestimada la animación entran en juego steganabara, stegsolve y demás familia. Si todo lo anterior falla abro el archivo con un editor hexadecimal y lo reviso manualmente por si hay algo que me llama la atención.
Bytes
Explorando el interior del archivo enseguida encontramos algo que llama la atención, una sucesión de bytes con espacios intercalados.
Tras copiar los bytes lo primero es eliminar los espacios y empezar a jugar con ellos. Una de las cosas que podemos hacer es convertir los bytes a ascii y voilá, nos encontramos con lo que parece otro archivo GIF.
Copiamos los bytes con la ayuda de nuestro editor hexadecimal favorito, guardamos el archivo como GIF y reto superado.
La primera entrega de Misión Imposible es ya un clásico y poco o nada tiene que envidiar a sus secuelas. Es ágil, entretenida y como toda peli de espías que se precie, los protagonistas tienen gadgets por un tubo.
El argumento gira sobre la lista NOC. Dicha lista relaciona nombres en clave de agentes repartidos por el mundo con sus nombres reales y al parecer la quiere todo el mundo.
Lista NOC
¿Donde está la lista aquí o aquí?
Al inicio nos hacen creer que la lista NOC está en un sótano de una embajada (No jodas), sin seguridad y accesible por todo el mundo que sepa llegar allí. En esta ocasión no se puede ni llamar hackeo, ya que, el tipo en cuestión simplemente copia la lista (bueno la mitad 😉 en un disco de 3,5″
Tipo robando la lista NOC
¿Eso son Emails o Newsgroups?
Aquí empieza la locura. ¿Os acordáis del BTM de Dexter donde empieza a escribir en foros aleatorios con la esperanza de contactar con el carnicero de la bahía?, pues aquí lo mismo pero con grupos de noticias o newsgroups.
La cosa es que a Ethan Hank no se le ocurre mejor idea para encontrar a Max que buscar en todo tipo de grupos de noticias relacionados con temas bíblicos y en concreto con el libro de Job. Vamos a ver Ethan, hijo del metal, eso es una puta locura, ya de paso anúnciate en el periódico y ponte una diana en el pecho. Pero como es una película resulta que funciona. El caso es que parece que existen la ostia de grupos de discusión donde incluso se puede hablar sobre un capítulo y versículo en particular.
Newsgroup sobre el Libro de Job
El error
El problema es que en cada grupo que encuentra escribe un mensaje muy parecido a como se escribe un email y claro, queda un poco mal. Tanto si quieren hacer creer que escriben un email como si no, el caso es que la escena pierde credibilidad. Ni podría ser un email ni parece factible que alguien se ponga ese nombre de usuario, en definitiva, una chapuza.
¿Parece un email no?
Os dejo una serie de imágenes para que os deleitéis.
Aquí tenemos un crackme clásico realizado en Visual C++. La única particularidad que tiene es que no muestra MessageBox al introducir bien o mal el serial, simplemente cambia una imagen de un emoticono. Si observamos el comportamiento del crackme notaremos que inicialmente el emoticono está neutral y al fallar se pone triste y por lo tanto es de suponer que al acertar se pondrá contento.
El BreakPoint
Intermodular Calls
Al mirar en las Intermodular Calls de OllyDbg vemos que LoadIconA es un buen candidato para ubicar la comprobación del serial. Si nos fijamos hay tres llamadas, ponemos un breakpoint en las tres y enseguida llegamos a la zona de comprobación del serial.
La comprobación es muy sencilla, en resumen hace esto con todas las letras del nombre excepto la última:
1º Caracter
(1ºname + 1ºserial - 2 = X)
(X / 2)
(X + 1)
(2ºname - 2 = Y)
¿Y = X?
2º Caracter
(2ºname + 2ºserial - 2 = X)
(X / 2)
(X + 1)
(3ºname - 2 = Y)
¿Y = X?
...
Con el último caracter del nombre hace lo siguiente:
(6ºname + 6ºserial - 2 = X)
(X / 2)
(X + 1)
(2ºname - 2 = Y)
¿Y = X?
---------
Para revertir la primera parte de la comprobación para el nombre deurus quedaría:
X1 = (((2ºname-2-1)*2)+2)-1ºname
X2 = (((3ºname-2-1)*2)+2)-2ºname
X3 = (((4ºname-2-1)*2)+2)-3ºname
X4 = (((5ºname-2-1)*2)+2)-4ºname
X5 = (((6ºname-2-1)*2)+2)-5ºname
X6 = (((2ºname-2-1)*2)+2)-6ºname
Keygen
var nombre = "deurus";
nombre = nombre.toUpperCase();
var serial = "";
var tmp = "";
var i;
for (i = 0; i < nombre.length-1 ; i++) {
tmp = ((nombre.charCodeAt(i+1)-2-1)*2+2)-nombre.charCodeAt(i);
serial += String.fromCharCode(tmp);
}
tmp = ((nombre.charCodeAt(1)-2-1)*2+2)-nombre.charCodeAt(nombre.length-1);
serial += String.fromCharCode(tmp);
document.write(serial);
El reto consiste en dos imágenes (v1.png y v2.png) que, a simple vista, parecen contener ruido aleatorio. Sin embargo, ambas forman parte de un sistema de criptografía visual en la que cada imagen contiene información parcial que no es interpretable por separado, pero que al combinarse correctamente revelan informaciónoculta.
La trampa está en que la combinación no se hace con operaciones normales como suma, resta o multiplicación. El autor del reto espera que el jugador use una herramienta como StegSolve y pruebe distintas operaciones tipo XOR, AND o MUL hasta encontrar una transformación en la que uno de los métodos muestre algo significativo. El truco está en llegar a la conclusión de que una de las imágenes hay que invertirla antes de combinar ambas imágenes. Todo esto se puede hacer con StegSolve sin necesidad de utilizar ninguna herramienta adicional, pero voy a aprovechar para hacerlo con python y así de paso entendemos como realiza las operaciones StegSolve. En resumen, para resolver el reto basta con:
Invertir (Colour Inversion XOR) una de las imágenes.
Combinar ambas imágenes mediante Analyse > Combine images.
Operación MUL del combinador.
La operación MUL no es una multiplicación normalizada, sino una multiplicación de enteros de 24 bits (0xRRGGBB) con overflow, algo que la mayoría de herramientas no replican correctamente.
¿Por qué aparece la solución con esa combinación
Las imágenes están preparadas para que ciertos bits de color en una imagen sean el complemento de los de la otra. Por tanto:
Si se muestran tal cual → parecen ruido
Si se combinan mediante XOR → parte de la estructura aparece, pero no se ve el resultado correcto
Si se combinan mediante MUL «normal» → tampoco aparece
Si se aplica la multiplicación bitwise exacta usada por StegSolve → se alinean las partes ocultas
La operación MUL de StegSolve no es una multiplicación de píxeles, es decir, no hace:
