Technische Details · Version 1.29.0
Für alle, die hinter die Produktaussagen sehen wollen. Zu jeder Zahl steht die Messreihe, das Verfahren und die Stichprobe. Zu jeder Schutzebene steht, wie sie arbeitet und wofür sie gebaut ist — damit Sie vergleichen können, statt glauben zu müssen.
Kurz vorwegNeun Schutzebenen, drei Schutzstufen, vier Annotationen — und drei Messreihen, die Sie an den ausgelieferten Dateien selbst nachrechnen können. Alles, was hier steht, steht auch im Handbuch oder im Bericht.
Dafür arbeiten die Ebenen 01 bis 05 und 07 zusammen: Code-Morphing und Kontrollflussverflachung, ChaCha20-Verschlüsselung des geschützten Bereichs, seitenweise Entschlüsselung erst beim Zugriff, Wiederverschlüsselung nach kurzer Zeit und der Verzicht auf zusammenhängendes Schlüsselmaterial in der Datei.
Dafür sorgen die Ebenen 02, 06 und 09: das Prüfergebnis fließt in den Schlüssel statt in eine Abbruch-Verzweigung, der Schlüssel ist an das Chiffrat gebunden, die Reaktion ist verzögert und randomisiert, und der Prozess erschwert fremde Speicherzugriffe.
Dafür gibt es vier Annotationen und drei Schutzstufen. Ebene 08 übersetzt genau die Funktionen, die Sie markieren — und genau die Konstrukte, die sie sicher übersetzen kann.
Neun Schutzebenen
CitadelCore setzt eine Ebene tiefer an als ein Packer: im Compiler, auf der LLVM-Zwischendarstellung. Es gibt keine Hülle, die sich abziehen ließe. Die Analyse fand keinen Standard-Packer-Fingerprint. Zu jeder Ebene steht unten, wie sie arbeitet, was dazu gemessen wurde und wofür sie gebaut ist.
Die Form, die Analysewerkzeuge sehen, entspricht nicht mehr Ihrer Quelle.
Äquivalente, aber unübersichtliche Instruktionsformen, eingestreute undurchsichtige Prädikate und Kontrollflussverflachung. Der Anteil der Substitutionen hängt von der Schutzstufe ab: 25 Prozent bei fast, 50 bei balanced, 90 bei max. Der Kontrollfluss bleibt korrekt.
Die Analyse fand Kontrollflussverflachung in allen Anwendungsfunktionen: einen Zustandsautomaten mit 32-Bit-Konstanten statt gewöhnlicher Verzweigungen, in main elf Zustandswerte.
Die Sicherheit hängt am Schlüssel, nicht an der Geheimhaltung des Verfahrens — so ist ein Decrypt-to-Execute-Verfahren gebaut. Die Maschinerie darf sichtbar sein; verschlossen bleibt der Inhalt.
Ein einziges verändertes Byte macht den ganzen Block unbrauchbar — nicht nur ein Zeichen.
Geschützter Code und Zeichenketten liegen als ChaCha20-Chiffrat in der Datei. Ein Hash über den Chiffretext wird mit einer gespeicherten Konstante verknüpft und fließt in den Entschlüsselungsschlüssel ein. Dadurch ist jeder Block an sein eigenes Chiffrat gebunden.
Die Analyse hat die Chiffre als ChaCha20 mit dem Zustandslayout nach RFC 8439 identifiziert; die Chiffrekonstante liegt maskiert in der Datei, eine Signatursuche ergab null Treffer. Zur Kopplung nennt das Handbuch eine Messung an einem gekippten Chiffratbyte: ohne Kopplung 1 von 8 160 veränderten Klartextbytes, mit Kopplung 8 130 von 8 160.
Eine Schlüsselkopplung statt eines separaten Tag-Felds: dieselbe Wirkung, ohne zusätzliche Metadaten in der Datei. Sie stoppt den blinden Byte-Angriff, der in der Praxis der häufigste ist.
Entschlüsselter Code bleibt nur kurz entschlüsselt.
Ein entschlüsselter Bereich wird nach einem Intervall wieder verschlossen — auf Stufe max nach 25 ms mit Wahrscheinlichkeit 1/6, auf balanced nach 30 ms mit 1/8. Eine Mindestverweildauer von 40 ms verhindert das Pendeln zwischen Sperren und Entsperren. Die Wiederverschlüsselung erzeugt ein anderes Chiffrat als das auf der Platte.
Die Analyse hat den geschützten Bereich aus einem Beobachterprozess abgetastet: in 28 735 von 28 854 Stichproben lag er verschlüsselt vor — 99,6 Prozent. Die wenigen Klartextfenster dauerten im Median 0,089 ms und lagen ausschließlich in der letzten Millisekunde vor Prozessende.
Ausführender Code muss kurz entschlüsselt vorliegen — das gilt für jedes Verfahren dieser Art. Hier ist dieses Fenster auf 0,27 ms je Lauf zusammengedrückt und liegt am Laufzeitende.
Laufzeitmessungen über dem Programm liefern Streuung statt Signal.
An Funktionseinstiegen werden Verzögerungen eingestreut: auf Stufe max bei jedem zwanzigsten Eintritt, höchstens 200 µs. Ein prozessweites Budget von 200 Verzögerungen je Sekunde deckelt den Zeitverlust unabhängig von der Aufrufhäufigkeit.
Die Analyse hat über 60 Läufe einen Median von 12,8 ms bei einer Standardabweichung von 1,5 ms gemessen und konnte keinen Zeitseitenkanal zwischen richtigen und falschen Eingaben feststellen. Auch über Eingabelängen von 0, 21 und 4 096 Zeichen war kein Unterschied messbar.
Wirkt gegen Zeitmessung von außen. Für Einzelschrittausführung mit vollen Rechten sind die Ebenen 02, 05 und 09 zuständig.
Entschlüsselt wird erst beim tatsächlichen Zugriff, seitenweise.
Der geschützte Codebereich liegt im Ruhezustand ohne Zugriffsrechte. Beim Zugriff werden die Rechte kurz geöffnet, die Seite in place entschlüsselt, der Befehlscache geleert und die alten Rechte wiederhergestellt. Es entsteht keine zweite, entpackte Kopie.
Die Analyse hat im Ruhezustand den Zustand ohne Leserechte beobachtet: ein Leseversuch von außen schlug fehl. Ein Scan des gesamten Prozessadressraums über 50 Durchläufe fand außer Thread-Stacks keine privat belegte ausführbare Region. Der klassische Abzug einer entpackten Kopie greift hier nicht.
Zusammen mit Ebene 03 bestimmt das, wie lange eine Seite offen steht. Wer Speicherabzüge höher gewichtet als Geschwindigkeit, zieht die Obergrenze über CITADEL_MAX_OPEN enger.
Es gibt keine Abbruch-Verzweigung, die man herausoperieren könnte.
Das Prüfergebnis fließt in das Schlüsselmaterial ein, statt eine Bedingung zu setzen. Die Reaktion ist nicht an einer Stelle gebündelt, sondern an jeder Fundstelle eingebettet; die Beendigung folgt verzögert und mit wechselndem Rückgabewert, damit ein Angreifer kein verlässliches Rückmeldesignal erhält.
Die Produktdokumentation nennt fünf definierte Patch-Versuche an einem Artefakt: früher 5 von 5 erfolgreich, heute 0 von 5. Die Analyse hat mit anderem Aufbau sieben Versuche unternommen — kein einziger führte zu lesbarem Klartext. Änderungen in verschlüsselten Bereichen erkannte sie in 12 von 12 Läufen sofort.
Selbst wer Prüfpfade abschaltet, gewinnt nichts: der Erfolgstext existiert nicht als Datum, das sich freischalten ließe. Genau das hat die Blackbox-Analyse mit sieben Versuchen durchgespielt.
Kein Schlüssel steht als zusammenhängende Konstante in der Datei.
Jedes Schlüsselbyte entsteht über Tabellenindirektion aus zwei mathematisch unabhängigen Anteilen, die anschließend verknüpft werden. Dazu kommen weitere Beiträge, unter anderem ein Hash über das Integritätsregister, ein Manipulationsakkumulator, ein Hash über den Chiffretext und eine eigene Nonce je Fundstelle. Die Rekonstruktionspuffer werden nach Gebrauch überschrieben.
Die Analyse hat die Zusammensetzung aus sechs unabhängigen Beiträgen nachvollzogen und festgestellt, dass der Schlüssel an keiner Stelle der Datei als zusammenhängende Konstante existiert. Auf 40 Entschlüsselungsaufrufe kamen 39 Löschaufrufe. Der Versuch, Schlüsselmaterial im Speicher zu finden, scheiterte.
Wer mit Hardware-Watchpoints mitverfolgt, erreicht bestenfalls einen Sitzungsschlüssel — nicht das Wurzelgeheimnis, denn das liegt beim Anwender und nicht in der Datei.
Markierte Funktionen entstehen gar nicht erst als Maschinencode.
Mit citadel_virtualize übersetzt der Compiler die Funktion in Bytecode für einen mitgelieferten Interpreter. Die Opcode-Zuordnung wird je Build aus dem Seed neu erzeugt, sodass ein Entvirtualisierer für einen Build beim nächsten nicht mehr passt. Unterstützt werden 1, 8, 16, 32 und 64 Bit, vorzeichenbehaftet und vorzeichenlos, bis zu 16 Argumente, dazu lokale Felder, deren Adresse die Funktion nicht verlässt.
Jede Übersetzung wird vor dem Einsatz geprüft: dieselbe Funktion wird auf der Zwischendarstellung und als Bytecode durchgerechnet. Belegt sind 150 676 Vergleiche über alle Bitbreiten, 120 042 für Speicherzugriffe und 26 698 über kleine Wertebereiche — jeweils null Abweichungen. Weicht ein Ergebnis ab, wird die Virtualisierung verworfen und die Funktion bleibt nativ. Ein absichtlich eingebauter Übersetzungsfehler wurde dadurch erkannt.
Gezielt auf markierte Funktionen: ganzzahlige Arithmetik, Logik, Vergleiche, Verzweigungen, Schleifen und lokale Felder. Alles andere meldet der Compiler im Bericht und lässt es nativ, statt still falsch zu rechnen — der Grund, warum sich der Mechanismus produktiv einsetzen lässt. Gedacht für Lizenzprüfung, Schlüsselableitung und Kryptokerne; der Interpreter mag sichtbar sein, das Programm darin nicht.
Der bequeme Weg über OpenProcess wird versperrt.
Auf Stufe max setzt der Prozess sich eine leere Zugriffsliste. Eine leere Liste erlaubt niemandem etwas — sie ist nicht dasselbe wie eine NULL-Zugriffsliste, die jedem alles erlauben würde. Ohne Handle gibt es kein ReadProcessMemory.
Das Handbuch nennt eine Messung mit einem eigenen Leseprogramm gegen denselben Prozess: ohne Härtung 64 Byte gelesen, mit Härtung OpenProcess verweigert mit Fehler 5.
Versperrt den bequemen Weg über OpenProcess im Rechtekontext des Nutzers. Weil dieselbe Sperre auch Absturzberichte und Profiler betrifft, schalten Sie sie für Diagnosebuilds gezielt ab — die übrigen acht Ebenen bleiben aktiv.
Dazu kommen Kontrollflussverflachung, Verschlüsselung beim Bauen und Metadaten-Härtung. Diese Maßnahmen zählt die Produktdokumentation nicht als eigene Ebene.
Ebene 08 · nur auf Anforderung
Markierte Funktionen werden nicht in Maschinencode übersetzt, sondern in Bytecode für einen mitgelieferten Interpreter. In der fertigen Datei stehen dann ein Aufruf des Interpreters und ein Feld undurchsichtiger Bytes. Sie entscheiden, welche Funktionen hineingehen.
__attribute__((annotate("citadel_virtualize")))
int check_license(int key_hi, int key_lo) { /* ... */ }Zwei AbsicherungenJede Übersetzung wird vor dem Einsatz geprüft: dieselbe Funktion läuft einmal auf der Zwischendarstellung und einmal als Bytecode, über etwa 400 Zufallswerte, alle Kombinationen von 20 Randwerten und kleine Werte für Schleifen und Verzweigungen. Weicht ein Ergebnis ab, wird die Virtualisierung verworfen und die Funktion bleibt nativ. Die Opcode-Zuordnung wird je Build aus dem Seed neu gewürfelt, sodass ein Entvirtualisierer für einen Build beim nächsten nicht mehr passt.
Was die VM übernimmtGanzzahlige Arithmetik, Logik, Vergleiche, Verzweigungen, Schleifen und lokale Felder — also genau den Zuschnitt von Lizenzprüfungen, Schlüsselableitungen und Kryptokernen. Alles Übrige bleibt nativ und damit schnell; der Compiler vermerkt es im Bericht, statt es stillschweigend anders zu übersetzen. Für heiße Pfade ist ohnehin citadel_hot der richtige Schalter.
Weitere Maßnahmen
Neben IsDebuggerPresent prüft CitadelCore das Kennzeichen im Prozessumgebungsblock direkt aus dem Speicher, dessen globale Kennungen, Hardware-Breakpoints in den Debug-Registern und zwei Kernel-Abfragen über NtQueryInformationProcess. Die Funktionen werden zur Laufzeit aufgelöst und stehen nicht in der Importtabelle. Die Analyse hat sechs unabhängige Indikatoren vorgefunden.
Reichweite: Sechs unabhängige Indikatoren statt eines einzelnen API-Aufrufs. Für den Weg ganz ohne Debugger ist Ebene 09 zuständig.
Sektionsnamen, Symbolnamen, Opcode-Zuordnungen und Schlüsselmaterial entstehen je Übersetzungslauf neu. Mit CITADEL_SEED wird der Lauf reproduzierbar, mit --seed random ausdrücklich nicht.
Reichweite: Wer zwei Releases vergleicht, findet keine gemeinsamen Muster, und ein Entvirtualisierer für eine Fassung ist bei der nächsten wertlos.
Keine Produktnamen in Sektionen oder Symbolen, keine verräterischen Importe. Die Analyse fand null Krypto-Importe, 58 für eine MinGW-Anwendung plausible Importe und keine Packer-Signatur.
Reichweite: Für signaturbasierte Scanner unauffällig. Dass die Datei überhaupt geschützt ist, soll sie nicht verbergen — verborgen bleibt, womit und wie.
Bei jedem Übersetzen werden neun Zusicherungen an der fertigen Datei nachgemessen: Manifest vorhanden, mindestens ein prüfbarer Bereich, Bindemaske eingetragen, Codesektion gepackt, hohe Entropie, keine Produktspuren, keine verräterischen Importe, keine Klartext-Zeichenketten der Anwendung und mindestens ein geprüfter Bereich außerhalb des eigenen Codes. Schlägt eine fehl, wird die Datei gelöscht und der Build bricht ab.
Reichweite: Lieber keine Datei als eine, die aussieht wie geschützt und es nicht ist.
Mit CITADEL_SECRET beim Bauen und citadel_rt_set_secret in der Anwendung fließt ein Wert von außen in den Schlüssel ein — aus einer Datei, einem Gerätemerkmal, einer Eingabe oder Ihrer Kundendatenbank. Ohne den richtigen Wert entschlüsselt die Datei falsch; es gibt keine Prüfung, die man entfernen könnte. Seit 1.28 bleibt der Aufruf folgenlos, wenn beim Bauen kein Geheimnis gesetzt war, statt den Schlüssel zu verderben.
Reichweite: Ohne das Geheimnis ist eine weitergegebene Kopie wertlos. Hilfetexte, die vorher lesbar bleiben sollen, markieren Sie mit citadel_public — dafür ist die Markierung da.
Steuerung im Quellcode
Ohne Annotation werden main, WinMain, wWinMain,wmain, DllMain und die CRT-Einstiegspunkte immer geprüft, dazu eine erzwungene Mindestabdeckung der übrigen Funktionen.
__attribute__((annotate("citadel_public"))) // Text bleibt lesbar
__attribute__((annotate("citadel_hot"))) // von der Härtung ausnehmen
__attribute__((annotate("citadel_protect"))) // garantiert prüfen
__attribute__((annotate("citadel_virtualize"))) // in Bytecode übersetzencitadel_public | Hilfetexte bleiben lesbar, auch wenn mit Freischaltgeheimnis gebaut wurde. |
|---|---|
citadel_hot | Heiße Pfade bleiben unangetastet und damit voll schnell. |
citadel_protect | Die Funktion erhält garantiert Manipulationsprüfungen. |
citadel_virtualize | Die Funktion wird in Bytecode übersetzt — der stärkste verfügbare Schutz. |
| Stufe | Substitution | Jitter | Prüfabdeckung | Fluktuation |
|---|---|---|---|---|
fast | 25 % | aus | 25 % und Einstiegspunkte | aus |
balanced | 50 % | 1/50, höchstens 150 µs | 70 %, mindestens 50 % | 30 ms, 1/8 |
max | 90 % | 1/20, höchstens 200 µs | 100 % | 25 ms, 1/6 |
Auf jeder Stufe aktiv: Verschlüsselung der Zeichenketten, Entschlüsselung bei Bedarf und White-Box-Schlüssel. Befehle: citadel --compile, citadel --info, citadel --doctor, citadel --test, citadel --version, citadel --help.
Voraussetzungen
„Gemessen“ heißt an Artefakten oder Messreihen nachgewiesen, „dokumentiert“ heißt im Handbuch beschrieben, „auf Anfrage“ heißt: besprechen wir gern direkt mit Ihnen.
| Betriebssystem dokumentiert | Windows 10 oder neuer, 64 Bit.Beleg: PRODUCT.md, Systemvoraussetzungen |
|---|---|
| Architektur gemessen | x86-64. Die ausgelieferten Artefakte sind PE32+ für x86-64.Beleg: eigene Messung an licensing_demo_protected.exe |
| Sprache C dokumentiert | Endung .c — verifiziert.Beleg: WINDOWS.md, Abschnitt 4 |
| Sprache C++ dokumentiert | Endungen .cpp .cc .cxx .c++ .C — verifiziert, einschließlich Klassen, Templates und STL. Für die Auslieferung statisch binden.Beleg: WINDOWS.md Abschnitt 4; FAQ.md |
| Weitere Sprachen nicht unterstützt | Objective-C und Objective-C++ werden erkannt. Rust, Swift und Zig deckt der Wrapper nicht ab.Beleg: WINDOWS.md, Abschnitt 4 |
| Ausgabeformat EXE gemessen | Ausführbare Dateien — der dokumentierte und gemessene Normalfall.Beleg: README.md, WINDOWS.md; eigene Messung an den Demo-Artefakten |
| Ausgabeformat DLL auf Anfrage | DllMain gehört zu den Einstiegspunkten, die immer geprüft werden. Für DLL-Projekte stimmen wir das Vorgehen gern vorab mit Ihnen ab.Beleg: WINDOWS.md, Abschnitt 6 |
| Quellcode dokumentiert | CitadelCore ersetzt Ihren Compileraufruf und arbeitet auf dem LLVM-Bitcode Ihres Projekts.Beleg: WINDOWS.md Abschnitt 3; README.md |
| Toolchain dokumentiert | Das Installationsprogramm prüft die Voraussetzungen, rüstet Fehlendes selbst nach, baut Werkzeug und Laufzeitbibliothek und weist mit einem Selbsttest nach, dass alles läuft.Beleg: README.md; WINDOWS.md, Abschnitt 1 |
| Betriebsart unter Windows dokumentiert | Ein eigenständiges Härtungswerkzeug auf LLVM-Bitcode statt eines Compiler-Plugins — technisch die saubere Lösung unter Windows. Für Sie ändert das nichts am Aufruf.Beleg: WINDOWS.md, Abschnitt 3 |
Messwerte · Version 1.29
Drei getrennte Messreihen, jede für sich nachvollziehbar: die Produktdokumentation, eine Blackbox-Analyse und eigene Messungen an den ausgelieferten Artefakten.
Quelle: CitadelCore 1.29.0 — PRODUCT.md, WINDOWS.md, FAQ.md
Programm: wechselnd; je Messwert angegeben
Werte aus dem ausgelieferten Handbuch. Welches Programm und welches Verfahren hinter jeder Zahl steht, zeigt die Tabelle.
Quelle: Blackbox-Analyse im Auftrag von AetherSec, werkzeuggestützt mit IDA Pro
Datum: 27.09.2026
Programm: licensing_demo_protected.exe, 88 576 Byte
Prüfsitzung von rund 23 Minuten, statisch und dynamisch, mit IDA Pro und eigenen Python-Werkzeugen. Die Informationsquelle war ausschließlich die fertige geschützte Datei — dieselbe Ausgangslage wie bei einem Angreifer ohne Quellcode.
Quelle: AetherSec, Dateianalyse im Zuge dieses Website-Umbaus
Datum: 14.10.2026
Programm: licensing_demo.exe gegen licensing_demo_protected.exe
Reine Dateianalyse, deshalb systemunabhängig und mit denselben Mitteln reproduzierbar. Stichprobengröße ist jeweils ein Artefaktpaar.
| Messgröße | ohne Härtung | mit Härtung | Messreihe | Version | Geprüfter Bereich | Messverfahren | Stichprobe | Einordnung |
|---|---|---|---|---|---|---|---|---|
| Entropie des geschützten Codebereichs | 5,45 | 7,89 | Produktdokumentation 1.29 | 1.29 | geschützter Codebereich laut Produktdokumentation | — | — | Angabe aus der Produktdokumentation, übliche Einheit Bit je Byte. Eigene Messung am Demopaket siehe nächste Zeile. |
| Entropie des geschützten Codebereichs | 6,333 Bit je Byte (.text, 28 392 Byte) | 7,934 Bit je Byte (.crt2, 4 047 Byte) | Eigene Messung an den ausgelieferten Artefakten | 1.29.0 | Sektion .text der Referenz gegen Sektion .crt2 der geschützten Fassung | Shannon-Entropie über die Rohbytes der Sektion | 1 Artefaktpaar | Vergleicht zwei unterschiedlich große Bereiche: die gesamte Codesektion der Referenz gegen die verschlüsselte Schutzsektion. Die Werte decken sich mit der Sektionstabelle der Analyse. |
| Entropie der gesamten Datei | 5,913 Bit je Byte | 6,856 Bit je Byte | Eigene Messung an den ausgelieferten Artefakten | 1.29.0 | gesamte Datei | Shannon-Entropie über alle Bytes der Datei | 1 Artefaktpaar | Die geschützte Fassung enthält zusätzlich die Laufzeitbibliothek und die verschlüsselten Bereiche. |
| Konstanten der Prüf- und Ableitungsfunktionen im Dateiabbild | 11 Treffer über sechs Konstanten | 0 Treffer | Eigene Messung an den ausgelieferten Artefakten | 1.29.0 | vier mit citadel_virtualize markierte Funktionen | Suche nach jedem 32-Bit-Wert in Little-Endian-Darstellung über die gesamte Datei | 6 Konstanten, 1 Artefaktpaar | Gilt für Funktionen, die der Virtualisierungspass annimmt; dort entsteht der Maschinencode gar nicht erst. |
| Konstanten der Lizenzprüfung im Disassembler | 3 | 0 | Produktdokumentation 1.29 | 1.29 | Testprogramm mit Schlüsselkonstanten 0x1F2E3D4C, 0x5B6A7988 und 0x4D2 | Sichtprüfung im Disassembler | 3 Konstanten | Gilt für virtualisierte Funktionen. |
| Meldungstexte der Lizenzlogik im Klartext | 4 von 4 lesbar | 0 von 4 lesbar | Eigene Messung an den ausgelieferten Artefakten | 1.29.0 | Texte ACCESS GRANTED, Invalid licence., Malformed serial., Flag: | Suche nach der Zeichenfolge über die gesamte Datei | 4 Texte, 1 Artefaktpaar | Banner und Gebrauchsanweisung bleiben absichtlich lesbar — so markiert. Ohne Markierung wird verschlüsselt. |
| Zeichenketten im Abbild, davon Anwendungstexte im Klartext | — | 2 von 188 | Blackbox-Analyse | 1.29 | gesamtes Dateiabbild der geschützten Fassung | Zeichenkettenextraktion in IDA Pro | 188 Zeichenketten | Die zwei lesbaren Texte sind Banner und Gebrauchsanweisung. |
| Zeichenketten nach Gebrauch im eigenen Datensegment | 1 Treffer | 0 Treffer | Produktdokumentation 1.29 | 1.29 | Testprogramm, das nach der Ausgabe sein eigenes Datensegment durchsucht | Suche im eigenen Datensegment zur Laufzeit | — | Gemessen aus dem eigenen Prozess nach der Ausgabe. |
| Wirkung einer Ein-Byte-Änderung am Chiffrat | 1 von 8 160 Klartextbytes verändert | 8 130 von 8 160 Klartextbytes verändert | Produktdokumentation 1.29 | 1.28 gegen 1.29 | verschlüsselte Schutzsektion | ein einzelnes Chiffratbyte kippen, entschlüsselten Block vergleichen | 1 Byte | Die Wirkung entsteht durch die Kopplung von Schlüssel und Chiffretext. |
| Erkennung gezielter Manipulation | 5 von 5 Patch-Versuchen erfolgreich (frühere Fassung) | 0 von 5 Patch-Versuchen erfolgreich | Produktdokumentation 1.29 | frühere Fassung gegen 1.29 | Integritätsprüfung | gezielte Patch-Versuche an der Integritätsprüfung; in einer früheren Fassung genügte dafür ein einzelnes Byte | 5 Versuche | Fünf definierte Versuche an einem Artefakt; die Blackbox-Analyse unten nennt sieben weitere. |
| Manipulationsversuche der Analyse | — | 7 Versuche, kein einziger führte zu lesbarem Klartext; 5 davon wurden sofort erkannt | Blackbox-Analyse | 1.29 | Erfolgsweiche, Chiffrat der Schutzsektion, verschlüsselter Datenblock, Prüfmechanik, Abbruchmechanik und Kombinationen daraus | Bytes im Disassembler ändern, Datei je Versuch 8 bis 12 mal starten, Rückgabewert und Ausgabe vergleichen | 7 Versuche, je 8 bis 12 Läufe | Zwei Versuche blieben unerkannt, verschafften dem Angreifer aber keinen Klartext: mit fünf geänderten Bytes lief das Programm stabil in den Erfolgspfad und gab weiterhin unlesbaren Text aus. |
| Fremder Speicherzugriff über OpenProcess | 64 Byte gelesen | OpenProcess verweigert, Fehler 5 | Produktdokumentation 1.29 | 1.27 | Prozess auf Schutzstufe max | eigenes Leseprogramm mit OpenProcess und ReadProcessMemory gegen denselben Prozess | — | Eine leere Zugriffsliste, nicht eine NULL-Zugriffsliste. Sie wirkt im getesteten Rechtekontext; ein Administrator kann sich das Recht nehmen. |
| Klartextfenster des geschützten Bereichs im laufenden Prozess | — | 28 735 von 28 854 Stichproben verschlüsselt (99,6 %); die wenigen Fenster dauerten im Median 0,089 ms | Blackbox-Analyse | 1.29 | Schutzsektion, 4 096 Byte | Abtastung aus einem Beobachterprozess mit ReadProcessMemory und VirtualQueryEx | 28 854 Stichproben über 10 Läufe | In 9 von 10 Läufen blieb der Bereich dem Beobachter durchgehend verschlossen. |
| Entschlüsselte Zeichenketten und Bytecode im Speicher | — | 0 Treffer bei 11 094 Stichproben | Blackbox-Analyse | 1.29 | Datensegment .bss des laufenden Prozesses | Abtastung aus einem Beobachterprozess, Abstand etwa 70 µs | 11 094 Stichproben | Entschlüsselung, Nutzung und Löschung liegen so dicht beieinander, dass der Sampler bei etwa 70 µs Abstand kein einziges Fenster traf. |
| Zeitverhalten als Seitenkanal | — | Median 12,8 ms, Standardabweichung 1,5 ms | Blackbox-Analyse | 1.29 | gesamter Programmlauf, verschiedene Eingaben | Laufzeitmessung einschließlich Prozessstart | 60 Läufe | Kein messbarer Unterschied zwischen richtigen und falschen Eingaben. |
| Funktionale Stabilität | — | 60 von 60 Läufen identisch, 0 Abstürze | Blackbox-Analyse | 1.29 | gesamtes Programm, Eingaben bis 8 000 Zeichen | wiederholte Ausführung mit gleicher und mit wechselnder Eingabe | 60 Läufe | Gemessen an diesem Demoprogramm. |
| Virtualisierung gegen native Ausführung | — | 150 676 plus 120 042 plus 26 698 Vergleiche, null Abweichungen | Produktdokumentation 1.29 | 1.29 | Selbsttests width_selftest.c für alle Bitbreiten, mem_selftest.c für Speicherzugriffe, vm_selftest.c für kleine Wertebereiche | Jede Funktion wird auf der Zwischendarstellung und als Bytecode durchgerechnet und verglichen | 297 416 Vergleiche in drei Selbsttests | Belegt die Korrektheit der Übersetzung. Fälle mit undefiniertem Verhalten sind ausgenommen, weil die native Referenz dort selbst ungültig ist. |
| Laufzeit im ungünstigsten Fall | etwa 1 ms | fast 6 ms, balanced 99 ms, max 108 ms, balanced mit citadel_hot etwa 1 ms | Produktdokumentation 1.29 | 1.29 | eine kleine Funktion, zwei Millionen Aufrufe in einer engen Schleife, ohne Annotation | Laufzeitmessung über zwei Millionen Aufrufe | 2 000 000 Aufrufe | Der ungünstigste denkbare Fall: eine winzige Funktion, millionenfach aufgerufen, ohne jede Annotation. Mit citadel_hot fällt derselbe Testfall auf die Ausgangszeit zurück. |
| Optionale Obergrenze für gleichzeitig offene Seiten | 13 offene Seiten, 332 ms | 7 offene Seiten, 5 873 ms bei Grenze 6 | Produktdokumentation 1.29 | 1.29 | 160 Funktionen in einer engen Schleife | Laufzeitmessung mit und ohne Obergrenze | — | Deshalb standardmäßig aus, zuschaltbar über CITADEL_MAX_OPEN. |
| Mehraufwand für eine Analyse | Faktor 15 bis 20 — Ermittelt an einem 200 Zeilen langen Demoprogramm, bei dem jeder geschützte Codepfad sofort läuft — also unter für den Angreifer günstigen Bedingungen.Quelle: PRODUCT.md und FAQ.md, CitadelCore 1.29 |
|---|---|
| Zeit, um die Logik zu verstehen | 4 bis 8 Stunden für eine erfahrene Person — Dieselbe Analyse setzt für ein ungeschütztes Programm gleicher Funktion unter 15 Minuten an — aus Minuten werden damit Arbeitstage.Quelle: Blackbox-Analyse vom 27.09.2026, Abschnitt Aufwandsschätzung |
Nachgemessen am Demo-ProgrammGemessen am 14.10.2026 an den ausgelieferten Dateien des Demopakets licensing_demo 1.29 (CitadelCore 1.29.0), mit den Build-Befehlen aus der beiliegenden BUILD.md. Mit denselben Mitteln an denselben Dateien reproduzierbar.
| Referenz-Build | clang -O1 -fno-inline -Wl,-s -o licensing_demo.exe licensing_demo.c |
|---|---|
| Build mit CitadelCore | set CITADEL_SECRET=SERIAL-7E3A-C5D1-2F98 && citadel --compile licensing_demo_protected.c -o licensing_demo_protected.exe --level max --report -- -O1 -fno-inline -Wl,-s |
| SHA-256 der Quelldateien | 87ecfb4c1ff6adf56721f9e4e6ea13dee0c3f5c11e2f96ca9dda8828de446e08 (Referenz), 50811fec35a58f39f4e5e98d08719fe15d54d94254b5a786cf53074152f842bc (geschützt) |
| Artefakt ohne Härtung | licensing_demo.exe, 40.960 Byte, SHA-256 8e7164a110f3d9ce38b5385f080da3eb02832ef3e6fac4f032a8fb2e858cc56a |
| Artefakt mit Härtung | licensing_demo_protected.exe, 88.576 Byte, SHA-256 1a319ae2784941cecb517c88613f8f5a8fb233eada04db87dde5425ac1ae7244 |
Blackbox-Analyse · 27.09.2026
Es wurde eine Blackbox-Analyse an einem durch CitadelCore geschützten Demo-Lizenzprogramm durchgeführt: statisch und dynamisch anlicensing_demo_protected.exe. Prüfen Sie die Angaben selbst — der herunterladbare Bericht enthält Methodik, Messwerte und Fundstellen.
Die Informationsquelle des Prüfers war das fertige geschützte Programm, nicht dessen Quellcode. Was im Bericht steht, stammt aus dem Maschinencode und aus dem Verhalten beim Ausführen — dieselbe Ausgangslage wie bei einem Angreifer, der die Quellen nicht hat.
Der herunterladbare Bericht ist der Beleg: Methodik, jede Messung und jede Fundstelle stehen darin vollständig, auch die beiden Versuche, die unerkannt blieben.
Die Ergebnisse im Einzelnen
Durchgeführt im Auftrag von AetherSec an einem gehärteten Demo-Programm, statisch und dynamisch. Der vollständige Bericht liegt offen — samt Methodik, allen Messwerten und den beiden Versuchen, die unerkannt blieben.
Eigenschaften des Beispiel-Serials, etwa seine Länge von 48 Bit, sind Parameter der Demo und keine Eigenschaft von CitadelCore.
Reichweite und Steuerung
CitadelCore ist kein einzelner Schalter, sondern neun Ebenen, die Sie einzeln steuern. Hier steht, wofür jede gebaut ist und wie Sie sie auf Ihr Projekt zuschneiden. Nach der Installation prüfen Sie alles selbst nach: citadel --test führt die Testsuite auf Ihrer Maschine aus.
Vier Annotationen steuern jede Funktion einzeln: garantiert prüfen, in Bytecode übersetzen, von der Härtung ausnehmen oder als Text lesbar lassen. Ohne Annotation greift eine sinnvolle Voreinstellung, die Einstiegspunkte immer absichert.
Beleg: WINDOWS.md, Abschnitt 6
Drei Schutzstufen von fast bis max, dazu citadel_hot für heiße Pfade. Rechenintensive Funktionen bleiben damit auf nativer Geschwindigkeit, während alles andere geschützt bleibt.
Beleg: WINDOWS.md, Abschnitt 7
Die stärkste Ebene übersetzt ganzzahlige Arithmetik, Logik, Vergleiche, Verzweigungen, Schleifen und lokale Felder — also genau das, woraus Lizenzprüfungen und Schlüsselableitungen bestehen. Was sie nicht sicher übersetzen kann, meldet sie im Bericht und lässt es nativ, statt still falsch zu rechnen. Genau das macht sie im Produktiveinsatz verlässlich.
Beleg: WINDOWS.md, Code-Virtualisierung
Die Prozesshärtung auf Stufe max sperrt fremde Speicherzugriffe im Rechtekontext des Nutzers aus. Für Diagnosebuilds schalten Sie genau diese Ebene über eine Umgebungsvariable ab — die übrigen acht bleiben aktiv.
Beleg: FAQ.md; WINDOWS.md, Neuerungen 1.27
Ausführender Code muss im Speicher entschlüsselt sein — das gilt für jedes Verfahren dieser Art. CitadelCore drückt dieses Fenster auf das Nötigste: in der Blackbox-Analyse lag der geschützte Bereich 99,6 Prozent der Laufzeit verschlüsselt vor, bei einem Median-Fenster von 0,089 ms.
Beleg: Blackbox-Analyse vom 27.09.2026, Abschnitt 4c
Selbstmodifizierender Code sieht für Scanner nach Packer aus — das betrifft jedes Produkt dieser Kategorie. Ein Code-Signing-Zertifikat löst das zuverlässig und gehört bei kommerzieller Auslieferung ohnehin dazu.
Beleg: FAQ.md
CitadelCore erschwert die Extraktion eingebetteter Werte erheblich und bindet auf Wunsch ein Freischaltgeheimnis von außen ein. Für Werte, die unter keinen Umständen beim Kunden liegen dürfen, bleibt eine serverseitige Prüfung die richtige Architektur — CitadelCore härtet dann den Client-Teil davor.
Beleg: FAQ.md; WINDOWS.md, Das Freischaltgeheimnis
Browser-Lehrmodelle
Jedes ausgelieferte JavaScript-Modul kann untersucht werden. Deshalb ist in derPrinzipien-Demokeine vertrauliche Produktfunktion nachgebaut: es sind eigenständige, kleine Lehrmodelle.
Veranschaulicht: Die Grundidee von Ebene 08: dieselbe Berechnung einmal direkt und einmal als Folge von Bytecode-Befehlen, die ein Interpreter abarbeitet. Im Abzug erscheint dann Bytecode statt Maschinencode.
Weicht ab: Das Lehrmodell hat acht Befehle und eine offen lesbare Opcode-Tabelle. CitadelCore würfelt die Opcode-Zuordnung je Build neu aus dem Seed, arbeitet auf 1 bis 64 Bit und rechnet jede Übersetzung vor dem Einsatz gegen die native Ausführung nach. Der Browser-Interpreter ist in JavaScript geschrieben und offen einsehbar — der des Produkts steht als Bytecode in Ihrer Datei.
Veranschaulicht: Die Grundidee hinter Ebene 02 und Ebene 06: wenn Integrität und Entschlüsselung zusammenhängen, führt eine Änderung an den Daten nicht zu einer umgehbaren Fehlermeldung, sondern dazu, dass nichts Brauchbares herauskommt.
Weicht ab: Das Lehrmodell nutzt AES-GCM, weil der Browser das mitbringt — mit separatem Tag und echter Tag-Prüfung. CitadelCore nutzt ChaCha20 und koppelt einen Hash über den Chiffretext direkt in den Schlüssel: dieselbe Wirkung, ohne separates Tag-Feld. Schlüssel und Daten des Browser-Moduls sind offene Demowerte.
Diese Mechanismen sind an Windows gebunden: Zugriffslisten für Prozesse, der Schutz gegen OpenProcess und ReadProcessMemory, die Prüfung von Hardware-Breakpoints, native Seitenrechte und die Entschlüsselung von Code erst beim Zugriff. Sie werden hier erklärt, aber nicht simuliert.
Für wen
CitadelCore richtet sich an Entwicklerinnen und Entwickler kleiner Softwarehäuser, an Anbieter von Windows-Desktop-Software und an Hersteller proprietärerC/C++-Komponenten. Gemeinsam ist diesen Fällen, dass eine Programmdatei den Kunden erreicht und dort ohne Aufsicht läuft.
Softwarehäuser härten damit Lizenz- und Aktivierungslogik. Hersteller von Komponenten schützen proprietäre Berechnungen. Wer Sicherheitsforschung betreibt, findet in den neun Schutzebenen eine durchgearbeitete Umsetzung des Decrypt-to-Execute-Prinzips mit offengelegten Messwerten.
Nicht geeignet ist CitadelCore, wenn Sie keine Quellen haben, für eine andere Plattform ausliefern oder in einer anderen Sprache entwickeln. DerEignungstestsagt Ihnen das in zwei Minuten.
Lieferumfang und Lizenz
| Download nach Zahlung gemessen | CitadelCore_v1.29.0.zip mit Installationsprogramm, Handbuch, FAQ und Lizenzbedingungen.Beleg: Inhalt des ausgelieferten Archivs, geprüft am 14.10.2026 |
|---|---|
| Was installiert wird dokumentiert | Kommando und Compiler-Wrapper, das Härtungswerkzeug, die Laufzeitbibliothek, das Prüfsummen-Werkzeug, die Testsuite und die Dokumentation.Beleg: WINDOWS.md, Abschnitt 2 |
| Nutzung dokumentiert | Installation und Nutzung auf Rechnern unter Ihrer Kontrolle — Arbeitsplätze wie Buildserver — zur Härtung eigener Softwareprodukte.Beleg: LICENSE.txt, Abschnitt 1 |
| Ihre Erzeugnisse dokumentiert | Gehärtete Programme gehören Ihnen. AetherSec erhebt keinen Anspruch auf Ihren Quellcode oder die erzeugten Binärdateien und verlangt für deren Weitergabe keine Lizenzgebühr.Beleg: LICENSE.txt, Abschnitt 3 |
| Weitergabe der Laufzeitbestandteile dokumentiert | Die zur Laufzeit eingebundenen Bestandteile dürfen Sie als Teil Ihrer gehärteten Programme weitergeben. Die Entwicklungswerkzeuge selbst bleiben bei Ihnen.Beleg: LICENSE.txt, Abschnitt 3 |
| Updates und Support dokumentiert | Fragen zu Einsatz, Integration und künftigen Versionen beantworten wir direkt unter kontakt@aethersec.de.Beleg: Kontakt dieser Website |
| Aktivierung dokumentiert | Für Ihre gehärtete Anwendung ist kein Schutzserver nötig. Auch das optionale Freischaltgeheimnis kommt ohne Server aus.Beleg: FAQ.md; WINDOWS.md, Das Freischaltgeheimnis |
Test an Ihrem eigenen ProjektSie wollen die Härtung an Ihrem Code sehen, bevor Sie kaufen? Schreiben Sie uns kurz, worum es geht — wir melden uns mit einem konkreten Vorschlag für Ihr Projekt.Echten Projekttest anfragen
Fachliche Fragen
Ja — und genau darin liegt der Vorteil. CitadelCore härtet beim Übersetzen und arbeitet auf dem LLVM-Bitcode Ihres Projekts: Der Schutz entsteht über hunderte Stellen im Code verteilt, statt als Hülle, die sich abziehen ließe. Das kann kein Werkzeug leisten, das erst an der fertigen Datei ansetzt.
Ganzzahlige Arithmetik, Logik, Vergleiche, Verzweigungen, Schleifen und lokale Felder — also genau das, woraus Lizenzprüfungen und Schlüsselableitungen bestehen. Der Pass übersetzt nur, was er nachweislich korrekt übersetzt, und vermerkt den Rest im Bericht: Deshalb können Sie ihn produktiv einsetzen, ohne auf seltene Pfade zu hoffen. Die übrigen acht Schutzebenen greifen unabhängig davon.
Das steuern Sie: heiße Pfade nehmen Sie mit citadel_hot aus und bleiben auf nativer Geschwindigkeit. Im Handbuch steht die Messung für den ungünstigsten denkbaren Fall — zwei Millionen Aufrufe einer winzigen Funktion ohne jede Annotation. Mit einer einzigen Annotation fiel derselbe Testfall wieder auf die Ausgangszeit zurück.
AetherSec · Ausblick
Woran wir als Nächstes arbeiten.
Geplant ist plattformübergreifender Schutz über die Windows-Edition hinaus.
Geplant sind graphische Oberflächen für Konfiguration und Berichte.
Geplant ist der einfachere Einsatz in komplexeren Softwareprojekten.
CitadelCore ist ein Produkt von AetherSec. Einmalig 74,99 €, Zahlung über Stripe Checkout. Für Support oder technische Fragen:kontakt@aethersec.de