Dokumentation
/

Laufzeitkompatibilität

Laufzeitkompatibilität

Wählen Sie target passend zur tatsächlichen Laufzeit. Browser- und Node-Builds können unterschiedliche Abwehrmaßnahmen enthalten; ein Browser-Target ersetzt kein Node-Target.

target

  • browser - Chrome, Firefox, Safari, Edge.
  • browser-no-eval - wie browser, aber die Ausgabe verwendet kein eval(). Nutzen Sie dies, wenn die Zielseite eine Content Security Policy hat, die eval/unsafe-eval verbietet.
  • node - Node.js-Umgebung. Browserspezifische Optionen sind deaktiviert (sie benötigen window/document und wären in Node wirkungslos oder würden Fehler werfen). Einige vmSelfDefending-Abwehrmaßnahmen, die auf reine Browser-APIs angewiesen sind, etwa die Erkennung von Headless-Browsern, die iframe-basierte Wiederherstellung eines sauberen Realms und Anti-Inspector-/DOM-Prüfungen, werden für dieses Target nicht erzeugt.
  • service-worker - Service-Worker-Kontext. Kein window, kein document, anderes globales self.
  • userscript - Sandbox eines Userscript-Managers (z. B. Tampermonkey). Die vmSelfDefending-Abwehrmaßnahmen werden entsprechend angepasst. Erfordert VM-Obfuskierung (oder Parse HTML) und Obfuscator v6.9.0+.
  • bytenode - für Code, der mit bytenode zu .jsc kompiliert wird. Erfordert VM-Obfuskierung (oder Parse HTML) und Obfuscator v6.13.0+.

Browserumgebung und Domains

Angaben darüber, wo der Code läuft, müssen dem tatsächlichen Deployment entsprechen. browserEnvironment muss beschreiben, wie der Build tatsächlich ausgeliefert wird (siehe Browser Environment), und VM Domain Lock muss jede Domain auflisten, die ihn ausliefert (siehe VM Domain Lock). Automatisierung und Debugger können erweiterte Abwehrmaßnahmen auslösen; siehe Tests und CI.

JavaScript

Funktionsnamen und der Quelltext von Funktionen können sich durch die Obfuskierung ändern. Verwenden Sie .name oder .toString() nicht als stabile Anwendungsdaten, sondern explizite Bezeichner. Öffentliche globale Werte können sichtbar bleiben, wenn Ihre Einstellungen dies erfordern.

strictMode

strictMode: null und strictMode: false erkennen explizite Direktiven, ES-Module und Klassenmethoden weiterhin als strikt. strictMode: true behandelt die gesamte Eingabe als strikt. Richten Sie sich nach dem endgültigen Laufzeitkontext; ein Bundler, der nach der Obfuskierung den Strict Mode hinzufügt, kann das Verhalten ändern.

Build-Pipeline

Kompilieren Sie TypeScript oder JSX und bündeln Sie Ihre Anwendung vor dem abschließenden Obfuskierungsschritt. Erhalten Sie die Kommentare /* javascript-obfuscator:vm */ während dieses Builds, damit der Kommentarmodus sie noch findet. Minifizieren, formatieren oder schreiben Sie durch Self Defending oder VM Self Defending geschützte Ausgabe danach nicht anderweitig um. Source Maps sind für VM- und HTML-Obfuskierung nicht verfügbar.