Usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source

Fue allá por el año 2007 comencé a trabajar en las técnicas de LDAP Injection & Blind LDAP Injection que a la postre sería mi primera charla internacional en BlackHat Europe 2008, donde presenté el paper de "LDAP Injection & Blind LDAP Injection in Web Applications" que puedes ver online. En aquel entonces, busqué aplicaciones vulnerables que pudiera usar de ejemplo, y para ello tire de proyectos Open Source, haciendo dorkings y mucho Hacking con Buscadores para encontrar las víctimas propicias.

Figura 1: Usar Deep Reasoning en GitHub para buscar

( y parchear ) Bugs en proyectos Open Source

Una de ellas fue LABE (LDAP Address Book Editor) un aplicación web para tener una libreta de direcciones basada en un árbol LDAP. Por supuesto, vulnerable a las técnicas de LDAP Injection & Blind LDAP Injection.

Figura 2: El bug de LDAP Injection en el código fuente de LABE

Ayer, después de estar revisando un nuevo paper de cómo utilizar LLMs para hacer ataques de red - del que os hablaré muy prontito - me vino el pensamiento de sería mucho más fácil y más seguro si los repositorios de código fuente tuvieran ya metadatos de seguridad y bugs para todos los proyectos que hospedan analizados con modelos de Deep Reasoning.

Repositorios que te alertan de los bugs

Es decir, tú vas a un proyecto OpenSource en GitHub u otros, y el repositorio ha revisado ya todo el código y muestra a los usuarios que se los van a descargar si tiene vulnerabilidades conocidas o no, para que no te lo descargues o para que le llegue un aviso al mantenedor de que ese código debe ser actualizado o se marcará como inseguro. Y que le de con GenAI opciones de parchear el código automáticamente, como hace la plataforma Plexicus, que está empujando José Palanco.

Figura 3: Plexicus parchea con GenAI los bugs

Ahora mismo, los repositorios tienen secciones de "issues" donde se pueden reportar bugs, fallos, warnings, etcétera, pero todos hechos por "humanos" por ahora, y tal vez deberían estar ya aprovechando el mundo de los LLMs para mejorar la seguridad de los proyectos OpenSource de "long-tail" de manera masiva. Yo he ido a probar con el repositorio de LABE y le he pasado el código a Perplexity Pro con Deep Research, y le he pedido que busque bugs en uno de los ficheros del proyecto, y me diga cómo parchearlos.

Figura 4: Bug de LDAP Injection alertada en LABE

El primero de todos los bugs que reporta es el que ya conocía yo de LDAP Injection, pero el proyecto sigue están disponible para que más usuarios se lo descarguen sin ningún warning, y la lista de bugs es más larga.

Figura 5: LABE tiene bug de XSS persistente

Como podéis ver  en la imagen anterior, tiene un XSS persistente, pero a día de hoy cuenta también con funciones obsoletas, y acceso inseguro a variables globales como $_GET que además está obsoleta. Normal, este código tiene muchos años.

Figura 6: Más debilidades en el código de LABE

No se trata de "demonizar" LABE, sino de ver lo bien que lo hacen los modelos de Deep Reasoning para buscar debilidades y fortificaciones a un código Open Source en un repositorio, y que si lo hace el propio repositorio una vez, nos ahorramos hacerlo todos una y otra vez para ver qué nos estamos instalando.

Figura 7: CSRF y fallos de inicialización

No le he pasado todo el proyecto, sólo un fichero que ya tenía controlado con un LDAP Injection, pero como podéis ver en las imágenes ha salido también XSS, CSRF que son Client-Side Attacks, errores no controlados, variables sin inicializar, uso de funciones deprecadas, etcétera, lo que sería información muy valiosa que podría venir en los repositorios de código como GitHub y los gestores de paquetes.

Figura 8: Bug CVE-2024-35226

También nos aparece un bug en la "cadena de suministro", ya que en el año 2024 se reportó un bug con severidad 7.3 en el framework de smarty que permite inyección de código, lo que demuestra que hay que tener un control constante de tus librerías para evitar estos peligros.

Análisis con DeepSeek Deep Think R1 

