纯静态硬啃xx反封号 dylib：OLLVM CFF MBA 全链路反混淆，还原 167 hook 攻防全图（看着吓人-iOS安全-看雪安全社区

纯静态硬啃xx反封号 dylib：OLLVM CFF MBA 全链路反混淆，还原 167 hook 攻防全图（看着吓人

发表于: 2026-4-26 16:22 23769

纯静态硬啃xx反封号 dylib：OLLVM CFF MBA 全链路反混淆，还原 167 hook 攻防全图（看着吓人

qqqiu

2026-4-26 16:22

23769

求爷爷告奶奶搞来了这个样本，上来一看：
 ![](upload/attach/202604/1053738_RKQD5JF6TCCVHJ2.webp)
看着就像ollvm 都是些sub函数 逻辑肯定都在sub函数里面了，希望是ollvm标准版 打开插件准备一把梭哈
 ![图片描述](upload/attach/202604/1053738_3QPDUCHMT3V2KRB.webp)
没用 说明标准ollvm 变体服了 开始正篇：
## 1. 第一锤子:确认是 OLLVM CFF

我对比了两个普通函数的开头,`sub_49C4` 和 `sub_87B0`:

```asm
; sub_49C4 开头              ; sub_87B0 开头
CMP  W8, W25                  MOV  W9, #0xB1EA1D76
CSET W9, LT                   CMP  W8, W9
STR  W9, [SP,#arg_CDC]        CSET W9, LT
LDR  X10, [X20,#0xC50]        STR  W9, [SP,#arg_88C]
LDR  X9, [X10,W9,UXTW#3]      LDR  X10, [X20,#0x800]
BR   X9                       LDR  X9, [X10,W9,UXTW#3]
                              BR   X9
```

这个模板太眼熟了 —— OLLVM Control-Flow Flattening 的标志五件套:

1. `CMP W8, <state_const>` 比当前 state 与魔数
2. `CSET Wx, LT` 把比较结果布尔化
3. `STR Wx, [SP, #...]` 暂存到栈,加数据流复杂度
4. `LDR X10, [X20, #table_off]` 取分发表基址
5. `LDR X9, [X10, Wx, UXTW#3]` 索引乘 8 取目标
6. `BR X9` 间接跳转,丢失静态分析目标

字节级一致。两个函数除了 cmp 常量(W25 vs `#0xB1EA1D76`)和 X20 偏移不同,指令序列、寄存器编号、移位形式完全一样,这种"指令骨架完全相同、只换立即数"的模板化代码,只有混淆器编译能产生,人手写或者普通编译器优化都不会出这种结果。可以肯定用了 <a href="elink@556K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6G2j5X3k6#2M7$3y4S2N6r3!0J5i4K6u0V1L8r3I4$3L8g2)9J5c8X3!0T1k6Y4g2K6j5$3q4@1L8%4t1`.">obfuscator-llvm</a> 或它的衍生(Hikari、Pluto-LLVM、Snake-LLVM 这些)。

值得多看一眼的是 `BR X9` 这一行的杀伤力。`BR` 是 ARM64 的间接跳转,目标地址在寄存器里,**IDA 的递归下降反汇编无法静态确定它跳到哪**。每碰到一个 `BR Xn`,IDA 默认就把这里当成函数边界 —— 因为再往下的字节它不能保证是不是新函数的开头。这就是为什么这个 dylib 会出现 1492 个 `sub_XXXX`:作者把所有原本的条件分支全部翻译成 `BR`,IDA 看到一片 `BR` 就在每处砍一刀,把原本的 1 个大函数切成上千段。这是 OLLVM CFF 的副作用,但作者很可能就是冲着这个副作用来的。

入口函数里出现的三个立即数:

```asm
W22 = 0xFD6886DF   ; 4019357919
W28 = 0xD8128E13   ; 3625422867
W25 = 0x3664924A   ;  912495690
```

我当时第一反应是字符串解密密钥,准备拿去试 XOR。32 位整数,出现在入口函数,看起来像 key —— 好像未知魔数的。我都已经写好了一段 Python:把 `__data` 段密文按 4 字节切片,跟这三个值挨个 XOR,看输出里有没有可见 ASCII 模式。结果当然是没有。气死我了。

后来发现这就是 OLLVM CFF 的 dispatcher state 初值,每个函数有独立的随机 state。在平坦化的 while-switch 结构里,这些值只是 case 的索引常量,没有任何密码学意义,“坑货啊”**brute force 是浪费时间**。看到入口函数装载几个高熵 32 位常量,先不要假定是密钥,先看它们在后续指令里被怎么消费 —— 如果是 `CMP W8, Wxxx` 这种直接比较,99% 是 dispatcher state;如果是 `EOR W?, W?, Wxxx`、`UMULL`、`MADD` 这种算术参与,才有可能是 key。兄弟们记住喽

然后发现:`sub_4000`(入口)和 `sub_32F14`(普通函数)都引用了同一张分发表 `off_42DA0`。这个细节在当时不起眼,我甚至差点跳过去,后面证明是关键 —— 朴素 CFF 是每函数独立 dispatch table(每个函数有自己专属的 state→target 大表),**这里是全局共享 dispatch table**,意味着不能简单用 IDA 脚本对单函数解 CFF,必须全局重建 dispatch graph。这种共享方案的好处是省体积:朴素 CFF 会让 `.text` 和 `.const` 急剧膨胀,共享 table 让所有函数共用一张大表,自己只取一段。坏处是反混淆的工程量提高,但这是混淆器作者乐见的。可恶。

## 2. 迷局一:1492 个函数到底是什么东西

CFF 看清楚之后,我准备开干 —— 先把 dispatch table 解出来,然后逐函数还原 CFG。现有的脚本好像都失效了，是变种，总有朋友问你怎么不trace，别急别急。（后面有狗头保命）

但搞到一半就感觉不对。问题出在数量上:1492 个函数,如果每个都是独立的 OLLVM CFF 函数,那 trampoline 数量应该跟函数数差不多。我数了一下,典型 trampoline 模板的实例只有两百多个。剩下 1200 多个"函数"是什么?

带着这个不对劲我又看了一眼 `__cstring`,84 字节;再看 `__data` 加密区,0x40328 字节。如果 1492 个函数大部分是真业务函数,那 `__cstring` 应该有几百到几千字节的明文剩余(C 字符串字面量、调试串、`__FUNCTION__` 这些总会漏一些),不可能压到 84 字节;反过来如果 1492 个全是 trampoline,加密区也用不上 263 KB。这两个数字加起来给我的感觉是:**真正的业务代码体量根本没到 1492 个函数**,我对"函数"的计量方式是错的。

那能不能:**先反编译一个看起来普通的函数,看它到底长什么样**。我挑了 `sub_8794`,因为它在数据交叉引用里出现频率特别高(后来知道是 130/223,占了 58%)。挑高频节点反编译,在大量同质化的混淆函数里这是一个被严重低估的姿势 —— 任何一个被反编译干净的样本都会暴露整套混淆协议,因为协议必须自洽,一个样本就是一个完整切片。

`sub_8794` 反编译出来非常短,前几条指令长这样:

```asm
LDAR  WZR, [X0]                 ; atomic load,丢值,纯内存屏障
ADRP  X8, dword_41DCC@PAGE
LDR   W8, [X8,#dword_41DCC@PAGEOFF]
ADRP  X9, dword_41DD0@PAGE
LDR   W9, [X9,#dword_41DD0@PAGEOFF]
ORR   W8, W8, W9
MOV   W9, #0xA96EA1AD
ORR   W8, W8, W9
SUB   W8, W8, W10               ; W10 是上层留下的!
;; ... 一堆 MBA 计算 ...
LDR   W8, [X29,#-0xDC]          ; 这一行让我愣住了
```

`LDR W8, [X29, #-0xDC]` —— **从栈上读 W8**。

我之前一直以为 W8 是 dispatcher 的 state 寄存器,顺着指令流传递。但这里赤裸裸地从栈帧读,意味着:**W8 的值不在寄存器里持续传递,而是每次进 trampoline 都从栈上读、算完再存回栈**。

这件事的后劲挺大的。它解释了之前一个困惑:在 lldb 或者 IDA 调试视图里盯 W8,你永远看到它"不停被覆盖、没有规律",因为 W8 在跨 trampoline 的层面根本不是状态,只是临时 cache。**真正的状态藏在栈上的某个固定 offset(这里是 `[X29-0xDC]`)**。OLLVM 这一手把"状态"从寄存器移到栈,对人工逆向是降维打击 —— 大多数逆向者下意识把寄存器当 first-class、把栈当 second-class,跟踪状态时盯的是寄存器视图,根本不会去看栈帧的某个固定 offset。

更狠的是,我去看 `sub_8794` 有没有自己的 prologue,**没有**。它没有 `STP X29, X30, [SP, #-0x10]!` 这种栈帧建立。也就是说,`sub_8794` 不是个真正意义上的"函数",它是某个母函数(就是 `sub_4000`)栈帧上的一段代码,通过尾调用链一路 `BR` 跳过来的。函数体里的 `X29` 不是它自己建立的,是从调用方继承来的;它读 `[X29-0xDC]` 实际上读的是调用方栈帧上的某个位置 —— 这个位置由调用方的调用方填充,可能再往上一层才是真正的源头。

顺手把它 `ORR` 进来的两个全局 `dword_41DCC` 和 `dword_41DD0` 也查一下,加上它前面的 `LDAR WZR, [X0]` 用到的 atomic flag 地址,跑一遍 `globals_probe.json` 落盘:

```json
[
  {"name": "dword_41DC4", "addr": "0x41DC4", "segment": "__data",
   "init_value": "0xBE732599", "description": "MBA seed key"},
  {"name": "dword_41DC8", "addr": "0x41DC8", "segment": "__data",
   "init_value": "0x43FFD974", "description": "MBA seed key"},
  {"name": "dword_41DCC", "addr": "0x41DCC", "segment": "__data",
   "init_value": "0x2338FB04", "description": "MBA seed key"},
  {"name": "dword_41DD0", "addr": "0x41DD0", "segment": "__data",
   "init_value": "0xF690C74D", "description": "MBA seed key"},
  {"name": "dword_41DD4", "addr": "0x41DD4", "segment": "__data",
   "init_value": "0x8B27A32A", "description": "MBA seed key"},
  {"name": "dword_41DD8", "addr": "0x41DD8", "segment": "__data",
   "init_value": "0x5AE39E39", "description": "MBA seed key"},
  {"name": "dword_4AF68", "addr": "0x4AF68", "segment": "__bss",
   "init_value": "0xFFFFFFFF", "description": "BSS atomic flag (LDAR/STLR pair)"},
  {"name": "dword_4AF80", "addr": "0x4AF80", "segment": "__bss",
   "init_value": "0xFFFFFFFF", "description": "BSS atomic flag"},
  {"name": "dword_4AF84", "addr": "0x4AF84", "segment": "__bss",
   "init_value": "0xFFFFFFFF", "description": "BSS atomic flag"}
]
```

6 个 MBA seed key 都在 `__data`,初值是高熵 32 位常量;3 个 atomic flag 都在 `__bss`,初值统一是 `0xFFFFFFFF`(BSS 段约定的"未初始化"标记)。**关键洞察**:这些 dword_41DCx 不是状态字,是只读的 MBA 种子常量。每个 trampoline 在 MBA 计算里取不同的种子组合(像 sub_8794 取 41DCC + 41DD0)+ 一个魔数偏移(`0xA96EA1AD`)+ 一个上游传入的 W10 → 算出本节点的判断函数。**整套 BDD 的"信息载体"实际上不在内存里,而在控制流的累积路径上** —— 每条不同的执行路径选择不同的种子组合,产生不同的最终行为。这是 BDD 对"分支信息"做的反直觉编码:**信息不存在节点里,信息存在路径里**。

这一刻整个理解全翻了。

**之前的模型**:1492 个独立函数,每个函数都做 OLLVM CFF。

**修正后的模型**:整个 dylib 实质上是一个超级函数。`sub_4000` 是入口,负责建立栈帧、写入分发表、初始化 state。然后通过尾调用链 (`BR Xn`) 跳到一系列 trampoline,每个 trampoline 从 `[X29-0xDC]` 读 state,跟一个魔数比较,根据结果索引分发表跳到下一个 trampoline。**1492 个"函数"实际是一个尾调用链上的 1492 个基本块**,IDA 因为它们都是 `BR Xn` 跳进来的,误以为是函数。

你可以把这个东西理解成 OLLVM 把一个普通的 `while-switch` 状态机,**整个翻译成了基于尾调用的递归形式,而且把状态字段从寄存器降级到栈槽**。这样静态分析就废了 —— 你看任何一个 trampoline,都不知道它的 W8 是从哪里来的、要去哪里,因为 W8 从栈读出来,而栈在调用方写入。再加上`CSET LT` 永远只产 0 或 1 这一个事实,每个 trampoline 实际只编码 1 比特决策(`<` 取 1,`≥` 取 0),根本不是经典 OLLVM CFF 的 N 路 switch。1492 个 trampoline 串起来不是一棵 N 叉决策树,而是一棵**二叉决策图(BDD)**。

这个观察直接改变了反混淆代价的量级。经典 CFF 反混淆需要对每个 case 做符号执行求 state 关系,O(N²) 复杂度,1492 个节点意味着数小时到数天的求解器跑;binary-fork 这种结构每个节点只藏 1 比特,直接读两个指针就能拿到分支去向,O(N) 就能推完。**整个混淆体系的工作量从"两到五人周"降到"两到五人天"**。混淆器作者很可能是想用函数数量把对手吓退(看到 1492 个 sub_XXXX 大多数人就放弃了),但忽略了单点信息量 —— 一旦识破"每个 trampoline 只藏 1 比特"这件事,整体就崩了。

确认这个之后,反混淆策略整个推翻重写。我开始写一系列分析脚本（ai真是个好东西，后面微调后效果真是不错啊）,从 `cff_step1_x20map.py` 一直干到 `cff_step19_parse_decomp_to_schedule.py`,一步步把这棵尾调用链解构。脚本一共写了 19 个,平均每个一两百行,加起来三千行左右,后面会挑核心几个讲玩玩。

## 3. 迷局二:xrefs_to(_MSHookMessageEx) 一个调用者都找不到

跟 CFF 的迷局并行的是 hook 注册表的迷局。

我习惯找 hook 注册函数的方式是:xrefs_to(_MSHookMessageEx) 看谁调它。逆向 iOS tweak 这是第一招,稳得不能再稳 —— MSHookMessageEx 是 MobileSubstrate 的入口 API,任何 tweak 想 hook ObjC 方法都得调它,谁调它谁就是 hook 注册函数,顺藤摸瓜整个 hook 列表都能挖出来。

这个 dylib 里这一招直接失败 —— xref 表显示只有几个 thunk 调它,真正的 hook 注册函数一个都看不见。

# 在 ida-pro-mcp 里跑
xrefs = mcp__ida-pro-mcp__xrefs_to(MSHookMessageEx_addr)
# 返回 19 个 site,全是 4 指令 thunk 包装
19 个 thunk,每个 thunk 长这样:

ADRP X16, _MSHookMessageEx@GOTPAGE
LDR  X16, [X16, _MSHookMessageEx@GOTPAGEOFF]
BR   X16
继续追这 19 个 thunk 的 xref —— 还是找不到真正的调用方。因为调用方是通过函数指针表(BDD 节点出口)跳进来的,不是直接 BL,所以 IDA 的 xref 网络在这一层就断了。

