Euskalbar Chromerako

TL;DR;

Euskalbar Chromerako eskuragarri daukazu. Ctrl-Shift-U (klik bat, lehen bezala) sakatu eta zuzenean bilatu nahi duzun hitza idatzi. On egin! 🙂

Bertsio luzea

Euskalbar hasiera-hasieratik berridatzi izan behar da (Igor Leturiak egin du -Elhuyar- lan bikain hori, oso denbora laburrean). Zergatik? Firefox-en egindako plugin-ak modu batean programatzen ziren (XUL eta bere API propioa erabiliz) eta Chromen beste era batera (WebExtensions APIa erabiliz). Emaitza: plugin bat garatzerakoan lan bikoitza egin behar zenuen bi nabigatzaileetan erabili nahi izanez gero. Izan ere, MS Edge (lehen Internet Explorer zena) nabigatzaileak ere WebExtensions APIa erabiltzen du orain. Istorio luze bat laburbilduz: Euskalbarreko kodea zakarrontzira bota eta hutsetik, zerotik hasi behar izan da. Eta epe baten barruan: azaroak 1ean WebExtensions APIa erabiltzen ez duten pluginak desgaitu egin dira.

Gauzak horrela, Chrome asko erabiltzen dudanez nire lanerako, Euskalbar-aren kode berria moldatu egin dut Chromen ere erabili ahal izateko. Aldaketa txikiak izan dira. Gero Web Store-ra igo dut. Tartean, kode nagusian ekarpen gutxi batzuk egin ditut… Besteak beste, erabilgarritasunari begira, klik bakar batekin funtzionatu behar du Euskalbar: alegia, Ctrl+Shift+U edo MacOSX-n Cmd+Shit+U sakatuz, automatikoki testua bilatzeko eremua hautatu egin behar da… Firefoxen oraindik ez dugu lortu baina Chromen bai.

Ea horrela erabiltzaile batzuen antsietatea lasaitzen den 🙂

FAQ

Zergatik aldatu da Euskalbarraren egitura? Lehen toolbar bat genuen eskuragarri aldi oro…

Bai, WebExtensions APIak oraindik ez du hori egiten uzten. Utziko digu? Agian bai, agian ez… Baina APIak aukera hori ematen badu noizbait, ziur Euskalbarran sartzen dela

Chromerako eta Firefoxerako bertsioak berdinak dira?

Bai, oinarrian, iturburu-kode bera erabiltzen dute. Noski, berezitasun txiki batzuk ere aurkituko dituzu, baina xehetasunak izango dira, inoiz ez funtzionalitate berriak.

Instalar soporte yaml-dev en PHP para OSX

Receta rápida para instalar soporte YAML en PHP 5.6 para OSX Sierra.

Añadir tap de php a brew:

$ brew tap homebrew/homebrew-php

Instalar librería dinámica yaml.so

$ brew install php56-yaml

Comprobar ruta de instalación:

$ ls -l /usr/local/opt/php56-yaml
/usr/local/opt/php56-yaml -> ../Cellar/php56-yaml/1.3.0

Crear php.ini para poder editarlo e indicar que active la carga de yaml.so:

$ sudo cp /etc/php.ini.default /etc/php.ini

Activar extensión en php.ini:

$ sudo vi /etc/php.ini
extension=/usr/local/Cellar/php56-yaml/1.3.0/yaml.so

Comprobar que ha cargado (reiniciar Apache si el soporte YAML se quiere para el servidor web… en mi caso no hacía falta, dado que el soporte se requería para línea de comandos):

$ php -i "(command-line 'phpinfo()')" | grep -i yaml
LibYAML Support => enabled
LibYAML Version => 0.1.7

HackIt! 2017 Level 5. Desempolvando el viejo MacOS

Ojo, ¿qué ha pasado con el nivel 4? W0pr lo ha descrito a la perfección usando Radare. La verdad es que es una delicia leer sus posts. En lo que a DiarioLinux respecta, lo solucionamos usando IDA Pro (en casa del herrero cuchara de palo) Bueno, realmente lo solucionó Kotxerra mientras nosotros dormíamos plácidamente a las 4AM. Echadle la culpa a él, por ser tan eficiente 😉 De hecho, nos impartió un mini-taller sobre la solución. Lo tengo documentado en uno de los backups que hice, así que en cuanto tenga un rato, lo desempolvaré para dar otra posible solución.
Lo que me interesa ahora es mostrar cómo abordamos el nivel 5. Poca gente lo solucionó… si no recuerdo mal (y el pantallazo de este post así lo ratifica), sólo W0pr (hats-off again) Por lo que comenté con ellos, hicieron análisis estático del código desensamblado. Nosotros seguimos otra vía, seguramente más tortuosa (y obviamente con peores resultados) pero interesante como ejercicio. Pero vayamos por partes. ¿De qué trata el level 5, Infinite Loop? Nos pasan un archivo infiniteloop.sit que hay que crackear. Los ficheros .sit son archivos comprimidos (Stuffit) que guardaban el ejecutable de los viejos MacOS 9. Ojo al parche, porque lo primero que se nos ocurrió fue encontrar un descompresor para Linux, ejecutar un emulador de MacOS9 sobre el ejecutable y depurar. No íbamos mal encaminados… Salvo que los .sit guardan datos de recursos (conocidos como «resource forks«) y metadatos del ejecutable y, sin ellos, el ejecutable realmente no sirve para nada. Nótese la «gracia» del título del level (A fork in the road…)

