Desde Chromium 148 se puede identificar el sistema operativo base con Math.tanh

 (scrapfly.dev)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Desde Chrome 148, Math.tanh de V8 llama a std::tanh del host en lugar del fdlibm integrado, por lo que la misma entrada devuelve bits finales distintos en glibc de Linux, libsystem_m de macOS y UCRT de Windows
  • Math.tanh(0.8) da 0.6640367702678491 en Linux, 0.664036770267849 en macOS y 0.6640367702678489 en Windows, lo que permite distinguir los tres sistemas operativos con una sola llamada; si el resultado no coincide con el sistema operativo que declara el User-Agent, la suplantación queda expuesta
  • La ruta de filtración varía según el motor: en Math.* de V8 solo tanh usa la biblioteca matemática del host, pero todas las funciones trigonométricas de CSS en Blink y algunas operaciones de Web Audio también pasan por bibliotecas específicas del sistema operativo
  • Si se perturban los valores de forma aleatoria, no coincidirán con ningún sistema operativo real y además se rompe la determinismo; por eso hay que reproducir bit a bit los coeficientes, tablas, reducción de rango y comportamiento FMA de la biblioteca objetivo, o mapear directamente el código original de UCRT
  • Scrapfly compara en cada release 871,000 entradas contra Macs reales y Chrome para verificar que Math.tanh y 7 funciones trigonométricas de CSS coincidan bit a bit, y ajusta no solo la precisión sino también las diferencias de arquitectura y el tiempo de ejecución al nivel de un navegador real

El sistema operativo que revela Math.tanh

  • El resultado de Math.tanh(0.8) cambia según la biblioteca matemática del host
    • glibc en Chrome para Linux: 0.6640367702678491
    • libsystem_m en Chrome para macOS: 0.664036770267849
    • UCRT en Chrome para Windows: 0.6640367702678489
  • Apple y glibc suelen diferir por 1 ULP en aproximadamente una cuarta parte de todas las entradas, mientras que Windows UCRT difiere de ambas bibliotecas en algunos puntos porcentuales de entradas
    • ULP (unit in the last place) es la distancia entre números de punto flotante consecutivos representables para una magnitud dada; 1 ULP es la mínima diferencia que puede representar un double
  • Al medir Chrome 150 real en Linux, macOS 26 sobre Apple Silicon y Windows 11 mediante DevTools Protocol, la capacidad de clasificación cambia según la entrada
    • tanh(0.5) es igual en los tres sistemas operativos: 0.46211715726000974, por lo que no sirve para detección
    • tanh(0.7) solo difiere en Linux por 1 ULP
    • tanh(0.8) es distinto en los tres sistemas operativos, con un rango total de 2 ULP
    • tanh(0.9) solo difiere en Windows por 1 ULP
  • En aproximadamente tres cuartas partes de las entradas, los tres sistemas operativos producen el mismo resultado, pero una sola entrada adecuada basta para obtener una firma por sistema operativo
  • Si se declara macOS pero se devuelven los bits matemáticos de Linux, el resultado de Math.tanh contradice al User-Agent

El cambio ocurrido en Chrome 148

  • Hasta Chrome 147, V8 calculaba Math.tanh con un port integrado de fdlibm, una implementación matemática portable, por lo que devolvía los mismos bits en todos los sistemas operativos
  • El commit de V8 c1486295ae5 reemplazó la implementación integrada por std::tanh de la plataforma
    • Este cambio se incluyó por primera vez en V8 14.8.57 y Chrome 148
    • Chrome 148, 149 y 150 exponen las diferencias del libm del host, pero Chrome 147 y anteriores no filtran el sistema operativo por esta ruta
  • IEEE 754 define cómo se almacena un double, pero no exige que funciones trascendentales como sin, cos, tanh o exp estén necesariamente redondeadas de forma correcta
  • La biblioteca matemática (libm) de cada sistema operativo equilibra rendimiento y error en ULP usando distintos coeficientes de polinomios de aproximación minimax, tablas de consulta y constantes de reducción de rango
    • Linux usa glibc
    • macOS usa Apple libsystem_m
    • Windows usa ucrtbase.dll de UCRT
  • Un detector no necesita analizar la operación matemática en sí: puede comparar el valor contra una tabla de resultados por entrada de Chrome real

