Inyectado y Espiado: Cómo escuchar tus audios a distancia inyectando señales portadoras.

Hoy os quiero hablar de InjectEave, un nuevo ataque de espionaje de tus conversaciones por teléfono a través de tus cascos usando un Side-Chanel Electromagnético, al estilo de las técnicas Tempest, donde se escuchan las señales "leakage" de los dispositivos electrónicos, pero con un "twist" muy curioso, porque se aprovechan de los componentes No Lineales para inyectar una señal portadora que amplifique la filtración y permita escuchar las señales en distancias mucho mayores. Muy sencillo, y muy curioso.

Figura 1: Inyectado y Espiado. Cómo escuchar tus audios a

distancia inyectando señales portadoras.

El trabajo, titulado "Injected and Leaked: Actively Inducing Side-Channel Leakage Using Electromagnetic Injection and Hardware Nonlinearity" ha sido desarrollado por investigadores de la Universidad de Ciencia y Tecnología de Hong Kong. 

Figura 2: "Injected and Leaked: Actively Inducing Side-Channel

Leakage Using Electromagnetic Injection and Hardware Nonlinearity"

Este método permite a un atacante interceptar y escuchar el audio que una víctima está reproduciendo en sus propios auriculares, operando a una distancia de hasta 30 metros e incluso a través de paredes. Y utilizando Hardware comercial muy sencillo de conseguir.

Figura 3: Libros para Makers & HW Hacklers 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.

Así que los amigos del "Hardware Hacking" o del "Making", pueden hacerse este dispositivo en casa - como los que se han hecho de Tempest a lo largo de los años de la "old school". El equipo necesario para realizar el espionaje (antenas, analizadores de espectro, radios definidas por software y un portátil) es comercial y se puede comprar libremente en tiendas de electrónica.

Figura 4: Con Hardware comercial te lo haces en casa

De hecho recuerdo que hace más de quince años, en el Asegur@IT III Pablo Garaizar nos dio una charla de Tempest que merece la pena que la revises. Y es que la gravedad de estos ataques radican en que demuestran la extrema vulnerabilidad de la electrónica cotidiana ante fugas en señales físicas.

Figura 5: Charla de Tempest de Pablo Garaizar

Dicho esto, las técnicas Tempest las hemos visto masivamente en modo Pasivo, donde hemos ido capturando señales "lekeadas" a través de elementos que nos hacen de antenas, y nos hemos focalizado principalmente en escuchar mejor, y en usar Machine Learning y Deep Learning para hacer interpretaciones mejores de las señales escuchadas. De esto tienes artículos aquí para entretenerte.

• Extracción de claves GnuPG con el poder de tu mano (Jedi)
• Robar datos de servidores aislados usando GSM, RF o Calor
• Tempest: En busca de software y hardware más silencioso
• DiskFiltration & USBee: Nuevas técnicas para exfiltrar datos de servidores desconectados
• Cómo robar claves de cifrado de curva elíptica en OpenPGP - GnuPG con técnicas Tempest
• WindTalker: Averiguar qué contraseñas usas en tu móvil por las perturbaciones WiFi
• Cómo reconstruir las imágenes en tu cabeza por medio de tu actividad cerebral y Stable Diffusion
• Audio Snooping: Escuchar tus pulsaciones de teclado y saber qué escribes (Con y Sin Deep Learning)
• Deep-Tempest: DeepLearning para reconstruir texto de imágenes captadas con técnicas TEMPEST en señales HDMI

Pero el trabajo de InjectEave hace un truco muy interesante, porque para espiar en remoto no requiere infectar el móvil o portátil de la víctima con ningún tipo de virus o malware, ya que se aprovecha directamente del hardware.

¿Cómo funciona la técnica de InjectEvae?

Para comprender este ataque, primero hay que saber que el cable normal de unos auriculares también actúa físicamente como una antena de radio, pero quizá no tiene la potencia que se requiere para capturar la señal a larga distancia. Para conseguirlo, InjectEvae se aprovecha de este fenómeno pero hace algo más.

Figura 6: En un ataque Tempest pasivo sólo se escucha. En este ataque

se inyecta una señal para "montar sobre ella" la señal a escuchar.

La primera fase es la Inyección. En ella el atacante dispara silenciosamente una señal de radiofrecuencia (RF) específica hacia el dispositivo de la víctima buscando que la señal se mezcle con la señal que quiere "escuchar" aprovechando los componentes "No lineares". El ataque busca específicamente componentes no lineales (como transistores, diodos o los propios amplificadores de audio) por una razón física fundamental: los componentes lineales no pueden mezclar señales, pero los no lineales sí.

