dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
497 Commits 3 Branches 0 Tags
df62898d22381ba2ca6a84ac109cfb7a9d7ed088
Commit Graph
168 Commits
Author SHA1 Message Date
yml2213 c3fd299f3a test(db): 测试改用真实 MySQL，方言差异不再漏到生产 
生产是 MySQL 8、测试是 SQLite，两者的方言差异在本地完全测不出来。今天为此
付出了两次代价：

1. `ORDER BY ck_checked_at ASC NULLS FIRST` 在 SQLite 上完全正常，本地 258 条
   全绿，一部署到生产第一次巡检就 1064 语法错误（MySQL 不支持 NULLS FIRST）；
2. P1b 自动重登的结算复用调度器事务读取，在 SQLite 下看不出问题，但在 MySQL 的
   REPEATABLE READ 下读到的是批次开始前的快照 —— 10 条实际成功的重登全部被记成
   失败。SQLite 的读一致性与 MySQL 不同，这类问题跑一万遍也复现不出来。

改动：
- 新增 tests/support/db.py：测试专用引擎/会话工具，连接串从 .env 读取，
  默认指向独立的 douyu_login_test 库；
- 新增 tests/conftest.py：会话级建好表结构，每个用例前后清空所有表做隔离；
- 根 conftest.py 接管连接串设置：它在 pytest 收集阶段最先执行，在这里把
  DATABASE_URL 指向测试库，应用模块首次 import 拿到就是 MySQL，不依赖任何
  import 顺序（原先这里是 sqlite:// 兜底，改造后会变成「先建 SQLite engine
  再打补丁换成 MySQL」，顺序一变就静默跑错库）；
- 21 个测试文件的 setup 样板统一改用共享测试引擎；
- 两个迁移测试改为在临时库 douyu_login_mig_<随机> 上跑完整 alembic upgrade head，
  跑完 drop —— 迁移脚本本身也终于在 MySQL 上被验证；
- dev.sh 与 README 的过时说明一并更新（原先写着「不需要 MySQL / .env 配置」；
  「测试各自建 SQLite 内存库」）。

安全与易用：
- 测试库名与开发库同名时**直接拒绝运行**（clear_tables 会 DELETE 所有表，
  一旦 TEST_MYSQL_DATABASE 被指到 douyu_login 就是数据灾难）；
- 连不上 MySQL 时给出可操作提示（先 ./dev.sh 起库 / 用 TEST_MYSQL_DATABASE 覆盖），
  而不是抛一段 SQLAlchemy 原始堆栈。

验收：
- 全量 301 条通过，连跑两次结果一致（隔离有效），耗时约 12.5 秒（原 SQLite 约 3.6 秒）；
- 单文件独立运行通过（不依赖全量执行顺序）；
- `grep -rn sqlite tests/ conftest.py` 已无实际用法；
- **方言确实生效**：临时把一条查询改回 `NULLS FIRST`，13 条测试立刻变红（含运行期
  失败），还原即恢复；这条由 test_generated_sql_is_mysql_compatible 长期守着。

代价（已在 README 与规划附录 C.2 记明）：跑测试前必须先有 MySQL，pre-push 钩子
同理；CI 需要 service container。
 2026-10-02 21:22:08 +08:00
yml2213 5645f19102 docs(plan): P1b 小规模实测完成——20/20 全部重登成功 
按 §7.4.7 第一段跑实测，用现有手动重登链路（batch 65eda0142b4c）对 20 个
invalid 账号重登，两组各 10：A「还没在 attempt_* 时代重试过」、B「取码 bug
时代失败过」。

结果：
- 成功率 20/20 = 100%（历史推断只有 78%）；耗时 2 分 13 秒（约 9 个/分钟）；
- 极验滑块 0 次；邮箱取码全部正常 —— B 组全过，证实那 144 条「验证码失败」
  确实是 20261001 修掉的取码 bug 造成的，修复在生产生效；
- 20 个 CK 全部替换成功，ck_check_status 由登录流程自动改回 valid。

可救量由此从估的 1,050 上调到约 1,350；失败分型仍要做但属少数路径。
实测速度与零极验说明当前风控容忍度比预想高，全量仍建议限速（每小时
100~200 个起步，观察极验率再决定是否加速）。
 2026-10-02 20:46:17 +08:00
