yml2213
|
2e2bbc876a
|
feat(密钥): 纯 Python 静态提取 XTEA 密钥 —— 去掉最后一个 Node 依赖 (6/6 构建与神谕逐字一致)
做了什么
- 新增 tcaptcha/tdc_opcodes.py: 按构建从解释器源码推导 opcode 表。
实测 opcode 编号**每份构建整体重排**(同一源码 pc0 的 SET_STACK_LEN 在 6 份构建里
= 53/19/32/57/55/1, JUMP = 60/17/42/58/21/2); 旧固化表只对 core_js 有效 ——
用它反汇编其它构建会在 pc0 撞上 RET_TRUE, 得到"空反汇编"的假象。
做法: 定位主循环 X[Y[Z++]]() 的 handler 数组 -> JS 感知切分 -> handler 源码规范化
(去空白 + 局部变量按首次出现重命名) 取指纹 -> 与内置 58 条 core_js 参考指纹匹配;
数组下标即该构建的 opcode, argc 由语义名取 (与 handler 体内 x[y++] 次数实测一致)。
- 新增 tcaptcha/tdc_key.py: 纯 Python XTEA 密钥静态还原器 (零 Node / 零 pc 硬编码)。
反汇编 -> 定位含 delta 的 XTEA 闭包 -> 用"两层捕获链"选出真密钥数组:
字闭包捕获的 B 帧寄存器, 经"定义 B 的那个闭包"的 caps 映射到 G 帧后须 == XTEA 闭包
捕获的寄存器; 借此排除脚本里并行计算的第二套诱饵字 -> 读 4 个 (源串, 偏移, 下标)
-> 折入轮加盐。
- tools/tdc_disasm.py: disassemble_cfg/_decode_one 支持注入按构建推导的 opcode 表
(names/arity/dynamic), 默认仍回落 core_js 表; 控制流 opcode 改为按语义名定位。
- tools/tdc_key_pure.py: CLI (-v 打印推导过程 / --opcodes 打印 opcode 表 / --json)。
- tcaptcha/crypto.py: extract_xtea_key 改为"纯 Python 主路径 + Node 插桩兜底"。
- 新增 tcaptcha/tests/test_tdc_key.py 并接入 selftest;
新增入库 fixture tcaptcha/tests/fixtures/tdc_fresh_2026-10-11.js (现场新抓的 tdc.js)。
为什么
- AGENTS.md §2.4 分层交付 / §1.1: 去掉最后一个 Node 依赖, 提高并发与抗发版能力;
- §5.7 负结果也是资产: 显式撤回"opcode 数值跨构建固定"与"密钥只能靠 Node 插桩拿"两条旧结论。
怎么验证
- 6 份构建纯 Python 结果 == Node 插桩 extract_xtea_key, **逐字一致**:
core_js / root / 1ms tdc.js / tdc_live / tdc_latest / 2026-10-11 现场新抓 tdc_fresh。
- opcode 表 6/6 构建 58/58 handler 精确匹配, 0 未识别。
- .venv/bin/python -m tcaptcha.selftest 全绿 (含既有逐字节对拍 test_xtea_key)。
- 把 node_bin 指向不存在的程序时 generate_telemetry 仍产出 collect (证明已零 Node)。
|
2026-10-11 22:49:23 +08:00 |
|
yml2213
|
9286f77661
|
docs(账本)+feat(神谕): 完全还原 XTEA 密钥构造算法 (纯 Python 复算与 Node 逐字一致)
做了什么:
- tdc_probe.js 神谕增强: 逐字追踪"某值首次出现的 PC"(__WP), DUMP_PC 支持记录多次命中
- PROGRESS.md 已知表新增 14-18 条: 密钥字构造算法 / 盐折叠 / 纯Python复算一致 /
运行时链路位置 / extract_xtea_key 正确性验证
为什么:
- 用"运行时神谕 + 反汇编阅读"替代逐条模拟(打地鼠), 定位并读懂密钥构造
怎么验证(硬结果):
- 密钥字算法(反汇编读出 + 运行时寄存器佐证):
word = Σ ((charCodeAt(src,k) + off) & 0xFF) << (8k)
四个 (源串, 偏移) = ("IA_t",-8) ("9:%!",+49) ("nTLS",-9) ("7XYf",+3)
- 运行时逐字首次出现: 7740/7526/7895/8852; 数组组装 @8886; 进XTEA @9030; 入口 @9109
- 纯 Python 复算 base=[1817655617,1381395306,1245924197,1767660346]
+ 折盐(855311->word0, 723726->word3)
= [1818510928,1381395306,1245924197,1768384072] == extract_xtea_key ✅
|
2026-10-11 22:27:29 +08:00 |
|
yml2213
|
32a78318ad
|
docs(账本): 记录 XTEA 密钥形态的关键发现(ASCII 打包串 / 闭包捕获 / 轮加盐随构建变)
做了什么:
- PROGRESS.md §一 已知表新增 4 条:
10. XTEA 密钥字 = 4 个「ASCII 打包的 4 字符串」(大端拼 32bit)
11. 密钥既不是立即数也不是字面字符串(明文/大端字节/base64 都搜不到)
12. 密钥数组经闭包捕获传入: @09463 CREATE_CLOSURE caps=[r7=r8], XTEA 轮以 reg7[(sum>>>11)&3] 取用
13. 轮加盐随构建变化(本构建 723726/855311, 台账另一构建 2829068/328986), 但都是可见立即数
- PROGRESS.md §五 下一步新增第 0 条: 静态提取密钥(逐闭包符号执行)
为什么:
- 这是"去掉最后一个 Node 依赖"的关键定位, 避免重复摸索
怎么验证:
- 密钥字节解剖: 1818510928 -> 0x6c644650 "ldFP" 等 (core_js/tdc_sample.js)
- 反汇编: .venv/bin/python tools/tdc_disasm.py tcaptcha/core_js/tdc_sample.js
|
2026-10-11 21:51:06 +08:00 |
|
yml2213
|
e2485c5ea6
|
docs(账本): 记录 H3 单变量实验结论(captcha 域 cookie 与 errorCode=12 无关)
做了什么:
- ANALYSIS.md §7.1 新增 E8: captcha 域"带/不带"腾讯云登录 cookie, 单变量 A/B 均为 12
- ANALYSIS.md §7.4 假设表更新: H3 标注为已排除, 只剩 H1/H2
- ANALYSIS.md §4.3 更正: extract_eks 改通用匹配后实测 248 字符, 与真实浏览器一致
- PROGRESS.md §三 已排除表新增 H3 一行
为什么:
- 彻底关闭"换 cookie/cookie 同源"这条猜测路线, 避免重复投入
怎么验证:
- 单变量 A/B: scripts/experiment_h3_cookie_ab.py --both -> A=12, B=12
(同一次运行, 题目 2404 求解 posterior=1.000 全对, collect_len=1856)
|
2026-10-11 21:47:27 +08:00 |
|
yml2213
|
47ce74b160
|
refactor(纯算): 移除全部补环境后端,收敛为纯算单一路径 + 修复两处红灯
做了什么:
- 删除 generate_telemetry_node/browser/probe 三个伪造环境后端, 以及 apply_real_environment、
4 段拼接旧结构、human_dt_ms、generate_collect_pure (crypto.py 955 -> 389 行)
- 遥测只剩纯算: python_keyed = Node 仅提取 XTEA 密钥字 + Python 模板回填 + 教科书 XTEA
- 修复 crypto.py 重复的 xtea_encrypt_block (内置自测从失败到通过), 并并入 selftest
- 修复 glyph_solver 强校验: 改用集成得分矩阵行 argmax 自洽校验, 回归 5/8 -> 8/8
- 移除注释里无证据的 errorCode=12 归因; 移除 12 自动换 IP 重试
- extract_eks 不再写死变量名; UA 常量统一为 Chrome/155
- 文档对齐: ANALYSIS §8 修订 / PROGRESS 重写 / TOOLCHAIN_REPORT §三 更正
为什么:
- 本项目证据账本已证: 12 与遥测后端/出口 IP/静默时长均无关, 补环境无收益且引入脆弱面
- 强校验用单引擎 ocr_text 会误杀正确解 (实测 簿->垂 / 笆->芭 / 筹->努)
怎么验证:
- .venv/bin/python -m tcaptcha.selftest 全绿 (crypto_core + glyph 8/8 + xtea_key)
- 端到端纯算: python / python_keyed 均可解回 '{"cd":[' 开头明文, probe 模式被拒绝
|
2026-10-11 21:30:26 +08:00 |
|
yml2213
|
1ef819b48d
|
feat(纯算): 以成功样本明文为模板的纯 Python 出包管线 + 证据账本 v2
做了什么
- 从「签到成功-1.har」提取该次会话的 tdc.js, 提取密钥解密出
errorCode=0 那次 collect 的完整明文 (1360 字节), 存为
tcaptcha/models/success_collect_template.b64
- 新增 generate_collect_success(): 以成功样本为结构模板, Python 只回填
轨迹/当前时间戳/随机盐, 其余环境字段 (canvas/WebGL/屏幕/语言/sd.ft) 原样保留
- 新增 _success_style_trajectory(): 按成功样本实测统计生成轨迹
(61 点, dt 均值 30.6ms, 50% 在 0~16ms, 途经 3 个目标, 驻留抖动)
—— 修正了统计正则不允许负增量的 bug (真实 61 点, 此前误数成 18)
- 发现成功样本用 \x00 填充 (不是空格), sd 多一个 ft 字段
- telemetry_mode=python_keyed 默认走该路径; Node 仅提取每构建 XTEA 密钥
- ANALYSIS.md 第七节重写为 v2 证据账本, 显式撤回 4 个无证据结论
验证
- 纯 Python 密文 == 真实 tdc.js 密文 (逐字节)
- 回归: test_xtea_key 11 项、test_glyph_solver 8/8
- 端到端 1ms 实测: 仍 errorCode=12 (诚实记录, 未解决)
结论(见 ANALYSIS.md 7.5-7.7)
- 12 不是"检测到机器人": 同 IP 有成功样本、参数逐字段一致、
真 Chrome 网络栈/真人点击/CDP 均排除
- 剩余假设: H1 需已登录业务会话(未用 auth_token 调 captcha/params 复测)
H3 需有效 qcloud.com cookie(过期 skey 复测不能定论)
- 下一步: 用登录态 auth_token 调 /api/v1/captcha/params,
对比返回是否多出鉴权字段 —— 这是唯一未做且成本低的关键实验
|
2026-10-11 19:12:23 +08:00 |
|
yml2213
|
be7a6ee97b
|
chore(git): har/ 下只忽略抓包产物,放行分析文档入库
做了什么
- .gitignore 的 `har/` 改为 `har/**` + `!har/**/` + `!har/**/*.md`
—— 仍忽略 har/ 下的 jpg/js/json 抓包产物,但 *.md 分析文档正常入库
- 首次纳入两份文本证据资产:
har/1ms_dianxuan/ANALYSIS.md (330+ 行协议分析报告)
har/1ms_dianxuan/PROGRESS.md (已知/未知/已排除假设/下一步)
为什么
- 原规则是整目录忽略,把「证据文档」和「大文件抓包」一起挡在版本控制外;
按 AGENTS.md §1.3,进度与证据必须落盘可追溯,文档应随代码版本化
怎么验证的
- git check-ignore 逐项确认: PROGRESS.md/ANALYSIS.md 入库,
bg_3.jpg/tdc.js/live/session.json 仍忽略
- git add 预演仅 3 个文本文件, 无二进制混入
- 已检查文档内无 API key 等凭据 (仅几个已过期住宅代理 IP)
|
2026-10-11 18:10:15 +08:00 |
|