 yml2213
|
80a122245a
|
feat(collect): 按 docs/tdc-案例.md 重做主链路 —— 四段加密 + 字符串指纹识别 37/37
做的什么:
1. 判决并修正 collect 结构: 不是「整体一次加密」, 而是
chunk1 / trajectory / chunk2 / sd **四段独立加密**, 前 3 段
空格 pad 到 24 字节对齐、sd 不 pad, 4 段 base64 直接拼接。
2. 按案例 §5.3 实现字符串+结构指纹的模块识别器, 把 37 个采集器
全部识别且跨构建唯一。
3. 修 reorder 的恒等映射 bug, 并补强断言。
4. 在线抓取全新样本作为唯一数据源, 清理探索性脚本。
为什么:
* 旧「整体加密 + \x00 补齐」与真机数据矛盾 —— 导致多轮实验
建立在结构错误的 collect 上（这正是此前反复"乱碰"的根因）。
* 模块 id 每份构建重排, 不能当跨构建锚点; 但模块的**代码**
（字符串集合、结构）不变 —— 这是案例指明的不变量。
* reorder 旧实现用「目标槽下标」切「源数组」, 顺序不同即全盘错位;
原测试只断言"是置换", 恒等函数也满足, 所以 bug 被放过了。
怎么验证:
* 四段结构（3 条独立证据, 其中一条不需密钥）:
- 真机明文 3 处连续空格串 [+5,+10,+24], 且 pad == 24-len%24 全中
- 密文长度算术 480+96+416+56 = 1048 == 真实 1048 字符
- '=' 只出现在 1046/1048, 对应 sd 段 33B→补 7→40B
* 指纹: 4 份全新在线构建 37/37 识别、0 unknown、跨构建语义名集合
完全一致、单构建内 0 重名
* 配对正确性: 独立证据 37/37 一致; 负对照（清单下标 / 模块 id /
随机配对）均只有 2-3/37 —— 证明归一化没有过拟合
* 端到端重排 3/3 正确且非恒等
* selftest 全绿; 强断言自查: 旧实现过不了新断言
新增:
tools/tdc_modules.py 字符串+结构指纹识别（案例 §5.3）
scripts/fetch_online_samples.py 在线抓取全新 tdc.js
scripts/verify/*.py 7 个可复现的验证脚本
docs/tdc-案例.md 案例原文（看雪, 作者执着的猫）
修改:
tcaptcha/crypto.py +build_collect / split_collect_segments（四段）
tools/tdc_collectgen.py reorder 改为跨构建锚点对齐 + spec_from_seq
tools/tdc_layout.py +static_fingerprint / opcode_histogram
tools/tdc_program.py 修符号求值插值类型崩溃
tcaptcha/tests/test_collectgen.py 补「非恒等」强断言 + 在线新样本端到端
tcaptcha/client.py debug 目录改到系统临时目录（不再写仓库内 scratch/）
har/1ms_dianxuan/PROGRESS.md 新增已知 #41~#49, 显式修正被推翻的旧结论
.gitignore +scratch/ +har/online/
删除:
scratch/（含 10-11 遗留的一次性脚本, 已确认不可恢复后清理）
注意:
* 账本记录了一次自我纠错: 曾据案例 §5.5 误判 kind=2「不进 cd」,
实测（cd 38 槽、轨迹在第 10 槽）否定后已撤回。
* 仍未打通: 纯离线生成需要每个语义名的取值来源（已知 #38）。
|
2026-10-12 02:28:08 +08:00 |
|
|
yml2213
|
fe1415508a
|
feat(VM): cd 槽位表可静态导出 + 槽位语义还原（符号求值）
tdc_program 新增 symbolic_assignments(): 对小程序做线性符号求值, 把字节码还原成
`r6 = c.navigator.userAgent` 这样的可读表达式（覆盖字面串/BIND_THIS/MAKE_(REG_)PROP_REF/
GET_GLOBAL_PROP/NEW_FUNC/CALL_*/STORE_REG/LOAD_REG_IMM/REVERSE_TOP2/DUP/算术）。
tdc_layout 新增:
* slot_value_expr(): 精确规则 —— 采集器模块把值存进某寄存器, `get` 闭包只返回它
（caps 的父寄存器就是取值寄存器）; 含"模块里唯一闭包"的兜底
* slot_semantics(): 合并"工厂赋值链 + require 委派 + 内部闭包"三条线索
* 输出改成叶子语义 + 真机明文并排核对
实测确认（线上构建 + 同会话解出的真机 collect）:
* 清单模块 = registry[7], 构造方式是 `r6[r6.length] = require(N)` 追加
-> **require 顺序即 cd 槽位顺序**（37 个 require + 1 个字面量槽 = 38, 与真机完全吻合）
* 语义已精确命中: cd[3] <- c.navigator.userAgent, cd[5] <- c.navigator.languages
* 仍有若干槽的语义标签未对齐（取值寄存器规则需再收口）, 已在账本记录
|
2026-10-12 00:17:30 +08:00 |
|
|
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 |
|