Diagnosticare gli errori di runtime della VM

Segui questi passaggi nell'ordine indicato. Ciascuno esclude una causa comune prima che tu dedichi tempo a circoscrivere il codice che fallisce.

1. Escludi le difese avanzate

Un errore che non ha senso per il tuo codice, il più delle volte RangeError: Invalid array length, di solito significa che una build di produzione è in esecuzione dove le build di produzione non devono girare. VM Self Defending e VM Debug Protection rompono il codice di proposito nei test runner e in altri strumenti di automazione, nei browser headless, in Node.js o jsdom che eseguono una build per browser e nei browser con i DevTools aperti. Prima di tutto, controlla dove viene eseguito il codice che fallisce.

Per prima cosa escludi le difese avanzate (VM Self Defending, VM Debug Protection, VM Domain Lock): riproduci l'errore con una build di test che usa le sovrascritture di Test e CI. Se la build di test funziona, sono le difese a reagire ai tuoi strumenti o al tuo ambiente, non il tuo codice a rompersi.

2. Verifica la compatibilità di esecuzione e circoscrivi la funzione che fallisce

Verifica che il target, la pipeline di build e le eventuali dichiarazioni sull'ambiente corrispondano al luogo in cui il codice viene effettivamente eseguito.

Se una build segnala avvisi di copertura come VMNoFunctionsToVirtualize, consulta Offuscamento VM per sapere che cosa copre la protezione VM.

Riduci il caso che fallisce alla funzione e al punto di chiamata più piccoli che riproducono ancora il problema. Usa la modalità comment per restringere le funzioni da virtualizzare.

Se usi vmBytecodeArrayEncoding con vmBytecodeArrayEncodingKeyGetter, il getter deve restituire esattamente la chiave usata in fase di build. Un getter sincrono richiede che la chiave sia impostata prima dell'esecuzione del codice offuscato. Un getter che restituisce una Promise richiede vmAsyncExecutor. Se manca uno dei due requisiti, il bytecode non può essere decodificato.

Compatibilità di esecuzione · Esternalizzare la chiave di Bytecode Array Encoding

3. Inviare una segnalazione di bug

Scrivi a support@obfuscator.io. Più informazioni tra le seguenti includi, più velocemente possiamo risolvere il problema:

• Lo stack trace completo dell'errore, esattamente come appare nella console, non una parafrasi.
• Le opzioni dell'offuscatore in formato JSON. Copia l'intero oggetto delle opzioni che hai usato (oppure il nome del preset più le eventuali sovrascritture). Le interazioni sottili tra le opzioni sono frequenti, quindi ci serve l'insieme esatto.
• Gli avvisi della build, se presenti: il type, il message e la functionName di ciascuno.
• La versione dell'offuscatore, mostrata nel selettore di versione della dashboard sotto l'editor. Per le chiamate API dirette, è il campo version del messaggio result o chunk_end. Con il pacchetto javascript-obfuscator, compare nel messaggio di avanzamento (Obfuscating with VM protection (vX.Y.Z)...), che la CLI stampa e che obfuscatePro passa alla sua callback onProgress.
• L'ambiente: browser e versione, versione di Node.js, sistema operativo, qualsiasi particolarità del runtime (estensioni, polyfill, funzioni integrate personalizzate).
• Una riproduzione minima, idealmente la singola funzione della sezione 2, più il punto di chiamata necessario a provocare l'errore.
• Il sorgente originale (prima dell'offuscamento), quando possibile. Anche per noi l'output offuscato è opaco; senza l'input dovremmo fare reverse engineering del nostro stesso bytecode.

Se il sorgente è proprietario, indicalo nell'email: possiamo firmare un NDA prima che tu lo condivida. Non possiamo diagnosticare in modo affidabile i bug della VM senza vedere lo schema di input che ha prodotto il bytecode difettoso, quindi vale la pena di questo passaggio in più.