yml2213 9143a3afa0 docs(plan): 按线上实测重写 P1b 设计——失败分型，并把 P1b 提到 P1a 之后 
线上数据把 P1b 的必要性和设计都改了：

- 巡检只产出失效清单、不兑现修复，1,356 个失效账号仍要人工逐个选集→重登→过
  滑块，所以要把 P1b 提前（原计划等一到两周观察期，但检测准确性/误判封堵/
  失效性质三个前提都已验证完）；
- 更正一处误判：那 1,356 个失效账号不是「从未成功过」，而是「曾经成功、CK 放
  了一两个月过期」。依据是 LoginTask 全项目只在一处创建（登录成功写回处），
  导入账号不建 LoginTask；attempt_status='' 只说明成功发生在该字段出现之前；
- 失效应属会话级（斗鱼回「用户未登录」而非密码错误），用库里密码重登大概率
  可救；按历史数据真实成功率约 78%，预计 1,356 个里可自动救回约 1,050；
- 新增失败分型 relogin_failure_kind（决策 11a）：极验/凭证问题转人工，取码/
  中断/网络自动重试，配额满退避次日。线上 415 个失败里 64% 实为可自动解决
  （取码 bug 与重启中断），不分型会白费 265 个可救名额；
- 记录速率约束：13,618 账号对应 13,618 个独立邮箱（1:1），单账号配额满不影响
  他人；瓶颈在 IP，建议走代理池 + 限速 30~60/小时；
- 排期改为 P1a → P1b → P0 → P2 → P3 → P4，P1b 估 2.5~3 人日；附录 A 补 P1b
  迁移，上线按「小规模实测 → 限量开 → 全量」三段。
 2026-10-02 20:41:25 +08:00
yml2213 f8c5e896d4 fix(automation): 巡检区分「查不到」与「失效」，并在大面积失败时自动暂停 
P1a 原本把「检测没通过」一律写成 invalid。但 check_douyu_cookie 的失败分两类：
斗鱼明确回「未登录/登陆异常」（CK 真失效），以及请求超时/响应异常（我们查不到）。
一视同仁的后果是：斗鱼接口抖动或被风控时，每 5 分钟 200 个、一小时就能把两千多个
好账号标成失效，客服会误判成「CK 大面积挂掉」。规划里的失败率熔断只给了 P1b，
P1a 漏了。

改动：
- 新增 classify_result()：valid / invalid（命中斗鱼鉴权类说法）/ error（其余）；
- error 时**不覆盖该行原来的 ck_check_status**，只更新 ck_check_result（带
  verdict 字段）与 ck_checked_at，并计入本轮 skipped；
- 一轮 error 占比 > 30% 且条数 >= 20 时自动把作业 enabled 置 false，message 与
  detail.paused 写明原因，避免继续污染；
- 真实死号占比高**不触发**暂停 —— 首轮 100% invalid 是预期情况（选行「从没检测过
  的优先」，积压的是两个月前批量导入、attempt_status 为空、从未登录的陈旧账号，
  生产实测 200 条错误信息一致为斗鱼侧「用户未登录」）。

新增 6 条测试：分类正确性、error 保留原结论、异常不再标失效、大面积失败自动暂停、
真实死号不暂停。全量 271 条通过。
 2026-10-02 20:35:30 +08:00
yml2213 60f1a8d542 docs(plan): 记录 P1a 生产上线结果与首轮数据结论 
按施工单三段走完并验证：调度器启动、手动 50 条观察无风控、启用后调度器自动
接管（12:27:26 跑完 200 条 / 22 秒 / next_run_at 按 tick 推进）。

记录两点供后续参考：
- 上线过程中抓到两个只有生产才暴露的问题（MySQL 不认 NULLS FIRST、compose 的
  environment 是显式列表导致 .env 新增变量传不进容器），均已在 C.2 记档；
- 首轮 100% invalid 属正常且是价值所在：选行「从没检测过的优先」，而积压的
  1,897 条多为 2026-08-04 批量导入、从未尝试登录、CK 已两个月的陈旧账号，
  斗鱼侧统一回「用户未登录」，非风控。客服页会突然出现大批失效账号，属预期。
 2026-10-02 20:34:00 +08:00
