Diagnozowanie błędów wykonania VM

Wykonaj poniższe kroki po kolei. Każdy z nich wyklucza częstą przyczynę, zanim poświęcisz czas na zawężanie błędnego kodu.

1. Testy i CI

Najpierw wyklucz zabezpieczenia wykonania (VM Self Defending, VM Debug Protection, VM Domain Lock): odtwórz błąd na buildzie testowym z nadpisaniami opisanymi w Testy i CI. Jeśli build testowy działa, to zabezpieczenia reagują na Twoje narzędzia lub środowisko, a nie psują Twojego kodu.

2. Zgodność środowiska

Sprawdź, czy target, pipeline builda i wszelkie deklaracje środowiska odpowiadają miejscu, w którym kod faktycznie działa.

Ochrona VM obejmuje kwalifikujące się funkcje. W trybie root opcja vmWrapTopLevelInitializers może również opakować kwalifikujące się inicjalizatory, aby poddać je wirtualizacji; obecne presety VM ją włączają. Sprawdzaj ostrzeżenia o pokryciu, takie jak VMNoFunctionsToVirtualize, i używaj trybu komentarzy, aby jawnie wskazać wrażliwe funkcje.

Zredukuj błędny przypadek do najmniejszej funkcji i miejsca wywołania, które nadal odtwarzają problem. Użyj trybu komentarzy, aby zawęzić zbiór wirtualizowanych funkcji.

Jeśli używasz vmBytecodeArrayEncoding razem z vmBytecodeArrayEncodingKeyGetter, getter musi zwracać dokładnie ten klucz, który został użyty podczas builda, a klucz ten musi być już ustawiony w chwili uruchomienia zobfuskowanego kodu; w przeciwnym razie kodu bajtowego nie da się odkodować.

Zgodność środowiska · Klucz Bytecode Array Encoding

3. Wyślij zgłoszenie błędu

Napisz na support@obfuscator.io. Im więcej z poniższych informacji dołączysz, tym szybciej naprawimy problem:

• Pełny stos wywołań błędu, dokładnie w takiej postaci, w jakiej pojawia się w konsoli, a nie jego parafrazę.
• Opcje obfuskatora w formacie JSON. Skopiuj cały użyty obiekt opcji (albo nazwę presetu wraz ze wszystkimi nadpisaniami). Subtelne interakcje między opcjami są częste, więc potrzebujemy dokładnego zestawu.
• Ostrzeżenia builda, jeśli wystąpiły: type, message i functionName każdego z nich.
• Wersję obfuskatora, widoczną w selektorze wersji w panelu pod edytorem. W przypadku buildów przez API i pakiet npm jest to pole version komunikatu result lub chunk_end z API.
• Środowisko: przeglądarkę i jej wersję, wersję Node.js, system operacyjny i wszystko, co nietypowe w środowisku uruchomieniowym (rozszerzenia, polyfille, niestandardowe obiekty wbudowane).
• Minimalną reprodukcję, najlepiej pojedynczą funkcję z sekcji 2 oraz miejsce wywołania potrzebne do wywołania błędu.
• Oryginalny kod źródłowy (sprzed obfuskacji), jeśli to możliwe. Zobfuskowany wynik jest nieprzejrzysty również dla nas; bez danych wejściowych musielibyśmy stosować inżynierię wsteczną wobec własnego kodu bajtowego.

Jeśli kod źródłowy jest poufny, napisz o tym w wiadomości: możemy podpisać NDA, zanim go udostępnisz. Bez wglądu we wzorzec wejściowy, który wygenerował wadliwy kod bajtowy, nie jesteśmy w stanie wiarygodnie zdiagnozować błędów VM, więc ta dodatkowa wymiana wiadomości się opłaca.