Cuatro trampas que dificultan la reproducción

  • Solo se filtran algunas funciones de V8

    • V8 enlaza estáticamente la mayoría de sus implementaciones matemáticas, así que produce el mismo resultado sin importar el sistema operativo
    • Math.exp, Math.pow, Math.atan y otras usan la implementación integrada de llvm-libc
    • Math.sin y Math.cos usan rutinas integradas dbl-64 originadas en glibc
    • Desde Chrome 148, solo Math.tanh, que usa std::tanh de la plataforma, filtra el sistema operativo dentro de Math.*
    • Si se falsifican como si fueran del sistema operativo objetivo funciones que no filtran, se rompe la estructura real de llamadas de V8; incluso puede comprobarse la asimetría de que solo tanh sea diferente

  • JavaScript y CSS usan rutas distintas

    • sin(), cos() y atan2() de CSS no comparten código con Math.sin de JavaScript
    • El motor de layout Blink reduce los ángulos en grados y luego llama a std::sin de la plataforma, entre otras funciones, sobre el valor reducido
    • El resultado difiere del cálculo directo con entrada en radianes, y las 7 funciones trigonométricas de CSS filtran el sistema operativo a través del libm del host
    • Para reproducir bit a bit hay que incluir no solo la función matemática final, sino también la reducción de rango en grados y la conversión entre radianes y grados

  • Dentro de macOS hay dos bibliotecas distintas

    • En Apple Silicon conviven el libsystem_m escalar y las rutinas vectoriales vvsin, vvtanh de Accelerate, y ambas implementaciones no son iguales
    • En un millón de entradas, los resultados difirieron entre 10% y 89% según la función
    • cos(0) es exactamente 1.0 en la implementación escalar
    • En Accelerate devuelve 0.9999999999999999
    • Se mide Chrome en un Mac real mediante el protocolo de depuración para distinguir qué biblioteca se usa en cada punto de llamada
    • Math.tanh, las funciones trigonométricas de CSS y las funciones trascendentales por muestra del compresor de audio usan el libsystem_m escalar
    • El DSP de Web Audio en Mac, FFT, matemáticas vectoriales y filtros biquad usan Accelerate
    • Entre las rutas relacionadas de Chromium están fft_frame_mac.cc, vector_math_mac.h, biquad.cc y BUILDFLAG(IS_MAC)
    • Si se elige una biblioteca de Apple que no corresponde al punto de llamada, muchas entradas pueden quedar desfasadas por 1 ULP

  • La arquitectura de CPU también interviene en el resultado

    • ARM y x86 muestran diferencias en fused multiply-add (FMA) y en la propagación del signo de NaN
    • Aunque el procedimiento matemático sea correcto, si el compilador fusiona una multiplicación y una suma solo en una arquitectura, los bits del resultado cambian

