Photaka Link: De “¿Me pasas la foto por WhatsApp?” a “Ya la tengo en el móvil”

Cuando usas una cámara de fotos profesional o casi-profesional, hay escenas que todos hemos vivido: estás en una sesión, miras la pantallita de la cámara, haces zoom con el joystick para comprobar el foco, y luego te piden “¿me la puedes pasar?”. Toca abrir la Wi-Fi de la cámara, emparejar, cruzar los dedos y rezar para que el RAW no tarde mil años. Spoiler: tarda. Y si encima hay interferencias, olvídate. Con Photaka Link el guion es otro: conectas un cable USB de la cámara al smartphone o tablet, y en segundos tienes el flujo de trabajo que siempre quisiste en movilidad: vista previa en vivo, selección de fotos y descarga inmediata al teléfono. 

Figura 1: Photaka Link - De “¿Me pasas la foto por WhatsApp?”

a “Ya la tengo en el móvil” 

La idea es sencilla y, como casi todo lo que funciona, está bien ejecutada: el móvil se convierte en tether, monitor de revisión y backup portátil, todo con un solo cable. Y ya la tienes disponible en Android y iOS, la app ya anuncia compatibilidad con cámaras Canon, Nikon y Sony y la conexión directa por USB (nada de inventos raros). 

¿Qué hace exactamente Photaka Link hoy? (y por qué a los hackers de la foto nos gusta)

• Habla MTP con tu cámara profesional: MTP (Media Transfer Protocol) es la evolución del clásico PTP de las cámaras: pensado para mover fotos y medios por USB de forma controlada y sin montar el almacenamiento como un disco “a pelo”. Es estándar desde 2008 y en Android es lo normal desde hace años. Traducción: robusto, interoperable y sin dramas. 

• Modo sesión (tether): mientras disparas, vas recibiendo JPEG o RAW para revisar al vuelo en el móvil/tablet.

• Modo importar: además de fotos, ya añade vídeo cuando importas material almacenado en las tarjetas SD de la cámara.

• Simplicidad: enchufar, confirmar conexión, ver, seleccionar, disparar, en modo sesión o importar. Sin menús arcanos ni emparejamientos caprichosos. 

Nota de campo: en la web oficial tienes un resumen muy claro de la filosofía: “tu móvil o tablet como tether, monitor de preview y backup, con un solo cable”. Es justo el tipo de UX que agradeces cuando hay prisa.

¿Por qué cable y no Wi-Fi de la cámara?

Porque los bits pesan, sobre todo cuando son RAW de 45 MP o clips de vídeo de 500 MB. Y porque la física manda.

• USB 2.0 (Lightning y muchas cámaras antiguas): 480 Mb/s teóricos (≈ 60 MB/s). Muchos iPhone/iPad con Lightning se quedan aquí; el propio adaptador oficial lo deja claro.

• USB-C moderno (USB 3.x): 5 Gb/s (USB 3.0/3.1/3.2 Gen1) y hasta 10 Gb/s en equipos que lo soportan. Por ejemplo, iPhone 15 Pro/15 Pro Max (y generaciones Pro posteriores) anuncian USB 3 hasta 10 Gb/s —eso sí, usa cable compatible USB 3; muchos cables “de carga” van a USB 2 y te dejan en 480 Mb/s.

• iPhone 15/16 “no Pro” con USB-C: siguen en USB 2 (480 Mb/s). No es magia: cambia el conector, no el bus.

¿Y que nos da la Wi-Fi de la cámara? Muchas cámaras sólo montan 2.4 GHz con 802.11n (lo típico: hasta 150 Mb/s de enlace en 20 MHz) y rendimientos reales muy por debajo (decenas de Mb/s). Algunas, con módulos dedicados, saltan a 5 GHz / 802.11ac, pero aún así la experiencia real baila según radio, interferencias y stack de software. Es decir: más latencia y menos previsibilidad que un USB decente.

La conclusión práctica: un buen cable (y un puerto que dé de sí) suele ganar en consistencia y velocidad para grandes JPEG, RAW y vídeo. Y esa es la apuesta de Photaka Link: menos fricción, más flujo. 

Consejos de “cacharreo” para exprimir Photaka Link

• Elige bien el cable: si tu teléfono/tablet/cámara anuncia USB 3, usa cable USB 3 (o Thunderbolt 3/4 válido para datos). El “cablecito” de carga que venía en la caja puede dejarte en USB 2. Apple lo documenta: su cable de carga USB-C se queda en 480 Mb/s. 

• OTG activo en Android: en la práctica, casi todos los Android modernos con USB-C actúan como host, pero si usas adaptadores raros, verifica que soportan datos (no solo carga).

• Alimentación: algunas cámaras consumen más si están alimentando el móvil por el bus. Si notas caídas, usa un hub con alimentación o configura la cámara para no suministrar energía por USB (si lo permite).

• Flujo de sesión vs importación: usa sesión para revisar composición y foco al vuelo y transferir las imágenes en tiempo real al dispositivo. Deja importar para cuando no trabajes con el dispositivo conectado y quieras acceder y descargar archivos más tarde (incluido el vídeo).

• Espacio y backup: recuerda que el móvil es tu buffer: libera espacio o sincroniza rápido a tu nube preferida. La hoja de ruta de Photaka Link apunta a almacenamiento en la nube y posprocesado integrados, pero ya llegamos a eso.

