Game Offliner Skill

让已关服、服务不可达的网游客户端重新跑起来的通用方法论，以 Agent Skill 形式提供给 AI 使用。

本仓库只收录与「网游离线化方法论」直接相关的 Skill。它把"复活一款关服网游"从零散的逆向技巧沉淀成一套可复用流程：换一个游戏、换一个引擎，仍能按同一套步骤推进，减少反复试错与 Token 消耗。

---

目录

• 核心思想
• 三条总体思路
• 方法论主线
• 五条铁律
• 拦截层决策矩阵
• 仓库结构
• 快速开始
• 在另一个项目中使用
• 适用与边界
• 贡献
• License

---

核心思想

客户端本身不包含游戏运行所需的全部逻辑——缺失的那部分在服务端。所谓"复活"，就是依据客户端留下的线索，把这部分服务端逻辑补回来。

先跑通登录。 登录跑通即意味着客户端已成功连上自制服务端，项目就成功了一半。

记忆口诀：先用探针把登录状态机跑明白，再用最低层的重定向把流量骗到本地，最后按依赖顺序把协议补全。

三条总体思路

方案	思路	优点	缺点 / 适合场景
复原服务端（默认通用解）	重写能配套运行的服务端，让客户端"以为"仍在官方服务器上	通用性最强；可保留多人功能；对客户端改动最少	启动链复杂、需逐步补协议；适合大多数场景
改造客户端	注入代码，把原发给服务端的请求在客户端内部处理，单机化	无需服务端；有机会做成点开即玩的单机版	需深入改已编译代码，受引擎/混淆影响大；适合代码较易读易改的客户端
重做客户端	只提取资源（模型 / 动画 / 场景）重做展示工具	难度最低；不依赖原协议	无法保留完整玩法；适合只想还原角色 / 剧情 / 场景

方法论主线（八阶段）

1. 战略选型 — 复原服务端 / 改造客户端 / 重做客户端。
2. 静态侦察 — 文件完整性与热更；三类线索：配置表、数据包协议、代码与热更模块；登录架构（直连 vs 中台 / SDK）。
3. 观测工具 — 注入框架 + 引擎与热更 VM 日志统一落文件 + 错误探针 + 崩溃兜底。
4. 状态机建模 — 把登录全链路每一跳建模为 触发 → C2S → S2C → 下一步。
5. 分层拦截 — DNS / 寻址 → 传输 / TLS → SDK / 中台 → 业务协议，自底向上，改动面最小化。
6. 逐层补回包 — 从登录链最上游往下逐跳应答，一次只补一个，两侧日志比对。
7. 时序与推送 — 依赖某次初始化的数据，必须在触发它的请求应答之前推送。
8. 持续优化 — 错误驱动、功能生效验证、一键闭环、版本适配器与门控。

五条铁律

1. 先静态再动态、先观测后改动 — 没有日志 / 探针前动手 = 盲修。
2. 分层拦截，自底向上 — 能改寻址就不碰业务，能伪造协议就不改客户端。
3. 一次只补一个 — 让每次改动与日志一一对应，出错时对照客户端与服务端两侧日志。
4. 时序即接口 — 推送顺序必须匹配客户端初始化顺序。
5. 版本门控 + 证据分级 — 每个 hook / patch 三重校验（模块名 + SHA-256 + 字节签名）；结论标注证据级别。

拦截层决策矩阵

按"改动面最小 / 通用性最高"排序，逐层尝试：

层	手段	何时用	代价
DNS / 寻址	注入取地址函数，域名 → 127.0.0.1	地址来自域名、端口可覆盖	最低
传输 / TLS	HTTPS 降级、阻断证书校验、本地 CA、TLS 代理	原协议是 TLS 且无本地证书	中
SDK / 中台	inline hook 登录函数，伪造成功回调	平台登录无法离线	中高
业务协议	服务端按真实 wire format 应答	始终需要	高（但必须）

仓库结构

.
├── README.md                     # 方法论总览（本文件）
├── USAGE.md                       # 详细用法：接入方式、各阶段指令与说明
├── LICENSE                        # MIT
└── offline-login-revival/         # 核心 Skill
    ├── SKILL.md                   # 入口：战略选型、前提与线索、铁律、八阶段、决策矩阵、坑、DoD
    ├── README.md                  # 技能简介
    └── reference/
        ├── playbook.md            # P0–P7 每阶段：目标 / 动作 / 验收 / 检查清单
        └── templates.md           # 注入器、hook 门控、配置、伪造响应、协议表、时序契约、一键脚本、版本适配器

后续新增 Skill 也必须是本方法论在某类引擎 / 传输 / 平台上的具体化。

快速开始

在本机全局配置 ~/.config/opencode/opencode.json 中注册本目录：

{ "$schema": "https://opencode.ai/config.json", "skills": { "paths": ["E:/AI/Skills"] } }

保存后退出并重启 opencode 生效。Agent 会在遇到相关任务时按 SKILL.md 的 description 自动触发匹配。

在另一个项目中使用

三种接入方式：

方式	做法	适用
项目级注册（推荐）	在目标项目 .opencode/opencode.json 的 skills.paths 里加本仓库路径	不复制文件，随仓库更新
复制进项目	把 offline-login-revival/ 放进 <项目>/.opencode/skills/	需要锁定某个版本随项目走
全局注册	写入 ~/.config/opencode/opencode.json	本机所有项目可用

接入后有两种触发方式：

• 自动：任务命中 description 的关键词（关服复现、离线登录、自制服务端、客户端重定向等）时自动加载；
• 显式：在指令里点名，例如「使用 offline-login-revival 技能，对 D:\Games\XXX 执行 P0 静态侦察」。

每个阶段可直接复制的指令、作用与期望产出，见 USAGE.md。 简版：

阶段	指令要点
P0 静态侦察	「分析 <客户端目录>，回答 5 个关键问题，产出登录架构图与三类线索清单，不要改文件」
P1 观测工具	「搭建注入框架 + 统一日志 + 错误探针 + 崩溃兜底，先只观测」
P2 状态机建模	「把登录全链路建模为 触发 → C2S → S2C → 下一步，标出未知项」
P3 拦截选型	「按决策矩阵列出最小改动拦截点，搭一个能监听、能记日志的基础服务端」
P4 重定向与绕过	「寻址→本地，按需处理 TLS 与 SDK/中台，把所有出网流量落到本地」
P5 逐层补回包	「从最上游往下一次只补一个响应，以客户端走到下一步为通过标准」
P6 时序与推送	「找出应答回调里做初始化的位置，把依赖数据提前到应答之前推送」
P7 持续优化	「错误驱动清零，做功能生效验证，补一键脚本、适配器与回归测试」

适用与边界

	说明
适用	客户端能启动但卡在登录；服务已下线但有可运行客户端；私服、离线复原、协议研究
不适用	客户端被完全加密且无任何可观测点；目标是绕过合法授权 / 付费墙
需具体分析	加密加壳、特殊架构等场景不在方法论覆盖范围内

免责声明：本项目仅供游戏开发的学习与研究。请勿用于仍在运营中的游戏。

贡献

欢迎补充新的 Skill 或修正方法论。每个 Skill 为一个目录：

<skill-name>/
├── SKILL.md        # 必需，YAML frontmatter（name + description）+ 正文
├── README.md       # 可选，面向人的介绍
└── reference/       # 可选，按需加载的参考文档

SKILL.md frontmatter 的 name 必须与目录名一致（小写连字符）；description 需同时说明"做什么"和"何时触发"，并前置触发关键词。提交 PR 前请确保内容仍属于「网游离线化」范畴。

License

本项目基于 MIT License 开源。