Rutas de filtración por motor y funcionalidad

  • Math.* de V8 en JavaScript usa casi siempre implementaciones integradas; el único punto conectado al libm del host es Math.tanh
    • sin, cos, tan, asin, acos, atan, atan2, exp, log, log2, log10 y pow usan implementaciones integradas de V8
    • sqrt, abs y las cuatro operaciones aritméticas son operaciones de hardware
  • Las funciones matemáticas de calc() en CSS hacen que Blink llame directamente a la biblioteca de la plataforma
    • sin, cos, tan, asin, acos, atan, atan2, exp, log, log2, log10 y pow usan el libm del host
    • En CSS no existe una ruta correspondiente para tanh
  • Web Audio mezcla varias implementaciones según el punto de llamada
    • En Mac, la FFT del oscilador, suma, multiplicación y escalado vectoriales, y FFT usan vDSP de Accelerate
    • Funciones trascendentales por muestra en DynamicsCompressor, como sin, exp, log10f y powf, usan el libsystem_m escalar
    • Un solo grafo de audio puede atravesar tres bibliotecas: matemáticas integradas de V8, biblioteca escalar y Accelerate
  • WebAssembly no tiene instrucciones para funciones trascendentales
    • El resultado de sin y similares queda determinado por el libm incluido en el módulo
    • Aritmética como f64.sqrt y f64.mul se ejecuta en hardware, por lo que es igual entre sistemas operativos
    • Los ejes de fingerprinting restantes son la normalización de NaN entre ARM y x86, y algunas diferencias de redondeo en SIMD
  • Las señales de detección se concentran en Math.tanh, todas las funciones trigonométricas de CSS y Web Audio
    • La FFT de Accelerate en Web Audio revela la arquitectura de CPU
    • El libsystem_m escalar del compresor revela el sistema operativo

Reproducir con exactitud en lugar de perturbar los valores

  • Por qué falla el ruido

    • Si se agrega ruido al resultado, puede no coincidir con ningún valor real de sistema operativo en la tabla de referencia
    • Si el valor aleatorio cambia en cada llamada, se rompe la determinismo, y ese fenómeno se convierte en otra señal de detección
    • El objetivo no es obtener un valor parecido, sino un resultado bit a bit idéntico al que devuelve el sistema operativo declarado

  • Restaurar todos los elementos del algoritmo objetivo

    • Se recuperan del libm objetivo los coeficientes de aproximación minimax, tablas de exponentes y constantes de reducción de rango, y se trasladan a código C portable
    • Incluso las entradas que la biblioteca objetivo redondea en la dirección incorrecta deben coincidir exactamente
    • La reproducción de sin de Apple usa el patrón exacto de bits de los coeficientes extraídos de libsystem_m y llamadas explícitas a fma()
    • Si los coeficientes se pasan a decimal, pueden volver a redondearse durante la transcripción, por lo que se preservan como valores de punto flotante hexadecimales
    • Cada multiplicación-suma que Apple fusiona también se fusiona explícitamente en el código

  • Fijar FMA de forma determinista

    • Se compila con -ffp-contract=off para impedir que el compilador agregue o elimine FMA arbitrariamente
    • Solo los fma() explícitos del código se ejecutan en las mismas posiciones que Apple, por lo que se obtienen los mismos bits incluso al imitar ARM en un servidor x86
    • El FMA de hardware y un FMA de software correctamente redondeado devuelven los mismos bits

Uso del código original de Windows UCRT

  • Windows UCRT usa la misma ISA x86-64 que un servidor Linux y es independiente de posición, por lo que se puede mapear el ucrtbase.dll real en memoria en tiempo de ejecución y llamar directamente a los exports de funciones matemáticas
  • Como se ejecuta el código original, se obtienen los bits reales de UCRT sin ingeniería inversa adicional del algoritmo matemático
  • Hay que manejar la diferencia entre la ABI System V de Linux y la ABI x64 de Windows
    • En Windows x64, el callee usa un shadow space de 32 bytes encima de la dirección de retorno
    • El conjunto de registros preservados por el callee también difiere de System V
    • Si el puntero a función no se declara como ms_abi, las escrituras en el shadow space corrompen el stack frame de clang y la llamada indirecta puede saltar a una dirección incorrecta
  • El código del DLL mapeado no es un destino de llamada indirecta registrado en CFI
    • En producción, -fsanitize=cfi-icall puede provocar una trampa #UD y SIGILL en cada llamada
    • El wrapper que llama al puntero a función necesita clang::no_sanitize("cfi-icall")
  • Las funciones matemáticas de UCRT leen al inicio un flag de despacho de CPU con mov eax, [rip+disp32] para elegir la ruta escalar o FMA/AVX2
    • En un DLL recién mapeado, el flag es 0, así que elige la ruta escalar lenta
    • El resultado de esa ruta difiere en bits del resultado de sistemas Windows modernos
    • Hay que encontrar la dirección del flag en el prólogo de tanh y forzar la ruta FMA antes de la primera llamada para coincidir bit a bit con Windows real

