题目概述#

Cold Forge 审批节点提取到两个文件：

目标是恢复阈值私钥、重建发布签名，从而解封加密内容。

密码学原理#

1
z_i = r_i + c_i · λ_i · s_i  (mod n)

1
r_i = z_i − c_i·λ_i·s_i  (mod n)

1
r_i = bucket · 2^104 + low,   0 ≤ low < 2^104
2
bucket ∈ {nonce_msb − 1, nonce_msb, nonce_msb + 1}

1
z_i = r_i + a_i·s_i  (mod n)
2
r_i = b_i·2^104 + e_i,   e_i ∈ [-2^104, 2·2^104)
3

4
=>  t_i ≡ a_i·s_i + e_i  (mod n)

格攻击实现#

1
B[i,i]     = n·S           (i = 0..m-1)    // 非ce列
2
B[m,i]     = a_i·S         (i = 0..m-1)    // 秘密行
3
B[m+1,i]   = t_i·S         (i = 0..m-1)    // 目标行
4
B[m,m]     = 1
5
B[m+1,m+1] = M

1
s·row_m − Σ k_i·row_i − 1·row_{m+1}
2
= (S·e_0, ..., S·e_{m-1}, s, −M)

重建阈值私钥与签名#

1
x = λ₁·s₁ + λ₂·s₂ = 2·s₁ − s₂ = 2·s₁ + v₂  (mod n)

1
key        = SHA256(b'cold-forge/release/v1' + sig)
2
nonce      = base64_decode(sealed_release.nonce)
3
aad        = base64_decode(sealed_release.aad)
4
ciphertext = base64_decode(sealed_release.ciphertext)
5
plaintext  = ChaCha20Poly1305(key).decrypt(nonce, ciphertext, aad)

解题结果#

1
flag{bd9b026e-b58e-416c-bf8f-d815573c35a6}

参考实现要点#

• 语言：Python 3.9
• 依赖：fpylll（LLL）、gmpy2（模逆）、cryptography（ChaCha20-Poly1305）
• EC 运算与 BIP340 签名均手写实现，未依赖第三方曲线库

题目描述#

一个开发者实现了一个微型的 NTRU 加密方案，认为只要隐藏私钥就够了。 给定源代码、公钥和密文，要求恢复私钥多项式并解密 flag。

文件：

• challenge.py
• ntru.py
• public_key.txt
• output.txt

1. 分析方案#

参数（challenge.py 与 ntru.py）：

1
F = sample_sparse_ternary(N, df, rng, avoid_zero=True)   # F 有 7 个 ±1，位置 1..N-1
2
G = sample_sparse_ternary(N, dg, rng)                    # G 有 7 个 ±1
3
f = [0]*N; f[0] = 1
4
f = poly_add(f, [p*x for x in F], N)                     # f = 1 + 3F
5
g = [p*x for x in G]                                     # g = 3G
6
finv_q = poly_inv(f, N, q)                               # f 在模 q 下的逆
7
h = poly_mul(finv_q, g, N, q)                            # h = g * f^{-1} mod q

1
f * h ≡ g  (mod q)

1
a = center_lift(poly_mul(f, ciphertext, N, q), q)  # f*c mod q 中心化
2
m = [x % p for x in a]                              # 再模 3 得到明文三进制系数

2. 漏洞：私钥太短，可被格归约恢复#

关键点：虽然 q 有 12289，但私钥 f = 1 + 3F 与 g = 3G 的系数非常小：

• f 的范数 ≈ sqrt(1 + 7*9) = 8
• g 的范数 ≈ sqrt(7*9) ≈ 7.9
• 整体 (f, g) 的范数 ≈ sqrt(127) ≈ 11.3

而 (f, g) 满足 f*h ≡ g (mod q)，等价于存在整数多项式 k 使：

1
f*h - g = q*k

所有满足 g ≡ f*h (mod q) 的 (f, g) 构成一个 2N = 254 维格，其最短向量就是真正的短私钥。这就是经典的 NTRU 密钥恢复格攻击（Coppersmith–Shamir）。

3. 构造格并做 BKZ 归约#

构造 2N × 2N 的整数格基矩阵 M：

1
M = [ I      H ]
2
    [ 0     qI ]

其中 I 是 N×N 单位阵，H 是乘 h 的循环矩阵：

1
H[i][k] = h[(k - i) mod N]     # 第 i 行的 g 部分 = x^i * h

这样，对任意系数向量 a，向量

1
(a, a*h mod q 的整数代表)

都在该格中。真正的 (f, g) 是该格中极短的向量。

用 Python 的 fpylll 做 LLL 预归约 + BKZ（块大小 15 即可）：

1
from fpylll import IntegerMatrix, LLL, BKZ
2

3
N, q = 127, 12289
4
h = ast.literal_eval(...)   # 从 public_key.txt 读取
5

6
dim = 2*N
7
M = [[0]*dim for _ in range(dim)]
8
for i in range(N):
9
    M[i][i] = 1
10
    for k in range(N):
11
        M[i][N+k] = h[(k-i) % N]
12
for i in range(N):
13
    M[N+i][N+i] = q
14

15
A = IntegerMatrix.from_matrix(M)
16
BKZ.reduction(A, BKZ.Param(block_size=15))

归约后，扫描每个基向量，找到 g 部分（后 N 个坐标）中心化后系数只在 {0, ±3} 且恰好 7 个非零的向量，即为恢复出的 (f, g)（可能存在整体符号与循环移位）。

4. 恢复私钥#

BKZ 返回的基向量（整体取负、循环移位后的形式）为：

• f 的非零项：27: +3, 46: -1, 61: -3, 74: -3, 95: -3, 102: +3, 108: +3, 110: -3

其中 -1 对应 f 常数项 1 取负并移位到位置 46。先整体取负，再循环移位 46 位，使常数项回到位置 0，得到：

1
f = 1 + 3x^15 + 3x^28 + 3x^49 - 3x^56 - 3x^62 + 3x^64 - 3x^108

即 F 的非零系数（三进制）为：

1
F[15]=1, F[28]=1, F[49]=1, F[56]=-1, F[62]=-1, F[64]=1, F[108]=-1

验证 f * h mod q 中心化后系数全部落在 {0, ±3}，且恰好 7 个非零，确认恢复正确。

5. 解密#

对每个密文块：

1
a = center_lift(poly_mul(f, c, N, q), q)
2
m = [x % p for x in a]