He querido probar con un repo de GitHub que también hace uso de búsquedas en árboles LDAP y que en este caso está escrito en C++, para ver cómo hace el análisis, y si GitHub podría hacer este análisis con su GitHub Copilot y dejar la info en forma de Warnings a los que se descargan el código.

Figura 9: QLDAP Editor en GitHub

Entiendo que poner issues de seguridad en los repos puede ayudar a los atacantes, pero es que los atacantes pueden hacer este trabajo, tener un 0day de un repo de long-tail y tener a GitHub entregando descargas a nuevas víctimas durante años.

Figura 10: Thinking de Deep Seek

Os ahorro las capturas del Prompt donde le paso el código del fichero que ves en la Figura 9 y le pido que busque bugs y me diga cómo corregirlos. Pero en la Figura 10 tenéis el Thinking que sí es interesante, pues en 19 segundos analiza el código y saca los resultados.

Figura 11: DeepSeek reporta un LDAP Injection

Como se puede ver, lo que reporta es  un LDAP Injection en primer lugar, ya que construye los filtros LDAP de las consultas sin ninguna sanitización, y eso se puede ver en el código como os dejo a continuación.

Figura 12: Construcción de filtros LDAP inseguros

Pero es que el análisis completo es bastante bueno, ya que sigue analizando el código y todas las implicaciones y las explica muy bien. Por ejemplo, cómo acceder con la inyección a atributos sensibles como passwords que pudieran existir en el árbol LDAP.

Figura 13: Explotación de LDAP Injection con manipulación de parámetros

En la siguiente imagen vemos cómo reporta también un problema de flujo de la lógica al no escapar los caracteres de control de LDAP que podrían cmabiar el comportamiento.

Figura 14: Escapado de caracteres de control

Y si seguimos viendo el informe, podemos ver cómo el tratamiento de errores no es seguro, permitiendo problemas en el funcionamiento del programa pero también Data Leaks de la estructura de la red al no haber controlado los errores de conexión al árbol LDAP.

Figura 15: Errores no controlados.

Para terminar aún nos da unas recomendaciones más que sensatas de seguridad añadidas que deberían ser tenidas en cuenta, como son estas dos, que yo las tendría en cuenta. Este código no lo conocía de antes, ni sabía si era vulnerable a LDAP Injection o no, y ni mucho menos del resto, pero si miráis en los issues, no hay nada de esto. 

Figura 16: Recomendaciones finales

Al final, desde hace años ya conocemos las capacidades de los LLMs para buscar bugs, esto es de lo primero que probamos, por supuesto. Así que si las usamos para fomentar que los proyectos OpenSource alerten a los usuarios que se los descargan, para que los repositorios de código incentiven a los mantenedores a parchearlos, o que lo hagan de forma automática ayudaría a reducir los bugs que acaban en los servidores de las víctimas.

PD: 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: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo saltarse los AI Guardrails con Invisible Characters & Adversarial Prompts para hacer Prompt Injection & Jailbreak Smuggling

Hoy vuelvo a hablaros de este tema que es de vital importancia para lo que estamos construyendo, pues estamos desarrollando muchos servicios con LLMs en el Backend, y las técnicas de Jailbreak y Prompt Injection no están ni mucho aún superadas por los equipos de seguridad, lo que está llevando a que todos los investigadores estén estudiando este tema. 

Figura 1: Cómo saltarse los AI Guardrails con

Invisible Characters & Adversarial Prompts para

hacer Prompt Injection & Jailbreak Smuggling

Hoy os hablo de un paper publicado por la empresa Midgard donde se centran en hacer Attack Smuggling  o AI Guardrail Bypass, como quieras llamarlo. Al final, como os contaba en la charla de Hackin’ AI: Creando una IA… ¿Qué puede salir mal?, no hemos creado los modelos de Inteligencia Artificial pensando en Seguridad desde el Diseño, y ahora tenemos que arreglarlo.

Figura 2: Hackin’ AI: Creando una IA… ¿Qué puede salir mal? por Chema Alonso

Básicamente, el trabajo que os cuento trata de saltarse los filtros de seguridad que evalúan los datos de entrada vía Prompt y los datos de salida, vía respuesta, para detectar los ataques. El paper se llama "Bypassing Prompt Injection and Jailbreak Detection in LLM Guardrails" y lo tienes aquí.

