Cómo eliminar la tarjeta de detección del sitio: encontramos los scripts de huellas digitales por nuestra cuenta

```html

El 20 de agosto de 2026, el desarrollador Matt Callaghan (blog laserphile) publicó un análisis de un extraño error: sus auriculares Bluetooth con multipunto dejaban de cambiar de la computadora al teléfono cada vez que se abría una pestaña de AliExpress. No se puso a adivinar: instrumentó las API del navegador y observó qué sucedía dentro de la página. Resultó que dos scripts ofuscados del stack antifraude de Alibaba levantaban el contexto de audio y tomaban la huella del dispositivo a través de un sonido que nadie escucha.

Esta es una ilustración perfecta de lo que casi nadie hace antes de configurar perfiles o lanzar un parser: no lee el stack de detección de la plataforma, sino que lo adivina. A continuación, se presenta un método práctico para crear un mapa de detección de un sitio específico por su cuenta, en una hora, sin revertir la ofuscación y sin servicios de pago.

¿Por qué crear un mapa de detección?

El ciclo típico se ve así: las cuentas son bloqueadas — ajustamos la configuración del navegador antidetección al azar — cambiamos proxies — nuevamente bloqueados. Entre "bloqueados" y "configuraciones" no hay datos: no está claro qué es lo que la plataforma está leyendo y en qué capa está detectando.

El mapa de detección cierra esta brecha. Es una lista: qué proveedor de protección está presente, qué scripts lo implementan, qué API tocan y a dónde va el resultado. Luego se puede ver dónde está realmente el punto crítico: en la IP, en la huella de red o en la capa de hardware del navegador. Esto es igualmente útil para tres audiencias:

• Multi-cuentas — entender qué señal une los perfiles. Tienen diferentes IP, pero el stack de audio, el renderizador WebGL y hardwareConcurrency a menudo son iguales para toda la granja.
• Scraping — entender si vale la pena levantar un navegador o si la tarea se resuelve con un cliente HTTP con una huella TLS correcta.
• Privacidad — ver qué es lo que la tienda o servicio recopila sobre su dispositivo además de las cookies.

Paso 1. Determinar el proveedor de protección a través de la red

Lo primero que debe hacer es abrir DevTools en la pestaña de Red, cargar la página y observar los encabezados y cookies del primer documento. Las marcas de identificación son conocidas y estables:

• CF-RAY en los encabezados de respuesta y la cookie cf_clearance — Cloudflare.
• Cookie _abck y script con la función bmak — Akamai Bot Manager.
• Variables y cookies con el prefijo _px — PerimeterX (HUMAN).
• Cookie datadome y un JS separado del dominio del proveedor — DataDome.
• Un 429 vacío sin cuerpo de respuesta — una firma característica de Kasada.

Si le da pereza hacerlo a mano, hay detectores abiertos como microlinkhq/is-antibot (30+ proveedores) y extensiones de navegador que detectan más de 26 proveedores. Proporcionan una respuesta rápida inicial, pero no responden a la pregunta principal: qué es exactamente lo que se mide en su navegador. Para eso hay que ir más allá.

Paso 2. Extraer la lista de scripts sospechosos

Filtre la Red por tipo JS y anote todo lo que se carga desde un dominio que no es el principal o que se encuentra en directorios de servicio. En el caso de AliExpress, estos fueron dos archivos con rutas claramente de servicio:

• assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
• assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

Señales de un script antifraude: código ofuscado, versión en la ruta, subdominio separado para estática, ausencia de cualquier conexión con la parte visual de la página. No es necesario abrir y leer la ofuscación: en el siguiente paso, el script se revelará por sí mismo.

Paso 3. Instrumentar el API de huellas digitales

Este es el núcleo del método y exactamente lo que hizo Callaghan: envolvió el constructor AudioContext y AudioNode.prototype.connect(), después de lo cual vio dos contextos de audio activos en la página, donde no hay ningún elemento multimedia y ninguna llamada a play().

La lógica es simple: reemplaza el método que te interesa con tu envoltura, que registra la llamada con el stack y pasa el control al original. El stack de llamadas muestra qué script específico llamó a la API. Es más conveniente insertar este snippet a través de DevTools Sources → Snippets o mediante una extensión que ejecute código en document-start — es importante hacerlo antes de que se cargue el script antifraude.

El conjunto mínimo de trampas que cubre la mayoría de las señales:

1. HTMLCanvasElement.prototype.toDataURL y getImageData — huella de canvas.
2. WebGLRenderingContext.prototype.getParameter — modelo de tarjeta gráfica y controlador, precisión de shaders.
3. AudioContext / OfflineAudioContext y AudioNode.prototype.connect — huella de audio.
4. Getters navigator.hardwareConcurrency, navigator.deviceMemory, navigator.plugins, navigator.webdriver.
5. RTCPeerConnection — WebRTC y direcciones locales.
6. screen.width/height, devicePixelRatio, Intl.DateTimeFormat().resolvedOptions() — pantalla y zona horaria.
7. navigator.mediaDevices.enumerateDevices — lista de dispositivos de audio y video.

Al final del proceso, tendrás una lista: cuáles de estas API fueron realmente llamadas, cuántas veces y por quién. En el caso analizado, los scripts de Alibaba tocaron el canvas y toDataURL, el renderizador WebGL y la precisión de los shaders, audio a través de osciladores y analizadores, tamaños de pantalla y devicePixelRatio, hardwareConcurrency y deviceMemory, plugins, soporte de códecs, WebRTC, tiempos de rendimiento, patrones de movimiento del ratón y toques, sensores de movimiento del dispositivo y propiedades indicadoras de automatización.

¿Qué hacían exactamente con el gráfico de audio?

Es útil entender cómo se ve la medición para reconocerla en otros lugares. El gráfico era así: oscilador en diente de sierra → AnalyserNode → ScriptProcessorNode, que lee el resultado del análisis → GainNode con ganancia cero → destination. No hay sonido, el volumen no importa — simplemente no existe. Pero la conexión a destination, según la formulación del autor, hace que el navegador procese activamente el gráfico, aunque el volumen final sea cero. Precisamente el tracto de audio activo mantenía abierto el camino Bluetooth, rompiendo el cambio multipunto de los auriculares.

Las diferencias en el procesamiento de esta señal dependen del procesador, hardware de sonido, sistema operativo, navegador y controladores — de ahí el identificador estable que sobrevive al cambio de IP y la limpieza de cookies. Un análisis detallado de esta capa y la configuración de perfiles para ella se encuentra en el artículo sobre protección contra Audio Context Fingerprinting.

Paso 4. Capturar el envío del resultado

La recopilación sin envío es inútil, por lo que el siguiente paso es encontrar a dónde va la huella recopilada. Filtra la Red por XHR/Fetch y observa por separado las solicitudes tipo ping — estas son generadas por navigator.sendBeacon, que los scripts de telemetría aman usar porque sobreviven al abandonar la página.

Prácticamente siempre es útil envolver adicionalmente fetch, XMLHttpRequest.prototype.send y navigator.sendBeacon — así verás el cuerpo de la solicitud antes de que se envíe. Prepárate para que el contenido esté serializado y cifrado: en el caso de AliExpress, los datos se cifraban antes de enviarse a la telemetría de Alibaba. Pero incluso así obtienes dos hechos: la dirección del receptor y el momento del envío en relación con tus acciones.

Si el sitio funciona no solo en el navegador, sino a través de una aplicación móvil o un cliente separado, la misma pregunta se resuelve a nivel de tráfico, no de DOM — la metodología de interceptación y análisis se describe en el análisis de auditoría de tráfico a través de mitmproxy.

Paso 5. Comparar el mapa con su perfil

Ahora tienes una lista de señales que la plataforma realmente lee. Solo queda verificar qué devuelve tu perfil de trabajo en estas señales. El orden es el siguiente: obtienes los valores en un navegador normal, luego en cada perfil de antidetección y comparas.

Dos cosas son importantes al mismo tiempo: los valores deben diferir entre perfiles y ser estables dentro de un mismo perfil entre sesiones. Un perfil cuya huella fluctúa en cada inicio parece para el antifraude tan sospechoso como diez perfiles con la misma huella.

Verifica por separado que la suplantación realmente existe en la capa necesaria. Aquí es revelador el rango entre navegadores: Firefox desde la versión 118 devuelve una salida constante de WebAudio, y según los datos del análisis, el 99,24% de los usuarios se reduce a tres valores; Brave inyecta datos aleatorios y desde el 22 de agosto de 2026 bloquea específicamente estos scripts de AliExpress, recordando que la protección contra la huella de audio ha estado habilitada por defecto durante más de seis años; Safari inyecta errores en los buffers de audio; Chrome no tiene protecciones agresivas.

Trampas

• El script ya ha tenido tiempo de ejecutarse. Bloquear el archivo no elimina el contexto de audio ya creado — el autor señala directamente que las pestañas abiertas deben cerrarse. Lo mismo se aplica a su instrumentación: si la envoltura se colocó después del script, no verá nada.
• El bloqueo rompe la funcionalidad. El stack antifraude a menudo responde también a cosas legítimas — autorización, pago, protección contra bots de abusos reales. Crear un mapa de detección y eliminar scripts son tareas diferentes; la segunda rompe el sitio.
• No hay una sola versión de detección. El stack puede diferir según la geolocalización, el tipo de dispositivo y el grupo A/B. Tiene sentido crear el mapa desde la IP y el dispositivo desde los cuales realmente trabajas, de lo contrario, estás describiendo una configuración ajena.
• La instrumentación en sí es detectable. Los métodos nativos redefinidos pierden el correcto toString, y un depurador conectado deja rastros. Para la exploración, esto no es crítico, pero no confundas un perfil de exploración con uno de combate — las técnicas de enmascaramiento de automatización se han analizado en la guía sobre enmascaramiento de navegadores sin cabeza.

Qué proxy se necesita para el resultado

La principal conclusión práctica de tal mapa casi siempre es una: la IP es solo la primera capa, y se verifica antes que todas las demás. Si el antifraude ya en la etapa de solicitud ve la dirección del hosting, simplemente no llegará al gráfico de audio y al canvas — recibirás un desafío o una salida vacía y estarás arreglando lo incorrecto.

Por lo tanto, la lógica de selección es la siguiente. Para plataformas con un stack serio (Akamai, DataDome, PerimeterX, desarrollos propios de nivel Alibaba), la base son proxies residenciales — direcciones de proveedores reales que no son bloqueadas en el primer filtro. Para aplicaciones móviles y plataformas donde la audiencia principal usa smartphones, los proxies móviles se acercan más al perfil natural: el CGNAT del operador hace que la dirección sea compartida entre muchos usuarios reales.

Y lo inverso también es cierto: si el mapa mostró que la plataforma se limita a encabezados y cookies, y no hay una huella de JS pesada, — una granja de navegadores es excesiva, la tarea se resuelve con un cliente HTTP normal y direcciones de centro de datos.

Conclusión

El caso de los auriculares es valioso no por el hecho mismo de la huella de audio — se ha sabido durante años. Es valioso el método: la persona no creyó en conjeturas, sino que envolvió dos métodos de la API del navegador y en una noche obtuvo una lista completa de lo que se le extrae y la dirección a donde va. El mismo truco toma una hora en cualquier plataforma con la que trabajes y reemplaza meses de ajustes al azar. Crea un mapa de detección antes de arreglar bloqueos — de lo contrario, existe el riesgo de gastar presupuesto en proxies donde el problema estaba en el mismo renderizador WebGL en todos los perfiles.