这是混淆的另一层手段:间接化所有调用关系。原本 BL _MSHookMessageEx 一行能搞定,被改成 LDR X8, [X20, #off]; BR X8,IDA 只能告诉你 BR X8 跳了出去,跳到哪里它不知道。X8 在更早的某条 LDR X8, [X20, #imm] 设置,X20 是栈基址,栈基址上面装的是另一个表,这个表的内容由 sub_4000 prologue 在运行时填充 —— 静态分析不跑 prologue 就拿不到这些数据,IDA 默认不模拟运行,所以一片漆黑。

更阴险的是 这个鸟dylib 还做了一层反静态:把 MSHookMessageEx 的调用包成 19 个不同地址的 4 指令 thunk(sub_3835C / sub_3839C / sub_383DC ……),每个 hook 注册函数随机用其中一个 thunk。这就让你哪怕用脚本扫"有谁直接 BL 到 _MSHookMessageEx"也只能找到 thunk 自己,而不是真正的注册函数。

我后来用了非常笨但有效的办法:直接在二进制里搜索 thunk 地址被 LDR 引用的地方。

# 找所有 19 个 _MSHookMessageEx thunk 的地址
thunk_addrs = [...]  # 19 个

# 在 __const / __data 段全段扫描：
# for offset in range(0x40000, 0x4B000, 8):
    val = mcp__ida-pro-mcp__get_u64(offset)
    if val in thunk_addrs:
        # 这个 8 字节槽里存了 thunk 地址,某个 BR Xn 会跳过来
        print(hex(offset), hex(val)
这种"在数据段里 grep 函数指针"的做法听起来粗暴,但它绕开了所有混淆层 —— 你不需要懂 BDD,不需要解 OLLVM CFF,只要相信"thunk 地址必须出现在某个 8 字节槽里才能被间接调用"这个简单事实。所有间接调用最终都要把目标地址装进某个内存槽,而 8 字节对齐的内存槽是有限的,扫一遍就完了。

跑出来 167 个引用点,而不是 19 个。换句话说,真正的 hook 数量是 167,不是 19。19 是 thunk 数,167 是 thunk 被装入函数指针表的次数 —— 每次装入对应一个 hook 注册。后面我把这 167 个引用点按地址段分布画出来,意外发现里面还有"双份镜像"结构,这个先按下不表,放到第 8 章讲。

到这里猜到这个 dylib 的"反逆向价值"也就是说作者的核心防护投入,不在于隐藏代码,而在于隐藏 hook 列表。隐藏 hook 列表的目的就一个:别人不能直接照抄。这是商业反封号工具的核心商业秘密 —— 算法可以重写,核心代码可以重新组织,但"作者花了多长时间发现微信哪些方法值得 hook、哪些方法 hook 后会引发副作用、哪些方法是关键卡口"这种领域知识,是用时间和试错堆出来的,这才是真值钱的部分。

## 4. 写反混淆器:223 个 trampoline 全部解码,0 错误

没招了怎么办，不trace怎么办，只能写反混淆器一个个来写了。整体思路按 OBDD(Reduced Ordered BDD)展开 —— 因为这棵尾调用链本质就是一棵决策树,每个 trampoline 是一个决策节点,根据 W8 的值二选一往下走。BDD 这个数据结构在 SAT/SMT 求解、模型检查、电路 EDA 里用得很多,核心思想就是把布尔函数表示成一棵分叉树,每层节点对一个输入比特做判断,共享相同的子树以减少节点数。OLLVM 在这里把一个常规 if-else 嵌套结构编译成 BDD,本质上是把逻辑结构延展到运行时。

step1 先重建 X20 偏移映射。`sub_4000` 的 prologue 里把一个巨型指针表的基址 hoist 到栈帧上的某个槽,后续所有 trampoline 用 `LDR X10, [X20, #imm]` 读这张表。要解 BDD 必须先把这张表完整还原出来。

ARM64 的 `ADRL Xn, off_xxxx` + `STR Xn, [X20, #imm]` 是两步指令,光看单条 `STR` 拿不到目标地址,必须维护一个 shadow state 跟踪"哪个寄存器最近被装载了什么地址",看到 STR 时再回查 source 寄存器:

```python
# cff_step1_x20map.py: 重建 X20 偏移 → mini-table 地址映射
import ida_funcs, ida_ua, idc

ENTRY = 0x4000
fn = ida_funcs.get_func(ENTRY)

last_adr_for_reg = {}     # 寄存器号 → 最近一次 ADRL 装入的地址
x20_map = {}              # x20_offset → mini-table 地址

ea = fn.start_ea
while ea < fn.end_ea:
    insn = ida_ua.insn_t()
    sz = ida_ua.decode_insn(insn, ea)
    if sz == 0:
        ea += 4; continue

mnem = idc.print_insn_mnem(ea)

# 1) ADRL/ADRP/ADR: 记录"哪个寄存器刚装了什么地址"
    if mnem in ("ADRL", "ADR", "ADRP"):
        reg = insn.Op1.reg
        target = idc.get_operand_value(ea, 1)
        last_adr_for_reg[reg] = target

# 2) STR Xreg, [X20, #imm]: 把刚才装入 reg 的地址,存到 X20+imm
    elif mnem == "STR" and insn.Op2.type == ida_ua.o_displ:
        op2_str = idc.print_operand(ea, 1)
        src_reg = insn.Op1.reg
        if "X20" in op2_str and src_reg in last_adr_for_reg:
            disp = insn.Op2.addr
            x20_map[disp] = last_adr_for_reg[src_reg]

ea += sz

import builtins; builtins._x20_map = x20_map
```

跑完得到 **202 条映射**,呈现明显的两段结构:`X20[0x0..0x3D0]` 全部指向 `0x42DA0`(共享大表的 122 个状态槽),`X20[0x3E0..0xC50+]` 指向从 `0x47348` 起递减的滑动窗口段。后来把这个映射 dump 成 JSON 重看才发现实际是 5 段结构外加 3 个特殊槽,其中 `X20[0xC78]` 指向 `0x4AF68` —— LDAR 用的 atomic flag。这个 LDAR flag 后来被证明是首次/再次入口判定的关键,但当时 step1 没意识到，分析到这里我都无语了。

后来dump吧，哎**dump 这个动作本身就是分析步骤**。我原本只是想"把结果存盘免得 IDA 关掉就丢",但落盘的过程被迫做了格式化和聚合,看到 JSON 文件里的 5 段结构 + 特殊槽,马上就发现之前"两段结构"的判断不完整。都dump了继续干吧。

step2 扫每个 trampoline,提取 `(cmp_const, true_target, false_target)` 三元组。模式匹配的锚点是末尾 3 条定式指令 —— `LDR Xn, [X20, #imm]`(取 mini-table 基址) + `LDR Xn, [Xm, Wk, UXTW#3]`(以 0/1 索引)+ `BR Xn`,这三条几乎从来不变,把它们卡住其它的就好办了:

```python
# cff_step2_scan_trampolines.py: 扫 1492 个函数, 识别 trampoline 模板
import ida_funcs, ida_ua, ida_bytes, idc, idautils, ida_segment, builtins

x20_map  = builtins._x20_map
text_seg = ida_segment.get_segm_by_name("__text")

# sub_4000 prologue 装的魔数寄存器(一开始只知道 3 个)
W_REG_CONSTANTS = {
    22: 0xFD6886DF, 25: 0x3664924A, 28: 0xD8128E13,
}

trampolines, errors = [], []
for fn_ea in idautils.Functions(text_seg.start_ea, text_seg.end_ea):
    if fn_ea == 0x4000:
        continue   # sub_4000 自己不是 trampoline,跳过

insns = list(decode_function(fn_ea))   # [(ea, mnem, ops, insn_t), ...]
    if not (4 <= len(insns) <= 12):
        continue

# 末尾必须是 BR Xn
    if insns[-1][1] != "BR":
        continue
    # 倒数第 2 条: LDR Xn, [Xm, Wk, UXTW#3]   ← mini-table 索引
    if insns[-2][1] != "LDR" or "UXTW#3" not in insns[-2][2][1]:
        continue
    # 倒数第 3 条: LDR Xn, [X20, #imm]   ← mini-table 基址
    pp = insns[-3]
    if pp[1] != "LDR" or "X20" not in pp[2][1]:
        continue
    x20_offset = pp[3].Op2.addr & 0xFFFFFFFF

# 往前找 CMP / CSET 解 cmp_const(8 种模式后面会讲)
    cmp_const = resolve_cmp_const(insns, W_REG_CONSTANTS)

# 用 X20 偏移查 step1 的映射拿到 mini-table 地址,读两个槽
    table_addr = x20_map.get(x20_offset)
    if table_addr is None:
        errors.append({"fn": fn_ea, "x20_offset": x20_offset})
        continue

trampolines.append({
        "ea":           fn_ea,
        "x20_offset":   x20_offset,
        "table_addr":   table_addr,
        "cmp_const":    cmp_const,
        "false_target": ida_bytes.get_qword(table_addr),
        "true_target":  ida_bytes.get_qword(table_addr + 8),
    })

builtins._trampolines = trampolines
# 跑完: 223 个 trampoline, errors = 0
```

`resolve_cmp_const` 是个递归往前扫的小函数,处理几种比较模式。第一版我只覆盖了三种:

```
CMP W8, #imm                                  ✓
CMP W8, W22/W25/W28                          ✓ (上面那三个魔数寄存器)
CMP W8, W?  + 前面 MOV W?, #imm              ✓
```

漏掉的:

```
CMP W8, [SP, #imm]                            ✗ 栈变量
CMP W8, W7/W9/W10/W11                         ✗ 其他寄存器
CMN W8, #imm                                  ✗ 负数比较
TST W8, #imm                                  ✗ 位测试
LDR W?, [X20, #imm] + CMP W8, W?              ✗ X20 数组取常量(最常见!)
```

第二版补全所有这些模式,解析率到 83%。剩下 17% 卡在 sub_4000 末尾隐藏的 13 个魔数寄存器 —— 我之前只看到 W22/W25/W28,实际 prologue 末尾紧跟着另外 13 个 `MOV Wn, #imm`,把其他寄存器初始化成更多魔数:

```
W12 = 0x40D58939     W17 = 0x52BD65EA
W13 = 0x3F4EFB5E     W0  = 0x7C2AD684
W14 = 0x3BEEF50F     W1  = 0x68470F1E
W15 = 0x50856051     W2  = 0x84FF6501
W16 = 0x5B167B19     W3  = 0x822E0282
                     W4  = 0x97F5C604
                     W27 = 0xCA599231
                     W23 = 0xFF9AE195
```

这 13 个 `MOV` 装在 0x493C-0x49A4,夹在 prologue 主体跟函数末尾的 BR 之间,我第一遍读 sub_4000 是从入口顺序读的,看到 X20 数组初始化和那一大堆 ADRL+STR 之后觉得已经摸清模式就跳过去了,完全错过了末尾这 13 行。这是典型的"以为读完了其实没读"。手工补完之后解析率到 100%(16 个魔数寄存器,从只看见 3 个变成 16 个),回头看 step2 跑出的 `cmp_const` 列表,所有"未知"标签都消失了。

这些 `cmp_const` 的值看起来都是高熵随机数(`0x3664924A`、`0x5245100A`、`0x673C4425`、`0x72E2FCCE`、`0x78AE4B81` ……),平均 popcount 接近 16(理论期望也是 16),没有明显模式 —— 这几乎可以肯定是 PRNG 的连续输出。这种模式有个有趣的副产品:**如果能猜出 PRNG 的种子和算法,就可以预测整条 trampoline 链的 cmp_const 序列**,这反过来可以做"哪些函数被切割成了 trampoline"的预测器。后面就不想做他的其他样本了。然后继续

step3 v3 把每个 trampoline 完整解构 —— 不光是 cmp_const + F/T 三元组,还包括 CSET 谓词类型(LT/EQ/NE)、栈读写槽 offset、比较常量来源标签(W22_global / MOV+CMP / 未知 caller 传入)。这一步最大的副产品是统计 read/write 槽的分布,跑完发现 186 个不同的 write offset(后来证明 184 个是 dead store,纯烟雾弹),read offset 只有 2 个固定位置(`[X29-0xDC]` 和 `[X29-0x74]`)。这种"写得到处都是,读只有两个点"的反差,直接揭露了 这个OLLVM 玩"假数据流"。

step4 是真正的反混淆器,把 223 个描述符渲染成 if-else 树。算法很直接:**入口 = trampoline 集合 - 任何被 F/T 引用的 EA**(没有上游),**出口 = F/T target - trampoline 集合**(跳出 BDD 的真实业务函数),从每个入口 DFS 递归渲染:

```python
# cff_step4_unflatten.py: BDD 反扁平化, 输出 if-else 树
from collections import Counter
import builtins

descriptors = builtins._tramp_descriptors
desc_by_ea  = {d["ea"]: d for d in descriptors}
tramp_set   = set(desc_by_ea)

# 1) 入口 / 出口 / 入度
referenced, all_targets = set(), set()
in_degree = Counter()
for d in descriptors:
    for k in ("false_target", "true_target"):
        t = d.get(k)
        all_targets.add(t)
        if t in tramp_set:
            referenced.add(t)
            in_degree[t] += 1

entries = tramp_set - referenced     # 没被任何 trampoline 跳来的
exits   = all_targets - tramp_set    # 跳出 BDD 的真实函数

# 2) 递归渲染(visited 防环, max_depth 防爆栈)
def render(ea, indent, visited, max_depth=15):
    pad = "  " * indent
    if ea not in tramp_set:
        return f"{pad}-> sub_{ea:X}()  [exit]\n"
    if ea in visited:
        return f"{pad}-> sub_{ea:X}  [LOOP]\n"
    if max_depth <= 0:
        return f"{pad}-> sub_{ea:X}  [DEPTH LIMIT]\n"

d    = desc_by_ea[ea]
    cond = d["cset_cond_pretty"]                                     # < / == / ...
    cst  = f"0x{d['cmp_const']:X}" if d.get("cmp_const") else "?"

out  = f"{pad}if W8 {cond} {cst}:  // sub_{ea:X}\n"
    out += render(d["true_target"],  indent+1, visited|{ea}, max_depth-1)
    out += f"{pad}else:\n"
    out += render(d["false_target"], indent+1, visited|{ea}, max_depth-1)
    return out

# 3) 输出全部入口
output = []
for entry in sorted(entries):
    output.append(f"### ENTRY: sub_{entry:X} (in-degree={in_degree.get(entry, 0)})")
    output.append(render(entry, 0, set()))

open("data/unflattened_bdd.txt", "w").write("\n".join(output))
```

跑完产物 4.7 MB / 84557 行 if-else,平均每个入口几百到几千层嵌套。文件大但不离谱,grep 找特定 hook 的 dispatch 路径很方便 —— 比如要看 `sub_8794` 在哪些上游被引用,直接 `grep -n "sub_8794" unflattened_bdd.txt | head -50` 就能列出来。

落盘到 `data/` 的产物有 4 份:

```
data/x20_map.json                5.2 KB   202 条 X20 偏移 → mini-table 地址
data/trampolines.json            67  KB   223 个完整描述符
                                          (cmp_const + F/T target + 6-7 条指令)
data/edges.csv                   17  KB   446 条 BDD 边 (223 × 2)
data/cff_bdd.dot                 33  KB   GraphViz dot 文件,
                                          dot -Tsvg cff_bdd.dot 出图
data/unflatten_summary.json      2.4 KB   入口/出口/内部节点 + top 入度
data/unflattened_bdd.txt         4.7 MB   反扁平化 if-else 树
```

`unflatten_summary.json` 里的几个关键数字值得拎出来:**74 个入口 / 53 个出口 / 149 个内部节点**。出口是真正跳出 BDD 的"业务函数",其中 38 个是 hook 的 newImp(后面会讲它们里面 36 个还是 BDD,只 2 个是真函数)。74 入口意味着这棵尾调用链不是一棵"大树",是 74 棵相对独立的子树并存,每棵子树对应一个 hook dispatch 路径。

入度统计揭露了 BDD 的拓扑形状极不均匀:

```
sub_8794    in-degree=130   ← 58% 的 trampoline 都跳来这里
sub_49C4    in-degree= 20   ← 主干链 #1 根节点
sub_87B0    in-degree= 20   ← 主干链 #2 根节点
sub_8F08    in-degree= 13
其余 ...    in-degree ≤ 2
```

**130 + 20 + 20 + 13 = 183 条边收敛到 4 个节点(占 446 条边的 41%)**,其余 263 条边平均分配到 217 个节点。这种"少数节点高度收敛 + 多数节点零散"的拓扑反映 OLLVM 用了 ROBDD(Reduced Ordered BDD)优化 —— 把多个判定路径里相同的尾段合并成共用节点,这是 BDD 数据结构的标准压缩。

**223 个 trampoline 全部成功还原,errors = 0**。这件事本身就是最强的信号 —— 它证明我的模型 100% 准确,没有漏掉任何一种 trampoline 形态。如果模型不准,稍微有点边界情况没覆盖,就会有 5%-10% 的解析失败。**0 错误意味着已经摸到这个混淆器的全部规律**。

很多人会盯着 `223 / 1492 ≈ 14.9%` 这个分子,觉得"覆盖率不高"。这是看反了。真正应该盯的是另一个数字:`errors = 0`。0 错误的真正含义是模板假设零反例 —— 任何 trampoline 一旦满足"6-7 条定式指令 + CSET LT + LDR [X20+off] + LDR [X10, Wx UXTW#3] + BR X9"模板,X20 偏移在映射表里一定能查到,F/T target 一定指向合法的 trampoline 地址。剩余 85% 没匹配上的不是反例,是**模板变种**(比如 `CSET NE` 而不是 `LT`、不同栈保存模式),后面继续做模式分类就能纳入。**模型对了,剩下的就是工程量;模型错了,跑 100% 命中率也是徒劳**。

跑完之后看入度统计:

```
=== Top in-degree(被多少 trampoline 跳过来) ===
sub_8794    130   ← 58%,所有路径几乎都汇聚到这里
sub_5C2C     43
sub_92F8     32
... 长尾
```

`sub_8794` 是个巨型汇聚点。58% 的 trampoline 都最终汇到这里。这个节点对应的是 BDD 里高频复用的子表达式,在 ROBDD 优化里这种共享子节点是核心特性 —— 同一个判断逻辑被多条路径复用,只算一次。

第一次看到 130 这个入度的时候我以为它有什么特殊语义,反编译过去才发现 `sub_8794` 自己也是个标准 trampoline,就是上面给的那 7 行 LDAR + LDR + ORR + ... + LDR `[X29, #-0xDC]` + BR。它的"特殊性"完全来自图拓扑(高入度),不是语义。到这里我都无语了这人到底要干啥。继续找解密器吧。

## 5. 找解密器:xref 全军覆没,dref 一击命中

反混淆完成之后,主战场转移到字符串解密。`__data` 段里有 0x40328 字节高熵密文,得搞清楚解密算法和 key。（不要问我为什么不trace了）

我的第一反应是找解密器函数 —— 解密器肯定要"写"密文区(把解密结果写到某个 buffer),那么 `xrefs_to(0x40000)` 应该能找到所有写入点。这是逆向加密字符串最直接的入口,十次有九次能用。

```python
# 第一轮(失败)
for cipher_byte in range(0x40000, 0x42500):
    refs = mcp__ida-pro-mcp__xrefs_to(cipher_byte)
    # 几乎全是 0 个引用!
```

整整一天我卡在这里。0 个 xref 意味着 IDA 没有任何指令"显式引用"这个地址。但密文确实存在,确实有人解密它,这是个矛盾。

更让人怀疑人生的是,我去看几个怀疑是字符串入口的地址(后来确认是密文段开头):`xrefs_to(0x40300)` = 0,`xrefs_to(0x40E30)` = 0,`xrefs_to(0x4020E)` = 0,扫了一圈想找的都是 0。当时一度怀疑是不是 IDB 没解析完整,关掉 IDA 重开了一次,跑了 `idaapi.auto_wait()`,xref 表还是空。我也试过反方向,挑几个明显是解密器嫌疑的函数(写入量大、含 EOR、含循环)看它的 `DataRefsTo`,期望能跟 0x40000 段产生关联,也是 0。

我换了个角度想:**IDA 的 xref 是已经确认的链接,但 IDA 还有一种更宽松的引用 —— dref(data reference),是数据流分析推断出来的"指令可能访问的数据地址"**。OLLVM 阻断了 xref(因为 xref 检查指令是否"明确引用某地址"),但阻断不了 dref(IDA 的 ADRP+ADD 重组分析)。

具体的差别在于,`xref` 是 IDA 看到形如 `MOV X0, addr` / `LDR X0, [addr]` 这种"指令的立即数操作数本身就是地址"才会建立的;但 ARM64 没法在单条指令里塞一个完整 64 位地址,通常用 `ADRP X8, page; ADD X8, X8, #pageoff` 两条指令拼出来。OLLVM 把这两条指令拆开,中间塞一堆无关 MOV/STR/CMP,IDA 的 xref 引擎匹配不到这种"两步寻址"模式,就不建立 xref。但 IDA 的 dref 引擎专门做 ADRP+ADD 的指令对配对,这种数据流分析在两步寻址下仍然有效。**OLLVM 阻断了 xref,但阻断不了 dref**,这是它自己挡不住自己的数据流分析。

第二轮 —— 不再扫"谁引用了密文地址",换成扫"哪些函数对密文区写入次数最多",而且区分 STR(写)和 LDR(读),顺手统计 EOR 指令数(疑似 XOR 解密的强指标):

```python
# cff_step16_find_dec_v3.py: dref 扫全函数, 找 master decryptor
import idc, idautils, ida_funcs, ida_ua

CIPHER_MIN, CIPHER_MAX = 0x40000, 0x42500
candidates = []

for fn_ea in idautils.Functions():
    fn = ida_funcs.get_func(fn_ea)
    if not fn: continue
    sz = fn.end_ea - fn.start_ea
    if sz < 30 or sz > 5000:
        continue   # 排除 thunk + sub_4000 这种巨型初始化函数

W_addrs, R_addrs = set(), set()
    n_eor = 0

ea = fn.start_ea
    while ea < fn.end_ea:
        mn = idc.print_insn_mnem(ea)

# 关键: dref 而不是 xref
        for dref in idautils.DataRefsFrom(ea):
            if CIPHER_MIN <= dref < CIPHER_MAX:
                if mn in ("STR", "STRB", "STUR", "STURB"):
                    W_addrs.add(dref)
                elif mn in ("LDR", "LDRB", "LDUR", "LDURB"):
                    R_addrs.add(dref)

if mn == "EOR":
            n_eor += 1
        ea = idc.next_head(ea)

if len(W_addrs) > 10:
        candidates.append({
            "ea": fn_ea, "size": sz,
            "n_W": len(W_addrs), "n_R": len(R_addrs), "n_eor": n_eor,
            "W_range": (min(W_addrs), max(W_addrs)),
        })

candidates.sort(key=lambda x: -x["n_W"])
# 跑完: 15 个候选, 头部 3 个写入量最大
```

几个阈值都是经验值:`size < 30` 排除 thunk(thunk 通常 4 条指令),`size > 5000` 排除 `sub_4000` 这种巨型初始化函数(它会把所有 mini-table 地址 hoist 到栈,会误判),`n_W > 10` 卡掉只是顺便引用一两个常量的普通函数。最后剩下来的几乎全是 master decryptor。

跑完落盘 `data/decryptor_candidates.csv`,15 行,头部几行(按 n_W 排序)长这样:

```
addr     name        size  n_R  n_W  n_eor  W_range
0x4f34   sub_4F34    2260  107  108  18     0x40005-0x4026B
0x6df4   sub_6DF4    2532  109  108  22     0x40005-0x4026B   ← W_range 跟上一行完全一样!
0x1e418  sub_1E418   2556  119  116  23     0x41130-0x4127C
0x22ab8  sub_22AB8   1724   76   73  12     0x4152F-0x415DF
0x26b3c  sub_26B3C   1160   49   47   6     0x416E9-0x4176E
0x1d0b8  sub_1D0B8    420   13   12   5     0x41032-0x4103D
0x1d3e0  sub_1D3E0    292   11   12   5     0x41032-0x4103D   ← 跟上一行同 W_range
... 其余小节点
```

光看这个表就能看出几个细节:第二三行(sub_6DF4 / sub_1D3E0)的 `W_range` 跟它们前一行完全相同,这就是孪生 —— 写入同样的 108 / 12 个字节地址,只是 MBA 模板不同。`n_eor` 越高的越像 OLLVM 字符串解密的"显式 EOR"版本(不那么努力 MBA 的);`n_eor` 低的可能 MBA 强度更高,EOR 全被位掩码替代了。后面挑解密器先反编译,我会优先挑 `n_eor > 10` 的版本看(MBA 弱、可读性高),化简后再去对照 MBA 强的孪生。

跑出来的 15 个候选里,头部 3 个写入量最大:

```
sub_168C4   写 161 个独立字节,W_range = 0x40590-0x41001    ★ master
sub_FB2C    写 160 个独立字节,W_range = 0x40642-0x40FC4
sub_10A30   写 160 个独立字节,W_range = 0x40642-0x40FC4    ← 跟 sub_FB2C 范围完全相同
```

注意第三行那个奇怪的事实:`sub_FB2C` 和 `sub_10A30` 写的范围完全一样。第一眼看到的时候我以为是哪里统计错了,跑了一遍验证,确实是两个不同的函数(地址相差 0xF04),但 W_addrs 集合完全相同。这是 OLLVM 的"复制粘贴 MBA 重写"模式 —— 每个真 master 在地址相邻 0x1000-0x4000 的位置有一个 MBA 重写孪生。代数等价,但 MBA 模板不同。

具体例子,反编译出来同一行的两个版本:

```c
// sub_FB2C
byte_40F60 = (~byte_40F30 & 0x89 | byte_40F30 & 0x76) ^ 0x13;

// sub_10A30
byte_40F60 = byte_40F30 ^ 0x9A;
```

代数化简两者等价,因为 `0x89 | 0x76 = 0xFF` 且 `0x89 & 0x76 = 0`,所以 `~b & 0x89 | b & 0x76 = b ^ 0x89`,再 XOR 0x13 得到 `b ^ (0x89 ^ 0x13) = b ^ 0x9A`,跟 sub_10A30 完全一样。

这种孪生不是冗余备份,是**双 MBA 写法测试** —— 同一组 K 值用两套不同的 MBA 模板生成两份代码,把分析者引入"哪个是真的"的死胡同。检测方法很简单:**找写地址集合 100% 相等的两个函数,跳过其中之一**。这能直接砍掉一半的工作量。后续每次发现新 master,我都会立刻在地址相邻 0x1000-0x4000 内扫一圈找它的孪生,基本都能扫到。整个项目里我一共找到 6 对孪生,等于免费省了 6 倍的反编译工作。美滋滋。

## 6. 数学化简:OLLVM 的 8 种 MBA 模板,代数化简后全是 b ^ K

确定 `sub_168C4` 是主解密器,我开始反编译它的解密公式。

它写得很恶心,121 个字节解密公式,每一个都用不同的 MBA 表达式包装。我看到的前几个:

```c
plain[0] = b ^ 0xE0;                              // 直接 XOR
plain[1] = ~b & 0x83 | b & 0x7C;                  // 位掩码 1
plain[2] = ~((b | 0x33) & (~b | 0xCC));           // 位掩码 2
plain[3] = b - 2 * (b & 0xF3) - 13;               // 算术 1
plain[4] = (~b & 0xE9 | b & 0x16) ^ 0xF6;         // 嵌套 XOR
plain[5] = b - 2 * (b & 0x50) + 80;               // 算术 2
plain[6] = ~(b & 0xA4 | ~b & 0x5B);               // 位掩码 3
```

刚开始看到这些我有点头疼,以为得逐条手工化简或者上 SMT solver。Z3、Souper、msynth 这种工具我都准备好了,甚至已经在脑子里规划"先写一个 IR 转换器把 IDA 反编译输出的 C 表达式转成 Z3 约束,然后用 simplify 求等价 XOR 形式" —— 听起来很正统,但工程量是日级别。

后来我盯着这些公式看了一会儿,发现一个规律:**所有这些公式,实质上只做一件事 —— XOR**。

| 公式形态                                   | 代数化简      | 真实操作    |
| ------------------------------------------ | ------------- | ----------- |
| `b ^ K`                                    | `b ^ K`       | XOR K       |
| `~b & A \| b & B`(A+B=0xFF, A&B=0)         | `b ^ A`       | XOR A       |
| `~((b\|A) & (~b\|B))`(同上约束)            | `b ^ B`       | XOR B       |
| `~(b & A \| ~b & B)`                       | `b ^ ~A`      | XOR ~A      |
| `b - 2*(b & A) ± C`(A 是单 bit 掩码或全位) | `(b ^ A) ± C` | XOR + 加减  |
| `(... bitmask ...) ^ K`                    | 双重 XOR 链   | XOR (M ^ K) |

证明的话用真值表展开就行,比如 `~b & A | b & B`,当 `A | B == 0xFF` 且 `A & B == 0` 时,A 和 B 互补:

```
b 的某一位 = 0 时:~b 该位 = 1,~b & A = A 的对应位,b & B = 0
                  → 输出 = A 的对应位
b 的某一位 = 1 时:~b 该位 = 0,~b & A = 0,b & B = B 的对应位
                  → 输出 = B 的对应位
```

把 A 和 B 拼起来等于 `0xFF`,而 `b XOR A` 在 b=0 时输出 A,b=1 时输出 ~A = B(当 A+B=0xFF 时)。完全等价。

`b - 2*(b & A) ± C` 这个看着最唬人,展开也很简单。`b - 2*(b & A)` 在每一位上的行为:如果 A 该位为 0,那么 `b & A` 该位为 0,整个减法不影响这一位;如果 A 该位为 1,那么 `b & A` 该位 = b 该位,`b - 2*(b & A)` 在该位上做的是减去自己的两倍,等价于翻转这一位再加一个 carry,carry 累计起来在跨位的整体效果上等于 `b XOR A` 加一个常数偏移 `±C`。这是 OLLVM 的标准 MBA 编码,代数等价于 `(b ^ A) ± C`。

OLLVM 用 8 种写法绕死分析者,代数学一拳打回原形。

我没有真的去手工化简每条公式。第一版 step17 是最笨的办法:把 IDA 反编译出来的 121 行 C 表达式逐行抄成 Python lambda,放进列表,直接跑:

```python
# cff_step17_apply_dec_168C4.py: 第一版手工照搬反编译输出
import ida_bytes
def b(addr):
    return ida_bytes.get_byte(addr)

# 把 sub_168C4 反编译里每一行 byte_DST = expr; 抄成 (DST, lambda) 元组
RULES = [
    # 第一段 0x40D5D-0x40D67 → 0x40D7D-0x40D87 (+0x20, 11 字节)
    (0x40D7D, lambda: b(0x40D5D) ^ 0xE0),
    (0x40D7E, lambda: b(0x40D5E) ^ 0xBA),
    (0x40D7F, lambda: ((~b(0x40D5F) & 0x83 | b(0x40D5F) & 0x7C) ^ 0xE4) & 0xFF),
    (0x40D80, lambda: (b(0x40D60) - 2 * (b(0x40D60) & 0xF3) - 13) & 0xFF),
    (0x40D81, lambda: b(0x40D61) ^ 0x23),
    (0x40D82, lambda: ~(b(0x40D62) & 0xA4 | ~b(0x40D62) & 0x5B) & 0xFF),
    (0x40D83, lambda: ~((b(0x40D63) | 0x33) & (~b(0x40D63) | 0xCC)) & 0xFF),
    # ... 共 121 条
]

decrypted = {dst: fn() & 0xFF for dst, fn in RULES}
plaintext = bytes(decrypted[a] for a in sorted(decrypted))
print(plaintext.split(b"\x00"))   # 9 段明文字符串
```

这种写法的好处是稳得不能再稳（美） —— 你眼睛看着反编译输出抄一行,Python lambda 跑一行,字节按字节验证,几乎不可能错。坏处是**121 行手写到第 50 行的时候我已经开始按错位** —— 复制 `byte_40D60` 的时候多带一个数字、`& 0xF3` 写成 `& 0xF7`,这种小错很容易漏。最后我在 121 行里至少改了 5-6 处错位。

跑出 9 段明文之后,我意识到下一个 master(sub_FB2C)还有 160 行公式要抄,后面还有 14 个 master 等着 —— 总共一千多行公式手抄,只要错一处就得回头 debug。这时候才动手把这一步抽象成通用解析器:

```python
# cff_step19_parse_decomp_to_schedule.py: 通用 schedule 解析器
import re

ASSIGN_RE   = re.compile(r"byte_([0-9A-Fa-f]+)\s*=\s*(.+?);", re.S)
BYTE_REF_RE = re.compile(r"byte_([0-9A-Fa-f]+)")

def parse_pseudo_to_schedule(pseudo_text):
    """把 IDA 反编译输出的 C 赋值行, 转成可 eval 的 Python 表达式列表"""
    schedule = []
    for m in ASSIGN_RE.finditer(pseudo_text):
        dst_addr = int(m.group(1), 16)
        c_expr   = m.group(2).strip()

# 跳过"右侧无 byte_ 引用"的行(栈引用 / 形参 / 临时变量)
        if not BYTE_REF_RE.search(c_expr):
            continue

# byte_XXXX → b(0xXXXX), 整体 & 0xFF 防止 ~ 在 Python 里的有符号扩展
        py_expr = BYTE_REF_RE.sub(lambda mm: f"b(0x{mm.group(1)})", c_expr)
        py_expr = f"({py_expr}) & 0xFF"

schedule.append((dst_addr, py_expr))
    return schedule

def apply_schedule(schedule, byte_func):
    """跑 schedule, 输出 dst → plaintext byte 字典"""
    return {dst: eval(expr, {"b": byte_func}) for dst, expr in schedule}

# 用法:
# pseudo = open("sub_168C4_decompile.c").read()
# sched  = parse_pseudo_to_schedule(pseudo)
# result = apply_schedule(sched, byte_func=ida_bytes.get_byte)
```

整套流程不需要 SMT solver、不需要 IR 转换、不需要代数化简,Python 标准库就够。这是写工具时的一种思路:**当对手已经把信息明文表达在 C 代码里,你就别费劲去做"理解"那一步,直接把代码当函数用**。Hex-Rays 反编译已经是高质量的 C 代码,IDA 自己已经做了一遍语义提取,你只是需要"执行"它。

step19 写完之后剩下 14 个 master 全部直接喂反编译伪代码,30 秒内拿到全部明文。**这是整个项目最有复用价值的产出**,下次遇到任何 OLLVM 字符串解密器,把反编译伪代码喂进去,几乎是即时出结果。后续 step20-23(批量跑 FB2C / 3 个 big master / 3 个 medium master / 8 个 minor master)都基于这个 parser,平均每个 master 写不到 30 行就能跑通。

落盘到 `data/`:

```
data/dec_168C4_schedule.csv      12  KB   sub_168C4 的 121 行解密 schedule
                                          (dst_addr, src_addr, py_expr, key, ...)
data/dec_168C4_schedule.json     33  KB   同上的 JSON 版
data/decrypted_strings.csv       1.4 KB   第一批 9 段明文
data/decrypted_strings.json      4.5 KB   同上 JSON
data/dec_summary.json            2.2 KB   解密总体摘要
                                          (master 函数 / 段数 / 字节数)
```

`dec_168C4_schedule.csv` 把每个字节的解密公式 + 等价 XOR 后的真实 key 都列出来了。这个文件之所以专门留下来,是想保留"具体 OLLVM 字节级混淆长什么样"的样本 —— 后面我自己写其他混淆器解密器时,直接拿这个文件当模板照着改就行,不用从头摸索 8 种 MBA 模板的代数化简。

跑完 sub_168C4 的 121 行公式,提取出 9 段密文 → 明文映射:

```
段 1   0x40D5D-0x40D67  →  0x40D7D-0x40D87  +0x20  11 字节
段 2   0x40DD0-0x40DDE  →  0x40DDF-0x40DED  +0x0F  15 字节
段 3   0x40E40-0x40E54  →  0x40E60-0x40E74  +0x20  21 字节
段 4   0x40BF1-0x40BFD  →  0x40BFE-0x40C0A  +0x0D  13 字节
段 5   0x40570-0x40585  →  0x40590-0x405A5  +0x20  22 字节
段 6   0x40B00-0x40B13  →  0x40B20-0x40B33  +0x20  20 字节
段 7   0x40C90-0x40CA8  →  0x40CB0-0x40CC8  +0x20  25 字节
段 8   0x40AD2-0x40AE1  →  0x40AE2-0x40AF1  +0x10  16 字节
段 9   0x40FD0-0x40FE1  →  0x40FF0-0x41001  +0x20  18 字节
```

注意"密文区在前,明文区在后,偏移 +0x20 出现 6 次"这个规律 —— 这个OLLVM 解密器会在固定偏移处放置明文输出 buffer,这是它的工程便利,也是我们的攻击面。一旦看到这个规律,后面找其他 master 的明文区就有了模板:**给定密文起点,在 +0x10、+0x0D、+0x0F、+0x20 这几个常见偏移上找明文区,基本一打一个准**。这种"偏移规律"一旦识别出来,后续的 master 解密就是流水线工作 —— 找写入位置 → 反编译公式 → eval 出 key → 拼明文。
继续跑。
## 7. 第一次明文曝光:9 段字符串炸开整个反封号机制

跑出来的 9 段明文是这样的:

```
0x40D87:  rRequest:                   ; 加好友请求 SEL 后缀
0x40DDF:  MMTokenService              ; ★ ObjC 类名
0x40E60:  MMClientCacheManager        ; ★ ObjC 类名
0x40BFE:  checkConfig                 ; ★ SEL
0x40590:  reportCrashLog:type:        ; ★★★ 被 nullify 的 hook!
0x40B20:  reportDeviceToken:          ; ★★ 设备 Token 上报
0x40CB0:  refreshTokenWithPolicy:     ; ★★ Token 刷新
0x40AE2:  getAppSignType              ; 应用签名类型
0x40FF0:  isJailbrokenDevice          ; ★★★★ 越狱检测!
```

第一段拿出来的瞬间我猜这个 dylib 在干什么了。

`isJailbrokenDevice` 配合后面发现的 9 个 `nullsub_1` newImp,机制完全清楚了:**dylib 把wx内部用于检测越狱、上报安全事件的方法,全部 hook 成空操作或返回伪值**。

`reportCrashLog:type:` 直接被替换成 `nullsub_1`(汇编层面就是 `MOV X0, #0; RET` 两条指令)。任何代码调它都直接返回。崩溃信息永远不会到达微信服务器。崩溃日志在风控里有非常高的价值 —— 黑产的 hook 工具崩溃模式跟正常用户完全不同(频繁在 ObjC runtime 内部崩溃、栈帧带有 MobileSubstrate 痕迹、崩溃地址固定在某些 hook trampoline),把这条上报通路砍掉,等于砍掉一个核心信号源。

`isJailbrokenDevice` 被 hook 让它永远返回 NO。wx代码里所有 `if ([self isJailbrokenDevice]) { ban_user(); }` 这种判断,直接走"非越狱"分支。这是单点替换的经典姿势,简单粗暴但有效 —— 客户端检测的所有"判定 BOOL"都可以靠 hook 改返回值瓦解。

`MMTokenService` 是wx Token 系统的核心类。dylib 拦截这个类的 `refreshTokenWithPolicy:` 等方法,控制 Token 刷新行为,维持账号"看起来合法"的状态。Token 是微信账号在服务端的"通行证",每隔一段时间会按策略刷新,如果服务端发现某个账号的 Token 刷新行为异常(比如该刷的时候没刷、刷新参数对不上历史模式),会触发风控复核 —— hook 这一层就是控制 dylib 用户的 Token 刷新节奏,让它跟正常用户的统计模式吻合。

那一刻我意识到一件事:**这个 dylib 不是在破解wx的风控算法,是在切断风控的信息源**。这是攻防中典型的高维降维打击 —— 算法再强,数据进不来等于零。wx服务端可能跑着最先进的图神经网络做账号关系建模、用 LSTM 做行为时序异常检测,但如果客户端连"isJailbrokenDevice = YES"这条信号都不上报、连崩溃日志都不发,模型再强也是在猜。

但只有 9 段我没有满足。`__data` 段里有 0x40328 字节密文,这 161 字节才占了 4%。还有 96% 在哪?当时我以为 sub_168C4 已经覆盖完了 hook 字符串区(0x40500-0x41100),剩下的 96% 是别的用途 —— 可能是错误信息、调试串、内部协议字段。后来证明这个判断完全错了,真正的 hook 字符串横跨整个 0x40000-0x42500,我刚刚只挖了入口处的一小块。这个错误判断让我又损失了大半天 —— 我先去尝试反编译 38 个 newImp 函数,做完之后才回头继续找其他 master,如果一开始就把搜索面扩到整个 `__data`,可以省下一天。继续干。

## 8. 扩搜索面:孪生 + 双份镜像
这里我犯了另一个错误:**以为找全了**。
之前我扫的 cipher 区是 0x40500-0x41100,因为这是 `sub_168C4` 写入的范围。我以为 cipher 总量就这么大。直到我去看 `sub_FB2C`(被识别为孪生)和它的孪生 `sub_10A30` 的 W_range —— 0x40642-0x40FC4,跟 sub_168C4 部分重叠但不完全相同。两个 master 不是覆盖同一片区域的"主备"关系,而是分别管不同的字符串区。这个事实推翻了我的"161 字节 = hook 字符串总量"判断。
我把搜索面扩大到整个 `__data` 段(0x40000 - 0x42500),用同样的 dref 扫描,这次找到了 17 个 master decryptor(包括 5 对孪生)。这一步给我留下另一条经验:**逆向时定下"字符串区"边界后,永远再扩 3-5 倍重扫一遍**。边界往往是分析者的"假设",不是数据的"真实"。我之前的 281 字节边界,扩 3-5 倍正好对上 1100 字节的真实跨度,这种数量级关系不是偶然 —— 第一次定边界总是低估,因为你只看到了入口处的明显结构,后面散落的、不那么显眼的字符串区会被忽略。
跑完每一个,累计解出 66 个独立明文字符串、981 字节。一下子从 4% 覆盖跳到接近全覆盖。
```
Master
明文范围
字节数
主要内容
sub_168C4
0x40590-0x41001
161
hook 主区(MMTokenService 系列)
sub_FB2C
0x40642-0x40FC4
160
hook 主区(MMContext / ExptService)
sub_5A4C
0x400D5-0x4031F
215
反作弊核心类(MMRuntimeIntegrity 等)
sub_4F34
0x40005-0x4026B
108
dylib 头部(isEnvironmentTrusted 等)
sub_1E418
0x41130-0x4127C
116
A/B 配置 key
sub_22AB8
0x4152F-0x415DF
73
状态字典 key
sub_26B3C
0x416E9-0x4176E
47
越狱痕迹擦除
sub_33CE8+sub_33A24
0x41BA0-0x41BBC
29
★ SHA-256("") 伪值前 29 字节
sub_2E5E8
0x4196A-0x41A64
12 静态可见 / 96 不可见
栈指针变种
... 其余 8 个小节点
```

辅助类名
最后那个 `sub_2E5E8` 是这个项目的死角,放到第 11 节讲。
落盘到 `data/`:

```xxxxxxxxxx
data/master_decryptors.csv       348  B    17 master 函数清单(含 5 对孪生)
data/all_decrypted_strings.csv   4.4 KB    66 个独立明文(本研究最重要的输出)
data/all_decrypted_strings.json  10  KB    同上 JSON
```
`all_decrypted_strings.csv` 每行一个明文字符串 + 它的地址 + 长度 + 由哪个 master 解出来 + 原始 hex,头部 10 行长这样:
```
xxxxxxxxxx
addr      length  plaintext                  master       raw_hex (前缀)
0x40005   4       B@:@                       sub_4F34     42403a4000
0x40030   17      auditLoadedImages          sub_4F34     6175646974...
0x40070   20      verifyCodeSignature:       sub_4F34     76657269...
0x400D5   15      startMonitoring            sub_5A4C     7374617274...
0x400B0   20      isEnvironmentTrusted       sub_4F34     6973456e76...
0x401A0   25      MMSecurityPolicyValidator  sub_5A4C     4d4d5365...
0x40240   17      MMAntiTamperGuard          sub_5A4C     4d4d416e74...
0x402B0   24      validateCertChain:depth:   sub_5A4C     76616c6964...
0x402CE   3       set                        sub_5A4C     73657400
0x40300   31      com.tencent.xin.security.policy  sub_5A4C  636f6d2e...
... (共 66 行)
```
里面 `B@:@`、`v@:`、`@@:` 这种 4-5 字节短串是 ObjC method type encoding(`B` = BOOL,`@` = id,`:` = SEL,`v` = void,`i` = int),是 ObjC runtime 在 `class_addMethod` 等 API 里用的方法签名格式。它们出现在解密结果里说明 dylib 不光 swizzle 已存在的方法,还会用 `class_addMethod` 给目标类**新增**方法 —— 这跟 hook 注册函数 sub_1BB50 等里出现的 `_class_addMethod` import 完全对得上,是 ObjC 动态新增方法标准流程。
`com.tencent.xin.security.policy` 这一串是xx安全策略的 `NSUserDefaults` suite name(也可能是 entitlement key、CFBundle 子标识)。这种内部命名空间一旦曝光,等于把"wx哪些安全配置存在哪里"的索引递给了对手。看到这条字符串的瞬间我就知道这个 dylib 作者大概率有内部知识 —— 这种命名空间靠纯逆向猜出来的概率极低,要么有内部文档,要么逆向了多个wx版本对照得出。
中间还有个意外发现 —— **hook 注册表是双份镜像的**。我把 167 个 hook site 按地址段分布画出来:
```
xxxxxxxxxx
0x118dc - 0x11dc0   ~64 个 hook
0x1bb98 - 0x1c2b4   ~64 个 hook   ← 跟上面完全相同的 SEL/Class 序列!
0x12128 - 0x121b8   ~6 个,签名相关
0x16598 - 0x16624   ~6 个,签名相关
0x1c134 - 0x1c2b4   ~20 个,Token/Crash 相关
```
两段 64 个 hook 是同一份。我先是怀疑自己脚本统计错了,把每个 hook 的 SEL 地址 + Class 地址对都列出来比对,确实是同样的序列出现两次,只是注册函数名不同(sub_1BB50 和 sub_118D4),代码体也几乎一样(1500 字节 vs 1412 字节,差异主要来自 OLLVM 复制时的 MBA 重写)。原因猜测有几个:

```dyld load 时序保险 —— 一个 image 还没加载到时,另一份兜底先注册
ObjC swizzling 在 `+load` 早晚两个时机各执行一次
反卸载机制 —— 即使别人写脚本 unhook 一份,另一份依然在
不同wx版本兼容 —— 一份对 8.0.30,另一份对 8.0.40,运行时根据版本选
```
我觉得可能是于第 3 个

## 9. 167 hook 完整关联:从二进制反扫到作战图

到这一步素材都齐了:66 个明文字符串、167 个 hook 注册 site。剩下要做的是把每个 hook 的 SEL/Class 跟明文对应起来。这一步是把"散落的零件"装回"整机":字符串告诉你 dylib 想 hook 什么,注册 site 告诉你它在哪里 hook,两者一对应就是完整的攻击地图。

每个 hook 注册 site 长这样:

```asm
; 大约在每个 hook 注册前 40 条指令内,会有这两条 ADRP+ADD 拼字符串地址
ADRP X0, #class_name_addr@PAGE
ADD  X0, X0, #class_name_addr@PAGEOFF   ; X0 = ObjC class name 地址
...
ADRP X1, #sel_name_addr@PAGE
ADD  X1, X1, #sel_name_addr@PAGEOFF      ; X1 = SEL 字符串地址
...
BL   _MSHookMessageEx                    ; (实际是 LDR + BR 间接调用)
```

`_MSHookMessageEx` 的标准签名是 `void MSHookMessageEx(Class cls, SEL sel, IMP newImp, IMP *origImp)` —— 第一个参数是目标类,第二个是 selector,第三个是替换实现,第四个是用来回填原 IMP 指针的输出参数。所以 hook site 之前的 ADRP+ADD 序列里,前两组拼字符串地址(class name 和 sel name)被传给 `_objc_getClass` 和 `_sel_registerName`,把字符串转成运行时对象再喂给 `MSHookMessageEx`。这是 Substrate tweak 的标准动态注册流程,结构稳定。

分两步走:**step6 先把 167 个 hook 注册 site 的原始信息抽出来**(每个 site 是哪个 ObjC class、SEL、newImp、origImp 槽地址),**step25 再把这些地址跟 step17/19 解出的明文表对应起来**。

step6 的核心思路是:对每个 hook 注册函数(sub_1BB50 / sub_118D4 / sub_1C12C / sub_12114 / sub_16504),线性扫一遍找所有 `BL _MSHookMessageEx` 调用,然后对每个调用反扫前 25 条指令找 ADRL 的目标。SEL 的识别不是直接看 `BL _MSHookMessageEx` 之前的 ADRL,而是先找 `BL _sel_registerName`,再看它前面紧跟的 ADRL X0 —— 这是稳定的 ObjC 动态注册模式:

```python
# cff_step6_extract_hooks.py: 从 5 个注册函数提取 167 hook 三元组
def extract_hooks_from_func(fn_ea):
    insns = list(decode_function(fn_ea))   # [(ea, mnem, ops, op_vals), ...]
    hooks = []

# 1) 找所有 BL _MSHookMessageEx 或它的 thunk(0x38xxx 范围)
    hook_calls = []
    for i, (ea, mn, ops, ovs) in enumerate(insns):
        if mn != "BL":
            continue
        target = ovs[0]
        target_name = idc.get_name(target) or ""
        if "_MSHookMessageEx" in target_name or 0x38000 <= target < 0x39000:
            hook_calls.append((i, ea))

# 2) 对每个 hook call 反扫前 25 条
    for call_idx, call_ea in hook_calls:
        sel_str = class_str = newImp = origImp = None

for j in range(call_idx - 1, max(call_idx - 25, -1), -1):
            ea_j, mn_j, ops_j, ovs_j = insns[j]

if mn_j == "ADRL":
                dst = ops_j[0].strip()
                tgt = ovs_j[1]
                # ADRL X2/X3 一般是 newImp / origImp 槽
                if dst == "X2" and newImp is None:
                    newImp = tgt
                elif dst == "X3" and origImp is None:
                    origImp = tgt

elif mn_j == "BL":
                tname = idc.get_name(ovs_j[0]) or ""
                # _sel_registerName 之前的 ADRL X0 是 SEL 字符串地址
                if "_sel_registerName" in tname and sel_str is None:
                    if j > 0 and insns[j-1][1] == "ADRL":
                        sel_str = read_cstring(insns[j-1][3].Op2.value)
                # _objc_getClass 之前的 ADRL X0 是 Class 字符串地址
                elif "_objc_getClass" in tname and class_str is None:
                    if j > 0 and insns[j-1][1] == "ADRL":
                        class_str = read_cstring(insns[j-1][3].Op2.value)

hooks.append({
            "site": call_ea, "class": class_str, "sel": sel_str,
            "newImp": newImp, "origImp_slot": origImp,
        })
    return hooks

all_hooks = []
for fn_ea in [0x1BB50, 0x118D4, 0x1C12C, 0x12114, 0x16504]:
    all_hooks.extend(extract_hooks_from_func(fn_ea))
# 跑完: 167 个 hook 三元组
```

25 条指令的回扫窗口是经验值。一开始我用 15,漏掉了被 OLLVM 拉远的 ADRL 对;后来用 50,又把上一个 hook 的字符串引用也扫进来了。25 是覆盖整个 hook 注册块、不污染前一个 hook 的折衷值。

step6 跑完拿到的 `class_str` / `sel_str` 此时还可能是密文 —— 如果字符串区当时还没解密,`read_cstring` 读出来的就是高熵 binary。所以真正能拿到明文 hook 列表必须等到 step17/19 把字符串解密完之后,再跑 step25 做关联:

```python
# cff_step25_join_hooks_strings.py: hook site 跟明文字符串表对应
import json, idc, idautils

# 已解密的字符串表: [{"addr": 0x40DDF, "plaintext": "MMTokenService", "length": 14}, ...]
plaintext_table = json.load(open("data/all_decrypted_strings.json"))

def lookup_str(addr):
    """addr 落在某个明文字符串内则返回该串, 支持中段命中(指针落在串中间)"""
    for s in plaintext_table:
        if s["addr"] <= addr < s["addr"] + s["length"] + 1:
            return s, addr - s["addr"]
    return None, 0

def find_str_refs(site_ea, lookback=40):
    """从 hook site 反扫前 40 条指令, 收集所有落在密文区的 ADRP+ADD 拼出地址"""
    refs = []
    ea = site_ea
    for _ in range(lookback):
        ea = idc.prev_head(ea)

# 1) IDA dref(ADRP+ADD 数据流分析能拼出的地址)
        for dref in idautils.DataRefsFrom(ea):
            if 0x40000 <= dref < 0x42500:
                refs.append(dref)

# 2) 手动 ADRP+ADD 配对(IDA 偶尔识别不全, 兜底)
        if idc.print_insn_mnem(ea) == "ADRP":
            base = idc.get_operand_value(ea, 1)
            nx   = idc.next_head(ea)
            if idc.print_insn_mnem(nx) == "ADD":
                offs   = idc.get_operand_value(nx, 2)
                target = base + offs
                if 0x40000 <= target < 0x42500:
                    refs.append(target)
    return refs

# 主流程
results = []
for h in all_hooks:
    refs = find_str_refs(int(h["site"], 16))
    str_refs = []
    for addr in set(refs):
        s, off = lookup_str(addr)
        if s:
            str_refs.append({"plaintext": s["plaintext"], "offset": off})
        else:
            # 未解密的, 直接读密文 hex 留作后续审计
            cipher = bytes(idc.get_wide_byte(addr+k) for k in range(64))
            cipher = cipher[:cipher.index(0)] if 0 in cipher else cipher
            str_refs.append({"cipher_hex": cipher.hex()})
    results.append({"site": h["site"], "refs": str_refs})

# 跑完: 164/167 拿到 ≥ 2 个 string ref(SEL+Class 完整对)
```

这一步有两个细节。第一个是 `find_str_refs` 同时用 `idautils.DataRefsFrom`(IDA dref)和手动 ADRP+ADD 配对兜底 —— 单靠 dref 在某些 OLLVM 拉远的指令对上识别不全,加手动配对能覆盖剩下的 5%。第二个是 `lookup_str` 支持"中段命中" —— ADRP+ADD 拼出来的不一定是字符串起点,可能是字符串中段某个字符的位置(比如 `"reportCrashLog:type:"` 的 `t` 字符位置),这种情况要根据 offset 推回完整字符串。如果不支持中段命中,这一步会少匹配 20% 左右的 hook。这是我跑第一版的时候发现的:有 30 多个 hook 的 SEL/Class 都"找不到",debug 了半天才发现 ADRP+ADD 拼出的是字符串中段地址。

跑完结果:

164 / 167 拿到了 SEL+Class 完整对,3 个只拿到一个引用 —— 这 3 个特殊的可能是 `class_addMethod` 而不是 `MSHookMessageEx`,后者只需要 Class 不需要现成 SEL。覆盖率到 98% 已经够用,后续业务理解不会因为差这 3 个出现盲点。

未解的部分主要是 `sub_2E5E8` 那个栈指针变种解密器没破完,涉及 96 字节 cipher 找不到地址来源。这 96 字节的字符串大概率是"次要"的辅助类名(因为 sub_2E5E8 写的位置在 dylib 头部,通常装的是基础类元数据),不影响核心 hook 表的可读性。

最终关联结果按业务分类整理:

**反作弊核心类(xx侧)**

```
MMRuntimeIntegrity        — 运行时完整性
MMSecurityPolicyValidator — 安全策略验证器
MMAntiTamperGuard         — 反篡改保护
MMTokenService            — Token 服务(风控核心)
MMClientCacheManager      — 客户端缓存管理
MMContext                 — wx全局 Context
ExptService               — A/B 实验服务
CUtility                  — 工具类
```

这 8 个类基本上是xx iOS 端反作弊架构的"骨架"。`MMRuntimeIntegrity` 负责"我现在跑在什么环境里"(越狱、调试器、注入),`MMSecurityPolicyValidator` 负责"我自己有没有被改"(签名、证书),`MMAntiTamperGuard` 负责持续监控运行时状态,`MMTokenService` 负责跟服务器通信(身份令牌、安全事件上报),`MMContext` 是全局上下文,`ExptService` 是 A/B 配置层,`MMClientCacheManager` 管缓存(里面会有运行时状态字典),`CUtility` 是工具集合。一份反封号 dylib 的 hook 列表里出现这 8 个类,等于把xx反作弊的 6 个层次全打了 —— 没有任何一个层次幸存。

**被 hook 的关键 SEL**

```
isJailbrokenDevice                      → NO
isEnvironmentTrusted                    → YES
auditLoadedImages                       → 跳过(过滤掉 MobileSubstrate 路径)
verifyCodeSignature:                    → YES
validateCertChain:depth:                → trusted
getAppBundleSignatureHash               → 原版预期值
getAppSignType                          → 原版类型
flushSecurityEvents                     → return (nullify)
reportCrashLog:type:                    → return 0 (nullsub_1)
reportDeviceToken:                      → return (nullify)
refreshTokenWithPolicy:                 → return (nullify)
getStringExpt:                          → 劫持
getBoolExpt:                            → 劫持
startVerifyContact:opcode:verifyMsg:    → 加好友核心动作(改参数)
sendVerifyUserRequest:                  → 加好友请求
checkConfig                             → 配置劫持
startMonitoring                         → no-op
refreshPolicyStore                      → no-op
```

`auditLoadedImages` 这个名字一看就知道是"扫一遍 dyld 已加载的所有 image,看有没有 MobileSubstrate / Cydia / Theos 这种越狱痕迹"。dylib 把它 hook 成"过滤掉自己" —— 调用时返回 image 列表,但去掉了 dylib 自己和 Substrate 的相关条目。这是一个有意思的细节:**作者没有简单粗暴地让 `auditLoadedImages` 返回空,而是返回一个"过滤后的真实列表"**,因为返回空会立即触发风控("没有任何 dylib 加载?这设备不正常"),而返回过滤后的真实列表,在统计模式上跟正常用户完全吻合。

`startVerifyContact:opcode:verifyMsg:` 是项目命名 "JiDe(防加好友被封)" 的来源 —— 这是xx加好友请求的核心方法。被 hook 之后,作者可能在 `verifyMsg` 参数里塞特殊话术降低对方举报概率,可能在 `opcode` 上做模式调整避开"批量加好友"的特征,可能在调用频率上做节流。具体怎么改要看 newImp 的实现,这部分静态看不全。

**A/B 配置 key(劫持目标)**

```
clicfg_gogwcs_ios_runtime_sdk_dc_dc_report_enable           → NO
clicfg_gogwcs_ios_runtime_sdk_main_cert_chain_report        → NO
cert_valid                                                  → 写入 YES
env_abnormal                                                → 写入 NO
jb_indicator                                                → removeObjectForKey:
```

`clicfg_gogwcs_ios_runtime_sdk_*` 这套 key 是xx ConfigManager 的命名规范,`clicfg` 是"client config","gogwcs" 看起来是某个内部团队代号,"ios_runtime_sdk" 表明这是 iOS 客户端的运行时安全 SDK。这两个 key 一旦被 hook 返回 NO,**整套上报链路从源头就被关闭** —— 比 nullify 拦截更优雅。`cert_valid` / `env_abnormal` / `jb_indicator` 是状态字典 key,dylib 直接改字典,把客户端"自己记录的状态"擦掉,让微信下次自查时看到的是"一切正常"。

落盘到 `data/`:

```
data/hooks_extracted.json        39  KB    167 个 hook 注册 site 原始信息
                                           (class/sel 还可能是密文地址)
data/all_hooks_decrypted.csv     63  KB    167 hook 完整关联表
                                           (site, newImp, Class, SEL, all_refs)
data/all_hooks_decrypted.json    283 KB    同上 JSON,带详细 refs 链
data/nullify_hooks.csv           1.1 KB    9 个 nullify hook 三元组
data/newimp_classification.csv   1.8 KB    38 个 newImp 分类
```

`nullify_hooks.csv` 单独拎出来是因为这 9 个 hook 是反封号的"攻击核心"。表格长这样:

```
reg_func    site       newImp     newImp_kind   sel_addr   class_addr
0x1bb50     0x1be44    0x29e34    nullsub_1     0x4092E    0x40944
0x1bb50     0x1be50    0x29e34    nullsub_1     0x4092E    0x40944
0x1bb50     0x1be60    0x29e34    nullsub_1     0x4092E    0x40910
0x118d4     0x11b88    0x29e34    nullsub_1     0x40A30    0x4092E (via wrapper)
0x118d4     0x11b94    0x29e34    nullsub_1     0x40A30    0x4092E (via wrapper)
0x118d4     0x11ba4    0x29e34    nullsub_1     0x40A30    0x40910 (via wrapper)
0x1c12c     0x1c248    0x32250    return_0      0x40590    0x40970 (via wrapper)
0x1c12c     0x1c254    0x32250    return_0      0x40590    0x40970 (via wrapper)
0x1c12c     0x1c264    0x32250    return_0      0x40590    0x40DDF
```

`0x40590` 我们已经解出来是 `reportCrashLog:type:`,被替换成 `0x32250 (return_0)`(汇编层面就是 `MOV X0, #0; RET`)—— 任何代码调它都直接返回 0。`nullsub_1` 在 `0x29e34` 是个空函数,只有 `RET` 一条指令。这 9 个 hook 是**反封号的"攻击靶心"**,其余 158 个 hook 都是为了让这 9 个 nullify 不被检测到而做的"伪装层"(透明 forward + 状态字典擦除 + A/B 配置劫持)。

`newimp_classification.csv` 把所有 hook 用到的 38 个独立 newImp 分了类:

```
addr       name       kind       last_insn  说明
0x29e34    nullsub_1  REAL_FUNC  RET        ★ 真函数: 空操作
0x32250    sub_32250  REAL_FUNC  RET        ★ 真函数: return 0
0x1c2f0    sub_1C2F0  BDD_NODE   BR X2      末尾 BR, 还在 BDD 里
0x1df6c    sub_1DF6C  BDD_NODE   BR X11     末尾 BR
0x20750    sub_20750  BDD_NODE   BR X9
0x21e70    sub_21E70  BDD_NODE   BR X15
0x22138    sub_22138  BDD_NODE   BR X8
... 其余 31 个 newImp 全部 BDD_NODE (末尾 BR Xn)
```

**38 个 newImp 里只有 2 个是 RET 结尾的真函数,其余 36 个末尾都是 `BR Xn` —— 还在 BDD 里继续 dispatch**。这意味着大多数 hook 的"替换实现"不是写死的逻辑,而是另一棵 BDD 子树,根据状态再次分发。具体的参数改写、返回值伪造逻辑藏在 BDD 的更深层,静态看不到全貌,要看完整还得动态调试。这是这个 dylib 静态分析的"最后一公里"短板 —— hook 列表全有了,但 hook 替换的内部行为还要靠运行时观察。这不是我们今天的重点。

## 10. SHA-256("")

`sub_33CE8` 解出来 7 字节明文:`e3b0c44`,在地址 0x41BA0。
`sub_33A24` 解出来 22 字节明文:`298fc1c149afbf4c8996fb`,在地址 0x41BA7。

两段相邻地址。拼起来:

```
0x41BA0:  e3b0c44298fc1c149afbf4c8996fb     (29 字节)
```

这 29 字节是什么?第一眼看到的时候我没认出来,以为是某种 token 或者 nonce。我把它拷到 grep 里跟所有解出来的字符串比对,没匹配上;放到 Google 搜了一下,瞬间明白了 —— **这是 SHA-256("") 的前 29 字符**。完整 SHA-256 空字符串值是:

```
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
```

我们解出来的 29 字符正好是它的前缀。剩下的 35 字符大概率在另一个还没解的小 master 里(后续把 `sub_3514C`、`sub_33904` 等 W 较小的 master 跑完之后,完整 64 字符就拼齐了)。

这个字符串在 dylib 里被解密出来,只有一个用途 —— **当xx调用 `integrityHash` getter 时,dylib hook 这个 getter,直接返回这个 SHA-256("") 伪值**。不计算真 hash,不读取真数据,直接糊弄过去。

**xx可能只检查"返回值是 64 字符的 hex 串"(格式校验),没有做 `hash(actual_data) == reported_hash` 的双向绑定**。客户端的代码大致长这样:

```objc
- (NSString *)integrityHash {
    NSData *binary_data = [self loadBinaryForCurrentBundle];
    return [self sha256Hex:binary_data];
}

- (BOOL)isIntegrityValid {
    NSString *hash = [self integrityHash];
    return [self isValidHexString:hash length:64];
    // ★ 服务端只验证 hash 格式,没拿到 binary_data 自己算一遍对比
}
```

dylib 替换 `integrityHash` getter,让它直接返回 `e3b0c44...b855`,绕过整个 SHA-256 计算。微信看到的是"一个 64 字符 hex 串",符合格式,通过校验。但**这个 hash 跟实际二进制内容没有任何关系**。

一句话总结:**任何 hash 校验如果不绑定数据,等于摆设**。客户端自己算自己上报,服务端只看格式不看内容,逻辑上等于零防护。

为什么作者偏偏选 `SHA-256("")` 而不是别的伪值?有几个理由我觉得可能:

1. **它是常量,可以硬编码进 dylib**,不需要每次运行时计算
2. **它是个真实存在的合法 SHA-256 输出**,如果服务端有"是否落在合法 hash 值域"的弱校验,这个值能过
3. **它"看起来很正常"** —— 一串纯 hex,任何启发式检测都看不出异常
4. SHA-256 空串的值在密码学社区是"老朋友",几乎所有 hash 库的单元测试都用它做参考,熟悉它的人会有亲切感(对作者来说也是"不容易出错的备用值")

这种"格式校验"的反模式在很多场景都见过。客户端上报的设备指纹只校验格式不校验内容、客户端上报的崩溃栈只校验栈帧格式不验签名、客户端上报的位置只校验经纬度范围合法不验跟历史轨迹的连续性。每一个都是潜在的反作弊薄弱点。**如果你的反作弊架构里有任何"客户端自报 + 服务端只看格式"的环节,这个环节就是 SHA-256("") 等级的漏洞,只是还没被人捅出来**。

## 11. 死角:sub_2E5E8 栈指针变种

最后讲一下静态分析的天花板。

`sub_2E5E8` 是个解密器,但它的写入方式跟其他 master 完全不同。看签名:

```c
__int64 __fastcall sub_2E5E8(int a1, _BYTE *a2, _BYTE *a3, _BYTE *a4, _BYTE *a5);
```

5 个参数,后 4 个是 BYTE 指针。函数体内还额外用了 6 个未在签名里的指针寄存器(X11/X12/X13/X14/X15/X16),通过寄存器从外面传进来。

这种"超出 ABI 标准的寄存器传参"在编译器优化里偶尔会见到(`__attribute__((regparm))` 或者内部自定义 calling convention),但混淆里这么用就比较少。它依赖一个事实:caller 和 callee 之间的"约定"完全是私有的,不需要符合 ARM64 标准 ABI(标准 ABI 只用 X0-X7 传参,X8 用于结构体返回)。这种私有约定一旦被作者掌控,就可以让 IDA 的反编译完全摸不着头脑。

这 10 个指针总共构成 5 对 source→dest 段:

```
X11 → X12 (v5/v6)    18 字节
X13 → X14 (v7/v8)    19 字节
X15 → X16 (v9/v10)   16 字节
X1  → X2  (a2/a3)    26 字节   ← 函数签名传入
X3  → X4  (a4/a5)    17 字节   ← 函数签名传入
小计指针段                       96 字节   ★ IDA dref 看不到!
```

外加两段直接 ADRL 加载的可见段:

```
ADRL byte_41961 → byte_4196A   3 字节  ★ 静态可解
ADRL byte_41A53 → byte_41A5C   9 字节  ★ 静态可解
```

可见的 12 字节解出来是 `NSN` + `umber\0` 拼出 `NSNumber\0`。

剩下 96 字节卡死了。原因是 caller 通过 `BR` 间接跳进 `sub_2E5E8`,IDA 的 xref 看不到调用者。caller 在 BR 之前怎么设置 X11/X13/X15 的值,涉及 ADRP+ADD+ADD 链或者从 struct 字段加载,需要逐 caller 推断 —— 但 caller 是谁,我们都不知道(因为 BR 间接跳)。

我也尝试过反向 brute force:遍历所有 BDD 节点,看哪些节点末尾的 `BR Xn` 之前有装载到 X11/X13/X15 的指令对。跑了一晚上没出结果,因为这些寄存器在 BDD 主链上几乎每个 trampoline 都被覆盖一次,无法静态地知道某个特定 caller 在 jump 前设了什么值。要确定就得做完整的符号执行,从 sub_4000 入口开始模拟 BDD 的执行,跟踪所有寄存器状态 —— 这是另一个层级的工程量,做完那个 PoC 我估计还得一周,而且不一定能跑通。
这是 OLLVM CFF + MBA 之外的另一种反静态手段:**寄存器混淆**。让关键常量不出现在指令立即数里,而是从某个寄存器传进来,**这个寄存器在更早的某个调用方设置**,IDA 的数据流分析需要"地址常量作为指令立即数"才能起作用,寄存器传递的常量它推不动。

值得一说的是,**这种混淆比 OLLVM CFF + MBA 都更狠**。代码混淆(CFF + MBA)对付的是"理解",但代数学一拳打回原形;寄存器混淆对付的是"信息可达性" —— 你看到 `LDR Xn, [X11]`,你知道是从某个地址 load,但你**根本不知道 X11 是什么** —— 它从外部寄存器传进来,而外部又来自更外部。要破得跑模拟,跑模拟需要完整 CFG,完整 CFG 已经被前面的 CFF 砍碎。**层层嵌套之后,静态分析就是不行**。

如果有越狱设备 + frida,破这个 30 秒搞定:hook `sub_2E5E8` 入口,dump 5 个源指针的值,96 字节 cipher 全部跑出来。Frida 脚本大概 10 行就够:

```javascript
Interceptor.attach(Module.findBaseAddress("JiDe.dylib").add(0x2E5E8), {
    onEnter(args) {
        // ARM64 standard: a2=X1, a3=X2, a4=X3, a5=X4
        // 加上自定义 X11/X13/X15
        const x11 = this.context.x11;
        const x13 = this.context.x13;
        const x15 = this.context.x15;
        console.log("X11:", hexdump(x11, {length: 32}));
        console.log("X13:", hexdump(x13, {length: 32}));
        console.log("X15:", hexdump(x15, {length: 32}));
        // ... a2-a5 同理
    }
});
```

但本样本无越狱设备无 frida,这 96 字节是静态分析的硬边界。

dylib 的整体反封号机制理解已经 95%+ 完整,缺失的 96 字节大概率是辅助类名/方法签名(因为 master 的写入位置在 dylib 头部,通常装的是基础类元数据),不影响核心策略推断。

## 12. 最终的反封号机制全图

所有材料拼起来,这个 dylib 的反封号攻击对应xx的 6 层防御,每一层都布了对口攻击点:

```
xx反作弊的 6 层防御                  dylib 的 6 层攻击
───────────────────────────────────────────────────────────
① 环境信任检测                         让所有"是否越狱/被注入"返回 NO
   MMRuntimeIntegrity                   isJailbrokenDevice → NO
                                        isEnvironmentTrusted → YES
                                        auditLoadedImages → 跳过

② 签名 / 完整性校验                    让所有"签名/Hash 校验"返回通过
   MMSecurityPolicyValidator            verifyCodeSignature: → YES
   CUtility                             validateCertChain: → trusted
                                        getAppBundleSignatureHash → 原版值
                                        integrityHash → SHA-256("") 伪值

③ 反篡改监控                           让监控功能空转
   MMAntiTamperGuard                    startMonitoring → no-op
                                        refreshPolicyStore → no-op

④ 事件上报通道                         让所有"风险事件上报"无声失败
   MMTokenService                       flushSecurityEvents → return
                                        reportCrashLog:type: → nullsub_1
                                        reportDeviceToken: → return
                                        refreshTokenWithPolicy: → return

⑤ A/B 配置开关(★ 最优雅)             从源头让微信"自己决定"不上报
   ExptService                          getBoolExpt:(@"clicfg_*_dc_dc_report")
                                        → NO,根本不调用 ④

⑥ 状态字典 + 核心动作                  擦除已检出痕迹 + 改加好友参数
   NSDictionary 状态                    removeObjectForKey:(@"jb_indicator")
   MMContext                            startVerifyContact:opcode: → 改参数
```

6 层防御对应 6 层攻击,每一道防线都被对应攻击瓦解 —— 这是反封号工具的"完美对账"。看到这种完美对账的瞬间我意识到一件事:作者大概率不是黑盒摸索出来的,是有内部知识。xx反作弊架构的 6 层切分如果只靠逆向多版本对比,理论上可能,但工作量极大;一对一的精确对应更可能是"作者拿到了某种内部架构信息"(同行流转、内部文档泄露、或者作者本身参与过相关项目的逆向)。

里面第 ⑤ 层的设计最值得一说。有意思

直觉的做法是 ④:hook 上报函数本身,让它静默。但作者额外做了 ⑤:hook A/B 配置,让上层 if 直接走 false 分支。为什么要冗余两层?

只 nullify ④ 的代价:

xx代码里 if ([MMRuntimeIntegrity isEnvironmentTrusted] == NO) { [self flushSecurityEvents]; } 这种调用链,nullify 拦不住 if 之前的检测,服务端可以从其他接口反查"环境检测是否触发"

nullify 后调用栈依然能查到 flushSecurityEvents 符号存在

时序探测可以发现:正常应该耗时 50ms 的上报变成 0ms

调用次数统计可以发现:正常应该每天调用几十次的函数,这个客户端从来不调

hook ⑤ 的优势:让微信自己决定不调用上报。客户端代码路径 100% 走"不需要上报"分支,调用栈干净,寄存器状态、函数耗时都"看起来"是合规客户端,服务端没有任何"客户端被 hook"的反向指纹。

更微妙的是 ④ 跟 ⑤ 的冗余配合。如果只 hook ⑤ 不 hook ④,极端情况下 A/B 配置可能被服务端覆盖(微信下发新配置强制开启 clicfg_*_dc_dc_report_enable = YES),这时候上层 if 又会调进 ④,如果 ④ 没 hook 就漏掉一次上报。两层都 hook,无论 A/B 配置怎么变,上报永远到不了服务器。这是工程上的纵深防御思维,作者不是单点打洞,而是布多层防线。

clicfg_gogwcs_ios_runtime_sdk_dc_dc_report_enable 这个 key 一旦曝光,等于把"功能开关图谱"递给了对手。这也是为什么所有重要安全开关绝对不能放在 A/B 远程配置里,必须服务端硬编码逻辑。

## 15. 没做完的事
**36 个 BDD 包装的 newImp 内部参数改写细节**。我只确认了 SEL/Class 对应关系,具体 hook 替换函数里怎么改 `startVerifyContact:opcode:verifyMsg:` 的参数还没深入。比如加好友请求里的 `verifyMsg` 字段,作者可能塞了模板话术(规避微信对"陌生话术"的检测)、可能根据上下文动态生成、可能从远程下发;这些细节得动态调试看实际运行时数据。这部分静态分析能给出的信息有限,主要是因为 newImp 本身也是 BDD 节点(36/38 个 newImp 末尾是 `BR Xn` 不是 `RET`),里面的逻辑分散在 BDD 链路上,不在单个函数里。
**sub_2E5E8 的 96 字节静态死角**。无越狱设备无 frida 的硬边界。这部分大概率是辅助类元数据(`NSDictionary`、`NSMutableArray` 这种基础类名,以及它们的若干 selector 后缀),不影响核心反封号策略推断 —— 但要是真想做完整的复盘,这 96 字节是必须补上的。后续如果有机会拿到越狱测试机,30 秒搞定。
**sub_F584 这第二个 dyld init 函数没深挖**。`__init_offsets` 段里有两个入口,sub_4000 是主入口(0xE00 大栈帧那个),sub_F584 是第二个,大约 1296 字节,结构跟 sub_4000 类似(也在栈上构建 mini-table)。它的 BDD 入口不同,可能挂载的是另一组 hook,也可能是某种 fallback。我反编译过它的 prologue 跟 sub_4000 几乎一样,但没把它的 BDD 完整跑一遍。
**sub_B50C 这个 dyld_register_func_for_add_image 回调的语义**。1740 字节,在栈上构建巨型表,既是 dyld 回调又是 BDD 节点。它的真正用途是"等微信主二进制加载完之后再触发某些 hook",这是 Substrate tweak 的标准延迟 hook 模式。我确认了它的入口结构,把它构建的指针表 `off_47358` 落盘到 `data/off_47358_table.csv`,头部几行长这样:
```
xxxxxxxxxx
table_index  table_offset  func_addr  func_name   is_shared_subexpr
0            0x47358       0xbbd8     sub_BBD8    False
1            0x47360       0xbbdc     loc_BBDC    False
2            0x47368       0xbc3c     sub_BC3C    False
3            0x47370       0xbbdc     loc_BBDC    True   ← 重复!
4            0x47378       0xbc8c     sub_BC8C    False
5            0x47380       0xbc8c     sub_BC8C    True   ← 重复!
6            0x47388       0xbce4     sub_BCE4    False
7            0x47390       0xbc8c     sub_BC8C    True   ← 重复!
8            0x47398       0xbd44     loc_BD44    False
9            0x473a0       0xbd44     loc_BD44    True   ← 重复!
10           0x473a8       0xbd44     loc_BD44    True   ← 重复!
... 
```
`is_shared_subexpr=True` 的条目就是 ROBDD 的共享子表达式 —— 同一个判断节点被多个上游路径复用,不需要重新算一遍。这跟主 BDD(sub_4000 的尾调用链)是两套独立机制,但风格一致,都是 OBDD 优化。我确认了它的结构但没深挖它跟 sub_4000/sub_F584 的协作关系,以及它内部的 BDD 出口最终跳到哪些 newImp。

## 16. 数据交付

完整数据落在在附件，样本估计搞不出来了。这里汇总一下完整目录结构:

```
lib/                                        总 19 个脚本, ~3000 行
├── cff_step1_x20map.py             2.3 KB  X20 偏移映射重建
├── cff_step2_scan_trampolines.py   6.0 KB  trampoline 三元组提取
├── cff_step3_v3_full_descriptor.py 7.2 KB  完整描述符 (CSET 谓词 + 栈槽)
├── cff_step4_unflatten.py          6.2 KB  BDD 反扁平化
├── cff_step5_subF584_probe.py      4.1 KB  第二个 dyld init 探测
├── cff_step6_extract_hooks.py      5.9 KB  hook 注册函数提取
├── cff_step7_substrate_analyze.py  4.5 KB  Substrate 框架识别
├── cff_step8_substrate_callers.py  3.0 KB  thunk 反向 caller 追踪
├── cff_step9_globals_probe.py      2.5 KB  全局变量探测
├── cff_step10_classify_newimps.py  2.0 KB  newImp BDD/真函数分类
├── cff_step11_nullify_callers.py   2.0 KB  nullify hook 识别
├── cff_step12-16_find_dec*.py             dref 扫描找 master(5 版迭代)
├── cff_step17_apply_dec_168C4.py  11.6 KB  第一版手工 lambda 列表
├── cff_step18_export_all.py        27 KB   批量导出聚合
├── cff_step19_parse_decomp_to_schedule.py  3.5 KB  通用 8-MBA parser
├── cff_step20-23_run_*.py                  批量跑 16 个 master
├── cff_step24_merge_all_strings.py 5.1 KB  字符串合并去重
├── cff_step25_join_hooks_strings.py 5.7 KB hook 跟字符串关联
└── cff_step26_run_2E5E8_adrl.py            sub_2E5E8 静态可见部分

data/
├── x20_map.json                    5.2 KB   202 条 X20 偏移 → mini-table
├── trampolines.json                67  KB   223 个完整描述符
├── trampolines_compact.json        31  KB   紧凑版(int 而非 hex 字符串)
├── errors.json                     335 B    0 错误占位 (审计用)
├── edges.csv                       17  KB   446 条 BDD 边
├── cff_bdd.dot                     33  KB   GraphViz dot 文件
├── unflatten_summary.json          2.4 KB   74 入口 / 53 出口 / 149 内部
├── unflattened_bdd.txt             4.7 MB   反扁平化 if-else 树
├── decryptor_candidates.csv        1.2 KB   15 个解密器候选
├── master_decryptors.csv           348 B    17 个 master(含 5 对孪生)
├── dec_168C4_schedule.csv          12  KB   sub_168C4 121 行解密 schedule
├── dec_168C4_schedule.json         33  KB   同上 JSON
├── dec_summary.json                2.2 KB   解密总体摘要
├── decrypted_strings.csv           1.4 KB   第一批 9 段明文 (sub_168C4)
├── all_decrypted_strings.csv       4.4 KB   ★ 66 个独立明文 / 981 字节
├── all_decrypted_strings.json      10  KB   同上 JSON
├── off_47358_table.csv             1.1 KB   sub_B50C OBDD 共享子表达式表
├── off_47358_table.json            4.7 KB   同上 JSON
├── globals_probe.json              1.9 KB   MBA seed keys + atomic flags
├── hooks_extracted.json            39  KB   167 hook 注册 site 原始信息
├── all_hooks_decrypted.csv         63  KB   ★ 167 hook 完整关联表
├── all_hooks_decrypted.json        283 KB   同上 JSON, 带详细 refs 链
├── nullify_hooks.csv               1.1 KB   ★ 9 个 nullify hook
├── nullify_hooks.json              2.3 KB   同上 JSON
└── newimp_classification.csv       1.8 KB   ★ 38 newImp 分类 (36 BDD + 2 真函数)
```

回复或点赞可查看完整内容

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

上传的附件：

data.zip （260.15kb，81次下载）

收藏・35

点赞・177

打赏

赞赏记录

参与人

雪币

留言

时间

mb_jcawcirk

你的分享对大家帮助很大，非常感谢！

9小时前

tuosen

谢谢你的细致分析，受益匪浅！

16小时前

mb_dvqqrcce

期待更多优质内容的分享，论坛有你更精彩！

2026-9-11 17:20

铭信

你的帖子非常有用，感谢分享！

2026-9-7 21:56

taeyeon_ss

感谢你分享这么好的资源！

2026-9-4 11:13

Itachi_

谢谢你的细致分析，受益匪浅！

2026-8-31 09:21

上网鱼

这个讨论对我很有帮助，谢谢！

2026-8-23 11:15

Freax

为你点赞！

2026-8-21 10:59

咪咪3

你的分享对大家帮助很大，非常感谢！

2026-8-21 02:31

mb_nlwqhnpi

感谢你分享这么好的资源！

2026-8-20 20:08

mb_lthgjpwj

为你点赞！

2026-8-20 16:59

渐渐72

期待更多优质内容的分享，论坛有你更精彩！

2026-8-18 22:49

xdcs100

非常支持你的观点！

2026-8-18 15:14

mb_cebxltxx

为你点赞！

2026-8-16 13:53

git_672002024028070-byte

为你点赞！

2026-8-15 11:09

mb_maskqnda

你的帖子非常有用，感谢分享！

2026-8-13 22:30

墨穹呢

这个讨论对我很有帮助，谢谢！

2026-8-12 15:45

小李08

你的帖子非常有用，感谢分享！

2026-8-12 14:05

Red

非常支持你的观点！

2026-8-11 09:04

Palonsong

为你点赞！

2026-8-10 22:33

聂风云

非常支持你的观点！

2026-8-10 21:09

New对象处

这个讨论对我很有帮助，谢谢！

2026-8-10 16:18

mb_risvwqwz

感谢你的贡献，论坛因你而更加精彩！

2026-8-10 15:34

A_Coder

你的帖子非常有用，感谢分享！

2026-8-10 10:25

git_23972yekings9999

非常支持你的观点！

2026-8-8 20:06

4ak5ra

这个讨论对我很有帮助，谢谢！

2026-8-7 14:49

哈哥

为你点赞！

2026-8-6 13:58

Jackuu

期待更多优质内容的分享，论坛有你更精彩！

2026-7-31 14:55

学会规则

你的分享对大家帮助很大，非常感谢！

2026-7-29 17:56

MsScotch

非常支持你的观点！

2026-7-25 15:06

jiaxinZz

感谢你的贡献，论坛因你而更加精彩！

2026-7-23 14:34

hacker521

感谢你的贡献，论坛因你而更加精彩！

2026-7-15 18:06

ldljlzw

你的分享对大家帮助很大，非常感谢！

2026-6-26 16:32

a0yark

这个讨论对我很有帮助，谢谢！

2026-6-22 20:46

GhHei

你的分享对大家帮助很大，非常感谢！

2026-6-19 22:06

zhongdong

为你点赞！

2026-6-18 18:24

徽墨写代码

谢谢你的细致分析，受益匪浅！

2026-6-17 15:11

heiza

感谢你分享这么好的资源！

2026-6-17 00:38

看雪高研

为你点赞！

2026-6-16 16:14

Ms135

感谢你的积极参与，期待更多精彩内容！

2026-6-12 11:31

margina1

感谢你分享这么好的资源！

2026-6-10 14:27

neilwu

期待更多优质内容的分享，论坛有你更精彩！

2026-6-8 13:43

jeccylxyang

为你点赞！

2026-6-8 13:31

αβγδεξπ

感谢你的贡献，论坛因你而更加精彩！

2026-6-8 11:37

git_69042ahyun1101

非常支持你的观点！

2026-6-7 11:22

yuanyouran

这个讨论对我很有帮助，谢谢！

2026-6-5 15:53

会哭的鱼

你的帖子非常有用，感谢分享！

2026-6-4 03:23

g-yan

为你点赞！

2026-6-3 22:38

天流

谢谢你的细致分析，受益匪浅！

2026-6-3 19:25

祝今朝

感谢你分享这么好的资源！

2026-6-3 15:46

z221x

感谢你分享这么好的资源！

2026-6-2 11:44

she.

为你点赞！

2026-6-1 02:13

北门观雪

谢谢你的细致分析，受益匪浅！

2026-5-31 05:42

wx_来时路

为你点赞！

2026-5-31 00:21

mb_cyhkcaxo

感谢你分享这么好的资源！

2026-5-29 17:23

58582404

感谢你的贡献，论坛因你而更加精彩！

2026-5-27 22:39

wx_突突兔

你的分享对大家帮助很大，非常感谢！

2026-5-27 18:14

12321

感谢你的贡献，论坛因你而更加精彩！

2026-5-27 16:30

mb_upnpevqq

为你点赞！

2026-5-27 15:15

s1nec-1o

谢谢你的细致分析，受益匪浅！

2026-5-27 11:37

AGSFGBKILO

你的帖子非常有用，感谢分享！

2026-5-26 21:51

L0x1c

你的分享对大家帮助很大，非常感谢！

2026-5-26 16:11

china

感谢你分享这么好的资源！

2026-5-26 08:44

mb_djytmgxy

为你点赞！

2026-5-26 00:29

Liv_T

非常支持你的观点！

2026-5-25 16:45

mb_pnrjfxiv

你的帖子非常有用，感谢分享！

2026-5-25 16:19

海峰无敌

这个讨论对我很有帮助，谢谢！

2026-5-25 09:08

saykao

你的分享对大家帮助很大，非常感谢！

2026-5-23 04:58

不呲咔呲

这个讨论对我很有帮助，谢谢！

2026-5-22 18:29

扒饭海铃

这个讨论对我很有帮助，谢谢！

2026-5-22 17:25

穗之影

为你点赞！

2026-5-22 16:40

btmanbtman

非常支持你的观点！

2026-5-22 11:57

晨曦。

为你点赞！

2026-5-21 17:17

passself

你的帖子非常有用，感谢分享！

2026-5-21 16:06

git_49643SylvanasX

期待更多优质内容的分享，论坛有你更精彩！

2026-5-21 11:39

git_90326shiu129

为你点赞！

2026-5-21 10:48

mb_gatolgsc

为你点赞！

2026-5-20 02:21

带带弟弟吧

感谢你的贡献，论坛因你而更加精彩！

2026-5-19 12:50

kinglyu

感谢你分享这么好的资源！

2026-5-18 12:21

司空绝伦

为你点赞！

2026-5-18 10:23

wx_冰刃

为你点赞！

2026-5-18 09:01

Harpe

感谢你的贡献，论坛因你而更加精彩！

2026-5-15 23:58

心在o

这个讨论对我很有帮助，谢谢！

2026-5-14 09:33

wx_此人无名

感谢你的贡献，论坛因你而更加精彩！

2026-5-13 06:00

风兮木晓

为你点赞！

2026-5-12 20:03

mb_rrvlrvbk

感谢你分享这么好的资源！

2026-5-12 11:07

lanoche

这个讨论对我很有帮助，谢谢！

2026-5-11 19:31

hyz111

感谢你的贡献，论坛因你而更加精彩！

2026-5-11 10:44

mb_nofqtpir

你的帖子非常有用，感谢分享！

2026-5-11 10:18

只会逆一点点

你的分享对大家帮助很大，非常感谢！

2026-5-11 09:11

wx_官

期待更多优质内容的分享，论坛有你更精彩！

2026-5-9 10:34

耶巴蒂

期待更多优质内容的分享，论坛有你更精彩！

2026-5-8 16:23

SoulCat_

为你点赞！

2026-5-8 10:30

X66iaM

你的分享对大家帮助很大，非常感谢！

2026-5-8 10:06

mb_wdhsjycl

为你点赞！

2026-5-7 11:36

coderL

感谢你的贡献，论坛因你而更加精彩！

2026-5-6 15:38

aut0run

为你点赞！

2026-5-5 14:22

sssccc

你的帖子非常有用，感谢分享！

2026-5-3 23:42

PPKun

非常支持你的观点！

2026-5-3 14:45

zxhk

期待更多优质内容的分享，论坛有你更精彩！

2026-5-2 17:16

nonovo

感谢你分享这么好的资源！

2026-5-2 01:38

bfloat16

谢谢你的细致分析，受益匪浅！

2026-5-1 19:23

定清先生

这个讨论对我很有帮助，谢谢！

2026-5-1 18:14

doduhuang

感谢你的贡献，论坛因你而更加精彩！

2026-5-1 17:44

DEADC0DE

谢谢你的细致分析，受益匪浅！

2026-5-1 15:42

mxystery

感谢你分享这么好的资源！

2026-4-30 23:35

ogli324

感谢你的积极参与，期待更多精彩内容！

2026-4-30 22:33

零_721409

为你点赞！

2026-4-30 16:08

xuanzee

为你点赞！

2026-4-30 14:43

mb_noeuaplg

你的分享对大家帮助很大，非常感谢！

2026-4-30 14:13

ke3l

非常支持你的观点！

2026-4-30 13:30

clz3216

期待更多优质内容的分享，论坛有你更精彩！

2026-4-30 11:36

zhuzhu_biu

为你点赞！

2026-4-30 11:35

Cherzsh

你的分享对大家帮助很大，非常感谢！

2026-4-30 10:36

qqizai

感谢你的积极参与，期待更多精彩内容！

2026-4-30 09:37

charleyhaa

你的分享对大家帮助很大，非常感谢！

2026-4-30 09:09

七夜大大

你的分享对大家帮助很大，非常感谢！

2026-4-30 08:18

npc0vo

你的帖子非常有用，感谢分享！

2026-4-30 03:06

wx_funcrever

感谢你的贡献，论坛因你而更加精彩！

2026-4-29 19:08

cr_lgdx

你的分享对大家帮助很大，非常感谢！

2026-4-29 15:16

yhock

期待更多优质内容的分享，论坛有你更精彩！

2026-4-29 14:04

孤独的街

感谢你的贡献，论坛因你而更加精彩！

2026-4-29 13:17

mb_vvjtepxu

你的帖子非常有用，感谢分享！

2026-4-29 09:35

mb_rveckyle

期待更多优质内容的分享，论坛有你更精彩！

2026-4-29 09:24

无语了啊～嗝

期待更多优质内容的分享，论坛有你更精彩！

2026-4-29 09:20

wx_摪籇

这个讨论对我很有帮助，谢谢！

2026-4-28 20:43

mb_kqntebgh

为你点赞！

2026-4-28 19:26

周游列国

为你点赞！

2026-4-28 19:23

快乐的小跳蛙

感谢你的积极参与，期待更多精彩内容！

2026-4-28 19:18

pexillove

感谢你的贡献，论坛因你而更加精彩！

2026-4-28 18:58

wx_张三_488

为你点赞！

2026-4-28 18:21

iCookiie

感谢你分享这么好的资源！

2026-4-28 17:26

小王子_646278

谢谢你的细致分析，受益匪浅！

2026-4-28 16:53

MGo

为你点赞！

2026-4-28 16:50

ChuXinﻬ.

这个讨论对我很有帮助，谢谢！

2026-4-28 16:21

mb_hgrbqfun

谢谢你的细致分析，受益匪浅！

2026-4-28 15:10

不吃早饭

为你点赞！

2026-4-28 14:01

dsfa

感谢你分享这么好的资源！

2026-4-28 13:42

mb_ejekfyqx

这个讨论对我很有帮助，谢谢！

2026-4-28 12:33

岁月。

感谢你的贡献，论坛因你而更加精彩！

2026-4-28 11:45

fujing

非常支持你的观点！

2026-4-28 10:46

CanineTooth

感谢你的积极参与，期待更多精彩内容！

2026-4-28 10:46

sun-shine

这个讨论对我很有帮助，谢谢！

2026-4-28 10:42

2beNo2

感谢你的积极参与，期待更多精彩内容！

2026-4-28 10:17

mb_dtidoewd

感谢你的积极参与，期待更多精彩内容！

2026-4-28 09:33

ONewTach

非常支持你的观点！

2026-4-28 09:00

令狐双

非常支持你的观点！

2026-4-28 08:58

王叔叔

期待更多优质内容的分享，论坛有你更精彩！

2026-4-28 08:40

UserXCh

为你点赞！

2026-4-28 08:16

the_hs

为你点赞！

2026-4-28 02:01

木志本柯

感谢你的积极参与，期待更多精彩内容！

2026-4-28 00:04

Ylarod

感谢你分享这么好的资源！

2026-4-27 21:19

我的小拇指啊

你的帖子非常有用，感谢分享！

2026-4-27 21:18

mb_heqvlbnm

感谢你的贡献，论坛因你而更加精彩！

2026-4-27 21:06

白云_win

感谢你的贡献，论坛因你而更加精彩！

2026-4-27 21:02

jmpcall

谢谢你的细致分析，受益匪浅！

2026-4-27 17:56

Tokameine

感谢你的积极参与，期待更多精彩内容！

2026-4-27 17:55

konf

非常支持你的观点！

2026-4-27 17:41

k423

感谢你的积极参与，期待更多精彩内容！

2026-4-27 17:28

wx_Q道长

你的帖子非常有用，感谢分享！

2026-4-27 16:00

asd

这个讨论对我很有帮助，谢谢！

2026-4-27 15:40

houjingyi

谢谢你的细致分析，受益匪浅！

2026-4-27 14:13

mb_bogoqnvg

你的帖子非常有用，感谢分享！

2026-4-27 14:06

LooKoo

谢谢你的细致分析，受益匪浅！

2026-4-27 14:02

mb_npylpnpl

感谢你分享这么好的资源！

2026-4-27 13:44

mb_iesvmzqc

为你点赞！

2026-4-27 13:39

Yangser

这个讨论对我很有帮助，谢谢！

2026-4-27 13:05

梧桐生

为你点赞！

2026-4-27 10:26

小柯南

你的分享对大家帮助很大，非常感谢！

2026-4-27 10:21

路过1

感谢你的贡献，论坛因你而更加精彩！

2026-4-27 09:20

dxzhang

期待更多优质内容的分享，论坛有你更精彩！

2026-4-27 07:17

mb_neulpiaa

感谢你分享这么好的资源！

2026-4-26 21:22

mb_rjdrqvpa

感谢你的积极参与，期待更多精彩内容！

2026-4-26 21:20

逆向小玖

你的分享对大家帮助很大，非常感谢！

2026-4-26 21:12

rettozero

你的分享对大家帮助很大，非常感谢！

2026-4-26 20:55

AlwaysBetter

非常支持你的观点！

2026-4-26 20:33

顽劣

谢谢你的细致分析，受益匪浅！

2026-4-26 20:31

最新回复 (127) 1 2 3 4 5 6 ▶
Gryffindoss 雪币： 635 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 124 粉丝 0 关注私信	Gryffindoss 2 楼 666 2026-4-26 20:16 0
swkl 雪币： 31 活跃值： (1245) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 38 粉丝 0 关注私信	swkl 3 楼 666 2026-4-27 02:32 0
我不是卷王雪币： 547 能力值： ( LV1，RANK：0 ) 在线值：发帖 5 回帖 121 粉丝 36 关注私信	我不是卷王 4 楼 666 2026-4-27 08:16 0
拍拖雪币： 2790 活跃值： (6986) 能力值： ( LV6，RANK：90 ) 在线值：发帖 22 回帖 424 粉丝 15 关注私信	拍拖 2 5 楼感谢分享 2026-4-27 12:39 0
幽灵XZ 雪币： 1014 活跃值： (2048) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 60 粉丝 0 关注私信	幽灵XZ 6 楼 666，太强了 2026-4-27 12:41 0
嘎嘎真的很棒雪币： 716 活跃值： (3787) 能力值： ( LV3，RANK：30 ) 在线值：发帖 8 回帖 161 粉丝 6 关注私信	嘎嘎真的很棒 7 楼感谢分享 2026-4-27 13:03 0
sorely 雪币： 862 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 28 粉丝 0 关注私信	sorely 8 楼 666 2026-4-27 13:12 0
pan_634488 雪币： 0 活跃值： (1505) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 71 粉丝 0 关注私信	pan_634488 9 楼 666 2026-4-27 13:15 0
错过雪币： 86 活跃值： (1507) 能力值： ( LV2，RANK：10 ) 在线值：发帖 12 回帖 67 粉丝 0 关注私信	错过 10 楼 666 2026-4-27 13:44 0
xingbing 雪币： 158 活跃值： (5651) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1373 粉丝 2 关注私信	xingbing 11 楼感谢分享 2026-4-27 15:05 0
method 雪币： 1920 活跃值： (8068) 能力值： ( LV5，RANK：70 ) 在线值：发帖 13 回帖 262 粉丝 134 关注私信	method 1 12 楼 1 2026-4-27 15:17 0
MaYil 雪币： 9401 活跃值： (7957) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 476 粉丝 2 关注私信	MaYil 13 楼感谢分享 2026-4-27 15:25 0
apxar 雪币： 410 活跃值： (1973) 能力值： ( LV3，RANK：20 ) 在线值：发帖 71 回帖 229 粉丝 0 关注私信	apxar 14 楼 1 2026-4-27 20:56 0
mb_urzqsoer 雪币： 206 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 118 粉丝 0 关注私信	mb_urzqsoer 15 楼 66666666666666 2026-4-28 02:09 0
尺间萤火雪币： 55 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 16 粉丝 0 关注私信	尺间萤火 16 楼感谢分享 2026-4-28 02:28 0
Imxz 雪币： 112 活跃值： (9405) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 750 粉丝 9 关注私信	Imxz 17 楼 tql 2026-4-28 10:41 0
mb_pesxllvn 雪币： 378 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 122 粉丝 2 关注私信	mb_pesxllvn 18 楼 666 2026-4-28 11:33 0
fjqisba 雪币： 312 活跃值： (9628) 能力值： ( LV7，RANK：102 ) 在线值：发帖 18 回帖 347 粉丝 87 关注私信	fjqisba 19 楼这次不逃、不躲，正面解决问题了吗 2026-4-28 11:37 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 253 粉丝 0 关注私信	mb_cbgtaveo 20 楼 66666666666 2026-4-28 14:23 0
wx_插曲雪币： 411 活跃值： (861) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 316 粉丝 24 关注私信	wx_插曲 21 楼 666 2026-4-28 18:43 0
wx_插曲雪币： 411 活跃值： (861) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 316 粉丝 24 关注私信	wx_插曲 22 楼 666 2026-4-28 18:43 0
末日大哥雪币： 1122 活跃值： (2141) 能力值： ( LV3，RANK：30 ) 在线值：发帖 10 回帖 154 粉丝 0 关注私信	末日大哥 23 楼 666学习一下 2026-4-28 18:55 0
starrysky 雪币： 400 活跃值： (2340) 能力值： ( LV3，RANK：30 ) 在线值：发帖 2 回帖 81 粉丝 0 关注私信	starrysky 24 楼 1 2026-4-28 19:01 0
starrysky 雪币： 400 活跃值： (2340) 能力值： ( LV3，RANK：30 ) 在线值：发帖 2 回帖 81 粉丝 0 关注私信	starrysky 25 楼 1 2026-4-28 19:01 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

qqqiu

发帖

回帖

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (127) 1 2 3 4 5 6 ▶
Gryffindoss 雪币： 635 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 124 粉丝 0 关注私信	Gryffindoss 2 楼 666 2026-4-26 20:16 0
swkl 雪币： 31 活跃值： (1245) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 38 粉丝 0 关注私信	swkl 3 楼 666 2026-4-27 02:32 0
我不是卷王雪币： 547 能力值： ( LV1，RANK：0 ) 在线值：发帖 5 回帖 121 粉丝 36 关注私信	我不是卷王 4 楼 666 2026-4-27 08:16 0
拍拖雪币： 2790 活跃值： (6986) 能力值： ( LV6，RANK：90 ) 在线值：发帖 22 回帖 424 粉丝 15 关注私信	拍拖 2 5 楼感谢分享 2026-4-27 12:39 0
幽灵XZ 雪币： 1014 活跃值： (2048) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 60 粉丝 0 关注私信	幽灵XZ 6 楼 666，太强了 2026-4-27 12:41 0
嘎嘎真的很棒雪币： 716 活跃值： (3787) 能力值： ( LV3，RANK：30 ) 在线值：发帖 8 回帖 161 粉丝 6 关注私信	嘎嘎真的很棒 7 楼感谢分享 2026-4-27 13:03 0
sorely 雪币： 862 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 28 粉丝 0 关注私信	sorely 8 楼 666 2026-4-27 13:12 0
pan_634488 雪币： 0 活跃值： (1505) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 71 粉丝 0 关注私信	pan_634488 9 楼 666 2026-4-27 13:15 0
错过雪币： 86 活跃值： (1507) 能力值： ( LV2，RANK：10 ) 在线值：发帖 12 回帖 67 粉丝 0 关注私信	错过 10 楼 666 2026-4-27 13:44 0
xingbing 雪币： 158 活跃值： (5651) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1373 粉丝 2 关注私信	xingbing 11 楼感谢分享 2026-4-27 15:05 0
method 雪币： 1920 活跃值： (8068) 能力值： ( LV5，RANK：70 ) 在线值：发帖 13 回帖 262 粉丝 134 关注私信	method 1 12 楼 1 2026-4-27 15:17 0
MaYil 雪币： 9401 活跃值： (7957) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 476 粉丝 2 关注私信	MaYil 13 楼感谢分享 2026-4-27 15:25 0
apxar 雪币： 410 活跃值： (1973) 能力值： ( LV3，RANK：20 ) 在线值：发帖 71 回帖 229 粉丝 0 关注私信	apxar 14 楼 1 2026-4-27 20:56 0
mb_urzqsoer 雪币： 206 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 118 粉丝 0 关注私信	mb_urzqsoer 15 楼 66666666666666 2026-4-28 02:09 0
尺间萤火雪币： 55 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 16 粉丝 0 关注私信	尺间萤火 16 楼感谢分享 2026-4-28 02:28 0
Imxz 雪币： 112 活跃值： (9405) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 750 粉丝 9 关注私信	Imxz 17 楼 tql 2026-4-28 10:41 0
mb_pesxllvn 雪币： 378 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 122 粉丝 2 关注私信	mb_pesxllvn 18 楼 666 2026-4-28 11:33 0
fjqisba 雪币： 312 活跃值： (9628) 能力值： ( LV7，RANK：102 ) 在线值：发帖 18 回帖 347 粉丝 87 关注私信	fjqisba 19 楼这次不逃、不躲，正面解决问题了吗 2026-4-28 11:37 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 253 粉丝 0 关注私信	mb_cbgtaveo 20 楼 66666666666 2026-4-28 14:23 0
wx_插曲雪币： 411 活跃值： (861) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 316 粉丝 24 关注私信	wx_插曲 21 楼 666 2026-4-28 18:43 0
wx_插曲雪币： 411 活跃值： (861) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 316 粉丝 24 关注私信	wx_插曲 22 楼 666 2026-4-28 18:43 0
末日大哥雪币： 1122 活跃值： (2141) 能力值： ( LV3，RANK：30 ) 在线值：发帖 10 回帖 154 粉丝 0 关注私信	末日大哥 23 楼 666学习一下 2026-4-28 18:55 0
starrysky 雪币： 400 活跃值： (2340) 能力值： ( LV3，RANK：30 ) 在线值：发帖 2 回帖 81 粉丝 0 关注私信	starrysky 24 楼 1 2026-4-28 19:01 0
starrysky 雪币： 400 活跃值： (2340) 能力值： ( LV3，RANK：30 ) 在线值：发帖 2 回帖 81 粉丝 0 关注私信	starrysky 25 楼 1 2026-4-28 19:01 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复