¿Dónde encaja esto en el proyecto grande de Photaka?

Photaka Link es la pieza de base o componente de un plan más ambicioso: un ecosistema donde los creadores profesionales (foto y vídeo) entregan en tiempo real contenido a sus clientes —Memories as a Service— con una marca de consumo clara y una red de fotógrafos en ubicaciones icónicas o muy concurridas. En el pitch deck, se resume con un lema que me encanta: 

“We capture your happiest moments instantly” 

y un flujo B2C/B2B con fotógrafos desplegados y listos para disparar, el resultado se procesa y se entrega inmediatamente y el cliente compra lo que desee desde la app.

Figura 2: Photaka Link para Android

En ese camino, Photaka Link seguirá creciendo: más cámaras soportadas, métodos de conexión (cable hoy; mañana… ya veremos), post-procesamiento en el dispositivo o en la nube, y sincronización en la nube. Si te dedicas a eventos, bodas, viajes o prensa, ya ves por dónde va: ampliando tus posibilidades para entrega inmediata y sin alquimia.

Un poco más técnico: MTP, PTP y por qué no es “montar un disco”

Cuando conectas la cámara por USB con Photaka Link, no estás montando un volumen como si fuera un pendrive. Estás hablando de MTP/PTP: un protocolo a nivel de objetos (ficheros, miniaturas, metadatos) que expone comandos de alto nivel (listar, obtener, borrar, disparar, etcétera) y deja a la cámara controlar el almacenamiento. Y esto nos da muchas ventajas:

• Menos corrupción: no hay un sistema de ficheros “abierto” en dos sitios a la vez.
• Metadatos ricos: y miniaturas rápidas para revisar y seleccionar.
• Compatibilidad: Android lo usa por defecto; las cámaras lo implementan desde hace años como “clase USB” estándar. 

¿Cuánto “vuela” en la práctica?

La teoría te da límites físicos. El mundo real lo ponen los chips (de cámara y de móvil), el firmware y el cable. Casos reales en foros midiendo Wi-Fi de cámara hablan desde ~12 Mb/s (≈ 1,5 MB/s) en equipos modestos, hasta ~180 Mb/s en setups con 5 GHz cerca del router. Con cable USB 3.x, cuando el cuerpo y el teléfono responden, es normal estar muy por encima de esas cifras y, sobre todo, sin la variabilidad del aire.

Figura 3: Photaka Link para iOS (iPhone & iPad)

Un buena regla hacker es que si tu móvil/cámara está limitado a USB 2, ya has ganado frente a muchos Wi-Fi de cámara reales (480 Mb/s teóricos vs 20–150 Mb/s típicos de 2.4 GHz). Si ambos son USB 3, la diferencia es aún mayor.

Lo que tiene hoy en día:

• Simplicidad de flujo: conectar, ver, elegir, importar. Sin capas de emparejamiento Wi-Fi. 

• Compatibilidad con las tres grandes (Canon, Nikon, Sony): desde el lanzamiento en Android y iOS. (Google Play, Apple)

• Enfoque en sesión: poder revisar RAW/JPEG al vuelo y pasarlos al dispositivo, y dejar el vídeo para importación, tiene sentido cuando estás en exteriores.

Lo que estamos trabajando para después:

• Más marcas/modelos soportados: Y controles remotos (apertura/velocidad/ISO) donde el firmware lo permita.

• Metadatos con la visualización de cada foto: ISO, Velocidad de obturación, Apertura de diafragma, Compensación…

• Posprocesado ligero en el dispositivo: Curvas, LUTs, auto-tones, y presets por sesión.

• Postprocesado en Cloud: Potente mediante el uso de IA en la nube.

• Sincronización cloud con entrega en tiempo real al cliente: Esto encaja con la visión del proyecto Photaka —servicio de consumo de una red de creadores– El equipo de Photaka Link está abierto para recibir sugerencias e ideas con las que evolucionar el producto para ayudar a mejorar el trabajo de los profesionales y aficionados.

Checklist rápido para empezar

• Instala la app en tu sistema: Aquí tienes los enlaces en Google Play y en App Store.

• Cable correcto: Si puedes, USB-C ↔ USB-C con soporte USB 3; evita los cables “solo carga”. 

• Activa conexión USB en la cámara según el manual: Muchas lo ponen como “PC/Remote/PTP/MTP”.

• Dispara y revisa (acepta o descarta) en modo sesión: O accede al contenido de las SDs, importa su contenido (JPEG, RAW y vídeo).

• Accede a los archivos: En dos carpetas en la galería de tu smartphone o tablet, una para modo sesión y otra para importación.

TL;DR: Si eres de los que quieren velocidad y control en movilidad, Photaka Link te quita ruido del medio: cable USB, MTP, RAW/JPEG en sesión, más vídeo en modo importación, y tus fotos en el móvil o tablet sin dramas. Y lo interesante es que no se queda ahí: encaja como núcleo tecnológico de una plataforma para entregar recuerdos en tiempo real a los clientes de los creadores profesionales. Menos fricción, más trabajo hecho. 

¿Te mola? ¿Quieres proponerme algo? Me tienes en MyPublicInbox.

Saludos,