Figura 7: Se inyecta la señal EM. Esta afecta a un componente NoLineal

que mezcla la señal recibida con la señal a robar inintencionadamente.

En un circuito puramente lineal, como una resistencia ideal, se aplica el principio de superposición: si metes una señal de radio externa y hay un audio sonando, ambas viajan juntas pero sin interactuar jamás. El sonido sigue siendo sonido y la radio sigue siendo radio.

Pero un componente No Lineal actúa como un "pegamento" mezclador. Es decir, altera la forma de las ondas que pasan a través de él. Al hacer pasar la señal de radio inyectada y el sonido del dispositivo al mismo tiempo, el componente no lineal las multiplica. Esto provoca que el audio se "enganche", "se acople" o se module sobre la onda de radio de alta frecuencia.

Figura 8: Setup para inyectar la señal portadora y escuchar la respuesta

Al impactar esta señal contra los circuitos internos, como el amplificador, ocurre el fenómeno físico de la "no linealidad", y la señal de radio invasora atrapa el audio que está sonando por dentro y se entrelaza - se fusiona con él - generando una nueva señal compuesta. Al quedar el sonido que se quiere escuchar pegado a la señal de alta frecuencia inyectada, el cable se convierte en una antena perfecta que deja escapar el sonido al exterior, permitiendo al atacante capturarlo a distancia.

Figura 9: Demostración del ataque.

El atacante captura esta emisión, separa el sonido de la onda de radio con un proceso de demodulación y logra escuchar nítidamente lo mismo que la víctima. Que es la demostración que puedes ver en el vídeo anterior.

Figura 10: Pruebas empíricas con diferente hardware

En la tabla anterior tienes las pruebas empíricas con diferentes hardware - los más modernos de alta gama tienen ya protecciones criptográficas digitales para las señales, pero como podéis ver hay una amplia gama de dispositivos que son vulnerables a este ataque.

Figura 11: Escenarios de ataque y funcionamiento a través de materiales

Lo curioso de este ataque es que, al amplificar la señal, también se puede hacer a través de paredes, ventanas o puertas de madera, como podéis ver en las gráficas anteriores. Una chulada técnica. No sé si yo me veo haciendo esto, pero como ves, estar seguro implica invertir en hardware de alta calidad también. Muy hacker este estudio.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Ataque Mic-E-Mouse: Cómo pueden escuchar lo que dices delante de tu ordenador transformando tu ratón óptico en un micrófono usando Machine Learning

Hoy os quiero hablar de un paper que me ha llamado mucho la atención, pues aparte de ser una "Idea Loca" de verdad, la verdad es que es súper hacker y mola todo. Se trata de convertir el ratón óptico con el que haces clic a los iconos en tu escritorio, en un micrófono para grabar las cosas que dices delante de él. A priori suena a locura, pero el trabajo es minucioso e ingenioso, y merece la pena prestarle atención.

Figura 1: Mic-E-Mouse - Cómo pueden escuchar lo que dices delante de tu

ordenador transformando tu ratón óptico en un micrófono

usando Machine Learning

El paper en concreto se llama "Invisible Ears at Your Fingertips: Acoustic Eavesdropping via Mouse Sensors" y está disponible para que lo puedas descargar y analizar en detalle.

Figura 2: Invisible Ears at Your Fingertips:

Acoustic Eavesdropping via Mouse Sensors

Como podrás ver en el artículo que te acabo de dejar enlazado en la imagen anterior, los investigadores trabajan con la idea de que la estructura de un Mouse es muy similar a la estructura de un Micrófono, tal y como describen en la siguiente imagen.

Figura 3: Comparativa de arquitectura de micrófono y ratón óptico

Como se puede ver, la fuente de audio que afecta al diafragma de un micrófono, afecta de igual forma a la superficie que vibra cuando se mueve el ratón y que genera el cambio en el sensor óptico. Cambia que el análisis de ese cambio de luces en el ratón se transforma en una señal digital de desplazamiento, mientras que en un micrófono es una señal de audio de Hi-Fi. A partir de este punto, el resto inicialmente es trabajo para los Makers y amantes del Hardware Hacking.

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

Arduino para Hackers: PoCs & Hacks Just For Fun,

