Documentación
/
Ofuscación VM
/

Browser Environment

Browser Environment

Pro
v7.9.0+

Declara cómo se sirve tu compilación de producción para que el código protegido pueda ligar a ella su integridad.

Ver

Obfuscator.io Advanced Defenses: Self-Defending, Debug Protection, Domain Lock

Ver en YouTube

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:

JavaScript

transport

El esquema por el que tu sitio de 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 que declara 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.1 o posterior del ofuscador.

Con 'remote', una copia servida desde un host de desarrollo local se trata como una discrepancia del entorno de ejecución, y las defensas contra automatización reaccionan según lo configurado en vmDefenseReaction (consulta Telemetría y reacciones de defensa de la VM). 'local' o un campo sin definir no añade esa protección.

Una compilación que declara hosting: 'remote' funciona correctamente solo cuando se carga desde un host remoto. Un bundle abierto desde un servidor de desarrollo local 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écelo en true para declarar que el runtime en el que se ejecuta tu compilación de producción reemplaza legítimamente funciones nativas integradas por envoltorios de JavaScript: el propio sistema antimanipulación 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 una función nativa integrada reemplazada como una manipulación e impide que la compilación 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.

JavaScript

hookedBuiltins relaja deliberadamente la detección de hooks sobre funciones integradas: una vez establecido, un analista que envuelva esas mismas funciones integradas para inspeccionar tu código tampoco será detenido. La virtualización de la VM, las protecciones antidepuración y las comprobaciones de integridad no se ven afectadas. Actívalo solo cuando sepas que tu runtime de producción intercepta funciones nativas integradas 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 no tiene efecto. 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 Defensas avanzadas. 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.1 o posterior para hosting, 7.15.0 o posterior para hookedBuiltins.

Ejemplo

JavaScript