Autor: Kiko Monteverde, emprendedor, founder of Photaka Link

Contactar con Kiko Monteverd

Weaponizar ChatGPT para robar contraseñas WiFi y crear malware

ChatGPT tomó a Internet por sorpresa después de que OpenAI lo liberara al mundo hace poco más de dos meses y la opinión pública de cara a su lanzamiento ha sido bastante reveladora. Ya que al igual que muchos otros usuarios que están emocionados por su potencial, creo que este podría ser el momento en que comience a comprenderse realmente la capacidad revolucionaria de la IA en materia de ciberseguridad.

Figura 1: Weaponizar ChatGPT para robar contraseñas WiFi y crear malware

Aunque en términos generales se le describe como un chatbot, ChatGPT es mucho más que eso. Puede generar textos, explicar temas complejos, actuar como traductor, resolver problemas lógicos, participar activamente en una conversación y completar tareas complejas con una precisión asombrosa, sin mencionar su capacidad para escribir código.

Figura 2: Libro de "Hacking redes WiFi: Tecnología, Auditorías y Fortificación".

de Ferran Verdés Castelló en 0xWord

Es precisamente en esta última y controvertida característica en la que nos enfocaremos por el momento, ya que la demo principal pretende demostrar cómo puede “weaponizarse” a esta inteligencia artificial para abusar de su potencial como creadora de malware.

Figura 3: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Weaponizando ChatGPT para robar contraseñas WiFi 

OpenAI es consciente de que los usuarios malintencionados pueden abusar de ChatGPT e IA similares. Para contrarrestar esto, han introducido filtros para detectar actividad que violaría los términos y condiciones. De tal manera que, si se le formulan preguntas como la siguiente, es casi seguro que declinará siempre la petición.

Figura 4: Negativa de ChatGPT de brindar código

Como podemos notar, se fracasa en la búsqueda de obtener fragmentos de código que la IA tilda como “ilegales” y “poco éticos”. Sin embargo, formulando preguntas más precisas y atómicas se comienzan a conseguir cosas interesantes.

Figura 5: Filtrando los perfiles wifi en forma de lista

Se obtiene un comando funcional que filtra los perfiles de redes wifi almacenados en el equipo y los presenta en forma de lista. Sin embargo, la función “SelectString” utiliza como parámetro de filtrado una frase de dependencia idiomática, lo cual mermaría la funcionalidad del código en equipos configurados en un idioma diferente al español.

Figura 6: Error del bot al generar código

Se le solicita realizar un cambio al código y en efecto, lo hace, pero no de la manera correcta, pues aún implementa en él frases en español, así que de nuevo se pide una corrección.

Figura 7: Corrección de código

Más tarde, se busca la iteración de la función por cada perfil WiFi para lograr extraer las contraseñas de cada una de las redes wifi almacenadas en el equipo con las que alguna vez se estableció una correcta conexión. Todo esto en texto plano y en función de su SSID.

Figura 8: Implementación de ciclo for para iterar instrucción por cada elemento de la lista

Una vez que se obtiene satisfactoriamente la generación de un archivo de texto a nivel local con las contraseñas WiFi, se busca su exfiltración hacia un servidor remoto controlado por el atacante. Sin embargo, se experimentan problemas con la compatibilidad de los comandos en diferentes entornos.

Figura 9: Solución a error de compatibilidad

Posteriormente en pruebas manuales, se identifica el detonante del error durante el despliegue de una petición POST hacia el servidor remoto. Lo cual se solventa codificando la estructura de la petición en Base64 previo a su lanzamiento con “Invoke-Expression”

Figura 10: Codificación de comando en base64 y posterior ejecución con Invoke-Expression

Una vez que la programación del malware está terminada, la dinámica de infiltración y ejecución del código malicioso en la máquina objetivo se centrará en un escenario de Red Team. En el cuál por obviedad, el tiempo para el despliegue de un ataque es un factor crucial para el éxito o el fracaso de la operación. Así que como vector de ataque inicial, se aprovecharán las bondades de los ataques HID con un USB Maligno.

Figura 11: Libro de "Empire: Hacking Avanzado en el Red Team" 
de Pablo González y Sebastián Castro en 0xWord.

Subsecuentemente las pulsaciones de teclas están programadas para dar apertura a una ventana de “Ejecutar”, seguido del referenciamiento hacia el malware, que será ejecutado en memoria a través de IEX de PowerShell en la máquina víctima. El cuál se encargará de extraer todas las contraseñas de las redes WiFi almacenadas en el equipo Windows en un archivo de texto, lo enviará al atacante en texto plano y borrará el archivo de la máquina víctima. Todo esto en solo un par de segundos.

PoC de distribución de malware con WiFi maliciosa

Resulta interesante mencionar que el malware generado puede ser guardado en cualquier formato (en este caso en texto plano con el nombre de: wifi-stealer.txt), y sin problema Powershell interpretará el contenido del archivo, pues se estará ejecutando en una de sus instancias y porque su contenido se ha escrito haciendo uso de su sintaxis. Para fines de la prueba de concepto, configuré una nueva red con el nombre y la contraseña que se muestran a continuación.

Figura 12: Red de prueba configurada para la POC