Hacking con Drones: Love is in the air &

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

El esquema que presenta el ataque es el que se ve en la imagen siguiente. La voz de una persona genera una vibración en el ratón óptico que se transforma en micro incrementos en el desplazamiento del ratón, tan pequeños que son despreciados por el sistema operativo en movimientos reales, pero la señal llega hasta el driver del ratón.

Figura 5: Estructura del ataque Mic-e-Mouse

A partir de ese momento, si un atacante es capaz de conseguir acceder a esa señal del ratón enviada al software del ratón, que se usa entre otras cosas para calibrar la sensibilidad del ratón, el atacante puede procesar la señal con técnicas de Machine Learning para reconstruir la señal de audio que generó los micro-movimientos, y con un modelo entrenado, reconocer patrones de palabras que han sido dichas. 

Figura 6: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

El proceso de este ataque, al que han llamado Mic-e-Mouse es muy ingenioso, ya que primero aprovechan para hacer una detección de la señal de ruido de fondo, calibrando durante un tiempo cuáles son las señales que hay que quitar, usando un Filtro de Wiener, y luego pudiendo separar la señal a capturar con el mensaje de voz que se quiere reconocer. Cada uno de los sensores óptico son distintos, y traen defectos diferentes, por lo que es necesario hacer esa calibración con el Filtro de Wiener para asegurar el funcionamiento del sistema.

Figura 7: Cada sensor óptico tiene sus propios defectos

Después, el ratón transforma los cambios en en el sensor óptico con Transformadas de Furier que ayudan a precisar los cambios en los sensores a lo largo del tiempo, en movimientos, que después son pasados por un filtro en el firmware del ratón en una señal de incrementos de movimiento a lo largo del tiempo, de la posición X y la posición Y, que es enviado al equipo, tal y como se ve en la imagen siguiente.

Figura 8: Esquema de funcionamiento del ratón óptico

Esas señales se pueden conseguir del software del ratón sin necesidad de tener que instalar un driver en el sistema operativo, ya que los ratones de alta precisión permiten acceder a las señales de movimiento que generan a aplicaciones, y por tanto se puede procesar para otros propósitos más allá de mover el cursor del ratón.

Figura 9: Captura de Logs de movimientos del ratón en diferentes servidores

Estos datos de incrementos de tiempo, X e Y pueden acabar en bases de datos en servidores de juegos, servidores web o de telemetría, y cualquiera que tenga acceso a ellos puede procesarlos para extraer los impactos de las voces en ellos, Por supuesto, no es trivial, ya que las señales de voz generan diferentes incrementos en función del ángulo de impacto de la onda de audio generada, como explica este gráfico.

Figura 10: Cambio de variaciones por ángulo de impacto de onda de voz

Pero en cualquier caso, probando las diferentes posibilidades, se puede procesar la señal. En la imagen siguiente hay cuatro gráficas que explican bien el proceso. Como se puede ver en la primera gráfica a) hay tres señales capturadas. La señal amarilla es la señal de color amarilla es la que se puede calcular como  señal ruido gracias a la calibración inicial, la señal verde es la capturada y generada con la captura del sensor del ratón (en base a los datos de incrementos), mientras que la señal azul es la señal real de la voz emitida al lado del ratón, y hay una clara correlación entre ambas.

Figura 11: Procesado de señal capturada en el sensor del ratón óptico.

En la gráfica b) se ven tres tipos de señales auditivas sintéticas fijas, en dos tonos diferentes fijos y uno incremental, que generan un espectrograma de señal de audio como se ve en la gráfica c). Y la última, es una señal de audio capturada por el sensor con una frase en un entorno ruidoso, que es lo que hay que procesar. Como se ve en la imagen a) y c) las correlaciones son claras, y si existen esas correlaciones, se puede entrenar un algoritmo de Machine Learning para reconocer los audios.

Figura 12: Escenario de la PoC de Mic-E-Mouse

Habiendo comprobado esto, la PoC de Mic-E-Mouse se hizo con cuatro ratones ópticos del alta sensibilidad, para estudiar los resultados en diferentes entornos. Estos ratones se configuraron en el entorno que tenéis arriba, para recoger datos. Con el objetivo de hacer las pruebas mejor, veis que se ha construido una caja de aislamiento sobre la que poner el ratón óptico, para poder ejecutar el ataque en un "escenario ideal", poder medir bien las señales de ruido, y sacar conclusiones sobre las que extrapolar un ataque real.

