Solve-It 2013 : Nivel 7

 

Bueno, por fin parece que acabamos con los solve-its del año 2013… Vamos con el enunciado del último …

Pues si vamos a ese servidor como se nos dice, se trata de un stream de un audio .ogg.

Nada más ponerlo podemos comprobar que son pitidos estilo morse con una música tipo jazz de fondo … (os dejo a continuación el enlace a la web de marcan para que la escuchéis)

Intentar guardar el fichero de audio es algo un poco dramático, ya que es un stream que está en bucle y por tanto anda creciendo contínuamente en tamaño y al no tener tamaño fijo nunca termina de descargarse así que se queda descargando infinito tiempo…

Lo que hice yo básicamente es esperar lo suficiente como para que se reprodujera el fichero completo y posteriormente ponerlo a descargar para luego coger el archivo .part que se genera mientras está descargándose:

Para abrir este archivo de sonido usamos el Audacity y nos aparece esto (en mi caso):

Yo seleccioné todos y me aparecieron las siguientes pistas:

Como podemos ver, la primera esta incompleta, pero la tercera no, así que desechamos las primeras y nos quedaremos con la última solamente.

Si hacemos zoom sobre la pista de audio podremos diferenciar muy fácilmente los puntos de las rayas del morse.

Podríamos a partir de aquí ir transcribiendo los guiones y puntos en un fichero de texto según los datos que tenemos … pero … la longitud del fichero de audio es bastante … grande y no me apetece básicamente, así que guardo el archivo de sonido como “hackElBueno.ogg”; abro Octave y lo leo de la siguiente forma:

>> soni = audioread(‘hackElBueno.ogg’);

Así se abre como un array. Ahora hay que tratarlo para leer el morse con el script que sale a continuación.

Bueno, antes de empezar con el script, lo que hago es tomar la anchura de lo que representa un punto y una raya según el sampleo que tengo del fichero de sonido:

Vemos que la anchura de una raya mas o menos es de unos 6000 muestras y la de un punto en torno a 2000 muestras.

Con esta premisa hacemos el programa/script que detecta automáticamente los puntos, las rayas y también los espacios entre los distintos caracteres del morse.

La distancia entre caracteres es bastante diferenciable con respecto a la distancia entre rayas y puntos de un mismo caracter, como podemos ver en la siguiente captura:

Tendremos también que tener en cuenta que para considerar que estamos ante el sonido de un pitido de morse, la amplitud de la señal ha de ser mayor que 0.6 (se puede apreciar en la captura anterior que 0.6 puede ser perfectamente válido… como otros muchos realmente …).

Empezamos con lo siguiente:

>> tamsoni = size(soni);
>> tamsoni = tamsoni(1);
>> fp = 0;
>> ultimoSampleMayorQue07 = 1;
>> mensaje = ”;
>> mensajeTXT = ”;
>> contTXT = 1;
>> cont = 1;
>> letra = 1;
>> mantener = 0;

Inicializamos todas estas variables como vemos en la captura anterior para luego hacer en un bucle for de la siguiente manera:

>>  for a=1:tamsoni
>>   if (abs(soni(a,1))>0.7 && fp == 0) //detectamos un pitido morse
>>     ultimoSampleMayorQue07 = a;  //almacenamos posicion del inicio del pitido
>>     fp = 1;
>>     if (mantener > 4000)  //Si detectamos un espacio entre caracteres morse …
>>        letra = letra + 1;
>>        cont = 1;
>>        mensajeTXT(contTXT) = ‘ ‘; //Ponemos un espacio en la cadena de texto
>>        contTXT = contTXT + 1;
>>     end
>>   end

>>   if (abs(soni(a,1)) < 0.7) //Si no estamos durante ningun pitido morse…
>>     mantener = mantener + 1;  //Vamos aumentando esta variable
>>   else
>>     mantener = 0;  //y si estamos en medio de un pitido, la ponemos a 0
>>   end

>>   if (abs(soni(a,1))<0.7 && fp == 1 && mantener>200) //Si acaba el pitido …
>>     if (a – ultimoSampleMayorQue07 < 4000) //… y ha sido menor de 4000
>>       mensaje(letra,cont) = ‘.’;  //Es un punto
>>       cont = cont + 1;
>>       mensajeTXT(contTXT) = ‘.’;
>>       contTXT = contTXT + 1;
>>     else
>>       mensaje(letra, cont) = ‘-‘; //Si no era un punto, sera una raya
>>       cont = cont + 1;
>>       mensajeTXT(contTXT) = ‘-‘;
>>       contTXT = contTXT + 1;
>>     end
>>     ultimoSampleMayorQue07 = a;
>>     fp = 0;
>>   end
>>  end

Y con este programilla, que igual parece algo aparatoso de hacer, pero realmente es muy simple y cuesta menos que hacer a mano… Obtenemos directamente una cadena de texto con el código morse en forma de puntos y rayas:

–… .— ..— .- … – -..— -.- –.. .. .-.-. -..-. .–.- -.–. —.- –.. —- .. ..- -… .-… -..-. –.-. .-.- .- .-.– .. —.- –.- .-.-.. ..– —- –. -… .-.. .-.-. -. .-.-. -. .. — .-.-.. –.-. .. .– .-.-.- .- .–. –.-. — -.-. ..- -. .- -..- –.-. — ..- .-.. .-.-.. -.-.. ..-.- .— –.– -.-.. … -…- -. –. –.-. .-. .- .-.-.. -.-.. ..-.- .— .-.. .. .–. .-.. –. -.-.- .—. -. –. –.-. .-. .- .-.-.. ..- -.- -.-.. .-. .-.-. .-.– –.-. .-. .- –.-. .-.-.- -.-.. ..-.- .— ..-.- —.- .-.– -. –. –.-. .-. .- .-.-.. -.-.. ..-.- .— .-. .-.. .—. -. –. –.-. .-. .- .-.-.. -.-.- — .-. … .— .- ..- —- ..-.. -..-. .-. .- — .-.-.. ..- —. -..-. .–. .-.. .-. .- –.-. .-.-.- -.-.. ..-.- .— -.-.. —.- .. .–. -.– -. –. –.-. .-. .- .-.-.. -..-. ..-. .-.- .-.-. .-.-.- -.-. -.. .-.-. —- .. ..– –.-. .. -..– .-.-. -… .. .-.-. -.-. –.-. -…- .- .— -.-. -..– ..- –. — …- –.-. .-.– …- -. .. -.-.- .- .-.-..

Y bueno, ya con los puntos y las rayas fácil, no?

Vamos a pasarlo por algún decodificador online de morse:

Oh.. vaya… qué sorpresa … marcan liándola en algún solve-it … ¬¬

7J2AST<DO>KZI<AR>/#<KN>#Z#IUB<AS>/#<AA>A#I#Q###GBL<AR>N<AR>NIM##IW.AP#MCUNAX#MUL###J##S<BT>NG#RA###JLIPLG<CT>#NG#RA#UK#R<AR>##RA#.##J###NG#RA###JRL#NG#RA#<CT>MRSJAU##/RAM#U#/PLRA#.##J##IPYNG#RA#/F<AA><AR>.CD<AR>#I##I#<AR>BI<AR>C#<BT>AJC#UGMV##VNI<CT>A#