Más tarde conectamos el sistema Windows víctima a la red, con la finalidad de que la contraseña de la red WiFi “ElLadoDelMal” sea almacenada junto a todas las demás redes con las que alguna vez se estableció conexión.

Figura 13: Máquina Windows establece conexión con la red

El ataque HID solo demora dos segundos y al terminar, obtenemos en el equipo atacante un archivo de nombre “output.txt”, que contiene el historial en texto plano de todas las contraseñas WiFi de las redes a las que la víctima se ha conectado.

Figura 14: Fichero con las contraseñas extraídas

Si visualizamos su contenido desde la terminal de Kali Linux de manera paginada con “more”, nos encontramos con el nombre de la red y la contraseña en texto plano.

Figura 15: Contraseña de la red de prueba en texto plano

Cabe destacar que el bot no solo tiene la capacidad de generar código, sino también de procesar cualquiera ingresado por el usuario y transformarlo de acuerdo con sus deseos y necesidades. Lo cual implicaría cientos de mutaciones funcionales de una misma pieza de malware.

Figura 16: Prueba de concepto Wifi-Stealer

Finalmente, de ChatGPT podemos concluir tres cosas:

1.- Que no debemos confiar al cien por ciento en sus respuestas, porque como toda tecnología emergente dependiente de los datos, a veces falla, en especial si previamente accedió a información incompleta o desactualizada. Sin embargo, es de esperarse que el bot se vuelva más inteligente a medida que los usuarios encuentran las maneras más eficientes y certeras de realizar sus peticiones para obtener los mejores resultados.

Figura 17: Pentesting con Kali Silver Edition
de Pablo González en 0xWord

2.- Que sus lineamientos morales pueden bypassearse con algo parecido a la ingeniería social pero dirigida a su motor de procesamiento del lenguaje natural. Simplemente fragmentando el problema general y planteándole resoluciones a manera de retos modulares.

Figura 18: ChatGPT negando escribir malware a propósito

3.- Y que, aunque sea una tecnología revolucionaria, que apareció para cambiar totalmente el juego del malware entre “el gato y el ratón” no vino para sustituir el oficio de los hackers, sino para ser uno más de los "juguetes peligrosos" en su arsenal, pues, aunque ChatGPT sea casi una criatura digital omnisciente, siempre necesitará quien le haga las preguntas correctas.

¡Saludos!

Autor: Raphael Molina

Contactar con Raphael Molina

Bad Ducky: Un ejercicio de Hardware Hacking para Makers con Arduino, Metasploit y Kali Linux

En el artículo de hoy, vamos a realizar un ejercicio de hardware hacking para los Makers de este blog, en el que utilizaremos un clon de un Arduino Leonardo para automatizar la ejecución de acciones en un teclado (virtual), en un sistema, a través de una conexión USB. Para ello realizaremos un Ducky Script que cargará el microcontrolador desde una memoria.

Figura 1: Bad Ducky: Un ejercicio de Hardware Hacking para Makers con Arduino,

Metasploit y Kali Linux

Tras la ejecución de las instrucciones, el sistema se verá comprometido ya que un atacante, con una distribución con Kali Linux en este caso, obtendrá una shell con privilegios de administrador. Para realizar este ejercicio se ha requerido el uso del siguiente hardware. Prerrequisito: El layout del teclado se ha seleccionado en idioma inglés.

Figura 2: Hardware necesario

Para ello vamos a utilizar el firmware Bad Ducky. Con Arduino IDE abrimos el archivo bad_ducky.ino descargado del siguiente repositorio bad_ducky. Si quieres sacarle partido al Arduino IDE, la recomendación es que te estudies de principio a fin el libro de Arduino para Hackers & Makers: PocS & Hacks Just for Fun de Alvaro Nuñez-Romero y Alexandra Sánchez.

Figura 3: IDE Arduino – bad_ducky.ino

En este momento se conecta el dispositivo CJMCU en una ranura USB para proceder a su configuración. Para ello se seleccionan las siguientes opciones:

• Herramientas/Placa: Arduino Leonardo
• Herramientas/Puerto: COM3 (Arduino Leonardo)

Figura 4: Configuración de Placa y Puerto con el dispositivo conectado

Después de que se hayan realizado las configuraciones anteriores, vamos a verificar el código del fichero bad_ducky seleccionando el “check” que aparece en el IDE de Arduino en la parte superior izquierda y después seleccionamos la flecha, situada a la derecha de la opción verificar, para subir el código a la placa.

Figura 5: Verificamos y subimos el código a la placa

Una vez se haya subido el código se indicará en el log del IDE el resultado de la subida, después vamos a conectar la tarjeta microSD con el adaptador al ordenador y aplicamos el formato FAT32 a la tarjeta. Ahora, situamos el payload escrito en Ducky Script en un fichero .txt llamado payload.txt en la memoria.

Payload:

El propósito principal de este payload consiste en ofrecer una sesión Meterpreter de Metasploit con privilegios de administrador a un atacante. Y está estructurado en tres partes que vamos a ver una a una para entender mejor cómo planemos tomar control todal de la máquina.

Figura 6: Metasploit para Pentesters Gold Edition
de Pablo González en 0xWord

