admin

HackIt, SolveIt and SmashCTF (II). カッター注意

Nos pasan una captura .pcap que abrimos con Wireshark. Vemos en los primeros paquetes UDP que el dispositivo 10.10.0.78 se está comunicando con el 10.10.0.70.

Según la MAC, el .78 ha sido fabricado por CASIO (lo que cuadra con la pista del level). Se trata de un tagger (según los strings de los primeros paquetes), y parece que el modelo es un MEP r2 (?). Buscando Casio Tagger MEP en Google, sale una pequeña impresora o etiquetadora. Si buscamos en el Twitter de marcan algo relacionado con las palabras clave:»casio marcan42 twitter»… Bingo!

Es más, el tweet en cuestión apunta a un Gist con un programa en Python que implementa el protocolo de la impresora para poder convertir, enviarle e imprimir imágenes a partir de ficheros.

Leyéndolo mientras tenemos el pcap abierto, vemos que inicialmente se realiza un primer intercambio de mensajes de protocolo (donde se especifica, entre otras cosas la altura y anchura de la imagen)

>>> import struct; struct.unpack("<HHxx", "\x70\x01\x00\x17\x00\x00")
(368, 5888)

1 2	>>> import struct; struct.unpack("<HHxx", "\x70\x01\x00\x17\x00\x00") (368, 5888)

Hay 368 filas * 16 columnas de bytes. Por tanto 16×8 = 128 bit en cada fila.

Los datos de la imagen en sí comienzan a enviarse a partir del paquete 43 (todos aquellos con un payload de 512 bytes). Ya tenemos todo preparado para extraer los datos que forman la imagen.

Si ejecutamos el script:

python leer.py > payload.bin

1	python leer.py > payload.bin

Podremos resolver directamente con:

xxd -b -c 16 payload.bin

1	xxd -b -c 16 payload.bin

Pero ya que tenemos el código para hacer el encoding de una imagen a 1’s y 0’s, podemos invertir el proceso fácilmente:

Y resolver 🙂

PD: カッター注意 = Cutter Attention ? (algo así como, «cuidado con la cuchilla» – que corta los trozos de papel de la impresora?)

HackIt, SolveIt and SmashCTF: aprender es un regalo (I)

Como todos los años, desde la Euskal Encounter 7 (antes Euskal Party), acudimos a la cita. La cuestión no es sólo intentar ganar (que también), sino aprender. Y aunque cada vez conocemos más técnicas, herramientas y teoría de nuestra área, en muchas ocasiones, tras pelearme con las pruebas del HackIt y SolveIt, me da la sensación de que mis lagunas de saber son también cada vez mayores. ¿Qué sé de la codificación Manchester? ¿Qué demonios es Toslink S/PDIF? Por no hablar de conocimientos olvidados hace muuucho tiempo (¿cuál es la estructura química de la aspirina?). Pero…

«El éxito es aprender a ir de fracaso en fracaso sin desesperarse (Winston Churchill)»

Así que, cada Euskal, los incombustibles de DiarioLinux (tal vez el año que viene seamos Ikasten.io, ahora que está de moda cambiarse de nombre, ¿eh Failrz? :), volvemos a intentarlo.

En el HackIt de 2018 quedamos en tercera posición, pero conseguimos resolver tres pruebas (y la tercera, tras mucho dolor, a eso de las 5am del sábado). En el SolveIt no nos solemos obcecar tanto, y este año, sólo pudimos resolver la primera prueba. Un FAIL doloroso, sí.

«Aprender es un regalo, aunque a veces el maestro sea el dolor» (Anónimo)

Nos gusta comentar las pruebas una vez que termina el deadline. Las locuras (trolleos) de marcan y cómo nos hemos buscado la vida para resolverlas. En esta edición, hubo un debriefing con las tres secciones (HackIt, SolveIt, SmashCTF) a las 00:00 del domingo (justo tras el deadline) y ahí, cuando aún tienes frescas las ideas que has ido probando durante unas 60 horas -y tienes una terrible curiosidad -«jakin-mina»- por conocer la respuesta de ciertos retos que no te han dejado dormir, es cuando realmente prestas atención a las explicaciones. Cuando tienes sed por aprender. Y cuando aplaudes los esfuerzos de otros grupos por superar el dolor – sueño, cabreos y dolores de cabeza 🙂 de intentar avanzar una prueba más, de leer con más detalle una especificación, de entender hasta el más mínimo detalle un binario de una plataforma arcaica… Creo que ese esfuerzo, esa motivación por mejorar, es lo que me contagia y hace que, año tras año, deje todo por estar ahí.

