yml/hello_js_reverse_skill
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
66 Commits 1 Branch 0 Tags
74d478050c5748e235923f306cee6c234b5bff11
Commit Graph
13 Commits
Author SHA1 Message Date
yml2213 74d478050c feat(神谕): PC 二分定位 + 任意 PC 全寄存器 dump, 破译密钥字算法 
做了什么:
- tdc_probe.js 钩子增强:
  * 扫描 E, 报告"基字数组"与"基字[0]"首次出现的 PC (二分定位构造点)
  * DUMP_PC=<pc> 时 dump 该 PC 的全部寄存器 (类型+值)
  * report 回传 __arr / __wrd / __dump

为什么:
- 需要"某个值在哪段字节码诞生"的运行时神谕(AGENTS.md §3.2 第3条), 而不是逐条猜

怎么验证(本轮硬结果):
- 基字[0] 首次出现 @7740 reg9; 基字数组首次出现 @8886 reg7;
  XTEA 闭包在 @9030 CALL_FUNC[2] 被调用, 入口 @9109
- DUMP_PC=7726 显示 E[3]="IA_t", E[10]=ref("IA_t","charCodeAt"), E[4]=0(i)
- 反汇编 @7712..@7740 读出的算法:
      word |= (str.charCodeAt(i) - 8) << (8*i)        // 小端打包
  验证: LE_pack('IA_t' 各字符-8) = 1817655617 == 基字[0]  ✅
- extract_xtea_key 交叉验证: 其密钥可把 probe 的 collect 解成 {"cd":[0,10,"top",... 真明文
  且 real[i]-base[i] 在 i=0/3 恰等于 XTEA 轮里的可见立即数 855311 / 723726
 2026-10-11 22:24:19 +08:00
yml2213 5c949090c1 feat(vm): 神谕钩子 —— 在真 VM 中按 PC 快照寄存器 (定位/校验任意值) 
做了什么:
- tools/tdc_probe.js 注入自包含钩子(window.__H): 记录 PC 轨迹, 并在指定 PC
  dump 指定寄存器 (默认 9109 / E[7]), 通过 report.__xtea / report.__pc_len 回传
- tools/tdc_keytrace.js 同步支持 TARGET_PC 钩子

为什么:
- 需要"某个值在哪段字节码诞生"的运行时神谕(AGENTS.md §3.2 第3条: 与运行时观测对齐)
- 钩子自包含写在沙箱 window 上(沙箱内没有 globalThis)

怎么验证(本轮的关键结论):
- 命中: @9109 入口 E[7] = [[1817655617,1381395306,1245924197,1767660346]];
  其后 PC 序列 tail = [...9021,9022,9023,9024,9026,9028,9030,9109]
  -> 说明 XTEA 闭包是在 @9030 CALL_FUNC[2] 被调用的
- 交叉验证: 用 extract_xtea_key 的密钥解密 probe 的 collect -> {"cd":[0,10,"top",...
  (真明文) => extract_xtea_key 正确;
  而 E[7] 解不开 => E[7] 是"基字", 不是生效密钥
- 结构确认: real[0]-cap[0]=855311, real[3]-cap[3]=723726 (XTEA 轮里的可见立即数)
  => 有效密钥 = 脚本基字 + 两个轮加盐
 2026-10-11 22:21:53 +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 eed7004754 chore(vm): 归档解释器 tdc_vm_run.py 到正确语义 (VM 返回 = 栈顶/切片) 
做了什么:
- 修正 VM 返回语义: `A ? (E.pop(), E.slice(3+VM.v)) : E.pop()` (闭包调用返回栈顶)
- JArr 缺键返回 undefined; E 初值 [this]=全局; CALL_FUNC 的 this=c

为什么:
- 该工具已判定为"用 Python 复刻 JS 运行时"的弯路(AGENTS.md §2.3 铁律2 打地鼠陷阱)
- 但已实现的 58 个 opcode 语义 + 诊断钩子仍有储备价值, 故归档而非删除(§1.4)

怎么验证:
- py_compile 通过; 与真值 PC 轨迹对拍仍显示前 713 步一致(未继续推进, 按新路线改走 lift)
 2026-10-11 22:15:51 +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
yml2213 9008af0d18 fix(vm): 3 处保真修复 + 精确定位到模块实参为 null 
做了什么:
- JArr.__getitem__ 缺失键返回 undefined (JS 语义), 原来返回 Python None
- E 初值 E[0]=[this], 顶层 this=全局对象 c (原来错写成 None)
- MAKE_REG_PROP_REF / CALL_METHOD / closure 调用 增加 DBGCALL 诊断输出

为什么:
- 用 PC 轨迹对拍逐条缩小: 前 713 步一致, 分歧在 @206 CALL_METHOD
- 根因链: @45631 CALL_FUNC(模块工厂) 的实参是 [null] -> 参数 r3=[null]
  -> 闭包 @20 捕获 r6=父r3 -> E[6][0]=null -> ref=[null,'call'] -> 调用不到

怎么验证:
- node tools/tdc_trace.js ... -> 19266 步(真值); 我们仍 739 步
- 分歧点/根因链见上 (已用 DBGCALL 定位到具体指令与寄存器)

下一步线索: 追 "谁把该实参压成了 null" (候选: PUSH_NULL(29) 被误用, 或某次属性读取应得对象却拿到 null)
 2026-10-11 22:07:16 +08:00
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