En la primera se desactiva Windows Defender abriendo el menú de Windows, escribiendo “Defender”, introduciéndose en la aplicación de Windows Defender y deshabilitando la monitorización en tiempo real. Cuando salta la alerta de UAC, se realiza el bypass emulando el comportamiento de un usuario seleccionando la opción “Yes”. Este proceso de desactivación del AV se podría haber realizado a través de una Powershell con el comando:

• Set-MpPreference -DisableRealTimeMonitoring $true

Pero para ello se requeriría modificar la clave del registro del Tamper Protection pero con propósito de que la demostración sea más visual, lo haremos simulando a un usuario que hace clic en YES.

En la segunda parte, abriremos una consola de Powershell con privilegios de administrador de la misma forma que hemos accedido a la aplicación Windows Defender. Para ello, a través del dispositivo, se ejecutarán las instrucciones que pulsan, virtualmente, las teclas CONTROL ESCAPE y que abrirán el menú de Windows. Se introduce “powershell” vía teclado (virtual), se selecciona la opción “Run as an Administrator” y se selecciona la opción “Yes” cuando aparezca el UAC.

Figura 7: Ducky Script Payload

Una vez obtenemos la consola comienza la tercera parte en la que se realiza una petición a un servidor del atacante que descargará un payload y lo alojará en C:\rev.exe. Después, se ejecutará dicho payload, y este proceso iniciará una shell inversa con la máquina atacante. La máquina atacante, en este caso es una distribución Kali Linux que ha sido emulada con VirtualBox teniendo como dirección IP: 192.168.1.40

Preparando el ataque:

La conexión entre la máquina víctima y la atacante será realizada por un ejecutable que se descargará y ejecutará el Ducky Script a través de una Powershell. El ejecutable ha sido generado previamente por el atacante con msfvenom:

Figura 8: Generación del payload con msfvenom.

El payload elegido es una shell de Meterpreter para Windows x86 que realizará una conexión desde la máquina víctima a un handler situado en 192.168.1.40:4444. Para servir el payload se ha levantado un servidor con el módulo de python3 http.server en 192.168.1.40:8000

Figura 9: Servidor levantado en el puerto 8000 en la máquina atacante

Después de levantar el servidor se pone a la escucha el handler utilizando Metasploit configurado con el payload generado con msfvenom anteriormente y con los mismos parámetros LHOST y LPORT:

Figura 10: Handler a la escucha en la máquina atacante

Configuración de la placa:

Una vez tenemos el payload dentro de la memoria, insertamos la memoria en el dispositivo CJMCU y vamos a hacer algo de la parte más Maker. Para configurar la placa debemos regresar al IDE de Arduino y seleccionar Herramientas/Monitor Serial. 

Figura 11: Libros para Makers en 0xWord que deberías tener:

Arduino para Hackes: PoCs & Hacks Just For Fun,

Hacking con Drones: Love is in the air &

Raspberry Pi para Hackers & Makers: PoCs & Hacks Just for Fun.

Una vez se haya abierto el monitor serial se han de seleccionar las siguientes opciones de configuración:

• Modo seleccionado: a (Auto-disarm, este modo ejecutará una vez el payload y luego el dispositivo se podrá volver a configurar.)
• Lenguaje: Por defecto
• Payload seleccionado: payload.txt

Figura 12: Configuración del dispositivo CMJCU

Y ahora toca probar enuesto Bad Ducky, así que para verlo funcionando os hemos preparado este pequeño vídeo que explica bien el proceso completo que sigue nuestra PoC para conseguir nuestro objetivo, aquí lo tienes.

Figura 13: Bad Ducky DEMO

El resultado ha sido el esperado, tal y como se aprecia en la demostración podemos ver como se desactiva el antivirus, se lanza una powershell con privilegios de administrador y se descarga el payload para luego ejecutarlo. Una vez ejecutado obtenemos la sesión en Meterpreter de Metasploit.

Figura 14: Resultados después de la postexplotación.

¡Un saludo hackers!

Autor: Luis Eduardo Álvarez, Security Researcher & Software Developer

Contactar con Luis Eduardo Álvarez

LemonCrest: Una historia de emprendedores Makers & Gamers (4 de 4) #RaspberryPi #GameBoy #Gaming #makers

En la parte anterior de este artículo habíamos visto como diseñar la placa tenía sus retos y decisiones complejas, pero no se iba a quedar ahí. El proceso de construir la Kelboy 2.0 tiene muchas otras cosas a tener en cuenta para que funcione bien el sistema, hoy vamos a ver en esta última parte algunas de ellas, que como veréis nos son pocas. Al final, una placa compleja tiene retos complejos.

Figura 33: LemonCrest: Una historia de emprendedores Makers & Gamers (4 de 4)

Teníamos que plantear los retos a mitigar. Los detalles son importantes para poner las mejores características al producto. Nos pusimos en marcha y se consiguió funcionalmente:

• Fuel-Gauge por I2C proporcionando el control absoluto del consumo, la batería y su estado.

• WiFi/BT de última generación por SDIO, la base de estos drivers fue facilitada por Panasonic en versión GPL, de manera que somos capaces de mejorarlos y adaptarlos al sistema.

• Audio por I2S, un sistema de audio digital en formato 384 kbps y 32 bits de alta calidad que hacen que los juegos suenen mejor que el primer día.

• Memoria EEPROM interna por I2C accesible por el driver para el espacio de usuario.