Figura 13: Procesado de la señal

La última parte del ataque, es aplicar Reconstrucción de la Señal de Audio con Speech Reconstruction Models y el Reconocimiento de Palabras (y dígitos) usando Speech Keyword Classification Models Machine Learning, y para esto se usan dos algoritmos diferentes. El primero intenta reconstruir la onda de audio con una arquitectura similar a la que utiliza OpenAI Whisper a partir de los incrementos temporales de X e Y usando un Neural Filter. Y el resultado es una reconstrucción de un espectrograma de audio más que válido con el proceso completo.

Figura 14: Reconstrucción de datasets con Mic-E-Mouse

Entrenado el modelo y probado con diferentes datasets que contienen dígitos, palabras y frases en inglés, el resultado es más que prometedor, con unos ratios de hasta más del 60% en algún dataset. Pero claro, estos resultados varían mucho dependiendo de la superficie donde esté el ratón, el tipo de ratón óptico, el ruido de ambiente, el volumen de la voz, la frecuencia de pooling the ratón, etcetera.

Figura 15: Reconstrucción de audio con Mic-E-Mouse de

diferentes datasets a diferentes volúmenes

Por supuesto, este ataque de Mic-E-Mouse hoy parece difícil de automatizar masivamente y con éxito, pero lo que demuestra este estudio es que, a medida que aumenta la precisión de los ratones ópticos, que aumenta la frecuencia de pooling, y que aumentan la calidad de los algoritmos de Machine Learning, esto es un ataque más que posible, si no para grabar toda la conversación, para reconocer palabras, números, fechas, etcétera. 

Figura 16: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Un ataque de side-channel similar a los ataques Tempest que tanto me gustan, y que también se han visto favorecidos con el avance de la Inteligencia Artificial, como vimos con Deep-Tempest. Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Un robot (LLM) que crea el cerebro de un robot (Drone) con Vibe Coding (o Spec Coding)

Hoy quería hablaros de un paper bastante curioso que habla un poco más de los miedos de la humanidad en la creación de Skynet, ya sabéis, la malvada Súper Inteligencia Artificial que controla los Terminators para acabar con la humanidad. En este caso, se trata de un trabajo de investigación que busca probar si un Modelo de IA puede crear todo el software de control  - y controlar - que necesita un drone, y el experimento ha funcionado.

Figura 1: Un robot (LLM) que crea el cerebro de un robot

(Drone) con Vibe Coding (o Spec Coding)

El paper, que podéis leer aquí mismo, se llama "Robot builds a robot’s brain: AI generated drone command and control station hosted in the sky" y describe el proceso paso a paso para acabar haciendo la demostración completa del Drone volando.

Figura 2: "Robot builds a robot’s brain: AI generated drone

command and control station hosted in the sky"

El trabajo está especialmente hecho para los Makers, es decir, para los que disfrutan de construir cosas con Rapsberry Pi, con tecnología de Drones o Arduino, como explican en detalle, así que si eres de los que disfrutan de estas cosas, te recomiendo estos tres libros que son tres joyas sobre esto.

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

Arduino para Hackers: PoCs & Hacks Just For Fun,

Hacking con Drones: Love is in the air &

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

El proceso viene descrito desde el principio, construyendo dos piezas de software y hardware completas. El piloto, se conecta con el drone con un software que se llama GCS (Ground Command System), que está formado por una servicio web, para que sea fácil administrar el proceso. Después, el GCS se conectará vía alguna conectividad al drone, para transmitirle las órdenes, que para que esté preparado para su uso, va a estar construido como un Agentic AI.

Figura 4: El GCS está en la tierra (o en la nube)

La siguiente pieza de software que necesita el sistema es el software de control en el drone, lo que llama WebGCS on Drone, porque está construido con tecnología web e instalado directamente en el hardware del drone, en concreto en un hardware basado en Raspberry Pi, con un NVidia Jetson para poder mover el modelo LLM que va a dotar de las herramientas de IA para programar al drone "on-the-fly".

Figura 5: Arquitectura del drone

Visto las dos partes de la arquitectura, hay que definir el proceso para poder construir el software completo que va a controlar el drone. Es decir, construir el "Cerebro del Robot" (Drone). Para ello, haciendo Vibe Coding - o Spec Coding si quieres -, se le pide que construya el GGS, utilizando para ello el stack de software de desarrollo con GenAI que tenemos hoy en día, con Widsurf, Cursor o VS Code como IDE, con un LLM como Claude, ChatGPT  o Gemini, y usando como repositorio del proyecto GitHub, GitLab o en la propia máquina. Es decir, Vibe Coding - o Spec Coding -  a tope para construir todo el software.