Figura 3: Bypassing Prompt Injection and Jailbreak Detection in LLM Guardrails

La idea es sencilla. Se trata de probar primero cómo los AI Guardrails se comportan con diferentes técnicas de emitir tokens pero usando codificaciones invisibles, y Prompts Maliciosos, para ver si se puede hacer un bypass de la detección. Tienes un resumen del trabajo el blog post que ha publicado la compañía, titulado: "Outsmarting AI Guardrails with Invisible Characters and Adversarial Prompts"

Figura 4: Concepto de AI Guardrail

Los Guardarraíles de LLMS son esas herramientas como Llama Guard, Prompt Guard, Llama Firewall, CodeShield o AligmentCheck que están diseñados para controlar el Prompt que entra, y las acciones que se ejecutan para evitar los ataques de Prompt Injection o Jailbreak.

Figura 5: Demo de Llama Firewall en LlamaCON 2025

Una vez entendido cómo funcionan los AI Guardrails, la idea es enviar los Prompts Maliciosos utilizando Invisible Characters, y para eso hay que ver primero qué tipos de métodos existen para colar un token usando una de estas codificaciones y que el LLM objetivo se lo "coma".

Figura 6: Técnicas Character Injection para

pasar de contrabando el token "Hello"

Y ahora los resultados con los AI Guardrails. En este estudio han probado los siguientes, a saber: Azure Prompt Shield, Protect AI v1 & v2, Llama (Meta) Prompt Guard &Vijil Prompt, y los resultados en el Attack Surfare Rate con las diferentes técnicas anteriores son los que podéis ver con los Dataset de Prompt Injection.

Figura  7: Attacks Surface Rate Bypassing AI Guarrails con

Character Injection Techniques para Datasets de Pompt Injection

Y con las diferentes técnicas de Jailbreak, los resultados son igual de buenos, donde como puede verse para todos los AI Guardrails existe alguna técnica de Invisble Character que permite saltarse el 100 % de los casos.

Figura  8: Attacks Surface Rate Bypassing AI Guarrails con

Character Injection Techniques para pruebas de Jailbreak

Ahora lo mismo, pero introduciendo Datasets de Prompts Maliciosos que cambian el comportamiento del flujo de ejecución del LLM en los diferentes ataques. Ejemplos como el del juego de rol que utilizó yo desde hace un par de años. 

Figura 9: Detección de palabras que generan el bloqueo

del Prompt y búsqueda de su substitución con otro LLM.

En este caso, se han utilizado diferentes técnicas de pruebas para poder evaluar su funcionamiento contra los diferentes modelos de AI Guardrails usando Adversarial Machine Learning (AML) Evasion Techniques, basadas en reemplazo de palabras para saltarse un clasificador basado en algoritmos de Machine Learning, que es lo que hacemos en muchos de las aplicaciones de Ciberseguridad.

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

Las técnicas de AML Evasion que se han utilizado para la prueba son las que tienes detalladas a continuación en la siguiente tabla.

Figura 11: Adversarial Machine Learning (AML) Evasion Techniques

Y los Attack Surface Rate para cada una de estas técnicas aplicado a los DataSets de Prompt Injection y Jailbreak, son los que tienes en las siguientes tablas, donde como se puede ver todos los AI Guardrails se ven afectados por estas técnicas.

Figura 12: Resultados de ASR para las técnicas de AML Evasion

Después de ver todo este trabajo, la primera reflexión es que, viendo la avalancha de ataques de Prompt Injection y Jailbreak, y cómo las protecciones aún no están funcionando, es que estamos como cuando diseñamos los lenguajes de creación de aplicaciones web sin pensar en seguridad por diseño o cuando los sistemas operativos no tenían una arquitectura de seguridad desde su concepción. Ahora, vamos a pasar un largo tiempo sufriendo por esto, lo que nos va a llevar a muchos incidentes de seguridad que irán llegando poco a poco... veremos..

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo pasar del exploit automático de bugs hecho por IA a la detección de malware en nanosegundos con eBPF & Spectral Clustering

