VM Self Defending

Die Option vmSelfDefending ergänzt die VM-Laufzeit um mehrschichtige Manipulationserkennung, Integritätsprüfungen des Codes, Anti-Hooking und Schutz vor Reverse Engineering. In Kombination mit vmDebugProtection erschwert sie sowohl manuelle als auch KI-gestützte Analyse erheblich.

Diese Option erzwingt die Aktivierung von vmBytecodeArrayEncoding und erhöht den Aufwand der VM-Ausführung. Messen Sie ihn an Ihren eigenen häufig ausgeführten Pfaden.

Wie jede Erkennung reagiert und wie Sie Erkennungen an Ihr Backend melden, statt nur abzubrechen, beschreibt VM-Abwehr: Telemetrie & Reaktionen; vmSelfDefending meldet Erkennungen in den Reaktionskategorien automation, debugger, tamper und integrity.

Empfohlen: Verwenden Sie sie für maximalen Schutz zusammen mit vmDebugProtection, vmBytecodeArrayEncodingKey und vmBytecodeArrayEncodingKeyGetter.

Laufzeitkompatibilität

Erkennung sensibler Umgebungen

Diese Option bindet den obfuskierten Code an seine Ziel-Laufzeitumgebung und nutzt fortgeschrittenes Browser-Fingerprinting, um Automatisierungswerkzeuge zu erkennen. Mit dieser Option geschützter Code bricht absichtlich ab, wenn er ausgeführt wird in:

• Headless-Browsern (Headless Chrome/Chromium, PhantomJS)
• Werkzeugen zur Browserautomatisierung (Puppeteer, Playwright, Cypress, Selenium/ChromeDriver, Nightmare)
• Node.js (wenn target auf browser gesetzt ist)
• jsdom oder ähnlichen serverseitigen DOM-Emulationen
• Umgebungen, in denen native Browser-Builtins gehookt oder ersetzt wurden (sofern nicht mit browserEnvironment.hookedBuiltins deklariert)

Der Code funktioniert korrekt in regulären Browsern (Chrome, Firefox, Safari, Edge), auch wenn er in iframes, Browsererweiterungen (Content Scripts) und Web Workers geladen wird.

Wählen Sie das target passend zur tatsächlichen Laufzeit. Browser- und Node-Builds enthalten unterschiedliche Abwehrmaßnahmen: Das Target node lässt diejenigen weg, die auf reine Browser-APIs angewiesen sind, und ein browser-Build, der unter Node läuft, bricht wie oben beschrieben ab.

Ist browserEnvironment.hookedBuiltins auf true gesetzt (v7.15.0+), toleriert Self Defending eine Laufzeit, die native Builtins legitimerweise durch JavaScript-Wrapper ersetzt, statt dies als Manipulation zu werten, sodass der geschützte Code dort weiterhin läuft. Dies lockert bewusst die Erkennung von Builtin-Hooks; VM-Virtualisierung, Anti-Debugging und Integritätsschutz bleiben unberührt. Das Feld transport derselben Option bindet den Build an das Schema, über das er ausgeliefert wird.

Self Defending prüft die Integrität seiner eigenen Ausgabe. Minifizieren, formatieren oder schreiben Sie den obfuskierten Code daher nachträglich nicht um. Wenden Sie solche Werkzeuge vor dem Obfuskierungsschritt auf Ihren Quellcode an.

Tests und CI

Diese Abwehrmaßnahmen wirken auch gegen Ihre eigenen Agenten, Automatisierungen und Debugger. Sie können die Ausführung stoppen, unzusammenhängende Fehler auslösen oder falsche Ergebnisse liefern. Diese Option soll automatisierte Analyse verhindern und kann mit keinem Automatisierungsframework sicher verwendet werden. Führen Sie Funktionstests daher gegen einen separaten Test-Build mit deaktiviertem vmSelfDefending aus. Tests und CI listet alle Überschreibungen für diesen Build auf.