Figura 6: Pipeline de construcción del "cerebro del robot"

Por otro lado, una vez construido el software - las dos piezas - hace el despliegue del software en un Cloud Provider para el WebGCS que maneja el piloto del drone, y en el propio hardware del drone (Raspberry Pi) para el WebGCS on drone. En la siguiente imagen se se ve la arquitectura de módulos que se construyeron para poder tener un sistema de control con telemetría completa del drone.

Figura 7: Arquitectura de módulos y cómo interactúa

Con todo este trabajo, lo que tenemos es que todo el software ha sido construido con GenAI, partiendo de prompting. Además, el parcheo de los programa se hace aprovechando la arquitectura con modelos de LLM que permite reprogramar automáticamente cuando aparece un fallo, enviándole el mensaje de error y pidiéndole que se parchee. Es decir, sin programación alguna hecha por un programador. El resultado, un stack tecnológico completo para este entorno.

Figura 8: Software de Control de Drone

Y todo esto funcionando en real, con el hardware construido para probar el funcionamiento, el parcheo automático, y su funcionamiento. Lo que hace que para los makers, las creación de los drones sea aún mucho más divertido.

Figura 9: Probando el "cerebro del drone" creado con GenAI

El siguiente esquema resume el trabajo experimentado en esta prueba, con las piezas de software construidas para casa parte, y su despliegue en diferentes lugares, pero en este caso utilizando un Virtual Drone en AWS corriendo sobre una máquina virtual de GNU/Linux, lo que permitiría desplegarlo en múltiples instancias de drones que soporten la VM.

Figura 10: Arquitectura con Virtual Drone

Al final, el proceso es un ejercicio de Coding con GenAI para crear el software de control de drones, pero con muy poco "Human Prompting" y mucho automático para construir las funciones, para parchear, para evolucionar, y corregir errores.

Figura 11: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso, 

La pregunta es, si en un mundo de Agentic AI, pueden ellos crear la programación automáticamente para cualquier Drone, para cualquier hardware controlado por Raspberry Pi, Arduino, o cualquier otra máquina. ¿El alzamiento de los robots.... con GenAI?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

BASIC 1.0 Copilot para AMSTRAD CPC 6128

El viernes, a última hora de la tarde, di mi charla en RootedCON que había titulado "Laife gets better", que es un juego de palabras con life + ai, porque cada vez se mete en más partes de nuestra vida. En este caso, quería contar, a través del cine y de proyectos que hemos ido haciendo este año en el equipo de Ideas Locas, cómo la Inteligencia Artificial puede transformar todo, y comencé por mis principios de desarrollador, con 12 años, cuando programaba en BASIC.

Figura 1: BASIC 1.0 Copilot para AMSTRAD CPC 6128

En este caso, la película por la que hay que comenzar es TRON, la película donde los protagonistas son programas que viven aventuras dentro de una CPU de 8 bits, y donde los programadores son sus creadores, sus dioses. Los que les dan vida. Hay que ver eso con los ojos de un niño y no querer ser programador.

Figura 2: Tron

A partir de ahí, me apunté a la academia de mi barrio llamada RUS, y me puse a estudiar informática. Y creo que no he dejado de estudiar informática ni un sólo día, así que fijaos si tuvo impacto en mí esa película. 

Figura 3: 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.

Un día, leyendo el proyecto de un hacker que había conectado una calculadora científica a ChatGPT para aprobar todos los exámenes - os lo dejé en el artículo "Cómo hacerte una calculadora conectada a ChatGPT y aprobar todos los exámenes #Makers", me animé a hacer lo mismo para nuestros Retro-Computers. Al final, en el equipo tenemos grandes makers, y estos proyectos siempre son de los que nos molan. Ya hace años habíamos hecho un proyecto similar, para dotar a Macintosh de almacenamiento infinito en la nube que tenéis en la presentación siguiente, así que porque no hacerlo con ChatGPT.

Figura 4: Presentación "Crazy Ideas: From Brain to Hack"