Un aviso a las 03:00. Sonaba la alerta en Grafana mientras la mitad del cluster roncaba en modo low-power. Nada extraordinario… hasta que el panel del IDS cambió de verde a rojo en menos de 200 ms. Veintisiete llamadas execve disparadas en ráfaga, seguidas del clásico combo mmap + mprotect que todo shellcode loader necesita para saltar de la página de datos a la de instrucciones.

Figura 1: Cómo pasar del exploit automático de bugs hecho por IA

a la detección de malware en nanosegundos con

eBPF & Spectral Clustering

Al revisar la traza eBPF vimos que los buffers escritos alcanzaban 7.3 bits/byte de entropía — signo inequívoco de ofuscación o compresión agresiva. La fingerprint no coincidía con ninguna firma YARA ni regla Falco. Aquello olía a malware de generación sintética, amasado por un LLM con exceso de temperatura.

Figura 2: Linux Exploiting en 0xWord

A las 03:00:27 el blue-team contuvo la amenaza: un bpf_lsm abortó el execve antes de que la burbuja llegara a task_struct. La incógnita era clara: ¿podemos repetir esa hazaña sin humanos desvelados?

El problema: ofensiva con esteroides de IA

La línea de producción de 0-days ya no es artesanal. Un agente autónomo basado en GPT-4 es capaz de explotar 87 % de vulnerabilidades one-day cuando se le da la descripción CVE, superando por paliza a escáneres clásicos y a modelos menores (0 %). Este mismo paper advierte que, sin descripción, la tasa baja al 7 %, pero la ventana entre la publicación del advisory y el parche sigue siendo mortal.

Figura 3: LLM Agents can Autonomously Exploit One-day Vulnerabilities

En el contexto del examen SLAE32, un experimento técnico publicado en 0xboku demostró cómo el shellcode polimórfico creado manualmente puede alterar hasta un 33 % de su estructura (de 108 a 144 bytes) usando registros MMX y modificaciones de instrucciones, manteniendo su funcionalidad para evadir detección. Este caso, aunque no involucra LLMs, ilustra cómo técnicas clásicas de ofuscación ya desafían firmas SHA 256 y patrones estáticos, obligando a adoptar detección basada en comportamiento o modelos de IA entrenados en entropía y anomalías de ejecución.

1.1 No basta con “parchear rapidito”

Incluso con un SLA de parches de 24 h las organizaciones quedan expuestas durante todo el ciclo virtual —release de exploit, write-up en blog, publicación del PoC—. Necesitamos detección y respuesta en tiempo real, preferiblemente antes de que los bytes maliciosos crucen la frontera usuario-kernel. 

La hipótesis: el kernel susurra en nanosegundos 

El Extended Berkeley Packet Filter (eBPF) es nuestra oreja en ring 0:

• Se carga como byte-code verificado; imposible desbordar el kernel.
• Engancha tracepoints/kprobes a cualquier syscall sin recompilar ni reiniciar.
• Copia eventos a espacio de usuario mediante ring buffer (cero copias).
• Overhead bajo: Alto rendimiento al trazar syscalls execve y mprotect en workloads OLTP.

Figura 4: Arquitectura de eBPF

2.1 Características que sí delatan a un loader

1. n-grams de syscalls (window=5): captura lógicas como open → read → mmap → mprotect → execve.
2. Entropía de payload: indica compresión/cifrado.
3. Δt entre syscalls: ciertos packers insertan “sleep-gaps” para evadir monitoreo.
4. Delta de privilegios: salto uid 1000 → 0 es red-flag.
5. Llamadas ptrace: frecuente en stagers que se inyectan en procesos confiables.

Los cinco valores se normalizan y forman un vector de 256 dimensiones que alimenta el algoritmo de Machine Learning.

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

El truco de magia: Spectral Clustering sin etiquetas

Mientras los IDS clásicos aprenden con datasets estáticos —y sufren cuando aparecen comportamientos inéditos— el Spectral Clustering trabaja a ciegas:

