Diagnosticar errores de la VM en tiempo de ejecución

Sigue estos pasos en orden. Cada uno descarta una causa habitual antes de que dediques tiempo a acotar el código que falla.

1. Descarta las defensas avanzadas

Un error que no tiene sentido para tu código, con mayor frecuencia RangeError: Invalid array length, suele significar que una compilación de producción se está ejecutando donde las compilaciones de producción no deben ejecutarse. VM Self Defending y VM Debug Protection rompen el código a propósito en ejecutores de pruebas y otras herramientas de automatización, navegadores headless, Node.js o jsdom ejecutando una compilación para navegador y navegadores con las DevTools abiertas. Antes que nada, comprueba dónde se ejecuta el código que falla.

Descarta primero las defensas avanzadas (VM Self Defending, VM Debug Protection, VM Domain Lock): reproduce el fallo con una compilación de pruebas que use las sobrescrituras de Pruebas y CI. Si la compilación de pruebas funciona, son las defensas las que reaccionan ante tus herramientas o tu entorno, no un fallo de tu código.

2. Comprueba la compatibilidad de ejecución y acota la función que falla

Comprueba que el target, el pipeline de compilación y cualquier declaración de entorno coincidan con el lugar donde el código se ejecuta realmente.

Si una compilación notifica advertencias de cobertura como VMNoFunctionsToVirtualize, consulta Ofuscación VM para ver qué cubre la protección VM.

Reduce el caso que falla a la función y el punto de llamada más pequeños que sigan reproduciéndolo. Usa el modo comment para acotar qué funciones se virtualizan.

Si usas vmBytecodeArrayEncoding con vmBytecodeArrayEncodingKeyGetter, el getter debe devolver exactamente la clave usada en la compilación. Un getter síncrono necesita que la clave esté establecida antes de que se ejecute el código ofuscado. Un getter que devuelve una Promise requiere vmAsyncExecutor. Si falta cualquiera de las dos cosas, el bytecode no puede decodificarse.

Compatibilidad de ejecución · Clave de Bytecode Array Encoding

3. Envía un informe de error

Escribe a support@obfuscator.io. Cuanto más de lo siguiente incluyas, antes podremos solucionarlo:

• La traza de pila completa del error, exactamente como aparece en la consola, no una paráfrasis.
• Las opciones del ofuscador en JSON. Copia el objeto de opciones completo que usaste (o el nombre del preajuste más las sobrescrituras). Las interacciones sutiles entre opciones son habituales, así que necesitamos el conjunto exacto.
• Las advertencias de la compilación, si las hay: el type, el message y el functionName de cada una.
• La versión del ofuscador, que se muestra en el selector de versión del panel, debajo del editor. En las llamadas directas a la API, es el campo version del mensaje result o chunk_end. Con el paquete javascript-obfuscator, aparece en el mensaje de progreso (Obfuscating with VM protection (vX.Y.Z)...), que la CLI imprime y que obfuscatePro pasa a su callback onProgress.
• El entorno: navegador y versión, versión de Node.js, sistema operativo y cualquier particularidad del entorno de ejecución (extensiones, polyfills, funciones integradas personalizadas).
• Una reproducción mínima, idealmente la función aislada de la sección 2, más el punto de llamada necesario para provocar el error.
• El código fuente original (antes de la ofuscación), siempre que sea posible. La salida ofuscada también es opaca para nosotros; sin la entrada estaríamos haciendo ingeniería inversa de nuestro propio bytecode.

Si el código fuente es propietario, indícalo en el correo: podemos firmar un NDA antes de que lo compartas. No podemos diagnosticar de forma fiable los errores de la VM sin ver el patrón de entrada que produjo el bytecode defectuoso, así que merece la pena el intercambio.