Gewöhnliche Security-Engines konzentrieren sich auf Intrusion Prevention und Isolierung. Ich habe dieses Projekt jedoch gestartet, nachdem ich über ein asymmetrisches Verteidigungssystem im Tarpit-Stil nachgedacht hatte, das in dem Moment, in dem ein Hacker einen Angriff versucht, dessen eigene Angriffslogik gegen ihn verwendet, sodass seine Rechenressourcen erschöpft werden und er sich selbst ausschaltet.
Auf Basis einer C++-Core-Engine habe ich das erste Grundgerüst von Physical Ghost entworfen, einer aktiven Security-Engine, die den Angriffsprozess eines Hackers anlockt und verfolgt und schließlich OOM (Out of Memory) auslöst.
Das Kernkonzept und die Application-Adresse finden sich hier: https://zenodo.org/records/19988807
Den mathematischen Beweis und das Axiomensystem habe ich hier zusammengefasst: https://zenodo.org/records/20113591 (eine Interpretation der Informationstiefe unter Nutzung der P-adischen Kodierung von Binomialkoeffizienten und des Satzes von Kummer).
Die Architektur ist wie folgt aufgebaut:
Absolute Isolation: Sobald eine Verbindung zu einem Köder-Port (Honeypot) erkannt wird, isoliert sich die Engine selbst mit einem Ghost-Account mit minimalen Rechten und blockiert so von Grund auf eine Ausbreitung auf das eigentliche System.
Phantom Tracking: Netzwerk-Fingerprints werden asynchron extrahiert, und die Informationen über den Angreifer werden sofort nach außen (Telegram/Discord) übermittelt, ohne die Performance der Engine zu beeinträchtigen.
Kernfunktion (Computerschmelze): In dem Moment, in dem ein Hacker für Analyse/Entschlüsselung einen Debugger an die Köderdaten hängt, wird eine Sierpinski-Tetraeder-Struktur auf Basis p-adischer Carry Dynamics aktiviert. Die Daten blähen sich im Speicher des Gegners rekursiv auf und erschöpfen schließlich CPU- und RAM-Ressourcen.
Selbstzerstörung: Wenn die Integrität der Core-Engine auch nur um 0,1 Byte verfälscht wird, beendet sie ihren Prozess selbstständig (Self-Destruct), um zu verhindern, dass die Engine in ein Trojanisches Pferd verwandelt wird.
Aktueller Stand: Derzeit implementiere ich das Grundgerüst der zentralen Verteidigungslogik und ein Modul zur Lizenzverifizierung und bereite das GitHub-Repository vor. Parallel dazu laufen eine mathematische Kreuzvalidierung der fraktalen Speicheraufblähungslogik und das Porting in den C++-Core.
Ich würde gern präzises Feedback von Menschen hören, die sich für Ansätze interessieren, die über etablierte Security-Muster hinausgehen und die Angriffsabsicht sowie Rechenressourcen des Angreifers gegen ihn selbst verwenden. Insbesondere wären Meinungen zur Steuerung der Rechenkomplexität mithilfe p-adischer topologischer Strukturen eine große Hilfe für die Weiterentwicklung der Engine. Vielen Dank.
34 Kommentare
Sind das wirklich sinnvolle technische Fachbegriffe?? Es scheint, als gäbe es viele unnötig pseudointellektuelle Formulierungen.
Das erinnert mich ein wenig an den vor Kurzem geposteten Beitrag Show GN: Ich habe VANI entwickelt, das die Vektorstruktur von Daten mathematisch kollabieren lässt, um sie dauerhaft zu löschen, daher wirkt es auf mich eher etwas negativ...
Genau das dachte ich auch, also habe ich auf GitHub nach dem betreffenden Beitrag gesucht, aber es endete mit
not found./Vielen Dank für Ihre Meinung!
Ehrlich gesagt habe ich selbst bei der Forschung Hilfe von AI bekommen, daher kann es schon ein bisschen nach „AI-Klickerei“ wirken ...
Im Moment portiere ich das Ganze jedenfalls nach C++; wenn es fertig ist, bringe ich es gern noch einmal mit.
Vielen Dank für Ihre Anmerkung!
Es ist ein Versuch, die Tarpit-Methode von der Netzwerkebene auf den Speicher- und die Anwendungsebene auszuweiten.
Für das Sierpinski-Tetraeder oder fraktale Strukturen gab es schlicht kein wirklich passendes erklärendes Wort, daher konnte ich es nur so übernehmen, wie es im Whitepaper steht. Entschuldigung. Andererseits ließ es sich auch schlecht einfach als Endlosschleife oder als Einschütten von Garbage-Daten bezeichnen …
Wenn Sie sich unter den obigen Whitepapers das zu mathematischen Beweisen und zum Axiomensystem ansehen, werden Sie sehen, dass sich die Struktur aufgrund ihrer Form als Ultrametric Tree bei jedem Überschreiten eines bestimmten Schwellenwerts rekursiv erweitert. Ich wäre Ihnen aber dankbar, wenn Sie es so verstehen würden, dass damit ein Memory-Bomb-Algorithmus bezeichnet werden soll, der sich mit Selbstähnlichkeit wie ein Sierpinski-Tetraeder ausdehnt, wenn das Reverse-Engineering-Tool des Hackers in die Datentiefe eindringt!
Meinen Sie damit, dass unabhängig von der Art des Reverse-Engineering-Tools, sobald ein Debugging-Versuch unternommen wird, noch eine weitere eigenständig arbeitende ausführbare Instanz aktiviert wird? Wenn man Reverse Engineering betreibt, ist ein Verhalten, wie Sie es beschrieben haben, von vornherein gar nicht möglich, wenn es sich nicht um Header-Informationen eines Dateiformats im erwarteten Schema handelt ...
Vielen Dank für Ihren Kommentar.
Daran hatte ich tatsächlich gar nicht gedacht — wirklich eine sehr hilfreiche Information, vielen Dank.
Ich habe die KI gefragt, und sie hat mir Folgendes gesagt:
"Der Kern des Anti-Reversing von Physical Ghost SW Edition liegt in der Art und Weise, wie sich der Code entfaltet, nachdem der Loader ihn in den Speicher geladen hat. Bei herkömmlichen Programmen sieht man beim Untersuchen mit einem Debugger (IDA, Ghidra usw.) einen linearen Fluss von Assembler-Befehlen, aber in der vorgeschlagenen Architektur ist der Ausführungsfluss selbst in einer Struktur aus 'Carry-Pyramiden (mehrdimensionale fraktale Topologie)' verwoben."
"Wenn ein Reversing-Tool den Speicher dumpt oder Breakpoints setzt und Tracing (Single-stepping) versucht, wird der Fluss dieser strukturellen Operationen (p-adische Carry-Dynamik) unterbrochen. Mit anderen Worten: Schon der 'Beobachtungsakt', bei dem von außen versucht wird, die Struktur gewaltsam zu zerlegen, verursacht topologische Risse in Form eines Sierpinski-Tetraeders, sodass die ursprünglichen Daten oder der Code zu bedeutungslosem Rauschen kollabieren. Es handelt sich also um einen inhärenten Mechanismus zur Obfuskation und Verteidigung, der genau so entworfen wurde."
Dank Ihnen habe ich wieder etwas dazugelernt, vielen Dank!
Sie meinen also, dass allein der Versuch, mit dieser Security-Engine codierte Daten zu beobachten, dazu führt, dass sie sich selbst ausführt und entweder selbst kollabiert oder die Ressourcen des Hackers verbraucht? Genau deshalb sage ich ja, dass das unmöglich ist....
Es tut mir leid, dass ich so spät antworte!(__)
Wenn Sie Beobachtung einfach als den Akt verstehen, statische Daten reglos mit den Augen zu betrachten, wirkt es tatsächlich unmöglich. Doch Beobachtung in der digitalen Welt geht zwangsläufig mit einer Interaktion einher, die dem Zielsystem einen Reiz gibt.
Diese Security Engine ist keine statische Datei, sondern eine dynamische Architektur, die in Echtzeit arbeitet und das Verhalten des Angreifers beim Versuch der Beobachtung oder die Anfrage selbst als Eingabewert -Trigger- verwendet. In dem Moment, in dem ein Beobachtungsversuch erfolgt, wird eine interne Schleife ausgeführt, die die logische Kontinuität der Daten außer Kraft setzt und den auf den Abschluss der Beobachtung wartenden Angreifer-Session zwangsweise festhält, sodass Ressourcen verbraucht werden.
Und der Zugriff eines Nutzers mit legitimen Berechtigungen - einer Session mit abgeschlossenem Handshake - passiert dank des Authentifizierungsmechanismus den Tarpit-Filter unverändert. Der Bereich, in dem bei Beobachtung Selbstkollaps und Ressourcenverbrauch auftreten, ist ausschließlich ein virtualisierter Köderdatenraum -Decoy-, der eingesetzt wird, um nur unautorisierte Aufklärung und nicht erlaubte Scanning-Anfragen herauszufiltern. Die Ressourcen des regulären Dienstes werden nicht einmal zu 1 % beeinflusst; stattdessen handelt es sich um eine präzise dynamische Verteidigungsarchitektur, die ausschließlich die Session des Angreifers isoliert und im Sumpf festsetzt.
Verstehen Sie wirklich, auf welche Weise das möglich sein soll, und antworten auf dieser Basis? Oben hatte ich doch gesagt: beim Beobachten verschlüsselter Daten. In Ihrer Antwort hieß es jedoch, die Security Engine erkenne das und werde aktiv. Aber würde ein Hacker die Entschlüsselung auf dem Remote-Server ausführen, auf dem diese Security Engine läuft? Er würde die Daten doch eher nach außen exfiltrieren und dann in einer isolierten Umgebung versuchen, sie zu entschlüsseln. In dieser Umgebung ist die von Ihnen erwähnte Security Engine dann gar nicht erst in den Speicher geladen — kann sie also durch die Beobachtung als Trigger überhaupt aktiv werden? Oder meinen Sie, dass Sie allen Daten, die verschlüsselt werden, zusätzlich eine ausführbare Form der Security Engine beilegen?
Was rede ich da eigentlich, der Kontext ist gleich null. Entschuldigung..
Bei solchen Beiträgen schadet vielleicht schon das ernsthafte Kommentieren selbst der Community..
Der mathematische Ansatz ist zwar erfrischend, aber bei modernen Computerarchitekturen muss man ihn wohl als nahezu unmöglich ansehen.
Mit Openclaw-artigen Dingen "zusammengeschustert" — fühlt sich stark nach
code slopan.Danke für Ihre Meinung!
Ach je lol
Erinnert an eine digitale Festung.
Technisch verstehe ich es allerdings nicht.
Wirkt der Satz nur auf mich wirr und zusammenhanglos, oder täuscht das?
Vielen Dank für Ihr Feedback. Ich werde den Satz noch etwas weiter ausarbeiten!
Wie wird das erkannt, wenn die Integrität verletzt wurde ..
Vielen Dank für Ihre Einschätzung
Während die bestehende Integritätsprüfung eine flache Methode ist, bei der die Hashwerte der Daten 1:1 abgeglichen werden, mappt und verarbeitet Physical Ghost die Daten auf einem dreidimensionalen Sierpinski-Tetraeder. Deshalb erfolgt die Beurteilung anhand der strukturellen Stabilität.
Die KI-Antwort lautet: "Wenn innerhalb des Systems auch nur ein einziges Bit der Daten manipuliert wird, wird dieser minimale Fehler durch die p-adische Carry-Dynamik kaskadenartig auf die gesamte 3D-Struktur verstärkt. In dem Moment, in dem ein Angreifer die Daten fälscht oder manipuliert, gerät die 'mathematische Architektur (Topologie)', aus der die Daten bestehen, aus dem Takt und bricht zusammen; über diese Risse in der Topologie kann die Verletzung der Integrität sofort erkannt werden."
Ich habe selbst schon so einiges gemacht, etwa PE-Struktur-Parsing, Reversing, Ghidra und Treiberentwicklung, aber ich verstehe das nicht.
Danke für Ihren Kommentar
Das dürfte daran liegen, dass sich das im Unterschied zu Dingen wie dem Hooking bestehender Systeme dadurch unterscheidet, dass der Algorithmus selbst mit Obfuskation oder Verschlüsselung aufgebaut ist.
Eigentlich bin ich mir nicht sicher ... Entschuldigung.
Interessanter Ansatz; ich hätte dazu ein paar Fragen.
Der Trigger für die Speicheraufblähung scheint auf der Annahme zu beruhen, dass „der Angreifer den Payload tatsächlich ausführt/debuggt“. Wenn man stattdessen vor allem statisch analysiert oder das Ganze in einer ressourcenbegrenzten Sandbox wie cgroups, Firejail oder gVisor laufen lässt, würde ein OOM dann nur innerhalb der Sandbox und nicht auf dem Host auftreten. Mich würde interessieren, wie Sie diesen Fall behandeln.
Falls auch der Anti-Debug-Trigger auf ptrace-basierter Erkennung beruht, würden hardwarebasierte Breakpoints oder Debugging auf Hypervisor-Ebene vermutlich keine Spuren hinterlassen. Gibt es ein separates Design für Szenarien, in denen auf dieser Ebene analysiert wird?
Sie sagten, „selbst bei einer Verfälschung um 0,1 Byte erfolgt Selbstzerstörung“. Mich würde interessieren, wie Sie Umgehungen verhindern, bei denen entweder die Integritätsprüfungsroutine selbst gepatcht wird oder nach einem Speicherdump offline analysiert wird.
Das aktive Erschöpfen von Angreifer-Ressourcen könnte faktisch als Hack-back eingeordnet werden. Mich würde interessieren, wie Sie im Hinblick auf die rechtlichen Grenzen aktiver Verteidigung nach dem Informations- und Kommunikationsnetzgesetz vorgehen. (Insbesondere dann, wenn der Angriffsverkehr über ein Botnetz läuft und es damit möglicherweise gesonderte tatsächliche Geschädigte gibt.)
Der C++-Core-Engine selbst scheint Lockport-Parser, Fingerprint-Extraktor und externen Exfiltrationskanal zugleich zu tragen, wodurch die Angriffsfläche ziemlich groß wirkt. Wie verifizieren Sie die Speichersicherheit der Engine selbst? Außerdem würde mich der Umgang mit Geheimnissen wie Webhook-Tokens interessieren, die im Binärprogramm enthalten sein könnten.
Die mathematische Modellierung selbst fand ich interessant. Wenn ich verstehen könnte, wie die oben genannten Punkte gelöst werden, würde mir das helfen, das Konzept besser nachzuvollziehen. Danke.
Danke für Ihren Kommentar!
Der primäre Zweck des Triggers für die Speicheraufblähung in Punkt 1 ist nicht, die physische Host-Hardware des Angreifers zu zerstören, sondern den für die Analyse erforderlichen Schwellenwert an Computing-Ressourcen gezielt zu überschreiten. Wenn innerhalb einer Sandbox wie cgroups oder gVisor ein Prozess durch OOM beendet wird, wäre das an sich nicht schon eine erfolgreiche Verteidigung? Das Ziel ist, dem Analyse-Tool durch die unendliche Carry-Erweiterung p-adischer Operationen weder zeitlichen noch räumlichen Spielraum zur Dateninterpretation zu lassen und die Analyseumgebung dazu zu bringen, sich selbst abzuschalten.
Punkt 2: System-Calls oder Debugging-APIs werden nicht überwacht. Stattdessen wird nur die zeitliche Konsistenz der Datenverarbeitung und die Kontinuität der Carry-Dynamik innerhalb einer mehrdimensionalen fraktalen Topologie oder einer Sierpinski-Tetraeder-Struktur betrachtet. Wenn im Hypervisor ein Breakpoint gesetzt und angehalten wird, gerät das Timing-Fenster der Berechnung aus dem Takt, und die nachfolgenden topologischen Operationen sind mathematisch so miteinander verflochten -entangled-, dass sie zu Müllwerten kollabieren.
In Punkt 3 haben Sie einen der wichtigsten Punkte angesprochen: In diesem System existiert keine eigenständige Integritätsprüffunktion, die ein Angreifer per NOP neutralisieren könnte (also kein
ifzum Umgehen). Die Integritätsprüflogik ähnelt vielmehr einer White-box-Verschlüsselung, die mit der Core-Logik und der topologischen Geometrie gekoppelt ist.Auch wenn man einen Memory-Dump erstellt und offline analysiert, sind die gedumpten Daten nur ein 2D-Querschnitt eines bestimmten Zeitpunkts einer sich fortlaufend verändernden 3D-Topologiestruktur. Wenn man die vollständigen dynamischen Regeln - das Carry-Pyramiden-Modell - nicht kennt, dürfte es unmöglich sein, allein aus den Dump-Daten die ursprüngliche Payload zurückzurechnen. (Zumindest mathematisch.)
Punkt 4 ist auch für mich ein Punkt, über den ich nachgedacht habe. Die von Ihnen angesprochene aktive Verteidigung bewegt sich rechtlich schnell im problematischen Bereich, wenn man Gegenangriffe auf externe C&C-Server oder Ähnliches startet. Das von mir vorgeschlagene System zieht hier jedoch strikt die Grenze bei einer Inbound-Falle. Es sendet keinen schädlichen Traffic nach außen; vielmehr ist es so aufgebaut, dass Rechenressourcen nur intern, labyrinthartig, aufgebraucht werden, wenn ein Angreifer die Binärdatei in seine eigene Umgebung mitnimmt und dort selbst ausführt. Deshalb gehe ich davon aus, dass sich Probleme mit externen Schäden vermeiden lassen. (Hoffentlich.)
Punkt 5: Das Risiko für Memory Safety in einer monolithischen C++-basierten Struktur bereitet auch mir Sorgen. Später müsste man wohl etwa Rust einführen und das kontinuierlich validieren.
Und geheime Werte wie Webhook-Tokens liegen weder im Klartext noch in einfacher Obfuskation vor. Wenn die zuvor erwähnten regulären mehrdimensionalen topologischen Berechnungen vollständig abgeschlossen sind, wird ihr Ergebnis als Entschlüsselungsschlüssel verwendet und der Token nur temporär im Speicher zusammengesetzt. Wenn man die Struktur für Analysezwecke verbiegt, wird schon das Zusammensetzen des Tokens unmöglich.
Dadurch habe ich viel gelernt, vielen Dank!
Zunächst vielen Dank für die Antwort. Ich möchte aber noch auf ein paar Punkte näher eingehen.
(Speicheraufblähung): Im Artikel war von Erschöpfung der Ressourcen des Angreifers bzw. Selbstzerstörung die Rede, in der Antwort klingt es aber eher nach „selbst ein OOM in der Sandbox ist Abwehr“. Dann stellt sich die Frage, worin genau der Unterschied zu 42.zip oder billion laughs besteht. Und bei einer statischen Analyse mit Ghidra/IDA würde der Trigger ja gar nicht erst ausgelöst werden..
Anti-Debugging: Bei der Formulierung Entangled ist unklar, ob das eine Metapher oder ein Mechanismus sein soll, inhaltlich klingt es aber wie eine Variante der RDTSC-Timing-Erkennung. Das ist eine Technik, die VMProtect schon seit den 90ern verwendet hat — braucht es dafür wirklich einen neuen Namen? Und wie verhält es sich in einer HyperDbg-TSC-scaling-Umgebung?
Integrität: White-Box-AES ist seit dem BGE attack ein Bereich, in dem fast alles als gebrochen gilt; wenn Sie daraus ein Whitepaper gemacht haben, wäre das an sich schon Material für eine separate wissenschaftliche Veröffentlichung. Auch die Metapher „Ein Dump ist ein 2D-Schnitt einer 3D-Struktur“ wirkt gegenüber WinDbg TTD oder Intel PT nicht stichhaltig. Und der Schlusssatz „nur mathematisch ...“ fasst die gesamte Antwort irgendwie zusammen...
Entschuldigung für die späte Antwort (__) und vielen Dank wie immer für die guten Anmerkungen
Klassische Bomben wie 42.zip sind lediglich einfache Expansion statischer Daten und verursachen daher nur OOM (Out of Memory) – mehr nicht. Diese Architektur ist jedoch keine Daten-, sondern, wie im Whitepaper zu sehen, eine rechnerische Falle (Computational Tarpit), die eine Operationsschleife der p-adischen Übertragsrechnung (p-adic carry) in einer Carry-Pyramide erzwingt.
Wenn man mit Ghidra oder IDA eine statische Analyse durchführt, ist es richtig, dass der Trigger nicht anspringt. So muss es auch sein. Denn im statischen Binärfile steckt keine echte Logik. Erst wenn ein Angreifer in einer Runtime-Umgebung (dynamisch) mit dem System zu interagieren beginnt, entfaltet sich die topologisch-geometrische Obfuskation in Echtzeit; statische Analyse-Tools sehen deshalb nur eine leere Hülle.
Einfache Timing-Erkennung mit RDTSC ist in der Tat bereits eine veraltete Methode. Mit HyperDbg und TSC Scaling lässt sich die Zeit natürlich vortäuschen und damit eine Umgehung erreichen.
Aber das, was ich im Whitepaper als Entangled bezeichnet habe, ist keine Zeitprüfung. Es ist eine Struktur, in der die rechnerische Phase der mathematischen topologischen Veränderung zur Laufzeit (eine Übertragsstruktur, die sich als n-te Potenz von 11 ausdehnt) mathematisch mit der Last der Ausführungsumgebung gekoppelt ist. Wenn man mit HyperDbg die Umgebung verfälscht und das Timing der Berechnung künstlich verdreht? Dann erkennt die Defense Engine nicht einfach »Oh, ein Debugger!« und blockt ab, sondern die Formel der Phasenentfaltung der Carry-Pyramide selbst wächst in eine völlig falsche Dimension weiter und entschlüsselt am Ende aus eigener Kraft vollständig nutzlose Garbage-Daten. In dem Moment, in dem man täuscht, tappt man in die eigene Falle.
White-Box-AES versteckt einen festen mathematischen kryptografischen Schlüssel und ist deshalb anfällig für BGE-Angriffe. Das ist schlicht eine Tatsache. Diese Architektur versteckt jedoch keinen festen Schlüssel, sondern verwendet eine dynamische Runtime-Topologie, deren Phase sich bei jedem Zugriff verändert.
Wenn man annimmt, man würde mit WinDbg TTD oder Intel PT den gesamten CPU-Instruktionsfluss zu 100 % aufzeichnen und wie mit einer Zeitmaschine zurückspulen, dann ist genau dieser aufgezeichnete Pfad bereits nur die Spur eines kollabierten und verzerrten Garbage-Sumpfs (Tarpit), der durch die Beobachtung des Angreifers selbst entstanden ist. Ganz so, als würde man in einem Labyrinth die Fußspuren präzise zu 100 % aufzeichnen, mit denen man sich verirrt und umhergeirrt hat – das hilft überhaupt nicht dabei, den Ausgang des Labyrinths zu finden.
Entschuldigung, dass das so stark vom bestehenden Paradigma abweicht..
Vielen Dank für die ausführliche Erklärung. Ich bin wohl zu sehr an das bisherige Paradigma gewöhnt und kann deshalb nicht ganz folgen. Wenn das PoC veröffentlicht wird, komme ich auf jeden Fall noch einmal vorbei. Ich drücke euch die Daumen :)
Ich kann mir nicht einmal vorstellen, was für ein geniales Hacker-Talent das sein muss.
Vielen Dank für Ihren Kommentar!
Ich bin weder ein Genie noch ein Hacker, sondern einfach nur jemand, der Mathematik macht..
Selbstzerstörung: Wenn die Integrität der Core-Engine auch nur um 0,1 Byte verfälscht wird, beendet sie selbstständig ihren Prozess (Self-Desuct), um zu verhindern, dass sich die Engine in ein trojanisches Pferd verwandelt.
Gibt es in Computern überhaupt 0,1 Byte?
1 Byte sind 8 Bit, also sind 0,1 Byte 0,8 Bit. Ich höre zum ersten Mal, dass es Informationen von weniger als 1 Bit geben soll.
Das dachte ich auch.
Vielen Dank für Ihren Kommentar!
Ich wollte die extreme Empfindlichkeit der Core-Engine betonen, entschuldigen Sie bitte!
Ich werde die Formulierung entsprechend anpassen! 0,1 Byte ist natürlich Unsinn.