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
Este BTM va otra vez sobre IPs. Si amigos del séptimo arte, viendo un capítulo de mi querida «The Sinner» me han vuelto a chirriar los dientes. La verdad que viendo el capítulo no te da tiempo a apreciarlo, únicamente me quedo con que aparece una URL y lo reviso a posteriori (esto lo digo para los curiosos que me preguntáis).
En esta ocasión me tiene un poco inquieto ya que es una serie que cuida enormemente los detalles y el fallo que os voy a mostrar parece intencionado. La imagen en cuestión es esta:
Aparece un buscador con una URL más o menos creíble si no fuera porque la IP que aparece es IMPOSIBLE. La máxima IPv4 es 255.255.255.255, es decir, no han dado ni una, y eso es lo que me tiene mosca. Si hubieran utilizado 82.47.25.29 hubiera quedado bien y estaríamos hablando de un problema de geolocalización de IPs, ya que el rango 82.47.xx.xx le pertenece a UK y deberíamos discernir si el servidor está en EEUU o no…
En definitiva, puede ser un fallo a propósito, un guiño o tener un significado. No se que deciros, bueno si, ¡lo investigaré!
El otro día navegando por la red fuí a dar a un mirror de la gran web «Karpoff Spanish Tutor«. Para los que no la conozcais, debeis saber que fué una referencia para el Cracking en la escena nacional. Contenía manuales, cursos, utilidades y todo lo que te pudieras imaginar y/o necesitar para iniciarte en el mundillo del Cracking. Por aquel entonces yo era un cigoto en esto de la Ingeniería Inversa pero la web de Karpoff sentó mis bases y contribuyó a mi afán por saber y compartir. El lector debería saber que estamos hablando de finales de los 90, por lo que este crackme y sucesivos de la web de Karpoff ahora pueden parecer más fáciles pero hay que tener en cuenta que ahora tenemos mejores herramientas.
El objetivo es sacar un serial valido o hacer un generador de llaves, esta hecho para newbies y no tiene ninguna otra proteccion.
El crackme está hecho en Delphi y no tiene ningún tipo de protección antidebug ni nada por el estilo.
Abrimos Delphi Decompiler y buscamos en los eventos el botón de registro, en este caso se llama «focusClick» y vemos que su RVA apunta a la dirección «442AEC«, lo apuntamos y abrimos el crackme con Ollydbg.
En Olly pulsamos Ctrl+G e introducimos el offset anterior. Un poco más abajo vemos un Call interesante, entramos en el.
Dentro del Call vemos a simple vista dos funciones muy interesantes como son «GetVolumeInformationA» y «GetUserNameA«.
Traceamos el código y vemos que obtiene el número de serie del disco C y el usuario de windows y finalmente los concatena. Se puede ver a simple vista en el Stack o Pila.
No necesitamos saber nada más, probamos el número de serie cazado y funciona. Os adjunto el keygen hecho en C++.
Se suele decir que para cada problema hay una solución. Si esto lo llevamos al terreno stego podemos decir que para cada reto hay una herramienta que nos da la solución. En la entrada anterior os comenté que mi fondo de armario son steganabara y stegsolve aunque cuando la imagen es PNG, una herramienta de uso obligatorio es TweakPNG.
Nos enfrentamos a una imagen PNG de 112KB (115477 bytes) con una resolución de 300×225 píxeles. A priori llama la atención el elevado tamaño VS la baja resolución, lo que aviva nuestras sospechas de que esos KB extras se deban a que haya insertado otro archivo en su interior.
Los archivos PNG tienen la peculiaridad de que están divididos en secciones (chunks) en la que algunas son críticas como IHDR (cabecera), IDAT (la imagen) e IEND (final) y otras muchas secundarias como por ejemplo tEXt (para insertar texto). Al explorar el archivo con TweakPNG vemos la cabecera, varios chunks de texto, muchos IDAT que he combinado en uno para mejorar el análisis y la sección final. Si os fijáis, al combinar los IDAT ha cambiado el tamaño del PNG de 115447 a 110893 bytes aunque en este caso sigue siendo un tamaño elevado.
Llama la atención el chunk cHRm de 12595 bytes del que TweakPNG ya nos avisa que no reconoce su contenido. Cargamos la imagen en un editor hexadecimal y buscamos la palabra «Great» que es el texto que hay justo antes del chunk cHRm que nos interesa.
La búsqueda da sus frutos ya que el chunk parece que está formado por un archivo mp4. A partir de aquí tenemos varias opciones, para mí la más limpia es con un editor hexadecimal apuntar los offsets de inicio y fin del chunk y crear un archivo nuevo con el contenido. Otra opción es exportar el chunk desde TweakPNG con extensión mp4 y borrar los bytes del nombre del chunk con un editor hexadecimal, de lo contrario no podréis reproducir el mp4.
Hecho esto, al escuchar el mp4 obtenemos la solución del reto.
Nota: si algo os pide clave es deurus.info
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.
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».
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
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.
La secuencia binaria es ésta:
110111000001110010010011101100011000001101111110000001011101110011101100011000001101011011111000011010100110111000001010100111111111000101110001010Lo primero que necesitamos saber es que funció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.
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
NextObtenemos 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
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.
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.
El cifrado XOR es uno de los algoritmos más utilizados en el mundillo de la encriptación. Aunque por sí solo no es seguro, suele formar parte de cifrados más complejos e incluso si sois aficionados a los crackmes os habréis dado cuenta de que raro es el crackme que no lo utiliza.
Hoy vamos a hacer un recorrido sobre los retos de encriptación que nos propone yoire.com, que aunque son muy sencillos, nos proporcionan una estupenda base para iniciarnos en este tipo de retos.
En este primer reto, el autor te da directamente la solución, ya que, nos da un texto cifrado y nos dice que está cifrado con la clave 10. Lo que el autor no indica es que la clave es hexadecimal, mas adelante ya aprendereis a fijaros en esos detalles.
Texto cifrado: uqci0t~7d0ie0dxy~{
Clave: 10
Esta vez disponemos de un texto cifrado pero sin pistas. Si nos fijamos en el código fuente veremos que la clave utilizada esta vez es 20 y decimal.
<?php
include("../../../core.php");
print Website::header(array("title"=>"The XOR Chall - Easy"));
print Challenges::header();
?>
Convierte la solución que está cifrada con una clave XOR para obtener la respuesta a este reto:
<br><br>
<?php
$solution_xored="m{a4s{`4}`5";
$key = sprintf("%2x",20);
$solution = Crypt::XorData($solution_xored,$key);
print "La solución es: ".$solution_xored;
print "<br><br>";
print Challenges::solutionBox();
print Challenges::checkSolution(Crypt::XorData($solution_xored,$key));
?>
En esta ocasión debemos ojear el código fuente para averiguar como solucionar el reto. En esta ocasión y como de lo que se trata es de aprender, este lo dejaré sin solucionar.
<?php
include("../../../core.php");
print Website::header(array("title"=>"The XOR Chall - Mid"));
print Challenges::header();
?>
Convierte la solución que está codificada y cifrada con una clave XOR para obtener la respuesta a este reto:
<br><br>
<?php
foreach (
preg_split("/\./","2.4.10.71.3698")
as $something
)
$value=pow($something,2);
$key = dechex($value);
$solution_xored = base64_decode("ucSnos+lo8Oqtw==");
$solution = Crypt::XorData($solution_xored,$key);
print Challenges::solutionBox();
print Challenges::checkSolution(Crypt::XorData($solution_xored,$key));
?>
<a href="<?=$_SERVER["PHP_SELF"]?>?showSource">Ver código fuente</a>
<?php
if(Common::getString("showSource")!==false) {
print "<hr>";
highlight_file(__FILE__);
}
print Website::footer();
?>
Venga que casi lo tienes.
En este reto nos indican que el código fuente está encriptado. Cuando nos enfrentamos a XOR en texto grandes y teniendo un indicio de lo que puede contener el código desencriptado es sencillo encontrar lo que buscamos. En este caso en concreto podemos intuir que seguramente el texto contenga la palabra «php«, una vez llegamos a esa conclusión la solución llega sola. Este método no deja de ser un ataque por fuerza bruta.
Código encriptado
lo 8 p]Z9>3<%45xr~~~~~~3?"5~ 8 ryk]Z "9>$p52#9$5jj85145"x1""1)xr$9
lt;5rmnr85p p81<$p81<<5>75#jj85145"xyk]Zon]Z1"535p!%5p5$5p81p#94?p396"14?~~~p%===~~~p$5>4"±#p!%5p1&5"97%1"p3£=?p 1"1p?2$5>5"p<1p"5# %5#$1p1p5#$5p"5$?j]Zl2"nl2"n]Zlo 8 ]Z]Zt;5)ppppppppppppmpre`rk]Zt=5pppppppppppppmp69<575$3?>$5>$#x yk]Zt=5(?"54pppppppmp") $jj?"1$1xt=5|t;5)yk]Z]Z "9>$p81<<5>75#jj#?<%$9?>?(xyk]Z "9>$p81<<5>75#jj3853;?<%$9?>xr3````aryk]Zon]Zl1p8"56mrlomt r r onolom%"<5>3?45x") $jj?"1$1xr#8?'?%"35r|t;5)yyonrn5"p3£497?p6%5>$5l1n]Z]Zlo 8 ]Z96x?==?>jj75$$"9>7x") $jj?"1$1xr#8?'?%"35r|t;5)yyqmm61<#5yp+]ZY "9>$prl8"nrk]ZY "9>$pt=5(?"54k]Z-]Z "9>$p52#9$5jj6??$5"xyk]Zon]Z
Código desencriptado
En este último reto nos aparece un mensaje que nos dice «La solución es: 7b1a4147100a155a0f45574e0f58«. Nos fijamos en el código fuente y vemos que en la encriptación interviene una cookie llamada «PHPSESSID«.
Código fuente
<?php
include("../../../core.php");
print Website::header(array("title"=>"The XOR Chall - Hard"));
print Challenges::header();
?>
Convierte la solución que está codificada y cifrada con una clave XOR para obtener la respuesta a este reto:
<br><br>
<?php
$sessid = isset($_COOKIE["PHPSESSID"])?$_COOKIE["PHPSESSID"]:">hi!|m¬_ö_Ó_;m'`ñ·$\"<";
$key = Encoder::asc2hex($sessid);
$hiddenSolution = file_get_contents(Config::$challsHiddenData."crypt_xor_average.solution");
$hex_xored_solution = Encoder::data2hex(Crypt::XorData($hiddenSolution,$key));
print "La solucion es: ".$hex_xored_solution;
print "<br><br>";
print Challenges::solutionBox();
print Challenges::checkSolution($hiddenSolution);
?>
<a href="<?=$_SERVER["PHP_SELF"]?>?showSource">Ver código fuente</a>
<?php
if(Common::getString("showSource")!==false) {
print "<hr>";
highlight_file(__FILE__);
}
print Website::footer();
?>
Desde Firefox vamos a usar una extensión muy interesante llamada Advanced Cookie Manager que nos permitirá visualizar y modificar dicha cookie.
Una particularidad de la encriptación XOR es que si realizamos «algo XOR 0 == algo«, por lo que un ataque típico sería anular la cookie. La modificamos poniendo como valor 0 y guardamos. Recargamos la web con F5 y ahora nos fijamos que el valor de la solución ha cambiado a «7e5f4410435f1058514254100a19«. Finalmente y teniendo en cuenta que el texto que tenemos es hexadecimal, hacemos fuerza bruta marcando la opción Output First y clickamos en Search.
En el mismo directorio donde tenemos el programa se genera un archivo llamado «XOR_enumeration.txt«, que contiene todos los resultados, echamos un vistazo y hemos tenido suerte.
En el primer vistazo con el editor hexadecimal ya vemos la solución al reto:
Al igual que el caso anterior con el editor hexadecimal tenemos más que suficiente para resolver el reto.
En el análisis inicial no destaca prácticamente nada excepto la palabra myadmin que podemos ver con un editor hexadecimal.
La palabra myadmin es una buena candidata a ser contraseña ante una decodificación. Probamos con lo estándar y conseguimos resultados con steghide. La decodificación nos devuelve la cadena AEMAVABGAGwAZQBhAHIAbgB7AHQAaABpAHMAXwBpAHMAXwBmAHU***** que rápidamente catalogamos como base64 para resolver el reto.
Se nos entrega una imagen GIF aparentemente corrupta. Estudiando un poco la cabecera de los archivos GIF llegamos rápidamente a la conclusión de que faltan los cuatro primeros bytes del archivo.
Bytes originales
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 39 61 F4 01 F4 01 F4 00 00 00 00 00 3A 00 00 00 9aô.ô.ô.....:...
00000010 00 3A 3A 00 3A 66 00 00 66 00 3A 00 00 66 90 3A .::.:f..f.:..f.:
00000020 00 90 3A 3A B6 66 00 B6 66 3A 90 90 3A DB 90 3A ..::¶f.¶f:..:Û.:
00000030 FF B6 66 00 3A 90 66 3A 90 00 66 90 00 66 B6 3A ÿ¶f.:.f:..f..f¶:
Después de insertar los bytes que faltan
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 47 49 46 38 39 61 F4 01 F4 01 F4 00 00 00 00 00 GIF89aô.ô.ô.....
00000010 3A 00 00 00 00 3A 3A 00 3A 66 00 00 66 00 3A 00 :....::.:f..f.:.
00000020 00 66 90 3A 00 90 3A 3A B6 66 00 B6 66 3A 90 90 .f.:..::¶f.¶f:..
00000030 3A DB 90 3A FF B6 66 00 3A 90 66 3A 90 00 66 90 :Û.:ÿ¶f.:.f:..f.Una vez insertados los bytes podemos ver una animación que contiene una cadena de texto fácilmente reconocible como base64. La decodificamos y ya tenemos la solución.
Mirando con un editor hexadecimal no encontramos nada excepto la frase This is not the flag you are looking for para intentar disuadirnos.
Cargamos la imagen en Aperi’Solve y enseguida nos llama la atención la sección Binwalk y un suculento Rar.
Descargamos el archivo Rar y al descomprimir nos encontramos con un archivo de texto con la misma frase desalentadora del inicio y una imagen JPG, esta vez con dos oreos. Inspeccionando la imagen damos con la solución.