yml2213 3d5d0f551f fix(automation): 去掉 MySQL 不认的 NULLS FIRST，排序改用可移植写法 
生产 MySQL 上手动跑第一轮就报 1064：

  You have an error in your SQL syntax ... near 'NULLS FIRST, login_tasks.id ASC'

NULLS FIRST 是 PostgreSQL/SQLite 语法，MySQL 不支持。本地测试全绿是因为跑在
SQLite 上（它认识这个语法），属于方言差异漏网 —— 生产是 MySQL、测试是 SQLite，
行为测试覆盖不到这类问题。

改成 `ck_checked_at IS NULL DESC, ck_checked_at ASC, id ASC`：三个方言下语义
一致（没检测过的优先）且都是合法 SQL。顺带把选行查询抽成 build_select_query，
便于按方言编译做回归。

新增回归测试：用 MySQL 方言 compile() 选行 SQL，断言不含 NULLS FIRST/LAST，
且「没检测过优先」用可移植写法表达。

规划附录 C.2 记下这条：写 SQL 前先确认方言；P0 连的是 order_site 的 PostgreSQL，
项目里已经出现 MySQL / SQLite / PG 三套方言。
 2026-10-02 20:14:49 +08:00
yml2213 f8a4a0baff fix(compose): 补齐自动化与 P0/P2 的环境变量透传，并放宽部署等待窗口 
部署 P1a 时发现两个问题：

一、compose 的 environment 是显式列表（不是 env_file），只写进 .env 不会传进
容器。于是 .env 里新加的 AUTOMATION_ENABLED=true 容器查不到，日志照旧打印
「AUTOMATION_ENABLED 未开启，自动化调度器不启动」——调度器根本没起。早先
§15.1 写入的 ORDER_SITE_* 与 OSS_* 也是同样情况，P0/P2 会直接踩到。

补齐 9 个变量的透传：AUTOMATION_ENABLED、ORDER_SITE_DATABASE_URL /
LOOKUP_ENABLED / LOOKUP_TIMEOUT_SECONDS、OSS_ENDPOINT / BUCKET /
ACCESS_KEY_ID / ACCESS_KEY_SECRET / PREFIX，全部带默认值（缺省即关闭或空），
不配置也不会让容器起不来。

二、deploy.sh 只等 15×2=30 秒就判「服务启动超时」，而 mysql 一起重建时应用
就绪约 35 秒，于是部署实际成功却报失败。等待窗口放宽到 40×2=80 秒。

规划附录 C.2 记下这条约定：新增环境变量要同时改 .env（实值）、
docker-compose.yml（透传）、.env.example（留档）三处。
 2026-10-02 20:12:24 +08:00
yml2213 7aaaeebe2b fix(automation): 修正调度口径——作业每 5 分钟跑一轮，interval_seconds 只是单行重检间隔 
P1a 把两个「间隔」混成了一个：next_run_at 用的是 job.interval_seconds，于是
作业 6 小时才跑一轮、每轮 200 条 = 800 条/天，全库 12,881 条要 16 天才能过
一遍 —— 等于没巡检，与规划里「账号 6 小时内被查一次」的目标差了两个数量级。

按规划原意修正：
- TICK_SECONDS 60 → 300：作业每个 tick（5 分钟）跑一轮；
- next_run_at 改为 finished + TICK_SECONDS，不再用 interval_seconds；
- interval_seconds 只作为「同一行多久重新检测」的选行 cutoff（选行逻辑本来就
  是这么用的，无需改）；
- 容量口径随之更新：5 分钟一轮 × 200 条 = 40 条/分钟 ≥ 需要的 36 条/分钟，
  冷启动约 5.4 小时覆盖全库，稳态每轮一百多条；
- 前端标签由「巡检周期(小时)」改为「单账号重检间隔(小时)」，说明文案写清
  「每 5 分钟跑一轮」，避免运维误以为是作业周期。

同步更新规划文档 §7.2/§7.3（含两个间隔不能混的说明）与附录 C 的三段上线
步骤（立即跑一次 → 每轮 50 观察 → 每轮 200 启用）。
 2026-10-02 19:54:31 +08:00
yml2213 2379598800 docs(plan): 记录迁移编号不能改名的坑，并说明应用过后的对齐做法 
P1a 的迁移先叫 20261002_0038，本地 dev 库应用过之后为保持链条连续改名成
0037，dev 库的 alembic_version 还记着旧编号，再启动就报
Can't locate revision identified by '20261002_0038'。

