Externaliser la clé de chiffrement du tableau de bytecode

Ce que font ces options

vmBytecodeArrayEncoding chiffre le tableau de bytecode de la VM afin qu'il ne figure pas en clair dans la sortie. Par défaut, la clé de chiffrement est dérivée de l'environnement et reconstruite sur le client, de sorte que vous n'avez jamais à la manipuler. C'est pratique, mais le matériel de clé réside toujours dans le bundle.

Deux options vous permettent de sortir la clé du bundle et de la contrôler vous-même :

• vmBytecodeArrayEncodingKey - la clé que vous fournissez à la compilation. Lorsqu'elle est définie, elle est utilisée à la place de la clé par défaut dérivée de l'environnement, et elle n'est pas intégrée à la sortie obfusquée.
• vmBytecodeArrayEncodingKeyGetter - une expression JavaScript qui renvoie cette même clé à l'exécution. Elle est intégrée telle quelle et évaluée dans le navigateur au chargement du code obfusqué.

L'intérêt réside dans la séparation : comme la clé ne figure pas dans le code, une analyse purement statique du bundle ne peut pas la récupérer. Elle doit tout de même être présente à l'exécution pour que le code fonctionne, elle n'est donc pas véritablement secrète - mais vous décidez d'où elle provient et qui peut la voir.

Ces deux options forment une paire. vmBytecodeArrayEncodingKey sans getter laisse le code obfusqué sans aucun moyen d'obtenir la clé à l'exécution, et un getter sans clé de compilation correspondante n'a rien avec quoi concorder. Définissez les deux, avec vmBytecodeArrayEncoding: true.

Comment les deux clés se combinent

Votre clé n'est jamais utilisée seule - des deux côtés, elle est mélangée à une clé interne que l'obfuscateur contrôle :

• À la compilation. vmBytecodeArrayEncodingKey est combinée à une clé interne dérivée par l'obfuscateur, et le tableau de bytecode est encodé avec la clé mixte résultante.
• À l'exécution. La valeur à laquelle se résout votre vmBytecodeArrayEncodingKeyGetter est combinée à la même clé interne, reconstruite sur le client à partir de divers facteurs d'exécution, pour décoder le bytecode.

Comme les deux côtés mélangent votre clé à la clé interne, le getter doit se résoudre à exactement la même chaîne que celle que vous avez passée en tant que vmBytecodeArrayEncodingKey. Aucune des deux parties ne suffit à elle seule : votre clé sans la clé interne ne peut pas décoder le bytecode, et la clé interne est inutile sans la vôtre - c'est pourquoi contrôler qui reçoit votre clé est ce qui protège réellement le code.

Fournir la clé à l'exécution

Par défaut, le getter est synchrone : l'expression doit renvoyer la clé immédiatement au chargement du code obfusqué. Lisez-la depuis n'importe quelle source déjà présente sur le client - un cookie, localStorage, une variable globale ou un élément du DOM injecté par le serveur.

La clé doit exister avant l'exécution du code obfusqué :

D'autres sources synchrones fonctionnent de la même manière - choisissez celle que votre application renseigne déjà :

Gardez la clé hors du même fichier ou script que le code obfusqué. L'y intégrer en ligne ruine tout l'intérêt - une analyse statique du bundle récupérerait à la fois le code et sa clé. Stockez-la dans une source distincte, et injectez la clé de compilation vmBytecodeArrayEncodingKey depuis une variable d'environnement ou un secret plutôt que de la committer.

Récupérer la clé depuis votre backend (async)

Requiert vmAsyncExecutor · v7.3.0+

Un getter synchrone ne peut lire que ce qui se trouve déjà sur le client. Pour récupérer la clé depuis votre serveur - afin de pouvoir la protéger derrière une authentification et la révoquer -, le getter doit être asynchrone, ce qui requiert vmAsyncExecutor. Lorsque l'exécuteur asynchrone est activé, le getter peut renvoyer une Promise, et la VM l'attend avant de s'exécuter.

Un getter qui renvoie une Promise requiert vmAsyncExecutor. Cela ne peut pas être vérifié au moment du build ; ainsi, un getter renvoyant une Promise avec vmAsyncExecutor désactivé échoue à l'exécution - le décodeur reçoit l'objet Promise au lieu de la chaîne de la clé.

Autorisez la remise de la clé avec une session validée et les contrôles de licence nécessaires. Origin ou Referer seuls n’authentifient pas un client ; les GET de même origine peuvent omettre Origin. Désactivez la mise en cache. Associez les clés à la bonne version et déployez clés et bundles ensemble. Le client qui reçoit une clé peut l’examiner à l’exécution.

Lorsque la clé ne correspond pas

Le code obfusqué ne fonctionne que lorsque le getter renvoie exactement la même clé que celle utilisée lors de l'obfuscation. Si les clés diffèrent - ou si le getter renvoie undefined, null ou une chaîne vide -, le déchiffrement produit un mauvais flux de clé et le code échoue à l'exécution avec une sortie inutilisable ou une erreur d'exécution ordinaire.

Il n'existe volontairement aucun message d'erreur distinct et propre à la clé : une clé défaillante est indiscernable de toute autre défaillance à l'exécution. Ainsi, lorsqu'un bundle protégé par la VM ne lève une erreur qu'une fois cette option en jeu, vérifiez d'abord le chemin de la clé - que le getter se résout sur la page, renvoie une chaîne non vide et renvoie la même valeur que celle avec laquelle vous avez compilé.