再把得到的各三进制块用 poly_blocks_to_bytes 重组为字节串，得到 flag。

6. 结果#

1
flag{27dec48f-f9c7-4bad-9a1b-f7aa77badc5f}

关键代码#

完整求解脚本 solve5.py + final.py：

1
# 1) 构造格
2
N, q = 127, 12289
3
dim = 2*N
4
M = [[0]*dim for _ in range(dim)]
5
for i in range(N):
6
    M[i][i] = 1
7
    for k in range(N):
8
        M[i][N+k] = h[(k-i) % N]
9
for i in range(N):
10
    M[N+i][N+i] = q
11

12
# 2) BKZ 归约并找短向量
13
A = IntegerMatrix.from_matrix(M)
14
BKZ.reduction(A, BKZ.Param(block_size=15))
15

16
def center(x):
17
    x %= q
18
    return x if x <= q//2 else x - q
19

20
for i in range(dim):
21
    f = [A[i][j] for j in range(N)]
22
    g = [A[i][N+j] for j in range(N)]
23
    cg = [center(x) for x in g]
24
    nz = [x for x in cg if x != 0]
25
    if all(x in (3, -3) for x in nz) and len(nz) == 7:
26
        # 找到 (f, g)，处理符号与移位后得到 f
27
        break
28

29
# 3) 解密
30
msgs = []
31
for c in ciphertexts:
32
    a = center_lift(poly_mul(f, c, N, q), q)
33
    msgs.append([x % 3 for x in a])
34
flag = poly_blocks_to_bytes(msgs, 24)
35
print(flag)

0. 题目概述#

工业边缘控制面的远程证明验证器 attestjit 在一次崩溃后只留下了：

目标：还原受保护的发布材料（flag）。

1. 解析 Core 文件#

attestjit.core 是 ET_CORE，包含一个 PT_NOTE 和一个 PT_LOAD：

• PT_LOAD：vaddr = 0x7fe82ec2e000，filesz = 0x1000 —— 即 RX JIT 缓存页。
• PT_NOTE：名字 ATJIT，desc 为 16 字节：

1
80 e1 c2 2e e8 7f 00 00   -> 策略入口地址 0x7fe82ec2e180
2
02 00 00 00 00 00 00 00   -> 版本号 2

于是知道策略函数入口在页内偏移 0x180。把整页 dump 出来用 Capstone 反汇编（base = 0x7fe82ec2e000）。

2. 反汇编 JIT 策略#

策略函数 int policy(void *rdi) 的 rdi 指向一个 0x111 字节的 binding 缓冲区，逻辑分三段：

1
r8  = [0x18] ^ [0x40] ^ [0x58]          = digest[0:8] ^ measurement[8:16] ^ nonce[0:8]
2
r9  = [0x28] + [0x90] + [0x109]         = digest[16:24] + claim268[8:16] + ev_nonce[0:8]
3
r10 = [0xb0] ^ [0xd9] ^ [0x50]          = claim256[8:16] ^ bootseed[16:24] ^ measurement[24:32]
4
r11 = [0xf1] + [0xa0] + [0x08]          = const[8:16] + claim268[24:32] + realm[0:8]

1
r8  = rol(r8 + r9 + K1, R1) ^ r11
2
r9  = ror(r9 ^ r10, R2) + K2
3
r10 = rol(r10 + r11 + K3, R3) ^ r8
4
r11 = ror(r11 ^ r8, R4) + K4

1
r8  == [0x68]  (policy binding[0:8])
2
r9  == [0x70]  (policy binding[8:16])
3
r10 == [0x78]  (policy binding[16:24])
4
r11 == [0x80]  (policy binding[24:32])

3. 解析 evidence.cose#

COSE_Sign1：d2 84 [protected, {}, payload(256B), signature(64B)]，alg=-7 (ES256)，kid=7cec207e6c6d6b7a。

payload 是 PSA token（map），关键 claim：

evidence digest = SHA256(payload) = ea0f4ace7ce4479fcb46d269f4bc5043f7b4de3ddbbae7c074bbf1cdf577c414（与负例请求 label 4 一致）。

4. 反汇编主程序（attestjit）#

关键数据流：

1. 读取 evidence.cose、iak_pub.pem、release_blob.bin 三个文件。
2. 解析请求 CBOR（label 1–5 = realm / nonce / policy-binding / evidence-digest / capability），其中 realm、capability 用 memcmp 与固定字符串比较，其余字段拷贝到 [rsp+0xf0..0x14f]。
3. 校验 evidence 签名（重建 Signature1 Sig_structure → SHA-256 → ECDSA_verify），并解析 PSA claim，存入 [rsp+0x1d0..0x268]。
4. 组装 binding 缓冲区 [rsp+0x270..0x390]：
   • [0x270] = 12288、[0x278] = realm、[0x288] = SHA256(payload)、[0x2a8] = measurement、[0x2c8] = nonce、[0x2d8] = policy binding、[0x2f8] = claim268、[0x318] = claim256、[0x339] = bootseed、[0x379] = ev_nonce。
5. mmap 一块页 → 把 JIT 策略编进去 → mprotect 为 RX → call policy(r15)，r15 = [rsp+0x270]。
6. 策略返回 1 才继续做 AES-GCM 解密。

1
key  = SHA256("ATJIT-release-key-v2\0"
2
              + evidence_digest + policy_binding + nonce + measurement + realm)   # 21 + 128 = 149 B

1
iv   = release_blob[8:20]
2
ct   = release_blob[22:64]   (长度字段在 [20:22]，大端 0x002a = 42)
3
tag  = release_blob[64:80]
4
aad  = "ATJIT/PSA/release-v2\0" + evidence_digest + realm   # 69 B

5. 计算 policy binding 并解密#

用 Python 还原混合函数，得到正确的 policy binding：

1
fd83cb3fb691fd79b1ad3e141ae2f10183fafe06bf4bbf0e3642b5a10e770fe1

（负例 negative_request.cbor 的 binding 首字节是 7d，即把 fd 的最高位清零，刻意制造非法。）

随后计算 AES key 并 AES-256-GCM 解密 release_blob.bin：

1
flag{f9f6752c-2a8e-45f3-aecb-cd8c12051627}

6. 正确请求（正例）#

positive_request.cbor（128 字节）：

1
a5
2
01 6f 70726f642e72656c656173652f7632        # realm = prod.release/v2
3
02 50 324f42326306a94d451e63f026384559        # nonce
4
03 58 20 fd83cb3fb691fd79b1ad3e141ae2f101
5
           83fafe06bf4bbf0e3642b5a10e770fe1    # policy binding（已修正）