结论写进附录 C.1：编号要在被任何库应用之前定下来；已经应用过又必须改名时，
除改文件外还要把每个应用过的库 UPDATE alembic_version 对齐（前提是迁移内容
未变）。
 2026-10-02 19:48:47 +08:00
yml2213 f745a61df1 feat(automation): CK 自动巡检（P1a），只检测不改 CK 
后台原本靠人工逐批点「CK 检测」发现失效账号，1.2 万个账号根本盯不过来。
P1a 把「哪些账号失效了」自动化：自动挑久未检测的账号、调现成检测接口、
把结果写回 ck_check_*。**本作业不替换任何 CK**，重登仍由人工点，符合规划里
「先做只读/只提示，确认无误再做自动动作」的渐进上线原则。

实现：
- 迁移 20261002_0037：automation_jobs / automation_runs 两张表，
  login_tasks 加 relogin_attempts / relogin_next_at / relogin_last_error
  （为 P1b 备好），accounts 加 auto_managed（特殊账号不参与自动化）；
- services/automation/scheduler.py：进程内调度线程，60s tick，状态全部落库
  （重启不丢调度进度、不重复跑轮）；AUTOMATION_ENABLED 默认关闭，作业开关
  也默认关闭；ensure_jobs 只补缺失行、不覆盖运维改过的配置；
  作业异常只记 failed，不拖垮调度线程；单容器 --workers 1，无需分布式锁；
- services/automation/jobs/ck_health.py：选行口径与人工检测一致
  （cookie_holding_filter：持有 CK 且无在途尝试），叠加久未检测、
  auto_managed、batch_size，按 ck_checked_at 升序（最久没查的优先）；
  只写 ck_check_status / ck_check_result / ck_checked_at；
- routers/automation.py：GET /jobs、PATCH /jobs/{key}、POST /jobs/{key}/run、
  GET /runs；新增权限点 automation:view（运营可看）与 automation:manage
  （仅超管），改配置与手动触发都写审计；
- 顺带补 POST /api/login/batch 的审计（此前批次是谁发起、多少账号无据可查）；
- 前端 /automation 页：作业卡片（开关/周期/单轮条数/并发）、运行历史、
  「立即跑一次」；总开关未打开、调度线程未运行时给明确提示。

验证：
- 22 条新测试覆盖调度器行为（只跑到点的、异常不抛出、下轮时间、配置不被重置）、
  选行条件（在途尝试/auto_managed/间隔/batch_size）、接口与权限，其中一条
  专门断言巡检后 cookie/status/message/attempt_status 一字未动；
- 全量 257 条通过；前端 tsc 与构建通过；
- 端到端用 3 个真实账号跑真实斗鱼接口：巡检结果与直接调 check_douyu_cookie
  逐条一致（3/3 valid），CK 与尝试状态全程未变。

顺带修掉一处会炸生产的坑：DB 时间列读出来是 naive UTC，直接与
datetime.now(UTC) 比较会 TypeError，现统一走 _as_utc() 补时区。
 2026-10-02 19:47:41 +08:00
yml2213 6a62bbe70f docs(plan): 新增自动化与资料收集规划与皮肤准入映射分析 
把「CK 全靠人工维护 / 资料靠人转述 / 兑换无台账」整理成分期规划，并基于两套
线上库的实测数据定下关键口径。

数据结论（2026-10-02 实测）：
- order_site 271,134 单按履约路由二选一且完全不重叠：A 有 fulfillment_tasks
  85,338 单（88.3% 已 delivered，是发货平台的活）、B 有 work_orders 96,755 单
  （打手）、C 两者都无 89,542 单 —— 只有 C 是「没人管」，才是本系统的目标；
- 斗鱼可兑换商品只有 78 个（皮肤类 60）。C 桶皮肤类 923 个快手商品名映射过去：
  62 个唯一命中（27.7% 件数）、14 个命中多个（12.4%，需用户选）、847 个斗鱼
  兑不了（59.9%）—— 准入白名单以斗鱼商品目录为准，不匹配就不建单；
- order_items.spec_json 已带 sellerId/relItemId/relSkuId/skuNick，(itemId, skuId)
  才是单订单的精确定位键（4,092 个数字 skuId 中 89% 唯一），接单平台就是按
  sku_exact/sku_series 匹配的，本系统照此设计；
