Externalisierung des Bytecode-Array-Verschlüsselungsschlüssels

Was diese Optionen bewirken

vmBytecodeArrayEncoding verschlüsselt das VM-Bytecode-Array, sodass es nicht als Klartext in der Ausgabe vorliegt. Standardmäßig wird der Verschlüsselungsschlüssel aus der Umgebung abgeleitet und auf dem Client rekonstruiert, sodass Sie ihn nie selbst handhaben. Das ist praktisch, aber das Schlüsselmaterial befindet sich weiterhin im Bundle.

Zwei Optionen ermöglichen es Ihnen, den Schlüssel aus dem Bundle herauszunehmen und selbst zu kontrollieren:

• vmBytecodeArrayEncodingKey - der Schlüssel, den Sie zur Kompilierzeit angeben. Wenn gesetzt, wird er anstelle des standardmäßig aus der Umgebung abgeleiteten Schlüssels verwendet und ist in der obfuskierten Ausgabe nicht eingebettet.
• vmBytecodeArrayEncodingKeyGetter - ein JavaScript-Ausdruck, der denselben Schlüssel zur Laufzeit zurückgibt. Er wird wortwörtlich eingebettet und im Browser ausgewertet, wenn der obfuskierte Code geladen wird.

Der Kernpunkt ist die Trennung: Da der Schlüssel nicht im Code steht, kann ihn ein rein statischer Scan des Bundles nicht wiederherstellen. Er muss zur Laufzeit dennoch vorhanden sein, damit der Code läuft, ist also nicht wirklich geheim - aber Sie entscheiden, woher er stammt und wer ihn zu sehen bekommt.

Diese beiden Optionen bilden ein Paar. vmBytecodeArrayEncodingKey ohne Getter lässt dem obfuskierten Code keine Möglichkeit, den Schlüssel zur Laufzeit zu beschaffen, und ein Getter ohne passenden Kompilierzeit-Schlüssel hat nichts, womit er übereinstimmen könnte. Setzen Sie beide, zusammen mit vmBytecodeArrayEncoding: true.

Wie die beiden Schlüssel kombiniert werden

Ihr Schlüssel wird niemals allein verwendet - auf beiden Seiten wird er mit einem internen Schlüssel vermischt, den der Obfuskator kontrolliert:

• Kompilierzeit. vmBytecodeArrayEncodingKey wird mit einem internen Schlüssel kombiniert, den der Obfuskator ableitet, und das Bytecode-Array wird mit dem resultierenden gemischten Schlüssel codiert.
• Laufzeit. Der Wert, zu dem Ihr vmBytecodeArrayEncodingKeyGetter aufgelöst wird, wird mit demselben internen Schlüssel kombiniert - auf dem Client aus verschiedenen Laufzeitfaktoren rekonstruiert -, um den Bytecode zu decodieren.

Da beide Seiten Ihren Schlüssel mit dem internen Schlüssel vermischen, muss der Getter zu exakt derselben Zeichenkette aufgelöst werden, die Sie als vmBytecodeArrayEncodingKey übergeben haben. Kein Teil genügt für sich allein: Ihr Schlüssel kann ohne den internen Schlüssel den Bytecode nicht decodieren, und der interne Schlüssel ist ohne Ihren nutzlos - weshalb die Kontrolle darüber, wer Ihren Schlüssel erhält, das ist, was den Code tatsächlich schützt.

Den Schlüssel zur Laufzeit bereitstellen

Standardmäßig ist der Getter synchron: Der Ausdruck muss den Schlüssel sofort zurückgeben, wenn der obfuskierte Code geladen wird. Lesen Sie ihn aus einer beliebigen Quelle, die bereits auf dem Client vorhanden ist - einem Cookie, localStorage, einer globalen Variable oder einem serverseitig injizierten DOM-Element.

Der Schlüssel muss vor der Ausführung des obfuskierten Codes existieren:

Andere synchrone Quellen funktionieren genauso - wählen Sie diejenige, die Ihre App bereits befüllt:

Halten Sie den Schlüssel aus derselben Datei oder demselben Skript wie den obfuskierten Code heraus. Ihn dort direkt einzufügen macht den gesamten Zweck zunichte - ein statischer Scan des Bundles würde sowohl den Code als auch seinen Schlüssel wiederherstellen. Speichern Sie ihn in einer separaten Quelle und injizieren Sie den Kompilierzeit-vmBytecodeArrayEncodingKey aus einer Umgebungsvariablen oder einem Secret, anstatt ihn zu committen.

Den Schlüssel von Ihrem Backend abrufen (async)

Erfordert vmAsyncExecutor · v7.3.0+

Ein synchroner Getter kann nur lesen, was bereits auf dem Client vorhanden ist. Um den Schlüssel von Ihrem Server abzurufen - sodass Sie ihn hinter einer Authentifizierung absichern und widerrufen können -, muss der Getter asynchron sein, und das erfordert vmAsyncExecutor. Wenn der Async-Executor aktiviert ist, darf der Getter ein Promise zurückgeben, und die VM wartet darauf, bevor sie ausgeführt wird.

Ein Promise zurückgebender Getter erfordert vmAsyncExecutor. Dies kann nicht zur Build-Zeit geprüft werden, daher schlägt ein Promise-Getter mit deaktiviertem vmAsyncExecutor zur Laufzeit fehl - der Decoder erhält das Promise-Objekt anstelle der Schlüssel-Zeichenkette.

Autorisieren Sie die Schlüsselausgabe mit einer geprüften Sitzung und erforderlichen Lizenzprüfungen. Origin oder Referer allein authentifizieren niemanden; bei gleichursprünglichen GET-Anfragen kann Origin fehlen. Deaktivieren Sie das Caching. Ordnen Sie Schlüssel der richtigen Build-Version zu und veröffentlichen Sie Schlüssel und Bundle gemeinsam. Ein Client mit Schlüssel kann ihn zur Laufzeit untersuchen.

Wenn der Schlüssel nicht übereinstimmt

Der obfuskierte Code funktioniert nur, wenn der Getter exakt denselben Schlüssel zurückgibt, der bei der Obfuskation verwendet wurde. Wenn sich die Schlüssel unterscheiden - oder der Getter undefined, null oder eine leere Zeichenkette zurückgibt -, erzeugt die Entschlüsselung einen falschen Keystream und der Code schlägt zur Laufzeit mit Datenmüll als Ausgabe oder einem gewöhnlichen Laufzeitfehler fehl.

Es gibt bewusst keine eigene, schlüsselspezifische Fehlermeldung: Ein fehlgeschlagener Schlüssel ist von jedem anderen Laufzeitfehler nicht zu unterscheiden. Wenn ein VM-geschütztes Bundle also erst dann einen Fehler wirft, sobald diese Option im Spiel ist, prüfen Sie zuerst den Schlüsselpfad - dass der Getter auf der Seite aufgelöst wird, eine nicht leere Zeichenkette zurückgibt und denselben Wert zurückgibt, mit dem Sie gebaut haben.