 yml2213
|
c4fe365e8c
|
feat(VM): 吃透 Chaos VM 程序结构层 —— 模块注册表 + collect 槽位表可静态导出
补上 VM_SPEC §5/§6 自己点出的缺口（"不是 VM 的问题, 而是模块系统 + 宿主调用序列"）。
新增 tools/tdc_program.py（程序结构分析器）:
* closures / entries / 字面串折叠 / 边界感知的函数体切分
* module_registry(): 识别顶层 "registry[id] = factory" 装配模式 -> 62 个模块工厂
* call_graph / shared_bodies / find_strings / --func 导出自身指令
修掉两个真 bug:
* tdc_disasm: RET_TRUE / THROW 未当终结符 -> 控制流穿过函数结尾线性走下去,
把父函数续段误判给夹在中间的兄弟函数（@4940 曾误归 @4362, 实为 @4160）
* tdc_lift: 终结符判定写死 opcode 数值 19/49 -> 改为按语义名
新增 tools/tdc_layout.py（静态导出 cd 槽位表）:
装配链已完全厘清:
顶层 = 62 个模块工厂的注册表（工厂形参 (module, exports, require)）
-> 清单模块 arr[arr.length] = require(N) <<< 这串 require 的顺序就是 cd 槽位序
-> 分发模块按 .on/.reset/.get 分三数组
-> 装配模块 r3='{"cd":[' + for(...) r3 += r8.get() + '],"sd":{...}'
跨构建实测: core_js 的 require 串与线上构建的串**不同**（槽位序按构建随机化, 与 #31 一致）;
语义对位已验证若干槽（userAgent->cd[3], href->cd[4], languages->cd[5] 命中）。
VM_SPEC 新增 §9 程序结构层（模块系统 / 入口 / collect 装配 / 为何决定 12）。
selftest 全绿。
|
2026-10-12 00:13:27 +08:00 |
|
|
yml2213
|
9c889215f2
|
feat(vm): 提升器按闭包边界切分函数 + 递归展开全部子程序
做了什么:
- tdc_disasm.disassemble_cfg 增加 follow_closures 开关
(提升单函数时关闭, 避免"子函数体的可达性溢进父函数")
- tdc_lift.run 递归提升所有被引用的闭包: 229 个独立函数
- 函数名统一为 sub_<target>, 便于按 pc 定位
为什么:
- 原来整个程序挤在一个 function 里(闭包 body 与父函数地址连续), 无法按子程序阅读
- AGENTS.md §3.3 步骤5 明确要求"子程序调用(闭包创建)递归展开"
怎么验证:
- .venv/bin/python tools/tdc_lift.py tcaptcha/core_js/tdc_sample.js
-> lifted functions=229; XTEA 例程 = sub_9109, 内含 r2=(r2+2654435769)
- .venv/bin/python tools/tdc_query.py .../tdc_sample.lifted.txt who r2
-> sub_9109 @9109: r2 = 0; @9285: r2 = (r2 + 2654435769);
|
2026-10-11 22:18:42 +08:00 |
|
|
yml2213
|
942421d811
|
feat(vm): 提升器改用"执行流栈快照(DFS)"渲染, 消除跨跳转失步
做了什么:
- _lift_func 重写为两遍:
第一遍: 沿执行流 DFS 传播"求值栈快照"(每条 pc 记录进入时的栈)
第二遍: 按地址序渲染, 块首用快照还原栈
- 新增 _next_pc(): 用规范操作数长度计算后继(含 CREATE_CLOSURE 动态长度)
为什么:
- 原来按"地址序 + 块首清空栈"提升, 表达式跨分支传递时会整体丢失
- 栈机必须在"执行流"上跟踪栈, 而不是地址序
怎么验证:
- XTEA 轮仍可读: r2=(r2+2654435769); r?+=(((r6<<4)^(r6>>>5))+r6)^(r2+r7[((r2>>>11)&3)])
- 闭包图正确: // closure func_9109(p0->r3,p1->r4) caps=[r7<-r8] target=@9109
- 已知残留: 汇合点(多前驱)取首路径栈, 仍会产出少量 r<?> (下一步: phi 合并/对齐运行时轨迹)
|
2026-10-11 22:17:55 +08:00 |
|
|
yml2213
|
2e7aaff9ec
|
feat(vm): 自上而下重构工具链 —— 新增提升器(lift)与查询CLI(query)
做了什么:
- 新增 tools/tdc_lift.py: 字节码 -> 可读伪代码 (AGENTS.md §3.3 步骤5)
* 表达式栈还原 (算术/比较/调用/属性)
* 寄存器引用惯用法还原 (PUSH_IMM_ARRAY n + MAKE_REG_PROP_REF -> rN[key])
* 控制流 label/goto/if; CREATE_CLOSURE 递归展开成具名函数
- 新增 tools/tdc_query.py: who rN / at @pc / funcs / grep RE (对齐 §4.2 验收)
- 新增 tools/tdc_keytrace.js: 用真 VM 当神谕, 定位某值在哪段字节码诞生
- VM_SPEC §7/§8 重写为"自上而下五件套 + 路线", 并把 tdc_vm_run.py 标注为归档(打地鼠陷阱)
- 修正 lift 的 [n]->rN 归一 与 标签刷屏
为什么:
- 之前用 Python 复刻 JS 运行时去"跑"VM = §2.3 铁律2 的打地鼠陷阱, 收敛极慢
- §3.3 步骤5 要的是"读指令流得到算法; 闭包递归展开" -> 提升(lift)才是正路
- §2.1 最后一步: 读出算法后用目标语言原生重写, 跳过 VM/环境层
怎么验证:
- lift 首次把 XTEA 轮读成可读式: r2=(r2+2654435769); r?+=(((r6<<4)^(r6>>>5))+r6)^(r2+(r7[((r2>>>11)&3)]+855311))
- query 三个验收问题均可秒答: who r2 / at @9285 / funcs
|
2026-10-11 22:15:43 +08:00 |
|