Документация
/

Решение проблем

/

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

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

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

1. Тестирование и CI

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

2. Совместимость со средой

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

VM-защита применяется к подходящим функциям. В режиме root vmWrapTopLevelInitializers также может оборачивать подходящие инициализаторы для виртуализации; текущие VM-пресеты его включают. Изучайте предупреждения о покрытии, например VMNoFunctionsToVirtualize, и используйте режим комментариев, чтобы явно выбирать чувствительные функции.

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

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

Совместимость со средой · Ключ для Bytecode Array Encoding

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

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

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

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