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 15-20 %, au prix d’un bundle obfusqué légèrement plus gros.

À pile ou à registres

Une VM à pile garde les opérandes sur une pile implicite : chaque valeur est empilée, consommée par l’instruction suivante, et le résultat réempilé. Une VM à registres adresse ses opérandes directement, de sorte que le même travail s’exprime en moins d’instructions et sans trafic d’empilage/dépilage entre elles. C’est de là que vient le gain d’exécution — et aussi pourquoi le bytecode grossit un peu, puisque chaque instruction doit désormais préciser 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

Utilisez-la lorsque le coût d’exécution de la VM compte. Le code virtualisé est plus lent que du JavaScript ordinaire par conception, donc sur un chemin chaud — une boucle d’animation, un gestionnaire par image, une routine de parsing serrée — les ~15-20 % que l’exécuteur à registres peut économiser valent le bundle plus gros. Sur du code qui s’exécute rarement, le coût en taille n’en vaut généralement pas la peine.

Elle varie aussi la forme de la VM. Parce qu’elle émet un bytecode et un exécuteur structurellement différents, la sortie porte une empreinte plus singulière que la VM à pile par défaut. Si vous voulez que la VM livrée ressemble peu à la version courante à pile — afin qu’elle soit moins reconnaissable par une analyse générique fondée sur des motifs —, c’est une manière de la modifier.

Comment cela fonctionne en interne

Ce n’est pas 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. La conséquence pratique est que tout le reste de l’obfuscation VM — ciblage, encodage du bytecode, les options du dispatcher — se comporte de la même façon, car le modèle à registres se situe en aval de tout cela.

Prérequis

• Nécessite vmObfuscation — cette option ne fait que remodeler la VM produite par vmObfuscation.
• Version de l’obfuscateur 7.12.0 ou ultérieure.

Exemple

JavaScriptObfuscator.obfuscate(code, {
    vmObfuscation: true,
    vmRegisterBased: true
});