Диагностика ошибок выполнения VM

Выполняйте эти шаги по порядку. Каждый из них исключает распространённую причину, прежде чем вы потратите время на поиск падающего кода.

1. Исключите продвинутые защиты

Ошибка, которая не вяжется с вашим кодом, чаще всего RangeError: Invalid array length, обычно означает, что продакшен-сборка запущена там, где продакшен-сборкам запускаться нельзя. VM Self Defending и VM Debug Protection намеренно ломают код в тест-раннерах и других средствах автоматизации, в headless-браузерах, в Node.js или jsdom, запускающих сборку для браузера, и в браузерах с открытыми DevTools. Прежде всего проверьте, где выполняется код, который падает.

Сначала исключите продвинутые защиты (VM Self Defending, VM Debug Protection, VM Domain Lock): воспроизведите сбой на тестовой сборке с переопределениями из раздела Тестирование и CI. Если тестовая сборка работает, значит, защиты реагируют на ваши инструменты или окружение, а не ломают ваш код.

2. Проверьте совместимость со средой и найдите падающую функцию

Проверьте, что target, конвейер сборки и все объявления окружения соответствуют тому, где код на самом деле выполняется.

Если сборка сообщает предупреждения о покрытии, например VMNoFunctionsToVirtualize, о том, что охватывает VM-защита, читайте в разделе VM-обфускация.

Сократите падающий случай до минимальной функции и места вызова, на которых проблема ещё воспроизводится. Используйте режим комментариев, чтобы сузить набор виртуализируемых функций.

Если вы используете vmBytecodeArrayEncoding с vmBytecodeArrayEncodingKeyGetter, геттер должен возвращать ровно тот ключ, который использовался при сборке. Синхронному геттеру нужно, чтобы ключ был задан до запуска обфусцированного кода. Геттер, возвращающий Promise, требует vmAsyncExecutor. Если одно из этих условий не выполнено, байт-код не удастся декодировать.

Совместимость со средой · Вынос ключа для Bytecode Array Encoding

3. Отправьте отчёт об ошибке

Напишите на support@obfuscator.io. Чем больше из перечисленного вы приложите, тем быстрее мы сможем всё исправить:

• Полная трассировка стека ошибки в точности в том виде, в каком она появляется в консоли, а не пересказ.
• Опции обфускатора в формате JSON. Скопируйте весь использованный объект опций (или название пресета вместе со всеми переопределениями). Неочевидные взаимодействия между опциями встречаются часто, поэтому нам нужен точный набор.
• Предупреждения сборки, если они есть: type, message и functionName каждого.
• Версия обфускатора - она показана в селекторе версий панели управления под редактором. Для прямых вызовов API это поле version сообщения result или chunk_end. С пакетом javascript-obfuscator она указана в сообщении о прогрессе (Obfuscating with VM protection (vX.Y.Z)...), которое выводит CLI и которое obfuscatePro передаёт в свой коллбэк onProgress.
• Окружение - браузер и его версия, версия Node.js, ОС, любые особенности среды выполнения (расширения, полифилы, собственные встроенные объекты).
• Минимальное воспроизведение - в идеале одна функция из раздела 2 плюс место вызова, необходимое, чтобы вызвать ошибку.
• Исходный (до обфускации) код, если возможно. Обфусцированный результат непрозрачен и для нас; без входных данных нам приходится заниматься реверс-инжинирингом собственного байт-кода.

Если код проприетарный, укажите это в письме - мы можем подписать NDA до того, как вы им поделитесь. Без паттерна во входном коде, который привёл к сломанному байт-коду, мы не можем надёжно диагностировать ошибки VM, так что лишний обмен письмами того стоит.