Tal y como nos adelanta el creador está programado en .NET. Lo abrimos para ver su comportamiento y a simple vista ya vemos algo que no nos gusta y es que se abre una ventana de DOS y posteriormente aparece el crackme. Esto indica que el ejecutable está escondido dentro de otro, empaquetado, encriptado o vete a saber.
Desempaquetado
Nuestras sospechas eran ciertas, abrimos el executable con ILSpy y no encontramos lo que buscamos, pero si vemos que al assembly se le hace algo parecido a un XOR. Probemos con algo sencillo, abrimos el crackme y la herramienta .Net Generic Unpacker y probamos a desempaquetar.
Esto nos genera un par de «exes» que ahora si abre correctamente nuestro decompilador.
Decompilado
Vamos a fijarnos en la rutina de comprobación del serial. Lo interesante se encuentra en btnCheckClick y TLicense.
Código fuente.
Como vemos en el código, License.a.a, License.a.b y License.a.c cogen 8 dígitos y License.a.d coge 10. A continuación comprueba que Licenseb.a = License.a.a XOR License.a.b y que Licenseb.b = License.a.c XOR License.a.d.
Una imagen vale más que mil palabras.
En su día hice un keygen, aquí teneis una captura.
Podeis encontrar el crackme, mi solución y otras soluciones en crackmes.de.
Hoy tenemos un crackme realizado en Visual C++ 6. Es el típico serial asociado a un nombre.
El algoritmo
Localizamos con Olly la rutina de comprobación del serial y empezamos a analizar. Vemos una serie de Calls que lo único que hacen es comprobar el tamaño de nuestro nombre y serial y si es <5 dígitos nos tira afuera.
Una vez pasada la traba anterior procede con un bucle para el nombre y otro para el serial. Yo he metido deurus y 123456. El bucle del nombre hace xor al los dígitos ascii con un valor incremental a partir de 1. Reconvierte el valor resultante en su caracter correspondiente y lo almacena.
AperiSolve es un conjunto de herramientas de análisis esteganográfico que nos ayuda a echar un primer vistazo cuando sospechamos que una imagen esconde algo.
Zsteg es una herramienta especializada en la detección y extracción de información oculta en imágenes, especialmente en formatos PNG y BMP. Está orientada a la esteganografía basada en bit-planes y es muy popular en entornos CTF y análisis forense, gracias a su capacidad para automatizar búsquedas exhaustivas de datos escondidos en los bits menos significativos (LSB) y en configuraciones de color poco habituales. Su principal fortaleza es que no se limita a examinar un único plano: prueba sistemáticamente combinaciones de canales (R, G, B, A), número de bits, orden de lectura y posicionamiento, detectando patrones que podrían pasar inadvertidos en una revisión manual.
Entre sus características más destacadas se encuentran la identificación automática de firmas de archivos (ZIP, PNG, texto ASCII, GZIP, etc.), la extracción directa de bitstreams reconstruidos y el soporte para diferentes rutas de exploración, como b1,rgb,lsb,xy, que describen exactamente cómo se han recuperado los datos. Esta capacidad de correlacionar parámetros técnicos con resultados concretos convierte a zsteg en una herramienta muy eficiente tanto para localizar contenido oculto como para entender la técnica esteganográfica aplicada.
En AperiSolve se utiliza únicamente la parte de Zsteg encargada de ejecutar el análisis automático y devolver todas las detecciones posibles de esteganografía LSB en imágenes PNG y BMP. Concretamente, AperiSolve llama al comando zsteg <imagen> tal como está implementado en el módulo analyze_zsteg , y captura la salida completa línea por línea. Esta salida incluye todas las combinaciones probadas de bit-planes (b1, b2…), canales (r, g, b, a), orden de bits (lsb/msb) y métodos de recorrido (xy), junto con cualquier coincidencia que zsteg reconozca como firma de archivo o texto. Es decir, AperiSolve no aplica filtros ni interpretación adicional: muestra exactamente lo que zsteg detecta y lo organiza para que el usuario pueda identificar rápidamente si existe un archivo embebido, contenido ASCII, o algún patrón de interés.
Para entender mejor a que se refiere todo esto vamos a repasar lo básico.
¿Qué es LSB y qué es MSB?
Cuando hablamos de esteganografía en imágenes PNG/BMP, nos referimos a manipular bits dentro de los canales de color (R, G, B, A). Cada canal tiene un valor de 0–255, es decir, 8 bits:
R = 11001010
G = 00110101
B = 11100001
LSB — Least Significant Bit (bit menos significativo). Es el bit más débil, el de la derecha:
1100101[0] ← LSB
Modificarlo cambia muy poco el color, por eso se usa en esteganografía. Ejemplo: cambiar 11001010 ↦ 11001011 no cambia el color perceptible.
MSB — Most Significant Bit (bit más significativo). Es el bit más importante, el de la izquierda:
[1]1001010 ← MSB
Modificarlo sí altera mucho el color. A veces se usa pero suele ser detectable.
Cuando Zsteg muestra una línea del estilo b1,rgb,lsb,xy .. file: Zip archive data, está indicando que ha analizado la imagen extrayendo bits según la ruta especificada —en este caso, 1 bit por píxel (b1), combinando los canales rojo, verde y azul (rgb), utilizando el bit menos significativo (lsb) y recorriendo los píxeles en orden normal de lectura (xy)— y que, tras recomponer esos bits, el resultado coincide con la cabecera reconocible de un tipo de archivo real. Por eso aparece “file: Zip archive data”: significa que los bits ocultos forman un flujo válido cuya firma corresponde a un archivo ZIP. En otras ocasiones puede detectar texto ASCII, PNG, JPEG u otros formatos. En resumen, cuando Zsteg muestra esta línea no solo indica dónde se ocultan los datos, sino que confirma que lo recuperado es un archivo auténtico y probablemente extraíble, ya que la estructura binaria coincide con un formato conocido.
Si vemos que Zsteg nos ofrece algo interesante, podemos extraerlo mediante el comando:
zsteg -E b1,rgb,lsb,xy imagen.png > dump.bin
También es habitual usar herramientas como StegSolve. En este caso debemos dirigirnos a Analyse > Data extract para comprobar lo encontrado por zsteg y extraerlo mediante Save Bin.
Zsteg
> Significado <
StegSolve
b1
Extrae 1 bit por canal (bit plano 0, el menos significativo).
En Bit Planes, marca Red 0, Green 0, Blue 0. Solo esos.
rgb
Usa R + G + B en ese orden para reconstruir los bytes.
En Bit Plane Order, selecciona RGB.
lsb
Lee los bits empezando por el LSB (bit 0) antes que el MSB.
En Bit Order, selecciona LSB First.
xy
Recorre la imagen por filas (izquierda → derecha, arriba → abajo).
En Extract By, elige Row.
Más allá de este caso concreto, conviene recordar que la esteganografía no se limita a los LSB: existen métodos basados en paletas, metadatos, manipulación de PNG chunks, secuencias alfa, audio incrustado o capas completas en formatos no comprimidos. Por ello, un análisis completo debería combinar la búsqueda clásica de LSB con herramientas complementarias como binwalk, foremost, exiftool, strings, o incluso análisis manual de cabeceras hexadecimales.
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.
El algoritmo
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.
Recapitulando
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».
Siguiendo con los crackmes que contienen RSA, esta vez tenemos un Keygenme del grupo PGC (Pirates Gone Crazy) que incluso servía para ser admitido en el grupo si mandabas la solución. Como veremos usa RSA32 + MD5 y en la parte de RSA ni siquiera usa el descifrado por lo que es de los sencillitos.
Resumen RSA
Parámetros
p = Primer número primo
q = Segundo número primo
e = Exponente público que cumpla MCD(e,(p-1)*(q-1))==1
n = Módulo público siendo n=p*q
d = Exponente privado que cumpla d=e^(-1) mod ((p-1)*(q-1))
De este modo e y n son la parte pública de la clave y d y n la parte privada. Los número primos p y q se utilizan solo para generar los parámetros y de ahí en adelante se pueden desechar.
Funciones de Cifrado/Descifrado
cifrado = descifrado ^ e mod n
descifrado = cifrado ^ d mod n
Debug
En las referencias de texto se ven a simple vista el exponente públicoe (10001) y el módulo n (8e701a4c793eb8b739166bb23b49e421)
Text strings referenced in RSA32+MD:.text
Address Disassembly Text string
00401848 PUSH RSA32+MD.00404104 ASCII "%.8x%.8x%.8x%.8x"
00401A72 PUSH RSA32+MD.0040429C ASCII "[PGCTRiAL/2oo2]"
00401AEE PUSH RSA32+MD.00404275 ASCII "10001"
00401AFE PUSH RSA32+MD.0040427B ASCII "8e701a4c793eb8b739166bb23b49e421"
00401B43 PUSH RSA32+MD.00404404 ASCII "Name Must Be >= 1 Character."
00401B57 PUSH RSA32+MD.00404421 ASCII "Key Must Be >= 1 Character."
00401B6D PUSH RSA32+MD.0040443D ASCII "Congratulations!"
00401B72 PUSH RSA32+MD.0040444E ASCII " You've done it!
Please send your keygen along with
source code to pgc@dangerous-minds.com
if you would like to be considered as
a new member of PGC."
00401BE7 PUSH 0 (Initial CPU selection)
00401C47 MOV [DWORD SS:EBP-24],RSA32+MD.00404119 ASCII "PGCWinClass"
00401C7C MOV [DWORD SS:EBP-24],RSA32+MD.0040424E ASCII "STATIC"
00401CDB PUSH RSA32+MD.00404115 ASCII "PGC"
00401CE0 PUSH RSA32+MD.00404119 ASCII "PGCWinClass"
00401D13 PUSH RSA32+MD.00404125 ASCII "EDIT"
00401D46 PUSH RSA32+MD.00404125 ASCII "EDIT"
00401DFB PUSH RSA32+MD.00404115 ASCII "PGC"
00401E00 PUSH RSA32+MD.0040424E ASCII "STATIC"
Como vemos comprueba que tanto el nombre como el número de serie tengan al menos un dígito y a continuación comienza el chequeo del serial. El chequeo es muy sencillo ya que ni siquiera tenemos que buscar los números primos p y q y a continuación n, simplemente podemos obtener el número de serie con la parte pública de la clave (par de número e y n). Lo resumimos a continuación:
Concatena nuestro nombre con la cadena «[PGCTRiAL/2oo2]»
Crea el hash MD5 de la cadena concatenada.
Cifra el hash usando el par de números e y n obtenidos en las referencias de texto.
//
// md5(deurus[PGCTRiAL/2oo2]) = dc8a39282da8539d11b8a6aec000c45a
//
var c = BigInt("0xdc8a39282da8539d11b8a6aec000c45a");
var e = BigInt("0x10001");
var n = BigInt("0x8e701a4c793eb8b739166bb23b49e421");
//
var serial = BigInt(0);
serial = powmod(c, e, n);
document.write(serial.toString(16));
//
//POWMOD
//
function powmod(base, exp, modulus) {
var accum = BigInt("1");
var i = BigInt("0");
var basepow2 = BigInt(base);
while ((BigInt(exp) >> BigInt(i) > BigInt(0))) {
if (((BigInt(exp) >> BigInt(i)) & BigInt(1)) == BigInt(1)) {
accum = (BigInt(accum) * BigInt(basepow2)) % BigInt(modulus);
}
basepow2 = (BigInt(basepow2) * BigInt(basepow2)) % BigInt(modulus);
i++;
}
return BigInt(accum);
}
Continuamos con la segunda entrega de Cruehead. En este caso nos encontramos con un único campo de contraseña para introducir.
El algoritmo
Abrimos con Olly y vemos dos saltos. El primer Call realiza una serie de operaciones con el serial introducido y el segundo comprueba si el serial es correcto.
A continuación llegamos aquí:
00401365 /$ C605 18214000 00 MOV BYTE PTR DS:[402118],0
0040136C |. 8B7424 04 MOV ESI,DWORD PTR SS:[ESP+4]
00401370 |. 56 PUSH ESI
00401371 |> 8A06 /MOV AL,BYTE PTR DS:[ESI] ; <---
00401373 |. 84C0 |TEST AL,AL
00401375 |. 74 19 |JE SHORT CRACKME2.00401390
00401377 |. FE05 18214000 |INC BYTE PTR DS:[402118]
0040137D |. 3C 41 |CMP AL,41 ; 41 = A
0040137F |. 72 04 |JB SHORT CRACKME2.00401385 ; ya es mayúscula
00401381 |. 3C 5A |CMP AL,5A ; 5A = Z
00401383 |. 73 03 |JNB SHORT CRACKME2.00401388 ; Convertir a mayúscula
00401385 |> 46 |INC ESI
00401386 |.^ EB E9 |JMP SHORT CRACKME2.00401371 ; Bucle -->
00401388 |> E8 25000000 |CALL CRACKME2.004013B2
0040138D |. 46 |INC ESI
0040138E |.^ EB E1 \JMP SHORT CRACKME2.00401371
00401390 |> 5E POP ESI
00401391 |. E8 03000000 CALL CRACKME2.00401399 ;Convertido a mayúsculas continuamos
00401396 |. EB 00 JMP SHORT CRACKME2.00401398
00401398 \> C3 RETN
Si nuestro serial contiene solo letras, las convierte a mayúsculas y seguimos aquí. En resumen hace XOR byte a byte entre nuestro serial y la frase «Messing_in_bytes»
00401399 /$ 33DB XOR EBX,EBX
0040139B |. 33FF XOR EDI,EDI
0040139D |> 8A8F A3214000 /MOV CL,BYTE PTR DS:[EDI+4021A3] ; Carga el primer byte de 4021A3
004013A3 |. 8A1E |MOV BL,BYTE PTR DS:[ESI] ;
004013A5 |. 84DB |TEST BL,BL
004013A7 |. 74 08 |JE SHORT CRACKME2.004013B1
004013A9 |. 32D9 |XOR BL,CL ; byteSerial XOR Byte"Messing_in..."
004013AB |. 881E |MOV BYTE PTR DS:[ESI],BL
004013AD |. 46 |INC ESI ;Siguiente byte de "Messing_in_bytes"
004013AE |. 47 |INC EDI ;Siguiente byte del serial
004013AF |.^ EB EC \JMP SHORT CRACKME2.0040139D
004013B1 \> C3 RETN ;XOR finalizado volvemos
Estado del DUMP (memoria) antes del XOR y con nuestro serial (12345678) cargado.
Si buscamos el comando REPE encontramos que si el flag Z = 1 el bucle se corta y que trabaja con bytes. El problema es que en Olly la instrucción REPE nosotros la vemos con un solo paso y nos puede pasar desapercibida.
En resumen, está comprobando los bytes de las direcciones 402150 (1F 2C 37 36 3B 3D 28 19 3D 26 1A 31 2D 3B 37 3E) con nuestro serial XOReado, 40217E en adelante, por lo que si hacemos XOR entre los bytes de 402150 y la frase «Messing_in_bytes» obtendremos la clave correcta.
M e s s i n g _ i n _ b y t e s
4D 65 73 73 69 6E 67 5F 69 6E 5F 62 79 74 65 73
XOR
1F 2C 37 36 3B 3D 28 19 3D 26 1A 31 2D 3B 37 3E
-----------------------------------------------
52 49 44 45 52 53 4F 46 54 48 45 53 54 4F 52 4D
R I D E R S O F T H E S T O R M
Serial: RIDERSOFTHESTORM
Para parchear un ejecutable realizado en .Net primero necesitamos ubicarnos. Abrimos IL Dasm y vamos al evento «Form_Load«, nos fijamos en los bytes y los buscamos con un editor hexadecimal. Fijaros bien en los bytes ya que siguen un orden específico, en la imágen del editor hexadecimal se aprecia perfectamente. Para que quede parcheada la Nag basta con sustituir los valores por ceros. Se parchea todo excepto el «RET (2A)».
Para la otra Nag sería lo mismo.
El algoritmo
El algoritmo es muy sencillo, consiste en la concatenación de varias palabras y un número aleatorio. El problema viene con el número aleatorio ya que lo tendremos que parchear para poder registrar el programa.
Buscamos el evento click en IL Dasm y nos fijamos que aparece el número «5F5E0FF» que en decimal equivale a «99999999«, buscamos los bytes en el editor hexadecimal y lo parcheamos a 1. De este modo anulamos la aletoriedad, ahora el número siempre es 1.
Recién rescatados del inframundo que es mi disco duro, os traigo un paquete de seis crackmes facilones para vuestro uso y disfrute. Desgraciadamente ya no está en activo la web de retos de donde los saqué así que os los dejo en descargas.
Los cuatro primero están realizados en Dev-C++ 4.9.9.2 siendo de estilo consola de comandos. Los dos restantes compilados con MingWin32 GCC 3.x carecen de GUI y vamos, que no se han esmerado mucho en darles forma.
Level 1
No cuesta mucho dar con el código interesante mediante las referencias de texto. En Ollydbg clic derecho sobre el código y Search for > All referenced text strings.
La madre del cordero está en la dirección 401310 que es donde se lleva a cabo la función de comparación strcmp.
756296A0 msvcrt.strcmp 8B5424 04 MOV EDX,DWORD PTR SS:[ESP+4]
756296A4 8B4C24 08 MOV ECX,DWORD PTR SS:[ESP+8]
756296A8 F7C2 03000000 TEST EDX,3 ; 0-3 = 4 bucles. Divide la comprobación en 4 bloques
756296AE 75 3C JNZ SHORT msvcrt.756296EC ; salta si hemos terminado los 4 bucles
756296B0 > 8B02 MOV EAX,DWORD PTR DS:[EDX] ; coge 4 caracteres del serial (INICIO BUCLE)
756296B2 3A01 CMP AL,BYTE PTR DS:[ECX] ; compara el 1º/5º/9º/13º dígito en función del bucle
756296B4 75 2E JNZ SHORT msvcrt.756296E4 ; salto a zona mala
756296B6 0AC0 OR AL,AL
756296B8 74 26 JE SHORT msvcrt.756296E0
756296BA 3A61 01 CMP AH,BYTE PTR DS:[ECX+1] ; compara el 2º/6º/10º/14º dígito en función del bucle
756296BD 75 25 JNZ SHORT msvcrt.756296E4 ; salto a zona mala
756296BF 0AE4 OR AH,AH
756296C1 74 1D JE SHORT msvcrt.756296E0
756296C3 C1E8 10 SHR EAX,10
756296C6 3A41 02 CMP AL,BYTE PTR DS:[ECX+2] ; compara el 3º/7º/11º/15º dígito en función del bucle
756296C9 75 19 JNZ SHORT msvcrt.756296E4 ; salto a zona mala
756296CB 0AC0 OR AL,AL
756296CD 74 11 JE SHORT msvcrt.756296E0
756296CF 3A61 03 CMP AH,BYTE PTR DS:[ECX+3] ; compara el 4º/8º/12º/16º dígito en función del bucle
756296D2 75 10 JNZ SHORT msvcrt.756296E4 ; salto a zona mala
756296D4 83C1 04 ADD ECX,4
756296D7 83C2 04 ADD EDX,4
756296DA 0AE4 OR AH,AH
756296DC ^ 75 D2 JNZ SHORT msvcrt.756296B0 ; Si no hemos terminado...
756296DE 8BFF MOV EDI,EDI
756296E0 33C0 XOR EAX,EAX ; EAX = 0 que es lo deseado
756296E2 C3 RETN ; salimos de la función superando la comprobación
756296E3 90 NOP
756296E4 1BC0 SBB EAX,EAX ; Zona mala
756296E6 D1E0 SHL EAX,1
756296E8 83C0 01 ADD EAX,1 ; EAX = 1 implica bad boy
756296EB C3 RETN ; salimos de la función
Si atendemos al volcado vemos el serial bueno Kcgcv8LsmV3nizfJ.
Curiosamente, si introducimos el serial bueno el crackme no lo acepta. Fijándome en la comprobación veo que al introducir un serial de 16 caracteres inserta un carácter nulo (0x00) alterando el serial correcto y falseando la comprobación.
Ahora ya no podemos comprobarlo pero recuerdo que la web consideraba válido el serial Kcgcv8LsmV3nizfJ, por lo que considero lo anteriormente citado un bug o un intento de despiste del autor.
Level 2
Es exactamente igual que el anterior cambiando el serial por 6LPw3vDYja9KrT2V.
Level 3
La comprobación del serial es igual a las dos anteriores pero añade una función intermedia que suma 0xD a cada carácter de nuestro serial
En la comparación vemos que el serial bueno es AvrQQsXjDk25Jrh por lo que si restamos 0xD (13 en decimal) a cada carácter obtendremos el serial bueno.
0060FF10 41 76 72 51 51 73 58 6A 44 6B 32 35 4A 72 68 00 AvrQQsXjDk25Jrh.
41 76 72 51 51 73 58 6A 44 6B 32 35 4A 72 68
- D
34 69 65 44 44 66 4B 5D 37 5E 25 28 3D 65 5B
4 i e D D f K ] 7 ^ % ( = e [
Serial bueno: 4ieDDfK]7^%(=e[
Level 4
La comprobación del serial es igual que la anterior pero sustituyendo la función que sumaba un valor a cada dígito del serial por una que genera un hash con nuestro serial y después lo compara con otro hash almacenado en memoria. Si no nos viene a la mente el tipo de hash que puede ser PEiD ya nos avisaba de que efectivamente el crackme incorpora la función MD5.
La función MD5 hace tiempo que no se considera segura debido a la existencia de numerosos «diccionarios» de hashes que hacen que encontremos la solución en segundos. Yo he utilizado la web MD5 online pero existen muchas más.
La carta de presentación de este crackme es la imagen que veis arriba. Al explorarlo unos minutos enseguida nos damos cuenta de que no realiza ninguna comprobación y que nos está haciendo perder el tiempo. Ahí es cuando empezamos a revisar el ejecutable más a fondo y enseguida encontramos la solución con nuestro amigo el editor hexadecimal.
the answer is AttachedString
Level 6
Misma carta de presentación que el anterior y misma ausencia de comprobación del serial. En esta ocasión echando un vistazo a los recursos encontramos la solución rápidamente.
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.
Estamos ante un ELF un poco más interesante que los vistos anteriormente. Básicamente porque es divertido y fácil encontrar la solución en el decompilado y quizá por evocar recuerdos de tiempos pretéritos.
El programa espera al menos 5 argumentos (nombre del programa y cuatro números enteros). Si se proporcionan los cuatro números enteros, se realizan los siguientes cálculos:
Esto es un sistema de ecuaciones lineales mondo y lirondo que debe ser resuelto para encontrar los valores correctos de qword_602148, qword_602150, qword_602158 y qword_602160. Una vez resuelto el sistema de ecuaciones se realiza la operación:
AVISO: Debido a que este reto está en activo no publicaré a donde pertenece.
El reto en cuestión nos presenta un esquema de puertas lógicas y una secuencia binaria que al pasarla por las puertas nos devolverá la solución al reto.
Lo primero que necesitamos saber es quefunción realiza cada puerta. Si indagamos un poco enseguida llegamos a la conclusión de que el esquema lo componen 3 puertas NOT, cuatro puertas AND y una puerta OR.
El funcionamiento es muy sencillo, la puerta NOT simplemente invierte el dígito de entrada convirtiendo los unos en ceros y los ceros en unos. La puerta AND siempre dará como resultado cero excepto cuando todos dígitos de entrada sean unos, que dará como resultado uno. La puerta OR es contraria a la AND y siempre dará como resultado uno excepto cuando todos los dígitos de entrada sean ceros, que en este caso dará como resultado cero.
Esquema con apuntes
Nota: Aunque lo más normal es encontrarse puertas de dos entradas y una salida, cuando tenemos múltiples entradas el funcionamiento es el mismo pudiendo resolverlo de manera secuencial. Por ejemplo, a la primera puerta AND le entran la pista cuatro, la dos y la tres. La solución es hacer cuatro AND dos y el resultado AND tres -> (cuatro AND dos) AND tres.
Teniendo en cuenta el funcionamiento de las puertas y con la ayuda del esquema anterior podemos automatizar el proceso fácilmente. A continuación os dejo el código en .Net.
Dim encoded As String = "110111000001110010010011101100011000001101111110000001011101110011101100011000001101011011111000011010100110111000001010100111111111000101110001010"
Dim uno, dos, tres, cuatro, cinco, seis As String
Dim w, x, y, z, tmp As Integer
For i = 0 To encoded.Length - 1 Step 3
uno = Mid(encoded, i + 1, 1)
dos = Mid(encoded, i + 2, 1)
tres = Mid(encoded, i + 3, 1)
If uno = "1" Then cuatro = "0"
If uno = "0" Then cuatro = "1"
If dos = "1" Then cinco = "0"
If dos = "0" Then cinco = "1"
If tres = "1" Then seis = "0"
If tres = "0" Then seis = "1"
w = CInt(cuatro And dos) And CInt(tres)
x = CInt(uno And cinco) And CInt(tres)
y = CInt(uno And dos) And CInt(seis)
z = CInt(uno And dos) And CInt(tres)
tmp = (w Or x) Or (y Or z)
txt_s.Text &= tmp.ToString
Next
Obtenemos como resultado: 1100100110100111001111101001111010011000011101100
Si intentamos decodificar la secuencia resultante en bloque no obtenemos ningún resultado pero si tenemos en cuenta que cada letra en binario ocupa siete dígitos enseguida encontramos la solución.
1100100 1101001 1100111 1101001 1110100 1100001 1101100
d i g i t a l