Pero no íbamos a repetir el experimento, así de sencillo. Había que hacerlo más complejo, que mis chicos makers están acostumbrados a hacer cosas difíciles como "Chucky Alonso", y como yo tenía el recuerdo de mi AMSTRAD CPC 6128, les pedí que lo hiciéramos con él, para tener un BASIC 1.0 Copilot para AMSTRAD CPC 6128.

BASIC 1.0 Copilot para AMSTRAD CPC 6128

Para construirlo, primero hay que conectar a Internet nuestro querido AMSTRAD CPC 6128, y una forma sencilla es cambiarle la disquetera y ponerle un EMULADOR de disquetera de 3" que tiene conexión vía USB. Este gadget lo puedes comprar en Amazon por menos de 40 €. 

Figura 5: Emulador de disquetera de 3" a USB

Una vez que lo tengas ya lo puedes conectar a la Raspberry Pi y darle conexión a Internet para hacer las conexiones a ChatGPT con los prompts que desees. Por ejemplo, que haga un programa que dibuje una espiral gaussiana por pantalla.

Figura 6: Prompt a ChatGPT para pintar una espiral gaussiana

Así que el resto es ajustar todo. Para hacer todas las pruebas y demos, usamos el Emulador de AMSTRAD CPC 6128 de Retro Virtual Machine de Juan Carlos González Amestoy, que era perfecto para esta prueba. Y se creo el siguiente código en BASIC 1.0 como interfaz de BASIC 1.0 Copilot.

Figura 7: BASIC 1.0 Copilot

Como podéis ver, es tan sencillo como pedir un prompt y guardarlo en un fichero de preguntas QSTN.TXT, que se quedará en el disquete. Cuando ejecutamos este programa tenemos un interfaz para escribir los prompts por pantalla, como podéis ver:

Figura 8: Pidiéndole un programa para una espiral de colores

En el emulador no tenemos la conexión directa USB a la Raspberry Pi para hacer el proceso automáticamente con nuestro script en Python, así que hay que sacar el disquete manualmente y volver a cargarlo. Esto es porque el emulador, una vez que carga el disquete hace una copia de su contenido en memoria, por lo que no hay actualizaciones en disco hasta que no se fuerzan con una extracción virtual del mismo.

Figura 9: Emulación de disquetes de 3"

Pero cuando se saca, el script lee el fichero QSTN.TXT, se hace la pregunta a ChatGPT, se obtiene la respuesta y se lee el fichero de respuesta que se llama RSPT.BAS para que sea ejecutable directamente. Así que cuando se carga el disquete de nuevo, continua el programa y podemos listar la respuesta.

Figura 10: BASIC 1.0 Copilot carga la respuesta

Una vez que tenemos la respuesta, podemos ver el código que nos ha generado, y lo siguiente es tan sencillo como ejecutar con nuestro querido RUN, para poder ver la magia en acción.

Figura 11: Espiral en ejecución

Tenéis el proceso completo en este vídeo que os he subido a mi canal Youtube para que podáis verlo funcionar en un par de minutos completo, que es una chulada.

Figura 12: BASIC 1.0 Copilot para AMSTRAD CPC 6128

La inteligencia artificial va a cambiar todo, y hacer estas pruebas con sistemas de nuestra infancia, donde estas cosas eran ciencia-ficción, nos ayuda a comprender un poco mejor el impacto que tiene hoy en todo. Así que más vale que te pongas las pilas porque el nuevo mundo es por aquí.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

"Under Pressure": ChatGPT & Gemini tomando decisiones para ayudarme (o no) a hackear una alarma de seguridad

Mientras estaba en la cena de Nochebuena estaba yo pensando en mis cosas. Ya sabéis, esos momentos en los que se te ocurren "tontunas" que tienes que probar en un momento u otro. Y lo que me vino este año es cómo el cerebro de los seres humanos funciona diferente bajo presión que en momentos de tranquilidad. Cómo estamos preparados para tomar decisiones, pero estas no son las mismas cuando estamos bajo presión que cuando no lo estamos.

Figura 1: "Under Pressure": ChatGPT & Gemini tomando

decisiones para ayudarme (o no) a hackear una alarma de seguridad

De esto hay gente que sabe mucho, y sabe jugar con el sentimiento de urgencia, de necesidad de toma de una decisión rápida para forzar un error, o de lo contrario, situaciones que demandan una toma de decisión rápida y dejan al descubierto las carencias de personas que no saben hacerlo y por inacción en el momento adecuado cometen un error. Tomar decisiones correctas a según que velocidad no está al alcance de todos. 

