Documentazione
/

Risoluzione dei problemi

/

Diagnosticare gli errori di runtime della VM

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. Test e CI

Per prima cosa escludi le difese di runtime (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. Compatibilità di esecuzione

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

La protezione VM si applica alle funzioni idonee. In modalità root, vmWrapTopLevelInitializers può anche avvolgere gli inizializzatori idonei per virtualizzarli; gli attuali preset VM lo attivano. Controlla gli avvisi di copertura come VMNoFunctionsToVirtualize e usa la modalità comment per selezionare esplicitamente le funzioni sensibili.

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, e quella chiave deve essere già impostata quando viene eseguito il codice offuscato; altrimenti il bytecode non può essere decodificato.

Compatibilità di esecuzione · 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 build tramite API e pacchetto npm, è il campo version del messaggio result o chunk_end dell'API.
  • 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ù.