某書 Android 9.43.1 の署名アルゴリズム解析

本稿では、小紅書 Android 9.43.1（build 9431801）のリクエスト署名を分析する。対象はデバイス識別子、MUA、SIG、S1、Shield、および Shield に必要な鍵交換だ。本文中の定数とバイナリレイアウトは、すべてこのバージョンを対象としている。

MUA、SIG、S1 は libtiny の処理チェーンに対応し、Shield と main_hmac の復号は libxyass に対応する。以下では、入力の組み立て、暗号変換、出力形式の順に説明する。本文でいう native はこのバージョンのネイティブライブラリを指し、エミュレーターでの比較結果は、所定の環境入力に対してライブラリが出力した値にすぎない。

以下では ||でバイト列を連結し、XORはビット単位の排他的論理和を表す。u32le、u32beはそれぞれ 32 ビット整数のリトルエンディアンおよびビッグエンディアン表現を表す。整数演算での切り捨てがある場合は、個別に明記する。

本稿はクライアントの署名実装をリバースエンジニアリングした記録であり、対象範囲は Android 9.43.1（build 9431801）のローカルアルゴリズムとメッセージ形式に限られる。ここで示す数式と定数は、このバージョンがリクエストヘッダーをどのように組み立てるかを説明するものであり、無許可アクセス、リスク制御の回避、または大規模なスクレイピングの手法を構成するものではない。サーバー側の方針、デバイス環境、後続バージョンによって、本文の結論は変わり得る。対象外の収集分岐や実機の状態を、たった一度の成功レスポンスで補って判断することもしない。

0. 署名フローの全体像

コンテンツリクエストには、次のフィールドが関係する。

SIG と S1 は同じ canonical 文字列を使う。以下ではこれを canonical と呼ぶ。

METHOD\nPATH\nQUERY\nhex(SHA256(body))\nMUA

ここで METHOD は大文字、PATH はドメイン名を含めず、QUERY は疑問符の後ろにある、再デコードもソートもしていない元の文字列で、疑問符自体は含めない。body は実際に送信するバイト列、SHA-256 は 64 文字の小文字 hex、MUA は末尾のピリオドを含めて完全な形式を保持する。五つの項目の間にはそれぞれ LF バイト（0x0A）を一つ入れ、末尾には改行を追加しない。上式の \n\n は改行を表し、バックスラッシュと英字 n の組ではない。query が空の場合も、対応する空行を残す。

GET リクエストの body は空で、その SHA-256 は次のとおり。

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Shield では別の入力を使う。path、query、指定されたリクエストヘッダー、body を固定順序でそのまま連結する。SIG、S1、MUA の三つのヘッダーを HMAC の入力データに直接含めることはない。

検証済みのコールドスタート時のクライアントフローは次のとおり。

生成设备身份与 MUA 会话材料
  ↓
获取 vfc_code 响应头 xy-ter-str
  → 解密 main_hmac，得到 key64
  ↓
发送 register/android
  → 服务端返回 GID
  ↓
发送 activate，携带临时 X25519 公钥
  → 解密 SSK，保存 sid
  ↓
请求 cold_start_config，取得 id_token
  ↓
生成内容请求的 MUA → canonical → SIG、S1
  ↓
用最终 path、query、白名单请求头和 body 计算 Shield
  ↓
发送请求

これはクライアントが呼び出す順序であり、すべての手順が暗号学的に依存しているわけではない。たとえば登録リクエストでは Shield を使わず、key64 にも依存しない。各段階で使われるフィールドは次のとおり。

activate のレスポンスには token が含まれることもある。ここで説明するクライアントは、すでに token を持っていても、cold_start_config をリクエストして更新する。sid と id_token はxy-common-paramsを経由して Shield に渡される。これらは canonical の独立したフィールドではない。

各レスポンスが更新する状態も異なる。登録ではdata.g、activate では main_ssk を復号し、data.sessionにsession.プレフィックスを付けて sid として保存する。cold_start_config ではdata.user_info.user_tags.id_tokenから token を読み取る。対応するレスポンスの処理が成功して初めて、後続のリクエストでこれらの新しい値を使える。

同じリクエストヘッダーと署名は、推薦、検索、著者ホームの各インターフェースにも使われる。匿名セッションで一連の処理を最後まで通過することを確認したインターフェースには、edith.xiaohongshu.com の imagefeed、user/info、user/posted、rec.xiaohongshu.com の homefeed、so.xiaohongshu.com の search/notes がある。canonical に含めるのは PATH だけで、ドメイン名は含めない。ドメインをまたぐ場合も変わるのは host と query だけで、署名式は変わらない。

サーバー側では、セッション単位の失敗が二種類確認されている。code=-100 では msg が「アカウントにログインしてください」、code=300011 では msg が「現在のアカウントに異常があります。アカウントを切り替えてから再試行してください」となる。どちらも連続したリクエストの途中で発生しており、同じデバイスで同じリクエストを再試行しても通常は失敗したが、別のデバイス識別情報で改めて初期化すると復旧した。これらはサーバー側のセッション状態とリスク制御状態を示すものであり、本文では特定の署名入力の誤りが原因だとは断定しない。

1. android_id と deviceId

deviceId には、標準的な MD5 と UUID v3 のバージョンビットおよびバリアントビットの規則が使われる。入力は android_id テキストの UTF-8 バイト列である。たとえば 16 文字の hex テキストも 16 バイトの ASCII として扱い、先に 8 バイトへ変換することはない。

h = MD5(utf8(android_id))
h[6] = (h[6] & 0x0F) | 0x30
h[8] = (h[8] & 0x3F) | 0x80
deviceId = 按 8-4-4-4-12 格式输出 h 的小写 hex

ここでは name bytes をそのままハッシュし、namespace を追加で連結しない。そのため、任意の namespace を使う UUID v3 API で置き換えることはできない。

同値な書き方は (h[6] & 0x3F) | 0x30 と (h[8] & 0xBF) | 0x80である。前者では保持していた bit 4、5 が後でいずれも 1 に設定され、後者では保持していた bit 7 も後で 1 に設定されるため、最終結果は同じになる。

例：

android_id = c91d22e4e041c6bd
MD5        = 4df7198147ee23390a7d7bbe597eca24
deviceId   = 4df71981-47ee-3339-8a7d-7bbe597eca24

例：

import hashlib, uuid

def device_id(android_id: str) -> str:
    h = list(hashlib.md5(android_id.encode()).digest())
    h[6] = (h[6] & 0x3F) | 0x30
    h[8] = (h[8] & 0xBF) | 0x80
    return str(uuid.UUID(bytes=bytes(h)))

device_id("c91d22e4e041c6bd")
# '4df71981-47ee-3339-8a7d-7bbe597eca24'

2. x-mini-mua：セッション素材とデバイスプロファイル

MUA の形式は次のとおり。

MUA = Base64URL(Part1_JSON_UTF8) + "." + Base64URL(Part2_ciphertext) + "."

連結時に空白は入れない。二つの Base64URL セクションから末尾の=を取り除き、最後のピリオドは残す。Part1 はそのまま JSON にデコードできるが、Part2 の復号にはまずセッション共有秘密を得る必要がある。

セッションの初期化では、まず 64 バイトのランダム素材sを取得し、続いて 32 バイトの X25519 生 scalar を取得する。セッション中はこの二つの素材を再利用する。リクエストカウンターやデバイスの実行状態は変化し続けるため、セッション素材を再利用しても、MUA 全体を再利用できるとは限らない。

2.1 X25519 と AES 素材

X25519 は素数体p = 2^255 - 19上で計算する。scalar を曲線演算に渡す前に clamp を行う。

scalar[0]  &= 0xF8
scalar[31]  = (scalar[31] & 0x7F) | 0x40

元の scalar はそのまま保存してよく、clamp が作用するのは曲線演算に使う入力のコピーだけである。

k     = X25519(scalar, basepoint9)
slotA = X25519(scalar, MUA_SERVER_PUBLIC_KEY)
key   = slotA[0:16]
iv    = slotA[16:32]

基点 9 はリトルエンディアンの 32 バイト、つまり09の後に00を 31 個続けた形でエンコードする。MUA のサーバー公開鍵は次のとおり。

c9b68adc9a607bd108c7b7bba0dd6b5a9eba716fb6027b52c861b838cae63637

SSK では別のサーバー公開鍵を使う。第 7 節を参照。共有秘密がすべてゼロになった場合は、失敗として扱う必要がある。

この関係を特定できる根拠は、同じ native セッションから得た元の scalar、公開鍵k、AES 素材をそれぞれ照合したことにある。基点との乗算からkが得られ、固定の peer key と X25519 を行うと slotA が得られる。scalar の異なる二つのセッションでもこの関係が成立し、さらに導出した key/IV で Part2 を再構成できたため、直前の中間値だけに依存したものではないことが確認できる。

native では、フィールド要素を五つの 51 ビット limb で表現する。シリアライズ結果は標準 X25519 の 32 バイト・リトルエンディアン出力に対応するため、プロトコルを再現するだけなら内部の limb 表現を保持する必要はない。

native の中間バッファーを直接照合する場合、五つの limb はそれぞれリトルエンディアンの u64 を一つ占め、合計 40 バイトになる。その値を h0…h4 とすると、シリアライズ式は次のとおり。

value = h0 + (h1 << 51) + (h2 << 102) + (h3 << 153) + (h4 << 204)
encoded = little_endian_32_bytes(value mod (2^255 - 19))

ここでは完全な値に対して剰余を取り、各 limb を先に 51 ビットへ切り詰めることはしない。中間 limb には、まだ正規化されていない繰り上がりが含まれる場合がある。k と slotA も、この境界では同じ規則に従う。

曲線部分の最小実装：

P = 2**255 - 19

def clamp(k: bytes) -> bytes:
    k = bytearray(k)
    k[0] &= 0xF8
    k[31] = (k[31] & 0x7F) | 0x40
    return bytes(k)

def x25519(scalar: bytes, u: bytes) -> bytes:
    k = int.from_bytes(clamp(scalar), 'little')
    x1 = int.from_bytes(u, 'little') & ((1 << 255) - 1)
    x2, z2, x3, z3, swap = 1, 0, x1, 1, 0
    for t in range(254, -1, -1):
        kt = (k >> t) & 1
        swap ^= kt
        if swap:
            x2, x3 = x3, x2
            z2, z3 = z3, z2
        swap = kt
        a = (x2 + z2) % P
        aa = (a * a) % P
        b = (x2 - z2) % P
        bb = (b * b) % P
        e = (aa - bb) % P
        c = (x3 + z3) % P
        d = (x3 - z3) % P
        da = (d * a) % P
        cb = (c * b) % P
        x3 = ((da + cb) ** 2) % P
        z3 = ((da - cb) ** 2 * x1) % P
        x2 = (aa * bb) % P
        z2 = (e * (aa + 121665 * e)) % P
    if swap:
        x2, x3 = x3, x2
        z2, z3 = z3, z2
    return ((x2 * pow(z2, P - 2, P)) % P).to_bytes(32, 'little')

セッション素材と slotA の分割：

MUA_SERVER_PUBLIC_KEY = bytes.fromhex(
    'c9b68adc9a607bd108c7b7bba0dd6b5a9eba716fb6027b52c861b838cae63637')

pub = x25519(private_key, b'\x09' + b'\x00' * 31)   # Part1 的 k
slotA = x25519(private_key, MUA_SERVER_PUBLIC_KEY)
key, iv = slotA[:16], slotA[16:]                      # prefix16 / suffix16

2.2 Part1 のフィールド

現在のリクエスト生成で使われるキーの順序は次のとおり。

a, c, k, p, s, t, [u], v

シリアライズにはコンパクト JSON を使い、Unicode は ASCII エスケープに変換せず、フィールド順も保持する。登録経路では u を省略する。過去の完全なリプレイサンプルには t を含まない Part1 もあるため、リプレイ時は元のフィールド集合を維持しなければならない。キーを追加すると Part1 と MUA 全体が変わる。

