Navegadores Chromium parcheados: explicación

¿Qué es un navegador Chromium parcheado?

Un navegador Chromium parcheado es un build de Chromium cuyo código fuente se ha modificado para eliminar las huellas que lo identifican como un navegador automatizado. Los cambios van compilados. Cuando el binario arranca, las señales que normalmente lo delatarían ya no están: variables inyectadas, flags reveladores, propiedades del runtime fuera de lugar.

Es distinto de los plugins stealth como puppeteer-extra-stealth, que sobrescriben propiedades con JavaScript al cargar la página. Los shims en runtime dejan su propio rastro. Los builds parcheados no, porque aquello que se iba a sobrescribir nunca estuvo ahí.

Los proyectos más usados son undetected-chromedriver, rebrowser-patches, Patchright (un fork de Playwright), nodriver y, en el lado de Firefox, camoufox. La premisa compartida: arreglar el leak en C++, no en JavaScript. Desde que Chrome unificó sus bases de código headful y headless en noviembre de 2022, buscar la cadena `HeadlessChrome` en el user-agent ya casi no atrapa nada (Castle, 2025).

Por qué el Chromium parcheado importa ahora

Si lanzas Puppeteer o Selenium con la configuración por defecto contra un sitio con detección real, pierdes. `navigator.webdriver` es `true` por especificación cuando una herramienta de automatización controla el navegador, y cualquier JavaScript en la página lo lee en una línea. El string `$cdc_asdjflasutopfhvcZLmcfl_` que ChromeDriver inyecta en cada página es igual de fácil de detectar con una regex (DataDome, 2024). A eso se suman las propiedades del runtime que difieren entre un navegador real y uno controlado: plugins que faltan, `navigator.languages` vacío, `screen.colorDepth` incorrecto, ausencia de `window.chrome`.

Arreglar cada uno de estos leaks es un cambio de una línea. Por eso un navegador parcheado se monta en aproximadamente una hora, y por eso con esa hora solo se superan las comprobaciones de un sistema de detección de 2019. Los sistemas modernos miran otra cosa.

Tipos de técnicas de Chromium parcheado

El ecosistema se divide en tres generaciones, cada una apuntando a una capa distinta del stack de automatización.

**Primera generación: parches de superficie de fingerprint.** undetected-chromedriver renombra las variables `$cdc_` en el binario de ChromeDriver, y rebrowser-patches modifica el código de Puppeteer y Playwright para que no activen el dominio Runtime en cada carga. Estos parches se aplican una vez a la instalación de automatización y persisten entre releases hasta que el upstream cambia lo suficiente como para romperlos.

**Segunda generación: parches a nivel de protocolo.** Patchright (un fork de Playwright mantenido como `patchright` y `patchright-python`) ejecuta JavaScript a través de `Page.createIsolatedWorld` para que la página nunca vea los eventos que busca la detección. Los parches se escriben a nivel C++, no como wrappers JavaScript, porque los wrappers JavaScript introducen sus propios side-effects detectables.

**Tercera generación: frameworks post-CDP.** nodriver y su fork asíncrono zendriver controlan el navegador con APIs del sistema operativo: mueven el ratón vía APIs del SO y teclean vía eventos de teclado, así que no existe sesión CDP que un detector pueda ver. Camoufox hace lo mismo en Firefox parcheando el protocolo Juggler a nivel de C++ antes de compilar, con `navigator.hardwareConcurrency`, strings del renderer de WebGL y geometría de pantalla ajustados a lo que reportaría un navegador real.

Castle resume el cambio así: los frameworks anti-detect modernos son más dirigidos — en lugar de aplicar decenas de evasiones, se concentran en un conjunto más pequeño de señales potentes de bajo nivel, principalmente las introducidas por los protocolos de automatización del navegador (Castle, 2025).

Mantener tu propio fork de Chromium es caro, y por eso casi nadie lo hace. Chrome libera una nueva versión mayor cada cuatro semanas (proyecto Chromium). Cada release mueve código, renombra estructuras internas y abre nuevas superficies de detección. Los parches en sí son pequeños, a menudo un puñado de líneas en un handler concreto de Runtime o Page, pero cada cuatro semanas hay que rebasarlos, probarlos contra los sistemas de detección en producción y compilar un binario nuevo antes de que el anterior quede obsoleto. La larga interrupción en el mantenimiento de camoufox durante casi todo 2025 ilustra lo que pasa cuando una sola persona carga con el trabajo. Por eso Bright Data, Browserless y servicios similares llenan el hueco ofreciendo Chromium parcheado como API gestionada. La contrapartida: benchmarks independientes encuentran que el flag de automatización del CDP sigue siendo legible desde dentro del navegador en todas las sesiones que sirven (benchmark de ScrapeOps, 2026).

