指紋検出回避：OS 固有の数学ライブラリによる指紋解析と完全再現技術

指紋検出は通常、WebGL、フォント、オーディオなどの分野を対象にしますが、より静かに機能する信号として**数字の最後の数ビット（最低限の有効桁）**に宿る情報も存在します。以下にその仕組み、対策、および完全再現の技術詳細を解説します。

指紋検出の確認

Math.tanh

Math.tanh(0.8)

結果の例:

• 本物の Linux Chrome (glibc 使用):

  0.6640367702678491

• 本物の macOS Chrome (libsystem_m 使用):

  0.664036770267849

• 本物の Windows Chrome (UCRT 使用):

  0.6640367702678489

仕組みと注意点

この値は定数ではなく、オペレーティングシステム（OS）によって正確なビット構成が異なります。

• macOS: Apple の数学ライブラリ (

  libsystem_m

  ) を介して計算。
• Linux:

  glibc

  を介して計算。
• Windows: ユニバーサル C ランタイム (UCRT) を介して計算。

3 つのライブラリは入力値の約 4 分の 1 の精度で合致しないが、通常は有効桁の最後の 1 ユニット（1 ULP）程度の差です。入力が

0.8

Chrome バージョンによる挙動の違い

Chrome 150 を使用した測定結果では、以下の通り動作します：

• Math.tanh(0.5)

  : Linux・macOS・Windows の 3 者とも一致（情報漏洩なし）。

• Math.tanh(0.7)

  : Linux は一致するが、macOS と Windows では 1 ULP 差。

• Math.tanh(0.8)

  : 3 つの OS で全て異なる結果となり、ばらつきは 2 ULP に及ぶ（識別に最適）。

• Math.tanh(0.9)

  : Windows が他と比べて 1 ULP 差のみ。

重要: Chrome 148 以降、V8 はホストの

libm

から読み取るよう仕様変更されました。以前は bundled な fdlibm ポートを使用していたため、どの OS でも同じビットを返し情報漏洩していませんでした（V8 コミット

c1486295ae5

で変更）。

なぜ 1 つの関数が異なるビットを返すのか

IEEE 754 は double の保存方法を定義しますが、

sin

cos

tanh

exp

主要なライブラリ一覧

• Linux: glibc
• macOS: Apple

  libsystem_m

• Windows: UCRT (

  ucrtbase.dll

  )

これらはほぼすべての場所では一致しますが、OS を分類するのに十分な頻度で分岐します。検出器には数学的計算の知識が必要ではなく、単に結果テーブルを持つことで検出が可能です。

四つの罠：単純な再実装は失敗する

「Mac の関数を再実装する」というアプローチは、以下の 4 つの理由で接触するだけで失敗します。

1. 一部の数学機能だけが漏洩する

V8 は独自の数学を静的にリンクしています。

• Math.exp

  、

  Math.pow

  、

  Math.atan

  など：bundled な llvm-libc から提供（全 OS で同一）。

• Math.sin

  /

  Math.cos

  ：bundled な glibc 由来の double ルーチンから提供（全 OS で同一）。
• 例外

  Math.tanh

  ：Chrome 148 以降、V8 はプラットフォーム固有の

  std::tanh

  を使用し、ホストの libm から読み取ります。これが唯一 OS を漏洩する

  Math.*

  関数です。

2. JavaScript の数学と CSS の数学は別々のコードパス

CSS の

sin()

cos()

atan2()

Math.sin

1. レイアウトエンジンで角度を度数に変換。
2. プラットフォーム固有の

   std::sin

   を呼び出し（値を減少させ）。

これは直接ラジアンで計算する

Math.sin

3. macOS は互いに不一致を生じる 2 つの数学ライブラリを持つ

Apple Silicon は以下の 2 つの異なるライブラリを持っています：

• スカラー版:

  libsystem_m

  （使用例：

  Math.tanh

  ）。
• ベクトル版: Accelerate フレームワーク (

  vvsin

  ,

  vvtanh

  )。

これらのコードは異なり、100 万の入力において関数により10〜89% のケースで発散します。

• 例：

  cos(0)

  はスカラー版で正確に

  1.0

  ですが、Accelerate では

  0.9999999999999999

  と異なります。

したがって、「Apple の数学を再現する」ことは定義が曖昧です。正しい解決策は、デバッグプロトコルで実際の Mac を駆動し、実際の Chrome から正確な double 値を読み取り、スカラー

libsystem_m

4. アーキテクチャによる漏洩

ARM と x86 は、融合乗算加算（FMA）や NaN の符号伝播において異なります。コンパイラが一つのターゲットで FMA を融合させ、別のターゲットでは行わない場合、ドリフトが発生します。

マップ：どこで何かが漏洩しているか

sin

cos

tan

asin

acos

atan

atan2

tanh

exp

log

pow

• V8 bundled: 静的にリンクされており、すべての OS で同一です。
• ホスト libm: OS を漏洩するプラットフォーム固有のライブラリ（Mac:

  libsystem_m

  , Linux: glibc, Windows: UCRT）。
• Accelerate: Mac の Web オーディオ DSP に使用される Apple の vDSP。

3 つの重要な情報源:

1. V8 はほぼすべての処理を bundled 数学でルーティングするため、JS は

   Math.tanh

   のみに情報が漏洩します。
2. Blink はすべての三角関数に対してホストの libm を直接呼び出すため、CSS は常に情報源となります。
3. Mac の Web オーディオは、FFT では Accelerate ですが、DynamicsCompressor（単位の超越関数）ではスカラー版

   libsystem_m

   を使用します。1 つのオーディオグラフに 3 つ異なるライブラリが存在します。