同じ登録処理で使われる body.c、MUA.c、S1 フレーム内の counter には、すべて同じ値が入る。コールドスタート時のクライアントが最初に登録するときは c=2 だが、カウンターはセッション状態で管理しなければならず、すべてのリクエストで 2 を固定値として使ってはいけない。

Part1 のフィールド集合は、プラットフォームやバージョンによって変わる。iOS 9.47.2 で確認された Part1 ではa=ECFAAF02が使われ、さらにi、m（ミリ秒単位のタイムスタンプ）、nなど、本文で扱っていないフィールドも現れる。リクエストヘッダーにはさらにx-mini-nsigが付く。本文の式をバージョンをまたいで再利用する前に、まずフィールド集合を照合する必要がある。

Part1 の組み立て：

part1 = {
    'a': 'ECFAAF01', 'c': counter, 'k': pub.hex(), 'p': 'a',
    's': random_material.hex(),
    't': {'c': 0, 'd': 0, 'f': 0, 's': 4098, 't': 0, 'tt': []},
    'v': '2.9.99',
}
part1_b64 = b64url(json.dumps(part1, separators=(',', ':')).encode())

dict は挿入順に出力され、上表のキー順と正確に一致する。コンテンツリクエストでは OAID が空でない場合、u（'00000000' + oaidに位置し、tとvの間にある）、登録経路ではuを省略する。

2.3 Part2 のエンコードと暗号化

Part2の平文はデバイスプロファイルのJSONで、確認できたベースラインには95個のフィールドが含まれている。パッケージのバージョン、ビルド情報、インストール時刻、バッテリー、ネットワーク、ストレージ、プロセス状態などを扱う。

profile
  → 顶层键按字符串顺序排序
  → 紧凑 JSON，UTF-8
  → zlib，level=6，带 zlib 头
  → PKCS#7
  → AES-128-CBC(key, iv)
  → Base64URL，去掉 =

キーの順序は x0,x1,x10,…で、数値順ではない。ここで並べ替えるのはトップレベルのキーだけで、ネストしたオブジェクトは元の順序のままシリアライズする。浮動小数点数の表記やUnicodeのエスケープ方法も入力バイト列の一部なので、言語をまたいで再現する場合は一致させる必要がある。

PKCS#7のパディング規則:

pad = 16 - (len(compressed) mod 16)
padded = compressed || byte(pad) 重复 pad 次

圧縮結果が16バイト境界に揃っていても、16個の 0x10 を追加する。

逆向きに検証する場合は、Base64URLデコード、CBC復号、PKCS#7の検証と除去、zlib展開の順に処理する。圧縮データにはzlibラッパーが付いているため、raw DEFLATEとして直接展開することはできない。同じJSONでも、圧縮器が異なれば圧縮後のバイト列が完全に一致するとは限らない。バイト単位で再現するには、圧縮ストリームも照合する必要がある。

フィールドの値はJSONの型を保持しなければならない。たとえば、x2はバージョン番号の整数、x17はSDKの整数、x43はネットワークを表す文字列、x242は空の配列である。"0" と 0 も入れ替えられない。x5の "JTdCJTdE" はテキスト %7B%7D のBase64であり、 {} のBase64ではない。ここで扱うプロファイルと登録時のsnapshotは、互いに独立した2つのオブジェクトである。

この層の検証では、平文JSON、zlibバイト列、CBC暗号文、最終的なMUAを同時に比較する必要がある。「自分で暗号化したものを自分で復号できる」ことを確認するだけでは、nativeとの一致は証明できない。セッション用の固定材料と元のプロファイルを固定したところ、完全なMUAはnativeの出力とバイト単位で一致した。

暗号化の復元とデバイス情報の収集処理の復元は別の問題である。合成したプロファイルを使えばエンコード処理の流れは検証できるが、実際のAndroid端末ですべてのフィールドがどこから取得されるかまでは導けない。

外側の処理パイプライン:

import zlib
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes

def pkcs7(data: bytes) -> bytes:
    n = 16 - len(data) % 16
    return data + bytes([n]) * n

def part2(profile: dict, key: bytes, iv: bytes) -> str:
    raw = json.dumps(
        {k: profile[k] for k in sorted(profile)},
        ensure_ascii=False, separators=(',', ':'),
    ).encode()
    cipher = Cipher(algorithms.AES(key), modes.CBC(iv)).encryptor()
    return b64url(cipher.update(pkcs7(zlib.compress(raw, level=6))) + cipher.finalize())

sorted(profile) は文字列順のソートで、x0, x1, x10, … のトップレベルキーの順序がそのまま得られる。ネストしたオブジェクトは入力された順序を保つ。

2.4 95フィールドのプロファイル完全マッピング

次の表は、実装済みのプロファイル構築方法をまとめたものである。パッケージ、ビルド、ハードウェアのフィールドは端末パラメータから取得し、時刻や実行状態のフィールドは明示的に指定できる。固定値、時刻のオフセット、seedからの派生値はオフラインで合成するための方法であり、実機での収集式を意味しない。引用符付きの値はJSON文字列で、それ以外の数値は整数である。ただし、x247の値は浮動小数点数である。

実機で確認済み（Xiaomi MI 6 / Lineage 15 / 9.43.1）：ログインプロセスの MUA Part2 の平文はちょうどこの95個のキーで、合成器のキー集合と一致した。パッケージ名、バージョン、board、product、ABI、build id/host/incremental はパラメータ表と一致している。同じ起動中に取得した2回分の95キー dump は、時間、明るさ、x258、x293、x302/x303 だけが異なっていた。確認できたものの合成時のデフォルト値を変更していない項目として、x70 は Wi-Fi の 3 ではなく 25、x258 は 1 になる場合がある、x235 は 3348494、x302/x303 は空でなく同じプロセス内でも変化する、という点がある。2社目のメーカーのサンプルはまだない。

Nを現在のUnix時刻（ミリ秒）、Iを保存されたインストール時刻、Uを max(1, uptime_ms)とする。uptimeが渡されなかった場合は、Nから保存された起動時刻を引く。実行状態について明示的に渡された値は、次の表のデフォルト値より優先される。固定デバイスパラメータは、同じプロファイル内で一貫させる必要がある。

展開後の結合項目は合計95個のキーになる。構築時には既存のスロットを上書きできるが、キーを追加したり欠落させたりすると、この基準状態から外れる。x234のデフォルトのキー順は "1"、"2"、"3"で、値はそれぞれI−67648、I−70281、I−70435。x247は次のとおり：

{"0":53.333333333333336,"1":71.42857142857143,"2":71.42857142857143,"3":32.0,"4":85.71428571428571,"5":71.42857142857143}

2.5 seedの導出と永続化方針

デバイスseedは同じ合成IDを繰り返し生成するために使うもので、nativeの鍵導出入力ではなく、MUAのランダムなsやscalarの代わりにもならない。文字列seedはそのままUTF-8に変換し、bytes型のseedはまず小文字のhexテキストにしてからUTF-8に変換する。seedがない場合は、32バイトの乱数をhexテキストにして生成・保存する。

D(label,L)を次のバイト列の先頭Lバイトと定義する。カウンタjは0から始まる：

D(label,L) = first_L_bytes(
    SHA256(seed_bytes || 00 || UTF8(label) || u32be(0))
 || SHA256(seed_bytes || 00 || UTF8(label) || u32be(1))
 || ...)

R(label,lo,hi) = lo + big_endian_u64(D(label,8)) mod (hi-lo+1)

ここでいうjは導出ストリーム用のカウンタであり、MUA.cとは無関係である。永続フィールドは次の規則で初期化し、保存済みの値を優先する：

created_at_ms、インストール時刻、起動時刻、x146はプロファイルとともに保存される。seedだけを残して毎回created_at_msをリセットすると、デフォルトのインストール時刻と起動時刻が変わる。x146自体はcreated_at_msに依存しない。

同じ導出規則は登録IDにも使われる：

合成インストールディレクトリは /data/app/~~{apk-dir}/com.xingin.xhs-{apk-id}。合成ファイルシステムの状態では第12項目だけを成功とし、fstypeには61267を設定し、残り11項目は両方とも失敗とする。SoC serialとboot_idはまとめて省略し、空のファイルツリーを基準に再現できる。MMC、UFS、および追加のSettingsにはデフォルトの仮想値を設定しない。

シミュレートしたJNI IDでは、完全なディスクリプタ java/util/Map->方法签名 のJava String.hashCodeを使う。UTF-16コードユニットごとに h=(31*h+unit) mod 2^32 を適用してから、第9.2節のMD5に入力する。シミュレートしたattestationでは SHA256(UTF8(deviceId)) を使い、IDが空の場合は空バイト列のSHA-256となる。これらの代替値で再現できるのはシミュレーション環境だけであり、ARTやTEEの実際の計算式ではない。

合成方針ではattestation分岐を残し、x148は空文字列、x128はファイル欠落を示すテキストとする。x170は、デバイスパラメータのmanufacturerが Xiaomi と等しいかどうかに基づいて、観測済みの分岐を選択する。実機で分岐を決めるのはクラスのロード結果と収集結果であり、この選択方針で実際の検出を代用することはできない。

3. x-mini-sig：SHA-256とGF(2)アフィン変換

digest = SHA256(utf8(canonical))
front  = A × bits(digest[0:16]) XOR b
sig    = hex(front || digest[16:32])

出力は64文字の小文字hexである。後半16バイトはSHA-256ダイジェストをそのまま保持し、前半16バイトには固定のGF(2)アフィン変換を施す。

3.1 アフィン関係の求め方

GF(2)では、加算はXOR、乗算は単一ビット同士のANDである。各出力ビットは、128個の入力ビットの線形結合を取り、それに定数をXORしたものとして表せる。

ダイジェスト後の変換入口に入力を自由に注入できるなら、まず f(0) を求めれば、定数bが得られる。次に128個の単一ビット基底ベクトル e_j に対して評価する：

b      = f(0)
A[:,j] = f(e_j) XOR b

リクエスト単位の入出力しか取得できない場合は、各ダイジェスト前半xと署名前半yの組について、次を立てる：

[x 的 128 个 bit, 1] × coefficients = y 的某一 bit

GF(2)上のガウス消去で解く。拡大入力行列のランクが129に達して初めて全係数を一意に決定できる。さらに、学習サンプルとは別のデータで検証する必要がある。

これはアフィン変換を復元する方法である。現在の資料には最終行列と独立したキャプチャベクトルが残っているが、当時の全サンプル取得や消去過程を本稿で再現できるだけの元の求解記録はない。独立したGETサンプル11組によって、この行列の出力が一致することは確認できるが、この11組だけから128×129個の係数を逆算することはできない。

3.2 ビット順序と評価

行列を128行129列として表し、最後の列に定数項を格納する。

v = int.from_bytes(digest[0:16], "big") | (1 << 128)

对输出行 ob = 0..127：
    bit = XOR(matrix[ob][j] AND ((v >> j) & 1), j=0..128)
    将 bit 写入输出字节 ob//8 的第 (7-ob%8) 位

入力列0はビッグエンディアン整数の最下位ビットに対応する一方、出力行0は結果の最上位ビットに対応するため、向きが異なる。完全な行列のコンパクトな表現は付録に示す。

ある入力に対する中間結果は次のとおり。

SHA256(canonical) =
31e2d1e8600bcfc46c0ba17ad2fdf6a9 34afff0c5c86368cb2f12521cafa5e7f

仿射变换后前 16 字节 =
839db883aafc9058c440fbaee6135968

SIG =
839db883aafc9058c440fbaee613596834afff0c5c86368cb2f12521cafa5e7f

POSTにも同じ式を使うが、異なるのはbodyのダイジェストだけだ。署名結果を比較する意味があるのは、canonicalが完全に一致している場合に限られる。

canonical、行列、ビット順を組み合わせると、次のようになる。

import hashlib

def canonical(method: str, path: str, query: str, body: bytes, mua: str) -> bytes:
    return (f'{method}\n{path}\n{query}\n'
            f'{hashlib.sha256(body).hexdigest()}\n{mua}').encode()

