Alles, was LITHIUM in deine Binary einbaut.
Mehrere Schutzschichten, die ineinandergreifen. Jeder Build wird strukturell anders — ein Crack-Tool für Build N läuft nicht auf Build N+1.
Dual-Layer-Verschlüsselung
Zwei unabhängige, komplett hauseigene Chiffren übereinander. Rundenzahl (6–10), Konstanten und Schlüssel-Regionen sind pro Build unterschiedlich. Cracker muss beide Schichten separat reversen.
Server-Bound Protection
Verschlüsselungsschlüssel werden nicht in der Binary gespeichert — sie werden zur Laufzeit über TLS-gepinnte HTTPS-Verbindung vom Lithium-Server geholt. Statisches Reversing findet keine Keys mehr, weil keine da sind. Ohne Internet startet die Binary nicht.
Remote Revocation
Ein Klick im Dashboard widerruft einen kompromittierten Build weltweit. Alle Kopien können ihre Schlüssel beim nächsten Start nicht mehr abholen und beenden sich sauber — auch wenn sie längst verkauft/geleakt wurden.
Tamper Dashboard
Live-Übersicht aller Debug-Versuche, Manipulationen und blockierten Aufrufe pro Build — mit HWID, IP und Zeitpunkt. Auto-Revoke bei fünf kritischen Ereignissen pro Stunde.
Hauseigene Krypto-Suite
Selbst entwickelte Stream- und Block-Chiffren mit per-Build-generierten S-Boxen. Keine Open-Source-Cipher — etablierte Angriffs-Toolkits sind nicht direkt anwendbar. Hand-implementiert ohne externe Krypto-Libraries.
Verschleierte Imports
Import-Table und PE-Directory sind zur Laufzeit komplett gewiped. DLL- und API-Namen tauchen weder in strings noch bei statischen PE-Analyzern auf — Auflösung erfolgt dynamisch über selbstgebauten Resolver.
Anti-Debug & Anti-Analyse
16 unabhängige Debugger-Erkennungen und 4 aktive Gegenmaßnahmen. Direct-Syscall-Ausführung umgeht sämtliche Usermode-Hooks von gängigen Anti-Anti-Debug-Werkzeugen.
Salt-XOR Debug-Detection
Anti-Debug-Ergebnisse fließen als Salt in den Entschlüsselungs-Schlüssel. Unter Debugger = falscher Salt = falscher Key = Klartext wird zu Müll. Kein Crash, kein sichtbarer Check — das Programm läuft weiter, produziert aber garbage.
Anti-Tampering
Verteilte Integritätsprüfungen erkennen statische und Laufzeit-Patches. Manipulation führt nicht zu offensichtlichen Aborts, sondern zu falscher Entschlüsselung — Cracker findet keinen klaren Signal-Punkt.
Anti-Dump mit Runtime-Re-Encryption
Nach dem Start wird der Code wieder verschlüsselt und die Speicher-Pages als NOACCESS markiert. On-Demand-Entschlüsselung nur beim tatsächlichen Zugriff — Memory-Dumper erhalten kein verwertbares Abbild, egal wann sie zuschlagen.
Anti-VM & Anti-Sandbox
Erkennt automatisierte Analyse-Umgebungen, VM-Detection-Bypasses und Sandbox-Setups. Verhindert Auto-Reverser-Pipelines wie any.run und ähnliche.
Code-Virtualisierung · 221 Opcodes
Sensible Routinen laufen in einer hauseigenen virtuellen Maschine mit 221 Opcodes. Handler-Reihenfolge, Rolling-Key und Dispatch-Pfad sind pro Build unterschiedlich — ein VM-Devirtualizer für Build N läuft nicht auf Build N+1.
Polymorpher Stub
Der Entschlüsselungs-Stub wird pro Build durch rund 190 Instruction-Mutationen gejagt. Identische Funktionalität, komplett anderer Byte-Fingerabdruck — YARA-Rules und Signatur-basierte Detection sind nutzlos.
OEP-Schutz mit Dependency-Chain
Fünf-stufige Abhängigkeitskette schützt den ursprünglichen Entry Point. Fehlt eine Stufe — Debugger, Patch, VM-Bypass, Dump-Rekonstruktion — bleibt der OEP unerreichbar.
HWID-gebundene Lizenzen
Kryptografisch signierte Lizenzdateien, fest an die Hardware-Signatur des Kunden gebunden. Eine Lizenz aus Maschine A funktioniert nicht auf Maschine B.
Server-verwaltete HWID-Slots
Wieviele Endnutzer-Maschinen deine geschützte Binary starten dürfen, entscheidet der Server. Professional: 3 HWIDs pro Build · Enterprise: unbegrenzt. Kein Sharing zwischen Käufern.
Standalone Lizenz-Manager
Eigenständiges CLI-Tool für Schlüssel-Generierung, Signierung und Verifikation. Der private Signatur-Schlüssel bleibt vollständig auf deinem Build-Server.
Drag-&-Drop GUI
Native Windows-Oberfläche mit Drag-&-Drop-Bedienung. Binary reinziehen, Plan wählen, geschützte Version rausziehen. Komplett auch per CLI bedienbar.
Developer-SDK
Header-only-Makros für punktgenauen Schutz im Quellcode — verschlüsselte Strings, geschützte Funktions-Pointer und Runtime-Anti-Debug-Callbacks im Game- oder App-Loop.
Kernel-Mode Guard
Optionaler signierter Treiber blockiert externe Schreib- und Suspend-Zugriffe auf deine geschützte Anwendung — mit transparentem Fallback, wenn nicht installiert.
Verfahren, die wir einsetzen.
Etablierte, audit-fähige Standards — keine selbstgebauten Verschlüsselungs-Experimente.
Zwei eigene Chiffren
Custom ARX-Stream-Cipher + Feistel-basierte Blockchiffre, hand-implementiert. Cracker kann keine öffentlichen Attack-Toolkits ansetzen — er muss beide Verfahren erst reversen.
Per-Build Cipher-Genesis
Rundenzahl, S-Box, Konstanten und Schlüssel-Regionen werden pro Build zufällig neu generiert. Kein Build ist mit dem nächsten identisch.
Public-Key-Signaturen
Server-ausgestellte Runtime-Keys werden asymmetrisch signiert und im Stub verifiziert. MITM-Angriffe werden erkannt und blockiert.
TLS-gepinnter Key-Transport
Runtime-Key-Abruf über HTTPS mit Certificate-Pinning. Zusätzliche Application-Layer-Verschlüsselung mit per-Build Transport-Key.
HWID-Bindung
Mehrteilige Hardware-Signatur aus stabilen, eindeutigen Maschinen-Identifikatoren — sowohl für Developer-Lizenz als auch für Endnutzer-Binding.
Was sich schützen lässt.
Native Windows-PE64. Managed Assemblies (.NET) und 32-Bit-Binaries werden derzeit nicht unterstützt.
| Typ | Status | Bemerkung |
|---|---|---|
| Windows PE64 .exe | CONSOLE & GUI | |
| Windows PE64 .dll | mit DllMain-Wrapper | |
| Statisch gelinkte Libraries | automatisch mit geschützt | |
| PE32 (32-Bit) | — | derzeit nicht unterstützt |
| .NET / Managed Assemblies | — | nur native Binaries |
| Externe 3rd-Party DLLs | — | müssen separat geschützt werden |
Probier LITHIUM an deinem nächsten Build aus.
Wähle einen Plan, lade die CLI-Tools im Dashboard und ziehe deine Binary hinein.