Puntos de parcheo y restricciones de rendimiento

  • Se engancha el único cuello de botella donde el motor llama a libm, y se elige la ruta según el sistema operativo que declara el navegador
    • Si declara Linux, se conserva glibc
    • Si declara macOS, se usa la implementación de reproducción de Apple
  • Aunque el resultado sea exacto, puede detectarse si el tiempo de ejecución difiere del de un navegador real
  • La primera compilación tenía una línea base x86 por defecto más antigua que FMA de hardware, por lo que todos los fma() se degradaban a llamadas de software y era entre 2.5 y 6 veces más lenta que la nativa
  • Al comparar la proporción de tiempos en bucles de Math.tanh y Math.sin, pueden revelarse patrones de rendimiento inexistentes en un navegador real
  • Al habilitar FMA de hardware, cada operación fusionada se convirtió en una sola instrucción y aceleró alrededor de 6 veces; además, quedó más rápida que glibc manteniendo idénticos los bits del resultado

Validación con 871,000 entradas

  • El harness de validación ejecuta en cada release 871,000 entradas que cubren todas las ramas y dominios
    • grilla densa de entradas
    • límites de intervalos
    • subnormales
    • cero con signo
    • infinito
    • NaN
  • Se usan dos tipos de entornos reales como valores de referencia
    • Un Mac real calcula en todas las entradas los resultados escalares y de Accelerate por separado para identificar dónde divergen las dos implementaciones
    • Chrome en un Mac real se controla mediante el protocolo de depuración para recolectar resultados de precisión completa de Math.tanh y de todas las funciones trigonométricas de CSS
  • Math.tanh y sin, cos, tan, asin, acos, atan, atan2 de CSS coinciden bit a bit con Chrome real en Mac
  • También se verifica que la implementación de reproducción se comporte igual que el código máquina real dentro del binario distribuido
  • Hay que igualar incluso el posprocesamiento del navegador en los límites del dominio
    • En un Mac real, CSS asin(2) está fuera del dominio, por lo que se convierte en NaN, y CSS limita NaN a 0; el valor final es 0
    • Una implementación de reproducción simple podría devolver erróneamente 90 grados

