四路探子下 so 层：vtable 回调协议、RequestAd 等待机制的追索，与「无广告」判定路径的三线合围

上一班钉死了三条闸门，这一班派四路探子去量门轴的尺寸。四线合围的目标只有一个：确定 patch 的落点——动 libcupid，还是动内核的等待点。

一、四路的分工

兵力部署照旧家法：子代理一号逆向内核 RequestAd 调用链，定位「广告就绪/无广告」事件的等价物；子代理二号反汇编 ARM32 共享库，追 CUPID 广告回调协议的 vtable——IAdJsonDelegate 虚函数表就是 CUPID 与内核之间的回执合同；子代理三号在 libcupid.so 里找「无广告」的判定路径（让状态机直接走 no ad 分支、快速失败而不卡死）；子代理四号在盒子 root 环境做 CUPID 事件日志观察，提取真实的请求/响应事件序列。前两路回答「内核在等什么」，后两路回答「libcupid 在什么条件下说没有」。

二、vtable：回调协议的载体

二号探子的战场是函数指针的迷雾：内核注册给 CUPID 的回调对象是一个 C++ 对象，其 vtable 的每一个虚函数槽都是一条回执通道——广告就绪走哪一槽、失败走哪一槽、无广告走哪一槽。找到这个 vtable 的内存布局，就等于拿到了两军之间的密码本：无论选择 patch libcupid 的出口还是伪造内核的入口，都必须按这本密码书写。配合主线的发现（slot_type 位掩码、事件 13 失败分支、0x6f9f4 出口），回调协议的全图只差最后几页。

三、等待机制：卡死的根因方向

一号探子追的是另一个悬案：RequestAd 之后内核在等什么、等多久——v13 测试包「广告秒过后卡死」的根因就藏在这段等待逻辑里。若等待有超时上限，伪造无广告回调后的收尾就能优雅落地；若等待是无限阻塞，patch 还须附带唤醒。这是 TEST-ONLY 包能否「不卡死」的关键前提。

四、合围的方法论

四线并进的价值不在并行本身，而在互证：静态反汇编（vtable 与等待机制）、库内路径（无广告判定）与动态日志（盒子上的真实事件序列）三面互为印证，任何单一线索的误读都会被另外两面纠正——此前 thumb BLX 的冤案正是单线扫描的教训。云机构建 TEST-ONLY 的前置条件已经齐备：闸门地址、伪造配方、协议密码本、卡死根因方向。剩下的只是把 patch 写出来，让广告在《魅影神捕》的一百多秒等待变成一次优雅的「无广告」回执。