WASM について

WASM は超越演算オペコードを持っていないため、数学は bundled libm から供給されます。その算術（

f64.sqrt

f64.mul

これを閉じる方法：完全再現技術

単なる出力の乱す（ノイズなし）では無意味です。「主張している OS と同一である」ことが目標です。以下に 3 つの主要なアプローチがあります。

アプローチ A: アルゴリズムの完全再現

目標の libm からミニマックス係数などを回復し、移植可能な C に転記します。良い

tanh

tanh

Apple の sin 多項式（libsystem_m から抜き取った係数）を例示します：

// Apple が発火する各融合乗算加算 (fma) は明示的な fma() として記述されます。
// 係数のビットパターンはそのままコピーされ、小数点表記では異なる丸めになります。
static const double P[6] = {
     0x1.5d8fd1fd19ccd * p-33, -0x1.ae5e5a9291f5d * p-26,  0x1.71de3567d48a1 * p-19,
    -0x1.a01a019bfdf03 * p-13,  0x1.111111110f7d0 * p-7,  -0x1.5555555555548 * p-3,
};
static double sin_poly(double x2) {
  double p = fma(x2, P[0], P[1]);
  p = fma(x2, p, P[2]);
  p = fma(x2, p, P[3]);
  p = fma(x2, p, P[4]);
  p = fma(x2, p, P[5]);
  return x2 * p;                 // 呼び出し側で完了: sin(x) = fma(x, x2*p, x)
}

決定論的な再現:

• 明示的な

  fma()

  が重要です。
• コンパイル時に FMA 収縮をオフにする (

  -ffp-contract=off

  )。これにより、コンパイラが自らの融合を発明したり捨てたりすることを防ぎ、Apple と同じ演算フローになります。
• 結果は FMA と非 FMA CPU で同一に、ARM マシンと x86 フリート上で同一になります。

アプローチ B: オリジナルライブラリの直接読み込み

再現が割に合わない場合は、オリジナルの libm をマップします。

• Windows UCRT:

  ucrtbase.dll

  を実行時にメモリ上にマップし、エクスポートを直接呼び出します。コードが本物なので、リバースエンジニアリングなしでビットは本物です。

// Windows x64 ABI (System V ではない)。ms_abi がないとクラッシュします。
typedef double(__attribute__((ms_abi)) * D1)(double);          // tanh, sin, ...
typedef double(__attribute__((ms_abi)) * D2)(double, double);  // atan2

// マップされた DLL コードは CFI リージスターズでないため、
// -fsanitize=cfi-icall (生産環境オン) は #UD-trap を発生させます。
[[clang::no_sanitize("cfi-icall")]]
double ucrt_tanh(double x) {
  return ucrt.loaded ? ucrt.tanh(x) : std::tanh(x);
}

詳細な調整:

• UCRT の数学関数は

  mov eax, [rip+disp32]

  で始まって、スカラーか FMA/AVX2 パスかを選択する CPU ディスパッチフラグを読み取ります。
• 新鮮なマップではこのフラグが 0 になり遅いパスを取得するため、初期呼び出し前にFMA パスに強制することで、実際の Windows マシンとビット単位で一致します。

アプローチ C: フックによるゲート制御

エンジンが libm を呼ぶ単一の関数をフックし、主張する OS にゲートします（Linux は glibc を保持し、Mac では再現版を使用）。

速度最適化 (FMA 有効化): 完全に再現されていても低速であれば情報源となります。ソフトウェア呼び出しの

fma()

• デフォルトの x86 ベースラインはハードウェア FMA 以前の挙動のため、比率が不自然です。
• ハードウェア FMA をオンにすると、各融合演算は 1 インストラクションになり約 6 倍高速化し、glibc よりも速く、ビット単位で同一になります。

バリデーション

出荷前の証明として、以下のテストを実行します：

• 871,000 の入力実行: 稠密グリッド、間隔境界、サブノーマル、符号付きゼロ、無限大、NaN など。
• 本物のデバイスオラクル: スカラーと Accelerate の両方の結果を計算する実際の Mac で不一致箇所を検出。
• 本物のブラウザアンカー: 実際の Mac Chrome (

  Math.tanh

  と CSS 三角関数) を完全精度で計算し、指紋検出器の基準とする。

確認事項:

• Math.tanh

  と CSS の

  sin

  /

  cos

  /

  tan

  /

  asin

  /

  acos

  /

  atan

  /

  atan2

  について、再現版は出荷バイナリ内の機械コードと完全に一致しています（Bit-for-bit パラリティ）。
• ドメインエッジもチェックされます：例えば実際の Mac では

  asin(2)

  は 0 に解決（NaN クランプ）しますが、ナイーブな再現版では 90 度となりません。

結論：なぜそれが重要なのか

数学は決定論的であり、プローブするのは簡単ですが、偽装するのは困難であり、スプーフィングスタックのレーダーにはほぼありません。

• 防衛者にとって: 強いシグナルとなります。
• スクレイパーにとって: 負債となります。

これを正しく行うには、ベンダーの libm 内部をリバースエンジニアリングし、3 つのエンジンが呼び出しサイトごとに数学をルーティングする方法をマッピングし、アルゴリズムを最後のビットまで一致させ、アーキテクチャを超えて決定論性を維持し、実在するハードウェアに対して証明する必要があります。

これにより、API を介して macOS として提示するとしても、アイデンティティはコサインの丸めまで保持され、実在するトラフィックと区別できなくなります（Scrapfly / Scrapium の技術スタック）。