Cómo funciona el Chromium parcheado

Puppeteer, Playwright y Selenium hablan con Chromium por el mismo canal: el Chrome DevTools Protocol (CDP), una interfaz WebSocket para depuración. Alrededor del 95 % de las acciones automatizadas terminan pasando por `Page.evaluate`, la forma en que CDP ejecuta JavaScript dentro de la página (Rebrowser, 2024). `Page.evaluate` requiere activar el dominio `Runtime` de CDP, y esa activación emite eventos observables desde la página.

Durante años, el patrón estándar de detección consistía en colocar un objeto Error con un getter personalizado en `.stack`, llamar a `console.debug()` sobre él y ver si el getter se disparaba. Si lo hacía, el dominio Runtime estaba serializando el objeto por el WebSocket. En mayo de 2025, dos commits en V8 liquidaron ese truco: Avoid error side effects in DevTools el 7 de mayo y Apply getter guard throughout error preview el 9 de mayo. Desde entonces los getters definidos por el usuario ya no se ejecutan durante la previsualización de errores (Castle, 2025). El check basado en `console.debug` dejó de funcionar, y la mayoría de los proveedores tardaron meses en notarlo.

El ecosistema se mueve hacia abajo en el stack. Cada vez que se publica una señal de detección, los parches bajan una capa más cerca del metal.

Cómo identificar navegadores parcheados

Detectar un fingerprint headless es fácil de eludir. Detectar comportamiento no. Las señales que sobreviven al parcheo son las que dependen de *cómo* se usa el navegador, no de cómo se ve al cargar la página. Trayectorias de ratón en líneas rectas entre elementos. Ritmos de tecleo idénticos entre sesiones. Formularios rellenados más rápido de lo que un humano podría leer. Patrones de sesión que se repiten en intervalos de peticiones que ningún usuario real genera.

La escala del tráfico automatizado en la web actual fuerza este cambio. Cloudflare midió en 2025 que alrededor del 30 % de todo el tráfico de internet eran bots, y durante la primera semana de marzo de 2025 más del 94 % de las peticiones de autenticación venían de bots (Cloudflare, 2025). Imperva observa cada día más de 10.000 IPs únicas ejecutando Headless Chrome para scraping y carding (Imperva, 2024). A ese volumen, un sistema de detección que solo mira una petición aislada está midiendo ruido. A principios de 2025, puppeteer-extra-stealth, durante años la forma estándar de ocultar automatización, dejó de saltarse Cloudflare de forma fiable, y los mantenedores pararon la actividad (ZenRows, 2025; Castle, 2025).

Cómo responder cuando los parches se adaptan

Los navegadores parcheados son una carrera armamentística. Cada vez que un proveedor de detección publica una señal nueva, los autores de parches bajan una capa más cerca del metal. La pregunta para cualquier defensor es si su propio stack de detección se refresca a la misma cadencia.

Monitoriza las señales que siguen disparándose contra automatización conocida. Cuando un check antes fiable se apaga — como le pasó al truco del getter `console.debug` tras los commits de V8 de mayo de 2025 — ese es el momento de auditar el resto del stack contra tráfico fresco. Las señales conductuales aguantan más que las señales de fingerprint porque dependen de cómo usa la automatización el navegador, no de qué es el navegador. Mantén la base de firmas refrescada con una cadencia fija (nuevo Chromium, nuevo release de Patchright, nuevo cambio de CDP) y emparéjala con una capa conductual que un solo commit en V8 no pueda apagar.

Conclusiones clave

- Los builds de Chromium parcheados eliminan huellas de automatización en C++ antes de compilar, no con JavaScript al cargar la página. Los checks de `HeadlessChrome` y el flag `navigator.webdriver` atrapan herramientas viejas y nada más. - Tres generaciones de parches bajan por el stack: superficie de fingerprint (undetected-chromedriver, rebrowser-patches), nivel de protocolo (Patchright, isolated worlds) y post-CDP (nodriver, zendriver, camoufox). - Los commits de V8 de mayo de 2025, que desactivaron los getters de usuario durante la previsualización de errores, mataron el check CDP de `console.debug` de la noche a la mañana. Los proveedores que dependían de esa señal única corrieron ciegos durante meses. - Lo que sigue funcionando es la detección multi-señal que combina fingerprints a nivel de petición con patrones conductuales a lo largo de una sesión. Cuando el 94 % de las peticiones de autenticación están automatizadas (Cloudflare, 2025), un detector de un único flag ya está por detrás. Centinel corre señales de runtime contra más de 1.600 firmas de crawler más análisis conductual en el edge.