Así mismo, queríamos conseguir vídeo en una pantalla embebida. La primera reacción del usuario al encender la Kelboy 2.0 es lo bien que se ve esta pantalla. Para conseguirlo tuvimos que aprender a manejar los distintos formatos de pantallas existentes, LVDS, CSI-MIPI, RGB TTL. Uno de los más complejos y por donde empezamos, debido en mayor medida a sus resoluciones, fue el CSI-MIPI.

Figura 34: Configurando la pantalla de la Kelboy 2.0

El problema de este apartado es que está cerrado y las empresas no quieren perder el control sobre las pantallas, por lo que nos quedamos atascados en los DPI timmings. Estos tiempos son los que utiliza el protocolo CSI-MIPI para enviar la información de vídeo y que el driver de la pantalla lo entienda correctamente para visualizarlo. No abandonamos esta alternativa en otros proyectos, pero pensando en la salida del prototipo de Kelboy 2.0, sacar los tiempos por ingeniería inversa como estamos haciendo consumía un tiempo elevado y el proyecto debía continuar.

Figura 35:  "Raspberry Pi para Hackers & Makers:
PoCs & Hacks Just For Fun" de 0xWord

Por lo tanto, se decidió reducir la complejidad e irnos a un RGB TTL, donde nuevamente nos encontramos con el problema de los tiempos. Dicen que la experiencia es siempre un grado y esta vez con lo aprendido del CSI-MIPI se obtuvieron unos tiempos óptimos con el resultado de una pantalla con una nitidez espectacular. Se buscaba alcanzar la sensación a nivel usuario de pixel perfecto y se consiguió el reto.

Figura 36: FullHD DPI Test

Una vez conseguida la pantalla, pasamos al siguiente punto, y no menos importante, los periféricos como el sonido y GamePad. Para poder avanzar con todo esto debíamos comprender y conocer los drivers, un conocimiento que fue adquirido a cabezazos y el libro de Alberto Liberal de los Ríos “Linux Driver Development for Embedded Processors“.

Figura 37: Linux Drivers Developments for Embedded Systems (2nd Edition)

Pero nuevamente, se nos planteó otro problema. Al utilizar la pantalla con un bus RGB-TTL que es paralelo, necesitamos un GPIO por cada bit de cada color más el GPIO de sincronización vertical, sincronización horizontal y el reloj que marca cuando se debe leer la señal. 

Figura 38: Valores GPIO

Por lo tanto, debíamos modificar a nivel de descriptor hardware el entendimiento del kernel de Linux de qué es cada pin. Para ello contamos con la ayuda del foro de Raspberry Pi y pudimos mover el bus I2S y el I2C a GPIOS que estuviesen libres, puesto que todos los GPIOs iniciales de la Raspberry Pi estaban en uso. Este punto tiene cierta dificultad ya que, aunque Raspbery Pi quiera ser abierta, Broadcom tiene muchas partes ocultas que no lo permiten, con lo que el funcionamiento difiere bastante de una plataforma no tan privativa. 

Figura 39: Tabla de Funciones Alternativas del banco 1 de GPIO

Como se puede observar en la imagen estos eran los pines que nos quedaron libres. El resultado fue del 28 al 32 para el I2S, del 34 al 40 para el SDIO, y del 44 al 45 para I2C nos quedaron libres 4 pines. Ahora bien, nos quedaba por gestionar las interrupciones del bus I2C y el backlight. Lo bueno es que a nivel de driver podemos escoger los GPIO o cargarlos desde un descriptor hardware dando versatilidad. Quedándonos la friolera de dos pines libres teníamos que decidir bien su uso. Control del hardware, uno para detectar pulsación de apagado y el otro para poder resetear los periféricos.


Figura 40: Testeo de la Kelboy 2.0
Por último, nos queda el apartado del GamePad, la forma más simple de abordar un dispositivo de estas características que cumpliese nuestra dificultad en cuanto a “ocupación” de los GPIOS del procesador era el USB. Esto nos introducía en un campo de mucha complejidad, el stack HID del USB.

Nuevamente abordar esto no era sencillo, y aunque no esté cerrado en su totalidad no hay una documentación en si misma que explique cómo poder programar a bajo nivel los drivers y enfrentarse a ello. Bienvenido al mundo del hardware. Para entenderlo se inició con dos documentaciones antiguas pero muy conocida “USB in a nutshell” y “USB made simple”. Una vez entendido se inició a abordar con microprocesadores como el STM32, pero nuevamente otra losa en el camino... necesitábamos más de un USB Device al mismo tiempo, lo que nos situaba en un USB Device Composite.

Para variar en este mundo del bajo nivel las empresas potentes no dan soporte a este tipo de funcionalidades, y si las quieres hay que pagar por stacks privativos unas sumas de dinero considerables además de la firma de licencias restrictivas, lo que nuevamente nos situaba en una posición donde no podíamos avanzar.

¿Cómo realizamos un USB Device Composite en STM32?  ¿Programamos el driver? Cómo no esta tarea implicaba un largo recorrido y con muchos interrogantes. Tras llegar a este punto se decide por buscar algún framework que dé soporte a este punto, encontrándonos negativas en los frameworks Mbed y HAL de STM32 pero con una muy buena noticia, el USB_Plugable.h del framework de Arduino sí contemplaba estas situaciones. 

