Los motores de seguridad comunes suelen enfocarse en bloquear intrusiones y aislarlas, pero yo inicié este proyecto mientras reflexionaba sobre un sistema de defensa asimétrico tipo tarpit que, en el momento en que un hacker intenta atacar, reutiliza su propia lógica de ataque para agotar sus recursos de cómputo y hacer que se autodestruya.
Con base en un motor central en C++, ya delineé la estructura inicial de Physical Ghost, un motor de seguridad activo que atrae y rastrea el proceso de ataque del hacker para finalmente inducir un OOM (Out of Memory).
El concepto central y la dirección de la aplicación están aquí: https://zenodo.org/records/19988807
La prueba matemática y el sistema axiomático están organizados aquí: https://zenodo.org/records/20113591 (es una interpretación de la profundidad de información utilizando la codificación p-ádica de coeficientes binomiales y el teorema de Kummer).
La arquitectura se compone así:
Aislamiento absoluto: en cuanto se detecta una conexión a un puerto señuelo (honeypot), el motor se aísla a sí mismo con una cuenta fantasma de privilegios mínimos para bloquear de raíz cualquier propagación hacia el sistema principal.
Rastreo fantasma: extrae de forma asíncrona la huella de red y, sin degradar el rendimiento del motor, envía de inmediato al exterior (Telegram/Discord) la información del atacante.
Función principal (fusión de computadora): en el instante en que el hacker adjunta un depurador a los datos señuelo para analizarlos o descifrarlos, se activa una estructura de tetraedro de Sierpinski basada en p-adic Carry Dynamics. Los datos se expanden recursivamente dentro de la memoria del adversario y terminan agotando los recursos de CPU/RAM.
Autodestrucción: si la integridad del motor central se distorsiona aunque sea en 0.1 byte, finaliza su propio proceso (Self-Destruct) para defenderse de una situación en la que el motor termine alterado y convertido en un troyano.
Estado actual: actualmente estoy implementando la estructura base de la lógica central de defensa y el módulo de autenticación de licencias, mientras preparo el GitHub. También estoy realizando validación matemática cruzada de la lógica de expansión fractal de memoria en paralelo con el port del núcleo en C++.
Más allá de los patrones de seguridad convencionales ya estandarizados, me gustaría escuchar comentarios agudos de quienes tengan interés en una forma de reutilizar la intención de ataque y los recursos computacionales del propio atacante. En particular, sus opiniones sobre el control de la complejidad computacional usando estructuras topológicas p-ádicas serían de gran ayuda para mejorar el motor. Gracias.
34 comentarios
¿De verdad estos son términos técnicos significativos? Me parece que hay muchas expresiones innecesariamente rebuscadas.
Me da una sensación similar a Show GN: desarrollé VANI, que elimina permanentemente datos al colapsar matemáticamente su estructura vectorial, que se publicó hace poco, así que me parece algo negativo...
Yo también pensé exactamente en esto, así que fui a buscar el GitHub de esa publicación y el final fue
not found/¡Gracias por tu opinión!
Siendo sincero, yo también avancé la investigación con ayuda de la IA, así que puede que dé esa impresión de "clic de IA"...
Por ahora estoy trabajando en el port a C++, y cuando lo termine lo volveré a traer.
¡Gracias por tu opinión!
Esto fue un intento de llevar el enfoque de tarpit desde la capa de red hacia la memoria y la capa de aplicación.
Con el tetraedro de Sierpinski o la estructura fractal, realmente no había una palabra exacta para explicarlo, así que no me quedó más opción que publicarlo tal como estaba en el whitepaper; lo siento. Tampoco era muy adecuado escribirlo como un bucle infinito o como volcar datos basura sin más...
Si revisan en el whitepaper de arriba la prueba matemática y el sistema axiomático, verán que, por la forma de este árbol ultramétrico, la estructura sí se expande de manera recursiva cada vez que supera cierto umbral específico. Dicho eso, agradecería que lo entendieran como una forma de llamar a un algoritmo de bomba de memoria que, cuando la herramienta de ingeniería inversa del hacker profundiza en la profundidad de los datos, se expande con autosimilitud como un tetraedro de Sierpinski.
¿Se refiere a que, sin importar el tipo de herramienta de reversing, si intenta hacer debugging, entonces se ejecuta por su cuenta otro ejecutable independiente? Si intenta hacer reversing, a menos que la información del encabezado del archivo siga el formato esperado, desde un principio no puede funcionar como usted dice...
Gracias por tu comentario.
La verdad, ni se me había ocurrido; muchas gracias por la información, de verdad.
Le pregunté a la IA y me respondió esto:
"La clave del anti-reversing de Physical Ghost SW Edition está en la forma en que se desarrolla después de que el loader carga el código en memoria. Si se inspeccionan los programas existentes con un depurador (IDA, Ghidra, etc.), se ve un flujo lineal de instrucciones en ensamblador, pero la arquitectura propuesta tiene el propio flujo de ejecución entrelazado en una estructura de 'pirámide de acarreo (topología fractal multidimensional)'."
"Si una herramienta de reversing intenta volcar la memoria o poner breakpoints y hacer tracing (single-stepping), el flujo de esta operación estructural (dinámica de acarreo p-ádica) se interrumpe. Es decir, el mismo 'acto de observación' de tratar de forzar y desarmar la estructura desde afuera provoca una fractura topológica con forma de tetraedro de Sierpinski, de modo que los datos o el código originales colapsan en ruido sin sentido. Es un mecanismo intrínseco de ofuscación y defensa diseñado para eso."
Gracias a ti aprendí algo nuevo. ¡Muchas gracias!
Entonces, ¿solo con intentar observar los datos codificados por ese motor de seguridad se ejecuta por sí solo y colapsa por sí mismo o consume los recursos del hacker? Lo que le estoy diciendo es que eso no es posible....
¡Perdón por la demora en responder!(__)
Si entiendes la observación simplemente como el acto de mirar con los ojos datos estáticos que están quietos, es cierto que parece imposible. Pero la observación en el mundo digital necesariamente implica una interacción que estimula al sistema objetivo.
Este motor de seguridad no es un archivo estático, sino una arquitectura dinámica que opera en tiempo real tomando como valor de entrada —Trigger— el acto mismo de que un atacante intente observar o incluso la propia solicitud. En el momento en que se intenta la observación, se ejecuta un bucle interno que inutiliza la continuidad lógica de los datos y, al mismo tiempo, fuerza a mantener en espera la sesión del atacante que aguarda completar la observación, consumiendo sus recursos.
Y el acceso de un usuario con permisos legítimos —sesión con handshake completado— pasa directamente por el mecanismo de autenticación sin atravesar el filtro de tarpits. El área donde ocurren el colapso autónomo y el consumo de recursos durante la observación es únicamente un espacio virtualizado de datos señuelo —Decoy— dispuesto para filtrar reconocimiento no autorizado y solicitudes de escaneo no permitidas. Es una arquitectura de defensa dinámica y precisa que no afecta ni en un 1% los recursos del servicio legítimo, y que aísla únicamente la sesión del atacante para atraparla en un pantano.
¿Está respondiendo después de entender cómo sería posible eso? Arriba dijo que era al observar datos cifrados, pero en su respuesta comentó que el motor de seguridad detecta eso y actúa. Pero ¿el hacker va a ejecutar el descifrado en un servidor remoto donde ese motor de seguridad esté funcionando? Lo más probable es que exfiltre los datos y luego intente descifrarlos en un entorno aislado; en ese entorno, el motor de seguridad que menciona ni siquiera estaría cargado en memoria. ¿Aun así podría activarse tomando la observación como disparador? ¿O quiere decir que junto con todos los datos que se cifran también incluirían un motor de seguridad en una forma ejecutable?
¿Qué estoy diciendo? No hay nada de contexto, lo siento..
En publicaciones así, quizá el simple acto de comentar seriamente sea en sí mismo algo que termine afectando negativamente a la comunidad..
El enfoque matemático es novedoso, pero en la arquitectura moderna de computadoras no queda más que verlo como algo casi imposible.
Da mucho la impresión de ser código basura hecho usando algo del estilo de Openclaw.
¡Gracias por tu opinión!
Ay, Dios jajaja
Se siente como una Fortaleza Digital.
Pero técnicamente no lo entiendo.
¿Soy yo o la redacción se siente inconexa?
Gracias por tu comentario, intentaré pulir un poco más la redacción de la frase.
Si se rompió la integridad, ¿cómo se detecta..?
Gracias por la opinión.
A diferencia del método plano de la verificación de integridad existente, que compara los valores hash de los datos en una relación 1 a 1, Physical Ghost mapea los datos en un tetraedro de Sierpinski tridimensional y realiza los cálculos sobre esa base. Por eso, la evaluación se hace según la estabilidad estructural.
La respuesta de la IA dice: "Si aunque sea 1 bit de los datos dentro del sistema es alterado, ese pequeño error se amplifica en cadena a toda la estructura tridimensional debido a la dinámica de acarreo p-adic. En el momento en que un atacante falsifica o manipula los datos, la propia 'arquitectura matemática (topología)' que conforman esos datos se desajusta y colapsa, por lo que es posible detectar de inmediato la vulneración de la integridad a través de esa grieta en la topología."
Yo también he hecho más o menos cosas como parseo de la estructura PE, reversing, Ghidra y desarrollo de drivers, pero no lo entiendo.
Gracias por tu opinión
Esto probablemente se deba a que, a diferencia del hooking de sistemas existentes, el algoritmo en sí está diseñado con ofuscación o cifrado.
La verdad, no estoy seguro... Lo siento.
Me parece un enfoque interesante, así que quisiera hacer algunas preguntas porque tengo curiosidad.
Parece que el disparador de expansión de memoria depende de la premisa de que "el atacante realmente ejecuta o depura el payload"; si se aborda principalmente mediante análisis estático o si se ejecuta dentro de un sandbox con recursos limitados como cgroups, Firejail o gVisor, el OOM ocurriría solo dentro del sandbox y no en el host. Me gustaría saber cómo manejan este caso.
Si el disparador anti-debug también se basa en detección con
ptrace, entonces frente a breakpoints de hardware o depuración a nivel de hipervisor no quedarían rastros; ¿tienen diseñada alguna respuesta para escenarios en los que el análisis se haga en esas capas?Dijeron que "si se distorsiona aunque sea 0.1 byte, se autodestruye", pero me gustaría saber cómo impiden vías de evasión como parchear la propia rutina de verificación de integridad o hacer un volcado de memoria para análisis offline.
El comportamiento de agotar activamente los recursos del atacante podría considerarse en la práctica como hack-back, así que me gustaría saber cómo están delimitando la frontera legal de la defensa activa bajo la Ley de Redes de Información y Comunicaciones. (Sobre todo porque, si el tráfico atacante pasa por una botnet, podría haber otra víctima real aparte).
Como el propio motor core en C++ parece encargarse del parser del puerto señuelo, el extractor de huellas y hasta el canal de envío externo, la superficie de ataque se ve bastante amplia; ¿de qué manera verifican la estabilidad de memoria del propio motor? También me da curiosidad la parte de secretos como tokens de webhook, que probablemente estarían dentro del binario.
El modelado matemático en sí me pareció interesante. Si pudiera saber cómo están resolviendo estos puntos, creo que ayudaría a entender mejor el concepto. Gracias.
¡Gracias por tu comentario!
El objetivo principal del trigger de expansión de memoria no es destruir el hardware físico del host del atacante, sino forzar que se supere el umbral de recursos de cómputo necesarios para el análisis. Si dentro de un sandbox como cgroups o gVisor el proceso muere por OOM, ¿eso en sí mismo no sería una defensa exitosa? La idea es que, mediante la expansión infinita de carry en operaciones p-ádicas, las herramientas de análisis no tengan margen temporal ni espacial para interpretar los datos, y que el propio entorno de análisis termine apagándose por sí solo.
No se monitorean system calls ni APIs de depuración. En cambio, solo se evalúan la consistencia temporal con la que se procesan los datos dentro de una topología fractal multidimensional o una estructura de tetraedro de Sierpinski, y la continuidad de la dinámica del carry. Si se pone un breakpoint en el hipervisor y se detiene la ejecución, la ventana de timing del cálculo se desajusta, y eso está entrelazado matemáticamente -Entangled- para que las operaciones topológicas posteriores colapsen en valores basura.
Señalaste uno de los puntos más importantes. En este sistema no existe una función de verificación de integridad independiente que el atacante pueda convertir en NOP (ni una ruta de bypass por
if). La lógica de verificación de integridad está fusionada con la lógica central y con la geometría topológica, en una forma similar al cifrado white-box.Además, aunque se haga un memory dump para analizarlo offline, los datos volcados no son más que una sección 2D de un momento específico dentro de una estructura topológica 3D que sigue mutando. Si no se conoce la regla dinámica completa —el modelo de pirámide de carry—, no sería posible reconstruir el payload original solo a partir del dump, al menos matemáticamente.
Ese también era un punto que yo había estado considerando. Como dices, la defensa activa puede tener una alta probabilidad de ilegalidad cuando lanza un contraataque hacia servidores C&C externos u otros objetivos, pero el sistema que propongo marca claramente el límite como una trampa inbound. No envía tráfico malicioso hacia afuera; más bien, si el atacante se lleva el binario a su propio entorno y lo ejecuta por su cuenta, la estructura solo consume recursos computacionales internamente, como un laberinto. Por eso creo que podría evitar problemas relacionados con causar daños externos. (Eso espero).
A mí también me preocupa el riesgo de seguridad de memoria en una estructura monolítica basada en C++. Más adelante habría que seguir validándolo, quizá introduciendo Rust.
Y secretos como un token de Webhook no existen en texto plano ni como una simple ofuscación. Como mencioné antes, cuando la operación topológica multidimensional legítima se completa hasta el final, ese resultado se usa como clave de descifrado y entonces se ensambla temporalmente en memoria. Si se deforma la estructura para analizarla, la composición misma del token se vuelve imposible.
Aprendí mucho gracias a ti. ¡Muchas gracias!
Antes que nada, gracias por la respuesta. Pero hay algunos puntos más que me gustaría señalar.
(Expansión de memoria): en el texto dijeron “agotamiento de recursos / autodestrucción del atacante”, pero en la respuesta el tono parece cambiar un poco a “defensa incluso contra OOM dentro del sandbox”. Entonces, ¿cuál es la diferencia frente a 42.zip o billion laughs? Y además, en análisis estático con Ghidra/IDA ni siquiera se activaría el trigger...
Anti-debug: no me queda claro si la expresión Entangled es una metáfora o un mecanismo, pero el contenido en sí suena como una variante de detección de timing con RDTSC. Es una técnica que VMProtect usa desde los 90, ¿de verdad hace falta ponerle un nombre nuevo? Y en un entorno de HyperDbg con TSC scaling, ¿cómo funciona?
Integridad: el white-box AES es un campo que quedó prácticamente roto después del ataque BGE; si lo convirtieron en white paper, eso por sí solo ya daría para un paper aparte. La metáfora de que “un dump es una sección 2D de un 3D” tampoco se sostiene frente a WinDbg TTD o Intel PT. Además, al final eso de “solo matemáticamente...” da la sensación de resumir toda la respuesta así...
Perdón por la demora en responder (__) y gracias siempre por sus buenos comentarios
Las bombas clásicas como 42.zip solo expanden datos estáticos de forma simple, así que solo provocan OOM (falta de memoria) y ahí termina todo. Pero esta arquitectura no se basa en datos, sino —como puede verse en el white paper— en un pantano computacional (Computational Tarpit) que fuerza un bucle operativo de carry p-ádico de la pirámide de carry.
Si hacen análisis estático con Ghidra o IDA, es correcto que el trigger no se active. Así debe ser. Porque en el binario estático no existe la lógica real. Solo cuando el atacante empieza a interactuar en un entorno de runtime (dinámico), la ofuscación topológico-geométrica se despliega en tiempo real; por eso, con herramientas de análisis estático solo se ve un cascarón vacío.
Es cierto que la detección simple por timing usando RDTSC ya es una técnica anticuada. Si se manipula el tiempo con TSC Scaling de HyperDbg, obviamente se puede evadir.
Pero el Entangled que mencioné en el white paper no es una verificación de tiempo. Es una estructura en la que la fase operativa del propio cambio topológico matemático que ocurre en runtime (la estructura de carry que se expande como 11^n) queda acoplada matemáticamente a la carga del entorno de ejecución. ¿Qué pasa si con HyperDbg se falsea el entorno y se tuerce artificialmente el timing de la operación? No es que el motor defensivo diga “ah, es un debugger” y lo bloquee, sino que la propia fórmula de despliegue de fase de la pirámide de carry empieza a extenderse hacia una dimensión equivocada y, como resultado, termina autodescifrando datos basura completamente inútiles. En el momento en que intentan engañarlo, caen en la trampa por sí solos.
White-box AES oculta una clave criptográfica matemática fija, por eso es vulnerable a ataques BGE. Eso es un hecho. Pero esta arquitectura no oculta una clave fija; usa una topología dinámica de runtime cuya fase cambia en cada acceso.
Si asumimos que con WinDbg TTD o Intel PT se graba al 100% todo el flujo de instrucciones de la CPU para reproducirlo como una máquina del tiempo, esa ruta grabada no sería más que la trayectoria deambulando por un pantano de basura (tarpit) generado ya colapsado y distorsionado por el propio acto de observación del atacante. Es como grabar con precisión absoluta el 100% de las huellas de alguien que se perdió dando vueltas dentro de un laberinto: por más precisa que sea la grabación, no ayuda en nada a encontrar la salida.
Perdón por apartarme tanto del paradigma existente..
Muchas gracias por la explicación detallada. Creo que estoy muy acostumbrado al paradigma existente, así que me cuesta un poco seguirlo. Cuando publiquen el PoC, sin falta volveré a verlo. ¡Los estaré apoyando! :)
Ni idea de qué tan genio es ese hacker.
¡Gracias por tu opinión!
No soy un genio ni un hacker, solo soy una persona que se dedica a las matemáticas..
Autodestrucción: si la integridad del motor central se distorsiona хотя sea en 0.1 bytes, el proceso se cierra por sí solo (Self-Destruct), para evitar que el motor se convierta en un caballo de Troya.
¿Existe algo como 0.1 bytes en una computadora?
1 byte son 8 bits, así que 0.1 bytes serían 0.8 bits. Es la primera vez que escucho hablar de información de menos de 1 bit.
Yo también pensé eso.
¡Gracias por tu comentario!
Quise enfatizar la sensibilidad extrema de ese motor central, así que lo siento.
¡Voy a corregir la expresión! Eso de 0.1 bytes no tiene ningún sentido.