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. Tests und CI

Schließen Sie zuerst Laufzeitabwehrmaß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 Sie, ob target, die Build-Pipeline und alle Umgebungsangaben dazu passen, wo der Code tatsächlich läuft.

Der VM-Schutz gilt für geeignete Funktionen. Im Root-Modus kann vmWrapTopLevelInitializers außerdem geeignete Initialisierer für die Virtualisierung umschließen; die aktuellen VM-Voreinstellungen aktivieren dies. Prüfen Sie Abdeckungswarnungen wie VMNoFunctionsToVirtualize und wählen Sie sensible Funktionen im Kommentarmodus explizit aus.

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, und dieser Schlüssel muss bereits gesetzt sein, wenn der obfuskierte Code ausgeführt wird; andernfalls kann der Bytecode nicht dekodiert werden.

Laufzeitkompatibilität · Bytecode-Array-Encoding-Schlüssel

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 Builds über die API und das npm-Paket ist es das Feld version der API-Nachricht result oder chunk_end.
• Umgebung - Browser und Version, Node.js-Version, Betriebssystem, alles Ungewöhnliche an der Laufzeit (Erweiterungen, Polyfills, benutzerdefinierte Built-ins).
• 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.