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. Wyklucz zaawansowane zabezpieczenia

Błąd, który nie pasuje do Twojego kodu, najczęściej RangeError: Invalid array length, zwykle oznacza, że build produkcyjny działa tam, gdzie buildy produkcyjne nie powinny działać. VM Self Defending i VM Debug Protection celowo psują kod w test runnerach i innych narzędziach automatyzacji, w przeglądarkach headless, w Node.js lub jsdom uruchamiających build przeglądarkowy oraz w przeglądarkach z otwartymi DevTools. Zanim zrobisz cokolwiek innego, sprawdź, gdzie działa kod, który zawodzi.

Najpierw wyklucz zaawansowane zabezpieczenia (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. Sprawdź zgodność środowiska i zawęź błędną funkcję

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

Jeśli build zgłasza ostrzeżenia o pokryciu, takie jak VMNoFunctionsToVirtualize, zobacz Obfuskacja VM, aby dowiedzieć się, co obejmuje ochrona VM.

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. Getter synchroniczny wymaga, aby klucz był ustawiony przed uruchomieniem zobfuskowanego kodu. Getter zwracający Promise wymaga vmAsyncExecutor. Jeśli któregoś z tych warunków brakuje, 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 bezpośrednich wywołań API jest to pole version komunikatu result lub chunk_end. W pakiecie javascript-obfuscator pojawia się ona w komunikacie postępu (Obfuscating with VM protection (vX.Y.Z)...), który wypisuje CLI i który obfuscatePro przekazuje do swojego callbacku onProgress.
• Ś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.