- CK 巡检规模 12,881 行（valid 10,079 / invalid 905 / 从未检测 1,897），按 6h
  周期反推 batch_size 应为 200 而非 50，否则实际周期被拉长到 21 小时。

规划要点：
- 与 order_site 整合选只读直连 PG：order_site 零代码改动，跨库 SQL 只允许出现在
  一个适配层文件里，另配降级开关与只读保护参数；
- P1 拆成 P1a（只检测、不改动任何 CK）与 P1b（自动重登，默认关闭），按「渐进
  上线」原则逐步减少人工；
- 用户截图一律进私有 OSS 桶 + 后端鉴权代理读图，不落本地磁盘；
- P4 的规则/模板/状态机对齐 order_site 接单平台：资料模板固定为游戏编号 +
  游戏昵称 + 主页截图，皮肤由订单号自动对应，仅多选类让用户选一件；
- 取消规则映射层（与 skin_aliases 职责重叠），规则直接挂 commodity_id，
  连带去掉 rule_ambiguous 状态。

三轮复核：① 补齐结构与缺口（术语表、P0 章节、权限表、配置清单、保留策略、
文案、测试计划、风险回退、迁移与文件清单、施工单）；② 逐条核对代码事实
（路径/符号/接口/字段/迁移 head/测试基线全部命中）；③ 找出并修掉 8 处实现级
矛盾（选择结果无处存、365 天命中的状态缺失、draft 悬空、多选回链断点、P4 与
P1b 排期矛盾、映射层重叠、P2 能力错位、用户回看链接缺失）。

含：docs/自动化与资料收集规划.md、docs/皮肤准入映射分析.md，并更新文档索引。
 2026-10-02 19:34:37 +08:00
yml2213 4518b726ac feat(huya): 浏览器兑换三目标直达并收窄扩展注入范围 
- 操作列改为「直播间 / 精英宝典 / 电竞宝典」三个直达按钮，点哪个就按哪个目标写入登录态并打开，去掉弹窗内选择
- 新增 services/huya_exchange_targets.py 统一三个目标地址，接口支持可选 body {"target": "..."}（不传=精英宝典）
- 扩展内容脚本从 <all_urls> 收窄到后台站点白名单，service worker 校验 sender.tab.url，拒绝其它来源的注入
- 注入改为 Cookie 写完后回执（ok/written/failed/error），前端按回执提示成功或失败，不再静默
- 扩展图标兜底改用 world:'MAIN' 读取；一个 Cookie 都没写成功时不打开目标页
- 兑换材料签发写审计 huya:exchange:kit（含账号与目标）
- 控制台脚本增加 huya.com 域校验与 Secure，与扩展路径保持一致
- 修复兑换记录轮询的跨账号串扰与卸载后 setState；兑换请求加 epoch 防止过期结果覆盖弹窗
- 新增 tests/test_huya_browser_exchange.py（13 项）并同步 docs/HUYA_BROWSER_EXCHANGE.md
 2026-09-11 10:31:46 +08:00
yml2213andCursor e81119117f feat(huya): 多选登录改单线程队列并拆分路由与工作台 
默认同时只登一个号，失败两次跳下一个，号间留间隔，结束后可一键重试失败账号。
顺带拆分虎牙路由与斗鱼工作台页面，并补齐 raw_cookie 重建入口。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-10 11:31:50 +08:00
yml2213 90a0065918 虎牙菜单按角色显示并修复确认框暗色模式 
客服在虎牙导航只显示浏览器兑换，管理员/运营保留完整入口；退出登录
与显示凭据确认框改用 App.useApp() 的 modal 实例以适配暗色主题；
版本号升至 0.3.0。
 2026-09-05 19:21:59 +08:00
yml2213 178eba1eea 浏览器兑换独立成页面并按斗鱼模式优化导入 
新增 /huya/browser-exchange 页面（精英宝典下方），支持导入账号与
执行兑换，客服仅见已分配账号；账号管理页移除该功能。导入弹窗对齐
斗鱼操作台：服务端分页筛选、可搜索标签、无 CK 不展示、导入本页/
一键导入全部/导入选中；新增 /accounts/ids 接口与 workbench
browser_exchange scope。
 2026-09-05 18:30:29 +08:00