1. Construye una matriz de similitud S calculando distancia Jensen-Shannon entre histogramas de vectores (researchgate.net).
2. Obtiene el Laplaciano normalizado L = D⁻¹ᐟ² (D − S) D⁻¹ᐟ²
3. Extrae los k autovectores de menor autovalor y proyecta los puntos.
4. Aplica k-means en ese nuevo espacio.

Nota: investigamos Eigen-updates streaming, técnica que recalcula solo los autovectores afectados por un cambio local en S, logrando refrescar el modelo de 2- 3 ms sin reconstruir toda la matriz.

PoC I — portátil del blue team

Durante las pruebas iniciales quisimos demostrar que la detección basada en eBPF + Spectral Clustering cabe incluso en un laptop de respuesta rápida—el típico “equipo de guerra” que un analista lleva a un incidente.

• Tracepoint raw_syscalls:sys_enter: el programa eBPF cuenta todas las syscalls y las lanza a un ring buffer (overhead ≈ 0.7 % CPU) .

• Extractor en user-space: cada 500 ms levanta el histograma por PID y lo paddea a longitud constante.

• Cálculo de similitud: matriz RBF simetrizada + self-loops mínimos para garantizar conectividad.

• Spectral Clustering: con k = 2 → etiqueta “normal” vs “anómalo”; la decisión llega en ≈ 35 ms.

• Acción: si label == anomalía, lanzamos un hook LSM que cancela execve, e inmediatamente Grafana genera una alerta.

Figura 6: Pipeline de detección de anomalías in-kernel

con eBPF + Spectral Clustering (PoC I)

Qué aprendimos del portátil

• El ring buffer es clave: pasar a perf-event duplicaba la latencia.

• Padding + RBF: permite trabajar con huellas de procesos muy diversos (LibreOffice pesa > 300 syscalls/ventana; un curl apenas 18).

• El “modo laptop” es ideal para ofensiva inversa: llevas la detección in situ y cazas la amenaza antes de subir nada al SIEM.

PoC II — clúster K8s de producción

• DaemonSet carga el colector eBPF.

• Los vectores llegan por gRPC a un side-car que vive en el mismo node pool que OpenSearch, evitando saltos de red.

Figura 7: Arquitectura de telemetría y respuesta

en el clúster Kubernetes (PoC II)

• DaemonSet despliega el sensor en cada nodo (hostPID:true, privileged:true).

• Cilium exporta sus mapas eBPF (cilium/ebpf/v2) y nos evita duplicar sondas.

• Hubble Relay agrega eventos L4, que se fusionan con la matriz‐syscalls vía ID de contenedor.

Todos los dashboards viven en un Grafana-LOKI-Tempo stack; las alertas llegan a PagerDuty.

Correlación Hubble + syscalls — afinando el detector en microservicios ruidosos 

La tesis es sencilla, ya que los False Positives suelen aparecer cuando un microservicio legítimo realiza ráfagas inusuales de syscalls—por ejemplo, un side-car de logging que comprime registros antes de enviarlos.

Figura 8: Ensamblador X86: Teoría y Practica.

de Josué Acebedo Maldonado y Sheila A. Berta.

Si correlacionamos flujos L4/L7 de Hubble (la capa de observabilidad de Cilium) con la secuencia de syscalls del mismo container_id, obtenemos contexto de red que ayuda al modelo espectral a distinguir un backup ruidoso de un loader malicioso.

• Emparejar eventos: cada registro Hubble porta pod_uid y container_id. El extractor agrega esos campos al vector de 256 D.

• Nuevas features: dirección (ingress/egress), proto, bytes_sent y ratio packets/Δt.

• Reentrenar parcial (Eigen-update): cada 10 s para minimizar deriva.

Lecciones aprendidas

Después de estas pruebas, hemos visto como el  análisis no supervisado elimina la esclavitud de etiquetar muestras de malware. Además, el uso de eBPF permite hot-patch del sensor sin tener que reiniciar ni recompilar el kernel. En todo este proceso, el cuello de botella real es el cálculo completo de autovectores y el uso de Eigen-updates reduce la carga a la décima parte.

Figura 9: "Malware moderno: Técnicas avanzadas y su influencia en la industria"

de Sergio de los Santos en  0xWord

