 yml2213
|
3f91b0a4e3
|
feat(vm): PC 轨迹对拍工具 + 2 处语义修复(定位到首个执行流分歧)
做了什么:
- 新增 tools/tdc_trace.js: 给分发器 M=G[z[H++]]() 打补丁, dump 真实执行 PC 序列
- tdc_vm_run.py: 新增 TRACE_FULL 全量 PC 轨迹; 子 VM 共享 pcs/events(轨迹是全局的)
- 修复 CALL_FUNC 的 this 绑定: 真实语义 fn.apply(c, B) -> this = c (原来传 None)
- DBGCALL 调试输出(callee 类型/closure 异常/ref 与栈尾)
为什么:
- 单靠读语义会无限试错; PC 轨迹对拍能一步定位首个分歧
怎么验证:
- node tools/tdc_trace.js tcaptcha/core_js/tdc_sample.js -> 真实 19266 步
- 我们的解释器 739 步; 逐条 diff 后:**前 713 步完全一致**
- 首个分歧 @step714: real 进入 @1544, 我们 fall-through 到 @208
对应指令 @206 CALL_METHOD [4]; 我们的 ref=[None,'call'] (base 为 None),
真实应为一个可调用对象 -> 说明某个寄存器在我们这边是 None
|
2026-10-11 22:04:44 +08:00 |
|
|
yml2213
|
1fbd8f46f5
|
fix(vm): 修正解释器 4 处保真度问题 + 增加事件追踪
做了什么:
- E 初值改为 [[this],[{}]] (与 VM 源码默认一致)
- Stub 改为真正保存被赋属性 (模块工厂挂在对象上, 丢弃就找不到模块)
- Object/Array/String/... 改为 HostFn, new 时真正构造容器
- getprop/setprop 采用 JS 非严格语义 (原始值: 读=undefined, 写=静默忽略)
- 新增 TRACE=1 事件追踪 (CREATE_CLOSURE/CALL_*/RET_TRUE) 与模块表收集
为什么:
- 这些是解释器与真实 VM 保真度不符的根因, 导致顶层跑完却收不到任何模块闭包
怎么验证:
- py_compile 通过; TRACE=1 跑出 66 条关键事件(其中 CREATE_CLOSURE ~65)
- 现状: 仍只跑完顶层引导(739 步), 模块表为空 -> 待用 PC 轨迹对拍定位首个分歧
|
2026-10-11 22:02:20 +08:00 |
|
|
yml2213
|
70f2ece32c
|
docs(vm): 新增 Chaos VM 规范 + WIP 纯 Python 解释器
做了什么:
- 新增 tcaptcha/VM_SPEC.md: 从源码/反汇编事实整理 VM 全套规格
* §1 架构(VM(H,z,c,E,I,D,U,C), c=window, 主循环 M=G[z[H++]]())
* §2 数据模型(E 一物两用=寄存器区+求值栈; 寄存器单元 E[i][0]; 引用=二元数组 [base,key])
* §3 完整 opcode 表(70 槽/58 handler/12 空洞, 附 handler 源码与 argc, 由 AST 自动导出)
* §4 闭包与调用(CREATE_CLOSURE 动态布局, caps 共享单元, CALL_FUNC/METHOD 的 this 绑定)
* §5 引导流程(实测顶层只注册模块) §6 宿主与驱动(c 即 window, 环境全走 c)
* §7 工具链映射 §8 解释器路线图(已完成①-④, 未完成⑤模块系统+宿主驱动)
- 新增 tools/tdc_vm_run.py: 58 个 opcode 的具体解释器 + 宽松 JS 宿主 (WIP, 跑通顶层引导)
为什么:
- 之前"没头绪"的根因是数据模型(E 一物两用/寄存器单元/引用二元数组), 必须写成确定规格
- 并定位真正的卡点: 不在 VM 而在"模块系统 + 宿主调用序列"
怎么验证:
- tools/tdc_vm_run.py 跑 739 步后 RET_TRUE (仅顶层引导), 与 CFG 可达性一致
|
2026-10-11 21:59:06 +08:00 |
|
|
yml2213
|
d52368be2b
|
feat(工具链): 纯 Python 可达性 CFG 反汇编器 + 废弃旧线性反汇编器
做了什么:
- 新增 tools/tdc_disasm.py: 纯 Python 提取 tdc.js 字节码数组 + 可达性 CFG 反汇编
* opcode 表由 VM 源码 AST 推导 (70 槽 / 58 handler, 操作数个数 = handler 内 z[H++] 次数)
* 复刻 VM 内联的 base64 解码 + 游程展开 (含科学计数法常量), 无任何 JS 运行时
* 遍历根含 JUMP/JUMP_IF_TRUE/PUSH_TRY catch/CREATE_CLOSURE 闭包体
- tools/tdc_vm_disasm.js 降级为废弃 shim (转发到 Python 版)
- TOOLCHAIN_REPORT.md 更新工具行与复验命令; tdc_sample.disasm.txt 用正确实现重新生成
为什么:
- 旧线性反汇编对字节码里的数据区继续扫描会失步: 实测 73 处 UNKNOWN (16 处 >69 的
"不可能" opcode), 且未把闭包体当遍历根 -> 大半个程序不可达, 输出不可信
怎么验证:
- .venv/bin/python tools/tdc_disasm.py tcaptcha/core_js/tdc_sample.js
-> bytecode=45636 (与旧实现一致), 可达指令 26168, illegal opcodes: []
- 反汇编首次干净读出 XTEA 轮函数: PUSH_IMM 2654435769 / ADD / ... / SHR_UNSIGNED 11 / &3
并定位密钥数组在寄存器 7, 本构建轮加盐为 723726 / 855311 (均为立即数)
|
2026-10-11 21:47:27 +08:00 |
|
|
yml2213
|
60ae14d54a
|
feat(captcha): 增加全题型图片落盘、字形一致性强校验与防秒换拟人交互机制
- 题目图片自动下载: 所有题型原图统一落盘至 scratch/captcha_debug，文字点选自动生成带编号红圈标注图便于肉眼核验
- 字形严格一致性校验: 在 SolveResult 增加 text_match_ok 检查，对图字不符或混淆干扰题直接拒答换题，避免错答引发 errorCode=12
- 防秒换与拟人延时: 遇到非预期题目换题等待 2.8~4.2s (对齐 HAR 真实抓包)，求解失败等待 2.5~3.8s，作答前模拟交互 5.5~7.5s
- 代理容错增强: 在 OneMsAdapter 捕获代理断流与鉴权异常，支持动态轮换新代理重试
|
2026-10-11 20:51:12 +08:00 |
|
|
yml2213
|
d136fb7328
|
feat(tcaptcha): 建立AST解包、TDC虚拟机反汇编与深度Proxy语义探针工具链
- 解包 tcaptcha-frame bundle，圈定 122 个模块中的核心加签与通信模块
- 还原 __TENCENT_CHAOS_VM 架构：映射全部 70 个操作码语义并实现字符串折叠反汇编
- 提取 246 个核心字符串，全量排查并枚举 95 项环境检测与自动化探针特征
- 实现零浏览器依赖的深度 Proxy 探针，原生生成与会话自洽的 collect 与 eks
|
2026-10-11 20:13:14 +08:00 |
|