VM-Laufzeitfehler diagnostizieren

Gehen Sie diese Schritte der Reihe nach durch. Jeder schließt eine häufige Ursache aus, bevor Sie Zeit darauf verwenden, den fehlschlagenden Code einzugrenzen.

1. Erweiterte Abwehrmaßnahmen ausschließen

Ein Fehler, der zu Ihrem Code nicht passt, meist RangeError: Invalid array length, bedeutet in der Regel, dass ein Produktions-Build dort läuft, wo Produktions-Builds nicht laufen dürfen. VM Self Defending und VM Debug Protection legen den Code absichtlich lahm: in Test-Runnern und anderer Automatisierung, in Headless-Browsern, in Node.js oder jsdom mit einem Browser-Build und in Browsern mit geöffneten DevTools. Prüfen Sie vor allem anderen, wo der fehlschlagende Code läuft.

Schließen Sie zuerst erweiterte Abwehrmaßnahmen aus (VM Self Defending, VM Debug Protection, VM Domain Lock): Reproduzieren Sie den Fehler mit einem Test-Build, der die Überschreibungen aus Tests und CI verwendet. Funktioniert der Test-Build, reagieren die Abwehrmaßnahmen auf Ihre Werkzeuge oder Ihre Umgebung, statt Ihren Code zu beschädigen.

2. Laufzeitkompatibilität prüfen und die fehlschlagende Funktion eingrenzen

Prüfen Sie, ob target, die Build-Pipeline und alle Umgebungsangaben dazu passen, wo der Code tatsächlich läuft.

Meldet ein Build Abdeckungswarnungen wie VMNoFunctionsToVirtualize, lesen Sie unter VM-Obfuskierung nach, was der VM-Schutz abdeckt.

Reduzieren Sie den fehlschlagenden Fall auf die kleinste Funktion und Aufrufstelle, die ihn noch reproduziert. Grenzen Sie im Kommentarmodus ein, welche Funktionen virtualisiert werden.

Wenn Sie vmBytecodeArrayEncoding mit vmBytecodeArrayEncodingKeyGetter verwenden, muss der Getter exakt den beim Build verwendeten Schlüssel zurückgeben. Bei einem synchronen Getter muss der Schlüssel gesetzt sein, bevor der obfuskierte Code ausgeführt wird. Ein Getter, der ein Promise zurückgibt, erfordert vmAsyncExecutor. Fehlt eines davon, kann der Bytecode nicht decodiert werden.

Laufzeitkompatibilität · Schlüssel für Bytecode Array Encoding auslagern

3. Einen Fehlerbericht senden

Schreiben Sie eine E-Mail an support@obfuscator.io. Je mehr der folgenden Angaben Sie mitschicken, desto schneller können wir den Fehler beheben:

• Vollständiger Stack-Trace des Fehlers, genau so, wie er in der Konsole erscheint, nicht sinngemäß wiedergegeben.
• Obfuscator-Optionen als JSON. Kopieren Sie das gesamte verwendete Optionsobjekt (oder den Namen der Voreinstellung plus alle Überschreibungen). Subtile Wechselwirkungen zwischen Optionen sind häufig, daher benötigen wir genau diesen Satz.
• Build-Warnungen, falls vorhanden: type, message und functionName jeder Warnung.
• Obfuscator-Version - wird im Dashboard in der Versionsauswahl unter dem Editor angezeigt. Bei direkten API-Aufrufen ist es das Feld version der Nachricht result oder chunk_end. Beim Paket javascript-obfuscator erscheint sie in der Fortschrittsmeldung (Obfuscating with VM protection (vX.Y.Z)...), die die CLI ausgibt und obfuscatePro an seinen onProgress-Callback übergibt.
• Umgebung - Browser und Version, Node.js-Version, Betriebssystem, alles Ungewöhnliche an der Laufzeit (Erweiterungen, Polyfills, benutzerdefinierte Builtins).
• Minimale Reproduktion - idealerweise die einzelne Funktion aus Abschnitt 2 plus die Aufrufstelle, die zum Auslösen des Fehlers nötig ist.
• Der ursprüngliche (nicht obfuskierte) Quellcode, wenn möglich. Die obfuskierte Ausgabe ist auch für uns undurchsichtig; ohne die Eingabe müssten wir unseren eigenen Bytecode per Reverse Engineering entschlüsseln.

Ist der Quellcode proprietär, erwähnen Sie das in der E-Mail: Wir können eine Geheimhaltungsvereinbarung (NDA) unterzeichnen, bevor Sie ihn teilen. Ohne das Eingabemuster, das den fehlerhaften Bytecode erzeugt hat, können wir VM-Fehler nicht zuverlässig diagnostizieren; der zusätzliche Aufwand lohnt sich also.