482 lines
30 KiB
Markdown
482 lines
30 KiB
Markdown
# 发现与决策
|
||
|
||
## 需求
|
||
- 用户要求先了解一个黑盒测试比赛。
|
||
- 当前工作区：`ksjsb`
|
||
- 工具目录：`D:\decode-tools`
|
||
|
||
## 研究发现
|
||
- 工作区初始可见文件：
|
||
- `ksjsb.apk`：约 108 MB，核心 Android 目标。
|
||
- `log-sdk.ksapisrv.com_2026_07_08_12_16_09.har`：约 11 MB。
|
||
- `nebula.kuaishou.com_2026_07_08_14_16_43.har`：约 164 MB。
|
||
- `2026-07-09-065602-ddecode-toolsfrida.txt`：约 340 KB，疑似 Frida 输出。
|
||
- `sign_layers_all.log`：约 1.7 KB，疑似签名链路日志。
|
||
- `1.txt`：约 11 KB，内容待确认。
|
||
- `D:\decode-tools` 已存在 Android/逆向相关工具：
|
||
- `apktool`
|
||
- `dex-tools-v2.4`
|
||
- `jadx-1.5.5`
|
||
- `jadx-gui-1.5.5-with-jre-win`
|
||
- `GDA4.04`
|
||
- `ghidra_10.4_PUBLIC`
|
||
- `ghidra_11.3.2_PUBLIC`
|
||
- `IDA_Pro_7.7_Portable`
|
||
- `IDA_Pro_8.3`
|
||
- `ida93sp2`
|
||
- `jeb-pro-3.19.1.202005071620`
|
||
- `x64dbg`
|
||
- `dnSpy-net-win64`
|
||
- `ILSpy_selfcontained_8.2.0.7535-x64`
|
||
- `out` 目录并非空目录，已有大量前序分析成果：
|
||
- `CURRENT_STATE.md`
|
||
- `FINDINGS.md`
|
||
- `FINDINGS_VM.md`
|
||
- `ks_sign.py`
|
||
- 多个 `probe_*.js`、`kste_*.log`、`xfalcon_*.log`
|
||
- `jadx`、`jadx16`、`manifest`、`so`、`dex` 子目录
|
||
- `1.txt` 明确给出目标：逆向快手极速版看广告接口的 9 个签名/加密参数，
|
||
包括 `sig`、`__NS_sig3`、`__NS_xfalcon`、`__NStokensig`、
|
||
`encData`、`sign`，以及 `egid`、`oDid`、`did` 设备指纹，
|
||
最终转换成 Python 纯算。
|
||
- `1.txt` 中的关键链路：
|
||
- `sig`：`fmm/{a,b,c,e,i}.getSig(明文)`，后端疑似 `doCommandNative`
|
||
- `__NS_sig3`：`fmm/g: k.b(sig1, path)`，`doCommandNative(10418)` / `libkwsgmain`
|
||
- `__NS_xfalcon`：`fmm/{a,b,c,e}: k.a(path, str)`，涉及 `kste VM` / `libksxgs`
|
||
- `__NStokensig`：`fmm/g: k.d(sig2, token)`，记录中判断为 `sha256(sig2+token)`
|
||
- `encData/sign`：疑似 `libpfl_crypto` 的 AES/HMAC 类逻辑
|
||
- `sign_layers_all.log` 显示已在设备 `PJZ110` 上对
|
||
`com.kuaishou.nebula` 及多个子进程进行了 Frida attach，
|
||
但该文件本身只有 attach/detach 记录，未见具体签名结果。
|
||
- 当前核心样本 SHA256：
|
||
- `ksjsb.apk`：`EBA577EF45CBA1715CC8C5562022AD5D4B10C1C442578F1C41BD3F05CCC33183`
|
||
- `log-sdk...har`：`7FBCA534370DA5D63694BBC75E341D91A9E12ED97229C04DFB58FA7AEF64754C`
|
||
- `nebula...har`：`57F5A07645C6758761E43102567AB8DE45423C364744351BE695D8A7A098FADE`
|
||
- APK 初筛结论：
|
||
- 包名：`com.kuaishou.nebula`
|
||
- 版本：`14.5.50.11631`，`versionCode=11631`
|
||
- 入口：`com.yxcorp.gifshow.HomeActivity`
|
||
- Application：`com.yxcorp.gifshow.App`
|
||
- SDK：`minSdk=21`，`targetSdk=30`
|
||
- 19 个 dex，约 100 个 arm64 native so，混淆强。
|
||
- 不是传统单一壳入口；更像大型业务包 + 自研安全/插件/热修复体系。
|
||
- 高关注 so：`libkwsgmain.so`、`libksxgs.so`、`libksse.so`、
|
||
`libw.so`、`libpfl_crypto.so`、`libsnow.so`、`libshadowhook.so`。
|
||
- Manifest 高关注：`allowBackup=false`，未显式 `debuggable`，
|
||
网络安全配置允许明文流量，debug-overrides 信任用户证书。
|
||
- HAR 初筛结论：
|
||
- `log-sdk...har`：681 entries；方法分布 `CONNECT=395`、`POST=146`、`GET=139`。
|
||
- `nebula...har`：1156 entries；方法分布 `CONNECT=567`、`GET=511`、`POST=76`。
|
||
- 高频业务 endpoint：
|
||
- `POST adlog.e.kuaishou.com/rest/nebula/log/ad/photo/action`
|
||
- `POST log-sdk.ksapisrv.com/rest/wd/common/log/collect/misc2`
|
||
- `GET nebula.kuaishou.com/rest/n/nebula/activity/earn/...`
|
||
- `POST /rest/e/reward/mixed/ad` 各 HAR 中各 1 条。
|
||
- 未发现 `Authorization` header；认证/会话主要在 `Cookie` 与 query/body。
|
||
- 高频签名/状态字段：`sig`、`__NS_sig3`、`__NS_xfalcon`、
|
||
`__NStokensig`、`egid`、`did`、`oDid`、`rdid`、`kuaishou.api_st`、
|
||
`client_key`、`cold_launch_time_ms`。
|
||
- 原样短期重放可能可行；改参稳定重放必须重算签名。
|
||
- 已验证的本地算法/脚本：
|
||
- `out/ks_sign.py` 可验证 `sig`、`__NStokensig`、`10400 encData`、
|
||
`10418 reward sign`、`10418 __NS_sig3` 的多组样本。
|
||
- `out/analyze_reward_samples.py` 共解析 3 条 `/rest/e/reward/mixed/ad`
|
||
POST 样本，`sig_reward_form` 全部匹配。
|
||
- `out/test_live_reward_log.py`、`out/test_reward_sig.py`、
|
||
`out/test_build_reward_request.py` 等单测均通过。
|
||
- 当前算法完成度：
|
||
- `sig = MD5(sorted(query + formBody, skip sig/sig2/__NS*) + "772867c19925")`
|
||
- `__NStokensig = SHA256(sig + clientSalt)`
|
||
- `encData = Base64(kwsg 10400 raw)`，`strE -> 0x266fc block -> inner ZT -> outer ZT`
|
||
- `body.sign = kwsg 10418 true-mode(strE, sdk=95147564-...)`
|
||
- `__NS_sig3 = kwsg 10418 false-mode(path + sig)`
|
||
- `__NS_xfalcon` reward/API 输入链路已接入本地 core 计算。
|
||
- reward 广告拉取 strE 已能按当前账号/设备动态生成，并接入
|
||
本地 `encData/sign/sig/sig3/tokensig/xfalcon`。
|
||
- 轻量在线验证中，普通广告/签到广告/宝箱广告拉取均返回
|
||
`HTTP=200 result=1 msg=OK`，说明动态 reward body 已解决
|
||
换设备后的 `ANTISPAM_REQUEST/INVALID_REQUEST`。
|
||
- `did/oDid/rdid` 已可本地生成；`egid/cloud did` 已可通过 DFP
|
||
bootstrap 在线注册并覆盖；仍需继续处理 H5 `__NS_sig3/kww` 的
|
||
动态生成。
|
||
|
||
## 技术决策
|
||
| 决策 | 理由 |
|
||
|------|------|
|
||
| 优先做被动侦察 | 当前已有 APK、HAR、Frida 日志，足以先建立证据图 |
|
||
| 并行拆分子任务 | APK、HAR、日志、工具链互不依赖，可独立读取分析 |
|
||
| 主线从 `out/CURRENT_STATE.md` 等已有成果恢复 | 避免重复劳动，当前证据显示已有较深入的 xfalcon/kste 分析 |
|
||
| 暂不主动请求生产接口 | 当前阶段目标是了解和复核；主动重放可能消耗账号/服务端状态 |
|
||
|
||
## 验证结果
|
||
- `python out\ks_sign.py`：通过，输出多项 `[OK]`。
|
||
- `python out\test_reward_sig.py`：退出码 0。
|
||
- `python out\test_live_reward_log.py`：4 tests OK。
|
||
- `python out\test_analyze_xfalcon_te.py`：3 tests OK。
|
||
- `python out\test_build_reward_request.py`：1 test OK。
|
||
- `python out\test_extract_kste_vmobj_log.py`：1 test OK。
|
||
- `python out\analyze_reward_samples.py`：解析 3 条 reward 样本，
|
||
`sig_reward_form ok=True`，`__NS_sig3_calc ok=True`；其中一条
|
||
`tokensig` 不匹配当前 `CLIENT_SALT`，判断为不同账号/会话上下文。
|
||
|
||
## 遇到的问题
|
||
| 问题 | 解决方案 |
|
||
|------|---------|
|
||
| 当前目录不是 Git 仓库 | 不使用 Git 作为变更依据 |
|
||
| `.codex\skills\.system\using-superpowers` 不存在 | 改读 `.agents\skills\using-superpowers` |
|
||
|
||
## 2026-07-27 - passport_account_image 纯算结论
|
||
|
||
- `passport_account_image` 由客户端 `Engine.pr(99999, 0, mf.a().toString().length()*2, json)`
|
||
确定性生成，不是 `/f/a/p` 服务端签发或回写票据。
|
||
- 基础层是 `VIMG_` + Base64：固定头、Modified UTF-8 长度与正文经 `0x55` XOR，
|
||
再进入自定义状态的 ChaCha20-IETF。
|
||
- `$AI_` 由基础层文本经 16-word XOR 折叠、自定义 IV BLAKE2s 压缩和固定 H2
|
||
混合生成；跨 64-word 块使用累计 word counter。
|
||
- 21 组不同长度输入与 arm64 `libweapon.so` Unicorn oracle 完全一致。
|
||
- CLI 默认按当前 `DeviceProfile` 和现场时间纯算，不读取 app-fields，也不依赖
|
||
Frida、抓包、APK、ELF 或 Unicorn 运行时。
|
||
|
||
## 资源
|
||
- `D:\decode-tools`
|
||
- `ksjsb.apk`
|
||
- 两个 HAR 文件
|
||
- 已有 Frida/签名日志
|
||
|
||
## capture/ 登录链路 + APP 初始化实测（2026-07-23）
|
||
|
||
- 抓包：`capture/` Reqable body-only 导出（1738 文件，**无 URL/header/method**，
|
||
仅 req/res body；请求体多为 kwsg 加密）。
|
||
- 抓的是**全新装机**：`did=ANDROID_f05497e9cef09a7f`（与 `.env` 账号
|
||
`e8dfd2f16b618053` 不同），06:32 冷启动，启动时 `uid=0`（未登录）。
|
||
- 混入少量酷狗（`com.kugou.android`，flow 466/467）噪声；主体快手 nebula。
|
||
- APP 初始化（已定位）：
|
||
- DFP 设备注册 flow 189：`productName=NEBULA&ts&deviceInfo=<urlenc>`
|
||
（= `gdfp_report`/`unified_fetch`，已还原于 `core/dfp_forms.py`）。
|
||
- 配置拉取 flow 171：`public_param{uid:0,...}+request_info[{config}]`。
|
||
- 域名-IP 路由表 flow 272/274：`domains[]{domain,iplist}`（含
|
||
`api.e.kuaishou.com`、`id.kuaishou.com`，**非登录**）。
|
||
- **登录方式 = 运营商一键登录**（非手机号短信）：
|
||
- flow 221（登录提交，请求体明文 + 已还原签名）：
|
||
`provider=11 & provider_token=<protobuf> & session_id & sig & __NS_sig3
|
||
& __NS_xfalcon & client_key=2ac2a76d & os=android`。
|
||
- `provider_token` base64 解码 = protobuf `{kpn="NEBULA",
|
||
did="ANDROID_f05497e9cef09a7f", ts, nonce}`，由运营商一键登录 SDK
|
||
签发，绑定设备 did。
|
||
- `sig/__NS_sig3/__NS_xfalcon` 全部可用已还原算法复算。✓
|
||
- 响应：`{"result":1,"bind_interval_ms":604800000}`（设备绑定 7 天）；
|
||
会话在 flow 222 `{"dataRsp":"<576B加密>","result":1}` 内。
|
||
- **会话票据 = libpfl_crypto 层，未纯 Python 还原**：
|
||
- `dataRsp`（576B）`head8=7a1c41a6...`，**不属于**已还原的 kwsg 10400
|
||
ZT envelope（其 `head8=5a54eecd...`，见 `core/enc_data.py:ZT_OUTER_CONFIGS`）。
|
||
- 历史 `Pfl.decryptBinaryNative` 用的是 native 桥，纯 Python 解密未还原。
|
||
- `api_st`/`h5_st` 也可能下发在响应 header（body-only 抓包不可见）。
|
||
- 交叉验证 `out/FINDINGS.md:2476-2504`：直接换 H5 did/egid ->
|
||
`signIn/report`、`treasureBox/report` 返回 `result=50 签名验证失败`；
|
||
H5 真正缺口是 `kwssectoken/kwscode/kwfv1/kww`（Yoda/KsGuard/WebView
|
||
运行时票据），**不在 HTTP body 抓包**（`kww` 实为请求 header）。
|
||
- "新设备纯 Python 登录"三阻塞点：
|
||
① 运营商 `provider_token`（外部黑盒，需 SIM+设备）；
|
||
② `dataRsp` libpfl 解密（未还原纯 Python）；
|
||
③ `kwssectoken/kwscode/kwfv1/kww`（WebView 运行时票据，H5 换设备必 result=50）。
|
||
- 详见 `docs/capture_login_chain.md`。
|
||
|
||
## 视觉/浏览器发现
|
||
- 暂无。
|
||
|
||
## 2026-07-27 - region_ticket 静态逆向
|
||
|
||
- `pnm.b.b(-1479227965)` 绑定到
|
||
`com.kwai.framework.network.access.params.e`；其 `l0()` 仅从
|
||
`DefaultPreferenceHelper[<uid>_Region]` 读取 `Region.ticket`。
|
||
- `ResponseDeserializer` 从所有统一响应的顶层 `region` 读取
|
||
`uid/name/ticket`，`u0a.f` 注册的全局 `regions.c` 随后调用
|
||
`o2a.c.c(region, "New region received")` 持久化。
|
||
- `v0a.c` 把非空 ticket 序列化为请求 Cookie 的 `region_ticket`；没有
|
||
客户端生成、签名或 native 计算链。
|
||
- `RegionInfo` 的 APK 预置资源只有 API group/host 路由映射，没有 ticket。
|
||
- 全部 7 个 HAR 共 8334 entries：响应 `region.ticket=0`、响应
|
||
`Set-Cookie=0`、请求 Cookie 命中 362；共 12 个唯一票据，全部为
|
||
`RT_ + 73 hex`、总长 76。抓包开始时状态已经存在，未覆盖首次签发。
|
||
- 结论：纯 Python 应实现服务端 Region 的接收、按 UID 保存和复用；没有
|
||
本地等价生成算法。缺少该 Cookie 是 APP/CLI 差异，但不能据此单独解释 705。
|
||
- 详见 `docs/region_ticket_static_chain.md`。
|
||
|
||
## 2026-07-28 - keyconfig 与登录 query 必须分开建模
|
||
|
||
- APP 最终登录请求的 query 不包含 `client_key/os`；这两个字段由登录接口的
|
||
form body 承载，因此 `login_api_params()` 已正确排除它们。
|
||
- `system/keyconfig` 与登录接口只共享设备参数子集。APP 抓包显示 keyconfig
|
||
query 必须包含 `client_key=2ac2a76d` 和 `os=android`。
|
||
- 此前 `refresh_region_ticket()` 直接复用 `login_api_params()`，登录参数对齐后
|
||
意外导致 keyconfig 丢失上述两个字段，服务端 HTTP 200 但响应不含 Region。
|
||
- 已新增独立 `keyconfig_api_params()`，仅为 keyconfig 补回 `client_key/os`；
|
||
同时保持 `oaid/countryCode/sid/deviceName` 不进入该 query。
|
||
- APP 成功样本没有调用 `/rest/zt/pass/refresh/anonymousToken`，该接口不是当前
|
||
短信登录链路的前置条件。
|
||
- 修复只解释最新日志中的 `region_ticket present=False`。历史实测在已有有效
|
||
Region、KAW/KAS、VIMG 时仍可能返回 `705`，该部分仍属于服务端设备风险判定，
|
||
不能用本次 keyconfig 修复宣称已经解决。
|
||
|
||
## 2026-07-28 - 705 验证完成后的 captcha_token 重放
|
||
|
||
- `jlm.a.execute()` 是 APP 的通用 Retrofit Call 包装器；其字段
|
||
`f176918d` 非空时会把值以 `captcha_token` 追加到 FormBody/MultipartBody，
|
||
然后执行被包装的原请求。
|
||
- 浏览器链路先由 `kSecretApiVerify` 返回 `captchaToken`，再用该 token 调用
|
||
`/rest/wd/captcha/verify` 完成 challenge 绑定。APP 随后不是只同步 Cookie，
|
||
而是把同一个 token 注入原 API 表单并重新经过签名拦截器。
|
||
- CLI 旧实现已经捕获 token，但 `_complete_captcha_handoff()` 只返回布尔值，
|
||
token 在 checker/login 重试前被丢弃；因此重试请求仍没有 `captcha_token`，
|
||
服务端返回新的 705/key。
|
||
- `mobile_checker()`、`login_by_code()` 及其路径包装器现已支持
|
||
`captcha_token`，该字段参与 `sig/__NS_sig3/__NS_xfalcon/KAS` 的重新计算。
|
||
- `system` 浏览器模式改为启动独立系统 Edge/Chrome 并通过本地 CDP 观察响应，
|
||
保留可见人工滑动窗口，同时能回传 token 和 Cookie。
|
||
|
||
## 2026-07-28 - CAPTCHA WebView 设备身份绑定
|
||
|
||
- 用户实测已经证明 `captcha_token` 被捕获并注入原接口，但每次重放仍得到新的
|
||
705/key；因此“缺少 captcha_token”只是先前缺口，不是当前剩余根因。
|
||
- APP 静态链路在 WebView 导航前通过 `CookieInjectManager` 注入公共参数。
|
||
`com/yxcorp/gifshow/webview/cookie/f.smali` 明确把 `sys/appver/did` 设为高优先级，
|
||
`und/b.smali` 的公共列表还包含 `kpn/kpf/userId/c/ver/language/countryCode/mod/net`。
|
||
- CLI 的临时 Edge/Chrome 画像此前没有预注入 Cookie，验证码页会建立 `web_*` DID；
|
||
`/rest/wd/captcha/verify result=1` 只证明 Web 挑战成功，不能证明返回 token 与
|
||
原 API 的 `ANDROID_*` DID 属于同一身份。
|
||
- 验证浏览器现会在首次导航前注入 APP 同形态匿名身份 Cookie，并在成功响应后
|
||
校验浏览器 DID 必须仍等于设备画像 DID。页面若改写为 `web_*` 或删除 DID，
|
||
CLI 会停止重放并报告身份不一致，避免继续生成无效的新 challenge key。
|
||
- 当前没有证据表明还缺某个普通 HTTP 请求头；APP 每次重试本来就会重新生成
|
||
`X-REQUESTID`。后续实测应以 `device_identity=matched` 和原接口不再返回新 705
|
||
作为联合成功条件。
|
||
|
||
## 2026-07-28 - 10418 进程状态连续性
|
||
|
||
- 最新实测已经达到 `/rest/wd/captcha/verify result=1`、`captchaToken` 回传、
|
||
39 个 Cookie 同步和 `device_identity=matched`，但重放仍生成新的 705 key；
|
||
因此普通 header、滑块求解和 Web/Android DID 不一致均不再是首要假设。
|
||
- 代码审计发现每个短信端点都会调用 `_sig3_state(session_seed)` 创建新对象，
|
||
导致 checker、验证码重放、发码和登录的 10418 counter 全部重复从 1 开始。
|
||
- APP 捕获证明 10418 是进程级全局状态：新进程首次可见 counter 约为 `0x60`，
|
||
后续请求严格递增；seed 也不是固定 `0x5d7e742b`。
|
||
- 捕获的 `session_seed=0x6f5d0faa` 可由进程启动秒 `1785049292` 经 Android
|
||
bionic/BSD `srand(time); rand()+1` 精确复现，确认了动态 seed 的来源。
|
||
- CLI 现为每次运行创建一份新鲜 `Kwsg10418State`，默认从启动后基线 `0x5f`
|
||
开始，并在整条短信链共享；`--session-seed` 和 `--sig3-counter` 可用于样本回放。
|
||
|
||
## 2026-07-28 - 705 重放结构与实际出站诊断
|
||
|
||
- 最新实测中动态 sig3 seed/counter 已启用，浏览器绑定仍为 `result=1`，但 API
|
||
重放继续返回新 705；因此 sig3 状态重置不是当前剩余根因。
|
||
- APP 的 705 链通过 `retryWhen` 重新订阅，并在每次订阅时克隆 Retrofit Call；
|
||
`NetworkSequenceIdInterceptor` 还会重新生成 `X-REQUESTID`。CLI 每次重放生成
|
||
新请求 ID 与 APP 一致，不能复用首次请求 ID。
|
||
- 705 Activity 回调只把 `RETURN_RESULT` 写入 `jlm.a` 的 token 字段；随后
|
||
`jlm.a.execute()` 只向原 FormBody 追加 `captcha_token`。没有 CAPTCHA 专用
|
||
query、header 或 cookie，因此继续猜测额外验证码字段缺少静态依据。
|
||
- `_do_post()` 现从 `requests.Response.request` 读取实际出站请求，脱敏记录：
|
||
header 名、body 字段顺序、Cookie 名、captcha token 长度/摘要、请求 ID、
|
||
sig3 seed/counter 和 HTTP 版本。不会记录手机号、Cookie 值或 token 明文。
|
||
- 浏览器绑定成功日志也打印同算法的 token SHA-256 短摘要；它应与随后
|
||
PreparedRequest 中的摘要一致，从而直接验证 token 交接未被替换或损坏。
|
||
- 当前 CLI 使用 `requests`，通常通过 HTTP/1.1 和 Python/OpenSSL 指纹访问；APP
|
||
使用 OkHttp/BoringSSL 且可协商 HTTP/2。若下一次诊断确认 token/body/Cookie
|
||
均正确但仍为 HTTP/1.1，传输指纹将成为优先假设，但尚未用同请求 A/B 实测证明。
|
||
|
||
---
|
||
## 2026-07-28 - 705 传输层 A/B
|
||
|
||
- 用户最新日志证明浏览器绑定 token 与实际 POST 中的 `captcha_token` 摘要完全
|
||
一致，Region、KAW/KAS 和动态 sig3 counter 也都存在；应用层交接已闭环。
|
||
- 静态确认 APP 的 OkHttp 默认协议顺序是 HTTP/2、HTTP/1.1，且 Aegon 的
|
||
`CronetInterceptor` 可能接管请求并动态选择 QUIC/H2/TCP；所以 APP 不是简单的
|
||
“固定 OkHttp HTTP/2”。
|
||
- 登录通用链不会添加 `Accept`。原 `requests.Session` 自动携带的
|
||
`Accept: */*` 是已确认的出站差异。
|
||
- 新增显式 `--transport okhttp4-android10` A/B 路径，使用 curl_cffi 官方文档的
|
||
OkHttp 4 Android 10 JA3/Akamai 参考配置，并优先协商 HTTP/2；默认仍保留
|
||
`requests`，便于同一业务输入做单变量比较。
|
||
- HTTP/2 适配层移除 framing 层禁止的 `Connection`，关闭 curl_cffi 浏览器默认
|
||
headers，保留现有表单原始字节、CookieJar、签名和验证码 token。
|
||
- 该参考配置不等于 APP 的精确 Aegon/Cronet 指纹。若 A/B 仍返回 705，应采集
|
||
APP 实际 ALPN/JA3/HTTP2 SETTINGS 后再替换 profile，不能据此倒推缺业务字段。
|
||
|
||
## 2026-08-27 - 签到/签到看视频 H5 链路 → ksjsb.py
|
||
|
||
- 新抓包 `签到_2026_08_27_14_50_32.har`(428 条)/`签到看视频_2026_08_27_14_51_46.har`
|
||
(307 条),App ksNebula/14.6.50.11735、Yoda WebView Chrome/121、userId=5402308233。
|
||
- 签到链(全部 Yoda WebView H5,非原生 API):
|
||
- `overview/popup` 响应 `data.unionSignInPopup.button.eventTrackingLogInfo`
|
||
(deliverOrderId=5118, EXTERNAL_SIGN_POPUP)是 `signIn/report` 的
|
||
`eventTrackingLogInfo` 来源;上报前在 `extParams` 追加 `source`。
|
||
- `signIn/report` 为 GET + query eventTrackingLogInfo,响应
|
||
`reportRewardResult.eventTrackingAwardInfo.awardInfo[].amount` 即奖励。
|
||
- 签到看视频链:`signIn/showPopup` 响应按钮(text=去看视频)的
|
||
`eventTrackingLogInfo`(deliverOrderId=2044, SIGN_IN_BUTTON_60038_RPC,
|
||
businessPriceUniqueId 服务端每次下发)→ `POST
|
||
/rest/wd/usergrowth/encourage/matrix/resource/action`
|
||
body=`{"actionType":1,"resourceSlotInfo":<slot+source>}`。
|
||
- 看视频奖励由第三方 CPX 广告(通义 TONGYI)S2S 回调发放
|
||
(`ad.partner.gifshow.com/track/activate?callback=...&event_type=84`),
|
||
明文抓包中无客户端领奖请求;`businessPriceUniqueId` 是回调绑定键。
|
||
- H5 sig3 纯算链对新端点交叉验证:抓包 query+cookie(document.cookie
|
||
编码值,如 `mod=OnePlus%28PJZ110%29`)重建 sign_input,CRC32 与
|
||
showPopup/report/popup(含 notificationKey)/signIn_resource/matrix action
|
||
(POST+JSON body)共 5 类真实 sig3 内嵌值完全一致;counter 进程级
|
||
101→121 单调递增。
|
||
- `multi-az-hebei-webh5.kuaishou.com` 是抓包代理的域名映射,真实
|
||
Host/Referer/Origin 均为 `nebula.kuaishou.com`。
|
||
- 交付:`ksjsb.py`(独立运行,不读 HAR;复用 core H5 纯算链)+
|
||
`tests/test_ksjsb.py`(8 用例:URL/键序黄金值、CRC 交叉验证、body
|
||
逐字节一致、sig3 往返+counter 递增、dry-run 无网络冒烟)。
|
||
|
||
## 2026-08-27 - 开宝箱/看广告 HAR → ksjsb.py 重写为顺序任务脚本
|
||
|
||
- 新增抓包: `开宝箱_15_01_21`、`开宝箱看广告_15_02_14`、`看广告得金币+打开
|
||
广告详情_15_04_32`(与上午同设备/账号会话,sig3 counter 连续递增到 162)。
|
||
- 宝箱冷却规则(treasureBox/info 响应): `remainSeconds=0 & status=3` 可开,
|
||
`remainSeconds=300 & status=2` 冷却中; `rewardCount` 当前宝箱金币。
|
||
- 开宝箱链: 任务列表宝箱挂件位(dailyTasks[].extParam.eventTrackingLogInfo,
|
||
taskId 20022)→ matrix/resource action(ext 追加 threshold/thresholdTaskId/
|
||
source)→ treasureBox/report(body 复用 info 响应 eventTrackingLogInfo
|
||
(taskId 20035)+source); 响应 `data.title.rewardCount` 即到账金币,
|
||
开箱后按钮 linkUrl(base64)=matrixMixedAd 广告跳转参数
|
||
(11101/100024064/20346/606,与 main.py AD_FETCH_FALLBACK_SCENE 一致)。
|
||
- 看广告得金币: overview/tasks dailyTasks[0](TASK_LIST_17_672_CD_PROGRESSING)
|
||
的 eventTrackingLogInfo 先做 matrix 点击上报, 再走原生广告链(拉取/播放/
|
||
上报全部在 tm-s.xxpkg.com:13500 隧道内,明文不可见;复用 main.py 已在线
|
||
验证的 reward/mixed/ad + ad/task/report 机器)。"打开广告详情"为第三方
|
||
广告 SDK 落地行为(meituan/qianwen),不在脚本范围。
|
||
- CRC 交叉验证新增 6 端点全对: treasureBox/info(可开/冷却两种状态)、
|
||
treasureBox/report(POST+JSON body)、matrix action(宝箱点击/开箱后/
|
||
任务点击)。body 键序细节: matrix 点击的 extParams 中 threshold/
|
||
thresholdTaskId 在 source 之前(抓包 #115)。
|
||
- `ksjsb.py` 重写为无 CLI 顺序任务脚本: 余额 → task_list(广告上下文)→
|
||
签到(showPopup 查 todaySigned,未签才 report)→ 开宝箱(冷却检查)→
|
||
看广告 random(20,30) 次(冷却等待重试,拉取失败提前结束,每 5 次刷新
|
||
任务列表)→ 最终余额。复用 main.KsNebulaClient 全部机器,子类 KsJsB
|
||
注册 2026-08-27 新指纹 header 模板(Chrome/121, per-run PxSessionId)。
|
||
- `tests/test_ksjsb.py` 重写为 11 用例: 6 个 URL/body 黄金值、7 端点 CRC
|
||
交叉验证、sig3 往返+counter 递变、资源位提取、顺序流程 dry-run 冒烟。
|
||
|
||
## 2026-08-27 - ksjsb.py 改为完全单文件(零项目内依赖)
|
||
|
||
- 用户要求: 不依赖 main.py/core,以 HAR 为准。重写为单文件(623KB),
|
||
唯一依赖 `requests`;零 `main`/`core` import(已验证)。
|
||
- 关键工程点: KWSG T1/T2 分组密码表(A=10400/true-mode sign, B=10418
|
||
sig3)无法纯算重建,以 base64 内嵌(147456+41216 字节 ×2);其余算法
|
||
全部内联: 10400 ZT envelope、10418 digest/state/时间驱动 seed、reward
|
||
sign、xfalcon(自定义 IV BLAKE2s + $TE_)、Weapon kaw/kas、KWF AES+
|
||
自定义 base64 kww、WebWeapon kws 票据、H5 sig3 envelope+双层 SHA、
|
||
API sig/tokensig/signed_api_url、reward strE、广告素材提取/上报 biz。
|
||
- 算法黄金值回归(与 core 逐位一致): 4 张表==bin 文件、10418 digest、
|
||
reward sign、10400 raw、report encData wrapper、xfalcon value、H5
|
||
sign_input/digest field/from_fields、kww、kas、signed_api_url(含
|
||
sig3; 需固定 unix_time 才可黄金化,已加透传参数)。
|
||
- H5 sig3 counter 依 2026-08-27 抓包改为递增(100+rand 起步,真机
|
||
101→162);elapsed=(开机秒<<16)|ms;state=0x10000|16bit 随机;seed
|
||
每次运行随机(新页面会话)。
|
||
- 传输层差异(已标注 TODO): API 请求用 requests/HTTP1.1,真机为
|
||
OkHttp/Cronet;Accept-Encoding 降级 gzip,deflate(无 brotli)。
|
||
- `tests/test_ksjsb.py` 只 import ksjsb(17 用例,单文件自洽证明):
|
||
6 URL/body 黄金值、6 端点摘要字段交叉验证、5 组算法黄金值、
|
||
sig3 往返+counter 递增、资源位/场景提取、dry-run 全流程冒烟。
|
||
全套件 289 用例,仍只有 4 个存量失败(test_main 导入、sms_login
|
||
captcha auto_solve 签名),无新增。
|
||
|
||
## 2026-08-27 - 在线首跑复盘 + 诊断日志
|
||
|
||
- 用户实测(账号 userId=1579452490/vivo): basicInfo/task_list OK;宝箱
|
||
matrix 点击 result=6001 但 treasureBox/report **开箱成功 +539 金币**
|
||
(证明点击上报非必需);广告 matrix 点击与 reward/mixed/ad 拉取均
|
||
result=6001,循环终止;签到 showPopup 无资源位(弹窗已关闭场景)。
|
||
- 历史抓包中 matrix/ad fetch 全部 result=1,6001 为脚本请求特有的
|
||
业务/风控拒绝;jadx/HAR 中无 6001 定义。候选根因:当日广告任务已完成
|
||
(该账号今日已重度使用)/传输指纹(requests HTTP1.1)/uQaTag 为 7 月
|
||
旧设备样本。待用诊断日志定位。
|
||
- 脚本改进:
|
||
1. 每请求 JSONL 诊断日志(out/ksjsb_replay_*.jsonl,完整 URL/body/
|
||
响应,仅脱敏 api_st/token 等登录票据;KS_RECORD_FILE=0 关闭)。
|
||
2. 签到判定: showPopup.todaySigned -> 弹窗关闭时回退 overview/popup
|
||
的 unionSignInPopup 资源位 -> 任务列表 20022/60038 任务在
|
||
finishedTaskList 则确认已签。
|
||
3. matrix 点击降级 best-effort: 失败一次即停发(避免重复触发风控),
|
||
不影响领奖流程。
|
||
4. 广告拉取 6001 时输出明确诊断(任务不可用/风控)并终止循环。
|
||
5. API body 字段序对齐真机抓包: cs, client_key, videoModelCrowdTag,
|
||
os, kuaishou.api_st, uQaTag, token(此前 api_st 在 uQaTag 后)。
|
||
|
||
## 2026-08-27 - 6001 根因定位(诊断日志 diff)
|
||
|
||
- 第二次在线跑(任务可用: 看广告任务 status=1 completed=0)仍 6001,
|
||
排除"任务已完成"。JSONL diff 发现两处与真机抓包的实质偏差:
|
||
1. **API query 多了 `sid` 和 `deviceName`**: 真机 reward/mixed/ad 与
|
||
ad/task/report 的 57 键参数集从不包含这两键(全部历史 HAR 实证);
|
||
系 main.py `_api_params` 从 cookie 盲目带入的偏差。已移除并加
|
||
参数集回归测试。
|
||
2. **`uQaTag` 设备错配**: 旧值 `DP:3hX9ONf4GgQ...` 是 7 月 OnePlus
|
||
设备的 QoE 采集态标签,现配 vivo 设备身份。2026-07-08 抓包实证
|
||
QoE 未采集的合法回退形态 `1##DP:null#ecBl:00#ecPp:--#cmNt:-1#
|
||
cmMnsl:-0` 被 result=1 接受且设备无关 —— 已改为默认值,
|
||
`KS_UQA_TAG` 可覆盖。7 月 main.py 在线验证通过时账号设备恰好与
|
||
uQaTag 同为 OnePlus,佐证设备绑定假设。
|
||
- matrix 点击 6001 与此独立(H5 端点,无 uQaTag);保持 best-effort。
|
||
- 待用户下次在线验证两处修复是否消除 ad fetch 6001。
|
||
|
||
## 2026-08-27 - 6001 第三轮: 传输指纹 + 设备一致性修复
|
||
|
||
- 第二轮修复(去 sid/deviceName、uQaTag null 形态)经日志确认已生效但
|
||
ad fetch 仍 6001 —— 排除参数集/标签问题,剩余嫌疑集中在传输指纹与
|
||
设备一致性。第三轮修复:
|
||
1. API 请求默认走 **OkHttp4/Android10 TLS 指纹 + HTTP/2**
|
||
(curl_cffi 0.15 已内联封装, 不可用时回退 requests,
|
||
KS_API_TRANSPORT=requests 可强制 A/B)。
|
||
2. `X-Client-Info.model` 从 cookie `mod` 括号内型号动态生成
|
||
(vivo(V2408A)->V2408A), 修复此前硬编码 PJZ110 与 vivo 设备的
|
||
头部错配。
|
||
3. 签名参数追加序对齐抓包: sig, __NS_sig3, __NS_xfalcon,
|
||
__NStokensig(此前 tokensig 在 xfalcon 前)。
|
||
- 黄金值回归: signed_api_url 的 sig/sig3 值不受参数序调整影响(逐位
|
||
不变); 19 项单文件测试 + 全套件 291 用例无新增失败。
|
||
- 待第四轮在线验证。若 okhttp 指纹下仍 6001, 剩余候选:
|
||
strE 内嵌 network_ip(硬编码 172.31.230.147, 可 KS_AD_NETWORK_IP
|
||
覆盖为出口公网 IP)、egid↔did 绑定状态、10418 seed/counter 模式。
|
||
|
||
## 2026-08-27 - 6001 第四轮: 版本对齐 + API 金丝雀探针
|
||
|
||
- okhttp 指纹 + X-Client-Info 修复后仍 6001。第三轮日志排查发现:
|
||
`appver=14.5.50.11631/ver=14.5`(cookie 7 月导出的旧版本号, 真机
|
||
当前 14.6.50.11735)与 `kcv=1627`(默认值, cookie 实为 1630)。
|
||
- 修复: API `appver/ver` 默认对齐 2026-08-27 抓包版本(14.6.50.11735,
|
||
KS_APPVER 可覆盖), `kcv` 改从 cookie 覆盖; strE appInfo.version 随
|
||
api_params 自动对齐。
|
||
- 新增 **styleTemplate 金丝雀探针**(`/rest/e/load/styleTemplate`,
|
||
2026-07 抓包实证 result=1): 同传输/sig3/xfalcon 管线但无鉴权
|
||
token、无加密体, 真机形态连 __NStokensig 都不带(已按抓包实现)。
|
||
广告步骤先跑探针 —— 探针过而 ad fetch 败 => 投放层拒绝
|
||
(api_st/strE/任务绑定); 探针也败 => 传输/签名层。
|
||
- fetch_ad 的 JSONL notes 现记录 strE 明文/scene/businessId/
|
||
neoParamsLen, 下次失败可直接检查加密体内容。
|
||
|
||
## 2026-08-27 - 6001 结案: 根因=旧 api_st; gzip 解压为最后一坑
|
||
|
||
- 用户用 `tools/sms_login_cli.py` 重新登录获得新鲜 api_st/h5_st/设备
|
||
(did=ANDROID_63fdacb5388e2572 + 在线注册 egid)并更新 .env 后:
|
||
- styleTemplate 探针 HTTP 200 + 12.7KB 模板 —— **实为成功**,此前
|
||
`result=None` 是 curl_cffi(okhttp 指纹)手动 `Accept-Encoding: gzip`
|
||
时 libcurl 不自动解压导致 `json()` 失败的解析 bug。
|
||
- 修复: `_request` 按 `\x1f\x8b` 魔数兜底 `gzip.decompress`
|
||
(requests 自动解压不受影响)。
|
||
- **广告全链路打通**: fetch result=1(16KB gzip 素材, 19.1s)→
|
||
按素材时长等待 → report result=1 `neoAmount:497金币` 实际到账。
|
||
- 6001 根因链(多因叠加, 逐轮排除): 旧 cookie 的 api_st 过期(H5 用
|
||
h5_st 所以全通, API 全挂)+ 传输指纹 + 版本号滞后 + uQaTag 设备
|
||
错配 + 参数集多余键。新会话 + okhttp 指纹 + 版本对齐后消除。
|
||
- 端到端验证后 19+291 测试回归无新增失败。诊断体系(JSONL 探针/
|
||
strE notes)保留, 供后续问题定位。
|
||
|
||
---
|
||
*每执行2次查看/浏览器/搜索操作后更新此文件*
|
||
*防止视觉信息丢失*
|