Es curioso que el inicio del mensaje es legible, es decir, 7J2AST se lee bien en morse y se corresponde con letras y números del morse estándar al parecer… pero luego… liadón…

Bueno, es hora de pensar …

Después de dar unas vueltas al tema nos centramos en la música de fondo … ¿de qué será? (si es que es de algo…) Vamos a darle al Shazam o a alguna mierda de software semejante para ver si suena la flauta y la reconoce …

Pues efectivamente …

 

Evangelion 2.0 … y qué es Evangelion 2.0? Pues una película de animación Japonesa…

Siguiente paso? Pues seguramente si buscamos en internet información sobre código morse japonés … encontremos algo útil …

Bueno pues nada, ya tenemos entretenimiento para las proximas horas/días …

Si vamos a esa entrada de la wikipedia y nos ponemos a comparar cualquier carácter de los que aparecen en ella con alguno cogido del código morse que hemos sacado antes, vemos que efectivamente coinciden.

Por otro lado (como nota), si nos fijamos en el código morse que hemos obtenido, después de los caracteres que he dicho antes que son legibles en morse de toda la vida (7J2AST) vemos que hay un código como el siguiente:

… que si buscamos en los signos de puntuación en código morse, en esta entrada de wikipedia:

https://en.wikipedia.org/wiki/Prosigns_for_Morse_code

(Y de hecho en la misma entrada de wikipedia del código Wabun también aparece)

Curiosamente nos dice:

Que bueno, a estas alturas, es curioso que nos diga que está cambiando a código wabun, pero realmente ya lo sabíamos …

Total, que asociando a cada código morse un caracter en kana (creo que se llama así), obtenemos:

ワフ゛ンモールスフコ゛ウハオモシロイテ゛スネ。
ノコリハカンタンダヨ。
シ゛ヤ、イツシヨニウタイマシヨウカ。
キミヲアキラメタリシナイ。
キミヲカ゛ツカリサセタリシナイ。
ウワキナンテシナイシ、キミヲミステタリシナイ。
キミヲナカセタリシナイ。
サヨナラヲイウコトモナイヨ。
ウソモツカナイシ、キミヲキス゛ツケタリシナイ。
モチロン、ニホンコ゛ノシ゛ユンハ゛ンニシメイヲニユウリヨクシテクタ゛サイ。

Y aquí empieza el festival… Buscar la traducción de todo eso ha sido una odisea… Y en parte ha sido así porque resulta que en el código Wabun no sólo tienes que tener en cuenta el carácter en sí, sino igualmente los caracteres que le siguen a determinados caracteres… Es decir, por ejemplo:

“ki” se corresponde con -.-.. pero hay que mirar si después no hay niguna de las otras 6 combinaciones posibles porque habría que cambiar la “versión” del kana por la que corresponda … una verbena vamos… porque tal y como está el texto escrito en katakana en la parte superior, esto último no lo habíamos tenido en cuenta con lo que habría que rehacerlo.

De todas formas, y después de dar más vueltas al asunto nos topamos con que hay un traductor de morse japonés que ya tiene este tipo de combinaciones en cuenta. Es el siguiente:

https://www.dcode.fr/wabun-code

Con éste decodificador, no obtenemos el texto en katakana, pero sí en romaji lo cual en parte no está mal tampoco…

Aquí pongo lo que sale de ese decodificador:

WABUNMŌRUSUFUGOUHAOMOSHIROIDESUNE.
NOKORIHAKANTANDAYO.
JA,ITSUSHONIUTAIMASHOUKA.
KIMIWOAKIRAMETARISHINAI.
KIMIWOGATSUKARISASETARISHINAI.
UWAKINANTESHINAISHI,KIMIWOMISUTETARISHINAI.
KIMIWONAKASETARISHINAI.
SAYONARAWOIUKOTOMONAIYO.
USOMOTSUKANAISHI,KIMIWOKIZUTSUKETARISHINAI.
MOCHIRON,NIHONGONOJUNBANNISHIMEIWONYUURYOKUSHITEKUDASAI.

Y a continuación, la magnífica traducción que da google al respecto:

The Japanese answering machine is also interesting.
The rest is easy.
Well, when will you sing.
Give up on you.
You will not get soaked.
I don’t cheat, I won’t give up on you.
I won’t make you cry.
I will never say goodbye.
Do not lie or hurt you.
Of course, please enter the Japanese order doctor’s name

He marcado en negrita-cursiva en el párrafo “traducido” anterior algo que nos llamó en especial la atención…

Pese a estar aparentemente penosamente traducido, salta a la vista que ese texto se corresponde con una canción bastante mítica:

Demasiada coincidencia para no ser lo que parece …

Así que tenemos la canción de “Never gonna give you up” de Rick Astley por aquí pululando para variar …

Si nos centramos ahora en lo que son las tres primeras frases y la última, que no parecen pertecer a la canción, podríamos llegar a la conclusión de que igual las primeras frases son de troleo … y que serían algo como…

“El morse japonés es interesante…”

“Lo demás es sencillo …”

“Cantemos todos juntos …”

Y luego nos viene la canción de Rick Astley para finalmente llegar a la frase que debería de darnos la clave del nivel…

Pero nuestro problema es que las traducciones que hacemos nos desconciertan…

Según como dividas las palabras de la frase tienes unas traducciones u otras, en katakana los traductores que utilizamos no sacaban más que otros símbolos u otros textos en japonés que luego no eran capaces de traducir, …

En general, nos volvimos bastante locos …

Lo que optamos por hacer llegado un punto fue simplemente … dar la caca a marcan en twitter para que nos dijera a ver qué pasaba con la traducción de la última frase o no sé … alguna pista! 😀

Lógicamente, no nos dio la traducción, se limitó a decirnos que la que teníamos estaba mal y que la respuesta estaba en esa última frase … Amos, soltando ni prenda, como de costumbre … xD

Total, que al final hicimos lo que había que hacer … consultar con profesionales en la materia: echamos mano de reddit en un hilo de traducciones:

モチロン、ニホンゴノジュンバンニシメイヲニュウリョクシテクダサイ。

Y esta fue su respuesta:

“Of course, enter your full name in the Japanese order”

y otro comentario posterior que vino bien también … :

“[…] Japanese order means family name first”

Y ya está! No era mi nombre (evidentemente) el que había que poner, sino el de Rick Astley … pero en orden japonés:

astley rick

Solve-It 2013: Nivel 6

Venga, que hacía mucho que no retomaba el tema solve-its. Aquí hemos vuelto; con uno que tenía a medias:

A priori, como todos los solve-its, un poco desconcertante, pero como casi siempre, las cosas van cobrando sentido según vamos avanzando …

“Muy Impredecible” visto en conjunto con la tirada de numeros y asteriscos del solve-it en sí, se asocia casi inmediatamente a un teléfono móvil de esos de los viejunos, esos que tenían texto predictivo (o igual no tanto, de ahí lo de “impredecible”).

