Browser Environment

La opción browserEnvironment declara hechos sobre el entorno en el que se sirve tu compilación de producción, de modo que el código protegido pueda vincularse a ellos o reaccionar ante ellos. Es un objeto pequeño, y cada campo surte efecto junto con una protección concreta; por sí sola la opción no hace nada:

transport

El esquema por el que tu producción sirve el bundle: 'http' o 'https'. Surte efecto con vmSelfDefending.

Con 'https', una copia que un ingeniero inverso sirva por HTTP plano no funcionará correctamente. 'http' o un campo sin definir no añade esa protección.

Una compilación declarada con transport: 'https' funciona correctamente solo allí donde realmente se sirve por https:. Cualquier otro esquema la corrompe, así que decláralo únicamente cuando todos los contextos que cargan tu compilación de producción usen HTTPS. Eso excluye:

• http:// plano, incluido http://localhost en desarrollo;
• file:// - Electron, Cordova y otras apps empaquetadas;
• incrustaciones blob: y about: - un bundle que se ejecuta dentro de un iframe about:blank o srcdoc.

Una redirección HTTP→HTTPS del lado del cliente sigue renderizando primero la página HTTP, por lo que el bundle no debe ejecutarse antes de que la redirección se complete.

hosting

Desde dónde se sirve tu bundle de producción: 'remote' o 'local'. Surte efecto con vmDebugProtection, y solo en los targets browser y browser-no-eval. Requiere la versión 7.14.0 o posterior del ofuscador.

Con 'remote', una copia que un ingeniero inverso extraiga y ejecute en su propio entorno local se trata como una discrepancia del entorno de ejecución, y las defensas contra automatización reaccionan según lo configurado en vmDefenseReaction. 'local' o un campo sin definir no añade esa protección.

Una compilación declarada con hosting: 'remote' funciona correctamente solo cuando se carga desde un host remoto. Un bundle abierto desde un entorno local (localhost, un servidor de desarrollo, file://) se trata como una discrepancia por diseño, así que decláralo únicamente cuando todos los contextos que cargan tu compilación de producción se sirvan de forma remota, y déjalo fuera de las compilaciones que uses para desarrollo local, pruebas y CI.

hookedBuiltins

Establézcalo en true para declarar que el runtime en el que se ejecuta su build de producción reemplaza legítimamente los builtins nativos por wrappers de JavaScript: el propio anti-tamper de la aplicación, la página anfitriona u otras extensiones del navegador que comparten el mismo realm. Surte efecto con vmSelfDefending. Requiere la versión 7.15.0 o posterior del ofuscador.

Normalmente, Self Defending trata un builtin nativo reemplazado como una manipulación e impide que el build se ejecute. Con hookedBuiltins: true, tolera ese entorno y el código protegido sigue ejecutándose. false o un campo sin establecer mantiene el comportamiento estricto.

hookedBuiltins relaja deliberadamente la detección de manipulaciones: una vez establecido, un analista que envuelva esos mismos builtins para inspeccionar su código tampoco será detenido. La virtualización de la VM, las protecciones anti-depuración y las comprobaciones de integridad no se ven afectadas. Actívelo solo cuando se sepa que su runtime de producción intercepta (hooks) builtins y esa garantía más débil sea aceptable.

Targets admitidos

browserEnvironment solo se aplica a los targets browser, browser-no-eval y service-worker. Para node, userscript y bytenode la opción se rechaza: la ofuscación falla con un error de validación en lugar de descartar silenciosamente el ajuste. hosting es aún más restringido: se acepta en un service worker, pero allí no vincula nada.

En el panel, los controles Transport, Hosting y Hooked Builtins viven en la sección de Protección avanzada. Cada uno se vuelve editable cuando la protección con la que se empareja está activada (VM Self Defending para Transport y Hooked Builtins, VM Debug Protection para Hosting) y el target lo admite.

Requisitos

• transport y hookedBuiltins surten efecto con vmSelfDefending, y hosting con vmDebugProtection; de otro modo ninguno hace nada.
• Un target browser, browser-no-eval o service-worker (browser o browser-no-eval para hosting).
• Versión del ofuscador 7.9.0 o posterior para transport, 7.14.0 o posterior para hosting, 7.15.0 o posterior para hookedBuiltins.

Ejemplo