6
04 58 20 ea0f4ace7ce4479fcb46d269f4bc5043
7
           f7b4de3ddbbae7c074bbf1cdf577c414    # evidence digest
8
05 74 6669726d776172652d6b65792d72656c65617365

在 Linux 环境运行 ./attestjit positive_request.cbor 应输出 attestation accepted 并打印解密后的发布材料。

附：可复现脚本要点#

• 从 Core 提取 RX 页：page = core[0x1000:0x2000]，入口 0x180。
• Capstone 反汇编：Cs(CS_ARCH_X86, CS_MODE_64)，base = 0x7fe82ec2e000。
• 提取 cmp rax,[rdi+off] / cmp rax,[rip+X] 的配对，用 struct.unpack('<Q') 从页内取常量。
• 混合函数轮常量按内存序取 .rodata 0x404380 的 32 个 qword，旋转量从 rol/ror 立即数读取。
• AES 用 cryptography 的 AESGCM 库即可完成解密。

1. 题目信息#

• APK 文件：pixel_oracle.apk
• 包名：com.ddl4.easy
• 说明：flag 不是明文存储，验证器依次检查 move 路线长度、棋盘边界规则、FNV-1a 路径哈希、score 重放、native 门、以及基于 xorshift32 的加密字节数组。

2. 解包与静态分析#

使用 apktool 反编译：

1
unzip pixel_oracle.apk -d extracted
2
apktool d -f -o decoded pixel_oracle.apk

关键文件：

• classes.dex：主逻辑（com/ddl4/easy/MainActivity、com/ddl4/easy/K）
• lib/x86_64/libpixgate.so：native 门（Java_com_ddl4_easy_MainActivity_ng）

3. 关键常量（MainActivity）#

棋盘（5×5，BOARD[y][x]）：

1
row0: 23 41 17 5b 2d
2
row1: 09 72 4e 31 66
3
row2: 58 0d 39 7c 20
4
row3: 44 6f 12 55 2a
5
row4: 33 18 6a 07 4d

初始状态：x=0, y=4, score=0x5157。

4. 解题过程#

1
score = (score * 0x83) ^ (BOARD[y][x] + (i+7) * move)
2
score &= 0x7fffffff

1
UURRDRURDDL

1
ng(a, b) = xs32(a ^ rotl32(b, 5) ^ 0x6f726163) ^ 0x42b0c0de

1
nativeGate = 0x4dbcda7a   （与 EXPECTED_NATIVE_GATE 一致）

1
seed = nativeGate ^ score ^ pathHash ^ 0x9e3779b9
2
     = 0x59ef578d

1
def xs32(x):
2
    x ^= (x << 13) & 0xffffffff
3
    x ^= (x >> 17)
4
    x ^= (x << 5)  & 0xffffffff
5
    return x & 0xffffffff
6

7
p = seed
8
flag = ''
9
for i in range(27):
10
    p = xs32(p)
11
    flag += chr(ENC[i] ^ (p & 0xff) ^ ((i * 0x11 + 0x3d) & 0xff))

5. Flag#

1
flag{pix_oracle_moves_5279}

6. 完整求解脚本#

1
ENC = [0x19,0x81,0x41,0xd6,0xc5,0x9b,0x81,0x5b,0x78,0xc0,0xfd,0x74,
2
       0x13,0x5a,0x1c,0x38,0x11,0xd3,0x7a,0x97,0xa7,0x2f,0x6b,0xcc,
3
       0xb8,0xd4,0x72]
4

5
def xs32(x):
6
    x &= 0xffffffff
7
    x ^= (x << 13) & 0xffffffff
8
    x &= 0xffffffff
9
    x ^= (x >> 17) & 0xffffffff
10
    x &= 0xffffffff
11
    x ^= (x << 5) & 0xffffffff
12
    return x & 0xffffffff
13

14
def rotl32(x, n):
15
    x &= 0xffffffff
16
    return ((x << n) | (x >> (32 - n))) & 0xffffffff
17

18
def djb2(s):
19
    h = 0x1505
20
    for c in s:
21
        h = (((h << 5) + h) ^ ord(c)) & 0xffffffff
22
    return h
23

24
pathHash = 0xb97de93a
25
score    = 0x33191d74
26

27
ng = xs32(pathHash ^ rotl32(score, 5) ^ 0x6f726163) ^ 0x42b0c0de
28
seed = (ng ^ score ^ pathHash ^ 0x9e3779b9) & 0xffffffff
29

30
p = seed
31
flag = ''
32
for i in range(27):
33
    p = xs32(p)
34
    flag += chr(ENC[i] ^ (p & 0xff) ^ ((i * 0x11 + 0x3d) & 0xff))
35

36
print(flag)                       # flag{pix_oracle_moves_5279}
37
print(hex(djb2(flag)))            # 0x27a50d6c

0. 先看清题目长什么样#

APK 只有 17 KB，结构极其干净：

1
rift_runner.apk
2
├── AndroidManifest.xml
3
├── classes.dex              # 全部 Java 逻辑
4
├── lib/x86/librtrack.so     # 1472 字节
5
├── lib/x86_64/librtrack.so  # 2192 字节
6
└── resources.arsc

包名 com.ddl4.medium，入口 MainActivity，只有一个 native 导出函数 Java_com_ddl4_medium_MainActivity_mx。

用到的工具：

1
unzip -o rift_runner.apk -d apk_raw     # 拿原始 .so
2
apktool d -f rift_runner.apk -o apktool_out   # 拿 smali
3
objdump -d -M intel lib/x86/librtrack.so --section=.text

没有 jadx 也没关系，这题 smali 量很小（主类 1778 行），直接硬读完全可行。

1. 静态字段里先把常量抄下来#

MainActivity.smali 开头就挂着一张”答案表”，这基本等于出题人把考点列给你了：

2. 第一层：LCG 字符串解密器 S.d()#

S.smali 是个很短的解密函数，还原成 Java 就是这样：

1
static String d(int[] data, int seed) {
2
    char[] out = new char[data.length];
3
    for (int i = 0; i < data.length; i++) {
4
        seed = seed * 0x41c64e6d + 0x3039;          // glibc 经典 LCG，int 溢出
5
        int v = data[i];
6
        v ^= (seed >>> 16) & 0xff;                   // 注意是 >>> 无符号右移
7
        v ^= (i * 13) & 0xff;                        // 位置相关的第二层掩码
8
        out[i] = (char) v;
9
    }
10
    return new String(out);
11
}

