Ihr VM-obfuskierter Code wirft zur Laufzeit einen Fehler – vielleicht einen RangeError: Invalid array length, aber dieselbe Checkliste gilt für andere unerwartete Fehler, die erst nach der Obfuskierung auftreten. Arbeiten Sie die folgenden Schritte der Reihe nach ab. Der erste deckt die mit Abstand häufigste Ursache ab; die übrigen grenzen einen echten Fehler ein.

Schritt 1 – die Laufzeitumgebung gegen die Option target prüfen

Die mit Abstand häufigste Ursache für Invalid array length und ähnliche Fehler ist eine Diskrepanz zwischen der Option target und der Umgebung, in der der Code tatsächlich läuft, in Verbindung mit vmSelfDefending: true.

Umgebungen, in denen das auslöst:

• Node.js (das obfuskierte Bundle wird direkt über node ausgeführt)
• Headless Chrome / Chromium, PhantomJS
• Puppeteer, Playwright, Cypress, Selenium / ChromeDriver, Nightmare
• jsdom und andere serverseitige DOM-Emulationen
• Jede Umgebung, in der native Browser-Builtins gehookt oder ersetzt wurden

Steht Ihre Laufzeitumgebung auf dieser Liste, ist der Fehler kein Bug, sondern der Schutz, der wie vorgesehen arbeitet. Wählen Sie die Lösung, die zu Ihrem Fall passt:

• Sie führen den Code bewusst in Node.js aus (serverseitiges Skript, CLI-Werkzeug, Electron-Hauptprozess): Setzen Sie beim Obfuskieren target: 'node'. Die Self-Defending-Schicht richtet sich dann auf Node statt auf den Browser aus.
• Sie führen automatisierte Tests bzw. E2E-Tests gegen einen obfuskierten Build aus (Cypress, Playwright, Puppeteer, Selenium): Erzeugen Sie einen separaten Test-Build mit vmSelfDefending: false. Die Option ist darauf ausgelegt, Automatisierung zu unterbinden; einzelne Werkzeuge lassen sich nicht auf eine Freigabeliste setzen. Die vollständige Liste inkompatibler Umgebungen finden Sie unter VM Self Defending.
• Sie führen den Code in einem echten Browser aus und sehen den Fehler trotzdem: Stellen Sie sicher, dass keine Erweiterung, kein DevTools-Skript und keine Wrapper-Seite native Builtins hookt (Array, Function.prototype, JSON usw.). Reproduzieren Sie das Verhalten in einem sauberen Profil, bevor Sie es als Bug behandeln.

Schritt 2 – auf eine einzelne Funktion eingrenzen

Ließ sich das Problem mit Schritt 1 nicht lösen, steckt der Fehler in einem bestimmten Stück transformierten Codes. Wechseln Sie zu vmTargetFunctionsMode: 'comment' und fügen Sie /* javascript-obfuscator:vm */ jeweils nur einer Funktion hinzu, bis der Fehler wieder auftritt. Die Funktion, die Sie markiert hatten, als der Fehler zurückkam, ist die Übeltäterin – das ist die minimale Reproduktion, die Sie an den Support schicken.

Schritt 3 – einen Fehlerbericht senden

Sobald Sie ausgeschlossen haben, dass es sich um eine Diskrepanz zwischen target und Self Defending handelt, und die Funktion eingegrenzt haben, schreiben Sie an support@obfuscator.io. Je mehr der folgenden Angaben Sie beilegen, desto schneller können wir das Problem beheben:

• Vollständiger Stacktrace des Fehlers, exakt so, wie er in der Konsole erscheint – keine Umschreibung.
• Obfuskierungsoptionen als JSON. Kopieren Sie das komplette Optionsobjekt, das Sie verwendet haben (oder den Namen der Voreinstellung samt aller Abweichungen). Subtile Wechselwirkungen zwischen Optionen sind häufig, daher brauchen wir genau diese Zusammenstellung.
• Obfuscator-Version – sie wird unten rechts im Editor angezeigt.
• Umgebung – Browser + Version, Node.js-Version, Betriebssystem und alles Ungewöhnliche an der Laufzeitumgebung (Erweiterungen, Polyfills, eigene Builtins).
• Minimale Reproduktion – idealerweise die einzelne Funktion aus Schritt 2 samt der Aufrufstelle, die zum Auslösen des Fehlers nötig ist.
• Der ursprüngliche Quellcode (vor der Obfuskierung), sofern möglich. Die obfuskierte Ausgabe ist auch für uns undurchsichtig; ohne die Eingabe entwickeln wir unseren eigenen Bytecode zurück.