Long story short, encontramos la forma de instalar un emulador de MacOS 9 (la versión 9.2, no valía ni la 9.0, ni la 9.1, por experiencia) sobre qemu… sobre MacOSX Sierra :), tras muchas vueltas, usando SheepShaver. Cuando digo muchas vueltas estoy hablando de unas 5-6 horas, con gente muy experimentada. Fallaba por todos los lados: la instalación, el sistema de archivos, cuelgues en medio de la instalación, and the kitchen sink.

Pero finalmente, conseguimos instalarlo, subir el .sit.hqx y ejecutar. ¡Magia!

Cuando lo comentamos con @marcan42 vimos brillo en sus ojos: «¡Por fin alguien que lo ha ejecutado!». Y no me extraña, la verdad. Sin embargo, las cosas no eran tan fáciles como nos esperábamos…

Lo primero que llama la atención es que, tras teaclear el código de unlock, asumíamos que podríamos cancelar y volver a intentarlo con otro código (básico para poder depurar). Pero no, la ventana de FAIL se quedaba fija en pantalla y NO había forma de quitarla, teniendo que resetear la máquina entera (OMFG!)
Lo siguiente que intentamos fue instalar un debugger en MacOS 9.2. Como puede observarse en la primera pantalla, donde se ve el logo de MacOS y debajo el texto «Debugger installed», tenemos instalado MacsBug, un debugger un tanto arcaico para Motorola 68000. La gracia es que para activar el debugger, es necesario pulsar la combinación de teclas «Command-Power» (Programmer’s key), lo cual, en qemu, y con un teclado de un MBP moderno, no logré hacerlo ¯\_(ツ)_/¯

HackIt! 2017 Level 3


usbmon es una funcionalidad ofrecida por el kernel Linux para recolectar trazas de entrada/salida que usen el bus USB. El level 3 nos plantea unas trazas de texto plano obtenidas a través de usbmon.

Tras mucho analizar, allá donde esperábamos información sobre el dispositivo USB en concreto, vimos que había tres líneas censuradas.

Intentamos también convertir la salida ascii de usbmon a formato .pcap para manejar el dump más cómodamente desde wireshark, pero no lo conseguimos. Así que tocaba parsear el fichero de texto. Antes de ponernos a programar un parser, buscamos alguno ya existente y encontramos varias alternativas, entre ellas este script en python que además generaba su salida en un bonito HTML.

Lo intentamos por todos los medios. Lo primero fue extraer los datos de tipo isochronous e interpretarlos: como raw image, como audio, como señal de unos y ceros… agua.

Hasta muchas horas después de planteado el reto, nadie lo solucionó. Si no recuerdo mal, el lunes 24 pusieron la primera pista: «Audio parece, pero audio no es.» que nos dejó igual que estábamos (bueno, redujo el espacio de búsqueda, eso sí). La madrugada del lunes al martes (a eso de las 4am) se publicó la segunda pista, pero nos pilló exhaustos, y a la mayoría dormidos. La segunda pista restauraba parte de las líneas del dump eliminadas, facilitando información sobre el dispositivo que las generó. Un láser. Seguramente se nos tenía que haber ocurrido antes, conociendo al autor de la prueba y su afición por estos dispositivos

No sé si w0pr solucionó este reto con esta segunda pista o con la primera… pero ¡lo solucionó! Así que espero que publiquen el write-up para actualizar este post con el enlace directo.

UPDATE (30/07/2017): w0pr ha publicado la solución completa a este reto.

HackIt! 2017. Level 2

¡Y vamos a por bingo! El nivel 2 nos pide que encontremos el secreto que esconde una captura de tráfico de red. Realmente esto me sonaba a otra prueba del hackit… de 2007 (!). Abriendo la captura con un wireshark moderno, vemos tramas bluetooth. Probablement de algún dispositivo que envía datos, y en concreto, este SoundCore-Sport-XL-Bluetooth-Speaker.

Seleccionamos Telephony / RTP / RTP Streams…

Y oímos la señal, pero muy distorsionada. Aquí tuvimos un problema: queríamos exportar el audio para poderlo tratar con Audacity. Pero oh, sorpresa, no era posible:

Aquí se nos ocurrió una solución tal vez no muy «ortodoxa», pero que funcionó perfectamente 🙂 Abrimos Camtasia, lo configuramos para grabar sonido del sistema y le dimos al Play stream en Wireshark. Exportamos luego el resultado de la grabación a formato mp4 (en Camtasia) y lo abrimos con Audacity, aplicándole el efecto de cambio de speed, encontrando la solución (fuaaaa!) 🙂