Les moteurs de sécurité classiques se concentrent généralement sur le blocage et l’isolement des intrusions, mais j’ai lancé ce projet en réfléchissant à un système de défense asymétrique de type tarpit qui, au moment même où un hacker tente une attaque, détourne sa propre logique offensive pour épuiser ses ressources de calcul et le conduire à son autodestruction.
En m’appuyant sur un moteur cœur en C++, j’ai posé l’ossature initiale de Physical Ghost, un moteur de sécurité actif qui attire et suit le processus d’attaque du hacker pour finalement provoquer un OOM (Out of Memory).
Le concept central et l’adresse de l’application sont ici : https://zenodo.org/records/19988807
La preuve mathématique et le système axiomatique sont organisés ici : https://zenodo.org/records/20113591 (il s’agit d’une interprétation de la profondeur de l’information utilisant le codage en base p des coefficients binomiaux et le théorème de Kummer).
L’architecture est organisée comme suit :
Isolement absolu : dès qu’une connexion est détectée sur un port leurre (honeypot), le moteur s’isole lui-même avec un compte fantôme à privilèges minimaux, afin de bloquer à la source toute propagation vers le système principal.
Phantom Tracking : en extrayant de manière asynchrone l’empreinte réseau, il transmet immédiatement vers l’extérieur (Telegram/Discord) les informations sur l’attaquant, sans dégrader les performances du moteur.
Fonction clé (fusion informatique) : au moment où le hacker attache un débogueur aux données leurres pour les analyser/déchiffrer, une structure de tétraèdre de Sierpiński fondée sur la dynamique des retenues en base p (p-adic Carry Dynamics) s’active. Les données se dilatent récursivement dans la mémoire de l’adversaire et finissent par épuiser les ressources CPU/RAM.
Autodestruction : si l’intégrité du moteur cœur est altérée ne serait-ce que de 0,1 octet, il termine lui-même son processus (Self-Destruct) afin d’empêcher qu’il soit détourné en cheval de Troie.
État actuel : j’ai actuellement implémenté l’ossature de la logique de défense centrale et le module d’authentification de licence, et je suis en train de préparer le dépôt GitHub. En parallèle, je poursuis la validation croisée mathématique de la logique de dilatation fractale de la mémoire ainsi que son portage dans le cœur C++.
Au-delà des schémas de sécurité conventionnels, j’aimerais recueillir les retours pointus de personnes intéressées par une approche qui retourne contre l’attaquant son intention offensive et ses ressources de calcul. En particulier, vos avis sur le contrôle de la complexité computationnelle à l’aide d’une structure topologique en base p seraient d’une grande aide pour faire évoluer le moteur. Merci.
34 commentaires
Est-ce que ce sont vraiment des termes techniques pertinents ?? J'ai l'impression qu'il y a beaucoup de formulations inutilement pédantes.
Cela me donne une impression similaire à Show GN: J’ai développé VANI, qui supprime définitivement des données en faisant s’effondrer mathématiquement leur structure vectorielle, publié il y a quelque temps, donc j’ai une perception plutôt négative...
C’est exactement ce à quoi j’ai pensé aussi, donc je suis allé chercher le GitHub de l’article, et au final c’était un
not found/Merci pour votre avis !
Pour être honnête, moi aussi j’ai fait avancer mes recherches avec l’aide de l’IA, donc je comprends que ça puisse donner une impression de « clic IA »...
Pour l’instant, je suis en train de le porter en C++, et une fois ce sera terminé, je reviendrai le partager.
Merci pour votre avis !
C’est une tentative pour faire remonter l’approche du tarpit du niveau réseau vers la mémoire et la couche applicative.
Pour le tétraèdre de Sierpinski ou la structure fractale, je n’avais pas vraiment de meilleur terme explicatif, donc je n’ai eu d’autre choix que de reprendre tel quel ce qui figurait dans le livre blanc, désolé. Cela dit, il était difficile d’écrire simplement « boucle infinie » ou « injection massive de données parasites »…
Si vous regardez, dans le livre blanc ci-dessus, la partie sur les preuves mathématiques et le système axiomatique, vous verrez qu’en raison de sa forme en hyperarbre, la structure s’étend bien récursivement chaque fois qu’un certain seuil critique est dépassé. J’aimerais simplement que vous compreniez qu’il s’agit d’un algorithme de bombe mémoire qui se déploie avec une auto-similarité, comme un tétraèdre de Sierpinski, lorsque les outils de reverse engineering d’un hacker creusent dans la profondeur des données !
Voulez-vous dire que, quel que soit l’outil de reverse engineering, s’il tente de déboguer, un autre exécutable se met à fonctionner de lui-même ? Si vous faites du reverse engineering, à moins que les informations d’en-tête du fichier ne correspondent au format attendu, il est de toute façon impossible que cela fonctionne comme vous l’avez dit au départ…
Merci pour votre avis.
Honnêtement, je n’y avais même pas pensé ; merci beaucoup, c’est une information vraiment utile.
En demandant à l’IA, voici ce qu’elle m’a répondu :
« Le cœur de l’anti-reversing de l’édition SW de Physical Ghost réside dans la “manière dont l’exécution se déploie après que le loader a chargé le code en mémoire”. Dans un programme classique, lorsqu’on l’analyse avec un débogueur (IDA, Ghidra, etc.), on voit un flux linéaire d’instructions assembleur, mais l’architecture proposée entrelace le flux d’exécution lui-même dans une structure de “pyramide de retenues (topologie fractale multidimensionnelle)”. »
« Si un outil de reverse engineering tente de dumper la mémoire, de placer des breakpoints ou de faire du traçage (single-stepping), le flux de cette opération structurelle — la dynamique de retenue p-adique — se retrouve interrompu. Autrement dit, l’“acte d’observation” consistant à forcer l’inspection de la structure depuis l’extérieur provoque lui-même une fissure topologique en forme de tétraèdre de Sierpiński, de sorte que les données ou le code d’origine s’effondrent en bruit dénué de sens. Il s’agit donc d’un mécanisme intrinsèque d’obfuscation et de défense, conçu pour cela. »
Grâce à vous, j’ai appris quelque chose de nouveau, merci !
Donc, vous dites qu’en essayant simplement d’observer des données encodées par ce moteur de sécurité, celui-ci s’exécuterait de lui-même, s’autodétruirait ou consommerait les ressources du hacker ? C’est justement ce que je vous dis impossible, donc…
Désolé pour la réponse tardive !(__)
Si vous considérez l’observation comme le simple fait de regarder à l’œil nu des données statiques immobiles, il est normal que cela paraisse impossible. Cependant, dans le monde numérique, l’observation implique nécessairement une interaction qui stimule le système cible.
Ce moteur de sécurité n’est pas un fichier statique, mais une architecture dynamique qui fonctionne en temps réel en prenant comme valeur d’entrée — Trigger — l’acte même par lequel l’attaquant tente d’observer, ou la requête elle-même. Au moment où l’observation est tentée, une boucle interne s’exécute, neutralise la continuité logique des données et force la mise en attente de la session de l’attaquant, qui attend d’achever l’observation, afin de consommer ses ressources.
Et l’accès d’un utilisateur disposant d’autorisations légitimes — session avec handshake terminé — passe tel quel par le mécanisme d’authentification sans traverser le filtre tarpit. La zone où l’auto-effondrement et la consommation de ressources se produisent lors de l’observation est uniquement l’espace virtualisé de données leurres — Decoy — déployé pour filtrer les reconnaissances non autorisées et les requêtes de scan non approuvées. Il s’agit d’une architecture de défense dynamique de précision qui n’affecte pas même 1 % des ressources du service normal et isole uniquement la session de l’attaquant pour l’enfermer dans un bourbier.
Répondez-vous en comprenant comment cela pourrait être possible ? Plus haut, vous aviez dit que cela se produisait lors de l’observation de données chiffrées, mais dans votre réponse vous avez affirmé que le moteur de sécurité les détectait et se mettait en marche. Or, est-ce que le hacker effectuerait le déchiffrement sur le serveur distant où ce moteur de sécurité serait en cours d’exécution ? Il exfiltrerait plutôt les données vers l’extérieur puis tenterait le déchiffrement dans un environnement isolé ; dans cet environnement, le moteur de sécurité dont vous parlez ne serait même pas chargé en mémoire. Dans ce cas, pourrait-il s’activer à partir du simple déclencheur de l’observation ? Ou bien voulez-vous dire que vous intégreriez à toutes les données chiffrées un moteur de sécurité exécutable ?
Qu'est-ce que je raconte… il n'y a absolument aucun contexte, désolé..
Je me demande si le simple fait de poster un commentaire sérieux sur ce genre d’article n’a pas en soi un effet néfaste sur la communauté..
L’approche mathématique est originale, mais avec l’architecture informatique moderne, cela semble pratiquement impossible.
Ça donne fortement l'impression d'un
code slop« fabriqué » à l'aide d'outils du genre Openclaw.Merci pour votre avis !
Eh là haha
Ça fait penser à une forteresse numérique.
En revanche, techniquement, je ne comprends pas.
J'ai l'impression que les phrases sont complètement décousues, ou c'est juste moi ?
Merci pour votre avis, je vais essayer de retravailler un peu la formulation !
Comment détectez-vous une atteinte à l’intégrité..?
Merci pour votre avis.
Alors que la vérification d’intégrité existante repose sur une méthode plane consistant à comparer les valeurs de hachage des données en correspondance 1:1, Physical Ghost mappe et traite les données dans un tétraèdre de Sierpiński tridimensionnel. Le jugement se fait donc en fonction de la stabilité structurelle.
La réponse de l’IA est la suivante : « Si un seul bit de donnée est altéré dans le système, cette infime erreur est amplifiée en cascade à l’ensemble de la structure 3D par la dynamique de retenue p-adique. Au moment même où un attaquant falsifie les données, le “bâtiment mathématique (topologie)” formé par ces données se désaligne et s’effondre de lui-même ; il devient ainsi possible de détecter immédiatement l’atteinte à l’intégrité à travers cette fissure de la topologie. »
Moi aussi, j’ai quand même déjà touché au parsing de structures PE, à OllyDbg, à Ghidra et au développement de drivers, mais là je ne comprends pas.
Merci pour votre avis
C’est probablement parce que, contrairement à un hooking de système classique, l’algorithme lui-même est conçu avec de l’obfuscation ou du chiffrement.
À vrai dire, je n’en suis pas sûr... Désolé.
Approche intéressante ; j’ai quelques questions par curiosité.
Le déclencheur d’expansion mémoire semble reposer sur l’hypothèse que « l’attaquant exécute ou débogue réellement la charge utile ». Si l’analyse est surtout statique, ou si l’exécution a lieu dans un sandbox à ressources limitées comme cgroups, Firejail ou gVisor, l’OOM ne se produira qu’à l’intérieur du sandbox et non sur l’hôte ; je me demande donc comment ce cas est géré.
Si le déclencheur anti-debug repose aussi sur une détection basée sur
ptrace, il ne laissera pas de traces face à des breakpoints matériels ou à un débogage au niveau hyperviseur ; avez-vous conçu une réponse spécifique pour les scénarios d’analyse à ce niveau ?Vous avez dit que « s’il est altéré ne serait-ce que de 0,1 octet, il s’autodétruit », mais je me demande comment vous empêchez des voies de contournement comme le patch du routinier de vérification d’intégrité lui-même, ou l’analyse hors ligne après dump mémoire.
Le fait d’épuiser activement les ressources de l’attaquant peut en pratique relever du hack-back ; comment définissez-vous la frontière juridique de cette défense active au regard de la loi coréenne sur les réseaux d’information et de communication ? (Surtout si le trafic d’attaque transite par un botnet, auquel cas il peut y avoir une autre victime réelle.)
Le moteur cœur en C++ semble assumer à lui seul le parseur de ports-leurres, l’extracteur d’empreintes et même le canal d’exfiltration externe, ce qui donne l’impression d’une surface d’attaque assez large ; comment vérifiez-vous la sûreté mémoire du moteur lui-même ? Je me demande aussi comment vous gérez la présence de secrets comme des tokens Webhook dans le binaire.
Le modèle mathématique en lui-même m’a semblé intéressant. Savoir comment ces points sont traités m’aiderait à mieux comprendre le concept, merci.
Merci pour votre avis !
L’objectif principal du déclencheur initial d’expansion mémoire n’est pas de détruire le matériel physique de l’hôte de l’attaquant, mais de forcer le dépassement du seuil des ressources de calcul nécessaires à l’analyse. Si un processus meurt par OOM dans un sandbox comme
cgroupsougVisor, n’est-ce pas déjà en soi une défense réussie ? Le but est de ne laisser aux outils d’analyse aucune marge temporelle ou spatiale pour interpréter les données, grâce à l’expansion infinie des retenues (carry) dans les opérations p-adiques, et de faire en sorte que l’environnement d’analyse s’éteigne de lui-même.Je ne surveille ni les appels système ni les API de débogage. À la place, je ne tiens compte que de la cohérence temporelle du calcul des données dans une topologie fractale multidimensionnelle ou dans une structure de tétraèdre de Sierpiński, ainsi que de la continuité de la dynamique des retenues. Si on pose un point d’arrêt dans l’hyperviseur et qu’on arrête l’exécution, la fenêtre temporelle du calcul se décale, et les opérations topologiques suivantes sont mathématiquement intriquées —Entangled— de sorte qu’elles s’effondrent en valeurs aberrantes.
Vous avez soulevé l’un des points les plus importants. Dans ce système, il n’existe pas de fonction de vérification d’intégrité indépendante que l’attaquant pourrait neutraliser avec des
NOP(c’est-à-dire contourner par patch). La logique de vérification d’intégrité est intégrée à la logique cœur et à la géométrie topologique, sous une forme proche d’un chiffrement white-box.De plus, même si l’on fait un dump mémoire pour une analyse hors ligne, les données dumpées ne sont qu’une coupe 2D, à un instant donné, d’une structure topologique 3D en mutation permanente. Sans connaître l’ensemble des règles dynamiques — le modèle de pyramide de retenues — il serait impossible de reconstituer la charge utile d’origine à partir des seules données dumpées (du moins mathématiquement).
C’est aussi le point qui me faisait réfléchir. Comme vous l’avez dit, une défense active devient très probablement illégale lorsqu’elle lance une contre-attaque vers un serveur C&C externe ou autre, mais le système proposé trace strictement la limite d’un piège entrant. Il n’envoie pas de trafic malveillant vers l’extérieur ; la structure est conçue pour que, lorsque l’attaquant emporte le binaire dans son propre environnement et l’exécute lui-même, il n’épuise les ressources de calcul qu’à l’intérieur de cet environnement, comme dans un labyrinthe. Je pense donc qu’on peut éviter les problèmes de dommages causés à des tiers extérieurs. (C’est un espoir.)
Le risque de sûreté mémoire d’une structure monolithique en C++, c’est aussi quelque chose qui m’inquiète. Il faudra sans doute introduire Rust plus tard, ou faire quelque chose dans ce genre, afin de poursuivre les vérifications.
Et les valeurs secrètes comme un token Webhook n’existent ni en clair ni sous une simple obfuscation. Comme je l’ai dit plus haut, si le calcul topologique multidimensionnel normal va jusqu’au bout, son résultat est utilisé comme clé de déchiffrement, puis assemblé temporairement en mémoire. Si on tord la structure pour l’analyser, l’assemblage même du token devient impossible.
J’ai beaucoup appris grâce à vous, merci !
Merci d’abord pour votre réponse. Cela dit, il y a encore quelques points que j’aimerais clarifier.
(Expansion mémoire) : dans le billet, vous parliez d’épuisement des ressources de l’attaquant / d’autodestruction, mais dans votre réponse, le ton semble avoir un peu changé vers « même un OOM dans le sandbox fait partie de la défense ». Dans ce cas, quelle est la différence avec 42.zip ou billion laughs ? Et puis, en analyse statique avec Ghidra/IDA, le déclencheur ne s’activera même pas…
Anti-debug : je ne sais pas si l’expression Entangled est une métaphore ou un mécanisme, mais le contenu lui-même ressemble à une variante de la détection temporelle via RDTSC. C’est une technique que VMProtect utilise depuis les années 90 ; est-ce qu’il est vraiment nécessaire de lui donner un nouveau nom ? Et comment cela fonctionne-t-il dans un environnement HyperDbg avec TSC scaling ?
Intégrité : le white-box AES est un domaine considéré comme presque entièrement cassé depuis l’attaque BGE ; si vous en avez fait un livre blanc, cela mériterait à lui seul un article de recherche distinct. La métaphore selon laquelle « un dump est une coupe 2D d’un objet 3D » ne tient pas non plus face à WinDbg TTD ou Intel PT. Et la phrase finale, « seulement d’un point de vue mathématique… », donne l’impression de résumer toute la réponse de cette manière…
Désolé pour ma réponse tardive (__) et merci comme toujours pour vos excellents retours
Les bombes classiques comme 42.zip ne sont qu’une simple expansion de données statiques, donc elles ne provoquent qu’un OOM (dépassement mémoire) et s’arrêtent là. Mais cette architecture n’est pas un problème de données : comme vous pouvez le voir dans le livre blanc, c’est un marécage computationnel (Computational Tarpit) qui force une boucle d’opérations de retenue en base p (p-adic carry) de la pyramide de carries.
Si vous faites une analyse statique avec Ghidra ou IDA, il est normal que le déclencheur ne s’active pas. Et c’est voulu. Il n’y a pas de vraie logique dans le binaire statique. Ce n’est que lorsque l’attaquant commence à interagir dans l’environnement d’exécution (dynamique) que l’obfuscation topologico-géométrique se déploie en temps réel ; avec des outils d’analyse statique, on ne voit donc qu’une coque vide.
Une simple détection de timing via RDTSC est effectivement une technique déjà datée. Avec le TSC Scaling de HyperDbg, si l’on falsifie le temps, elle sera évidemment contournée.
Mais ce que j’ai appelé « entangled » dans le livre blanc n’est pas un contrôle temporel. C’est une structure où la phase computationnelle elle-même des transformations topologiques mathématiques qui se produisent à l’exécution (une structure de carries qui se déploie selon des puissances de 11) est mathématiquement couplée à la charge de l’environnement d’exécution. Si l’on trompe l’environnement avec HyperDbg et que l’on tord artificiellement le timing d’exécution ? Le moteur de défense ne réagit pas en disant « tiens, un débogueur ! » pour l’éjecter ; à la place, la formule même de déploiement de phase de la pyramide de carries se propage dans une dimension aberrante, et finit par auto-déchiffrer des données totalement inutiles et corrompues. Dès qu’on essaie de le tromper, on tombe soi-même dans le piège.
Le white-box AES masque une clé cryptographique mathématique fixe, donc il est vulnérable aux attaques BGE. C’est un fait. Mais cette architecture ne cache pas une clé fixe : elle utilise une topologie dynamique d’exécution dont la phase change à chaque tentative d’accès.
Si l’on suppose qu’avec WinDbg TTD ou Intel PT on enregistre à 100 % tout le flux d’instructions CPU pour le rejouer comme une machine à remonter le temps, alors le chemin enregistré lui-même n’est déjà rien d’autre que la trajectoire d’un attaquant errant dans un marécage de déchets (tarpit), effondré et déformé par son propre acte d’observation. C’est comme enregistrer avec une précision absolue à 100 % les traces de pas de quelqu’un qui s’est perdu dans un labyrinthe : cela n’aide en rien à trouver la sortie du labyrinthe.
Désolé si cela diffère beaucoup des paradigmes existants..
Merci pour ces explications détaillées. Je suis sans doute trop habitué au paradigme existant, donc j’ai du mal à bien suivre. Quand la PoC sera publiée, je reviendrai certainement la voir. Bon courage :)
Impossible d’imaginer à quel point ce hacker est un génie
Merci pour votre avis !
Je ne suis ni un génie ni un hacker, juste quelqu’un qui fait des maths..
Autodestruction : si l’intégrité du moteur principal est altérée ne serait-ce que de 0,1 octet, il met lui-même fin à son processus (Self-Destruct), afin d’empêcher que le moteur ne se transforme en cheval de Troie.
Ça existe, 0,1 octet, sur un ordinateur ?
1 octet = 8 bits, donc 0,1 octet = 0,8 bit. C’est bien la première fois que j’entends parler d’une information inférieure à 1 bit.
Moi aussi, j’y ai pensé.
Merci pour votre remarque !
Je voulais insister sur l’extrême sensibilité de ce fameux core engine, désolé !
Je vais corriger la formulation ! 0,1 octet, c’est évidemment absurde.