实现要点（新手最容易踩的坑）：seed >>> 16 是无符号右移。Java 的 int 是带符号的，但 >>> 不补符号位。在 Python 里必须先 & 0xFFFFFFFF 再移位，否则 seed 为负数时会算错。

怎么确认自己写对了？找已知明文验证 —— 代码里有两处：

这两个能解出来，说明你的 LCG 实现是对的。做题时一定要先做这一步自测，不然后面全是白搭。

3. 第二层：反汇编 native 库#

librtrack.so 小到只有两个函数：rotl32 和 mx。x86 和 x86_64 两份汇编逻辑完全一致，任选一份看即可。

x86 关键片段：

1
mov  dword ptr [esp], eax        ; eax = 参数 b
2
mov  dword ptr [esp + 4], 0x9    ; 9
3
call rotl32                      ; rotl32(b, 9)
4
...
5
xor  ecx, eax                    ; ^= rotl32(b,9)
6
shl  eax, 0x10                   ; c << 16
7
xor  ecx, eax
8
xor  ecx, dword ptr [ebp+0x1c]   ; ^= d
9
xor  ecx, 0x72696674             ; ^= "rift"  ← 出题人埋的彩蛋
10
...
11
shr  ecx, 0xf ; xor  ; imul 0x45d9f3b      ; h ^= h>>15;  h *= 0x45d9f3b
12
shr  eax, 0xd ; xor                         ; h ^= h>>13
13
xor  eax, 0x9e3779b9                        ; ^= 黄金分割常数

还原出来：

1
int32 mx(int32 a, int32 b, int32 c, int32 d) {
2
    uint32 h = a ^ rotl32(b, 9) ^ ((uint32)c << 16) ^ d ^ 0x72696674;
3
    h ^= h >> 15;
4
    h *= 0x45d9f3b;
5
    h ^= h >> 13;
6
    h ^= 0x9e3779b9;      // 0x9e3779b9 = 黄金分割数，TEA 系列的标志性常数
7
    return h;
8
}

那个 0x72696674 按字节倒过来就是 t f i r → rift，是出题人留的签名，看到它基本能确认你没读错架构。

调用点是 nativeGate(hash, score, energy, routeLen)，返回值必须等于 0x135ce483。

4. 第三层：verify() 的完整校验链#

1
private int verify(String route, String flag, int p3) {
2
    route = route.trim().toUpperCase(US);          // 只认 U/D/L/R
3
    if (route.length() == 0 || route.length() >= 0x78) return 0;
4
    if ((p3 ^ 0x5a) != route.length()) return 0;   // 长度二次校验
5

6
    ReplayResult r = replay(route);                 // 走迷宫
7
    if (!r.ok) return 0;
8

9
    if (r.hash   != 0x5db04953) return 0;           // ① 路径哈希
10
    if (r.score  != 0xb134e765) return 0;           // ② 路径评分
11
    if (r.energy != 29)         return 0;           // ③ 能量
12
    if (route.length() != 47)   return 0;           // ④ 长度
13

14
    int gate = nativeGate(r.hash, r.score, r.energy, route.length());
15
    if (gate != 0x135ce483) return 0;               // ⑤ native 校验
16

17
    if (flag.length() != ENC.length) return 0;      // ⑥ flag 格式
18
    if (flag.charAt(0) != 'f') return 0;
19
    if (flag.charAt(4) != '{') return 0;
20
    if (flag.charAt(flag.length()-1) != '}') return 0;
21

22
    int[] s = {                                     // ⑦ xorshift128 种子
23
        r.hash ^ 0x243f6a88,
24
        r.score ^ 0x85a308d3,
25
        (route.length() ^ (r.energy << 24)) ^ 0x13198a2e,
26
        0x03707344 ^ gate
27
    };
28
    for (int i = 0; i < flag.length(); i++) {
29
        int k = xs128(s) & 0xff;
30
        int t = (k ^ flag.charAt(i) ^ ((i*0x49 + 0xa5) & 0xff)) & 0xff;
31
        if (t != ENC[i]) return 0;
32
    }
33
    return 1;                                       // "finish line"
34
}

xs128() 就是标准 xorshift128（原地更新 4 个状态字），位移量 <<11 / >>>19 / >>>8：

1
static int xs128(int[] s) {
2
    int v1 = s[0] ^ (s[0] << 11);
3
    s[0] = s[1]; s[1] = s[2]; s[2] = s[3];
4
    int v0 = s[3];
5
    v0 ^= v0 >>> 19;
6
    v0 ^= v1;
7
    v0 ^= v1 >>> 8;
8
    s[3] = v0;
9
    return s[3];
10
}

1
static boolean opaque(int x) { return ((x*x + x) & 1) != 0; }

5. 突破口：密钥流跟迷宫无关#

这是整题最关键的一步观察。看第 ⑦ 步的种子构造：

1
s[0] = hash   ^ 0x243f6a88        ← hash   已被断言 == 0x5db04953
2
s[1] = score  ^ 0x85a308d3        ← score  已被断言 == 0xb134e765
3
s[2] = len    ^ (energy << 24) ^ 0x13198a2e   ← len=47, energy=29，全是常量
4
s[3] = 0x03707344 ^ gate          ← gate   已被断言 == 0x135ce483

四个输入全部是被前面断言死掉的常量，没有一项依赖迷宫的具体走法。

换句话说：即便你完全不知道那条 47 步的路径长什么样，只要这些断言成立（它们必然成立，否则程序走到不了这一步），种子就是确定的：

1
s = [0x798f23db, 0x3497efb6, 0x0e198a01, 0x102c97c7]

于是直接反解 flag：

1
flag[i] = ENC[i] ^ (xs128_next() & 0xff) ^ ((i * 73 + 165) & 0xff)

通用套路：看到”用校验过程中的中间值当密钥”，先问一句——这些中间值是不是已经被前面的 if 断言成常量了？如果是，整条动态校验链就可以静态短路掉。

6. 解密脚本#

1
M32 = 0xFFFFFFFF
2
def u32(x): return x & M32
3
def rotl32(x, n):
4
    x = u32(x); n &= 31
5
    return u32((x << n) | (x >> (32 - n)))
6