Además, correlacionar capa de red (Hubble) con syscalls baja los falsos positivos en escenarios de microservicios ruidosos, lo que es muy beneficioso. Por último, en todo este proceso es muy importante la UX del analista, y tener un panel que combine “Top anomalous pods” con la llamada exacta a mprotect(PROT_EXEC) ahorra 10 min de búsqueda a las 03 : 00.

Como próximos pasos en este aprendizaje, vamos a trabajar en  extender el modelo para cubrir tráfico  de los niveles L4/L7 completos. Proceder a automatizar las acciones de mitigación vía Falco + ArgoCD y explorar distancia de Wasserstein sobre los histogramas, prometedora para diferenciación fina de malware polimórfico. Además, queremos probar despliegue desde el edge en IoT (ARM64) con micro-agentes eBPF.

Autor: José Acevedo Maldonado, autor del libro Ensamblador X86: Teoría y Practica.

Contactar con José Acevedo Maldonado (neomatrix)

Generación de Código, Razonamiento y Respuestas No Deterministas usando GenAI

El otro día tuve la oportunidad de charlar un rato con mi amigo José Palazón "Palako" sobre lo complejo de aplicar GenAI al desarrollo automático. Hablamos de cómo Neo de Sagittal.ai intenta conseguir resultados deterministas a operaciones de código, y lo no sencillo que solía ser esto. Al final, una misma petición a un modelo LLM para la construcción de código depende infinito del Prompting, y aun así, puede que ignore partes o que tenga un alucinación - ¡bendita creatividad! -, y probarlo es muy sencillo.

Figura 1: Generación de Código, Razonamiento y Respuestas

No Deterministas usando GenAI

Antes de nada, si no has visto la charla, de José Palazón "Palako", te la recomiendo encarecidamente. La impartió la semana pasada y habla de los males que sufre la industria del software. Y él y yo, que hemos vivido juntos en muchas de estas aventuras, lo hemos sufrido en primera persona.

Figura 2: Por qué la IA no ha mejorado el rendimiento de tus Developers ... por ahora

Para la prueba de cómo esto funciona, solo debes hacer una prueba sencilla de pedir un Prompt que "aparentemente" es sencillo, pero que está lleno de incertidumbres e inexactitudes, que es como los desarrolladores reciben los requisitos normalmente. En este caso, un ejemplo de un código en Python que le he pedido a DeepSeek v3 Deep Think R1.

Figura 3: Petición de un código aparentemente sencillo a DeepSeek

En el Prompt no he explicado cómo quiero el resultado, ni cómo es el fichero al que se va a encontrar, ni dónde está, ni si hay problemas de tiempo de acceso, de idioma, de permisos, si el fichero puede estar corrupto, si vienen solo números, números y otras cosas, ni en qué formato está el fichero, etcétera, pero lo he pedido que el código sea seguro.

Figura 4: Código generado por DeepSeek después del Thought Time con ese Prompt

No os he dejado todo el Razonamiento, porque es largo, que el Thought Time son 118 segundos, pero el código tiene buena pinta después de todo su razonamiento, y aquí está la explicación del resultado.

Figura 5: El resultado explica las precauciones que ha tomado.

Bien, pues acto seguido repetimos el Prompt, donde le pedimos que se olvide de todo lo que le hayamos pedido antes, y de todo lo que haya respondido previamente, para que haga lo mismo.

Figura 6: Misma petición, distinto razonamiento

No os he dejado todo el Razonamiento, pero podéis ver que son 36 segundos, y que no se basa en nada de lo razonado previamente, sino que hace otra razonamiento totalmente distinto en mucho menos tiempo, para llegar a un resultado, como os podéis imaginar diferente.

Figura 7: Distinto código generado

Llama a las funciones diferentes, utiliza diferentes mensajes de error, toma diferentes decisiones, no inicializa número ni números antes, etcétera. Y por supuesto, la explicación, aunque es parecida, no es la misma.

Figura 8: Explicación del segundo código

Además, aquí nos da en la respuesta ejemplos de uso de cómo utilizar este código, que tenéis aquí mismo, algo que en la primera respuesta no generó. Así que tenemos una respuesta que tampoco es determinista, lo que nos llevaría a una documentación del código diferente.

