Register-Based VM

Opcja vmRegisterBased przełącza VM z domyślnego kodu bajtowego opartego na stosie na rejestrowy model wykonania. W niektórych przypadkach poprawia to wydajność VM w czasie wykonania o około 10-20%, kosztem nieco większego zobfuskowanego bundle'a.

Jej włączenie wyłącza opcję Stateful Opcodes (vmStatefulOpcodes): obie opcje są ze sobą niezgodne, więc jeśli vmStatefulOpcodes było włączone, build rejestrowy po cichu z niego rezygnuje.

VM stosowa a VM rejestrowa

VM stosowa przechowuje operandy na niejawnym stosie: każda wartość jest odkładana, pobierana przez kolejną instrukcję, a wynik ponownie odkładany. VM rejestrowa adresuje natomiast swoje operandy bezpośrednio, więc ta sama praca wymaga mniejszej liczby instrukcji, bez operacji push/pop między nimi. Stąd bierze się zysk wydajności, i z tego samego powodu kod bajtowy nieco rośnie: każda instrukcja musi teraz jawnie określać, które rejestry odczytuje i zapisuje, zamiast pozostawiać je niejawnie na stosie.

Żaden z modeli nie zmienia tego, co robi Twój kod, ani tego, co chroni VM. To dwa sposoby zakodowania tej samej zwirtualizowanej logiki; wariant rejestrowy po prostu wymienia odrobinę rozmiaru na odrobinę szybkości.

Kiedy jej używać

Sięgnij po nią, gdy liczy się koszt wykonania VM. Zwirtualizowany kod z założenia jest wolniejszy od zwykłego JavaScriptu, więc na często wykonywanej ścieżce (pętla animacji, obsługa każdej klatki, intensywna procedura parsowania) około 10-20%, które może zaoszczędzić executor rejestrowy, jest warte większego bundle'a. W przypadku rzadko wykonywanego kodu koszt rozmiaru zwykle się nie opłaca. Zysk zależy od kodu, więc zmierz go na własnych często wykonywanych ścieżkach.

Zmienia też kształt VM. Ponieważ generuje strukturalnie inny kod bajtowy i executor, wynik ma odcisk palca odmienny od popularnej VM stosowej. Ogólna analiza oparta na wzorcach, dostrojona do kształtu stosowego, trudniej rozpoznaje build rejestrowy, więc jest to jeden ze sposobów, by odsunąć dostarczaną VM od domyślnej.

Jak to działa od środka

To nie jest natywny kompilator rejestrowy. Zwykły kompilator stosowy nadal generuje kod bajtowy dokładnie tak samo jak bez tej opcji; osobny etap transformacji przepisuje następnie ten kod bajtowy do postaci rejestrowej. Ponieważ wariant rejestrowy znajduje się za nimi wszystkimi w potoku, większość obfuskacji VM (wybór funkcji, kodowanie kodu bajtowego, opcje dispatchera) pozostaje bez zmian (z wyjątkiem Stateful Opcodes, zobacz wyżej).

Wymagania

• Wymaga vmObfuscation: ta opcja jedynie przekształca VM tworzoną przez vmObfuscation.
• Obfuskator w wersji 7.12.0 lub nowszej.

Ta opcja jest eksperymentalna. Przepisywanie do postaci rejestrowej jest nowsze i mniej sprawdzone w boju niż domyślna ścieżka stosowa, więc przed wdrożeniem sprawdź, czy Twój kod działa poprawnie z włączonym vmRegisterBased. Ta rada dotyczy każdej opcji VM, ale tutaj szczególnie.

Przykład

Wykonanie rejestrowe łączy się z resztą obfuskacji VM: Bytecode Encoding, Compact Dispatcher, VM Self Defending i VM Domain Lock działają dokładnie tak samo jak w przypadku domyślnej VM stosowej. Zmienia ono sposób wykonywania kodu bajtowego, a nie zabezpieczenia, które go otaczają.