7
def mx(a, b, c, d):                       # 还原自 librtrack.so
8
    h = u32(u32(a) ^ rotl32(b, 9) ^ u32(c << 16) ^ u32(d) ^ 0x72696674)
9
    h = u32(h ^ (h >> 15)); h = u32(h * 0x45d9f3b)
10
    h = u32(h ^ (h >> 13)); return u32(h ^ 0x9e3779b9)
11

12
def xs128(s):                             # 原地更新
13
    v1 = u32(s[0] ^ u32(s[0] << 11))
14
    s[0], s[1], s[2] = s[1], s[2], s[3]
15
    v0 = u32(s[3]); v0 = u32(v0 ^ (v0 >> 19))
16
    v0 = u32(v0 ^ v1); v0 = u32(v0 ^ (v1 >> 8))
17
    s[3] = v0; return s[3]
18

19
HASH, SCORE, ENERGY, LEN, GATE = 0x5db04953, 0xb134e765, 29, 47, 0x135ce483
20

21
assert mx(HASH, SCORE, ENERGY, LEN) == GATE      # 交叉验证 native 还原是否正确！
22

23
s = [u32(HASH ^ 0x243f6a88),
24
     u32(SCORE ^ 0x85a308d3),
25
     u32(u32(LEN ^ u32(ENERGY << 24)) ^ 0x13198a2e),
26
     u32(0x03707344 ^ GATE)]
27

28
flag = bytes(ENC[i] ^ (xs128(s) & 0xff) ^ ((i * 0x49 + 0xa5) & 0xff)
29
             for i in range(len(ENC))).decode()
30
# -> flag{rift_runner_native_path_8613}

7. 顺带记录：迷宫其实是个死路#

出于完整性，我把迷宫也查了一遍，结论是它在当前 APK 里根本解不开：

• 地图是 <init> 里 121 个 int 经 S.d(data, 0x2b) 解密得来的 11×11 网格（121 = 11×11，对得上）。
• 但用种子 0x2b 解出来是乱码；我核对了 DEX 原始字节（fill-array-data 载荷在 offset 0x1850），数据与 apktool 输出完全一致，排除了工具解析问题。
• LCG 输出只取 bits 16–23，因此密钥流只依赖种子的低 24 位 —— 也就是说枚举 2^24 个种子就等价于枚举了全部 2^32 空间，这是完备的。
• C 程序全量枚举结果：最好的种子也只能让 121 字节里 75 个可打印（纯噪声水平，随机期望约 45）。不存在能解出 ASCII 网格的种子。

所以 replay() 这条运行时路径是走不通的。结合 flag 内容里的 native_path，可以确定出题人的意图就是让你走 native 常量静态还原这条路，迷宫只是叙事包装。

顺带一提，guard() 里的反调试遥测（检查 TracerPid、test-keys 指纹、包名）在干净设备上返回 0，同样不影响密钥流。

8. 复盘：这题值得记住的点#

1. 先把静态常量表抄下来。 出题人常常把答案直接摆在 .field 里，这是性价比最高的一步。
2. 写解密函数前先找已知明文自测。 本题有 rtrack 和 com.ddl4.medium 两个天然测试用例，不验证就往下走很容易白干。
3. Java 的 >>> 是无符号右移，用 Python 复现时务必先 & 0xFFFFFFFF。
4. 对流密码题，先确认密钥是否依赖动态输入。 本题密钥完全由被断言死的常量构成，直接静态短路，绕开了整个迷宫。
5. 警惕恒真/恒假的”假检查”。 opaque() 里 x(x+1) 恒为偶数，整个判断是摆设。
6. 用交叉验证给自己兜底。 native 函数还原得对不对，用 mx(...) == EXPECTED_NATIVE_GATE 一验便知，比”解出来像人话”可靠得多。
7. 善用数学性质缩小爆破空间。 LCG 只输出 bits 16–23 → 只需枚举 2^24 而非 2^32，把不可行变成秒级可行。

0. 题目给了什么#

目录里有 5 个原始文件（+ 我后来加的 2 个）：

核心参数：

1
p       = 1488956407306536737472865018058180519339      # 131-bit
2
order   = p + 1 = 1488956407306536737472865018058180519340
3
q       = 387192404707928581                            # 大素数，私钥 d 的取值范围
4
cofactor= order / q = 3845520700308425278140
5
SMALL_FACTORS = [4, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59]

验算一下：

1
4*3*5*7*11*13*17*19*23*29*31*37*41*43*47*53*59 = 3845520700308425278140   # 正好等于 cofactor

也就是说：d ∈ [1, q)，且 q ≪ cofactor，所以一旦能把 d mod 每一个小因子 都拿到，CRT 就能把 d 唯一确定下来。

顺便说一句：order = p + 1 这种曲线其实是”异常曲线”，理论上还可以用 Smart’s Attack 一发秒；但本题的设计让你”必须”用 16 次 oracle，所以失效曲线攻击（invalid curve attack）才是出题人想考的点。

1. ECDH 怎么工作（极简版）#

1. 服务端挑一个私钥 d（题目里 d ∈ [1, q)，随机均匀）。
2. 服务端有公钥 Q_pub = d · G，但这次题目没让你看到 Q_pub。题目只给了另一个固定点 B_pub = (PEER_X, PEER_Y)，那是给 flag 加密用的对端公钥，不是 ECDH 的对端。
3. 你作为客户端挑自己的私钥 e，发公钥 e · G 过去。
4. 服务端算 shared = d · (e · G) = (d·e) · G。
5. 两边都拿 shared.x ‖ shared.y 当材料，派生出 AES 密钥通信。

ECDHE 安全的核心前提是：曲线本身是安全的 + 对方发来的点一定在曲线上。

本题的 bug 就藏在第 2 条——服务端从来不验证发过来的点是不是真的落在曲线上。

2. 漏洞到底在哪#

看 server.py 的 Oracle.query：

1
def query(self, x, y):
2
    if self.used >= self.max_queries:
3
        raise InvalidPoint("query limit exceeded")
4
    if not (0 <= x < params.P and 0 <= y < params.P):
5
        raise InvalidPoint("coordinate out of range")
6

7
    self.used += 1
8
    peer = Point(x, y)
9

10
    # Vulnerability: the implementation never calls self.curve.is_on_curve(peer).
11
    shared = self.curve.mul(self.secret_d, peer)
12
    key = derive_key(shared)
13
    iv = get_random_bytes(16)
14
    ct = AES.new(key, AES.MODE_CBC, iv).encrypt(pad(params.KNOWN_PLAINTEXT, 16))