Por qué las matemáticas importan en la suplantación de navegadores

  • Los resultados matemáticos pueden comprobarse de forma determinista y barata, pero para suplantarlos con precisión hay que conocer el interior del libm del proveedor y las rutas de llamada de cada motor
  • Para coincidir con un navegador real hay que saber qué biblioteca matemática eligen V8, Blink y Web Audio en cada punto de llamada, y ajustar el último bit, el comportamiento por arquitectura y hasta el tiempo de ejecución
  • Scrapium de Scrapfly está configurado para que, cuando se le pide presentarse como macOS, incluso los bits de redondeo del coseno coincidan con el tráfico real de macOS

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios en Hacker News

  • La explicación de que el resultado de llamar una vez a tanh con la entrada de la derecha se vuelve una firma por sistema operativo pasa por alto que también podría identificar un rango de versiones del navegador
    La mayoría no falsifica el sistema operativo del User-Agent, y el fingerprinting se interesa más por combinaciones de rasgos semiúnicos que por el sistema operativo en sí. El hallazgo es interesante, pero el texto está demasiado escrito por LLM y eso le quita credibilidad.

    • La empresa que hizo este artículo en realidad intenta disfrazar bots en VMs Linux como si fueran equipos físicos con Windows o macOS
      Así pueden pasar más fácilmente la detección de bots y vender a clientes datos recolectados de otros sitios web.
    • Por ahora, con este método solo puede determinarse que es Chromium 148 o superior, pero si se inspeccionan con JavaScript o CSS las funciones de V8 y Blink añadidas en cada versión, se puede fijar con certeza la versión mayor desde alrededor de la 120
      El hecho de que fue escrito con LLM se reveló en el artículo y en el blog; no se ocultó ni se fingió ser humano. Por falta de tiempo, de otro modo no habrían podido publicar el artículo, y están dispuestos a asumir esa decisión.
    • Se puede identificar un rango de versiones, pero ya existen incontables medios para hacerlo
      El navegador sigue añadiendo funciones y corrigiendo errores, y la mayoría de ellos puede detectarse con JavaScript.
    • Si el contenido es cierto, no importa quién lo escribió, y el argumento central del LLM también es válido.

  • Es una estrategia inteligente: analizar con IA todas las técnicas de fingerprinting y publicarlas, y tras la polémica empujar a los navegadores a bloquearlas, para que su negocio de scraping gane más dinero
    Si no existieran empresas así, el fingerprinting del navegador no estaría tan extendido como ahora y internet sería mejor. Preferiría más bien textos del lado opuesto con intereses claros, como fingerprint.js.

    • No estoy de acuerdo; con o sin scrapers, para rastrear humanos se necesita fingerprinting, y tarde o temprano se iba a usar.

  • Hay otra razón más para impulsar las funciones trascendentales con redondeo correcto
    Hace poco me enteré de que este problema en la práctica ya está resuelto. Vean la segunda ponencia magistral de https://arith2026.org/program.html.

    • Las funciones libm con redondeo correcto son excelentes, pero no deben tener un peor caso de rendimiento terrible, como pasó con pow de glibc en el pasado
      Se podría mejorar el peor caso vectorizando manualmente con SLP la ruta alternativa de alta precisión usada cerca del umbral de redondeo, pero para la mayoría de usos ya es suficiente. Sorprende que los motores de JavaScript no sigan usando fdlibm, recomendado por la especificación ECMAScript, y si Math.tanh es una ruta crítica en JavaScript, sería un código bastante extraño.
    • Cuesta entender por qué la precisión fija y la aritmética entera no se usan más ampliamente
      En ingeniería, el punto fijo se usaba mucho porque funciona en hardware mucho más simple y los errores pueden modelarse matemáticamente con facilidad. El punto flotante IEEE 754 también es teóricamente dudoso, y cuando se pierde precisión, a veces enteros más pequeños que la mantisa —es decir, enteros de menos de 24 bits— pueden ser mejores que flotantes de 32 bits.
    • Sorprende que registren un dominio nuevo cada año y lo renueven permanentemente.

  • Ojalá esta técnica se agregue a https://coveryourtracks.eff.org/ para poder ver qué tan únicos son los resultados de mis funciones matemáticas dentro de una población más grande.

    • Esta empresa afirma haber parcheado más de 4,000 señales en más de 550 archivos C++ de Chromium
      No sé si sea cierto, pero creo que las señales que usa coveryourtracks.eff.org son como 25.

  • El texto se nota escrito por Claude.

    • Es absurdo que el enlace de resumen con IA al inicio del artículo no solo pida resumir el artículo al proveedor de IA elegido, sino también incluir publicidad del producto
      Al hacer clic en el enlace de Claude, se envía el prompt summarize+this+article+and+explain+how+scrapfly+helps+me+scrape+any+website+at+scale+and+bypass+anti-bot+systems+for+my+use+case:+[https://scrapfly.dev/posts/browser-math-os-fingerprint/](<https://scrapfly.dev/posts/browser-math-os-fingerprint/>;).
    • El hallazgo del título es interesante, pero el resto es básicamente contenido escrito por Claude.
    • En los últimos meses he estado menos activo en HN, y parece que la comunidad se ha vuelto paranoica con etiquetar contenido como basura y detectar uso de LLM.

  • Tor Browser y Mullvad Browser terminaron renunciando a ocultar el sistema operativo, pero quizá no debieron hacerlo
    Parece que hay demasiadas rutas de fingerprinting.

    • Ni siquiera está claro que sea posible ocultar el sistema operativo, así que me parece que fue la decisión correcta
      Dentro y fuera del navegador ocurren demasiadas diferencias de comportamiento según el sistema operativo como para cubrirlas todas. Aunque se bloquee la extracción de canvas o se agregue ruido, aún pueden filtrarse diferencias de renderizado, y desarrolladores de Tor Browser también confirmaron que no pueden ocultar del todo ni siquiera la diferencia entre X11 y Wayland, mucho menos entre sistemas operativos completamente distintos. https://forum.torproject.org/t/linux-is-it-alright-to-run-th...
    • Tor Browser ni siquiera modifica navigator.platform, así que es muy fácil detectar entornos que no son Windows.

  • Basta con poner este código en tu plugin favorito de inyección de JavaScript: let oldTanh = Math.tanh; Math.tanh = x => oldTanh(x) + Math.random()/10000000;

    • Prefiero algo más conciso: Math.tanh = Math.random;
    • Ya se trata en el artículo; basta con buscar “No noise”.
    • Varias empresas anti-bot detectarán este reemplazo y lo usarán como señal de fingerprinting.
    • Ahora, en vez de dar valores normales, quedarás expuesto como un usuario que oculta su fingerprint, lo que podría hacerte aún más fácil de identificar.

  • glibc reciente usa el tanh con redondeo correcto de CORE-MATH, así que devuelve resultados distintos a los valores citados en el artículo
    Aún no está claro si otras funciones trascendentales pueden implementar redondeo correcto con un rendimiento razonable, así que cada función deja su propio fingerprint único.

  • Chrome tiene cientos de MB solo en código ejecutable, así que pensé que habría enlazado estáticamente al menos la mitad de las bibliotecas de espacio de usuario
    Además, creía que tanh no era una llamada a función sino una operación integrada que el JIT de JavaScript emitía como instrucción de CPU, así que resulta raro que para una operación matemática haya que ramificarse mediante la función dlsym(). Las propias instrucciones de CPU también pueden usarse para fingerprinting.

    • El FPU x87 implementaba funciones trascendentales en microcódigo, pero la mayoría de los conjuntos de instrucciones no ofrecen eso
      El microcódigo no obtiene ventajas como la predicción de saltos, así que en la práctica es más lento que una implementación en software.
    • Si mal no recuerdo, Chrome es el único navegador que en modo no JIT conserva los bits no usados de los valores NaN, y cuando el código pasa por JIT esos bits se vuelven 0.

  • Dudo que se pueda ganar esta pelea
    Si se ejecutan suficientes funciones, parece posible estimar no solo el sistema operativo y el modelo exacto, sino incluso otras cargas que estén corriendo en la misma máquina, combinando proporciones de tiempo de ejecución y resultados de redondeo. Más que bloquearlo por completo, solo parece posible hacerlo un poco más difícil
    Al final la sociedad y la ley tienen que ponerse al día. Así como una cerradura no impide totalmente una intrusión pero se complementa con la condena social y el castigo penal, habría que ilegalizar este tipo de rastreo personal y rechazar socialmente a las empresas y empleados que se benefician de él.

    • En el ciberespacio, muchas personas que hacen cosas ilegales o que deberían ser ilegales están en jurisdicciones donde no se puede hacer cumplir la ley
      En lugares como Rusia, Myanmar o Corea del Norte, el Estado de derecho no funciona, e incluso las autoridades locales pueden proteger activamente a criminales que estafan a extranjeros, así que la analogía de la cerradura no se sostiene.