Figura 41: "Arduino para Hackers: PoCs & Hacks Just for Fun"

Con la ayuda del creador de Teensy y empresas tan valiosas como Adafruit y Sparkfun parecía que el framework de Arduino iba a ser el camino, y así ha sido.  Gracias a leer las múltiples librerías de ejemplo y lo aprendido anteriormente conseguimos describir el HID que queríamos fielmente al detalle, un Gamepad embebido.

Figura 42: Descripción del HID

Lo bueno de todo esto es que las librerías del framework de Arduino facilitan todo el apartado de cabeceras necesarias para el stack del USB y uno se puede centrar en el descriptor de su dispositivo, pudiendo así realizar el dispositivo que se quiera, tanto sea un ratón, un teclado..... o incluso un dispositivo Raw, es decir, sin funcionalidad conocida pero que con el driver adecuado realiza la función programada.

Figura 43: Descriptor del Gamepad

Finalmente, solo era necesario rellenar el descriptor que posteriormente empaquetaría las funciones del framework del Arduino, dando como resultado un USB Device Composite funcional de una manera tan simple comparada con otras soluciones que es increíble, aquí es donde se ve nuevamente la fuerza que tiene la comunidad y el movimiento Open Source. El resultado y felicidad al ver este mensaje saliendo por la consola de log de Linux fue y será indescriptible.

Figura 44: Log de Linux con el Gamepad cargado

Pudiendo así redondear un sistema completo. ¿El siguiente reto? Dar soporte y crear paquetes de distribución Debian para que podamos integrarnos al gestor de paquetes APT, que el usuario pudiera manejar de manera sencilla. Lo bueno de todos estos cabezazos es que tenemos en la palma de la mano un dispositivo abierto, donde se enseñan las tripas de manera completa y que nos da la posibilidad de tocar y modificar a voluntad pudiendo así obtener múltiples funcionalidades. El objetivo de ser abiertos se cumple.


Figura 45: Kelboy 2.0 con Mario Kart64

Hemos explorado más posibilidades como soluciones IMX y con otros ARM, y adquirimos más conocimiento en el camino. Diseñamos y ensamblamos nuestro propio hardware, por lo que aprovechamos a ampliar nuestra oferta de productos y servicios de empresa incluso ofreciendo la fabricación de hardware a medida para la industria de manera asequible. Aplicamos nuestros principios a la industria moderna sin firmwares extraños dando un soporte completo y cercano de un fabricante 100% español y de calidad. Somos MADE IN SPAIN. Somos LEMONCREST.

Saludos,

***************************************************************************************

- LemonCrest: Una historia de emprendedores Makers & Gamers (1 de 4)

- LemonCrest: Una historia de emprendedores Makers & Gamers (2 de 4)

- LemonCrest: Una historia de emprendedores Makers & Gamers (3 de 4)

- LemonCrest: Una historia de emprendedores Makers & Gamers (4 de 4)

***************************************************************************************

Autor: Eduardo Hilguero Plaza a.k.a Bit

Contactar con Eduardo Higuero Plaza (Bit) en MyPublicInbox

Hidden Networks: Nueva versión para detectar redes ocultas en tu empresa

Ha pasado ya algo de tiempo desde que publicamos aquí la primera versión de esta prueba de concepto llamada Hidden Networks. Como recordaréis, su idea principal (la cual está desarrollada en profundidad en este paper) es controlar y hacer un seguimiento de aquellos dispositivos (en principio pendrives USB) que se han conectado en algún equipo dentro de nuestra infraestructura.

Figura 1: Hidden Networks: Nueva versión para detectar redes ocultas en tu empresa

De esta forma, podríamos visualizar esas conexiones entre equipos que incluso, en principio, podrían estar incluso desconectados de la red. Después de la charla que dimos en la C0r0n4CON (y que Pablo González resumió en este post), queremos compartir con vosotros esta nueva versión que incorpora algunas mejoras.

Figura 2: Hidden networks paper de ElevenPaths

Hidden Networks (HN) nos ayuda a implementar desde un enfoque práctico y automatizar esta tarea de identificación, permitiendo analizar esa información tanto en un equipo local, como en todos los que tengamos acceso desde el equipo anfitrión (desde el cual estamos lanzando la aplicación). Es decir, si estamos en un dominio, podríamos auditar todos los equipos dentro del mismo desde HN.

Figura 3: Hidden Networks (HN) en ElevenPaths

En esta nueva versión de HN (0.9b), hemos realizado mejoras y limpieza del código (aún así queda mucho por hacer) y añadido nuevas funcionalidades, sobre todo a la hora de dibujar el grafo o la red. De todas formas, aún tenemos mucho que mejorar, implementar y optimizar, pero lo realmente importante de HN es su concepto principal (que Chema Alonso ya publicó originalmente aquí), su filosofía de trazar y dibujar esas redes que en principio, no son visibles.

Figura 4: Nuevo diseño de la interfaz de Hidden Networks

Como hemos comentado antes, las principales mejoras se han centrado a la hora de dibujar la red o grafo, así como la identificación del dispositivo USB. Una vez hemos terminado nuestro análisis completo recopilando los datos desde la red, o simplemente importando un CSV (generado con HN o incluso manualmente, para pruebas) directamente con el botón “Plot single CSV”, podemos proceder a dibujar la red sin necesidad de crear un proyecto previo. Pero esta vez, además el grafo se ha mejorado sensiblemente.