15
    return OracleResponse(iv, ct)

注意注释那句 # Vulnerability: the implementation never calls self.curve.is_on_curve(peer).

服务端只检查了坐标在 [0, p) 范围内，就直接拿去做 mul(d, peer)。这意味着：

我随便挑一条别的曲线 y^2 = x^3 + c' (mod p)（c’ ≠ 7），从上面挑一个点发过去，服务端会照算不误。

3. 攻击思路（核心）#

关键观察：对于一个阶 ℓ（很小）的点 P，d · P 的可能取值只有 ℓ 个（P, 2P, 3P, …, ℓP = O）。

而且 derive_key 和 AES-CBC 是确定性的：

1
key  = SHA256( (d·P).x ‖ (d·P).y )   # 确定性
2
ct   = AES-CBC(key, iv, pad(KNOWN_PLAINTEXT, 16))   # iv 已知、ct 已知

所以暴力枚举 k = 1 … ℓ，算 k·P，用对应的 key 解 ct，看解出来是不是 KNOWN_PLAINTEXT：

• 是 ⇒ k ≡ d (mod ℓ)，我们得到了 d mod ℓ 的一个信息。
• 否 ⇒ 换一个 k 继续试。

把 ℓ 在 {12, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59}（共 16 个，恰好 = max_queries）上各做一次，再 CRT 一合并，得到的就是 d mod cofactor。因为 d < q ≪ cofactor，所以恢复出的就是真实私钥 d。

拿到 d 之后：

1
shared  = d · B_pub
2
key     = SHA256(shared.x ‖ shared.y)
3
flag    = AES-CBC-decrypt(key, flag_iv, flag_ct)

4. 怎么找”阶为 ℓ 的点”#

服务器不验证你发的点是否在曲线上，但它用的还是同一条加法公式——这条加法公式对任何曲线 y^2 = x^3 + 7 + Δ (mod p) 都成立（因为加法公式只用了 a = 0，没用到 b 的具体值）。

所以我们其实不需要”换曲线”——我们仍然在曲线上找点，只是把”群阶”换成了”某个小素数的倍数”。

params.ORDER = p + 1 是真实曲线 y^2 = x^3 + 7 (mod p) 的群阶，群里的每个点的阶都整除 ORDER。

所以策略是：

1. 随机猜一个 x，算 y² = x³ + 7 (mod p) 的一个平方根 y，得到曲线上的点 R。
2. 把它乘 m = ORDER // ℓ：得到 P = m·R。如果 ℓ 整除 R 的阶，P 就有阶 ℓ；否则 P 是 O。
3. 检查 ℓ · P == O 且对 ℓ 的任何真因子 d 都有 d · P ≠ O，那就是精确阶 ℓ。

ecc.py 里 sqrt_mod_p_3_mod_4 假设 p ≡ 3 (mod 4) 才能用快速公式。p = 1488956407306536737472865018058180519339，末位是 9，9 ≡ 1 (mod 4)，所以这个函数其实并不总是返回正确的平方根。但我们的暴力枚举会很快碰到一个 x 让它恰好算对；况且就算 y 不在曲线上，加法公式也照样返回”看起来合理”的点，最后被服务端拒绝的话只会让那一次查询失败。所以实际跑起来完全没问题（脚本里暴力范围设的是 1 … 2^20）。

5. CRT 把小块拼起来#

标准 CRT：

1
已知:  d ≡ r1 (mod m1)
2
       d ≡ r2 (mod m2)
3
       …
4
       d ≡ rk (mod mk)
5
所有 mi 两两互素 ⇒ x = Σ ri · Mi · (Mi^-1 mod mi)  (mod M)   其中 M = Π mi

我们这一步的产物是 d mod cofactor，因为 d < q ≪ cofactor，所以这就是 d。

6. 关键代码走读#

我整合后的 attack.py（去掉全部冗余打印后就是下面这段）：

1
def find_point_exact_order(ell):
2
    m = ORDER // ell
3
    for x in range(1, 1 << 20):
4
        rhs = (pow(x, 3, P) + 7) % P
5
        y = sqrt_mod_p_3_mod_4(rhs, P)
6
        if y is None: continue
7
        R = Point(x, y)
8
        scaled = curve.mul(m, R)        # 阶为 ell 的候选
9
        if scaled.is_infinity(): continue
10
        if not curve.mul(ell, scaled).is_infinity(): continue
11
        ok = all(
12
            curve.mul(d, scaled).is_infinity() is False
13
            for d in range(2, ell) if ell % d == 0
14
        )
15
        if ok: return scaled
16
    raise RuntimeError(...)

1
def recover_residue(ell, pt, oracle):
2
    resp = oracle.query(pt.x, pt.y)   # 真实攻击点
3
    if resp is None:                  # 服务端发现 d·P=O，丢"invalid"
4
        return 0                      # d ≡ 0 (mod ℓ)
5
    iv, ct = resp
6
    target = pad(KNOWN, 16)
7
    for k in range(1, ell):
8
        cand = curve.mul(k, pt)       # 尝试 k = 1, 2, ..., ℓ-1
9
        if cand.is_infinity(): continue
10
        key = derive_key(cand)
11
        if AES.new(key, AES.MODE_CBC, iv).decrypt(ct) == target:
12
            return k
13
    raise RuntimeError(...)

1
def attack(oracle):
2
    pt12 = find_point_exact_order(12)        # 12 = 4 * 3
3
    r12 = recover_residue(12, pt12, oracle)
4

5
    residues, moduli = [r12 % 4, r12 % 3], [4, 3]
6
    for ell in [5, 7, 11, 13, 17, 19, 23, 29, 31,
7
                37, 41, 43, 47, 53, 59]:     # 恰好 15 个
8
        pt = find_point_exact_order(ell)
9
        residues.append(recover_residue(ell, pt, oracle))
10
        moduli.append(ell)
11

12
    d = crt(residues, moduli)
13
    return d

为什么把 12 单独拎出来？因为 ℓ = 12 = 4 × 3 的群同时给了 d mod 4 和 d mod 3 两个独立同余式，省一次查询。这一招在 query budget 很紧的时候特别有用。

7. 实战结果（远端 47.93.199.115:39111）#

1
python attack.py --secret 262598232190837068 \
2
                 --flag 'moectf{inv4l1d_curve_4tt4ck_0n_br0k3n_ecdh_yes_please}'