Por otro lado vemos que “parece” que se nos está pidiendo una fecha, ya que hablan de que, precisamente, se les ha perdido una y que, a cambio, tienen la tirada de números y astericos que nos muestran.

Haciendo alguna que otra búsqueda por internet, logramos encontrar un emulador de texto predictivo T9 (el que usaba supuestamente Motorola en su día):

https://www.sainsmograf.com/labs/t9-emulator/

Tecleando los números que nos dan, y teniendo en cuenta que el ‘*’ es un espacio (en el emulador de esa URL, la tecla de ‘*’ no es espacio, pero había móviles que sí que tenían el espacio en la tecla de ‘*’). Total, que obtenemos lo siguiente:

to ped a world go a grain me pand11
ame a heaven go a flower
gold infinity go the palm me wots game
ame eternity go am goup1
the tipup

 

Lo cual … no tiene casi sentido …

Sin embargo, no hay que olvidar que éste sistema no era infalible, es decir, no acertaba siempre al 100% la palabra que queríamos poner y casi siempre podíamos elegir entre varias de las opciones que nos daba; así pues, siendo un poco más selectivos tenemos:

to see a world in a grain of sand,
and a heaven in a flower
hold infinity in the palm of your hand
and eternity in an hour.
the virus

Si hacemos una búsqueda en internet, veremos que este párrafo pertenece a un poema de William Blake …

Y es entonces cuando podemos empezar a poner en la solución años de las fechas de fallecimientos, de nacimientos, de publicaciones de los poemas, etc … NADA de esto es la solución al solve-it …

Lo realmente desconcertante, y que nos va a dar la pista para dar con la solución, de este solve-it es “the virus”. (aunque hay que decir también que en el poema, la frase “and a heaven in a flower” está incompleta, ya que en el original es “in a WILD flower”… esto tambíen ayudó a que me volviera un poco loco, pero bueno, no era importante).

The virus sin embargo, NO forma parte del poema original, pero SI que es importante.

Al seguir buscando el poema con “the virus” incluído en la búsqueda, no lograba encontrar nada que no fuera la referencia en sí a esa parte del poema, ya que la palabra “virus” no me la localizaba en las búsquedas:

Sin embargo, si seguimos buscando a cerca de este trozo de poema únicamente, veremos que forma parte del poema “Auguries of Innocence“, que a su vez, pertenece a la obra “The Pickering Manuscript“.

Con esta nueva información, si seguimos haciendo varias búsquedas, pero incluyendo de nuevo ‘the virus’, llegamos a toparnos con lo siguiente:

“virus” y “the pickering manuscript” en el mismo enlace? Aquí tenía que estar la solución…

Resulta que Amoeba Virus es, como su nombre indica, un virus informático, que si miramos en esa misma web nos dice:

Damage:

Permanent damage: upon trigger condition, it will overwrite low tracks of a hard disk and any diskette, accompanied by a flashing display, and subsequently hang-up the system. In the overwritten partition sector, the following encrypted text (from Pickering Manuscripts: Blake’s Auguries of Innocence, first 4 lines) can be found: “To see a world in grain of sand And a heaven in wild flower, Hold infinity in the palm of your hand And eternity in a hour.” The Virus 16/3/91 When an infected system is booted, this text is displayed and the system hangs. Moreover, partition sector contains also un- encrypted texts: “AMOEBA”, and the message that University of Malta “destroyed 5X2 years of human life”. Transient damage: —

Y ahí he marcado una fecha, que es curiosamente la contraseña para pasar el nivel:

16/3/91

Solve-It EE26: Nivel 4

Vamos con uno de los niveles que únicamente sacó un grupo (Barcelona92):

Este es su enunciado con unas cuantas pistas más o menos normales y entendibles y luego con su posterior pista … casi indescifrable …

A este solveit la verdad es que no le dedicamos demasiado tiempo. Nos mantuvo bien entretenido el solve-it 2 la mayor parte del tiempo … No obstante alguna vuelta que otra (y paseo por el el pabellón) ya dimos.

Con ese croquis que nos aparece ahí, estaba bastante claro que tenía que sera alguna cosa que teníamos que buscar por ahí … una T invertida? a saber…

Las tres primeras pistas estaban bastante claras en general más o menos…

La primera nos indica casi literalmente… buscad en el pabellón 5 (el de la party) ya que en el 3 (opengune) y el 1 (dormitorios) “te harán perder el tiempo”, es decir, ahí no nos ha puesto lo que sea que tenemos que buscar.

La segunda nos dice que no hay que molestar ni tocar nada ya que “todo funciona por arte de magia”. Bueno, supusimos que con esto se refería a que no tenemos que andar preguntando ni incordiando a nadie (como hicimos la mayoría de los grupos con el solve-it 3 …). El tema de “todo funciona por arte de magia” no lo comprendimos excesivamente bien … supongo que si hubiéramos topado de inicio con lo que teníamos que buscar lo habríamos llegado a comprender.

Por cierto que hay una pista más en el título en referencia a esta “magia”… Luego la comentaremos.

La tercera pista deja claro que hay duplicados (tecnología RAID-1). Sea lo que sea que hubiera que buscar, están duplicados … supusimos que el pabellón 5 es lo suficientemente grande como para poner en un único punto lo que teníamos que encontrar…

El recordatorio no lo vamos a comentar y la pista ……….. tampoco … Todavía no entendemos muy bien a qué se refería marcan con esa pista …

Vamos al tema en cuestión.

Si nos dabamos un paseo por el pabellón 5 de la euskal y nos íbamos fijando bien a una altura de 1.4m podría darse el caso de que encontrásemos cosas como esta:

O esta:

Efectivamente era lo que había que buscar …

Y había un montón, en concreto 28, aunque con 14 (no repetidos) eran suficientes para resolver el nivel.

Y no era la disposición dentro del pabellón de esas pegatinas lo que había que tener en cuenta para resolver el nivel … aquí es donde entra en juego la pista “magia” que hemos dejado al margen un poco antes.

Si nos fijamos en el titulo del level: “NO F*!%ING CLUE” y cogemos las iniciales del mismo tenemos … NFC

Por si no sabéis qué es NFC os lo digo yo. Básicamente se trata de una tecnología de comunicación inalámbrica (Near Field Communication) basada en radiofrecuencia que ahora se usa bastante para el tema de pago con teléfonos móviles, intercambio de datos entre móviles, identificación de acceso tipo Forfait (los tornos esos de las pistas de esquí) …

Si echamos un ojo a la pegatina que tenemos en la bandera de Euskaltel en la captura anterior, pero por la parte posterior, podemos apreciar levemente las espirales:

Sabiendo esto, ahora con casi cualquier movil moderno podemos leer el contenido de estos chips. Lo que contenían eran líneas como la siguiente:

En general eso no dice mucho … pero bueno, si seguimos capturando información de las pegatinas que nos íbamos encontrando, vemos que, los datos de la izquierda son una fracción de 14 elementos y al final si capturamos todos (y como digo había repetidos) tenemos esta lista de datos:

