[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-1925":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":15,"stars7d":16,"stars30d":17,"stars90d":14,"forks30d":14,"starsTrendScore":18,"compositeScore":19,"rankGlobal":9,"rankLanguage":9,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":9,"pushedAt":9,"updatedAt":25,"readmeContent":26,"aiSummary":27,"trendingCount":14,"starSnapshotCount":14,"syncStatus":28,"lastSyncTime":29,"discoverSource":30},1925,"spider-king-skill","aoyunyang\u002Fspider-king-skill","aoyunyang","Protocol-first reverse engineering skill for turning hostile web clients into pure-protocol Python collectors.",null,"Python",247,53,145,0,20,38,87,60,5.2,"MIT License",false,"main",true,[],"2026-06-12 02:00:34","# Spider King\n\u003Cimg width=\"591\" height=\"250\" alt=\"image\" src=\"https:\u002F\u002Fgithub.com\u002Fuser-attachments\u002Fassets\u002Fcfbb487e-8def-4a6c-b8da-0d1bd0e83771\" \u002F>\n\n`Spider King` 是一套面向 Web 协议恢复与参数还原场景的逆向工程 Skill。\n\n它的目标不是“把网页点通”，也不是“用浏览器把请求糊过去”，而是把看起来依赖浏览器环境的目标，拆回到可复现、可验证、可长期维护的纯协议采集链路中。\n\n- 先证据，后结论\n- 先协议，后自动化\n- 先还原动态状态，再谈分页、规模化\n- 最终交付必须脱离浏览器运行\n\n## 核心定位\n\n`Spider King` 解决的不是“怎么自动点按钮”，而是下面这类问题：\n\n- 页面代码写的是一个接口，真实网络请求走的是另一个接口\n- 业务层构造了 `sign` \u002F `token`，但真正发包前又被 wrapper 改写\n- 请求能发出去，但响应体仍然要经过解码、解密、字形映射或二进制解析\n- 页面能用，协议重放不稳定，表现为 `403`、`412`、`429`、偶发成功、只第一页成功等\n- 签名、Cookie、挑战脚本、WASM、WebSocket 会话、协议包装、响应侧解码纠缠在一起\n\n一句话概括：\n\n> 它是一套“把 hostile web client 还原成 stable protocol collector”的方法论与执行框架。\n\n## 核心能力\n\n当前版本围绕 `chrome-devtools` 与 `js-reverse` 两套 MCP 工具展开，强调轻量双工具侦察、离线还原、Python 优先交付。\n\n主要能力包括：\n\n- 协议路径恢复：识别假接口、真实接口、包装层、跳转链与兼容页\n- 动态参数定位：区分签名、随机片段、时间戳、旋转 Cookie、包装字段、挑战产物\n- 协议包装还原：处理 GraphQL、WebSocket、protobuf、msgpack、加密信封、请求 wrapper\n- 响应侧恢复：处理解密、压缩、字形映射、分层编码、二进制帧解码\n- 环境差异分析：识别“标准函数被补丁化”“本地输出与页面输出不一致”等问题\n- 挑战与引导链恢复：处理服务器返回 JS、启动引导、Cookie 写入、预热请求\n- 状态流恢复：处理登录、配对、心跳、ack、会话密钥、媒体派生密钥等流式协议\n- Python-first 交付：最终采集器优先使用 Python，只在必要时保留极小 JS \u002F WASM helper\n\n## 这套 Skill 不做什么\n\n为了保证最终交付可靠、可迁移、可维护，`Spider King` 明确不把以下做法视为合格答案：\n\n- Playwright \u002F Selenium \u002F CDP 驱动页面作为最终交付\n- 隐式依赖浏览器 profile、手工登录状态、手工点击流程\n- 用页面内 `fetch` 代替真正的协议恢复\n- 只做一次幸运重放，不验证重复性\n- 把动态 Cookie、一次性 token、挑战结果直接硬编码进最终代码\n\n这不是一个浏览器自动化 Skill。\n\n这也不是一个“只要能跑就行”的抓包脚本模板。\n\n它是一套以“纯协议交付”为终点的逆向工作流。\n\n## 方法论概览\n\n`Spider King` 的最短主线可以概括为五步：\n\n1. 先做 `Startup Gate`\n2. 用 `chrome-devtools` 与 `js-reverse` 做轻量双工具侦察\n3. 找到真实请求与真实动态状态\n4. 在本地离线重建这些动态状态\n5. 交付脱离浏览器运行的 Python 采集器\n\n更细一点的执行逻辑如下：\n\n### 1. Startup Gate\n\n在正式深入分析前，先完成三件事：\n\n- 环境与工具可用性检查\n- 目标家族分流\n- 最终交付意图声明\n\n当前 Skill 将目标优先分成四类：\n\n- `signer-gated`\n- `verifier-gated`\n- `decode-gated`\n- `session-gated`\n\n这一步的意义不是“写模板”，而是尽早判断这到底是哪种仗，避免一上来就钻进大 bundle 或把页面样本弄脏。\n\n### 2. 轻量双工具侦察\n\n每个 fresh target 都要先过一轮轻量 paired pass：\n\n- `chrome-devtools` 负责页面状态、跳转链、首轮网络视图、可见流程\n- `js-reverse` 负责 initiator、源码搜索、wrapper 追踪、首轮 mutation 假设\n\n这里强调的是“轻量”。\n\n也就是说，fresh target 必须双工具起手，但不代表一上来就要做重型 Hook、深度断点或侵入式浏览器操作。\n\n### 3. 识别真实动态状态\n\nSkill 的核心原则之一是：\n\n> 真正变化的东西，不一定叫 `sign`。\n\n真实动态状态可能是：\n\n- 旋转 Cookie\n- 页面专属 header\n- 请求 wrapper 字段\n- 服务器返回的引导 JS\n- 动态字体\n- WASM 导出\n- 响应侧解码链\n- 会话绑定状态\n\n### 4. 离线重建\n\n一旦确认了真实动态状态，交付路径按成本和稳定性排序：\n\n1. 纯 Python\n2. Python + 极小 JS helper\n3. Python + 极小 WASM helper\n4. Python + 本地 bootstrap executor\n\n最终目标始终不变：\n\n- 不依赖浏览器\n- 不依赖手工动作\n- 不依赖隐藏页面上下文\n\n### 5. 重复性验证\n\n`Spider King` 不接受“这次跑通了”作为完成条件。\n\n至少要验证：\n\n- 同样逻辑能稳定成功 2 到 3 次\n- 分页 \u002F cursor 能前进\n- 关键动态状态能正确再生\n- 页面特例、账号边界、列表\u002F详情权限边界被明确记录\n\n## 为什么这套 Skill 更适合复杂目标\n\n`Spider King` 的优势不在“工具多”，而在“把复杂目标拆成稳定问题”。\n\n它特别适合处理这些复杂症状：\n\n- 页面显示的接口和网络层真实接口不一致\n- 签名函数名称看着标准，但输出和标准实现不一致\n- 只有最后一页失败，或者某一页需要特殊头\n- 页面公开可见，但真实业务请求仍依赖引导配置、Cookie 或包装层\n- 响应不是直接数据，而是加密字段、乱码、字体字形、二进制帧\n- WebSocket 建立后要经历 auth \u002F subscribe \u002F heartbeat \u002F ack 才能拿到数据\n- 挂 Hook 以后反而更容易失败，出现明显 observer effect\n\n## 目录结构\n\n当前仓库结构如下：\n\n```text\nspider-king\u002F\n├── README.md\n├── SKILL.md\n├── agents\u002F\n│   └── openai.yaml\n├── scripts\u002F\n│   ├── check_reverse_env.py\n│   ├── crypto_fingerprint.py\n│   ├── protocol_diff.py\n│   └── scaffold_reverse_project.py\n└── references\u002F\n    ├── workflow-overview.md\n    ├── startup-triage-playbook.md\n    ├── tool-playbook.md\n    ├── official-self-test-task-suite.md\n    ├── crypto-patterns.md\n    ├── obfuscation-guide.md\n    ├── jsvmp-analysis-playbook.md\n    ├── structured-transport-playbook.md\n    ├── response-decode-playbook.md\n    ├── server-js-cookie-bootstrap-playbook.md\n    ├── cookie-provenance-playbook.md\n    ├── stateful-stream-e2ee-playbook.md\n    └── ...\n```\n\n其中：\n\n- `SKILL.md` 是主技能定义文件，也是最高优先级规则入口\n- `references\u002F` 是按症状路由的通用参考手册\n- `scripts\u002F` 是高频辅助脚本，用来缩短重复劳动\n- `agents\u002Fopenai.yaml` 用于技能代理配置\n\n## 关键参考文档\n\n如果你第一次接触这个仓库，建议按下面顺序阅读：\n\n1. `SKILL.md`\n2. `references\u002Fworkflow-overview.md`\n3. `references\u002Fstartup-triage-playbook.md`\n4. `references\u002Ftool-playbook.md`\n5. `references\u002Fofficial-self-test-task-suite.md`\n\n按场景继续深入时，再按症状跳转：\n\n- 参数不一致、wrapper 重写：`transport-wrapper-playbook.md`\n- 标准函数不标准：`patched-helper-playbook.md`\n- 浏览器输出与本地输出不一致：`env-diff-playbook.md`\n- JSVMP \u002F 重混淆：`jsvmp-analysis-playbook.md`\n- 服务器返回 JS 引导 Cookie：`server-js-cookie-bootstrap-playbook.md`\n- 响应需要本地解码：`response-decode-playbook.md`\n- WebSocket \u002F 长连接会话：`stateful-stream-e2ee-playbook.md`\n- 挑战或 verifier：`verifier-replay-playbook.md`\n\n## 辅助脚本说明\n\n仓库中自带 4 个辅助脚本：\n\n### `scripts\u002Fcheck_reverse_env.py`\n\n快速检查本地 reverse 环境是否具备最小运行条件。\n\n适合在 fresh target 开始前先确认：\n\n- Python 是否可用\n- Node \u002F npm \u002F curl \u002F git 是否可用\n\n### `scripts\u002Fcrypto_fingerprint.py`\n\n用于快速判断可疑输出更像哪一类摘要、Base64、字母表变种或自定义编码。\n\n### `scripts\u002Fprotocol_diff.py`\n\n用于对比多组请求 \u002F 响应样本，把真正有意义的差异筛出来。\n\n适合排查：\n\n- 哪个字段才是真正动态字段\n- 某一页为什么失败\n- 某次响应为什么和成功样本不同\n\n### `scripts\u002Fscaffold_reverse_project.py`\n\n用于生成 Python-first 的协议恢复项目骨架。\n\n适合在确认交付形态之后，快速落出一个结构清晰的项目目录，而不是把所有逻辑塞进一个 `main.py`。\n\n## 安装方式\n\n你可以将本仓库放入支持 Skill \u002F Agent 能力的工具目录中，例如：\n\n```bash\ngit clone \u003Cyour-repo-url> ~\u002F.codex\u002Fskills\u002Fspider-king\n```\n\n如果你的工具支持通过 `SKILL.md` 自动加载技能定义，那么只要仓库目录结构保持一致即可。\n\n## 适用场景\n\n建议在以下场景触发 `Spider King`：\n\n- 已拿到目标页面 URL、接口 URL、请求样本、Cookie 样本或 JS 片段\n- 明确需要恢复参数、协议包装、响应解码或状态流\n- 最终目标是可复现、可长期维护的协议采集器\n- 需要将签名 \u002F bootstrap \u002F 解码逻辑落到 Python 或本地 helper 中\n\n## 不适用场景\n\n以下情况不建议使用这套 Skill 作为主路径：\n\n- 需求本质只是标准 UI 自动化\n- 目标本身没有公开协议恢复价值，只是简单页面操作录制\n- 最终交付允许长期依赖浏览器 profile、人工点击、人工登录维持\n- 没有任何合法授权边界，不适合进入实际协议恢复流程\n\n## 交付标准\n\n一个通过 `Spider King` 完成的任务，理想上应包含以下产物：\n\n- 真实接口路径说明\n- 动态状态分类结论\n- 关键固定输入 \u002F 输出验证样本\n- Python 采集器\n- 必要时的极小 JS \u002F WASM helper\n- 原始请求 \u002F 响应样本\n- 风险与不稳定点说明\n\n合格交付至少满足：\n\n- 不依赖浏览器自动化\n- 不依赖手工页面操作\n- 重放逻辑可重复成功\n- 关键动态状态可解释、可验证、可再生\n\n## 自检与防漂移\n\n这个仓库已经开始把“技能回归检查”纳入设计：\n\n- `references\u002Fofficial-self-test-task-suite.md` 用于验证主路线是否仍然 protocol-first\n- `Startup Gate` 用于确保 fresh target 不会一上来就乱冲\n- `tool-playbook.md` 强调只使用当前真实可用的 MCP 能力，不依赖不存在的工具方法\n\n后续如果继续演进这个仓库，推荐始终把这三类内容一起维护：\n\n- 主技能规则\n- 参考手册路由\n- 自测任务与回归标准\n\n## 一句话总结\n\n`Spider King` 不是让浏览器替你干活。\n\n它是让你把浏览器里看起来神秘、脆弱、依赖上下文的行为，拆回成一条可验证、可复现、可长期运行的本地协议链路。\n","Spider King 是一个用于将依赖浏览器环境的复杂Web客户端逆向工程为纯协议Python采集器的工具。其核心功能包括识别真实接口、动态参数定位、协议包装还原以及响应侧恢复等，利用 chrome-devtools 和 js-reverse 两套工具进行轻量级侦察和离线重建。该项目强调在不依赖浏览器运行的前提下，实现稳定且可维护的数据采集流程。特别适用于需要处理签名加密、动态状态管理或响应解码等复杂网络请求场景，如API接口隐藏、数据加密传输及WebSocket会话管理等情况。",2,"2026-06-11 02:46:52","CREATED_QUERY"]