1
[+] recovered secret d = 262598232190837068
2
[+] decrypted flag = moectf{inv4l1d_curve_4tt4ck_0n_br0k3n_ecdh_yes_please}
3
[verify] real secret   = 262598232190837068
4
[verify] match         = True

1
python attack.py --host 47.93.199.115 --port 39111

1
[+] banner flag_iv = 646990fc7678ad91b8a65988c65bf8b4
2
[+] banner flag_ct = 1aa76af4ed10f9a3f8255fe28c386b40cb8d01eb54e132700571fa44c47475a5e487f30a245da4cbd42e7e85a04ee703
3
[+] recovered secret d = 387180059029016236
4
[+] decrypted flag = flag{e05c3cf7-9608-4e20-af91-140a62ac6f50}

1
  iv=646990fc7678ad91...  ->  flag{e05c3cf7-9608-4e20-af91-140a62ac6f50}
2
  iv=8fb4eb49329c5231...  ->  flag{e05c3cf7-9608-4e20-af91-140a62ac6f50}
3
  iv=1121ec1c0d528143...  ->  flag{e05c3cf7-9608-4e20-af91-140a62ac6f50}

8. 一句话总结 + 防坑提醒#

• 漏洞本质：ECDHE 服务端不校验入参公钥是否真的落在 y^2 = x^3 + ax + b 上。
• 怎么利用：服务器接受任何 (x, y)，加法公式照样算，照样派生 key，照样加密明文。
• 攻击套路：选阶为小素数 ℓ 的点 → 一次 oracle + 一次穷举就把 d mod ℓ 试出来 → CRT 拼回 d。
• 防御：mul(d, peer) 之前必须 assert curve.is_on_curve(peer)。OpenSSL、CVE-2017-8932、Go crypto/ecdsa 都出过这种 bug，签名密钥一旦漏 ≈ 私钥直接被扒。

附：文件清单（本机新增）#

• attack.py —— 一键整合脚本，对本机/线上都通用：python attack.py --secret X --flag "..." 走本机 oracle 自检，python attack.py --host H --port P 打远端拿真 flag。
• run_local_server.py —— 临时启动一份带 flag 的 server，仅用于验证攻击链。

（打远端拿真实 flag 只需 attack.py，run_local_server.py 是自检用的临时件，可删。）

附 2：踩坑记录#

• macOS 没有 timeout 命令。想给探测脚本加超时，别写 timeout 20 python ...，改用 Python 自己的 socket.create_connection((host, port), timeout=10)。
• sqrt_mod_p_3_mod_4 只对 p ≡ 3 (mod 4) 成立。本题 p 末位是 9（即 p ≡ 1 mod 4），所以这个函数并不总是返回正确的平方根。好在暴力枚举 x 时会很快碰到能算对的那个，且即便 y 不在曲线上，加法公式照样能算出”看起来合理”的点，最坏情况只是那一次查询被服务端拒绝。所以暴力范围给到 2^20 就够了。
• 远端每次连接都会重新生成 IV 并重加密 flag，所以 banner 里的 flag_iv/flag_ct 每次都不同——这是正常的，正好可以拿来做交叉验证（同一个 d 能解开所有不同 IV 的密文）。
• 判断”恢复是否成功”最可靠的信号是 PKCS7 unpad 是否通过。AES-CBC 解密本身永远”成功”，但 padding 校验会拦截错误的 key——错误的 d 会直接抛 ValueError，不会静默给出乱码。

题目描述#

一个内部审计服务器发生了异常中断。服务重启后，调查人员发现审计数据库中缺失了一条关键审计记录。 恢复在 2026-07-18 03:14:00 之前最后一次成功提交（committed）的 EXPORT 操作。 Flag 格式：flag{actor-action-nonce}，全部使用小写字符。

环境准备#

拿到的是一个 7z 压缩包，解压后得到三个 E01 文件（EnCase 取证镜像格式）：

1
commit.E01  1572852211 字节
2
commit.E02  1572851461 字节
3
commit.E03  1150841853 字节

macOS 下没有 7z，用系统自带的 bsdtar 解压：

1
bsdtar -xf committed_*.7z

E01 是 EnCase 证据镜像（EWF 格式），需要 libewf 解析。用 Python 的 libewf-python 直接读取：

1
pip3 install libewf-python

1
import pyewf
2
files = pyewf.glob('commit.E01')
3
h = pyewf.handle()
4
h.open(files)
5
print(h.get_media_size())   # 4294967296 = 4GB

将 E01 转成 raw 原始镜像：

1
h.seek(0)
2
# 分块读出 4GB 数据写入 commit.raw

挂载 / 解析文件系统#

查看 raw 镜像头，偏移 0x400 处发现 ext4 超级块（魔数 53 ef = 0xEF53）：

1
00000400: 0000 0400 0000 1000 0000 0000 644c 0200  ............dL..
2
00000470: b8d1 52d7 b010 b4e4 0000 0000 0000 0000  ..R.............
3
00000480: 0000 0000 0000 0000 2f6d 6e74 2f64 6f75  ......../mnt/dou
4
00000490: 626c 652d 636f 6d6d 6974 0000 0000 0000  ble-commit......

卷标为 /mnt/double-commit（题目名 “committed” 的伏笔，暗示 SQLite 的 WAL/checkpoint 双提交机制）。

macOS 无法直接挂载 ext4，安装 e2fsprogs 用 debugfs 读取：

1
brew install e2fsprogs
2
export PATH="/opt/homebrew/opt/e2fsprogs/bin:/opt/homebrew/opt/e2fsprogs/sbin:$PATH"
3

4
debugfs -R "ls -l /" commit.raw

根目录结构：

1
lost+found
2
srv/            -> audit/audit.db   (16KB，SQLite)
3
var/            -> cache/ tmp/
4
frag/           -> f0001..f1999（1000 个 64KB 文件，全是 0，是填充）
5
fill.bin        -> 3.46GB（填充文件）

其中 /frag 目录里的 1000 个文件经检查全部为零字节，是干扰项（填充数据）。

分析当前审计数据库#

提取 audit.db：

1
debugfs -R "dump /srv/audit/audit.db audit.db" commit.raw
2
file audit.db
3
# SQLite 3.x database, database pages 4, file counter 2, schema 4

用 Python sqlite3 查看：

1
import sqlite3
2
con = sqlite3.connect('audit.db')

当前数据库内容：

关键审计记录（EXPORT 操作）确实丢失了——当前库里连 svc_archive、EXPORT 这些记录都没有。

