Browser Environment

L'opzione browserEnvironment dichiara alcuni fatti sull'ambiente in cui viene servita la tua build di produzione, così che il codice protetto possa vincolarsi a essi o reagire di conseguenza. È un piccolo oggetto, e ogni campo ha effetto solo insieme a una protezione specifica: da sola l'opzione non fa nulla:

transport

Lo schema con cui la produzione serve il bundle: 'http' o 'https'. Ha effetto con vmSelfDefending.

Con 'https', una copia servita via HTTP semplice da chi ne fa reverse engineering non funzionerà correttamente. 'http' o un campo non impostato non aggiunge questa protezione.

Una build dichiarata transport: 'https' funziona correttamente solo dove viene effettivamente servita via https:. Ogni altro schema la corrompe, quindi dichiaralo solo quando ogni contesto che carica la build di produzione usa HTTPS. Sono esclusi:

• http:// semplice, incluso http://localhost in sviluppo;
• file:// - Electron, Cordova e altre app pacchettizzate;
• le incorporazioni blob: e about: - un bundle in esecuzione dentro un iframe about:blank o srcdoc.

Un redirect HTTP→HTTPS lato client mostra comunque prima la pagina HTTP, perciò il bundle non deve essere eseguito prima che il redirect si sia completato.

hosting

Da dove viene servito il bundle di produzione: 'remote' o 'local'. Ha effetto con vmDebugProtection, e solo sui target browser e browser-no-eval. Richiede l'offuscatore in versione 7.14.0 o successiva.

Con 'remote', una copia che un reverse engineer estrae ed esegue nel proprio ambiente locale viene trattata come una discrepanza dell'ambiente di esecuzione, e le difese anti-automazione reagiscono secondo quanto configurato in vmDefenseReaction. 'local' o un campo non impostato non aggiunge questa protezione.

Una build dichiarata con hosting: 'remote' funziona correttamente solo quando viene caricata da un host remoto. Un bundle aperto da un ambiente locale (localhost, un server di sviluppo, file://) viene trattato come discrepanza per progettazione: dichiaralo quindi solo quando ogni contesto che carica la tua build di produzione è servito da remoto, e tienilo fuori dalle build che usi per sviluppo locale, test e CI.

hookedBuiltins

Impostalo su true per dichiarare che il runtime in cui gira la tua build di produzione sostituisce legittimamente le funzioni native (builtin) con wrapper JavaScript: l'anti-tamper dell'app stessa, la pagina host o altre estensioni del browser che condividono lo stesso realm. Ha effetto con vmSelfDefending. Richiede l'offuscatore in versione 7.15.0 o successiva.

Normalmente Self Defending tratta una funzione nativa sostituita come una manomissione e impedisce l'esecuzione della build. Con hookedBuiltins: true tollera un ambiente del genere e il codice protetto continua a funzionare. false o un campo non impostato mantiene il comportamento rigoroso.

hookedBuiltins allenta deliberatamente il rilevamento delle manomissioni: una volta impostato, nemmeno un analista che avvolge quelle stesse funzioni native per ispezionare il tuo codice viene più fermato. La virtualizzazione della VM, le protezioni anti-debug e i controlli di integrità non sono interessati. Abilitalo solo quando è noto che il tuo runtime di produzione esegue hooking sulle funzioni native e quella garanzia più debole è accettabile.

Target supportati

browserEnvironment si applica solo ai target browser, browser-no-eval e service-worker. Per node, userscript e bytenode l'opzione viene rifiutata: l'offuscamento fallisce con un errore di validazione invece di scartare silenziosamente l'impostazione. hosting è ancora più ristretto: viene accettato su un service worker, ma lì non vincola nulla.

Nella dashboard, i controlli Transport, Hosting e Hooked Builtins si trovano nel pannello Advanced Protection. Ciascuno diventa modificabile solo quando la protezione a cui è abbinato è attiva (VM Self Defending per Transport e Hooked Builtins, VM Debug Protection per Hosting) e il target lo supporta.

Requisiti

• transport e hookedBuiltins hanno effetto con vmSelfDefending, hosting con vmDebugProtection; altrimenti nessuno di essi fa nulla.
• Un target browser, browser-no-eval o service-worker (browser o browser-no-eval per hosting).
• Offuscatore in versione 7.9.0 o successiva per transport, 7.14.0 o successiva per hosting, 7.15.0 o successiva per hookedBuiltins.

Esempio