Browser Environment

Section

Pro

v7.9.0+

Deklarieren Sie, wie Ihr Produktions-Build ausgeliefert wird, damit der geschützte Code seine Integrität daran binden kann.

Die Option browserEnvironment deklariert Fakten über die Umgebung, in der Ihr Produktions-Build ausgeliefert wird, damit sich der geschützte Code an sie binden oder auf sie reagieren kann. Sie ist ein kleines Objekt, und jedes Feld wirkt zusammen mit genau einem bestimmten Schutz — für sich allein bewirkt die Option nichts:

browserEnvironment: { transport: 'https', hosting: 'remote' }

`transport`

Das Schema, über das Ihre Produktionsumgebung das Bundle ausliefert — 'http' oder 'https'. Wirkt zusammen mit vmSelfDefending.

Mit 'https' läuft eine Kopie, die ein Reverse Engineer über einfaches HTTP ausliefert, nicht korrekt. 'http' oder ein nicht gesetztes Feld fügt keinen solchen Schutz hinzu.

Ein Build mit der Deklaration transport: 'https' läuft nur dort korrekt, wo er tatsächlich über https: ausgeliefert wird. Jedes andere Schema beschädigt ihn; deklarieren Sie es daher nur, wenn jeder Kontext, der Ihren Produktions-Build lädt, HTTPS verwendet. Ausgeschlossen sind:

einfaches http://, einschließlich http://localhost in der Entwicklung;
file:// — Electron, Cordova und andere paketierte Apps;
blob:- und about:-Einbettungen — ein Bundle, das in einem about:blank- oder srcdoc-iframe läuft.

Eine clientseitige HTTP→HTTPS-Weiterleitung rendert dennoch zuerst die HTTP-Seite, daher darf das Bundle nicht laufen, bevor die Weiterleitung abgeschlossen ist.

`hosting`

Woher Ihr Produktions-Bundle ausgeliefert wird — 'remote' oder 'local'. Wirkt zusammen mit vmDebugProtection, und nur für die Targets browser und browser-no-eval. Erfordert Obfuscator-Version 7.14.0 oder neuer.

Mit 'remote' wird eine Kopie, die ein Reverse Engineer abgreift und in seiner eigenen lokalen Umgebung ausführt, als Abweichung der Laufzeitumgebung behandelt, und die Automatisierungs-Abwehr reagiert so, wie es vmDefenseReaction vorgibt. 'local' oder ein nicht gesetztes Feld fügt keinen solchen Schutz hinzu.

Ein Build mit der Deklaration hosting: 'remote' läuft nur dann korrekt, wenn er von einem entfernten Host geladen wird. Ein Bundle, das aus einer lokalen Umgebung geöffnet wird — localhost, ein Dev-Server, file:// — wird absichtlich als Abweichung behandelt. Deklarieren Sie es daher nur, wenn jeder Kontext, der Ihren Produktions-Build lädt, entfernt ausgeliefert wird, und lassen Sie es aus den Builds für lokale Entwicklung, Tests und CI heraus.

`hookedBuiltins`

Setzen Sie es auf true, um zu deklarieren, dass die Laufzeitumgebung, in der Ihr Produktions-Build läuft, native Builtins legitim durch JavaScript-Wrapper ersetzt — der eigene Manipulationsschutz der App, die Host-Seite oder andere Browser-Erweiterungen im selben Realm. Wirkt zusammen mit vmSelfDefending. Erfordert Obfuscator-Version 7.15.0 oder neuer.

Self Defending behandelt ein ersetztes natives Builtin normalerweise als Manipulation und verhindert, dass der Build läuft. Mit hookedBuiltins: true toleriert es eine solche Umgebung, und der geschützte Code läuft weiterhin. false oder ein nicht gesetztes Feld behält das strikte Verhalten bei.

browserEnvironment: { hookedBuiltins: true }

hookedBuiltins lockert die Manipulationserkennung absichtlich: Sobald es gesetzt ist, wird auch ein Analyst nicht mehr gestoppt, der dieselben Builtins umhüllt, um Ihren Code zu untersuchen. Die VM-Virtualisierung, der Debugging-Schutz und die Integritätsprüfungen bleiben unberührt. Aktivieren Sie es nur, wenn Ihre Produktions-Laufzeitumgebung bekanntermaßen Builtins hookt und diese schwächere Garantie akzeptabel ist.

Unterstützte Targets

browserEnvironment gilt nur für die Targets browser, browser-no-eval und service-worker. Für node, userscript und bytenode wird die Option abgelehnt — die Obfuskation schlägt mit einem Validierungsfehler fehl, statt die Einstellung stillschweigend zu verwerfen. hosting ist noch enger gefasst: Es wird für einen Service Worker akzeptiert, bindet dort aber nichts.

Im Dashboard befinden sich die Steuerungen Transport, Hosting und Hooked Builtins im Bereich „Advanced Protection“. Jede wird erst editierbar, sobald der zugehörige Schutz aktiv ist — VM Self Defending für Transport und Hooked Builtins, VM Debug Protection für Hosting — und das Target sie unterstützt.

Voraussetzungen

transport und hookedBuiltins wirken zusammen mit vmSelfDefending, hosting mit vmDebugProtection; andernfalls bewirkt keines von ihnen etwas.
Ein Target browser, browser-no-eval oder service-worker (browser oder browser-no-eval für hosting).
Obfuscator-Version 7.9.0 oder neuer für transport, 7.14.0 oder neuer für hosting, 7.15.0 oder neuer für hookedBuiltins.

Beispiel

JavaScriptObfuscator.obfuscate(code, {
    vmObfuscation: true,
    vmSelfDefending: true,
    vmDebugProtection: true,
    target: 'browser',
    browserEnvironment: { transport: 'https', hosting: 'remote' }
});

Zurück

VM Domain Lock

Weiter

Das NPM-Paket verwenden