yml2213 230d6c1918 虎牙人工兑换改用本机浏览器并新增扩展自动注入登录态 
移除服务器浏览器方案（容器/Xvfb/noVNC/CDP 会话管理），后端仅下发
兑换材料；新增内置 Chrome/Edge 扩展一键写入 huya.com 登录态，
未安装扩展时回退控制台脚本手动注入，兑换始终由用户手动完成。
 2026-09-05 17:55:31 +08:00
yml2213 aaaa568916 修正活动WSS会话guid一致性 2026-09-02 18:07:31 +08:00
yml2213 92ba6cbc62 闭合QIMEI h38兼容键 2026-09-02 17:51:12 +08:00
yml2213 1f3773de28 修正QIMEI UUID42随机段生成 2026-09-02 17:15:06 +08:00
yml2213 17ee943753 复刻QIMEI UUID42并默认使用无头浏览器 2026-09-02 16:59:46 +08:00
yml2213 c62c025ced 整理虎牙文档并接入设备画像指纹 2026-09-02 13:42:32 +08:00
yml2213 0d21a3fa09 trace文档补充：逆向生成器全链路验证通过（含真实兑换成功） 2026-09-01 23:53:28 +08:00
yml2213 8fef04d0af web_cookie_fields 用逆向算法替换随机：__yamid_new=UUIDv1时间戳复刻、game_did=35位63字符集、_yasids同源、_qimei_uuid42=1a前缀、guid回退加固定段 2026-09-01 23:48:00 +08:00
yml2213 8b24732c81 文档：网页设备字段溯源实证——5字段服务端下发/其余浏览器脚本生成，定位QIMEI SDK 0.6.3与guid固定段 2026-09-01 23:34:30 +08:00
yml2213 3ae1c3de1e 文档：浏览器注入ck未登录根因=domain需带前导点(.huya.com)，host-only仅主域生效 2026-09-01 23:02:40 +08:00
yml2213 0839fc5947 文档记录商品/兑换全链路验证：getActPrizeList/Detail/Records 全 200，scoreExchangePrize 往返成功(604积分不足) 2026-09-01 22:29:59 +08:00
yml2213 416dc2585b 文档补充三通道cookie依赖矩阵：商城WSS/HTTP RPC原始cookie即可，仅活动WSS需补齐 2026-09-01 22:23:13 +08:00
yml2213 9b0ef63eca 文档补充端到端验证：query_game_name/query_points 均 success 2026-09-01 22:16:38 +08:00
yml2213 5dc736516f 补齐网页Cookie缺失字段并接入会话自动预取guid 
- 新增 core/huya/web_cookie_fields.py：4 核心设备字段（guid 取自 wsLaunch 会话、
  _qimei_uuid42/__yamid_new/game_did 随机对齐格式）+ qimei 皮肤 + 22 个统计/会话字段
- elite_session 活动通道初始化时若缺网页字段，先 wsLaunch 预取服务端认可 guid，
  补齐 cookie 后重建会话；业务 RPC 统一走补齐后的 cookie
- 实测：账号 id=58（原始 16 字段登录态）checkUserBindGameAccount status=200
  （和平精英已绑定/收麦季）、getUserScore status=200（积分 4880）
- 附补齐方案与浏览器实测来源记录 docs/HUYA_CHAT_缺失字段补齐方案.md
 2026-09-01 22:12:58 +08:00
