VM Debug Protection

Opcja vmDebugProtection dodaje do środowiska uruchomieniowego VM mechanizmy przeciwdziałające debugowaniu, dzięki czemu inżynieria wsteczna chronionego kodu staje się znacznie trudniejsza. Reakcję na każde wykrycie określają kategorie debugger, automation i sandbox opcji vmDefenseReaction.

Gdy browserEnvironment.hosting ma wartość 'remote' (v7.14.1+), Debug Protection wiąże też build z serwowaniem ze zdalnego hosta: kopia serwowana z lokalnego hosta deweloperskiego jest traktowana jako niezgodność środowiska uruchomieniowego, a zabezpieczenia przed automatyzacją reagują.

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. Do testów funkcjonalnych używaj osobnego builda testowego; opcje nadpisywane w takim buildzie pokazuje strona Testy i CI.

Wykrywanie inspektora

Od wersji obfuskatora 8.0.0 opcja vmDebugProtection przyjmuje obiekt, a nie tylko wartość logiczną. Przekazanie obiektu pozostawia Debug Protection włączone, a łagodzi działanie jednego detektora:

inspectorDetection (domyślnie włączone) wykrywa podłączony inspektor Chrome DevTools Protocol lub aktywny debugger i na niego reaguje. Otwarcie narzędzi deweloperskich przeglądarki podłącza taką sesję, więc otwarty inspektor zostaje wykryty i wywołuje reakcję. W produkcji pozostaw tę opcję włączoną; wyłącz ją tylko wtedy, gdy Twoi użytkownicy mają uzasadniony powód, by otwierać narzędzia deweloperskie. W panelu jest to przełącznik podrzędny Inspector Detection w VM Debug Protection (v8.0.0+), który pojawia się po włączeniu Debug Protection.

Po wykryciu kod wraca do działania dopiero po przeładowaniu strony. Zamknięcie narzędzi deweloperskich nie przywraca chronionego kodu: dopóki strona nie zostanie przeładowana, każde kolejne wywołanie rzuca błędy, które niczego nie wyjaśniają, np. Uncaught 0, albo przy reakcji decoy zwraca błędne wyniki. Przeładowanie oznacza utratę wszystkiego, czego użytkownik nie zapisał. Aby to zapisać lub najpierw wyświetlić komunikat, uruchom własną reakcję w vmDefenseHook, który jest wywoływany, zanim zareaguje mechanizm obrony. Dla chronionego kodu narzędzia deweloperskie i inne narzędzia łączące się przez ten sam protokół wyglądają tak samo, więc pozwalając użytkownikom otwierać narzędzia deweloperskie, wpuszczasz też te narzędzia.

Frameworki automatyzacji. Przy włączonym inspectorDetection (domyślnie) sterowanie chronioną stroną za pomocą narzędzia opartego na CDP (Puppeteer, Playwright, Selenium/ChromeDriver) jest wykrywane jako podłączony inspektor. vmDebugProtection: { inspectorDetection: false } wyłącza tylko detektor inspektora; detektor automatyzacji w Debug Protection nadal może reagować na sterowaną przeglądarkę. W przypadku buildów do testów automatycznych postępuj zgodnie z przewodnikiem Testy i CI, który wyłącza vmDebugProtection i vmSelfDefending.

Content Security Policy

Jeśli Twoja Content Security Policy zabrania dynamicznego wykonywania kodu (brak unsafe-eval), użyj targetu browser-no-eval i zweryfikuj wynik przy tej polityce. Ten target stosuje rozwiązanie zastępcze dla kontroli, które w przeciwnym razie opierają się na dynamicznym wykonywaniu kodu. To samo dotyczy rozszerzeń przeglądarki z restrykcyjną CSP: dla najlepszej zgodności używaj browser-no-eval.