01/14 : 02
02/14 : 07 01
03/14 O : 11
04/14 : 13
05/14 H : 06
06/14 O : 11
07/14 : 09
08/14 O : 13
09/14 : 12 07
10/14 O : 13 02
11/14 : 01 03
12/14 : 14
13/14 : 08
14/14 : 01 12

Tabulando un poquito para que quede todo más bonito tenemos :

La verdad es que esto … no llegamos a sacarlo con lo que no sé si habríamos llegado a alguna conclusión. Os adelanto que teníamos un farmacéutico en el grupo, así que igual habríamos dado con la solución más o menos fácilmente, pero a priori a mi una lista así, no me diría nada.

Si nos fijamos vemos que, ignorando la fracción, tenemos 2 campos separados por ‘:’ y en el campo de la derecha nunca pasa de 14 con lo que podríamos deducir que son uniones.

Si hacemos un croquis sobre la marcha de las conexiones que parece que hay entre los distintos elementos nos topariamos que queda algo asi (he puesto los numeros en circulo porque en linea era un cristo):

Y entendí que aquí es donde tendría algo de sentido la pista de marcan “beauty matters etc… etc… “.

Si logramos colocar todos esos valores y conexiones sin que se intersecten *igual* podría verse algo …

Se me ocurre ahora mismo que para calcular la forma de esa castaña de manera que no cruce ninguna conexión, podríamos utilizar el software gratuito de cálculo de circuitos integrados “Fritzing” … Vamos a probar a ver si sale …

Con un poco de paciencia y arrastrando los “transistores” para que no se cruce ninguna linea (de ahí lo de “beauty matters”) vemos la figura de la parte inferior…

Si ahora dibujamos con los numeros y letras y con todas las conexiones faltantes obtenemos esto:

Posiblemente a la gente que haya estudiado quimica esto le pueda resultar familiar o sonar de algo … Yo igual, como muuuuucho, podría haberlo asociado a química orgánica … y nada más xD. Ya que buscar el compuesto del que se trata … ya habría sido otra historia …

En resumidas cuentas; se trata del siguiente compuesto:

 

ácido acetilsalicílico

(o comúnmente llamado: aspirina)

 

 

 

Solve-It AE01: Nivel 4

Hoy me sentía inspirado (y vale, también algo aburrido …) después de llegar del trabajo y se me ha ocurrido echar un ojo por encima a un solve it que tenía por ahí pendiente de revisar:

Se trata de un archivo de sonido .ogg (‘syster.ogg’ concretamente). Que al abrir suena bastante chirriante (muy agudo y bastante ‘roto’).

La gente un poco viejuna (como yo) enseguida se puede dar cuenta de que se trata de un sonido que se emitía hace años por una cadena de televisión de pago y que cuando sonaba además se veía así de mal:

