feat(反VM): 纯 Python 还原 XTEA 算法 + 从 tdc.js 运行时提取每构建密钥
做了什么
- 确认 collect 的加密算法就是教科书 XTEA (32 轮, delta=0x9E3779B9),
并证明 crypto.py 原有的"带加盐"写法只是把两个密钥字折叠:
K' = [k0, k1+salt1, k2+salt2, k3]
- tdc_worker.js 新增 captureKey 模式: 正则改写 VM 的 ADD/XOR opcode 为带日志版本,
用反向引用自动识别栈变量名 (样本=g/雨云实时=j/1ms=M, 版本无关);
匹配数不为 1 时显式报错, 不静默失败
- 密钥反推: (sum + K[j]) 是一次 ADD, 两操作数必有一个等于 r*DELTA,
另一个就是密钥字; 再对 Top-N 候选做 4! 排列 + 明文内容特征验证
- 新增 recover_payload_template / generate_collect_from_template:
运行时标定一次明文模板, 之后轨迹生成/组包/加密/编码全部在 Python
- 新增 tcaptcha/proxy.py 代理提取, client 支持 --proxy-api 遇 12 自动换 IP
为什么
- 服务端只认 collect 的解密结果, 而密钥是每构建随机的;
把算法做成纯 Python 后, 只有"取密钥"依赖 Node, 抗发版能力最强
怎么验证的
- 纯 Python XTEA 加密结果与真实 tdc.js 产物前 48 字节逐字节一致
- 密钥按构建固定的证据: 同一脚本 3 次运行密文首块均为 f6a24e3e4fb5dd2b
- 三份脚本 (样本/雨云实时/1ms实时) 均成功复原密钥
- 雨云 aid 端到端: 纯 Python 出包 -> errorCode=0 + 真实 ticket
- 回归测试: tcaptcha/tests/test_xtea_key.py 11 项断言全过,
文字点选求解 8/8; 新增 tcaptcha/selftest.py 一键复验
已知未解
- 1ms aid=195672344 在答案正确时仍返回 errorCode=12; 已排除密钥、
遥测引擎、出口 IP (4 个住宅代理)、短时频控、静默窗口
yml2213
fbcf2d448a