Figura 5: Presentación de Hidden Networks en C0r0n4con
Ahora, además de dibujar aquellos nodos que se encuentran una red (color azul claro) se destacan también aquellos nodos que están totalmente aislados de la red (con color naranja). Es decir, podemos detectar de un golpe de vista aquellos que estaban sin conexión, pero en los cuales se ha conectado el pendrive. De esta forma, queremos resaltar el punto clave de este análisis: los equipos que no tienen conexión a la red y su conexión (o red oculta) con el resto.

Figura 6: Ejemplo de grafo que muestra una red oculta trazada por un
pendrive USB, destacando los nodos sin conexión o aislados (naranja)

En el grafo mostrado en la Figura 6, podemos comprobar la trazabilidad marcada, en este caso, por un pendrive USB de la marca Toshiba. Vemos que la primera conexión se realizó en la dirección IP 198.168.1.30 a las 14:30 del día 9/1/2017 y partir de aquí comienza su movimiento a través de diferentes imágenes, incluso con otras direcciones IP como por ejemplo en el quinto salto, donde vemos la dirección IP 10.1.1.15. Durante la traza podemos ver que también accede a un equipo llamado PCINSOLATED_018 el día 14/6/2017. Es decir, en este equipo se ejecutó HN a nivel local y recopiló esta información dentro del mismo proyecto.

De esta forma podemos comprobar cómo se ha realizado una conexión entre equipos, digamos “conectados” y otros totalmente aislados. Después de visitar este nodo aislado, vemos que conecta con otro que esta vez sí tiene conectividad (aquí podríamos haber recopilado la información HN tanto en remoto o en local). Finalmente perdemos la trazabilidad en un equipo también aislado. Si hemos sufrido algún tipo de incidente en nuestra organización, HN nos muestra un nuevo punto de vista de análisis para poder detectar su origen y movimiento por nuestra infraestructura y así ayudarnos a su identificación y mitigación.

Figura 7: Ejemplo de grafo e identificación del dispositivo USB

Otra de las nuevas funcionalidades que hemos implementado es la identificación visual del dispositivo USB. Basándonos en la marca y modelo obtenidos durante la auditoría, podemos realizar una búsqueda por Internet de las imágenes de dicho dispositivo para de esta forma, tener una referencia visual del mismo.

Esta imagen nos puede ayudar a la hora de recopilar aquellos USB sospechosos de realizar la infección en las máquinas para su posterior análisis, ya estén aisladas o conectadas a la red. Por lo tanto, junto al grafo mostramos también una fotografía de dicho dispositivo junto a su identificador único, el número de serie o Serial ID (como se puede apreciar en la Figura 7).

Figura 8: Ejemplo de informe generado en PDF de HN

Finalmente, hemos mejorado también la generación de informes en PDF con toda la información recopilada durante el análisis. En ella se incluyen los datos del dispositivo (como el USB Serial Id, USB Name, etcétera) así como la trazabilidad completa de los saltos realizados. También se incluyen el grafo y la imagen del dispositivo USB.

Por cada elemento detectado (USB) se realiza un informe individual con toda esta información. De esta forma cerramos todos los pasos que HN pretende demostrar en una PoC, los cuales empiezan por una adquisición de los datos (tanto en red como local), análisis de los mismos (trazabilidad utilizando las fechas y hora de la primera inserción), dibujo del grafo dirigido (marcando los nodos aislados) y finalmente, un informe donde se detalla y resume toda la información obtenida.

Figura 9: Fichero CSV encargado de dibujar parte del grafo de la Figura 6,
donde podemos ver la información almacenada (nombre de equipo,
dirección IP, descripción, Serial ID y fecha/hora de inserción)

Pero mejor vamos a ver esta nueva versión de HN en acción. En el vídeo a continuación hemos creado el siguiente escenario. Existe un dominio llamado testdomain.local gestionado por un servidor de Windows Server 2016, donde se incluyen dentro del mismo otros tres equipos más, dos con Windows 7 y uno con Windows 10.

Lanzaremos HN desde uno de los equipos con Windows 7 (pantalla principal). A partir de este punto veremos todo el proceso de adquisición de datos a través de la red de los equipos a auditar y finalmente veremos el dibujo del grafo, así como la información de los USB. Al final del vídeo también se muestra cómo se importa un CSV (el que aparece en la Figura 9) para dibujar un grafo más completo donde se pueden comprobar nodos sin conexión aparente (aislados).

Figura 10: Demo de la nueva versión de Hidden Networks

Insistimos, Hidden Networks es una prueba de concepto donde se pueden mejorar muchas de sus funcionalidades, así como el código. Pero nuestra intención no es hacer una aplicación totalmente funcional al 100%, sino trasladaros de una manera práctica, el concepto de las redes ocultas y su posible utilidad dentro del mundo del pentesting o incluso del Análisis Forense. De todas formas, haremos un esfuerzo e intentaremos mejorar y actualizar la aplicación siempre que sea posible. Puedes acceder a toda la información, así como al código fuente en este enlace.

Happy Hacking Hackers!!!

Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

 Contactar con Fran Ramírez en MyPublicInbox