mcpField
W
web-reverse-algorithm

web-reverse-algorithm

github.com/lwjjikeセキュリティ38054 回インストール14 週間前に更新
リポジトリ

web-reverse-algorithm について

web-reverse-algorithmは、署名、チャレンジ、プロトコルを調べるためのスキルです。最終出力点と中間チェックポイントを軸に調査を整理し、問題の種類に応じた資料とケース用ひな形を備えています。

主な機能

  1. 01アルゴリズムや課題の分類
  2. 02writer、builder、entry、sourceの追跡
  3. 03中間チェックポイントの記録
  4. 04最小限の実行環境構築ガイド
  5. 05標準ケースひな形の作成

活用シーン

  1. 01リクエスト署名やCookieの調査
  2. 02難読化JavaScriptの計算追跡
  3. 03CAPTCHAや検証フローの分析
  4. 04再利用可能なサイト事例の整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lwjjike/xbsreverseskill --skill web-reverse-algorithm

インストール後、Claude Code で/web-reverse-algorithmを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
01-decision-tree.md
02-algorithm-families.md
03-captcha-families.md
04-debug-env-playbook.md
05-training-routes.md
06-engineering-maintenance.md
captcha-patterns.md
debug-env-checkpoints.md
purecalc-patterns.md
route-map.md
scripts/
new_case_scaffold.py

詳細

プロジェクトの README より

Web 逆向纯算

这项技能不是“给一个固定公式”,而是把资料库里的方法层、题型层、训练层、工程化层压成一套总入口。

先把任务压缩成这条闭环,再决定读哪份 references、走哪条路径、写哪种落地代码:

最终请求 / 最终 cookie / 最终 verify / 最终 WS 帧
-> writer
-> builder
-> entry
-> source

核心原则

  1. 先找最终写出点,不先读混淆大文件。
  2. 先存中间值,不先猜算法名。
  3. 先缩小执行范围,再补环境。
  4. 先证明输入输出边界,再决定是否整体迁移。
  5. 先把结果整理成可复用结构,再继续做版本适配。

使用顺序

1. 先判题型

把目标先归到下面之一:

  • 标准签名 / 标准摘要题
  • 混合加密 / 密钥包装题
  • Cookie / Header / 多参数联动题
  • JSVMP / VMP / 强混淆纯算题
  • Wasm / Protobuf / WebSocket / 二进制协议题
  • 验证码 / 风控 / challenge 题

如果还没分清,先读 references/01-decision-tree.md。

2. 再判当前阻塞点

优先判断你卡在下面哪一类:

  • 入口没找对
  • 原始串或原始 payload 没对齐
  • 中间数组 / 中间对象没采到
  • 运行时依赖没补齐
  • 图像线和参数线没拆开
  • 协议边界没证明

遇到这一步拿不准时,优先读 references/04-debug-env-playbook.md。

3. 按题型选路线
标准签名 / 混合加密 / Cookie / Header / 国密

适用信号:

  • 输出长度规整
  • md5/sha1/hmac/aes/rsa/sm3/sm4
  • token&t&appKey&data
  • params + encSecKey
  • document.cookie 或 header 明显可追

优先读取 references/02-algorithm-families.md。

JSVMP / VMP / 小红书 / a_bogus / 多参数复杂纯算

适用信号:

  • 大数组、解释器、for(;;)+switch
  • 位运算密集、状态数组、寄存器式写法
  • window._webmsxyw、__TENCENT_CHAOS_VM、byted_acrawler 一类入口

优先读取 references/02-algorithm-families.md 和 references/04-debug-env-playbook.md。

Wasm / Protobuf / WebSocket / challenge 协议

适用信号:

  • WebAssembly.instantiate
  • application/x-protobuf
  • 二进制响应、导出函数、首包/验证包分段

优先读取 references/02-algorithm-families.md 和 references/03-captcha-families.md。

验证码 / 风控 / challenge / verify

永远先拆 5 条线:

  1. 初始化 / challenge 线
  2. 图像或题面识别线
  3. 参数 builder 线
  4. 环境 / 指纹 / collect 线
  5. 最终 verify 线

优先读取 references/03-captcha-families.md。

统一工作流

1. 锁定最终写出点

优先从这些位置切:

  • fetch
  • XMLHttpRequest.send
  • setRequestHeader
  • document.cookie
  • JSON.stringify
  • verify 提交点
  • WebSocket 首包或验证包发送点
2. 记录 5 层检查点

至少保留:

  1. writer 检查点:最终 URL / header / body / cookie / WS 帧
  2. builder 输入:query、payload、token、challenge、distance、track、browser info
  3. 原始串或原始 payload
  4. 中间数组 / 中间对象 / 编码前字节流
  5. 最终输出
3. 先恢复中间态,再恢复最终编码

这条规则在下面几类题里尤其重要:

  • 小红书 x-s / x-s-common
  • 抖音 a_bogus / X-Bogus
  • 腾讯 collect
  • 网易盾 w
  • 各类 payload -> encode 的 header 家族
4. 只在必要时补环境

优先补到最小可运行边界:

  1. window/self/globalThis/document/navigator/location
  2. cookie/storage/performance/Date/crypto
  3. canvas/webgl/audio/plugins/mimeTypes/RTCPeerConnection

如果目标已经被收缩成纯函数,就不要把任务升级成“大补环境题”。

5. 把结果收敛到工程接口

最终优先沉淀下面这些产物:

  • 最小输入集合
  • 中间检查点集合
  • build_context() / build_payload() / sign() / solve() 这种分层接口
  • 本地样本与浏览器样本对照
  • 失败诊断点

你应该产出的结果

使用这项技能时,优先输出:

  1. 题型判断
  2. writer / builder / entry / source 分层
  3. 当前阻塞点判断
  4. 必要检查点列表
  5. 是否需要 AST、插桩、补环境、图像识别或协议拆包
  6. 推荐的落地结构:函数、solver、SDK、服务
  7. 易错点与版本风险

资源导航

案例脚手架

要在工作区里快速起一套“可复盘、可扩展”的案例骨架,运行:

python "<skill-dir>\\scripts\\new_case_scaffold.py" `
  "case-name" `
  --type captcha `
  --family tencent `
  --tags captcha,collect,pow `
  --sources "https://example-a,https://example-b" `
  --language py `
  --output ".\\research"

脚手架会生成:

  • case-overview.md
  • request-chain.md
  • evidence-log.md
  • checkpoints.json
  • metadata.json
  • solver_stub.js 或 solver_stub.py
  • todo.md

最后约束

始终偏向下面这些做法:

  1. 从真实请求或真实 sink 进入。
  2. 对浏览器值和本地值建立同构检查点。
  3. 先拆算法层、环境层、协议层,再决定怎么迁移。
  4. 同站点多文章时记录“思路差异”,不要只保留一个最终答案。
  5. 每个案例都沉淀输入边界、检查点、代码骨架、易错点,而不是只留最终成品。

コメント