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
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.
El crackme que analizamos hoy está hecho en ensamblador y si bien su dificultad es baja, la creación del keygen es un poco liosa. Al keygen que veremos más adelante, le he dado cierta aleatoriedad para que quede más elegante.
El crackme comprueba el serial en función de un identificador de 4 dígitos que el mismo crackme genera.
Coje nuestro serial mediante la función GetDlgItemTextA.
004010D3 |. 68 FF000000 PUSH 0FF ; /MaxCount = 255. 004010D8 |. 68 40324000 PUSH OFFSET 00403240 ; |String 004010DD |. 68 EC030000 PUSH 3EC ; |ItemID = 1004. 004010E2 |. FF75 08 PUSH DWORD PTR SS:[ARG.1] ; |hDialog => [ARG.1] 004010E5 |. E8 6E010000 CALL <JMP.&user32.GetDlgItemTextA> ; \USER32.GetDlgItemTextA 004010EA |. 68 40324000 PUSH OFFSET 00403240 ; /String 004010EF |. E8 52010000 CALL <JMP.&kernel32.lstrlenA> ; \KERNEL32.lstrlen 004010F4 |. A3 47334000 MOV DWORD PTR DS:[403347],EAX 004010F9 |. 33DB XOR EBX,EBX 004010FB |. 33C0 XOR EAX,EAX 004010FD |. EB 54 JMP SHORT 00401153
Comprueba que nuestro serial esté formado por números (30h – 39h), letras de la A a la F (41h – 46h) y el guión (2Dh), es decir, el alfabeto hexadecimal más el guión. Si hay algún dígito indeseado nos tira fuera.
004010FF |> 8A83 40324000 /MOV AL,BYTE PTR DS:[EBX+403240] 00401105 |. 3C 2D |CMP AL,2D 00401107 |. 74 40 |JE SHORT 00401149 00401109 |. 3C 30 |CMP AL,30 0040110B |. 74 3C |JE SHORT 00401149 0040110D |. 3C 31 |CMP AL,31 0040110F |. 74 38 |JE SHORT 00401149 00401111 |. 3C 32 |CMP AL,32 00401113 |. 74 34 |JE SHORT 00401149 00401115 |. 3C 33 |CMP AL,33 00401117 |. 74 30 |JE SHORT 00401149 00401119 |. 3C 34 |CMP AL,34 0040111B |. 74 2C |JE SHORT 00401149 0040111D |. 3C 35 |CMP AL,35 0040111F |. 74 28 |JE SHORT 00401149 00401121 |. 3C 36 |CMP AL,36 00401123 |. 74 24 |JE SHORT 00401149 00401125 |. 3C 37 |CMP AL,37 00401127 |. 74 20 |JE SHORT 00401149 00401129 |. 3C 38 |CMP AL,38 0040112B |. 74 1C |JE SHORT 00401149 0040112D |. 3C 39 |CMP AL,39 0040112F |. 74 18 |JE SHORT 00401149 00401131 |. 3C 41 |CMP AL,41 00401133 |. 74 14 |JE SHORT 00401149 00401135 |. 3C 42 |CMP AL,42 00401137 |. 74 10 |JE SHORT 00401149 00401139 |. 3C 43 |CMP AL,43 0040113B |. 74 0C |JE SHORT 00401149 0040113D |. 3C 44 |CMP AL,44 0040113F |. 74 08 |JE SHORT 00401149 00401141 |. 3C 45 |CMP AL,45 00401143 |. 74 04 |JE SHORT 00401149 00401145 |. 3C 46 |CMP AL,46 00401147 |. 75 07 |JNE SHORT 00401150 00401149 |> 8305 4B334000 |ADD DWORD PTR DS:[40334B],1 00401150 |> 83C3 01 |ADD EBX,1 00401153 |> 3B1D 47334000 |CMP EBX,DWORD PTR DS:[403347] 00401159 |.^ 76 A4 \JBE SHORT 004010FF 0040115B |. A1 47334000 MOV EAX,DWORD PTR DS:[403347] 00401160 |. 3905 4B334000 CMP DWORD PTR DS:[40334B],EAX ; si no coincide el tamaño del serial con el 00401166 |. 0F85 94000000 JNE 00401200 ; contador nos tira fuera
La comprobación del serial la realiza sumando el valor ascii del primer dígito al valor ascii del tercero y sucesivos y a continuación restando la suma anterior al ID. Cuando finalice la comprobación de todos los dígitos del serial, el restador tiene que ser cero, de lo contrario nos tira fuera. Si el ID es cero también nos tira fuera.
Ejemplo (base 10)para ID = 4011 y SERIAL: 1-23456
0040116C |. 33C0 XOR EAX,EAX 0040116E |. BB 02000000 MOV EBX,2 00401173 |. A0 40324000 MOV AL,BYTE PTR DS:[403240] 00401178 |. A3 43334000 MOV DWORD PTR DS:[403343],EAX 0040117D |. EB 13 JMP SHORT 00401192 0040117F |> 8A83 40324000 /MOV AL,BYTE PTR DS:[EBX+403240] ; Coje el dígito correspondiente 00401185 |. 0305 43334000 |ADD EAX,DWORD PTR DS:[403343] ; 1ºdig + dig 0040118B |. 2905 4F334000 |SUB DWORD PTR DS:[40334F],EAX ; ID - (1ºdig + dig) 00401191 |. 43 |INC EBX 00401192 |> 3B1D 47334000 |CMP EBX,DWORD PTR DS:[403347] 00401198 |.^ 72 E5 \JB SHORT 0040117F 0040119A |. 833D 4F334000 CMP DWORD PTR DS:[40334F],0 ; CHECK RESTADOR SEA = 0 004011A1 |. 75 49 JNE SHORT 004011EC 004011A3 |. 833D 3F334000 CMP DWORD PTR DS:[40333F],0 ; CHECK ID <> 0 004011AA |. 74 40 JE SHORT 004011EC 004011AC |. FF35 3F334000 PUSH DWORD PTR DS:[40333F] ; /<%d> = 0 004011B2 |. 68 00304000 PUSH OFFSET 00403000 ; |Format = "REGISTRADO CON ID:%d" 004011B7 |. 68 40324000 PUSH OFFSET 00403240 ; |Buf 004011BC |. E8 A9000000 CALL <JMP.&user32.wsprintfA> ; \USER32.wsprintfA
Como veis, el resultado de ir restando todos los dígitos de nuestro serial con la ID debe ser cero para que el serial sea correcto.
Lo primero que se me ocurre para obtener una solución directa es buscar una combinación de dígito + dígito que sea múltiplo del ID. Para ello podemos usar la función módulo. La función módulo lo que hace es darnos el resto de la división de dos números, de modo que si el resto es cero los números son múltiplos. Para ello debemos cruzar todos los números y letras hasta encontrar los dígitos múltiplos del ID. Un serial de este primer tipo quedaría algo así como 1-FFFFFFFFFFFFFFFFFF ya que como el primer dígito es fijo el otro se repetirá tanta veces como sea necesario para hacer que el ID sea cero.
Con nuestro reducido alfabeto, cabe la posibilidad de que no encontremos una combinación válida, por lo que tendremos que pensar en un plan B. El plan B que se me ocurre a mi es intentar forzar el plan A restando caracteres aleatorios al ID y volviendo a comprobar si encontramos múltiplos del nuevo ID. Un serial de este tipo quedaría más elegante, por ejemplo 3-A6D53B628BBBBB.
Os dejo unos cuantos números de serie.
'Keygen for Flamer's asm keygenme
Dim id As Integer
Dim serial As String
Dim tmp, tmp2, na, nb As Integer
Dim alfabeto As Integer() = New Integer() {48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 65, 66, 67, 68, 69, 70}
Dim r As Random = New Random
'Button generate
Private Sub btngen_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btngen.Click
ini:
If txtid.TextLength <> 4 Then GoTo Mal
id = txtid.Text
txtdebug.Text = ""
na = alfabeto(r.Next(1, 16))
serial = Chr(na) & "-"
tmp = id
For i = 0 To alfabeto.Length - 1
For y = 0 To alfabeto.Length - 1
'Solución directa
If id Mod (alfabeto(i) + alfabeto(y)) = 0 Then
tmp = id / (alfabeto(i) + alfabeto(y))
txtserial.Text = Chr(alfabeto(i)) & "-"
For z = 0 To tmp - 1
txtserial.Text &= Chr(alfabeto(y))
Next
GoTo fuera
End If
'Indirecta con aleatoriedad
nb = alfabeto(r.Next(1, 16))
tmp = tmp - (na + nb)
serial &= Chr(nb)
If tmp Mod (na + nb) = 0 Then
tmp2 = tmp / (na + nb)
For z = 0 To tmp2 - 1
serial &= Chr(nb)
Next
txtserial.Text = serial
GoTo fuera
End If
If tmp < 0 Then
GoTo ini
Else
txtdebug.Text &= tmp & " "
End If
Next
Next
Mal:
txtserial.Text = "¿id?"
fuera:
End Sub
Me doy cuenta que en el keygen no he utilizado el guión, pero no pasa nada, se lo dejo al lector como curiosidad.
File carving is the process of reassembling computer files from fragments in the absence of filesystem metadata. Wikipedia.
«File carving», literalmente tallado de archivos aunque lo traduciremos como extracción, es el proceso de re-ensamblado de archivos extraídos de un conjunto de mayor tamaño.
Header = Cabecera
Footer or tail = Pie
All this documents have the same header and footer, because of this, we need search the middle bytes. This type uses a ZIP file package.
Los documentos de Microsoft Office >2007 tienen la misma cabecera y pie, por lo que necesitamos bytes intermedios para distinguirlos. Usan encapsulado ZIP.
All this documents have the same header and footer, because of this, we need some bytes to differentiate them. In this case we can do this jumping 73 bytes from header. This type uses a ZIP file package.
Los documentos de OpenOffice tienen la misma cabecera y pie, por lo que necesitamos bytes intermedios para distinguirlos. Usan encapsulado ZIP.
Note: >2007 versions have two patterns and the key is the position 0x80. If in this position we get the bytes «68 40 F8 F7 92», we need to search again for this bytes and displace 107 bytes to find the end of the file. If in the position 0x80 we get another different bytes, we need to search again this bytes and displace 1024 bytes to find the end of the file.
Nota: Las versiones >2007 siguen dos patrones y la clave está en la posición 0x80. Si en la posicion 0x80 obtenemos los bytes «68 40 F8 F7 92», los buscamos una segunda vez y ha 107 bytes encontramos el final del archivo. Si en la posición 0x80 obtenemos otros bytes diferentes a los del primer caso, los volvemos a buscar y a 1024 bytes hallaremos el final del archivo.
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.
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).
Bucle nombre se puede resumir así:
MOVSX EAX,BYTE PTR DS:[EBX] --> Dígito a EAX XOR EAX,55 --> EAX xor 55 ... CMP BYTE PTR DS:[EBX],0 --> ¿hemos acabado? JNZ SHORT 10001022 --> bucle LEA ECX,DWORD PTR SS:[EBP-20] --> ECX = nuestro serial xoreado
Bucle comprobación se podría resumir así:
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 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 ?
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.
Este es el típico reto de Javascript, no tiene mucha complicación pero he decidido dedicarle una entrada por que me llamó la atención lo que utiliza de usuario y clave.
function getStyle(el,styleProp)
{
var x = document.getElementById(el);
if (x.currentStyle)
var y = x.currentStyle[styleProp];
else if (window.getComputedStyle)
var y = document.defaultView.getComputedStyle(x,null).getPropertyValue(styleProp);
if (y.substr(0, 1) == "#"){ return y; } else {
var value = y.split(',');
var R = value[0].substr(4);
var G = value[1];
var B = value[2].substr(0, value[2].length-1);
var RGB = "#" + toHex(R)+ toHex(G)+toHex(B);
return RGB;
}
}
function toHex(N) {
if (N==null) return "00";
N=parseInt(N); if (N==0 || isNaN(N)) return "00";
N=Math.max(0,N); N=Math.min(N,255); N=Math.round(N);
return "0123456789ABCDEF".charAt((N-N%16)/16)
+ "0123456789ABCDEF".charAt(N%16);
}
function pw (form)
{
var d1, d2, d3;
if (navigator.appName == "Netscape"){
d1= getStyle('content', 'background-color');
} else {
d1= getStyle('content', 'backgroundColor');
}
d2=form.Name.value;
d3=form.Password.value;
if (d2==d1.length) {
if (d3==d1) {
window.open ("../" + d1.substr(1, 10), "_self")
} else {
alert("Muhaha! Wrong!")
}
} else {
alert("Muhaha! Wrong!")
}
}
<div class="chal_box" style="padding:10px;">
<form name="form" action="" method="post">
Username<br />
<input id="inputd2" type="text" name="Name" value="" size="30" maxlength="30"><br />
Password<br />
<input id="inputd1" type="text" name="Password" value="" size="30" maxlength="30"><br /><br />
<input type="button" name="Only a button" value="Enter Site" id="Only a button" class="btn" onclick="pw(this.form)">
</form>
</div>
En el formulario vemos que llama a la función «pw» y ésta a su vez llama a la función «getStyle«, bueno, pués es tan simple como poner un «alert();» dentro de la función «pw» para cazar la clave. Con éste método podemos cazar la clave del 90% de este tipo de pruebas.
Con esto ya tenemos la clave. El usuario responde a la siguiente sentencia «d2==d1.length«, es decir, es el número de dígitos de la clave.
¿Fácil no?
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.
This crackme is for the crack challenge 6 of canyouhack.it.
Hoy vamos a enfrentarnos a cuatro retos de esteganografía relativamente sencillos, y digo relativamente, debido a que hay tantas formas de esconder información en un archivo, ya sea imagen, vídeo o sonido, que afrontarlos suele ser desesperante. Las cuatro imágenes son aparentemente las mismas que la que se ve en portada.
Una buena práctica cuando te enfrentas a retos stego de tipo imagen es realizar una búsqueda inversa. Una búsqueda inversa consiste en buscar la imagen original mediante buscadores especializados como TinEye o Google. Si conseguimos la imagen original podemos resolver el reto simplemente comparando o nos puede dar una idea del tipo de modificación por su diferencia de tamaño, colores, degradados, etc.
Descargamos la imagen del reto. Se trata de una imagen JPEG de 526×263 y 76.6 KB (78445 bytes). Su hash SHA1 es «89aed5bbc3542bf5c60c4c318fe99cb1489f267a«
Realizamos una búsqueda inversa de la imagen y encontramos sin dificultad la imagen original mediante TinEye.
Características de la imagen original:
Por lo que vemos ha cambiado el tamaño de 78447 bytes a 78445 bytes y su hash SHA1 tampoco coincide obviamente, lo que nos confirma que ha sufrido alguna modificación. Echando un vistazo con un editor hexadecimal te puedes volver loco por lo que vamos a realizar una comparación mediante la herramienta online DiffNow.
Al realizar la comparación sale a relucir lo que buscamos. La clave es una simple cadena de texto.
Lo primero es realizar de nuevo la comparación.
| Imagen | Tamaño | SHA1 |
|---|---|---|
| Original | 78447 bytes | 8924676317077fc07c252ddeec04bd2a0ecfdda4 |
| imagen2.jpeg | 116386 bytes | 7641e3906f795c137269cefef29f30fcb9cb1b07 |
Como vemos, la imagen ha aumentado significativamente, de 76,6 KB a 113 KB. Cuando el aumento de tamaño llama la atención normalmente tenemos otro archivo insertado. Lo primero que suelo hacer yo es fijarme si ha sido modificado el final del archivo con un editor hexadecimal. Los bytes de cola de un archivo jpg/jpeg son FFD9 y en este caso no vemos modificación alguna al final del archivo. Si el archivo no está al final requiere realizar una búsqueda más exhaustiva. Para estos casos tengo una herramienta de creación propia que se llama Ancillary y que sirve para buscar cierto tipo de archivos dentro de otros como imágenes, documentos de Office, Open Office, pdf, etc. Ancillary encuentra otro jpg que es el que le daba el peso extra y que vemos a continuación. La clave es el título de la película (ojo a las mayúsculas/minúsculas).
El tercer reto parece que tiene algún error debido a que el archivo coincide completamente con el original. Pienso que se ha subido la imagen original por error. Se lo he comunicado al admin del dominio y si algún día obtengo respuesta actualizaré la entrada.
| Imagen | Tamaño | SHA1 |
|---|---|---|
| Original | 78447 bytes | 8924676317077fc07c252ddeec04bd2a0ecfdda4 |
| imagen3.jpeg | 78447 bytes | 8924676317077fc07c252ddeec04bd2a0ecfdda4 |
Actualización 21/08/2016
Al parecer, la solución de este reto es llegar a la conclusión de que la imagen no está modificada. La respuesta del Administrador de la web así lo confirma.
desingsecurity [at] gmail [dot] com – Sorry about the delay, is precisely what is intended with that challenge, they can determine if the image is changed or not , the challenge was solved you . We’ll be equal way improving this point.
Greetings and Thanks
Stego 4
Lo primero es realizar de nuevo la comparación.
| Imagen | Tamaño | SHA1 |
|---|---|---|
| Original | 78447 bytes | 8924676317077fc07c252ddeec04bd2a0ecfdda4 |
| imagen4.jpeg | 93174 bytes | a6329ea4562ef997e5afd067f3b53bdab4665851 |
Al igual que en el caso dos el tamaño ha aumentado significativamente de modo que miramos al final del archivo y esta vez si vemos que hay insertado unos bytes tras el final del jpg (recordemos FFD9)
El archivo tiene pinta de ser una hoja de cálculo de Open Office o Libre Office según indica la palabra «spreadsheet«. Lo abrimos con Excel y tras analizar la maraña de datos enseguida vemos una clave que llama la atención.
Hemos interceptado un mensaje secreto, pero ninguno de nuestros traductores lo sabe interpretar, ¿sabrías interpretarlo tú? Lo único que hemos encontrado es esto en un foro: шжзклмнпфъ = 1234567890
Mensaje secreto: нж, фн, фф, шън, нф, шшъ, шжз, мф, шъп, фл, пк, шъш, шшм, шшк, шъл, шшл, фл, шъш, шшл, фл, шшн, шшъ, фл, шъм, шшн, шъш, шъз, шшш, фл, пж, шшн, шшл, шшш, шжл
Parece que el mensaje secreto está encriptado utilizando un alfabeto cifrado que corresponde a números. Según la clave proporcionada (шжзклмнпфъ = 1234567890), cada letra del alfabeto cirílico se sustituye por un número.
Primero, descompondremos la clave dada:
ш = 1
ж = 2
з = 3
к = 4
л = 5
м = 6
н = 7
п = 8
ф = 9
ъ = 0
Ahora, aplicamos esta clave al mensaje secreto:
нж, фн, фф, шън, нф, шшъ, шжз, мф, шъп, фл, пк, шъш, шшм, шшк, шъл, шшл, фл, шъш, шшл, фл, шшн, шшъ, фл, шъм, шшн, шъш, шъз, шшш, фл, пж, шшн, шшл, шшш, шжл
Sustituyendo cada letra según la clave:
нж = 72
фн = 97
фф = 99
шън = 107
нф = 79
шшъ = 110
шжз = 123
мф = 69
шъп = 108
фл = 95
пк = 84
шъш = 101
шшм = 116
шшк = 114
шъл = 105
шшл = 115
фл = 95
шъш = 101
шшл = 115
фл = 95
шшн = 117
шшъ = 110
фл = 95
шъм = 106
шшн = 117
шъш = 101
шъз = 130
шшш = 111
фл = 95
пж = 82
шшн = 117
шшл = 115
шшш = 111
шжл = 125
El mensaje traducido a números es:
72, 97, 99, 107, 79, 110, 123, 69, 108, 95, 84, 101, 116, 114, 105, 115, 95, 101, 115, 95, 117, 110, 95, 106, 117, 101, 130, 111, 95, 82, 117, 115, 111, 125
Este parece ser un mensaje cifrado en números. La secuencia de números se puede interpretar de varias maneras (como ASCII, coordenadas, etc.). Si asumimos que es un texto codificado en ASCII:
Convertimos cada número a su correspondiente carácter ASCII:
72 = H
97 = a
99 = c
107 = k
79 = O
110 = n
123 = {
69 = E
108 = l
95 = _
84 = T
101 = e
116 = t
114 = r
105 = i
115 = s
95 = _
101 = e
115 = s
95 = _
117 = u
110 = n
95 = _
106 = j
117 = u
101 = e
130 = ?
111 = o
95 = _
82 = R
117 = u
115 = s
111 = o
125 = }
Juntando todo:
HackOn{El_Tetris_e_s_u_n_j_u_e?o_Ruso}
La parte «{El_Tetris_e_s_u_n_j_u_e?o_Ruso}» parece un mensaje en español. Probablemente deba ser leído como: HackOn{El_Tetris_es_un_juego_Ruso}
Así, el mensaje secreto es: HackOn{El_Tetris_es_un_juego_Ruso}.
La imagen de portada de la entrada ha sido generada con ChatGPT.
Hace unos años cuando empecé a trastear con Android y animado por mi afición a la Ingeniería Inversa, decidí realizar una serie de crackmes. Los dos primeros pasaron algo desapercibidos, pero el Crackme nº3 tuvo una gran repercusión en el mundillo y, aunque no fue el primer crackme para Android ni mucho menos, si que fue uno de los más estudiados. Todos ellos fueron publicados a través de crackmes.de y el nº3 en cuestión el 6 de Noviembre de 2010. Os dejo una lista de unas cuantas webs donde aparece analizado para que veáis la repercusión que a mi parecer tuvo.
En una entrada anterior sobre cómo Expediente X abordó la tecnología de vanguardia, comenté que dedicaría un espacio a esos tres personajes tan peculiares y entrañables que, desde el segundo plano, se ganaron un hueco en el corazón de los seguidores de la serie: los Pistoleros Solitarios. Pues bien, ha llegado el momento.
Estos tres tipos —John Fitzgerald Byers, Melvin Frohike y Richard “Ringo” Langly— no necesitaban armas ni placas del FBI. Su poder estaba en los teclados, los cables enredados y los monitores de tubo que parpadeaban en un sótano lleno de conspiraciones y café frío. Eran los outsiders de Expediente X, tres hackers con alma de periodistas que luchaban por algo tan simple y tan enorme como la verdad.
Su primera aparición fue en E.B.E. (temporada 1), casi como un alivio cómico: tres frikis que ayudaban a Mulder a rastrear información sobre ovnis. Pero pronto quedó claro que había algo especial en ellos. No solo eran fuente de datos, sino conciencia crítica en un mundo plagado de mentiras digitales y gobiernos con demasiados secretos. Con el tiempo se convirtieron en aliados imprescindibles de Mulder y Scully, y también en el reflejo más humano de lo que significa ser hacker: curiosos, testarudos, torpes a veces, pero con un sentido moral inquebrantable.
Byers era el idealista, el que aún creía en la decencia y en las instituciones (al menos en teoría). Frohike, el cínico veterano con corazón de oro, siempre dispuesto a arriesgarse por una buena causa… o por impresionar a Scully. Y Langly, el genio rebelde que parecía vivir en permanente conversación con su módem de 56 k. Juntos formaban un trío excéntrico, pero perfectamente equilibrado.
Mientras Mulder y Scully perseguían abducciones y virus extraterrestres, los pistoleros combatían en otra trinchera: la digital. Hackeaban redes gubernamentales, interceptaban comunicaciones cifradas y desmantelaban cortafuegos que, en los noventa, parecían pura ciencia ficción. Lo suyo no era la acción física, sino la resistencia informativa. Y aunque muchas veces eran el chiste del capítulo, también representaban algo muy real: la gente corriente que lucha contra el poder desde el conocimiento.
Su lema no declarado podría haber sido el clásico “la información quiere ser libre”, y en eso se mantuvieron firmes hasta el final. Si había que elegir entre la seguridad o la verdad, ellos siempre elegían la verdad, aunque les costara caro.
| Temporada | Episodio | Título | Comentario |
|---|---|---|---|
| 1 | 17 | E.B.E. | Primera aparición de los pistoleros. |
| 2 | 3 | Blood | Manipulación de dispositivos y mensajes ocultos. También control mental a través de la tecnología. |
| 2 | 25 | Anasazi | Un hacker roba archivos clasificados. Se tratan temas como el cifrado y filtración de datos del gobierno. |
| 3 | 15 | Apocrypha | Acceso a bases de datos secretas y descifrado de archivos comprometidos. |
| 3 | 23 | Wetwired | Manipulación de señales televisivas. |
| 4 | 14 | Memento Mori | Infiltración digital en sistemas médicos y vigilancia biotecnológica. |
| 5 | 1 | Redux | Robo y manipulación de pruebas digitales. |
| 5 | 3 | Unusual Suspects | Orígenes de los pistoleros: intrusión, cifrado y espíritu hacker de los noventa. |
| 5 | 11 | Kill Switch | IA autónoma y malware inteligente. |
| 6 | 20 | Three of a Kind | Hacking social, suplantación y síntesis de voz para infiltración corporativa. |
| 7 | 13 | First Person Shooter | Hackeo de entornos virtuales y brechas de seguridad en sistemas de realidad aumentada. |
| 9 | 15 | Jump the Shark | Su sacrificio final: bloqueo de una amenaza biológica, ética hacker y altruismo extremo. |
| 11 | 2 | This | Langly como conciencia digital en un servidor. Debate sobre IA y trascendencia del código. |
El final de los pistoleros fue tan inesperado como heroico. En el episodio “Jump the Shark” de la novena temporada, descubren un complot bioterrorista que amenaza con liberar un virus mortal. No hay tiempo para avisar a nadie, ni margen para escapar. Así que, fieles a su estilo, deciden sacrificarse para salvar a otros. Sellan el laboratorio desde dentro, sabiendo que no volverán a salir.
Lo reconozco, este desenlace mi cogió completamente por sorpresa. No hay épica de Hollywood, ni música grandilocuente. Solo tres hombres anónimos haciendo lo correcto. Mueren juntos, sin reconocimiento, sin medallas, pero con la serenidad de quienes saben que su causa era justa. Y en ese silencio final, Expediente X nos recordó algo que las grandes historias suelen olvidar: que los verdaderos héroes a veces no llevan traje ni pistola, solo convicción.
Años después, Mulder vuelve a verlos —o cree verlos— en The Truth. Ya no están en este mundo, pero siguen a su lado, como fantasmas digitales de la conciencia hacker. Es un homenaje discreto a quienes siempre pelearon desde las sombras por liberar la verdad.
Para cerrar el círculo, Langly reaparece de forma inesperada en la temporada 11, dentro del episodio This. Su mente, o más bien su copia digital, sobrevive atrapada en un servidor, reclamando ser liberada. Es el epílogo perfecto: el hacker que muere físicamente, pero cuya conciencia sigue inmortal. Una vez más me volvió a sorprender Chris Carter con este homenaje.
Me gusta pensar que los pistoleros solitarios representaban algo más que tres hackers secundarios en una serie de los noventa. Fueron el reflejo de una época en la que creíamos que la tecnología podía liberar al ser humano, antes de que las redes sociales y la hiperconectividad lo diluyeran todo. Byers, Frohike y Langly no luchaban por fama ni por dinero: luchaban por entender el sistema para exponerlo, por esa curiosidad genuina que hoy apenas sobrevive entre líneas de código y algoritmos opacos. Quizá por eso seguimos recordándolos y mola tanto volver a ver los capítulos. Porque, de algún modo, todos los que amamos el conocimiento libre llevamos dentro un pequeño pistolero solitario, buscando la verdad entre los bits.
AVISO: Debido a que este reto está en activo no publicaré a donde pertenece.
En este pequeño CrackMe se nos pide investigar como se genera la clave que resuelve el reto. No tiene formulario donde introducir usuario y clave, cuando lo ejecutamos simplemente aparece una NAG dándonos a entender que no lo conseguimos.
Lo primero que vemos es esto:
004010B8 | 53 | push ebx | 004010B9 | 56 | push esi | 004010BA | 57 | push edi | 004010BB | 83 C4 F4 | add esp,FFFFFFF4 | 004010BE | C6 05 84 20 40 00 00 | mov byte ptr ds:[402084],0 | Dirección 402084 = 0 004010C5 | C7 44 24 08 28 00 00 00 | mov dword ptr ds:[esp+8],28 | 004010CD | 54 | push esp | 004010CE | 6A 01 | push 1 | 004010D0 | 6A 00 | push 0 | 004010D2 | 68 0C 20 40 00 | push exepuzz1.40200C | ;0040200C:"Software\\Caesum\\rev1" 004010D7 | 68 02 00 00 80 | push 80000002 | 004010DC | E8 F4 00 00 00 | call <exepuzz1.RegOpenKeyExA> | Distracción 004010E1 | 85 C0 | test eax,eax | 004010E3 | 0F 85 C6 00 00 00 | jne exepuzz1.4011AF | Parchear este salto 004010E9 | 8D 44 24 08 | lea eax,dword ptr ds:[esp+8] | 004010ED | 50 | push eax | 004010EE | 68 84 20 40 00 | push exepuzz1.402084 | Coge lo que haya en la dirección 402084 ........
Lo primero que nos llama la atención es que en 4010BE pone el DUMP 402084 a cero. Lo corroboramos:
00402000: 04 20 40 00 63 6D 62 69 70 6F 66 00 53 6F 66 74 ; . @.cmbipof.Soft
00402010: 77 61 72 65 5C 43 61 65 73 75 6D 5C 72 65 76 31 ; ware\Caesum\rev1
00402020: 00 6B 65 79 00 74 65 6C 6C 20 6D 65 20 74 68 65 ; .key.tell me the
00402030: 20 61 6E 73 77 65 72 00 59 6F 75 72 20 70 61 73 ; answer.Your pas
00402040: 73 20 69 73 20 00 42 6C 61 68 00 54 68 69 73 20 ; s is .Blah.This
00402050: 6C 69 74 74 6C 65 20 62 75 6E 6E 79 20 77 65 6E ; little bunny wen
00402060: 74 20 68 6F 70 00 42 6C 61 68 00 42 6C 61 68 2C ; t hop.Blah.Blah,
00402070: 20 73 65 65 20 69 66 20 49 20 63 61 72 65 00 42 ; see if I care.B
00402080: 6C 61 68 00 00 00 00 00 00 00 00 00 00 00 00 00 ; lah.............
^
|
----402084 (Ahora no hay nada)
Además para poder continuar la ejecución debemos parchear el salto JNE de la dirección 4010E3. Seguimos:
........ 004010F3 | 8D 54 24 0C | lea edx,dword ptr ds:[esp+C] | 004010F7 | 52 | push edx | 004010F8 | 6A 00 | push 0 | 004010FA | 68 21 20 40 00 | push exepuzz1.402021 | ;00402021:"key" 004010FF | 8B 4C 24 14 | mov ecx,dword ptr ds:[esp+14] | 00401103 | 51 | push ecx | 00401104 | E8 C6 00 00 00 | call <exepuzz1.RegQueryValueExA> | Distracción 00401109 | 8B 04 24 | mov eax,dword ptr ds:[esp] | 0040110C | 50 | push eax | 0040110D | E8 B7 00 00 00 | call <exepuzz1.RegCloseKey> | 00401112 | 68 25 20 40 00 | push exepuzz1.402025 | ;00402025:"tell me the answer" 00401117 | 68 84 20 40 00 | push exepuzz1.402084 | Coge lo que haya en la dirección 402084 0040111C | E8 17 FF FF FF | call exepuzz1.401038 | 00401121 | 83 C4 08 | add esp,8 | 00401124 | 85 C0 | test eax,eax | 00401126 | 74 72 | je exepuzz1.40119A | 00401128 | 68 84 20 40 00 | push exepuzz1.402084 | 0040112D | E8 CE FE FF FF | call exepuzz1.401000 | 00401132 | 59 | pop ecx | 00401133 | 8B F0 | mov esi,eax | 00401135 | 33 DB | xor ebx,ebx | 00401137 | B9 84 20 40 00 | mov ecx,exepuzz1.402084 | 0040113C | 3B F3 | cmp esi,ebx | 0040113E | 7E 21 | jle exepuzz1.401161 | 00401140 | 0F BE 01 | movsx eax,byte ptr ds:[ecx] |>----BUCLE------ 00401143 | 8B D0 | mov edx,eax | EAX y EDX contienen el valor HEX del dígito que toque 00401145 | BF 1A 00 00 00 | mov edi,1A | EDI = 1A 0040114A | 43 | inc ebx | incremento el contador 0040114B | 8D 04 C2 | lea eax,dword ptr ds:[edx+eax*8] | EAX = Dígito+Dígito*8 0040114E | 8D 04 C2 | lea eax,dword ptr ds:[edx+eax*8] | EAX = Dígito+EAX*8 00401151 | 83 C0 3B | add eax,3B | EAX = EAX+3B 00401154 | 99 | cdq | 00401155 | F7 FF | idiv edi | EAX / EDI 00401157 | 80 C2 61 | add dl,61 | DL + 61 0040115A | 88 11 | mov byte ptr ds:[ecx],dl | 0040115C | 41 | inc ecx | 0040115D | 3B F3 | cmp esi,ebx | ¿He terminado de recorrer la string? 0040115F | 7F DF | jg exepuzz1.401140 |^-----BUCLE------ ........
En 401117 vemos que intenta leer del DUMP en la dirección 402084 y a partir de ahí según lo que haya en el DUMP realiza una serie de operaciones con los datos y nos devuelve el resultado en forma de NAG.
Probamos varias cosas y nuestra teoría funciona pero, ¿cúal es la cadena de texto que debemos introducir?. A partir de aquí ya es un poco la intuición de cada uno, aunque la más lógica es «tell me the answer» que aparece justo antes del bucle.
En resumen: t 74 74*8+74 = 414*8+74 = 2114+3B = 214F MOD 1A = 19 + 61 = 72 (z) e 65 65*8+65 = 38D*8+65 = 1CCD+3B = 1D08 MOD 1A = 16 + 61 = 77 (w) l 6C 6C*8+6C = 3CC*8+6C = 1ECC+3B = 1F07 MOD 1A = D + 61 = 6E (n) l 6C 6C*8+6C = 3CC*8+6C = 1ECC+3B = 1F07 MOD 1A = D + 61 = 6E (n) 20 20*8+20 = 120*8+20 = 0920+3B = 095B MOD 1A = 3 + 61 = 64 (d) m 6D 6D*8+6D = 3D5*8+6D = 1F15+3B = 1F50 MOD 1A = 8 + 61 = 69 (i) e 65 65*8+65 = 38D*8+65 = 1CCD+3B = 1D08 MOD 1A = 16 + 61 = 77 (w) 20 20*8+20 = 120*8+20 = 0920+3B = 095B MOD 1A = 3 + 61 = 64 (d) t 74 74*8+74 = 414*8+74 = 2114+3B = 214F MOD 1A = 19 + 61 = 72 (z) h 68 68*8+68 = 3A8*8+68 = 1DA8+3B = 1DE3 MOD 1A = 7 + 61 = 68 (h) e 65 65*8+65 = 38D*8+65 = 1CCD+3B = 1D08 MOD 1A = 16 + 61 = 77 (w) 20 20*8+20 = 120*8+20 = 0920+3B = 095B MOD 1A = 3 + 61 = 64 (d) a 61 61*8+61 = 369*8+61 = 1BA9+3B = 1BE4 MOD 1A = 10 + 61 = 71 (q) n 6E 6E*8+6E = 3DE*8+6E = 1F5E+3B = 1F9C MOD 1A = 6 + 61 = 67 (g) s 73 73*8+73 = 40B*8+73 = 20CB+3B = 2106 MOD 1A = 4 + 61 = 65 (e) w 77 77*8+77 = 42F*8+77 = 21EF+3B = 222A MOD 1A = A + 61 = 6B (k) e 65 65*8+65 = 38D*8+65 = 1CCD+3B = 1D08 MOD 1A = 16 + 61 = 77 (w) r 72 72*8+72 = 402*8+72 = 2082+3B = 20BD MOD 1A = 9 + 61 = 6A (j) zwnndiwdzhwdqdekwj
La cadena de texto resultante ¿sera la correcta?
Hoy tenemos aquí un crackme hecho en Visual Basic 6 (pcode), pero lo vamos a abordar de una manera diferente, ya que, vamos a conseguir el código fuente mediante VB Decompiler, le vamos a hacer una serie de modificaciones para hacerlo funcional con la ayuda de ExDec, y a partir de eso vamos a generar nuestro propio keygen.
El funcionamiento del crackme es simple, tenemos una primera caja de texto «Code» que en función de lo que introduzcamos nos activa el botón «OK». Al pulsar el botón comprueba lo que tengamos en la caja de texto «Serial» para haber si está todo correcto.
Abrimos el crackme con VB Decompiler y vemos sus fauces.
Pinchando en cada parte obtenemos su respectivo código fuente.
El botón OK
Private Sub Command1_Click() '402F70 'Data Table: 402724 Dim ourserial As Variant ourserial = CVar(Me.SERIAL.Text) 'String If (ourserial = cript(Left$(Me.CODE.Text, &HA))) Then MsgBox "Great", 0, ourserial End End If Dim x As String x = cript(Left$(Me.CODE.Text, &HA)) MsgBox "Not Completed - " & x, 0, ourserial Me.CODE.Text = "" Me.SERIAL.Text = "" Exit Sub End Sub
El evento KeyUp
Private Sub CODE_KeyUp(KeyCode As Integer, Shift As Integer) 'Data Table: 402724 If (Len(Me.CODE.Text) > 4) Then ourserialsum = checkcode(Me.CODE.Text) If CBool((ourserialsum > 70) And (ourserialsum < 90)) Then Me.Command1.Enabled = True End If End If Exit Sub End Sub
La función cript
Public Function cript(a) 'Data Table: 402724 Dim var_9C As Long var_98 = CStr(UCase(a)) For var_10C = 1 To CVar(Len(var_98)): var_CC = var_10C 'Variant var_9C = CLng((CVar(var_9C) + (CVar((Asc(Mid$(var_98, CLng(var_CC), 1)) - 9) Xor &H58) + var_CC) ^ 2)) Next var_10C 'Variant For var_160 = 1 To 100: var_140 = var_160 If (Mid$(CVar(Me.CODE.Text), CLng(var_140), 1) = vbNullString) Then GoTo loc_4030C0 End If Next var_160 loc_4030C0: var_9C = CLng(((CVar(var_9C) * Int((var_140 / 2))) * 16)) var_94 = Hex(var_9C) 'Variant cript = var_94 End Function
La función checkcode
Public Function checkcode(a) For var_F4 = 1 To CVar(Len(a)): var_A4 = var_F4 var_128 = var_128 + (CVar(Asc(Mid$(a, CLng(var_A4), 1)))) Next var_F4 var_94 = Int(((var_128 / CVar(Len(a) / CVar(Len(a))))) checkcode = var_94 End Function
Se compone de dos partes, el código y el serial.
Si el resultado de la función checkcode está entre 70 y 90 nos activa el botón OK.
Lo genera la función cript en función del código anterior.
Con lo obtenido anteriormente podemos entender perfectamente el comportamiento de la comprobación del serial pero si los cargamos en Visual Basic 6 y lo intentamos ejecutar tal cual nos dará una serie de errores. Es aquí cuando entra ExDec, ya que, nos proporciona el desensamblado del programa en forma de Opcode para poder comparar con el código obtenido.
En este caso el único problema se encuentra en la función checkcode en concreto en ésta línea:
var_94 = Int(((var_128 / CVar(Len(a) / CVar(Len(a)))))
El problema está en que divide dos veces entre el número de dígitos de a, si lo analizamos vemos que es imposible ya que nunca nos daría un código entre 70 y 90. La corrección queda así:
var_94 = Int(((var_128 / CVar(Len(a)))))
Finalmente el código fuente de nuestro keygen quedaría así:
Private Sub Command1_Click() 'Generate CODE
Dim CODE As String
Dim var As Integer
Randomize
var = CLng((0 - 9999) * Rnd + 9999)
Me.CODE.Text = "deurus" & var
codesum = checkcode(Me.CODE.Text)
If CBool((codesum > 70) And (codesum < 90)) Then
lbl.Caption = "Code valid, now generate a serial"
Command2.Enabled = True
Else
Command2.Enabled = False
Command1_Click
End If
End Sub
Private Sub Command2_Click() 'Generate SERIAL
If (Len(Me.CODE.Text) > 4) Then
codesum = checkcode(Me.CODE.Text)
If CBool((codesum > 70) And (codesum < 90)) Then
SERIAL.Text = cript(Left$(Me.CODE.Text, 10))
Else
lbl.Caption = "Code not valid, first gen code"
End If
End If
End Sub
Private Sub CODE_KeyUp(KeyCode As Integer, Shift As Integer)
If (Len(Me.CODE.Text) > 4) Then
var_B0 = checkcode(Me.CODE.Text)
lbl.Caption = "Value must be between 70 - 90. Yours: " & var_B0
If CBool((var_B0 > 70) And (var_B0 < 90)) Then
lbl.Caption = "Code valid, now generate a serial"
Command2.Enabled = True
Else
Command2.Enabled = False
End If
End If
Exit Sub
End Sub
Public Function cript(a)
Dim var_9C As Long
var_98 = CStr(UCase(a))
For var_10C = 1 To CVar(Len(var_98)): var_CC = var_10C
var_9C = CLng((CVar(var_9C) + (CVar((Asc(Mid$(var_98, CLng(var_CC), 1)) - 9) Xor &H58) + var_CC) ^ 2))
Next var_10C
For var_160 = 1 To 100: var_140 = var_160
If (Mid$(CVar(Me.CODE.Text), CLng(var_140), 1) = vbNullString) Then
GoTo loc_4030C0
End If
Next var_160
loc_4030C0:
var_9C = CLng(((CVar(var_9C) * Int((var_140 / 2))) * 16))
var_94 = Hex(var_9C)
cript = var_94
End Function
Public Function checkcode(a)
For var_F4 = 1 To CVar(Len(a)): var_A4 = var_F4
'Suma el valor ascii de todos los caracteres / Add the ascii value of our code
var_128 = var_128 + (CVar(Asc(Mid$(a, CLng(var_A4), 1))))
Next var_F4
'Lo divide entre la longitud del code / Divide our codesum by code lenght
var_94 = Int(((var_128 / CVar(Len(a))))) 'corrección
checkcode = var_94
End Function
En crackmes.de podéis conseguir el crackme y el keygen.
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».
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.
Los retos de encriptación son muy variados como hemos comentado anteriormente. Aquí tenemos unos buenos ejemplos de ello.
En este primer nivel nos encontramos con un método de encriptación muy antíguo. Sólo diré como pista, que es de los más antiguos que se conocen.
ozhlofxrlmvhxzorulimrz
Lo primero que suelo hacer en este tipo de retos cuando son solamente letras, es comprobar las dos opciones más típicas, que son el cifrado César y Vigenere. En este caso necesitamos ahondar un poco más, aunque enseguida llegamos a la conclusión de que el cifrado usado es el afín. Un ataque por fuerza bruta nos devuelve la solución y los coeficientes utilizados.
Solución: A=25,B=25 – LASOLUCIONESCALIFORNIA
Fuente: http://www.dcode.fr/chiffre-affine
En este segundo nivel recordaremos a un general romano muy conocido. Lo complicaremos un poco, sólo lo justo para que cueste algo más de cinco minutos encontrar la clave 🙂
oehoeahhjoexhkzqhfsvzhffhwrhotqk
Lo primero que nos viene a la cabeza es el cifrado César pero no va. Probando varios cifrados por sustitución al final damos con el correcto. De nuevo un ataque por fuerza bruta nos da frutos.
Solución: (3,4,5)/1 – LACLAVEDELASEGUNDAPRUEBAESMEKONG
Fuente: https://www.dcode.fr/chiffre-decalages
Este nivel también va a ser sencillo. Estos caracteres, pertenecientes a un sistema bastante conocido de encriptado, esconden una palabra que, al introducirla (en minúsculas), nos permitirá superar el nivel.
Investigando un poco llegamos a la conclusión de que se trata del cifrado Francmasón o Pig Pen.
Solución: primates
Fuente: https://www.dcode.fr/chiffre-pig-pen-francs-macons
Esta prueba es tan simple que la he dividido en dos partes que, aunque de apariencia similar, se resuelven de distinta manera. La clave es la unión de las dos palabras resultantes de descifrar las dos líneas de números y que, juntas, forman una tercera palabra.
0111001101110101011100000110010101110010
0001001110011000111110100100110010010001
La primera parte se puede convertir en bloque:
0111001101110101011100000110010101110010 = super
Fuente: https://www.rapidtables.com/convert/number/binary-to-ascii.html
Para la segunda debemos separar en grupos de 5 dígitos y listo:
00010 01110 01100 01111 10100 10011 00100 10001
C O M P U T E R
Fuente: www.lindau-nobel.org
Para descubrir la palabra clave sólo se necesita una mínima capacidad de observación.
31 04 40 23 20 34 33 13 23 22
Se trata del cuadrado de Polibio.
Aquí hay que hacer un poco de trabajo de investigación: Hay que descubrir la clave que empleó un escritor francés (Una pista: «Lagardère») en una de sus novelas, que es la empleada aquí para formar la palabra clave (en minúsculas) que, por cierto, es alemana.
RI3I2MIL2I2A3
POR RESOLVER
Seguimos con cosas fáciles. Se trata de descifrar este texto escrito en inglés.
kgw qkoev ol 617 qthpreoz iwjpz sdkg kgw pdeyeplk rwqdjzwe ipezwq spbbdq sgo sgwz goqkdbdkdwq iwjpz spq rwkwecdzwr ko cpmw gdq uweqozpb yozkedihkdoz ko kgw spe wlloek
Una vez descifrado, nos será fácil descubrir la clave:
pzpyozrp
Se trata de un cifrado de sustitución mono alfabético.
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ZLMIRVHUBGTFJKOASDWQPYEXCN
THE STORY OF 617 SQUADRON BEGAN WITH THE AIRCRAFT DESIGNER BARNES WALLIS WHO WHEN HOSTILITIES BEGAN WAS DETERMINED TO MAJE HIS PERSONAL CONTRIBUTION TO THE WAR EFFORT
Una vez descifrado el alfabeto la solución queda:
pzpyozrp = anaconda
A veces, las cosas no son lo que parecen. Donde aparecen unos números, en realidad hay otros números distintos.
273664524572348321143738
853442616537643005319627
POR RESOLVER
Para resolver algunos problemas, hay que tener una buena base. Este es un buen ejemplo de ello:
ZW50ZXJwcmlzZQ0K
¿Os suena base 64?
Solución: enterprise
Fuente: https://www.base64decode.org/
Esto es más complicado. Para descifrar este texto que contiene la clave para superar el nivel, se necesita otra clave. Para que no sea demasiado difícil, he utilizado una palabra muy sencilla de sólo cuatro letras 🙂
myiemyuvbaeewcxweghkflxw
Mediante fuerza bruta matamos dos pájaros de un tiro.
lapalabraclaveesdiogenes
Fuente: https://www.guballa.de/vigenere-solver
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.
En AperiSolve veremos algo como esto:
... b1,a,lsb,xy .. b1,a,msb,xy .. b1,rgb,lsb,xy .. file: Zip archive data, at least v1.0 to extract, compression method=store b1,rgb,msb,xy .. b1,bgr,lsb,xy .. b1,bgr,msb,xy .. b1,rgba,lsb,xy .. b1,rgba,msb,xy .. file: OpenPGP Public Key b1,abgr,lsb,xy .. b1,abgr,msb,xy .. file: OpenPGP Secret Key b2,r,lsb,xy .. b2,r,msb,xy .. text: "P@UPUUPAAUU@" b2,g,lsb,xy .. text: "(ahOFyIS!" ...
Para entender mejor a que se refiere todo esto vamos a repasar lo básico.
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.
Se nos proporciona la imagen anterior y se nos invita a resolver la ecuación para el menor entero positivo que representa cada fruta. La solución del reto es concatenar «Flag-» a la suma de los valores de las tres frutas.
El enunciado es breve pero ya nos adelanta que existen varias soluciones y que además sólo quieren los números más pequeños que podamos encontrar.
Las frutas están muy bien y son muy sanas pero a nosotros se nos hace más sencillo plantear la ecuación con letras.
\begin{align}
& \frac{x}{y+z}+\frac{y}{x+z}+\frac{z}{x+y}=4\\
\end{align}Para arrojar algo de luz veamos la representación gráfica en 2D y 3D con la ayuda de Desmos.
Las gráficas más que luz nos traen oscuridad de modo que preguntemos a ChatGPT.
resuelve: (x/y+z)+(y/x+z)+(z/x+y)=4 para enteros positivos
Dado que las variables x, y, z son enteros positivos, podemos intentar encontrar una solución para la ecuación bajo estas condiciones. Sin embargo, encontrar una solución exacta puede ser complejo debido a la naturaleza no lineal de la ecuación. Aun así, podemos intentar algunos enfoques:
Voy a realizar un análisis numérico con un rango limitado de valores para ver si encontramos alguna solución que cumpla con las condiciones. Vamos a probar con valores de 1 a 10 para cada variable.
El análisis numérico para valores de en el rango de 1 a 10 no ha encontrado ninguna solución que satisfaga la ecuación. Esto sugiere que, dentro de este rango, no existen combinaciones de enteros positivos que cumplan con la ecuación.
Dado que la ecuación es bastante compleja y no lineal, es posible que las soluciones, si existen, se encuentren fuera del rango considerado o que requieran un enfoque diferente para ser identificadas. Si tienes un rango específico de valores en mente o si hay alguna otra restricción o contexto relevante, por favor házmelo saber para poder ajustar el análisis en consecuencia.
Básicamente nos está invitando a utilizar prueba y error para encontrar una solución, y el prueba y error de las matemáticas no es más que la fuerza bruta en programación.
Partiendo del problema anterior dame un código en python que realice una comprobación recursiva de todas las variables con un rango de 1 a 999.
soluciones = []
rango_valores_x = range(1, 999)
rango_valores_y = range(1, 999)
rango_valores_z = range(1, 999)
for x in rango_valores_x:
for y in rango_valores_y:
for z in rango_valores_z:
# Calculamos el valor de la expresión para cada combinación de x, y, z
valor = x / (y + z) + y / (x + z) + z / (x + y)
# Comprobamos si el valor es igual a 4 y agregamos la solución a la lista
if abs(valor - 4) < 1e-6: # Usamos una pequeña tolerancia para evitar errores de precisión
soluciones.append((x, y, z))
print(soluciones)Dejo resaltada la línea 12 del código ya que en ella reside el problema. Está comprobando con un margen de tolerancia de 10-6 ya que el resultado de las diferentes fracciones no da como resultado exacto 4. Esto es un problema ya que nosotros necesitamos que de exactamente 4 para validar los valores enteros de x, y y z. Pongo un ejemplo para el que se haya perdido con una solución válida para la tolerancia 10-6 siendo x=2, y=264 y z=993.
\begin{align}
& \frac{2}{264+993}+\frac{264}{2+993}+\frac{993}{2+264}=4.000000429\\
\end{align}En otras palabras, ChatGPT nos ha brindado una solución aproximada que no sirve para nuestro propósito. Seguimos probando con el código anterior quitando la tolerancia y con rangos mayores hasta que en 106 paro. Me acaba de quedar claro que con la fuerza bruta no vamos a ninguna parte, o más bien, no tenemos capacidad de computación para resolverlo de ésta manera.
Lo que pasa es que estamos ante una ecuación algebraica de 3 incógnitas que deben ser enteros positivos cuya solución se alcanza mediante la teoría de curvas elípticas.
Las curvas elípticas son fundamentales en matemáticas avanzadas, representadas por la ecuación y2=x3+Ax+B, donde A y B son constantes. Estas curvas son un punto de encuentro entre la geometría, la teoría de números y el álgebra, ofreciendo un campo rico para la exploración y el análisis. En este CTF, nos enfocaremos en los puntos racionales de las curvas elípticas. Utilizando el método tangente-secante, un procedimiento geométrico iterativo, buscaremos ampliar un conjunto finito de soluciones conocidas a la ecuación de la curva. Este método nos permite indagar en la estructura de las soluciones racionales, que potencialmente pueden ser infinitas. Además, estableceremos una conexión entre las soluciones enteras de las ecuaciones diofánticas y los puntos racionales en las curvas elípticas partiendo de la ecuación (1) especificada en el análisis inicial. A pesar de su aparente simplicidad, esta ecuación es conocida por presentar soluciones mínimas de gran tamaño.
Antes de nada, necesitamos saber el grado de la ecuación, de modo que planteamos la ecuación en forma polinómica estándar deshaciéndonos de los denominadores.
\begin{align}
\begin{split}
n(a+b)(b+c)(c+a)=a(a+b)(c+a)+b(b+c)(a+b)+c(c+a)(b+c)
\end{split}
\end{align}Ahora necesitamos expandir y simplificar para llegar a la conclusión de que estamos ante una ecuación diofántica de grado 3. Este proceso es engorroso por la cantidad de términos a manejar así que vamos a utilizar Mathematica como software de respaldo para finalmente obtener el polinomio en la forma de Weierstrass según la ecuación 4.
\begin{align}
& y^2=x^3+109x^2+224x\\
\end{align}donde:
\begin{align}
x = \frac{−28(a+b+2c)}{(6a+6b−c)}\\
y = \frac{364(a−b)}{(6a+6b−c)}
\end{align}Las relación entre la ecuación 3 y los puntos de la curva elíptica se establecen mediante la ecuación 4. Las transformaciones entre las soluciones (a, b, c) y los puntos (x, y) en la curva elíptica vienen dados por las ecuaciones 5 y 6. Con estas transformaciones, cada solución de la ecuación diofántica se puede representar como un punto en la curva elíptica, y las operaciones de suma de puntos en la curva elíptica pueden usarse para encontrar nuevas soluciones de la ecuación diofántica.
El código que tenéis a continuación pertenece al gran trabajo de Aditi Kulkarni [7], que además nos da el resultado para cualquier valor de n. Ojo porque para n=4 el resultado tiene 81 dígitos, para n=6 tiene 134, para n=10 tiene 190 y para n=12 asciende a 2707 dígitos.
(* Asignar un valor numérico a n *)
n = 4;
(* Definir la ecuación de una curva elíptica en términos de n *)
curve4 = y^2 == x^3 + (4*n^2 + 12*n - 3)*x^2 + 32*(n + 3)*x;
(* Encontrar un punto racional en la curva que no sea (4,0) *)
P4 = {x, y} /. First[FindInstance[curve4 && x != 4 && y != 0, {x, y}, Integers]];
(* Función para calcular la pendiente entre dos puntos en la curva,
o la derivada en el punto si son iguales *)
Slope4[{x1_, y1_}, {x2_, y2_}] :=
If[x1 == x2 && y1 == y2,
ImplicitD[curve4, y, x] /. {x -> x1, y -> y1},
(y2 - y1)/(x2 - x1)];
(* Función para calcular la intersección en y de la línea entre dos puntos
o la tangente en el punto si son iguales *)
Intercept4[{x1_, y1_}, {x2_, y2_}] := y1 - Slope4[{x1, y1}, {x2, y2}]*x1;
(* Función para encontrar el siguiente punto racional en la curva *)
nextRational4[{x1_, y1_}, {x2_, y2_}] :=
{Slope4[{x1, y1}, {x2, y2}]^2 - CoefficientList[curve4[[2]], x][[3]] - x1 - x2,
-Slope4[{x1, y1}, {x2, y2}]^3 + Slope4[{x1, y1}, {x2, y2}]*(CoefficientList[curve4[[2]], x][[3]] + x1 + x2) - Intercept4[{x1, y1}, {x2, y2}]};
(* Función para convertir un punto en la curva elíptica a una solución diofántica *)
ellipticToDiophantine[n_, {x_, y_}] :=
{(8*(n + 3) - x + y)/(2*(4 - x)*(n + 3)),
(8*(n + 3) - x - y)/(2*(4 - x)*(n + 3)),
(-4*(n + 3) - (n + 2)*x)/((4 - x)*(n + 3))};
(* Usar nextRational4 para iterar desde P4 hasta encontrar una solución
válida y positiva para la ecuación diofántica *)
sol4 = ellipticToDiophantine[n,
NestWhile[nextRational4[#, P4] &, P4,
! AllTrue[ellipticToDiophantine[n, #], Function[item, item > 0]] &]];
(* Escalar la solución para obtener enteros mínimos *)
MinSol4 = sol4*(LCM @@ Denominator[sol4])
(* Suma de las tres variables*)
Total[MinSol4]
Concatenando Flag- con el resultado de Mathematica tenemos la ansiada flag.
Flag-195725546580804863527010379187516702463973843196699016314931210363268850137105614
ChatGPT ha demostrado ser eficaz en el análisis y la resolución de problemas, siempre que se le proporcione el contexto adecuado. Sin embargo, es importante ser conscientes de que la respuesta proporcionada puede ser aproximada, especialmente si la solución requiere una gran cantidad de recursos computacionales. Por ejemplo, al trabajar con una ecuación diofántica y valores específicos para (x) e (y), ChatGPT puede ayudar a calcular puntos como (P), (2P), (3P), etc., pero hay que tener en cuenta que los resultados para estos puntos pueden ser estimaciones.
Finalmente, os invito a leer la solución de Mingliang Z. [4], en la que se resuelve el problema por completo y de forma muy detallada.