Register-Based VM

L'option vmRegisterBased fait passer la VM de son bytecode à pile par défaut à un modèle d'exécution à registres. Dans certains cas, cela améliore les performances d'exécution de la VM d'environ 10 à 20 %, au prix d'un bundle obfusqué légèrement plus gros.

L'activer désactive Stateful Opcodes (vmStatefulOpcodes) : les deux sont incompatibles, donc si vmStatefulOpcodes était activé, le build à registres l'abandonne silencieusement.

VM à pile ou VM à registres

Une VM à pile conserve ses opérandes sur une pile implicite : chaque valeur est empilée, consommée par l'instruction suivante, et le résultat est de nouveau empilé. Une VM à registres adresse au contraire ses opérandes directement : le même travail s'exprime donc en moins d'instructions, sans empilements ni dépilements entre elles. C'est de là que vient le gain à l'exécution - et c'est aussi pourquoi le bytecode grossit légèrement, puisque chaque instruction doit désormais indiquer explicitement quels registres elle lit et écrit au lieu de les laisser implicites sur la pile.

Aucun des deux modèles ne change ce que fait votre code ni ce que la VM protège. Ce sont deux encodages de la même logique virtualisée ; le modèle à registres échange simplement un peu de taille contre un peu de vitesse.

Quand l'utiliser

Optez pour ce modèle lorsque le coût d'exécution de la VM compte. Le code virtualisé est par nature plus lent que du JavaScript classique : sur un chemin critique - une boucle d'animation, un gestionnaire appelé à chaque image, une routine d'analyse intensive - les quelque 10 à 20 % que l'exécuteur à registres peut faire gagner valent bien un bundle plus gros. Pour du code rarement exécuté, le surcoût en taille n'en vaut généralement pas la peine. Le gain dépend du code : mesurez-le donc sur vos propres chemins critiques.

Cela fait aussi varier la forme de la VM. Comme il produit un bytecode et un exécuteur structurellement différents, la sortie porte une empreinte différente de celle de la VM à pile courante. Une analyse générique fondée sur des motifs, réglée sur cette forme à pile, reconnaît moins facilement un build à registres : c'est donc une façon d'éloigner la VM livrée de la forme par défaut.

Fonctionnement interne

Il ne s'agit pas d'un compilateur natif à registres. Le compilateur à pile habituel génère toujours le bytecode exactement comme sans l'option ; une étape de transformation distincte réécrit ensuite ce bytecode sous forme à registres. Comme le modèle à registres intervient en aval de tout cela, la plus grande partie de l'obfuscation VM - ciblage, Bytecode Encoding, options du dispatcher - n'est pas affectée (hormis Stateful Opcodes, voir plus haut).

Prérequis

• Nécessite vmObfuscation - cette option ne fait que remodeler la VM produite par vmObfuscation.
• Obfuscateur en version 7.12.0 ou ultérieure.

Cette option est expérimentale. La réécriture à registres est plus récente et moins éprouvée que le chemin à pile par défaut : vérifiez donc que votre code s'exécute correctement avec vmRegisterBased activé avant de le livrer - le conseil vaut pour toute option VM, mais doublement ici.

Exemple

L'exécution à registres se combine avec le reste de l'obfuscation VM : Bytecode Encoding, Compact Dispatcher, VM Self Defending et VM Domain Lock fonctionnent tous exactement comme avec la VM à pile par défaut. Elle change la manière dont le bytecode est exécuté, pas les protections qui l'entourent.