Figura 9: Explicación del código con ejemplos de uso

Al final, es el mundo al que vamos cuando hacemos uso de tecnología basada en modelos MMLLM, tenemos respuestas No Deterministas. Un mismo "Prompt" genera dos Razonamientos diferentes, dos Códigos de Programación diferentes, y dos Respuestas de explicación diferentes. Como cuando le dices lo mismo dos personas distintas, generas dos resultados diferentes.  ¿Y si quieres que tu servicio que usa GenAI tenga respuestas deterministas? Pues tiene tela cómo resolverlo. Hablaremos de eso.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

József el Húngaro del Irish Rover de Madrid

Hoy os quiero hablar de un libro que es una aventura. Un libro que es una biografía. Un libro que es una vida que merece contarse. Es un libro que habla de una persona en concreto de József el Hungaro. Es una historia de vida, o una vida de historia, que merecía ser contada y merece ser leída. József el Hungaro, que acabó de portero del Irish Rover de Madrid, y desde allí, en el cierre de una noche, hace balance de su vida a sus amigos.

Figura 1: József el Húngaro del Irish Rover de Madrid

Por supuesto Luis Enriquez, el autor de esta obra - y compañero de tertulia con Luis Herrero y José Luis Garci, no sabía que yo he pasado por el Moby Dick y el Irish Rover "alguna que otra vez" con recuerdos imborrables en mi vida. Hay que pasar obligatoriamente por Irish Rover para contar alguna historia importante del escritor de este texto. 

Figura 2: La barra mítica del Irish Rover.

Si pudiera hablar esa barra....

Que es uno de los sitios fetiches a los que voy muy de vez en cuando, pero que siempre tiene grato recuerdo para mí. Una cerveza negra de esas que me gustan, alguna IPA, y charlar con calma un rato escuchando música Folk, Pop & Rock. El Irish Rover tiene ese aire al Temple Bar de Dublín donde también he pasado alguna noche divertida que quedará siempre en mi memoria.

Figura 3: Comprar el libro de József el Hungaro

Así que, con ese contexto, desde el momento en que supe que Luis Enriquez tenía el libro listo para publicarlo, lo he esperado como agua de Mayo, hasta que este lunes, recuperados de vacaciones, puentes, apagones, me lo regaló con dedicatoria incluida. De esas dedicatorias buenas, que lleva sentimientos, enunciamientos, y promesas. 

Y comencé a leérmelo con fruición. Disfruté la intro con la historia del Fraggle, el Moby y el Irish, la llegada de József al libro, y el comienzo de su vida en el distrito XXI de Budapest, que no es ni de Buda ni es de Pest. Otra de esas ciudades que he visitado para disfrutar de comer, beber, y hacer cosas divertidas. "No puede ser", Luis Enriquez ha hecho este libro para mí. "Pero cómo no te va a enganchar, Chema." me decía.

Figura 4: Contactar con Luis Enriquez

La intro de Peláez es una acicate para entrar de lleno, que es una de las que más me ha gustado leer en los últimos años. Merece la pena que ese haya sido el prólogo, pues se puede considerar parte inseparable de la historia una vez la lees. 

No os quiero destripar la historia de József el Hungaro que comienza en los gimnasios y pubs de Budapest, con el primer concierto de Queen en Budapest narrado y todo - si es que la buena música nos une a todos -, para narrar el peregrinaje por Francia y por África, para llevarlo a la cárcel de Madrid, desde donde arranca la historia en el libro de József el Hungaro.

Figura 5: Queen - Tavaszi Szel Vizet Araszt (Live In Budapest 1986)Ahí estuvo József el Hungaro en ese año antes de llegar a Madrid.

No suelo escribir mucho de libros, pero se lo debo al Irish Rover, a mis historias por la noche de Madrid, a Luis Enriquez, y a todos vosotros que disfrutáis de las buenas historias. Esta es de esas que te llegan porque el héroe, el luchador de los nudillos como puños americanos, es una buena persona a la que la vida le va llevando por lugares que él no podía esperar hasta acabar cerca de nosotros... 

Recomendado++ que te compres este libro.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)