(Bueno, en la captura se puede apreciar claramente de qué cadena se trataba 😉

(os dejo el fichero de sonido para que lo oigais pero con video: marcan solamente nos daba el sonido como digo 😉

Es curioso que nada más escuchar el fichero sonido codificado, sólamente con oir el inicio pensé … eh! esto es “You never gonna give you up !! FIJO”… Y efectivamente lo era!!! pero …. la cosa no iba a ser tan fácil …. Ni la contraseña era “rick astley”, ni “you never gonna give you up” ni nada … había que descodificarlo …

Indagando un poco por internet, pude descubrir que el sistema de codificación que utilizaba Canal+ se hacía llamar Nagravision/Syster (de ahí viene el nombre del fichero de audio de hecho, una pista bastante clara).

Si abrimos con audacity el .ogg vemos que tiene esta pinta (con el análisis de espectro):

Como vemos no hay frecuencias bajas, todo son frecuencias altas en torno a 300Hz hasta 15000Hz. Es curioso, no tenía ni idea de que este sistema de codificación dejase así el sonido.

Si buscamos en internet podemos encontrar un trozo de artículo que dice muy básicamente, cómo funciona el encriptado de Nagravision/Syster:

Al principio de este texto habla de cómo se codifica el video y demás, pero no nos interesa eso…

En la parte del audio dice cómo funciona. Literalmente “muy rudimentario”: invierte el espectro de sonido en torno a la frecuencia 12.8 kHz. Si lo pensamos tiene sentido: si ponemos en la frecuencia correspondiente a lo que tenemos ahora en 12.8 kHz, a la frecuencia 0, y si luego tiramos desde ese punto hacia frecuencias más bajas en la gráfica que tenemos y las asociamos a las frecuencias altas … es muy posible que tengamos la solución:

El problema es … ¿cómo vamos a hacer eso? => bueno, seguro que audacity tiene alguna herramienta para invertir el espectro sobre una frecuencia 😉 …

Buscando por internet logré encontrar algo de información sobre este tema:

http://www.svengrahn.pp.se/trackind/scramble/scramble.htm

https://forum.audacityteam.org/viewtopic.php?f=39&t=77214

Esencialmente es un manual sobre un comando de Audacity molón llamado “Nyquist” (el famoso Nyquist y su amigo Shannon hacen acto de presencia …) que sinceramente no me apetecía ponerme a estudiar … No obstante, estoy seguro de que pensando un rato y un poco más de la cuenta, incluso que hasta con algún ejemplo de los que pueden venir, podría haberme salido sin mayor problema …

En cualquier caso, lo que hice fue más sencillo (algo realmente no muy habitual; ya que siempre voy a lo complicado 😛 …); pues esta vez pensé: “SEGURO, que alguien ya ha hecho un decodificador de audio de Syster…”. Y efectivamente buscando en internet encontré algo:

http://cryptimage.vot.pl/cryptimage.php

Pero este software tenía un problema …. y es que no acepta directamente los archivos de audio… por lo visto necesitan que sean de video…:

Así que nada … habrá que hacer un archivo de video … ponerle el audio … y luego ya pasarle por esta aplicación … porque sí, lo he comprobado, esta aplicación descodifica también audio además de video:

Total, que me descargué VirtualDub y me creé un vídeo de unos 6000 fotogramas (a 25 fps son unos 4 minutos de vídeo y el audio de marcan dura exactamente 3 minutos 30 segundos así que nos vale de sobra).

Y entonces es cuando después de crear el fichero de video en VirtualDub, voy a intentar meterle el sonido y ….

¬¬

Todo problemas ….

Pues nada, voy a pasarlo a .wav… que ese formato seguro que acepta. La verdad es que no me apetecía andar buscando en internet ningún conversor y tenía reciente el haber cacharreado con ficheros de sonido en matlab así que en estas 3 líneas de código pasé el .ogg a .wav:

Ahora sí que sí, VirtualDub lo traga bien:

Listo, vamos a compilar todo … :

8 Gb de archivo … bueno… no pasa na … 😛

Una vez terminó de hacerlo. Lo paso finalmente por el software de CryptImage …

Después de otro buen rato … finalmente tengo el fichero de audio perfectamente descodificado!

Y efectivamente …. se trataba de Rick Astley y su Never gonna give you up ! … marcan 100%

Si podéis ver el video, hacia el minuto 2:04 hay una voz que dice “cual es el productor del vídeo?“

Y a partir de aquí, que estaba ya resuelto en un 99% fue donde perdí un poco los papeles porque NO encontraba quién demonios era el productor !!

Tras un buen rato buscando, tuve la brillante idea de echar mano de IMDB …..

Ahí tenemos nuestra contraseña 😉

Solve-It EE26: Nivel 3

Finalmente, vamos con el nivel 3 de esta euskal.

En el enunciado vemos lo siguiente:

“Buscanos” : palabra clave que no entendimos muchos de los concursantes.

Directamente y tras una rapida búsqueda en google de “all your ink are belong to us”, nos dimos cuenta de que esto tenía que ver algo con la zona retro (debido al juego de Splatoon) así que allí fuimos a decirles la frase …

No. La cara rara con la que se nos quedaron mirando nos indicaba que ibamos mal por ese camino …

Mientras unos nos peleabamos con el nivel 2, otros fueron diciendo la frase a diestro y siniestro por ahí a gente ya aleatoria por toda la Euskal … (de aquí que igual te vinieran posibles quejas a posteriori marcan  …. O:D

Finalmente, uno de nosotros optó por la solución simple …. ir a decir la frase a marcan o imo… Y así fue como nos dieron este pedazo de hoja impresa plastificada:

Lo que se puede ver en ella es … lo que parece: un mogollonazo de letras impresas una encima de otra haciendo imposible ver nada legible en ellas.

Estuvimos observando esta etiqueta de mil formas distintas para ver si veíamos algo … Igual poniendo en perspectiva el trozo de papel podríamos ver algo ….. NADA.

Tras lo que sería … una hora o dos de andar dando vueltas con el papelito probando mil cosas (la luz del movil a traves, en la pantalla LCD del PC, con algunos leds que teniamos por ahi, ….),

llegamos a pensar que tendría que ser algo que tuviera que ver la luz UV. (ultravioleta) No obstante, no podía ser … no teníamos por qué disponer de serie con una luz UV en el móvil ni mucho menos de una linterna UV …

He de decir sin embargo, que no ibamos mal encaminados (nos equivocamos en la longitud de onda … xD).

En cualquier caso, y descartada la opción de la luz UV, fui yo mismo quien dijo … “seguro que el troll de marcan lo ha plastificado porque hay algo escondido dentro …” así que agarré una navajilla que tenía por ahí un compi y corte el plastico al ras del papel por una de las partes estrechas. Luego fue estirar para terminar de abrir el plastiquete y … sorpresa!!

… no, no hay nada … ¬¬

Con la de tinta que había impregnada en el papel en la parte posterior (el trozo de papel solamente estaba impreso por una cara), el plástico del plastificado se soltó a la perfección y, como se puede apreciar en la foto, se nos rompió un poco también al ir llegando al final. No le dimos mas importancia a este trozo de plastiquete y nos metimos con la parte impresa.

Después de volver a examinarla con mil luces opté por darle un pequeño remojón (veis el trozo de papel que falta? xD) Ahí me di cuenta que había tinta que no era tinta negra pura, ya que con el agua se corrió algo la tinta a color con la que marcan había puesto la contraseña. De hecho, yo pensé en un principio que era bolígrafo. Así que la clave tenía que estar ahí aunque no la vieramos! Siguiente paso? Conseguir otro trozo intacto …

No fue hasta la mañana siguiente cuando a un compañero se le ocurrió mirar en lo que habíamos desechado: el trozo de plástico del plastificado (y semiroto). Le había puesto un celo al movil que había pintado con rotulador azul para ver si lograba ver algo … y conseguía ver algo, pero no por la luz azul. De hecho, se veía mejor a simple vista.

Lo puso sobre un fondo blanco (dejando olvidadisimo su invento del movil con el celo pintado de azul-rotulador xD…) y:

Ahora sí, se veia algo!

WavelenghtDivisionMultiplexing

Y ahora la explicación de cómo debía haberse resuelto originalmente el solve-it …. xD

Nos comentaba marcan que el negro hecho a base de mezcla de tinta de color de las impresoras (cyan, amarillo y magenta) es sensible a la luz INFRAROJA (que no ULTRAVIOLETA, que fue lo que pensamos utilizar al principio).

Resulta que marcan había colocado bajo un televisor en la zona de redes un pequeño faro de leds infrarojos. Si poníamos el papel en ese foco, se podían distinguir (aunque he de decir que vagamente) las letras con la solución a este solve-it.

Estando intentando resolver el siguiente solve-it (buscando las pegatinas con las ‘ T ‘ invertidas, que ya comentaremos en el siguiente post) vimos un montón de gente dando vueltas en torno al foco IR con el trozo de papel (cuando nosotros ya habíamos resuelto éste) y fue gracioso que nos preguntamos …. ¿por qué andarán enredando ahí con el trozo de papel?, si el solve it no se hace asi … de hecho … pensamos que ese foco tendría que ver con el solve-it 4 y anduvimos con un movil grabando el foco, pensando que igual se podría apreciar algo que a simple vista no se veía …

Solve-It 4 : 2010

Antes de continuar con los solve-its de este año, vamos a hacer un inciso y a detenernos un momento en un solve-it del año 2010. De los más difíciles (yo creo) que ha puesto marcan.

Nos propone el siguiente enunciado:

Dentro de éste hay un enlace a lo que parece un fichero. Se trata de una imgen .png:

“goindown.png”

Antes de continuar he de decir, que tras estar dandole vueltas varios días y también dando la caca a @marcan42 por twitter pidiendole pistas … este solve-it no lo saqué … la verdad es que es de los “mas o menos” difíciles de marcan (como él bien me dijo por twitter 😉

En esta imagen hay que fijarse en un par de cosas; de hecho, en tres para ver por donde van los tiros:

La primera es que se trata de un .png y … es una fotografía … normalmente las fotografías son en formato .jpg. Si hacemos un ‘file’ sobre el archivo .png nos da la siguiente información:

Se trata de un PNG de 1659×866, 8 bits de profundidad de color y lo realmente importante: tiene una capa de color Alpha (RGBA).

La segunda es la pista que nos da en el propio level: “Cada elemento tiene su razon de ser“. Esto significa que los puntos están a diferentes alturas bien marcados en un cuaderno cuadriculado para indicar que es así porque tiene que ser así; es decir, que si un punto esta a 0.5 cuadrados más abajo que otro, es porque tiene que serlo.

Y finalmente la tercera son esas 2 líneas horizontales marcadas en la gráfica. Si nos fijamos cada una divide a la grafica en 6 cuadrados del cuaderno de altura; además de esto, hay que tener en cuenta que los cuadrados del cuaderno nos los divide por la mitad, lo que hacen que haya 12 alturas cada división.

Vamos por partes.

En primer lugar vamos a extraer el canal alpha de la imagen a ver qué vemos. Para ello usamos el comando “convert -alpha extract goindown.png alpha.png“. Luego abrimos la imagen con imageMagick y veremos que sale toda en blanco:

Sin embargo, si le damos a rellenar con negro en cualquier punto de la imagen obtenemos:

MiReDo>>

Esto es otra pista, que esencialmente nos está diciendo que la gráfica se trata de notas musicales, que tenemos que pasar muy rápidamente.

Es por eso por lo que hay 12 divisiones entre líneas: se trata de divisiones entre octavas de todas las notas musicales:

Averiguado esto, y sabiendo ya de antemano la solucion, cogí y (con mis prácticamente nulos conocimientos de música) asumí lo siguiente (tras varias ojeadas en wikipedia y alguna otra web):

Total, que teníamos que ponernos a producir música en base a las notas de esa gráfica.

Echemos mano de Octave (que para esto nos va a venir bien y así aprendemos un poco cómo funcionan las notas). Vamos a ver si conseguimos que suene algo decente.

En la wikipedia (entre otros) nos dan la frecuencia a la que vibran cada una de las ondas de las notas musicales (esta frecuenci aparece en la captura que he puesto antes).

Vamos a empezar por asignar a cada una su frecuencia:

Ésta es la parte fácil realmente … ahora hay que hacer sonarlas, lo cual realmente no es muy complejo tampoco … y más si buscamos un poco por internet, ya que encontraremos información de cómo hacerlo muy fácilmente, ya sea con Octave o Matlab.

Para ello en primer lugar hay que elegir una frecuencia de muestreo (el mundo digital es lo que tiene…). Ésta me da un poco igual, pero ya que es gratis voy a poner 44100Hz que es un poco lo típico:

>> fs=44100;

Posteriormente hay que hacer una señal sinusoidal (o cosenoidal, da lo mismo), que oscile a la frecuencia de la nota que queremos. Para hacerlo en Octave primero definimos una variable en la que introduciremos el tiempo que queremos que suene la nota, por ejemplo 1 segundo y con eso creamos un array de tiempos que luego utilizaremos para generar la onda:

>> duracion = 1;
>> t = [0:1/fs:duracion];

Esto nos da un array de tiempos de 44101 valores/muestras. Como podemos deducir, cuanta más frecuencia de muestreo, más muestras tendremos en el array ‘t’.

Ahora vamos a generar una onda con una de las frecuencias correspondientes a una nota, por ejemplo, vamos a hacer la nota ‘LA’ (440Hz). Para generar la onda tenemos también que definir una amplitud S para la misma (en este caso cogeré S=1 para simplificar) cuya frecuencia sea 440Hz tenemos que hacer lo siguiente:

S·sin(w·t) , donde w = 2·pi·f => nota = sin(2·pi·440·t)

Aplicando esto en Octave tendríamos que hacer:

>> x = sin(LA*2*pi*t);

Si ploteamos la forma de esta señal tenemos:

>> plot(t(1:500),x(1:500));

(con el comando de arriba ploteamos solamente las 500 primeras muestras de la señal ‘x’)

Donde el eje de abscisas es el tiempo (en segundos) y el eje de las ordenadas es la amplitud.

Si queremos oir esta señal, basta que escribamos lo siguiente en la ventana de comandos de Octave:

>> sound(x,fs);

Ahora bien, aquí hemos representado y escuchado unicamente una nota (LA) durante 1 segundo… pero ahora tenemos que poner todas las notas que nos presenta marcan en el dibujo, una detrás de otra y luego hacerlas sonar.

Bueno, antes de seguir comentar que en la captura que puse antes, las notas están colocadas de forma errónea en la octava, ya que no es ascendente desde el origen (desde el eje de ordenadas = 0 hacia arriba no empieza en DO (C4), luego al llegar a la posicion 12 es DO (C5), etc…) sino que la linea horizontal superior (24) se trata de la nota DO (C5) y la siguiente linea horizontal (12) representa la nota DO (C6). La forma correcta es:

Hay que decir que para deducir este orden lo que hice fue prueba-error en relación a la solución que yo ya sabía … 😉

Cabe destacar también que los puntos intermedios entre notas de la gráfica corresponden a las teclas negras de los pianos (notas sostenidas/bemoles (en la escala mayor; la escala más típica, vamos): en la lista que he creado antes en Octave son las notas que llevan la ‘_’ al final son las notas sostenidas de la escala mayor).

>> c = 2*pi*t;
>> x = [sin((DO*2)*c), sin((SOL)*c), sin((DO*2)*c),sin((MI*2)*c),sin((SOL*2)*c), sin((DO*4)*c), sin((SOL*2)*c), sin((SOL_)
*c), sin((DO*2)*c),sin((RE_*2)*c), sin((FA_*2)*c), sin((RE_*2)*c), sin((FA_*2)*c), sin((DO*4)*c),sin((RE_*3)*c), sin((SOL_*4)*c), si
n((RE_*4)*c), sin((LA_)*c), sin((RE*2)*c), sin((FA*2)*c), sin((LA_*2)*c), sin((FA*2)*c), sin((LA_*2)*c), sin((RE*4)*c), sin(FA*4)*c, sin(LA_*4)*c, sin(FA*4)*c ];

He metido el array de tiempos en la variable ‘c’, que se ve arriba, para que el codigo quedase algo más legible (y aún así… bueno…).

Lo que hace esa linea de código es concatenar los arrays de las ondas que generamos para cada nota (para cada frecuencia diferente), en un único array ‘x’.

Si os dáis cuenta también, hay algunas ‘notas’ multiplicadas por 2 o por 4.

Esto es debido a la octava. Según en la octava en la que estemos, si estamos haciendo un DO (C4), para subir de octava, DO (C5), hay que multiplicar su frecuencia por 2 (es decir, su frecuencia en una octava mayor es el doble). Y si queremos hacer un C6, habría que multiplicarla por 4 (o multiplicar la C5 por 2) y así igualmente y con cualquiera de las notas.

El resultado de hacer esto es un array bastante enorme (de 1190727 elementos):

Con esto tenemos un sonido que dura 27 segundos (1 segundo por nota) … cosa que no cuadra mucho con el ‘>>’ que vimos en la primera pista del .png (en el canal alpha).

A partir de aquí es probar distintas velocidades hasta que nos salga algo decente.

Si hacemos que la duración del sonido sea en total 1 segundo => 1/27 = 0.031s por nota:

>> duracion = 0.031;
>> t = [0:1/fs:duracion];
>> c = 2*pi*t;
>> x = [sin((DO*2)*c), sin((SOL)*c), sin((DO*2)*c),sin((MI*2)*c),sin((SOL*2)*c), sin((DO*4)*c), sin((SOL*2)*c), sin((SOL_)
*c), sin((DO*2)*c),sin((RE_*2)*c), sin((FA_*2)*c), sin((RE_*2)*c), sin((FA_*2)*c), sin((DO*4)*c),sin((RE_*4)*c), sin((SOL_*4)*c), si
n((RE_*4)*c), sin((LA_)*c), sin((RE*2)*c), sin((FA*2)*c), sin((LA_*2)*c), sin((FA*2)*c), sin((LA_*2)*c), sin((RE*4)*c), sin(FA*4)*c, sin(LA_*4)*c, sin(FA*4)*c ];

Con esto finalmente, pasamos a .ogg el fichero:

>> fich=’menudaCrisis.ogg’;
>> audiowrite(fich,x,fs);

Y sonará así:

Descargar fichero .ogg final

… para el que después de oír el fichero de sonido aún no sepa cual es la contraseña… os diré cuál es:

seta

Solve-It EE26: Nivel 2

Vamos ahora con el nivel 2 de los solve-its.

En este solve-it nos encontramos con el siguiente enunciado, que nos propone imobilis:

Spin-Up: Que en este nivel el enunciado no es que fuera una pista … de hecho yo diría que más bien fue un troleo …

Si escuchamos el fichero de sonido nos encontramos con que es un disco duro acelerando y rascando (ese sonido que hace cuando hacemos lecturas/escrituras sobre el mismo) y finalmente desconectándose y decelerando.

Lo primero que hacemos directamente es pasarlo por el Audacity para ver a qué nos enfrentamos de forma más visual:

Lo primero que se nos pasa por la cabeza al ver esto es el morse. Haciendo un analisis de espectros y ajustando algún que otro parámetro logramos obtener lo siguiente:

Ahí visualizamos más claramente donde están los pulsos que da el disco duro (lecturas/escrituras).

Podemos ver que cada cierto número de pulsos, y hasta un máximo de 5, hay un espacio de alrededor de 150 ms, por lo que separamos estos datos así en base a esos 150 ms:

4, 4, 2, 3, 2, 4, 4, 3, 2, 4, 4, 3, 3, 3, 3, 4, 4, 4, 1, 1, 3, 2, 3, 4, 4, 2, 4, 3, 1, 5, 1, 3, 3, 4, 1, 4, 1, 5, 1, 1

Esta lista de números es lo primero que obtuvimos pero no teníamos muy claro qué podíamos hacer con ella…

Teníamos esperanza de que pudiera ser morse, pero no tenía sentido, los pulsos eran iguales, no parecía haber diferencias notables entre lo que podrían ser los puntos y las rayas del código morse…

Pensamos bastante tiempo en letras asociadas a esos números pero también carecía de sentido, ya que estabamos hablando de 5 letras únicamente. Estuvimos dando vueltas a esto bastante tiempo a pesar de que habíamos visto que no parecía llegar a buen puerto en ningún caso…

Cambiamos un poco de tercio y basándonos en el nombre del fichero de audio hicimos algunas búsquedas por internet donde localizamos que habían logrado extraer datos de un disco duro por los ruidos que este emitía. Estuvimos echando un ojo también a un paper que encontramos sobre el tema pero… nos pareció que era excesivamente complejo… sobre todo para estar hablando de un solve-it de nivel 2…

Otra de nuestras opciones fue la de pasar a binario los elementos para ver si podíamos distinguir alguna forma o patrón:

No parecía tener buena pinta … pero confiabamos que tendrían que ir por ahí los tiros por ahí así que hicimos lo mismo pero cogiendo cada pareja de valores:

Agua…

O algo estabamos pasando por alto, o nos faltaba algún detalle más…

Seguimos por el camino de utilizar el título del level como “guía” y el propio nombre del fichero de audio, pero eso no nos llevaría mas que otros callejones sin salida. Analizamos el espectro de la señal en la zona “limpia” de la misma y sacamos algunas conclusiones (que no llevarían a ningun sitio… ):

Como vemos en la captura anterior, en el espectro frecuencia , la frecuencia dominante en este tramo correspondiente a 90Hz: eso nos dijo simplemente que el HDD estaba girando a 5400rpm … a modo de curiosidad es muy bonito, pero en lo que es avanzar para resolver el level, no nos serviría para nada…

Teniendo esto, hicimos por otro lado el análisis en frecuencia de cada uno de los bloques de conjunto de pulsos:

La frecuencia de 90Hz va a estar siempre ahí, pero al hacer ruido el disco duro se añaden más frecuencias, como se puede ver en el gráfico, y como estaban en torno a 90Hz también, pensamos que las frecuencias podrían corresponder a código ascii… pero era otro callejón sin salida:

Dejamos un poco a parte este nivel y nos centramos en el level 3…

Al día siguiente (ya viernes) lo retomamos un poco y optamos por la idea original del morse… que sabíamos de sobra que no era morse, pero también sabíamos que seguro que tenía algo relacionado o semejante con ello aunque no tuviéramos ni idea de qué podría ser…

Se nos ocurrió buscar por internet algo como “morse code variant” y fue cuando encontramos de casualidad, en imágenes de google, algo que nos llamó la atencion a los dos que estabamos mirando en la misma pantalla del ordenador esperando encontrar algo:

Una tabla de 5×5 (casualmente el máximo valor de pulsos que teníamos era 5!!) que asociaba por parejas de números una letra del abecedario… tenía muy buena pinta!

Empezamos a coger los datos numéricos de los pulsos de 2 en 2 y qué sorpresa cuando empezaron a salir cosas legibles:

4,4, t
2,3, h
2,4, i
4,3, s
2,4, i
4,3, s
3,3, n
3,4, o
4,4, t
1,1, a
3,2, m
3,4, o
4,2, r
4,3, s
1,5, e
1,3, c
3,4, o
1,4, d
1,5, e
1,1, a

Como veis, teníamos un código legible que tenía toda la pinta de ser la solución pero … no nos cuadraba bien la última letra …

thisisnotamorsecodea

… nos habíamos dejado algo o habíamos cogido ese dato de más?

En cualquier caso, primero optamos por introducir el código tal cual (incluida la ‘a’ del final). Pero no era la contraseña… así que … optamos por introducir el dato sin la última ‘a’ (al final ésta era la respuesta más sencilla; ¿qué datos iba a haber después de esa ‘a’?) y es AQUI cuando hicimos nuestra primera gran cagada: introdujimos la contraseña CON ESPACIOS:

this is not a morse code

A continuación, nuestra segunda gran cagada que fue la que hizo que se nos fuera de las manos este level, escribiendo auténticas idas de olla después. Fue al introducir a mano lo siguiente (entre otras cosas):

thisnotamorsecode

Sin el ‘is’ …

Luego este…

thisisnotamorescode

SI, 2 letras cambiadas por introducir a mano la password… y os preguntaréis que por qué sé que introdujimos las claves exactamente así (de mal) … luego lo contaré…

Total, que ya está liada: después de esto vino el despiporre y las estiradas de pelos y las juradas en griego incluyendo a imo en ellas (eh, pero siempre con cariño, que no se lo tome a mal nadie 😉

¿Qué posibilidades había de que hubiésemos encontrado ese código y NO fuera la contraseña? Era prácticamente imposible! encontrar un código y que sea una troleada? Pues la cosa es que lo pensamos… y como el nivel se llamaba Spin-Up nos obsesionamos por encontrar la clave en la arrancada del HDD.

Empezamos a pasarle filtros de mil tipos, espectros, calculamos aceleraciones, velocidades, luego empezamos a pasar a morse la clave, a binario, hexadecimal … y un sin fin de mierdas más sin sentido …

Fue el sabado a eso de las 11 de la mañana (a 1 hora para el deadline de la prueba) cuando un compi escribió la password con serenidad, tranquilidad y algo de cabeza y…  voilá, funcionó por fin !!! unas 12 horas liándola con la contraseña cuando ya la teníamos !

thisisnotamorsecode

Tras finalizar la prueba y después del deadline del apartado de Software Libre (sabado a las 23.59), fuimos a hablar con imobilis para ver si podríamos ver el log de las passwords que habíamos estado introduciendo desde que averiguamos la contraseña correcta.

He de decir, que cuando nos las mostró fue de los momentos mas desternillantes que he pasado durante esta Euskal. Había auténticas barbaridades, de las que algunas no sabíamos ni de dónde habían salido: vimos desde cosas como “No” o “El Equipo A” hasta “for the love of motherfucking god, what the hell’s missing here!”. Fue épico; llorando de la risa (gracias imobilis por ese momento !! xDDD).

Solve-It EE26: Nivel 1

Y otro año mas hemos estado en la multitudinaria Euskal Encounter (26ª edición) en la que, cómo no, hemos participado en el HackIt 2018 organizado en el apartado de Software Libre.

A diferencia de ikasten.IO (DiarioLinux), nosotros solemos obcecarnos con los Solve-Its más que con los Hack-Its (en nuestro grupo el fuerte no es la informática y los Hack-its en general se nos quedan grandes). Para el que no sepa, los Solve-Its están más orientados al manejo de software y el PC de forma más general y de uso común para llegar a las soluciones, mientras que los hack-its están más enfocados a tener habilidades de programación y conocimiento más profundo de tecnologías informáticas para dar con las soluciones.

No voy a alargarme mucho más con la introducción, pues como bien comenta en sus primeros párrafos el equipo de DiarioLinux en su web ikasten.IO, que al igual que nosotros participaron en este evento y que cuya lectura recomiendo ;), al final participar en este evento no lo hacemos principalemente por ganar, sino por aprender y pasar un buen rato … aunque hay que decir que “pasar un buen rato” ….. la verdad es sufrimos bastante para resolver las idas de olla de marcan & imobilis & company :P.

Entrando un poco en materia, de los 5 solveits de este año (aunque me pareció ver que inicialmente había 6), la gran mayoría de los equipos logramos sacar 3 de ellos y únicamente un equipo (Barcelona 92) consiguió sacar el 4º: no sin sufrirlo y tras buenas horas perdidas de sueño según anduvimos comentando con ellos al finalizar el evento …

Pero vamos al tema en cuestión…. aqui tenemos el primero de los Solve-its de esta edición:

 

Básicamente se nos presenta una tirada de imágenes que, con la pista del título del solve-it “Amigos Comunes”, no cuesta mucho averiguar en qué nos tenemos que fijar para resolverlo. De hecho, mientras yo estaba creando el usuario para “darnos de alta” en el evento, un compañero lo resolvió en pocos minutos.

El tema de este solve-it es que todos esos dispositivos que vemos en la imagen …

… tienen que tener algo en común. Basta que busquemos un poco por Wikipedia o en Google en general.

Tenemos de izquierda a derecha lo siguiente: Commodore Amiga, Calculadora Texas Instruments TI-89, Sega Megadrive, Atari ST, Apple Lisa, Osciloscopio LeCroy 9400 y una impresora LaserWriter de Apple.

Si nos fijamos un poco, con buscar de hecho 2 o 3 de los dispositivos de la lista anterior, nos podemos dar cuenta de que comparten la misma CPU. Se trata de un microprocesador Motorola 68000 o MC68000.

Y ésta es la contraseña que nos daría acceso al siguiente nivel.

Solve-It GE08: Nivel 1

Vamos con otro solve it sencillito.

“El nivel menos significativo”. Una pista realmente importante …

Si intentamos buscar patrones en los números que aparecen en esa lista. no vamos a ver nada. Puntos sueltos que no significan mucho así que, ya que el nivel se llama “menos significativo” vamos a pasar a binario toda esa tirada de numeros.

Se puede hacer en python, pero yo he optado, cómo no, por usar Octave.

Para introducir los números en Octave yo he usado el notepad de toda la vida y he copiado la lista tal cual. Posteriormente con la magnífica herramienta de “Reemplazar” he ido reemplazando todos los numeros del 0 al 9 por su correspondiente numero pero añadiendo un espacio; por ejemplo “0” por “0 “. Y así vamos obteniendo:

Posteriormente he quitado los “intros” y he introducido en una matriz todos estos valores para manipularlos tranquilamente.

Escibiendo este pequeño código:

lo que hacemos es pasar a binario todos los datos respetando los 4 bits máximo que se necesitan para representar un número de una cifra: obtenemos lo siguiente (en la captura hemos sustituido los 0’s por espacios:

No se ve nada claro pero si nos fijamos un poco y dado que el nivel se llama “menos significativo” si miramos el bit menos significativo de cada cifra, podría haber algo:

Cómo modificamos el programilla para ello? facil:

Elegimos el ultimo bit de esa forma y obtenemos lo siguiente:

A simple vista no se ve mucho, pero si sustituimos los 1’s y los 0’s por algo que contraste mas:

Obtenemos la solución:

3v3n4ch1ldC4nd0it

PD: … Visto esto podría habersenos ocurrido antes pero …. basta con mirar que el numero de la lista original sea un numero par o impar…. el bit menos significativo en binario, nos indica si el número decimal correspondiente es par o impar …

Solve-It GE07: Nivel 4

Vamos con otro Solve-It de los facilitos (la pista demasiado clara eh? marcan? mu facil :P)

Aquí nos da marcan un fichero de sonido llamado “ubercat.ogg” que inmediatamente abrimos con Audacity:

La verdad que a simple vista … no tiene mucha historia. Sin embargo marcan nos da una pista bastante clave en este caso (para lo que es él normalmente … que da hasta las pistas codificadas…)

Vamos a echar un ojo al Espectro del sonido; audacity tiene una herramienta para ello:

Vaya … qué cosas … Mira lo que nos encontramos en la banda por encima de los ~27KHz…

Tiene bastante pinta de que ahí hay algo…

Vamos a pasarle un filtro paso alto para quitarnos toda la morralla de la parte de las frecuencias inferiores a 27KHz a ver qué nos encontramos:

Aplicamos el filtro y anulamos lo máximo que podamos el resto de frecuencias (con la configuración de la captura anterior) y nos sale esto:

Choprechaa!! aquí hay algo, está clarísimo. Podría ser morse pero ….. los huecos y las franjas son bastante irregulares …. Vamos a acentuar estos cambios amplificando el “volumen” de la siguiente forma:

Amplificamos al máximo permitiendo el corte de la forma de onda y …:

… Bueno, a estas alturas y ya con este aspecto …. creo que está bastante claro de qué se trata …. 😉

Limpiamos un poquito la imagen y le pasamos por un lector de códigos de barras:

Listo! tenemos nuestro código:

c0de_NYAN128