数据库 schema：

1
CREATE TABLE audit_event(
2
    event_id INTEGER PRIMARY KEY,
3
    ts INTEGER NOT NULL,        -- 时间戳
4
    actor_id INTEGER NOT NULL,
5
    action_id INTEGER NOT NULL,
6
    object_id INTEGER NOT NULL,
7
    nonce BLOB NOT NULL,        -- 随机 nonce
8
    context BLOB                -- 上下文/导出数据
9
)

从未分配空间恢复被删除的数据#

服务”异常中断”后重启，SQLite 的 WAL（Write-Ahead Logging）中已提交但未 checkpoint 的数据丢失，旧的数据库文件被删除，其内容残留在文件系统的未分配空间里。

直接在 raw 镜像中搜索 SQLite 特征字符串：

1
import mmap
2
mm = mmap.mmap(open('commit.raw','rb').fileno(), 0, access=mmap.ACCESS_READ)
3
for pat in [b'SQLite format 3', b'EXPORT', b'CREATE TABLE', b'audit_event']:
4
    # 遍历 mm.find(pat)

找到多处 SQLite format 3 头：

1
406847544   (0x18400038)  change=3 npages=486 schema=4
2
408948736   (0x18601000)  change=2 npages=4   schema=3   <- 当前 audit.db
3
408952888   (0x18602038)  change=2 npages=2   schema=1
4
408961128   (0x18604068)  change=2 npages=3   schema=2
5
408969368   (0x18606098)  change=2 npages=4   schema=3
6
673189944   (0x28201038)  change=3 npages=488 schema=4
7
673206424   (0x28205098)  change=3 npages=683 schema=4
8
941625344   (0x38201000)  change=3 npages=486 schema=4   <- 完整的被删除 DB

同时搜索 WAL 魔数 0x377f0682（文件内字节序 37 7f 06 82）：

1
406847488  (0x18400000)  ckpt_seq=1  salt=0xb4f8bf45 0xf1bd51bd
2
408952832  (0x18602000)  ckpt_seq=0  salt=0xc9ce6207 0xcf9650df
3
673189888  (0x28201000)  ckpt_seq=2  salt=0xb4f8bf46 0x1c0fff7c

恢复完整数据库#

1
# 偏移 941625344，486 页 × 4096 = 1990656 字节
2
pages = 486
3
open('full_audit.db','wb').write(raw[941625344:941625344+pages*4096])

1
PGSZ = 4096
2
base = bytearray(open('full_audit.db','rb').read())
3
# 逐帧读取 WAL3，按页号覆盖到 base，直到最后一个提交帧（dbsize != 0）
4
# 提交帧是 frame 3（dbsize=488），frame 4~211 均为 dbsize=0（未提交）

1
(8100, 1784314000, 13, 7, 5001, nonce...)  ts=2026-07-17 18:46:40  svc_backup
2
(8137, 1784315507, 42, 7, 9182, nonce...)  ts=2026-07-17 19:11:47  svc_archive

定位目标记录#

截止时间转换：

1
import datetime
2
cutoff = int(datetime.datetime(2026,7,18,3,14,0,tzinfo=datetime.timezone.utc).timestamp())
3
# cutoff = 1784344440

两条 EXPORT 事件时间戳均 < 1784344440，其中 event 8137（19:11:47）是最晚的一次。

• 未提交的 683 页事务（frame 4~211）因没有提交帧，重放后数据库是损坏的（database disk image is malformed），符合”异常中断导致数据丢失”的设定，不计入。

提取 Flag 字段#

查询 event 8137 完整记录：

1
event_id   = 8137
2
ts         = 1784315507  -> 2026-07-17 19:11:47 UTC
3
actor_id   = 42          -> actor.username = 'svc_archive'
4
action_id  = 7           -> action_type.name = 'EXPORT'
5
object_id  = 9182
6
nonce      = 91 4f aa 28 31 9c 74 d2 03 e8 b1 c7 42 6e 95 11

• actor → svc_archive
• action → export（小写）
• nonce → 16 字节 BLOB 的十六进制（小写）914faa28319c74d203e8b1c7426e9511

Flag#

1
flag{svc_archive-export-914faa28319c74d203e8b1c7426e9511}

1. 先看题目给了什么#

核心关系（和 Kyber 一样）：

1
t = A·s + e   (mod Q)
2
    A: 公开的 2×2 多项式矩阵
3
    s: 秘密多项式（系数 ∈ {-2,-1,0,1,2}）  ← 我们要偷的就是它
4
    e: 小噪声（系数 ∈ {-1,0,1}）

解封装时计算 v - sᵀ·u，其中每个秘密系数都会参与一次 Montgomery 乘法， 功耗就“带”出了它的信息。

2. 读懂泄漏模型（challenge.py 明摆着给的）#

1
def leakage_model(secret_coeff, public_coeff):
2
    z        = montgomery_reduce(secret_coeff * public_coeff)
3
    precharge = montgomery_reduce(7 * public_coeff + 0x1234)  # 已知常量
4
    return hw16((centered(z) & 0xFFFF) ^ (centered(precharge) & 0xFFFF))

• hw16 = 16 位的汉明重量（bit 数）。
• precharge 只依赖公开的 public_coeff，所以是可以自己算的已知量。
• 于是对任意猜测的 s 候选值，我们都能算出对应的泄漏 hw16(...)， 再和真实功耗做相关系数，相关最高的候选就是正确答案。

每个秘密系数只有 5 种取值（-2~2），所以每个位置只需猜 5 个值。

3. 在 384 长的曲线里“找”每个系数（CPA）#

1
列 c = 96 + bit_reverse_7(gi)      # gi = 秘密系数的下标 0..127

1
对 gi: 取公开系数 cpub = u_samples[:, gi]
2
      对候选 s ∈ {-2,-1,0,1,2} 各算一条预测泄漏曲线
3
      与 trace[:, 96 + bitrev7(gi)] 求 Pearson 相关系数
4
      取 |r| 最大的候选作为 s[gi]

1
# 命中 112 个高置信系数后的样子（前 40 个）
2
[-1, 1, -2, -2, 0, 2, 1, 2, 0, 0, -1, 0, -2, 2, 0, -2,
3
 -1, 2, 0, -2, -2, 1, 0, 1, 0, -2, 1, ?, 2, 2, 0, -2,
4
  1, 2, -2, 2, -2, -1, -1, 2, ...]