def gf2_apply(digest16: bytes, rows) -> bytes:
    # rows：附录 A 的 128 行，每行 129 列（128 个输入位 + 1 个常量位）
    v = int.from_bytes(digest16, 'big') | (1 << 128)
    out = bytearray(16)
    for i, row in enumerate(rows):
        bit = 0
        for j, c in enumerate(row):
            if c:
                bit ^= (v >> j) & 1
        if bit:
            out[i // 8] |= 1 << (7 - i % 8)
    return bytes(out)

def compute_sig(method: str, path: str, query: str, body: bytes, mua: str, rows) -> str:
    d = hashlib.sha256(canonical(method, path, query, body, mua)).digest()
    return (gf2_apply(d[:16], rows) + d[16:]).hex()

rows の第 j 列は入力文字列の bit j（3.2の列順を参照）、出力第 i bit は第 i バイト目の bit 7 - i % 8に書き込まれる。

4. x-mini-s1：ダイジェスト変換、CBC、二重CRC

S1はSIGの出力を使わない。canonicalの末尾にcounterを追加してSHA-256を再計算し、さらにタイムスタンプを加えて暗号化対象の構造体を作り、最後に標準Base64で出力する。

この処理系を特定する際、最初に観測されたのはBase64化前の62バイト構造だった。乱数を固定しても、プロセスをまたぐと結果が変わることがある。変化の一つはcanonical内でまだ固定されていないMUAに由来し、もう一つは後から書き込まれる秒単位のタイムスタンプに由来する。canonical、counter、時刻をすべて固定して初めて、残る差異がアルゴリズムによるものかを判断できる。

中間バッファへの書き込みをさらに追跡すると、結果は32バイトのdigest lane、44バイトのseed、48バイトの暗号文、二つのCRCに分解できる。canonical全体を固定した後も残る変化は、最終的には秒単位の値の返り値に対応しtime(NULL)。この秒単位の値を固定すると、プロセスをまたいでも出力は一致する。

laneは当初、固定XORアフィンモデルで表そうとしたが、新しいサンプルがモデルと矛盾した。その後、VM命令とメモリ書き込みを手掛かりに、4段の変換をそれぞれ復元した。CBC部分では、テーブル参照層をAES S-boxと入力・出力XORマスクに分解し、4.4節の明示的なラウンド関数を得た。ここでいうマスクはテーブルから復元した定数であり、K0から標準AESの鍵スケジュールを実行して得たラウンドキーではない。

4.1 SHA-256とワード再配置

nested = utf8(canonical) || u32le(counter)
digest = SHA256(nested)
state  = digest 的 4 字节块按 (7,0,2,5,6,3,1,4) 重排

各4バイトブロック内のバイト順は反転しない。

counterは符号なし32ビットとしてエンコードし、MUA.cと一致させる必要がある。counterはnestedのダイジェストにも使われ、最終フレームヘッダーにも現れる。フレームヘッダーだけを書き換えても、その新しいcounterに対応する完全なS1にはならない。

4.2 4段のlane変換

stateを8バイトずつ4段に分け、それぞれを処理してから連結する。

IEEE反映CRC-32を使用し、多項式は0xEDB88320、初期値は0xFFFFFFFF。

crc32_internal(data) = CRC 循环结束时的寄存器值
crc32(data)          = crc32_internal(data) XOR 0xFFFFFFFF
swap(b)             = (b >> 4) | ((b & 0x0F) << 4)

第1段では、まず各バイトの上位ニブルと下位ニブルを入れ替え、次に内部CRCの下位8ビットを共通のXORマスクとして使う。

a[i]   = swap(input[i])
mask   = crc32_internal(a) & 0xFF
out[i] = a[i] XOR mask

第2段：

mix = ((input[0]<<4) | (input[7]>>4))
      XOR ((input[6]<<4) | (input[1]>>4))
a[i] = input[i] XOR (mix & 0xFF)

out[i] = a[i]       当 i 为 3 或 5
       = swap(a[i]) 其它位置

第3段ではニブルS-box（インデックス0..15）を使う。

B 2 F 6 8 9 E 3 1 D 7 5 C A 0 4

substituted = 对每个字节，依次追加 SBOX[高4位] 和 SBOX[低4位]
              # 每个结果各占一个字节，值为 0..15，共 16 字节
mask = crc32_internal(substituted) & 0xFF
out[i] = input[i] XOR mask

CRCへの入力は展開後の16バイトだが、最後にXORするのは元の8バイトのままである。

第4段：

C = 0xAE
first = input[0] XOR C
first_swapped = swap(first)
second = input[1] XOR first_swapped XOR C
second_swapped = swap(second)
mask = first_swapped XOR second_swapped XOR C

out[0] = first_swapped XOR second_swapped XOR first
out[1] = second_swapped XOR second
out[2:8] = input[2:8] XOR mask

4段分の出力を連結してlane32とする。第1段のCRC更新は、バイト単位でnativeの中間状態と照合した。残りの段はそれぞれ独立した変換を使うため、第1段の式を32バイト全体に適用してはならない。

4.3 seedとフレーム構造

seed44   = u32le(timestamp_seconds) || 51 24 4a 19 || 00 00
           || lane32 || 17 0e
crc_seed = u32be(crc32(seed44))
plain48  = seed44 || 04 04 04 04
body48   = fused_aes_cbc(plain48)

source53 = 01 || body48 || crc_seed
crc_src  = u32be(crc32(source53))
raw62    = 00 || u32le(counter) || source53 || crc_src
S1       = Base64(raw62)

2つ目のCRCは53バイトを対象とし、外側のmarkerとcounterは含めない。これも一時的なsourceバッファに連結する場合、そのバッファの長さは57バイトになる。ただし、これはCRCへの入力長とは別の概念である。

62バイトを標準Base64にすると84文字になり、末尾には「=」が1つ付く=。

timestamp_secondsはUnix時刻の秒数で、u32として書き込む。Part1.t.tのミリ秒単位のuptimeとは異なり、nestedのSHA-256には関与しない。時刻の変化はseed、CBC暗号文、後続の検証層に現れる。

4.4 融合型 AES 風 CBC

CBCのIVは次のとおり。

6e2052fb01f05fd238ad54534bd00831

まず現在の平文ブロックとpreviousをXORする。previousの初期値はIVとする。ブロック変換にはAES標準のS-boxとMixColumnsを使うが、演算の並びとラウンドキーテーブルは次の形式で構成される。

state = ShiftRows(Transpose(plain_block XOR previous))
for Ki in K0..K8:
    state = SBOX[state XOR Ki]
    state = ShiftRows(MixColumns(state))
state = SBOX[state XOR FA] XOR C
cipher_block = Transpose(state)
previous = cipher_block

Transposeは列優先の16バイト入力を行優先のstateに変換し、ShiftRowsは第r行をr個左ローテートする。ラウンドキーは上記の行優先stateに1バイトずつ対応するため、キーをさらに転置してはならない。

9ラウンドのキーは順に次のとおり。

786873306f6832697534616e376f6732
5a3241711e764471e0d4fb95096b0c3e
43713041275115398f5bfa6ff3c8c4fa
1e6f5f1e27766300174cf798864b8f75
ed82ddc30e781b293c70b32b4539b6c3
52d00dce760e1578cabaddf62717a162
2bfbf638faf4e18c2d9711e7789c3d5f
93689ea6fe0aeb0467f0ad4a819ba6f9
fa920caa767c97888c7ca1eb61bf19e0

FA = 69fbf75dee92059829554ea58b130aea
C  = 34cf3865648a181d73d6ffaa5f55bf34

K0はASCII文字列xhs0oh2iu4an7og2。最後の層はS-boxを1回適用するだけで、MixColumnsは行わない。

AES S-boxは、まずGF(2^8)で乗法逆元を求め、続いてアフィン変換を適用して構成する。既約多項式は0x11Bで、0の逆元は0として扱う。

SBOX[x] = inv(x) XOR rotl8(inv(x),1) XOR rotl8(inv(x),2)
          XOR rotl8(inv(x),3) XOR rotl8(inv(x),4) XOR 0x63

MixColumnsでは、各列[a,b,c,d]に対して次を計算する。

2a XOR 3b XOR c XOR d
a XOR 2b XOR 3c XOR d
a XOR b XOR 2c XOR 3d
3a XOR b XOR c XOR 2d

44バイトのseedに4バイトのゼロバイトを補うと0x04ちょうど3ブロックになる。上記の変換は、初期キーを1つ使う標準AES-CBCでそのまま置き換えることはできない。

現在、固定時刻で counter=1 の native 完全フレームの照合が23組あり、固定時刻で counter=2 の完全フレームの照合が5組ある。後者は異なる5つのUnix秒値をカバーしており、counter=1のサンプルと同じ秒値、隣接する秒、1時間のずれ、さらに11 と 17000000001700000000 を含む。この5組の raw62 は、同じ canonical、counter=2、対応する秒値を使うと、式の結果と1バイト単位で一致する。51244a1951244a19 と 170e170e は、これらの照合で変化しない。

さらに、Android 9.47.0（build 9470809）の arm64 libtinylibtinyの内容は9.43.1のサンプルとバイト単位で一致した。したがって、9ラウンド鍵、FAFA、CC、51244a1951244a19 および 170e170e は、この2つのアプリバージョン間で変化していない。これらの定数は so 内に連続した平文として現れないため、変化の判定はリテラル検索ではなく、ライブラリ全体のイメージに基づいている。

前述の式を実行可能な検証に落とし込むため、以下にサードパーティーライブラリに依存しない最小実装を示す。SBOXはGF(2^8)の逆元から直接生成し、標準AES S-boxと一致する。

import hashlib, struct

def gf_mul(a, b):
    r = 0
    for _ in range(8):
        if b & 1: r ^= a
        a = ((a << 1) ^ 0x11B) & 0xFF if a & 0x80 else (a << 1) & 0xFF
        b >>= 1
    return r

def gf_inv(x):
    if x == 0: return 0
    for y in range(1, 256):
        if gf_mul(x, y) == 1: return y

def rotl(v, n): return ((v << n) | (v >> (8 - n))) & 0xFF

SBOX = bytes(gf_inv(x) ^ rotl(gf_inv(x), 1) ^ rotl(gf_inv(x), 2)
             ^ rotl(gf_inv(x), 3) ^ rotl(gf_inv(x), 4) ^ 0x63 for x in range(256))

def crc_state(data):
    s = 0xFFFFFFFF
    for v in data:
        s ^= v
        for _ in range(8):
            s = (s >> 1) ^ 0xEDB88320 if s & 1 else s >> 1
    return s

def crc32(data): return crc_state(data) ^ 0xFFFFFFFF

def ns(data): return bytes((v >> 4) | ((v & 0x0F) << 4) for v in data)

WORD_ORDER = (7, 0, 2, 5, 6, 3, 1, 4)
LANE3 = (0xB, 0x2, 0xF, 0x6, 0x8, 0x9, 0xE, 0x3, 0x1, 0xD, 0x7, 0x5, 0xC, 0xA, 0x0, 0x4)
ROUND_KEYS = tuple(bytes.fromhex(h) for h in (
    "786873306f6832697534616e376f6732", "5a3241711e764471e0d4fb95096b0c3e",
    "43713041275115398f5bfa6ff3c8c4fa", "1e6f5f1e27766300174cf798864b8f75",
    "ed82ddc30e781b293c70b32b4539b6c3", "52d00dce760e1578cabaddf62717a162",
    "2bfbf638faf4e18c2d9711e7789c3d5f", "93689ea6fe0aeb0467f0ad4a819ba6f9",
    "fa920caa767c97888c7ca1eb61bf19e0"))
FINAL_A = bytes.fromhex("69fbf75dee92059829554ea58b130aea")
FINAL_C = bytes.fromhex("34cf3865648a181d73d6ffaa5f55bf34")
CBC_IV = bytes.fromhex("6e2052fb01f05fd238ad54534bd00831")

def digest_lane(canonical: bytes, counter: int) -> bytes:
    digest = hashlib.sha256(canonical + struct.pack('<I', counter)).digest()
    state = b''.join(digest[i*4:i*4+4] for i in WORD_ORDER)
    b0, b1, b2, b3 = state[0:8], state[8:16], state[16:24], state[24:32]
    s = ns(b0)
    lane0 = bytes(v ^ (crc_state(s) & 0xFF) for v in s)
    cn = ((b1[0] << 4) | (b1[7] >> 4)) ^ ((b1[6] << 4) | (b1[1] >> 4))
    lane1 = bytes(v if i in (3, 5) else ns(bytes((v,)))[0]
                  for i, v in enumerate(bytes(v ^ (cn & 0xFF) for v in b1)))
    sub = bytes(t for v in b2 for t in (LANE3[v >> 4], LANE3[v & 0x0F]))
    lane2 = bytes(v ^ (crc_state(sub) & 0xFF) for v in b2)
    first = b3[0] ^ 0xAE
    c0 = ns(bytes((first,)))[0]
    second = b3[1] ^ c0 ^ 0xAE
    c1 = ns(bytes((second,)))[0]
    mask = c0 ^ c1 ^ 0xAE
    lane3 = bytes((c0 ^ c1 ^ first, c1 ^ second, *(v ^ mask for v in b3[2:])))
    return lane0 + lane1 + lane2 + lane3

def transpose(s): return bytes(s[r*4+c] for c in range(4) for r in range(4))

def shift_rows(s): return b''.join(s[r*4+r:r*4+4] + s[r*4:r*4+r] for r in range(4))

def mix_columns(s):
    t = transpose(s); out = bytearray()
    for off in range(0, 16, 4):
        a, b, c, d = t[off:off+4]
        out += bytes((gf_mul(a,2)^gf_mul(b,3)^c^d, a^gf_mul(b,2)^gf_mul(c,3)^d,
                      a^b^gf_mul(c,2)^gf_mul(d,3), gf_mul(a,3)^b^c^gf_mul(d,2)))
    return transpose(bytes(out))

def s1_block(block):
    s = shift_rows(transpose(block))
    for rk in ROUND_KEYS:
        s = bytes(SBOX[v ^ m] for v, m in zip(s, rk))
        s = shift_rows(mix_columns(s))
    s = bytes(SBOX[v ^ a] ^ c for v, a, c in zip(s, FINAL_A, FINAL_C))
    return transpose(s)

def s1_cbc(payload):
    prev, out = CBC_IV, bytearray()
    for off in range(0, len(payload), 16):
        prev = s1_block(bytes(x ^ y for x, y in zip(payload[off:off+16], prev)))
        out += prev
    return bytes(out)

def build_s1_raw(canonical: bytes, counter: int, timestamp_s: int) -> bytes:
    lane = digest_lane(canonical, counter)
    seed = (struct.pack('<I', timestamp_s) + bytes.fromhex('51244a19')
            + b'\x00\x00' + lane + bytes.fromhex('170e'))
    source = b'\x01' + s1_cbc(seed + b'\x04' * 4) + crc32(seed).to_bytes(4, 'big')
    return (b'\x00' + struct.pack('<I', counter) + source
            + crc32(source).to_bytes(4, 'big'))

5. main_hmac：Shieldのkey64を取り出す

main_hmacはサーバーが返す暗号化素材であり、現在のリクエストのHMAC結果ではない。クライアントは/api/sns/v1/system_service/vfc_codeのレスポンスヘッダーxy-ter-strからBase64文字列を取得する。

raw96 = Base64Decode(xy-ter-str)
plain = CustomAES-CBC-Decrypt(raw96, round_keys, IV=0)
plain = header16 || key64 || footer16

固定ヘッダー：

3501323400020861667a666607176639

復号結果は96バイトでなければならず、先頭16バイトはheaderと一致する。Shieldが使うのは中央の64バイトで、footerはリクエストHMACには関与しない。ここではPKCS#7のアンパディングを行わない。

96バイトはちょうどAESの6ブロック分だが、長さだけでAESだと証明することはできない。根拠には、ブロック変換における標準S-box、行シフト、列混合に加え、deviceIdを基にしたラウンドキー展開もある。標準AESとの差異は、別のカスタムS-boxではなく、以下のRconに集中している。

5.1 カスタムAES鍵展開

deviceIdには、ハイフン付き36バイトUUIDのASCII表現を使う。

key16 = utf8(deviceId)[0:16] XOR MASK
MASK  = f1892131ff001123f1001356f1234890

続いてAES-128の鍵展開を実行するが、Rconは次の10個のビッグエンディアンu32に置き換える。

12310000 02000100 04020000 08020200 10102000
30020400 40002000 80002000 1b002000 36200200

w[0..3] = key16 按大端拆成四个 u32
for i = 4..43:
    t = w[i-1]
    if i mod 4 == 0:
        t = SubWord(RotWord(t)) XOR Rcon[i/4-1]
    w[i] = w[i-4] XOR t

RotWordは4バイトを1バイト分左ローテートし、SubWordは各バイトに標準AES S-boxを適用する。合計44ワード、つまり176バイトのラウンドキーが得られる。

CBC復号では、P_i = D_round_keys(C_i) XOR C_(i-1)先頭ブロックの前ブロックには16個のゼロバイトを使う。平文スライス[0:16]、[16:80]、[80:96]から、それぞれheader、key64、footerを得る。

ブロック暗号のラウンド関数は標準AESを使う。初期AddRoundKey、9ラウンドのSubBytes、ShiftRows、MixColumns、AddRoundKeyを行い、最後のラウンドではMixColumnsを省略する。変更されているのはkey scheduleなので、標準AESライブラリを呼び出してkey16だけを渡すと異なる結果になる。

例：

deviceId = aaaaaaaa-bbbb-4ccc-8ddd-eeeeeeeeeeee
key16    = 90e840509e617042dc627134930e7cf3
w[4]     = 29c94d8c

この復元が正しいかを判定するには、deviceIdをまたいで平文のheaderとkey64を検証する必要がある。対応する素材18組では復号結果が一致している。単に暗号化と復号を往復させるだけでは、この照合の代わりにならない。

deviceId だけから key64 をオフラインで導くローカルな公式は存在しない。libxyass は xy-ter-str を受信したときだけ、それを prefs の s/main_hmac に書き込み、deviceId を AES のラッピング鍵として使って64バイトを復号する。so には f_key のリテラルはない。prefs が空のコールドスタートでは Shield は70バイトのままになる。通常のプロトコルで main_hmac を取得すれば、key64 を取り出せる。

5.2 逆方向の暗号化

同じdeviceId、既知のkey64、footerが与えられれば、main_hmacを逆算して再構成できる。

plain96 = header16 || key64 || footer16
C_prev = 16 个零字节
for 每个连续 16 字节明文块 P_i:
    C_i = E_round_keys(P_i XOR C_prev)
    C_prev = C_i
main_hmac_b64 = Base64(C_0 || C_1 || ... || C_5)

Eには5.1節のカスタムラウンドキーを使い、平文は6ブロックで固定して追加のパディングは行わない。Shieldがfooterを使わないからといって省略してはならず、footerも入力として保持する必要がある。逆方向の暗号化で示せるのはラッパーを再構成できることだけであり、deviceIdから未知のkey64を生成できることや、サーバーが配布するものと同じ新しい素材を自力で得られることを意味しない。

key64の取り出しも標準ライブラリだけで行える。SBOXは4.4節の例と同じで、復号には本節のラウンドキーを使った標準AESブロック関数を用いる。

import base64, hashlib

RCON = [0x12310000, 0x02000100, 0x04020000, 0x08020200, 0x10102000,
        0x30020400, 0x40002000, 0x80002000, 0x1b002000, 0x36200200]
MASK = bytes.fromhex('f1892131ff001123f1001356f1234890')
HEADER = bytes.fromhex('3501323400020861667a666607176639')

def rotw(w): return ((w << 8) | (w >> 24)) & 0xFFFFFFFF

def subw(w): return int.from_bytes(bytes(SBOX[b] for b in w.to_bytes(4, 'big')), 'big')

def key_expand(key16: bytes) -> bytes:
    w = [int.from_bytes(key16[i*4:i*4+4], 'big') for i in range(4)]
    for i in range(10):
        t = subw(rotw(w[-1]))
        w.append(w[-4] ^ t ^ RCON[i])
        for _ in range(3):
            w.append(w[-4] ^ w[-1])
    return b''.join(x.to_bytes(4, 'big') for x in w)

def xtime(a): a <<= 1; return (a ^ 0x11B) & 0xFF if a & 0x100 else a & 0xFF

def gmul(a, b):
    r = 0
    for _ in range(8):
        if b & 1: r ^= a
        b >>= 1; a = xtime(a)
    return r

INV = [0] * 256
for i, v in enumerate(SBOX):
    INV[v] = i

def inv_shift_rows(s):
    return bytes([s[0], s[13], s[10], s[7], s[4], s[1], s[14], s[11],
                  s[8], s[5], s[2], s[15], s[12], s[9], s[6], s[3]])

def inv_mix_columns(s):
    o = bytearray(16)
    for c in range(4):
        a = s[c*4:c*4+4]
        o[c*4+0] = gmul(a[0],14) ^ gmul(a[1],11) ^ gmul(a[2],13) ^ gmul(a[3],9)
        o[c*4+1] = gmul(a[0],9)  ^ gmul(a[1],14) ^ gmul(a[2],11) ^ gmul(a[3],13)
        o[c*4+2] = gmul(a[0],13) ^ gmul(a[1],9)  ^ gmul(a[2],14) ^ gmul(a[3],11)
        o[c*4+3] = gmul(a[0],11) ^ gmul(a[1],13) ^ gmul(a[2],9)  ^ gmul(a[3],14)
    return bytes(o)

def xor16(a, b): return bytes(x ^ y for x, y in zip(a, b))

def aes_decrypt_block(block: bytes, rk: bytes) -> bytes:
    s = xor16(block, rk[160:176])
    for i in range(9, 0, -1):
        s = inv_shift_rows(s)
        s = bytes(INV[b] for b in s)
        s = xor16(s, rk[i*16:(i+1)*16])
        s = inv_mix_columns(s)
    s = inv_shift_rows(s)
    s = bytes(INV[b] for b in s)
    return xor16(s, rk[0:16])

def main_hmac_key64(main_hmac_b64: str, device_id: str) -> bytes:
    raw = base64.b64decode(main_hmac_b64)
    key16 = bytes(a ^ b for a, b in zip(device_id.encode()[:16], MASK))
    rk = key_expand(key16)
    plain, prev = bytearray(), bytes(16)
    for off in range(0, len(raw), 16):
        block = raw[off:off+16]
        plain += xor16(aes_decrypt_block(block, rk), prev)
        prev = block
    assert bytes(plain[:16]) == HEADER
    return bytes(plain[16:80])   # key64

6. Shield：リクエストHMACとSSK拡張

外側の形式は次のとおり。

Shield = "XY" + Base64(raw)

ここではパディングを保持した標準Base64を使う。rawには2種類の長さがある。基本構造は70バイトで、main_hmacとmain_sskの両方がある場合は118バイトになる。

6.1 HMACの原文

各項目を次の順序で連結する。改行、疑問符、追加の区切り文字は入れない。

source =
    path
 || query
 || xy-common-params
 || xy-direction
 || xy-live-net-bandwidth
 || xy-live-net-networktype
 || "platform=android&build=9431801&deviceId=" || deviceId
 || xy-scene
 || body

不足しているヘッダーは空文字列として扱い、最後にUTF-8でバイト列にする。host、scheme、METHODはこの原文には含めない。platform部分はバージョン定数とdeviceIdから再構成し、異なる可能性のあるxy-platform-info値を直接読み取らない。

bodyは実際に送信する内容と一致しなければならない。フォームリクエストでは、パーセントエンコード済みのフォームテキストを署名する。JSONでは、「意味が同じ」JSONを作り直すのではなく、最終的にシリアライズされたバイト列を署名する。

6.2 カスタムHMAC-MD5

HMACの外側の構造は変わらない。

inner = MD5_mod((key64 XOR 0x36) || source)
outer = MD5_mod((key64 XOR 0x5c) || inner)
request_hmac = outer

key64はちょうど64バイトなので、XOR 0x36とXOR 0x5cはそれぞれ各バイトと同じ定数とのXORを表す。innerとouterはいずれも16バイトの生ダイジェストであり、outerを計算する際にinnerをhex文字列へ変換してはならない。

nativeの初期化と64ラウンドの圧縮は、依然としてMD5の構造を保っている。そのため、初期状態、ローテーションテーブル、加算定数、メッセージインデックス、レジスタ更新を項目ごとに比較できる。以下の変更を合わせたものがMD5_modである。

初期状態は標準MD5と逆順にする。

a = 0x10325476
b = 0x98badcfe
c = 0xefcdab89
d = 0x67452301

Tテーブル：

e9c9b756 d71ba479 241081db 681088d9 9b14f7af ff1f5bb1 881cd7be 66666122
f6666193 a619639e 49140921 c11dceee f51c0faf 4717c62a a9104613 fd169501
f61e2562 02741453 d221e691 e213fbc9 2261cde6 f2d50d97 425a14ed a277e905
f277a3f9 626f12d9 922a4c9a c040b340 265e5a51 e9f6c7aa d63f105d c35707d6
fffc3942 977cd691 a4bcea44 4bdccfa9 bebcbc70 288c7ec6 f6cc4b60 eaac27fa
d4ec1095 d9dcd039 e6dc88e5 048c1d05 1fa27cf9 6d9d6122 c4ac5665 fde5391c
f4292244 ab9423a7 f593a039 655b59c3 452aff97 f5ef247d 85845dd1 850ccc92
f99926e0 f9997e4f a9994314 c5537e82 450811a1 450811a6 bd3af235 eb86d391

まずTをKにコピーし、次のように変更する。

K[16] = T[16] & 0xff00ff00
K[19] = T[19] & 0xff0011ff
K[29] = T[29] & 0xff110010
交换 K[39]、K[40]
交换 K[41]、K[42]

ローテーションビット数は、まず標準MD5の4組をそれぞれ4回ずつ繰り返す。

7,12,17,22 / 5,9,14,20 / 4,11,16,23 / 6,10,15,21

その後、10か所を上書きする。

S[0]=6, S[1]=13, S[3]=21, S[7]=20, S[10]=16, S[13]=13
S[39]=4, S[40]=23, S[41]=16, S[42]=11

ラウンド関数とメッセージインデックス：

i < 16: f(b,c,d) = (b&c) | (~b&d), g=i
i < 32: f(b,c,d) = (d&b) | (~d&c), g=(5*i+1)%16
i < 48: f(b,c,d) = b^c^d,           g=(3*i+5)%16
其它:   f(b,c,d) = c^(b|~d),       g=(7*i)%16

覆盖 g[39],g[40],g[41],g[42] 为 13,10,3,0

ラウンド39以降は、PINに従って入力レジスタを並べ替える。

39:       (3,0,1,2)
40..42:   (0,1,2,3)
43:       (1,2,0,3)
44:       (1,3,0,2)
45..63:   (2,3,0,1)

1 ブロックの 64 バイトをリトルエンディアンで 16 個の u32 に分解し、M とする。

a,b,c,d = state
for i = 0..63:
    按轮号选择 f 和 g
    A,B,C,D = (a,b,c,d)                   当 i <= 38
            = 按 PIN[i] 重排 (a,b,c,d)   其它情况

    x = (A + f(B,C,D) + M[g] + K[i]) & 0xffffffff
    new = (B + rotl32(x,S[i])) & 0xffffffff

    a,b,c,d = D,new,B,C    当 i <= 38 或 i == 63
            = B,C,D,new    当 39 <= i <= 62

state = 原 state 与 (a,b,c,d) 逐字相加，截断到 32 位

Padding は MD5 の規則に従い、追加 0x80、長さを 64 で割った余りが 56 になるまでゼロで埋め、その後、元のビット長をリトルエンディアンの u64 で書き込む。すべてのブロックを処理したら、state を 4 個のリトルエンディアン u32 として出力する。

この種の変種では、初期状態、テーブル定数、ラウンド関数、メッセージのインデックス、レジスタの更新順序をそれぞれ確認する必要がある。MD5 の T テーブルだけを置き換えれば済むわけではなく、ローテーション前の 32 ビット切り捨ても省略できない。

ダイジェストの確認値：

MD5_mod(ASCII("00000000-0000-0000-0000-000000000000"))
= 94d3c51d13033535c7ca0a1183028c1d

6.3 70 バイトの基本構造

定数は次のとおり。

RC4_KEY = UTF-8("逆向违法，即刻停止！Reverse engineering is illegal. Cease now!")
MASK36  = 606b39fd3c39443008502297d736827cf3903c05d0e77e0737f77066f77460435bd69068
MASK16  = b3661b2425c8d1cf9674e8218b30b91a
HDR_PREFIX = 8dfe00055569
HDR_SUFFIX = a6d7a54f949cf960
EMPTY_HF   = 9a89
NONEMPTY_HF = 9e8a

RC4_KEY は 72 バイトの UTF-8 文字列である。標準的な RC4 の KSA と PRGA を使用する。

tail = request_hmac XOR MASK16     有 main_hmac 时
     = MASK16                     无 main_hmac 时

plain54 = c1 || (utf8(deviceId) XOR MASK36) || f4 || tail
header16 = HDR_PREFIX || hf || HDR_SUFFIX
raw70 = header16 || RC4(RC4_KEY, plain54)

hf は main_hmac の有無に応じて EMPTY_HF または NONEMPTY_HF を選択するもので、HMAC を切り詰めた値ではない。基本構造の長さは 16 + 1 + 36 + 1 + 16 = 70 バイトである。

main_hmac がない場合、リクエスト HMAC は計算されない。このとき raw70 は deviceId のみに依存し、path、query、body を変更しても変わらない。main_hmac を取得して初めて、tail によってリクエスト内容が Shield に結び付けられる。70B と 118B はそれぞれ 96 文字と 160 文字の Base64 にエンコードされ、さらに XY を加えると全体の長さは 98 文字と 162 文字になる。

6.4 48 バイトの SSK 拡張

SSK の有無で出力を比較すると、基本部分は 70 バイトのままで、追加の末尾部分が 48 バイトあることが分かる。シリアライズ前の内容をさらに分解すると、2 つの TLV を識別できる。tag 4 は 20 バイトの証明、tag 5 は 24 バイトの証明である。

native は main_ssk の標準 Base64 ASCII を使用し、その 32 バイトの元データを直接使うわけではない。

main_ssk_b64 = Base64(main_ssk32)             # 44 字符，含 =
ssk_proof24  = nonce4 || SHA1(ASCII(main_ssk_b64) || nonce4)
req_proof20  = SHA1(request_hmac16 || ssk_proof24)
plain48      = 04 14 || req_proof20 || 05 18 || ssk_proof24

長さバイト 14 と 18 は 16 進数で、それぞれ 20 と 24 を表す。

拡張には、RC4 キーストリームの指定範囲を使用する。

stream = RC4(RC4_KEY, 116 个零字节)
extension = plain48 XOR stream[68:116]
raw118 = raw70 || extension

オフセットが 70 ではなく 68 なのは、最終的な raw の先頭 2 バイトが後処理で挿入されるためである。基本構造の同等な構築と拡張のストリームオフセットはそれぞれ維持する必要があり、plain54 と plain48 を単純に連結して RC4 をもう一度実行してはならない。

main_hmac が空の場合は、SSK があってもこの拡張分岐には入らない。query を変更すると request_hmac が変わり、それによって req_proof も変わる。SSK を変更した場合は、まず ssk_proof が変わる。

3種類のSSKと3種類のURLによる9組の固定 nonce サンプルでは、118バイト全体を再現できる。4バイトの nonce は libxyass の拡張分岐にある生成関数から得られ、getrandomgetrandom や /dev/urandom から取得したものではない。/dev/urandomこの関数はプロセス内のアトミックカウンタをインクリメントしてから、現在のスタック上にあるsp+0x20sp+0x20 というスロットのアドレス下位32ビットと XOR し、リトルエンディアンで書き出す：

counter = atomic_inc(global_counter)          # 观测到的会话从 1 开始
nonce4  = u32le(counter XOR trunc32(sp + 0x20))

続いて SHA1(ASCII(main_ssk_b64) || nonce4)SHA1(ASCII(main_ssk_b64) || nonce4)を tag 5 に格納する。sp+0x20sp+0x20 は実行時のスタック配置であり、プロトコル定数ではない。エミュレーターではスタックアドレスが安定しているため、連続するリクエストでは nonce の下位ビットがカウンタに応じて変化し、カウンタが16のべき乗をまたぐと単純なインクリメントではなく XOR による反転が現れる。実機ではASLRにより、この値はプロセスごとに異なる4バイト値になる。スタックアドレスが分からない移植実装でも、nonce はリクエストごとの入力として扱うべきであり、プロセスをまたいで共通の定数テーブルにしてはならない。同一プロセスで連続して取得した32組の native 出力は、上記の式を満たしている。

main_hmac のない 70B 形式はカスタム MD5 を必要とせず、単独で再現できる。

import base64
from urllib.parse import urlsplit

RC4_KEY = '逆向违法，即刻停止！Reverse engineering is illegal. Cease now!'.encode()
MASK36 = bytes.fromhex('606b39fd3c39443008502297d736827cf3903c05d0e77e0737f77066f77460435bd69068')
MASK16 = bytes.fromhex('b3661b2425c8d1cf9674e8218b30b91a')
HDR_PREFIX = bytes.fromhex('8dfe00055569')
HDR_SUFFIX = bytes.fromhex('a6d7a54f949cf960')
EMPTY_HF = bytes.fromhex('9a89')

def rc4(key: bytes, data: bytes) -> bytes:
    s = list(range(256)); j = 0
    for i in range(256):
        j = (j + s[i] + key[i % len(key)]) & 0xFF
        s[i], s[j] = s[j], s[i]
    i = j = 0
    out = bytearray()
    for b in data:
        i = (i + 1) & 0xFF
        j = (j + s[i]) & 0xFF
        s[i], s[j] = s[j], s[i]
        out.append(b ^ s[(s[i] + s[j]) & 0xFF])
    return bytes(out)

def shield_70b(device_id: str, url: str, headers: dict) -> str:
    parts = urlsplit(url)
    devid = device_id.encode()
    plain = bytearray([0xC1])
    plain += bytes(a ^ b for a, b in zip(devid, MASK36))
    plain.append(0xF4)
    plain += MASK16
    payload = HDR_PREFIX + EMPTY_HF + HDR_SUFFIX + rc4(RC4_KEY, bytes(plain))
    return 'XY' + base64.b64encode(payload).decode()

shield_70b('4ee6f1f8-75e5-313d-993b-e5a8aaedbaae',
           'https://edith.xiaohongshu.com/api/sns/v1/system_service/vfc_code'
           '?phone=13800138000&zone=1&type=login',
           {'xy-common-params': '', 'xy-direction': '90'})
# 'XYjf4ABVVpmomm16VPlJz5YE0FodlR1qnMmVnCszuzcoCJfJOhpEN1aN/UnJcBJa1K0LUqi0v+Qdey0hyMHeAio6PLpd74zQ=='

7. SSK：X25519 と AES-256-GCM

クライアントは /api/sns/v1/user/activate に一時的な X25519 公開鍵を送信し、フィールド名は client_public_key_base64 である。公開鍵はまず標準 Base64 に変換し、その後フォームの規則に従ってパーセントエンコードする。

SSK サーバー公開鍵は次のとおり。

2abd22ca0b02bb78a760935708be24e09bb369843669f235c5bc1cec11fab26f

shared = X25519(client_private, SSK_SERVER_PUBLIC)
blob   = Base64Decode(data.ssk)
       = iv12 || ciphertext32 || tag16
ssk32  = AES-256-GCM-Decrypt(shared, iv12, ciphertext32 || tag16, AAD=空)

デコード層は URL-safe Base64 にも対応できる。shared はそのまま 256 ビットの AES キーとして使われ、中間に HKDF はない。全ゼロの shared は拒否すべきであり、GCM タグは必ず検証し、平文は 32 バイトでなければならない。SSK の GCM nonce は 12 バイトで、Shield 拡張の nonce4 とは関係がない。

この処理を MUA の key/IV 分割と混同してはならない。MUA は共有秘密を AES-128-CBC の key と IV に分割するのに対し、SSK は共有秘密全体を AES-256-GCM に使い、IV はレスポンスから読み取る。

このリクエストとレスポンスでは、同じ一対の一時鍵を共有する必要がある。リクエストでは公開鍵を送信し、レスポンスを処理する際には対応する秘密鍵を保持する。秘密鍵を再生成して元のレスポンスを復号すると shared が変わり、GCM タグの検証に失敗する。MUA の scalar と activate の一時秘密鍵も、独立したセッション情報として管理すべきである。

RFC 7748 のベクトルで X25519 標準プリミティブを確認でき、GCM メッセージを組み立てれば復号とタグ拒否の挙動を確認できる。ただし、これらだけで、ある実際の activate レスポンスが同じ情報を使っていると証明することはできない。

main_ssk の復号：

from cryptography.hazmat.primitives.ciphers.aead import AESGCM

blob = base64.b64decode(encrypted_ssk)   # iv[12] || ciphertext+tag
main_ssk = AESGCM(shared).decrypt(blob[:12], blob[12:], None)   # 32B

shared 第2.1節の x25519()。peer は本節の SSK サーバー公開鍵であり、MUA の MUA_SERVER_PUBLIC_KEY ではない。得られた32バイトはそのまま AES-256-GCM の鍵になるため、第2.1節の slotA を再利用してはならない。

8. 登録リクエスト：GID と暗号化 snapshot

登録 API は POST /api/v1/register/android である。リクエストには MUA、SIG、S1 を付けるが、Shield は付けない。body は次のキー順で生成したコンパクトな JSON である。

a, c, d, e, k, p, s, v

a、c、k、p、s、v は同じ MUA Part1 と一致する。e は平文の identity オブジェクトで、初回起動時の empty-identity サンプルでは次のようになる。

{"device_id":"","rr":"0","sid":"","uid":""}

d のエンコード処理は次のとおり。

snapshot JSON
  → 顶层键按字符串排序、紧凑 UTF-8
  → zlib(level=6)
  → PKCS#7
  → AES-128-CBC(slotA[0:16], slotA[16:32])
  → Base64URL，去掉 =

d は MUA Part2 と同じセッションの slotA と外側のアルゴリズムを共有するが、平文は異なるデータ構造である。MUA Part2 の文字列をそのまま d に使うことはできない。

ある登録サンプルでは、snapshot の平文が 960 バイト、zlib の結果が 448 バイトで、パディング後の暗号文は 464 バイトだった。長さは圧縮後の内容によって決まり、プロトコルで固定された値ではない。

登録署名の依存関係は次のとおり。

会话材料 → MUA
同一 slotA → 加密 snapshot 得到 d → 生成最终注册 body
MUA + 最终 body 的 SHA256 → canonical → SIG / S1

署名の完了後に body を並べ替えたり変更したりすることはない。サーバーのレスポンスに含まれる data.g は、観測したサンプルでは 56 文字の hex であり、そのまま x-mini-gid と共通パラメータの gid に書き込まれる。

フィールド d と body の組み立て：

from collections import OrderedDict

def register_body(snapshot: dict, *, counter: int, pub_hex: str,
                  random_hex: str, key: bytes, iv: bytes) -> bytes:
    d = part2(snapshot, key, iv)   # 与 Part2 同一外层：zlib -> PKCS7 -> AES-CBC -> Base64URL
    body = OrderedDict((
        ('a', 'ECFAAF01'), ('c', counter), ('d', d),
        ('e', OrderedDict((('device_id', ''), ('rr', '0'), ('sid', ''), ('uid', '')))),
        ('k', pub_hex), ('p', 'a'), ('s', random_hex), ('v', '2.9.99'),
    ))
    return json.dumps(body, separators=(',', ':')).encode()

ここでの key と iv は、同じ登録処理の MUA Part2 と slotA を共有する。body の組み立てが完了した後、第 10 節の順序で SIG と S1 を計算する。

9. snapshot 内のハッシュとエンコード用フィールド

snapshot のフィールドには条件分岐があり、24 個のキーはあくまで基準にすぎない。たとえば他の条件が同じ場合、SDK 28 以降では x252 と x253 が追加される。オプションの収集結果によっては、さらにキーが追加または削除される。ここでは再現性に影響するハッシュとエンコードの関係だけを扱う。

9.1 x86：XXH3-128 と CRC32

x86 = uppercase_hex(XXH3_128bits_withSeed(input, 0x48FA5412), 32)
      || uppercase_hex(CRC32(input), 8)

XXH3 には標準の seeded 128-bit アルゴリズムを使用し、結果を high64 << 64 | low64 の形式に整形する。CRC32 は標準的な IEEE 反映形式で、常に 8 文字の hex で出力する。

入力は、正常に収集された内容を区切り文字なしで順番に連結したものである。

android_id ASCII
→ 非空 gcbooster_uuid、pps_oaid 的规范化字节
→ OAID ASCII（对应提供者分支启用时）
→ attestation 原始字节（采集分支存在时）
→ SoC serial（存在时）
→ resolution ASCII，例如 1080,1920,480
→ MMC cid（存在时）
→ UFS id（存在时）

SoC/MMC/UFS および上記 Settings 値は、前後の ASCII 空白を取り除いたうえで先頭 200 バイトを切り出して正規化する。cpuinfo と boot_id はこの入力経路には含まれない。

この種のフィールドは、単一変数の差分で確認するのが適している。他の収集項目を固定して入力を 1 つだけ変更し、連結バッファーと最終ハッシュを同時に観察する。固定 seed の根拠には、出力への当てはめだけでなく、native における即値のロードも含めるべきである。XXH3 の短・中・長入力の各分岐には標準実装を使い、2 つの 64-bit hash を単純に連結して 128-bit の代わりにしてはならない。

x86 の組み合わせは 1 行だけで、xxh3_128 の完全な実装は付録 B に示す。

import zlib

def x86(data: bytes, seed: int = 0x48FA5412) -> str:
    return f'{xxh3_128(data, seed):032X}{zlib.crc32(data):08X}'

9.2 x137：JNI method ID の MD5

次の 7 個の JNI method ID を順番にリトルエンディアンの u32 としてエンコードし、28 バイトに連結して標準 MD5 を計算し、大文字の hex で出力する。

Map.size()I
Map.get(Ljava/lang/Object;)Ljava/lang/Object;
Map.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
Map.remove(Ljava/lang/Object;)Ljava/lang/Object;
Map.keySet()Ljava/util/Set;
Map.values()Ljava/util/Collection;
Map.entrySet()Ljava/util/Set;

ハッシュの計算式と ID の出所は、分けて考える必要がある。

実機での経路は特定できている。native は java/util/Map を実行しFindClass、上表の順に各1回呼び出しGetMethodID、str x0 で64ビットの jmethodID をグローバルテーブルに書き込む。その後、MD5 は各スロットの先頭4バイトだけを読み取るため、リトルエンディアンの下位32ビットになる。実機サンプルのポインタはすべて4GB未満で上位32ビットが0だったため、trunc32 は完全なポインタと同じ値になる。ただし、すべての64ビットアドレス配置に一般化はできない。

これらの ID は ART のメソッドオブジェクトのアドレスで、約2.8 MiB のファイルバックエンドのない rw-rw- マッピングに収まっている。同じ起動中にプロセスを再起動しても7つの値は変わらないが、端末を再起動するとマッピングのベースアドレスがランダム化され、7つの値はまとめて移動し、相対オフセットは変わらない。したがって x137 は起動中だけ有効なランタイム変数であり、サーバーが固定テーブルで厳密に検証することはできない。シミュレーション環境では、ID の代わりに記述子の Java hashCode を使えるが、これはフォールバック用の oracle にすぎず、ART の割り当て公式ではない。

x137：

import hashlib, struct

def x137(method_ids) -> str:
    return hashlib.md5(struct.pack('<7I', *method_ids)).hexdigest().upper()

9.3 attestation と環境分岐

x147 は attestation バイト列を UTF-8 としてデコードし、不正なシーケンスを U+FFFD に置換する。x86 は元のバイト列を使用し、デコード後に再エンコードした x147 を使うことはできない。

def x147(attestation_bytes: bytes) -> str:
    return attestation_bytes.decode('utf-8', errors='replace')

入力元は特定できている。native は Class.forName をロードしcom.huawei.attestation.HwAttestationManager、リフレクションで呼び出す。このクラスは APK 内にはなく、Huawei のシステムクラスである。クラスが存在する場合、x148 は空文字列になり、元のバイト列が x86 に入る。クラスのロードに失敗すると x147 と x148 はどちらも現れず、attestation のバイト列も x86 には入らない。失敗後にはさらにgetDeviceID(I)[B と attestation_service を検出するが、これらで IHwTelephony$Stub のgetDeviceID戻り値を置き換えることはできない。

Xiaomi MI 6（Lineage、Huawei パッケージなし）では、プロセスを3回再起動してもすべて省略分岐になり、登録 snapshot の x147 経路からバイト列は生成されなかった。同じプロセス内でAMediaDrm_getPropertyByteArray("deviceUniqueId") は安定して32バイトを返すが、これは Widevine の取得値である。HwAttestationManager を隠しても x147 は引き続き消えるため、これは x147 の入力ではない。Huawei TEE のgetDeviceIDのペイロードは、依然として端末固有であり未調査である。

シミュレーション環境では、デフォルトで引き続き SHA256(UTF8(deviceId)) をフォールバックとして使う。元のバイト列を注入することも、明示的に省略分岐を選ぶこともできる。

同様に、OAID プロバイダー、ファイルの可読性、JNI 環境によっても snapshot は変わる。特定の固定環境におけるシリアライズと暗号化を再現できても、すべての端末メーカーの収集動作を再現したことにはならない。

9.4 x165：ファイルシステム情報の文字列エンコード

x165 は、12 個の固定された対象について、ファイルの状態とファイルシステムの状態をオブジェクトとしてエンコードする。成功した項目のキーは 1 から始まる 10 進数の序列表現で、/sdcard は "12" に対応する。各項目の形式は次のとおり。

{ctime_sec}{ctime_nsec:09d}-{inode}-{device}-{fsid}-{fstype}

固定の序号と対象は次のとおり。これらは Android の収集対象であり、記事読者のコンピューター上のディレクトリではない。

この MI 6 では、12個の対象のうち /data/system、/data/data/、/data/data/com.android.shell、/data/system/install_sessions、/sdcard、/dev/fd/0、/dev/fd/1、radio/debuggerd の2つの property ノードも存在する。一方、webview、GMS のデータディレクトリ、ffs_prop は存在しない。/system/bin/getprop と /system/bin/sh はどちらも存在し、9.5節の helper 規則に従えば、この端末の x128 は省略キーになる。データ消去後の register snapshot を使った直接照合はまだ行っていない。

ctime の秒とナノ秒の間に区切り文字はなく、ナノ秒は最低 9 桁で、不足分はゼロで補う。両者は符号付き 64 ビット整数として出力する。inode、device、fstype は符号なし 64 ビットとして出力する。fsid は 2 個の u32 をそれぞれ 8 文字の小文字 hex にエンコードし、low、high の順に連結する。

stat に失敗して statfs に成功した場合、ctime、inode、device はゼロにし、fsid と fstype は残す。stat に成功して statfs に失敗した場合、fsid はリテラル * となり、fstype は 0 になる。両方に失敗した場合は、その項目を省略する。すべての対象に失敗した場合、x165 の値は空オブジェクトではなく null になる。

たとえば第 12 項目だけを残し、stat の値がすべてゼロで、fsid の 2 つの語が 0xd3609fe8 と 0x04970d6b、fstype が 10 進数の 61267 である場合、次のようになる。

{"12":"0000000000-0-0-d3609fe804970d6b-61267"}

9.5 x170 と x128 の条件分岐

観測したクラスロード実験では、 com.android.id.impl.IdProviderImpl が存在すると x170 は "id_provider" になり、OAID は x173、x174、x175、x181 にも書き込まれ、x86 にも 1 回追加される。そのクラスを隠すと x170 は "vivo" に戻り、4 つの複製は消え、x86 に OAID は追加されなくなる。x171 には引き続き OAID が残る。これはこのエミュレーター環境での分岐結果であり、manufacturer 文字列だけから実際の端末でのプロバイダーを導き出すことはできない。

x128 は、ファイルを開くのに失敗した後の errno=2 のテキスト "No such file or directory" に対応する。観測した実験では、getprop と sh の 2 つのシステムヘルパーを同時に提供するとこのキーは消え、getprop だけを提供した場合は残る。boot_id は別途 x47 に入り、サンプルでは末尾の改行を削除した後、先頭 35 文字を残し、x86 には関与しない。異常な長さやエンコードに対する native の完全な読み取り動作は、まだ網羅できていない。

9.6 snapshot フィールドと出現条件

以下は、これまでに対応付けたフィールドである。文字列は UTF-8 でシリアライズし、容量フィールドはバイト数を表す整数とする。「存在」は、収集分岐が成功した場合、または呼び出し側から明示的に入力が与えられた場合を指す。

SoC serial、MMC cid、UFS idはそれぞれ /sys/devices/soc0/serial_number、/sys/block/mmcblk0/device/cid、正規化したバイト列はx86に入り、フィールド値ではそのバイト列をUTF-8のreplacementでデコードする。不正なUTF-8入力では、両者を相互に置き換えることはできない。publicSourceDirが個別に提供されない場合、現在の再構成ではsourceDirを使用する。/sys/ufs/ufsid以下のSettings値は、空でない文字列として読み取れた場合に対応するスロットへ書き込まれる。まず前後のASCII空白を取り除き、200バイトに切り詰めてから、UTF-8のreplacementでデコードする。キーの有無は正規化前の非空条件で判定するため、空白だけの入力から空文字列フィールドが生成されることがある。

Settings名

10. 各層を1つのリクエストに組み立てる

セッションのブートストラップが完了すると、1回のリクエストは次の順序で処理される。

最終的なmethod、path、query、bodyを確定する。

1. 今回のcounterを取り出し、セッション中のs、scalar、現在の端末プロファイルを使ってMUAを生成する。
2. 登録リクエストでは、同じslotAからdと最終bodyを生成してから、次の手順へ進む。
3. canonicalを組み立て、SIGとS1をそれぞれ計算する。S1には同じcounterと今回の秒単位の時刻を使う。
4. セッションの識別情報、common params、sceneなどのリクエストヘッダーを書き込む。
5. 最終的なpath、query、ホワイトリスト対象のヘッダー、bodyを使ってShieldを計算する。
6. 署名対象となった元のバイト列のままリクエストを送信する。
7. 最終的なpath、query、ホワイトリスト対象のヘッダー、bodyを使ってShieldを計算する。

ここでは、混同しやすい状態が3つある。MUAのセッション用ランダム素材、リクエストごとのcounter、そしてShieldのnonce4だ。これらはライフサイクルが異なり、互いに代用することもできない。

同じリクエストオブジェクトから、canonicalとShield sourceに必要なバイト列をそれぞれ取得できるようにする必要がある。HTTPライブラリが署名後にqueryの順序を変更したり、パーセントエンコーディングを変えたり、bodyを再シリアライズしたりすると、「ローカルの式は正しいのに、実際に送信した内容が一致しない」という問題が起こる。登録時は特に、最終的なbodyを先に生成してからSIGとS1を計算する必要がある。

10.1 SIG / S1を再計算できる入力例

以下は式を検証するための合成ベクトルで、MUAにはリテラル part1.part2.を使う。SIG/S1だけを切り分けるためのもので、サーバーに送信できる実際のMUAを示すものではない。

method    = GET
path      = /api/sns/v1/note/imagefeed
query     = note_id=example
body      = 空字节
mua       = part1.part2.
counter   = 2
timestamp = 1700000000

本文のLF連結規則に従ってcanonicalを組み立てると、結果は次のとおりだ。

SHA256(canonical) =
06fc306a81f499526239ed443e542e9a0f25df4625d7ca5a26020e8219cd697a

SIG =
7a78e9c4e104f6a7ffcc6e504d5fe6720f25df4625d7ca5a26020e8219cd697a

S1 lane32 =
390c3d289aa264822327b6ef0b47391162ebd4d38caa8da24eaa90dd4e9a9462

S1 raw62 =
000200000001a2b04bc749cdebd7dea41d703b71619b9b3b088e5cff71d06ee72b986dfd5736a04399afdf3836d7a3937736b3df1fad51852ee062ebcfea

S1 Base64 =
AAIAAAABorBLx0nN69fepB1wO3Fhm5s7CI5c/3HQbucrmG39VzagQ5mv3zg216OTdzaz3x+tUYUu4GLrz+o=

このベクトルを2つの実装で照合し、ビット順、counter、時間単位、エンコーディングを確認する。固定時刻での counter=2 の native 完全フレームについては別途照合済みであり、第4.4節を参照。

現在ある固定入力の照合結果は、本文の MUA エンコード、SIG、S1、main_hmac の復号、Shield の計算式を支持している。計算式の照合とは別に、純粋な Python クライアントで匿名セッションの一連の処理も検証済みだ。登録で GID を取得し、main_hmac と main_ssk を復号したうえで、homefeed、imagefeed、search/notes、user/info、user/posted はすべて code=0 を返し、複数の合成端末とセッションにまたがって確認できた。この検証で確認できるのは、リクエストヘッダーの構築と状態の引き継ぎがサーバーに受け入れられることだ。x137 の実機入力は、起動中の ART アドレスであると特定されている（第9.2節参照）。一方、まだ対象外なのは、実際の TEE attestation バイト列と、OEM ごとの取得分岐全体である。これらは結論の適用範囲を限定するものであり、サーバーから一度成功応答が返っただけで補えるものではない。

付録：SIGのアフィン行列

各行の129ビットを「列0から列128」の順に17バイトの上位129ビットへ格納し、下位7ビットは0で埋める。以下のhexは合計2176バイト、128行分である。レイアウト上、各テキスト行には行列の4行を含めている。

0000006b000000a1000000f41aa7488200000000d600000043000000e9344f900480000000ad00000087000000d3699e200a000000005a0000000f000000a7d23d401480
000000de000000be000000bbbfddc9a880000000d7000000dc00000083651ddbd000000000af000000b800000007cb3ab6a08000000035000000d0000000fa8dd324c080
000052c2000050580000948e724ad6de000000a4840000a0b10000281ce494adbc00000049090000416200005138c8285a788000009213000083c50000a2709151b5f280
000076e5000057d20000d16e50e8bc38800000be080000fefd00003752d29bafac0000007d110000fcfa00006fa4a5375e58000000a9e10000a8ac00004ac739256b6e80
005903f600b6dfcb67928b7da4d5840e0000b306ed006cbe97cf2416fb49ab091c8000660cdb00d87d2e9f482df69256133a0000cd19b600b0fb5d3f905bed24ac277400
00c2319a00d6297019b23ca6ec8dcae60000dd60c3001b8c2b55f6f3307dcf11c20000bac18600361857aaede761fb9f238400002c81fb00dbef65334945be52eac20680
2e83b6e02070089b2805fb342ddca9ea805d076cc040e01137510af6695bb852d680bb0ed88081c0236fa215edd2b771a4ae80771db001038046de452bdba56ee2495e00
c0b9d6e226718527a3524d7ff1183b5600aef01b246c9203d56fa161cbceecdf46805ce13648d82406abde43c3979dd9be8e809741db70903804cd94827d1a166ed4f480
0000c839000004bf525057d5373bf6f200000091720000087fa4a0aeab6f76ede480000022e4000011ff49415c56deecdbca00000044c8000023fe9283b9acbcd9b69480
000041a8000042437657248d4e899ad80000004b6900008138befe1fcfab29c34200000096d2000003707dfc3e9f56538684800000e49c0000025fa9a82bea9b9dfbf880
0000e80700007f41c7a6066322a26ad2000000d10e0000ff838e4d0cc74445d4a4800000a31d0000fe071c9a198e898ba94a800000473a0000fc0e3835321c1216529600
000067730000875cb7cd635b078fcefe00000027e1000070f8a93dc1d42cbcf72e0000004ec20000e0f0527a82a95979ef5c80000074830000bfa0635303319151b56880
0061cc240066d036e82b4c58155412588000c3994800cda16dd15798b12ba825b28000863390009b43daa3ae316257504a6600000d6720003787b4475c63c5aea094cc80
007a03640009df5e67928bd249153ac2000094caed00756e8b270f5afd877f66dc80002895db00eadc164e1fb5fa0fffcdba000030e69200b3681b741526ac0aaa892c00
4f7dffe1cd22b109585c8fcce37ac080809efbfec29b446213b1b91e99c6f58002803df6fc843789c52762733c338ceb0106007aedf8096f128a4ec5e6786718d7020c00
baa60ff21307a595d2907e03d3d5c498003a30e004ea2cfa23fd7c72ca44d148b0007461c008d559f446faf9e49589a3906000a7be7ff066915884acae47e6f13de04000
004972c159e314b3a0d85844c737f8de000092e482b3c6296641b0b1898e6ff0bc000024c805668c53cd836062121cdee178800048910acd18a69b07c1c52538bcc2f280
00d950d4c2d35984ae5ad20eb74e7c388000fbd268dd44a7bafc6dfd59a9ab01ac0000f6a5d0ba894f75f8dafab3525602580000a439602cf18a59506cac22639bfc6e80
00910f4e61cbf6b4a99b5dc62bf114300000221f9cc397ed685237bb8c57e329608000443e39862edbd0a46f7718aec653c28000897c720d5db6a149deee305c8ca68600
0083f6aa7a709af73b2780a792e9593c800096e21a942bc35bdfd55c890f22a74a00002cc434285786b7beabb9121f444f940000c887273065fbdad4cd2ee315788a1800
0026917e7f7a7f7fcc52e223de0bd9a880004c22fdfff5ffff99a4c446bc17b25200009844fafeebfefe3349888d792f64a400003189f4fcd7fcfc6792101af35fc94880
0045839787d587870376c31739b44a3a8000ad965070d17070cabe640cac634dde80005a2ca0e0a3e0e0957dc91958c79abe000093c83fbf3dbfbfe6a971116f85ecd400
743ecdc06bec892c6fddd951127d57b600e87c9b80d6d91259debab2a225fbae6c00d1f93701adb225b3bc7564454af65cd800a3f26f025a644a6679eac98b94edb9b000
33db13c4de251de19c084a473aa624d6001388ea48d7a6b3ee56cc4dde66301f1a802710d590af4d66ddac999abccd613e36003a1f66e03576449637eeec2889be2bda80
c751e0217a1dd8365c17560d304c03f4008ea2c042f53ab06db92fac1b619806e8801c458085eb7460da735f5836c3310cd280388b010bd7e8c1b4e6bfb16d866319a680
b747e236d5cc5a5e906834d73d8b31ba80a9de244cd1846d8b7cc73fa24a5a60828052bc4898a309da16f98e7e4594b5c10680632870103d0e6c1bae0bab86182681fa00
2ec92c906de01e859dd433f9fee74048005d935920dac03c0b3ba967f2fcce819000bb26b340b48078177652cfe5f89d032000774c66816801f12feca49fcaf03b064000
c051e193bde2fdda449d0c6c1f914cc880ae6beeb61624e43114ef2a21c0c5d8da805cd6dd6c2d48c86329df5542808ab0b6009764964836708f42ce6a997cfff3202400
5c68805b2d88b57c09115555c24ba8c400b9d001b75b106af91323aaaa849650880073a1026eb721d4f227465454092ca01000e64304dc6e42a9e54e8da8a81359412080
90ef88e3f10de7b6950b0505e5f82b86007cb7909dce937b1023065f5f08bbffc880f96e203b9d26f721460cbfbf1177fe9280aeb4c02d16c45a3e84082a2ae1a554e200
3cf10ea808ea48249e0228807d47ed4e0078e31d5011d590483d045101fb8fdb9c00f1c63aa023ab20907a08a202f61eb63880e38c744146564020f5114504ed3c6c7200
fae9e62b8546c9647521a388a63f35aa00c822c2ff0367dbed74406f903039861a00914484fe06cfb6dbe881de2061720d34001e780754047524924f0194c0bea3f62680

デコード方法は次のとおり。

def unpack_matrix(hex_text):
    raw = bytes.fromhex(hex_text)
    if len(raw) != 128 * 17:
        raise ValueError("expected 2176 bytes")
    rows = []
    for offset in range(0, len(raw), 17):
        value = int.from_bytes(raw[offset:offset + 17], "big") >> 7
        rows.append([(value >> bit) & 1 for bit in range(128, -1, -1)])
    return rows

ここでのビットのパッキング順は、行列を格納するためだけに使われる。rowsをデコードした後は、第3.2節の入力列のビット順に従って計算する必要があり、パッキング時の上位ビット優先をdigestからビットを取り出す順序と取り違えてはならない。

付録B：XXH3-128の完全な分岐

x86では、xxHash 0.8.3のseed付きXXH3-128を使用する。ここで展開するのは標準ハッシュの実装であり、このプロトコル固有なのはseed 0x48FA5412、入力の連結順序、そして末尾にCRC32を追加する規則である。

実装ではseedを符号なし64ビットに正規化する。整数はリトルエンディアンで読み込み、64×64の乗算では完全な128ビットの結果を保持する。折りたたむ場合は、積の上位64ビットと下位64ビットをXORする。加算、乗算、負数化後の切り捨ては、コード中のMASKに従う。

中程度の長さのmix16では (secret_low + seed) と (secret_high - seed) で2つの入力u64をマスクし、その積を折りたたんで64ビットにする。mix32ではlow/highを同時に更新し、もう一方の入力に含まれる2つのワードの合計を交差XORする。129～240バイト分岐の最終ウィンドウでは負のseedを使うため、位置と方向を前の完全なグループと入れ替えてはならない。

長い入力では、seedが0でない場合、まず192バイトのsecretを派生する。各16バイト単位について、前半のu64にはseedを加え、後半のu64からはseedを引く。各stripeは8系統に分け、元の値を隣接するアキュムレータに加え、マスクした値に含まれる2つのu32を乗算して現在のアキュムレータに加える。1024バイトの完全なブロックを処理した後にscrambleを行い、最後の64バイトのウィンドウは単独で処理する。このウィンドウは直前のウィンドウと重なってもよい。最終的には異なるsecretオフセットを使ってhighとlowを統合するため、独立した64ビットハッシュを2回実行するものではない。

以下のコードは、Pythonの標準機能だけで単独実行できる。xxHash 0.8.3をPythonに移植したもので、元のアルゴリズムの著作権はYann Colletに帰属し、BSD-2-Clauseライセンスを維持している。文末にライセンス全文を掲載する。

MASK = (1 << 64) - 1
P1 = 0x9E3779B185EBCA87
P2 = 0xC2B2AE3D27D4EB4F
P4 = 0x85EBCA77C2B2AE63
SECRET = bytes.fromhex("b8fe6c3923a44bbe7c01812cf721ad1cded46de9839097db7240a4a4b7b3671fcb79e64eccc0e578825ad07dccff7221b8084674f743248ee03590e6813a264c3c2852bb91c300cb88d0658b1b532ea371644897a20df94e3819ef46a9deacd8a8fa763fe39c343ff9dcbbc7c70b4f1d8a51e04bcdb45931c89f7ec9d9787364eac5ac8334d3ebc3c581a0fffa1363eb170ddd51b7f0da49d316552629d4689e2b16be587d47a1fc8ff8b8d17ad031ce45cb3a8f95160428afd7fbcabb4b407e")


def _read(b: bytes, pos: int) -> int:
    return int.from_bytes(b[pos:pos + 8], "little")


def _avalanche(x: int) -> int:
    x &= MASK
    x ^= x >> 37
    x = x * 0x165667919E3779F9 & MASK
    return x ^ (x >> 32)


def xxh3_128_medium(data: bytes, seed: int = 0) -> int:
    """Return high64<<64|low64, rejecting lengths outside 17..240."""
    n = len(data)
    if not 17 <= n <= 240:
        raise ValueError("medium XXH3-128 currently supports 17..240 bytes")
    seed &= MASK
    low, high = n * P1 & MASK, 0

    def mix16(pos: int, sec: int, seed: int) -> int:
        a = _read(data, pos) ^ ((_read(SECRET, sec) + seed) & MASK)
        b = _read(data, pos + 8) ^ ((_read(SECRET, sec + 8) - seed) & MASK)
        product = a * b
        return ((product & MASK) ^ (product >> 64))

    def mix32(a: int, b: int, sec: int, sd: int) -> None:
        nonlocal low, high
        low = ((low + mix16(a, sec, sd)) & MASK) ^ ((_read(data, b) + _read(data, b + 8)) & MASK)
        high = ((high + mix16(b, sec + 16, sd)) & MASK) ^ ((_read(data, a) + _read(data, a + 8)) & MASK)

    if n <= 128:
        for i in range((n - 1) // 32, -1, -1):
            mix32(16 * i, n - 16 * (i + 1), 32 * i, seed)
    else:
        for i in range(32, 160, 32):
            mix32(i - 32, i - 16, i - 32, seed)
        low, high = _avalanche(low), _avalanche(high)
        for i in range(160, n + 1, 32):
            mix32(i - 32, i - 16, 3 + i - 160, seed)
        mix32(n - 16, n - 32, 136 - 17 - 16, -seed & MASK)
    result_low = _avalanche(low + high)
    result_high = -_avalanche(low * P1 + high * P4 + (n - seed) * P2) & MASK
    return result_high << 64 | result_low


P3 = 0x165667B19E3779F9
P5 = 0x27D4EB2F165667C5
P32_1 = 0x9E3779B1
P32_2 = 0x85EBCA77
P32_3 = 0xC2B2AE3D


def _swap(x: int, size: int) -> int:
    return int.from_bytes(x.to_bytes(size, "little"), "big")


def _avalanche64(x: int) -> int:
    x &= MASK
    x = ((x ^ (x >> 33)) * P2) & MASK
    x = ((x ^ (x >> 29)) * P3) & MASK
    return x ^ (x >> 32)


def _short(data: bytes, seed: int) -> int:
    n = len(data)
    if n == 0:
        low = _avalanche64(seed ^ _read(SECRET, 64) ^ _read(SECRET, 72))
        high = _avalanche64(seed ^ _read(SECRET, 80) ^ _read(SECRET, 88))
    elif n < 4:
        combined = (data[0] << 16) | (data[n >> 1] << 24) | data[-1] | (n << 8)
        swapped = _swap(combined, 4)
        rotated = ((swapped << 13) | (swapped >> 19)) & 0xFFFFFFFF
        flip_l = (int.from_bytes(SECRET[:4], "little") ^ int.from_bytes(SECRET[4:8], "little")) + seed
        flip_h = (int.from_bytes(SECRET[8:12], "little") ^ int.from_bytes(SECRET[12:16], "little")) - seed
        low = _avalanche64(combined ^ (flip_l & MASK))
        high = _avalanche64(rotated ^ (flip_h & MASK))
    elif n <= 8:
        seed ^= _swap(seed & 0xFFFFFFFF, 4) << 32
        value = int.from_bytes(data[:4], "little") | (int.from_bytes(data[-4:], "little") << 32)
        flip = ((_read(SECRET, 16) ^ _read(SECRET, 24)) + seed) & MASK
        product = (value ^ flip) * (P1 + (n << 2))
        low, high = product & MASK, product >> 64
        high = (high + (low << 1)) & MASK
        low ^= high >> 3
        low = ((low ^ (low >> 35)) * 0x9FB21C651E98DF25) & MASK
        low ^= low >> 28
        high = _avalanche(high)
    else:
        flip_l = ((_read(SECRET, 32) ^ _read(SECRET, 40)) - seed) & MASK
        flip_h = ((_read(SECRET, 48) ^ _read(SECRET, 56)) + seed) & MASK
        head, tail = _read(data, 0), _read(data, n - 8)
        product = (head ^ tail ^ flip_l) * P1
        low, high = product & MASK, product >> 64
        low = (low + ((n - 1) << 54)) & MASK
        tail ^= flip_h
        high = (high + tail + (tail & 0xFFFFFFFF) * (P32_2 - 1)) & MASK
        low ^= _swap(high, 8)
        product = low * P2
        low = _avalanche(product & MASK)
        high = _avalanche((product >> 64) + high * P2)
    return (high << 64) | low


def _long(data: bytes, seed: int) -> int:
    if seed:
        parts = []
        for i in range(0, 192, 16):
            parts.append(((_read(SECRET, i) + seed) & MASK).to_bytes(8, "little"))
            parts.append(((_read(SECRET, i + 8) - seed) & MASK).to_bytes(8, "little"))
        secret = b"".join(parts)
    else:
        secret = SECRET
    acc = [P32_3, P1, P2, P3, P4, P32_2, P5, P32_1]

    def stripe(pos: int, sec: int) -> None:
        for lane in range(8):
            value = _read(data, pos + 8 * lane)
            keyed = value ^ _read(secret, sec + 8 * lane)
            acc[lane ^ 1] = (acc[lane ^ 1] + value) & MASK
            acc[lane] = (acc[lane] + (keyed & 0xFFFFFFFF) * (keyed >> 32)) & MASK

    n = len(data)
    blocks = (n - 1) // 1024
    for block in range(blocks):
        for j in range(16):
            stripe(block * 1024 + j * 64, j * 8)
        for lane in range(8):
            value = acc[lane]
            acc[lane] = ((value ^ (value >> 47) ^ _read(secret, 128 + lane * 8)) * P32_1) & MASK
    for j in range(((n - 1) - blocks * 1024) // 64):
        stripe(blocks * 1024 + j * 64, j * 8)
    stripe(n - 64, 121)

    def merge(sec: int, start: int) -> int:
        total = start
        for i in range(4):
            product = (acc[2*i] ^ _read(secret, sec+16*i)) * (acc[2*i+1] ^ _read(secret, sec+16*i+8))
            total += (product & MASK) ^ (product >> 64)
        return _avalanche(total)

    return merge(117, ~(n * P2)) << 64 | merge(11, n * P1)


def xxh3_128(data: bytes, seed: int = 0) -> int:
    """Return the unsigned 128-bit digest (high64 followed by low64).

    Seed is reduced modulo 2**64, as in the xxHash C API. This is a one-shot
    implementation, with no runtime dependency on xxhash/unidbg/native code.
    """
    if not isinstance(data, (bytes, bytearray, memoryview)):
        raise TypeError("data must be bytes-like")
    if type(seed) is not int:
        raise TypeError("seed must be an integer")
    data = bytes(data)
    seed &= MASK
    if len(data) <= 16:
        return _short(data, seed)
    if len(data) <= 240:
        return xxh3_128_medium(data, seed)
    return _long(data, seed)

戻り値は high64 << 64 | low64となる。x86を生成する際は、その整数を固定長32ビットの大文字hexにし、同じ入力から得た固定長8ビットの大文字CRC32を続けて連結する。

import zlib

def make_x86(data):
    return f"{xxh3_128(data, 0x48FA5412):032X}{zlib.crc32(data):08X}"

ライセンス：

Copyright (C) 2012-2023 Yann Collet

 BSD 2-Clause License (https://www.opensource.org/licenses/bsd-license.php)

 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are
 met:

    Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.
    Redistributions in binary form must reproduce the above
      copyright notice, this list of conditions and the following disclaimer
      in the documentation and/or other materials provided with the
      distribution.

 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 You can contact the author at:
   - xxHash homepage: https://www.xxhash.com
   - xxHash source repository: https://github.com/Cyan4973/xxHash