Un tip rápido que me tenía intrigado desde hace tiempo. Si usas VirtualBox en macOS, seguro que al tener una máquina virtual lanzada has pulsado sin querer Command+c (⌘+c) para copiar texto (la combinación por defecto en macOS) en lugar de Ctrl+C (la combinación por defecto en Linux y Windows). El problema es que en VirtualBox la combinación Command+C escala el tamaño de la pantalla (¡y la hace minúscula!). Para desactivar este molesto comportamiento, basta con entrar en las preferencias de VirtualBox (pulsa ⌘ + ,
), pestaña Input, pestaña VirtualMachine, pulsa sobre ScaledMode y elimina el dichoso shortcut.
Autor: admin
HackIt, SolveIt and SmashCTF (III) – HTML5 DRM – Conflicto ideológico
DRM y HTML5. EME (Encrypted Media Extensions). Hay que empaparse algo sobre estos temas para resolver el nivel. EME ofrece un API que permite a las aplicaciones web interactuar con sistemas de protección de contenido para poder reproducir audio o video cifrado. El famoso DRM en HTML5, algo que muchos consideran una aberración (la web nació para ser abierta, no para ofrecer contenidos cerrados). Pero… ahí está el API. Y es precisamente lo que hay que intentar resolver. Básicamente el cliente tiene una etiqueta video. Al pulsar el play se visualizan 26 segundos. Pero a partir de ahí, todo está negro. Parece que el video webm está protegido. En el código vemos que en un momento dado se hace una petición de licencia a un servidor license, que nos envía la clave para desproteger el webm.
Pero esa petición sólo se puede hacer si rellenamos los bytes que faltan… esos bytes forman parte de la solución al sudoku que nos han puesto debajo del vídeo. ¿Qué hacer cuando tengamos la clave de desprotección del vídeo? Visualizarlo en el navegador 🙂 ¿Y después? Bueno, eso lo veremos enseguida… Vayamos por partes. Lo primero es solucionar el sudoku. Lo siguiente es automatizar el proceso de meter los números en las casillas del sudoku (hacerlo a mano es un infierno).
Solucionar el sudoku es fácil. Entramos en sudoku-solutions.com, metemos los datos y pulsamos en check…
Vaya, tiene 9 soluciones posibles. No podía ser tan fácil …
Para no perder tiempo tecleando cada una de ellas, podemos automatizar el proceso. Abrimos la consola JavaScript y tecleamos:
var sudoku = $("#su input") var s ="852931647473862159961547283318476925549328761726159834637294518194685372285713496" for (var i = 0; i < sudoku.length; i++){ sudoku[i].value = s.charAt(i); } $("video")[0].needs_reload = 1; |
Por cierto, en ese código ya va la solución correcta 🙂 La última línea informa al navegador que el sudoku ha cambiado y debe leer sus datos. Bien, todo preparado. Pulsamos play y vemos que pasamos del segundo 26. Es un trailer de «Inception». Hay una serie de fotogramas que muestran pixels distorsionados. Seguramente porque se haya introducido por ahí algún string que no debería estar… Habrá que bajar el webm, descifrarlo y abrirlo más o menos por esa parte, para ver de qué string se trata.
¿Pero cómo obtenemos la clave de descodificación del webm? (el navegador la conoce, pero necesitamos aislarla…) ¿Por cierto, cuántas claves habrá? Vamos allá.
Abrimos main.js y metemos un punto de ruptura en la línea 71
}).then(function(e) { var n = (e = new Uint8Array(e)).slice(0, 12); return window.crypto.subtle.decrypt({ name: "AES-GCM", iv: n, tagLength: 128 }, r, e.slice(12)) }).then(function(e) { breakpoint ---> return t.target.update(e) }) |
En e tendremos la clave. Ojo, veremos que el breakpoint se ejecuta dos veces, y necesitaremos apuntar ambas claves (una es para cifrar el vídeo y otra para cifrar el audio). Creo recordar que no era «tan sencillo», sino que había que convertir el formato de las claves obtenidas en «e» con una línea como
atob(String.fromCharCode.apply(null, new Uint8Array(e))) |
y a continuación extraer las claves de 16 bytes con un script como el siguiente (una de las claves era w-UHS…):
var b64string = "w-UHS56ogAQacZLNj1TpqA" ; var buf = Buffer.from(b64string, 'base64'); var fs = require('fs'); fs.writeFile("key.txt", buf, "binary",function(err) { if(err) { console.log(err); } else { console.log("The file was saved!"); } }); |
Momento de descargar el vídeo (cifrado) y descifrar. ¿Cómo desciframos? Bien, sabemos la clave y tenemos el vídeo cifrado. Nos falta saber cómo se cifró. Investigando un poco, nos encontramos con la utilidad webm_crypt de las webm-tools. Tiene una dependencia con libwebm, pero siguiendo las instrucciones de compilación del anterior enlace, lo podremos obtener sin problemas (en Linux, en macOS no iba).
Desciframos con :
$ webm_crypt -i input.webm -o decrypted.webm -decrypt -audio_options base_file=clave1 -video_options base_file=clave2 |
Y por fin, podremos abrir el fichero decrypted.webm (por ejemplo, con vlc…)
o con strings (!)
$ strings -n 10 decrypted.webm |
(Nota: -n 10 = dame los strings ASCII de decrypted.webm que puedas visualizar, siempre y cuando esos strings sean de longitud mayor o igual a 10)
Y analizando la salida de strings, veremos la clave para el siguiente nivel 🙂
PD: creo que hay una herramienta que te permite pasar como input un vídeo webm y una marca de tiempo (hh:mm:ss) y te da como salida el contenido del fotograma de esa marca de tiempo. Lo cual te evitaría el uso de strings (o lo facilitaría). Pero eso lo dejo para que la gente de W0pr, navarparty o Barcelona92 nos lo cuenten en los comentarios.
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("Hay 368 filas * 16 columnas de bytes. Por tanto 16x8 = 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.binPodremos resolver directamente con:
xxd -b -c 16 payload.binPero 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 – 🙂
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 🙁