Y sin más preámbulos ( ni citas ! 🙂 , vayamos con la chicha. Prueba 1 del HackIt.

Simple código en JavaScript que opera con los valores introducidos en el input, realizando 10 comparaciones (2 por cada vuelta, 5 vueltas) para confirmar que cumplen los criterios que lo validan como contraseña. La variable c lleva el contador de condiciones que se cumplen. Lo único que despista inicialmente es que suma dos booleanos ( condición booleana + condición booleana). La idea es que false se evalúa como 0 y true como 1.

Aunque inicialmente pensamos en resolver el level de manera ortodoxa (resolver el sistema de ecuaciones), al final consideramos mucho más rápido usar fuerza bruta – pulsa sobre la imagen para ampliar – 🙂

Y con un console.log(solucion), pasamos al siguiente nivel…

IEEE Xplore, India y plagios en artículos académicos

En la lectura diaria de artículos me encuentro últimamente con algunas piezas, disponibles en la web de IEEE Xplore, donde me llevo sorpresas desagradables. El de hoy me ha hecho especial «gracia». Se trata de «A Novel Approach for Medical Assistance Using Trained Chatbot» de la conferencia
«2017 International Conference on Inventive Communication and Computational Technologies (ICICCT)», y disponible, como digo, en IEEE Xplore.

Son cinco autores del mismo departamento: Department of Computer Science & Engineering, Muthoot Institute of Technology and Science-Varikoli, una entidad educativa de la India.

Me llamó la atención que ninguno de los autores usara un email de la institución a la que pertenecen. Todos ellos son direcciones Gmail.

Por otro lado, hay al menos un par de errores gramaticales de bulto en el abstract. Son «bad smells», heurísticos que indican que lo peor está por llegar.

En efecto, el artículo está plagado de más errores de ortografía y gramática, pero sobre todo, de «olvidos» a la hora de citar. Sí, es una forma elegante de decir plagios. Me dí cuenta del mismo al ir leyendo los párrafos. Todos ellos de pésima calidad, salvo un par, con un inglés perfecto, pulcro. Por supuesto, sin citar, ni refrasear, ni entrecomillar, ni gaitas. Copia literal sin citar al autor. Con un par.

Una búsqueda en Google me llevó a la fuente original:

«Content is king, so don’t distract your user with fancy but redundant features. Also, simplicity is what helped the most successful brands win our hearts. These things are the core of a Chatbot concept that’s why they are doomed for success.»

Aunque buscando un poco más, me he llevado una sopresa extra. Por un lado, ese artículo «parece» el original. Pero según Google, fue publicado el 10 de noviembre de 2016. Y otra vez según Google, ese mismo párrafo fue publicado por esta otra web el 12 de junio de 2016:
[Quiz] 9 Reasons to Build a ChatBot Now – Letzgro

Algo me decía que eso no podía ser… La web de letzgro.net huele a web depredadora, con un estilo gráfico bastante malo. Por otro lado, la web de Chatbots Journal, tiene un estilo muy cuidado y en ella escriben en exclusiva artículos relacionados con el tema que nos concierne. ¿Qué está ocurriendo? Pues no sé cómo lo han hecho en Letzgro, pero según Web Archive, esa página no es de junio de 2016 sino que apareció en 2017.

PD: al paper plagiador se le fue de las manos. En la siguiente frase leo: «You may read about these two in more detail in some of our other blog posts». Yeah… blog posts. Lo peor: IEEE Xplore pide 31$ por leerlo 🙁

How to access the value of an array key in a Javascript Map object?

I wrote this message in StackOverflow and just before clicking the Send button I stumbled upon the solution. I don’t want to lose it, and I don’t have time today to publish the solution, so I decided to do it in two parts. First, publish the question and later (tomorrow?) publish the solution. Here we go!

I can set() a value using an array as a key in a JS Map, but it seems that there isn’t a clean interface to access that same value using the symmetric get() method:

  let z = new Map {}
    
    z.set([1,2], "a"); // Works as expected: Map { [ 1, 2 ] => 'a' }
    
    z.get([1,2]); // undefined (!)

let z = new Map {}

z.set([1,2], "a"); // Works as expected: Map { [ 1, 2 ] => 'a' }

z.get([1,2]); // undefined (!)

I suspect that this behaviour has something to do with the fact that in JS:

 [1,2] == [1,2] 
    false

1 2	[1,2] == [1,2] false

I can use [1,2].toString() as a key and then the z.get([1,2].toString()) method works as expected, but I’m wondering if there is in any other «cleaner» way to code that.

UPDATE:
Well, Map objects are a new addition of ES6. And it seems that ES6 has a problem with Maps if you are trying to use them with object keys. This has been discussed here
https://esdiscuss.org/topic/maps-with-object-keys and here https://stackoverflow.com/questions/21838436/map-using-tuples-or-objects .

A solution that WorksForMe was proposed in that same StackOverflow thread, using an ad-hoc built HashMap class, that takes a hash function as parameter to properly store and use object keys (specifically, for my problem, array keys)

function HashMap(hash) {
  var map = new Map;
  var _set = map.set;
  var _get = map.get;
  var _has = map.has;
  var _delete = map.delete;
  map.set = function (k,v) {
    return _set.call(map, hash(k), v);
  }
  map.get = function (k) {
    return _get.call(map, hash(k));
  }
  map.has = function (k) {
    return _has.call(map, hash(k));
  }
  map.delete = function (k) {
    return _delete.call(map, hash(k));
  }
  return map;
}

function HashMap(hash) {

var map = new Map;

var _set = map.set;

var _get = map.get;

var _has = map.has;

var _delete = map.delete;

map.set = function (k,v) {

return _set.call(map, hash(k), v);

}

map.get = function (k) {

return _get.call(map, hash(k));

}

map.has = function (k) {

return _has.call(map, hash(k));

}

map.delete = function (k) {

return _delete.call(map, hash(k));

}

return map;

}

I have used it as follows (note that JSON.stringify is NOT a hash function, but as I said, it works for my example because I certainly know that my array values are not going to have duplicates). I should think about a proper hash function or use something from here, but as I said, I’m lazy today 🙂

  let z = new HashMap(JSON.stringify);
  z.set([1,2], "a");
  z.get([1,2]); // "a"

let z = new HashMap(JSON.stringify);

z.set([1,2], "a");

z.get([1,2]); // "a"

VirtualBox headless en servidor Scaleway

Esta semana he necesitado instalar una máquina virtual de VirtualBox en un servidor Scaleway (de 2.9€/mes) sin entorno gráfico. La primera duda ha sido… ¿se puede? 🙂 Lo primero que necesitamos es instalar VirtualBox. La particularidad es que Scaleway no tiene un kernel vanilla sino que está bastante personalizado para adaptarlo a esta empresa de cloud hosting. Así que hay que descargar el código del kernel, ajustar su configuración a la misma que usa Scaleway, compilar los módulos necesarios y ahora sí, descargar e instalar VirtualBox. Gracias a $DEITY, alguien se ha pegado el curro de preparar un script al efecto. La última parte de ese script instalar una máquina virtual Windows en VirtualBox (yo no lo necesito, he comentado esas líneas).

Bien, ya tenemos el kernel preparado y VirtualBox instalado. Ahora, ¿cómo demonios instalo una máquina virtual a partir de una imagen .iso si no tengo entorno gráfico? Bueno, simulando el entorno gráfico a través de phpVirtualBox (sí, existe tal engendro y funciona de lujo). Además, este tutorial te explica cómo instalarlo paso a paso.

Finalmente, si quieres acceder a la consola que VirtualBox abre por defecto cuando lanzas una máquina virtual Linux, podrás hacerlo vía RDP (Remote Desktop Protocol). Tampoco sabía que una VBoxHeadless abría el puerto 9000 para acceso RDP. Desde tu host remoto puedes ver la consola de VirtualBox vía rdesktop (en Linux) o vía Microsoft Remote Desktop en OSX.

También es posible usar la línea de comandos para lanzar la máquina virtualbox desde una shell en Scaleway (sin necesidad de usar phpVirtualBox, pero es mucho menos intuitivo)