yml2213 727c32a5f5 接入匿名设备态协议补齐Cookie字段并放宽保存 2026-09-01 19:29:56 +08:00
yml2213 48c37bb8d7 虎牙网页Cookie来源驱动合并与WSS传输门禁 2026-09-01 19:17:32 +08:00
yml2213 24f312a3a9 更新虎牙宝典WSS接入进度文档 2026-09-01 12:25:34 +08:00
yml2213 c195430845 补充虎牙宝典全流程分析报告 2026-09-01 11:47:27 +08:00
yml2213 eb065a7c77 接入虎牙精英宝典最新商城前置流程 2026-09-01 11:42:52 +08:00
yml2213 684e16a07a 重构虎牙精英宝典协议与支付状态链路 2026-09-01 11:31:15 +08:00
yml2213 955ba45488 虎牙精英宝典 2026-08-31 19:34:59 +08:00
yml2213 76b14b69b7 修复虎牙手机号登录并统一部署项目名 2026-08-31 16:11:08 +08:00
yml2213 f4ed518b50 统一虎牙 App 登录设备画像 2026-08-30 23:04:28 +08:00
yml2213 47e19ed7b2 style: 统一 Ruff 代码格式 2026-08-30 21:04:52 +08:00
yml2213 a369829df3 docs: HDID32(t1.t0) 固定性终审 — app版本级常量, 证据链闭环; 更正 ID_NOMENCLATURE 陈旧结论 2026-08-29 17:15:22 +08:00
yml2213 f9d5868091 docs: sdid 前缀=hydevice SDK 协议常量定论 (16B固定密文头, 非设备关联) + 存量 device.json 补齐 2026-08-29 17:09:45 +08:00
yml2213 ff39a60a1d docs: 📋 登录系统全流程定案 (纯协议无卡点, 一号一设备方案, 工具索引) 2026-08-29 11:55:36 +08:00
yml2213 1a6711c180 docs: 绕过配方状态更正 (bypass_all 未验证, 以原版三脚本为准) + 三层健康检查工具 2026-08-29 11:44:54 +08:00
yml2213 5fa1f6d082 feat(dfp): 🔑 RC4 key=APK内嵌appkey常量(datadiv@3912240), 全流程零设备依赖闭环 (R38-R39) 2026-08-29 11:01:51 +08:00
yml2213 4868a3b0e8 feat(dfp): 🏆 dfpReport 加密完全攻破 — RC4+gzip, 12/12 密文解密+逐字节回验 (R35-R37) 2026-08-29 10:13:08 +08:00
yml2213 2fe23e4274 feat(huya): 💎💎💎 R34 会话密钥活体捕获成功 (P7TAzQYmX4O6i95q!) 
- Java.choose 堆枚举 @SSL_write 命中 = 密钥体系! (16字符随机, 每注册轮换)
- 多POST结构对比: 密文紧跟magic, 头版本位 01/11 变体
- Java Cprivate.a x 会话密钥 x 0-48切片 = 全null → 13.4.22传输≠Cprivate!
- hook_final/hook_brute 可复用捕获体系
 2026-08-29 09:10:57 +08:00
yml2213 0647c0c682 feat(huya): R33 45函数全零调用定论+第9密文(4036B,头89c8f5变体) 
- 25JNI+2XTEA核+16信封+2Java 全部安装且0调用
- 报告加密=防hook设计 (隐藏路径)
- 9密文集齐: 头变体 69c9f5/75c8f5/89c8f5 会话段逐注册变化
 2026-08-29 09:04:15 +08:00
yml2213 b76ec96573 feat(huya): R32 8密文集+三重钩全零调用定论+known-pair校准 
- 8活体POST存 evidence (magic 10B@70 一致, 头同族7cda11)
- 25 JNI + 2 XTEA核 + 2 Java = 全0调用 (报告=隐藏native路径!)
- rtk_known/ 44B known pair (native ct 45542bb3...) 后续差分用
 2026-08-29 09:01:51 +08:00
yml2213 08fcf5c34c feat(huya): 💎💎 R31 活体重抓3密文+Java全逆+native零调用铁证 
- 配方: frida-server -l 0.0.0.0 + 清状态(保留登录) + str_magic → 40s命中
- 3新POST (4384/4267/4261B, cipher@70) 存 evidence/dfp_live/
- Java Cprivate XXTEA + Perseus 会话密钥 + Lyra TLV 全解
- 报告加密 = 第三路径 (JNI族+XTEA核心+Java三重钩子全0调用!)
- cprivate.py 解密器就绪 (key一到即解)
 2026-08-29 08:53:31 +08:00
yml2213 5a138376ca feat(huya): 💎 JAVA侧全逆! Cprivate XXTEA+会话密钥架构+Lyra TLV格式 (R30) 
- Cprivate.java 加密/解密器全文 (XXTEA+MD5密钥变换+尾字长度)
- 密钥=SecureRandom 16字符[A-Za-z0-9] (guava.c内存明文! RSA封装上送)
- Lyra TLV: (type<<4)|tag, type 0-13 全表
- 捕获密文可用 Cprivate.a(data,会话key) 解密 - key在内存!
- 下一步: frida抓guava.c → 真key解密明文
 2026-08-29 08:12:10 +08:00