VM Self Defending

Opcja vmSelfDefending dodaje do środowiska uruchomieniowego VM wielowarstwowe wykrywanie manipulacji, kontrole integralności kodu, ochronę przed hookowaniem oraz ochronę przed inżynierią wsteczną. W połączeniu z vmDebugProtection znacznie utrudnia zarówno analizę ręczną, jak i wspomaganą przez AI.

Ta opcja wymusza włączenie vmBytecodeArrayEncoding i zwiększa narzut wykonania VM. Zmierz go na własnych często wykonywanych ścieżkach.

To, jak reaguje każde wykrycie, oraz jak zgłaszać wykrycia do własnego backendu zamiast wyłącznie przerywać działanie, opisano w przewodniku Telemetria i reakcje zabezpieczeń VM; vmSelfDefending zgłasza wykrycia w kategoriach reakcji automation, debugger, tamper i integrity.

Zalecane: dla maksymalnej ochrony używaj razem z vmDebugProtection, vmBytecodeArrayEncodingKey i vmBytecodeArrayEncodingKeyGetter.

Zgodność środowiska

Wykrywanie wrażliwych środowisk

Ta opcja wiąże zobfuskowany kod z jego docelowym środowiskiem uruchomieniowym i wykorzystuje zaawansowany fingerprinting przeglądarki do wykrywania narzędzi automatyzacji. Kod chroniony tą opcją celowo przestanie działać, gdy zostanie uruchomiony w:

• przeglądarkach headless (headless Chrome/Chromium, PhantomJS)
• narzędziach do automatyzacji przeglądarki (Puppeteer, Playwright, Cypress, Selenium/ChromeDriver, Nightmare)
• Node.js (gdy target ma wartość browser)
• jsdom lub podobnych emulacjach DOM po stronie serwera
• środowiskach, w których natywne funkcje wbudowane przeglądarki zostały podpięte hookami lub podmienione (chyba że zadeklarowano to za pomocą browserEnvironment.hookedBuiltins)

Kod działa poprawnie w zwykłych przeglądarkach (Chrome, Firefox, Safari, Edge), również po wczytaniu w ramkach iframe, rozszerzeniach przeglądarki (content scripts) i Web Workerach.

Wybierz target dla rzeczywistego środowiska. Buildy Browser i Node zawierają różne zabezpieczenia: target node pomija te, które opierają się na API dostępnych tylko w przeglądarce, a build browser uruchomiony w Node przestaje działać, jak opisano wyżej.

Gdy browserEnvironment.hookedBuiltins ma wartość true (v7.15.0+), Self Defending toleruje środowisko uruchomieniowe, które legalnie podmienia natywne funkcje wbudowane na wrappery JavaScript, zamiast traktować je jako manipulację, dzięki czemu chroniony kod nadal tam działa. Celowo osłabia to wykrywanie hooków na funkcjach wbudowanych; wirtualizacja VM, VM Debug Protection i kontrole integralności pozostają nienaruszone. Pole transport tej samej opcji wiąże build ze schematem, przez który jest serwowany.

Self Defending sprawdza integralność własnego wyniku, więc nie minifikuj, nie formatuj ani w żaden inny sposób nie przepisuj później zobfuskowanego kodu. Uruchamiaj takie narzędzia na kodzie źródłowym przed krokiem obfuskacji.

Testy i CI

Te zabezpieczenia działają także przeciwko Twoim własnym agentom, automatyzacji i debuggerom. Mogą zatrzymać wykonanie, zgłosić niezwiązane z niczym błędy lub dać nieprawidłowe wyniki. Ta opcja ma zapobiegać zautomatyzowanej analizie i nie da się jej bezpiecznie używać z żadnym frameworkiem automatyzacji, dlatego testy funkcjonalne uruchamiaj na osobnym buildzie testowym z wyłączonym vmSelfDefending. Pełny zestaw nadpisań dla takiego builda znajdziesz w Testy i CI.