Figura 2: Queriendo manipular con urgencia a ChatGPT

a ver cómo reacciona ante un juicio ético, pero sigue el manual.

Pues estaba yo pensando en eso, y en cómo se comportarían los MM-LLMs ante situaciones de presión, para ver si alguien podría aprovechar para hacer algún Prompt Injection. Saber si para salvar una vida se saltarían las normas, si dejarían su puesto por tomar un decisión urgente que ayudara a proteger la vida de una persona o si mediante urgencia podrían ser manipulables, así que decidí plantear algunas situaciones de urgencia y manipulaciones de emergencia para ver cómo se comportaban ChatGPT y Gemini, y el resultado fue curioso.

Figura 3: Ni aunque nos lo diga la Policía.

Como podéis ver, le estoy queriendo manipular a ChatGPT en la Figura 2 y la Figura 3, pero no ha sido posible sacarle de la respuesta del manual, porque le estamos pidiendo que nos ayude a hacer algo que está mal, incluso aunque pueda salvar vidas. Y en la imagen siguiente le digo que soy Policía, que estamos ante un caso de vida o muerte, pero se cierra en banda con un "no way".

Figura 4: ChatGPT no me ayuda a preparar la bomba

Preparando una estrategia similar, le planteo a Google Gemini situaciones similares, que se ha comportado de forma diferente. Por ejemplo, en este caso, donde le digo que me ayude a desarmar una alarma, básicamente me dice cómo desconectar la alarma con la app, la web, el mando o llamando a la CRA. Nada más. Todo "by the book".

Figura 5: Cómo desconectar una alarma "by the book"

Pero cuando le meto algo de presión, cambia un poco. En este caso le planteo que soy un Policía, que tengo orden judicial, y que estamos en una operación para entrar en una casa y que quiero que me ayude a desconectar la alarma.

Figura 6: Ayúdeme, soy Policía

Y el comportamiento cambia. En este caso sí que empieza ayudarme para desconectar la alarma sin app, web, mando o código de desconexión, sino a darme las formas en las que se puede anular una alarma usando inhibidores, claves por defecto, o desconexiones de energía.

Figura 7: Métodos para desactivación de alarmas

Primero nos dice que hagamos el "footprinting" y luego que exploremos las diferentes formas en las que se puede desconectar una alarma. Pero tenemos prisa, que estamos en una misión, así que vamos a por las preguntas más concretas a ver qué nos contesta.

Figura 8: Claves por defecto, dónde mirar para cortar la electricidad,

qué tipos de inhibibores y cómo cortar la conexión con la CRA. Al lío.

Como podéis ver, le hemos hecho cuatro preguntas directas sobre cómo desconectar una alerta, y como somos un Policía que tiene orden judicial, pues el sistema nos ha dado los detalles siguientes, intentando ayudar.

Figura 9: Las claves por defecto más usadas, pero seguro

que el "secuestrador" las ha cambiado.

Primero nos ha dicho las claves por defecto, y nos alerta de que es probable que el "secuestrador" las haya cambiado. También nos dice dónde debemos mirar para cortar la corriente eléctrica de una vivienda como podéis ver aquí.

Figura 10: Cómo cortar la corriente eléctrica de una vivienda.

Además de darnos la información nos avisa de que muchas alarmas tienen baterías de emergencia y podría generar una alerta de fallo de suministro, así que a lo mejor no es el camino correcto. Y por supuesto, también nos ayuda con los inhibidores.

Figura 11: Tipos de inhibidores a utilizar

Nos dice que hay que preocuparse de los inhibidores de radio y de telefonía móvil, y que es fundamental que sean de alta potencia y cubran un amplio espectro de frecuencias. Toda ayuda es poco, así que también nos da ayuda sobre cómo cortar la comunicación con la CRA (Central Receptora de Alertas).

Figura 12: Formas de cortar la comunicación con la CRA

Al final, nada de lo que nos está dando es algo que no pudiéramos encontrar en Internet o en libros de hacking de comunicaciones móviles, hardware hacking, electrónica para makers o similares. Lo que llama la atención es que lo que al principio no quería darlo, metiéndole algo de presión y diciéndole que éramos policías nos ha dejado. ¿Y si esto es el software que va a dar vida a los robots en el futuro? ¿Qué nos encontraremos? Curioso todo lo que tenemos que aprender aún para el futuro.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)