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:

Captura de pantalla 2018-08-29 a las 15.59.32

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:

Nagrasyster_encoded_frame.png

(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):

Audacity_01.PNG

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:

Syster_01.PNG

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:

Audacity_02.PNG

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…:

CryptImage_04.PNG

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:

CryptImage_02.PNG

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 ….

VirtualDub_03.PNG

¬¬

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:

Captura de pantalla 2018-08-29 a las 16.03.49.png

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

VirtualDub_02.PNG

Listo, vamos a compilar todo … :

VirtualDub_01.PNG

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

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

CryptImage_03.PNG

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 …..

Producer.PNG

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:

Captura de pantalla 2018-07-29 a las 11.26.51.png

“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:

photo_2018-08-17_15-49-51.jpg

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!!

photo_2018-08-17_16-12-19

… 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:

photo_2018-08-17_16-38-13

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:

Captura_Enunciado.PNG

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

goindown.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:

Captura_FileGoindown

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. Todo es 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:

Captura_alpha.PNG

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

Captura_MiReDo.PNG

MiReDo>>

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

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

Captura_ascendente_piano

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):

Captura_ascendente.PNG

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 (he puesto antes la captura).

Así que vamos a empezar por eso:

Captura_notas_octave

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

En primer lugar hay que elegir una frecuencia de muestreo (el mundo digital es lo que tiene…). Esto me da un poco igual, pero ya que es gratis voy a poner 44100Hz que es más o menos lo normal (además de 48000Hz):

>> fs=44100;

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

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

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

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

S·sin(w) , 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’)

Captura_SinLA.PNG

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, bastará 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 de tras de otras y 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:

Captura_nOTAS_bIEN.PNG

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 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 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.

Lo que hace esa linea de código es concatenar los arrays de las ondas que generamos para cada nota (cada diferente frecuencias), 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 multiplicarlo por 2 (su frecuencia en una octava mayor es el doble). Y si queremos hacer un C6, habría que multiplicarlo por 4 (o la C5 por 2) y así sucesivamente y con todas las notas.

El resultado de hacer esto es un array gigantesco de 1190727 elementos:

Captura_chorizo.PNG

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 de algo decente.

Si hacemos que la duración del sonido sea en total de 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é que 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:

photo_2018-08-03_12-07-04

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:

IOPS01

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:

IOPS02

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:

IOPS03.PNG

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:

IOPS04.PNG

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… ):

IOPS05.PNG

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:

IOPS06.PNG

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:

IOPS07.PNG

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:

IOPS08.PNG

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:

 

photo_2018-08-03_10-52-35.jpg

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 …

retro.png

… 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.