港台服的《新楓之谷》出来这么多年，账号登录方式其实一直没怎么大改，账号密码这一套传统登录到现在依然是很多老玩家的主力入口。问题就出在这儿：时间一长，注册过的账号多、密码又改过几轮，很多人手里只剩下一个客户端里"记住密码"打上的小勾，或者某个管理工具里存着的一串密文，真要填的时候压根想不起来原文。我这次动手的起因也很简单，帮朋友整理几台旧电脑，翻出来一堆登录凭据，全是加密字符串，明文一个都看不到。于是就有了这个项目：把传统登录方式里涉及到的密码解密流程摸清楚，再顺手把自动登录方式做出来，省得每次开游戏都要手动敲一遍。这篇就把我踩过的坑、验证过的步骤、以及背后为什么这么设计，完整讲一遍，适合手里有自己账号、想搞清楚本地凭据是怎么回事、又想搞自动化登录的朋友参考。
1. 标题背后的真实需求拆解
1.1 传统登录这条链路到底卡在哪
先把这个项目的边界划清楚。我们讨论的是"传统登录方式"，也就是账号加密码直接提交的那种入口，不是手机验证码、不是第三方平台授权跳转。这类入口的痛点在日常使用里其实很集中：第一，密码是加密后存在本地的，你看到的是一个哈希或者密文串，看不到原文；第二，每次启动客户端都要重新走一遍输入流程，账号还好说，密码输起来麻烦，尤其是带特殊符号的；第三，多个账号切换的时候，纯手工操作效率极低。这三点就是项目要解决的核心。
我把它们归成两个方向：一个是"读"——把本地已经保存的密文还原成明文，方便确认和整理；另一个是"写"——把还原出来的凭据重新喂回去，做成自动填表并提交的流程。前者对应关键词里的"密码解密"，后者对应"自动登录方式"。两个方向技术上其实是一体的，你能解密就说明你理解了加密规则，理解了加密规则就能反过来构造合法的登录数据包，自动登录也就水到渠成。所以这个项目我建议按"先解后登"的顺序来做，别一上来就想着跳过解密直接模拟提交，那样你连字段是怎么拼的都搞不明白。
注意：这里所有操作的前提都是"你自己的账号、你自己设备上保存的凭据"。任何涉及他人账号、来源不明的数据的行为都应当被排除，本文只讨论属于本人所有数据的技术处理方式。
1.2 "密码解密"在这类项目里指什么
很多人一听"密码解密"第一反应是破解别人的密码，这个理解方向就跑偏了。在本地凭据这个语境里，所谓解密，指的是把某个软件出于"方便你下次自动填充"这个目的，加密存在本机文件或配置里的字符串，用同样的算法和密钥反向还原回明文。它的本质是"数据恢复"，不是"入侵"。你想想，如果加密方案做得足够好、密钥根本不落盘，那谁也还原不了，软件自己也没办法自动填充，因为它同样需要拿到明文才能填进去。所以只要一个软件支持"记住密码自动填充"，它必然在本地某处存了一份可以用程序还原的凭据。
这正是我们做这件事的技术前提。数据库管理工具 Navicat 就是最典型的例子，它把连接密码加密存在注册表或者配置文件里，用的一直是同一套固定密钥的对称加密，所以社区里"Navicat 密码解密"才会成为一个经久不衰的话题，最近又被热搜带了一波，很多人搜"navicat 密码解密在线"其实是想找回自己以前配好的连接密码。游戏客户端也是同一个逻辑，只是加密方案各家自研、强度不一，有的甚至是明文异或一下，有的则是正经的 AES。理解了这个本质，你就不会觉得这件事有什么玄乎的，它就是一个标准的"已知算法还原已知密文"的工程问题。
1.3 适合谁来参考这篇内容
这篇不是给完全零基础的朋友写的启蒙文，虽然我会尽量把原理讲白，但你需要至少具备这些基础会更顺：会用一款抓包或者调试工具看请求、能读懂一段几十行的脚本、知道对称加密和哈希的区别。如果你手上正好有自己的老账号、又懒得每次手输密码，那这篇的实操部分你可以直接照搬。
反过来说，如果你只是想搞清楚"为什么这些工具能存密码""自动登录到底怎么实现的"，那前面几章的原理解析对你来说就是最有价值的部分，实操可以选做。我个人的习惯是把原理和实操分成两层来看，原理理解到位了，哪怕换个游戏、换个工具，你也能自己迁移过去，不用每次都重新找教程。
2. 登录链路拆解与客户端本地存储机制
2.1 一次完整登录请求包含哪些字段
要把自动登录做出来，第一件事不是写代码，是把一次正常登录的请求完整地"看"一遍。我用的方式是开着抓包工具，从输入账号密码到点登录按钮，把整个过程录下来，重点看提交出去的数据里到底有哪些字段。通常来说，传统登录的请求体逃不出这几个组成部分：账号标识、密码相关的密文或哈希、客户端生成的随机串或者时间戳、可能还有验证码字段和设备指纹字段。港台服这类老牌游戏客户端在字段命名上往往保留着早年架构的痕迹，字段名可能拼写都不太规范，别指望它给你一个漂亮的 JSON。
这里有个关键判断点：密码字段提交上去的到底是明文、是哈希、还是加密串。判断方法很简单，同一组密码登录两次，看这个字段值变不变。如果每次都一样，那多半是哈希或者固定加密；如果每次都不同，那说明里面掺了随机数或者时间戳，属于每次都要重新计算的动态密文。这个结论直接决定了后面自动登录的构造方式，动态密文你就必须复刻它的随机化逻辑，否则重放会失败。我第一次做的时候没注意这点，傻乎乎地把抓到的密文写死，结果第二次登录直接报错，排查了大半天才发现是动态的。
2.2 凭据在本机的几种落地形态
客户端"记住密码"之后，凭据不一定存在一个地方。我把常见的位置和形态整理了一下，你自己对照排查会发现基本就在这几类里：
| 存储位置 | 常见形态 | 还原难度 | 说明 |
|---|---|---|---|
| 客户端配置文件 | 加密字符串 / Base64 | 中 | 随客户端安装目录走，换电脑会丢 |
| 系统注册表 | 加密二进制 / 十六进制串 | 中高 | 需要先定位键值再判断算法 |
| 独立管理工具配置 | 专用加密格式 | 视方案而定 | Navicat 这类工具的典型做法 |
| 浏览器本地存储 | Cookie / localStorage | 低到中 | 网页版登录常见 |
理解这张表的意义在于：你要先确定自己手里的密文是"哪一类"，再决定用什么还原策略。同样是密文，配置文件和注册表里的东西处理方式完全不一样。我的建议是先用文件搜索工具按时间排序，找出客户端最近写入的文件，再一个个打开看有没有可疑的长字符串。经验上，凡是长度固定、字符集是十六进制或者 Base64 的字段，都值得重点怀疑。拿到候选密文之后别急着套算法，先把它的长度、字符集、是否含固定前缀这些特征记下来，这些信息会大幅缩小你的算法范围。
2.3 定位到密文之后的判断逻辑
假设你已经在一个配置文件里找到了一串可疑字符串，接下来怎么判断它用了什么加密？我的判断顺序是这样的：先看长度，十六进制长度能反推原始字节数，比如 32 个十六进制字符是 16 字节，很可能是一个 MD5 或者 AES 分组；再看有没有明显特征，比如 Base64 的结尾习惯、固定前缀常量；最后就是动手试。试的时候优先试最弱的方案——异或、Base64 直接解、固定密钥 AES，因为自研客户端为了省事经常用这三板斧。
这一步其实是最考验耐心的，因为不同版本的客户端可能中途换过加密方案。遇到这种情况，我的做法是找到客户端里负责加解密的那个模块，反编译出来看它的常量。绝大多数弱加密的密钥、初始向量都是硬编码在里面的，一旦你拿到这个常量，剩下的就是套标准库。这里我要提醒一句，反编译和分析仅供个人学习和数据恢复，别把它用在别人的软件服务上，也别传播逆向出来的私有算法细节。
3. 密码解密的核心思路与常见算法还原
3.1 数据库工具类凭据：Navicat 的 Blowfish 方案
既然热搜里带"navicat 密码解密在线"，我就拿它当典型讲透。Navicat 保存连接密码用的是对称加密，核心是 Blowfish 算法，配合一个固定的密钥。老版本和新版本在密钥派生和分组模式上有差异，早期方案用的密钥比较直接，后面版本改成对固定字符串做哈希再取头部若干字节作为密钥，并且以 ECB 模式逐块加解密。它的加解密对称性很强，你只要能复现出密钥，正反两个方向都能算。
理解这套方案的价值不在于 Navicat 本身，而在于它揭示了"工具类凭据"的通用套路：固定密钥加对称加密。为什么这么设计？因为工具要能自动帮你填密码，就必须让程序自己也能解密，所以密钥只能硬编码或者从固定字符串派生，没法真正做到"只有用户知道"。这就是它的安全性天花板的来源。我把这类方案的特征总结成一句话——凡是能自动填充的本地凭据，密钥一定在本地可复现。你记住这句话，遇到没见过的工具也能顺着找。
具体还原流程是这样的：先定位连接配置存储的位置，导出密文；再确定你用的工具版本，选择对应的密钥派生方式；然后调用标准库里的对称加密实现反向解出明文。整个过程不需要你自己实现加密算法，现成的密码学库都能做，关键是把密钥和分组模式对上。我实测下来，版本对错是最大的坑，用错版本的密钥解出来就是一堆乱码，这时候别怀疑密文损坏，先换密钥版本再试。
3.2 游戏客户端的自研弱加密（异或与固定密钥）
游戏客户端这边情况就杂了。港台服这类运营多年的游戏，客户端经过多次改版，登录相关的加密方案也可能迭代过。我遇到过的几类，按强度从低到高排：第一类是最粗暴的单字节异或，整串凭据用一个固定字节去 XOR，这种甚至连密钥都算不上，反推极其容易；第二类是"异或加轮转"的组合，每个字节用一个循环的下标做异或，稍复杂一点但规律性强；第三类是固定密钥的 AES 或者自定义的分组加密，这一类就需要你拿到密钥常量。
判断自己遇到的是哪一类，有个很实用的小技巧：拿一个你自己知道明文的密码去做对照实验。比如你想验证是不是单字节异或，就构造一个已知明文的密文，看两个密文异或的结果和两个明文异或的结果是否一致。如果一致，那算法就是可逆的线性变换，规律立刻就能扒出来。这个方法我第一次用的时候惊了一下，原来这么容易就能判断。当然，前提依然是你处理的是自己的数据，构造对照实验用的也是你自己的账号。
对于固定密钥的 AES，处理方式和 Navicat 那套就归一了，重点还是找密钥常量。游戏客户端的密钥往往藏在登录模块附近，字符串常量表里搜一搜经常能搜到可疑的短字符串，十六进制长度 16 或 32 的都值得试。这里要强调，找到密钥之后，正解密和逆加密都要验证一遍——先把密文解成明文，再把明文加回去看能不能得到原密文，两边都对上才算真正吃透了这套算法。
3.3 从密文到明文的通用还原流程
不管面对的是工具类凭据还是游戏客户端，我总结出一套通用的还原流程，按这个顺序走基本不会绕远路：
- 定位密文来源，确认它属于哪一类存储位置，导出原始字符串。
- 记录密文特征：长度、字符集、前缀常量、是否随登录变化。
- 从最弱方案开始试：明文直接解、Base64、单字节异或、循环异或。
- 弱方案不通，升级到对称加密：先找密钥常量，再确定分组模式和填充方式。
- 双向验证：解密后再加密，比对是否还原成原密文。
- 如果算法随版本变化，以当前实际运行的客户端版本为准，别照搬旧版教程。
这个流程里，第三步和第四步是关键分水岭。很多人卡住是因为一上来就往 AES 上想，其实大量自研客户端用的就是最简单那套。反过来，也有人以为随便异或一下就行，结果碰上了正经加密，白折腾。我的经验是：先花十分钟做快速筛查，把弱方案一次性全试一遍，不通再系统性地找密钥，这样时间利用率最高。
注意：双向验证这一步不能省。只做单向解密，你无法区分"解对了"和"解出来碰巧是一串看起来像明文的东西"，只有能原路加回去，才能确认算法、密钥、模式全部匹配。
4. 自动登录方案设计与落地
4.1 方案选型：UI 自动化还是协议模拟
密码解密做完，自动登录就有两条路可走。第一条是 UI 自动化，也就是模拟人的操作，找到账号框和密码框，填入内容，点击登录按钮。第二条是协议模拟，跳过界面，直接构造并发送登录请求。这两条路各有取舍，我实际都试过，下面把结论摆出来。
UI 自动化的优点是实现简单、对加密细节依赖低，因为填进去的是明文，让客户端自己去加密提交；缺点是慢、容易被界面改版搞崩、对验证码和防自动化检测比较敏感。协议模拟的优点是快、稳定、可以脱离客户端跑；缺点是你必须完整复刻客户端的加密和签名逻辑，前面的解密功夫一点都省不了，而且一旦客户端更新了协议，你就得跟着改。所以选型的关键在于你的目标：只是想省掉手输密码这一步，选 UI 自动化；想要批量、无人值守、脱离客户端，那只能上协议模拟。
我个人的建议是先用 UI 自动化把流程跑通，验证你对登录链路的理解是对的，再考虑要不要升级到协议模拟。因为 UI 自动化跑通的过程本身就是在帮你验证"账号密码是怎么被提交的"，这个验证结果是协议模拟的基础。跳过这一步直接写协议，很容易在字段和顺序上出错，排查起来特别痛苦。
4.2 UI 自动化路线的实现细节
UI 自动化落地的时候，有几个细节决定成败，我逐个说。第一是窗口定位，游戏客户端和普通窗口不太一样，有些是 DirectX 渲染的，普通的控件查找方法可能拿不到账号框句柄，这时候要么用图像识别找输入框位置，要么用底层输入模拟直接往窗口发按键消息。第二是输入方式，别用剪贴板粘贴，很多客户端对粘贴有拦截或者会触发校验，老老实实用模拟键盘输入更稳。第三是提交后的状态判断，登录成功和失败在界面上表现不一样，你得有个可靠的判断依据，比如检测特定窗口标题或者画面特征。
我踩过最深的坑是输入节奏。一开始我用脚本瞬间把账号密码敲完然后立刻回车，结果十次里能失败七八次，后来发现是客户端在输入框上有事件监听，输入太快会漏事件，导致密码只进了一半。解决办法就是在每个字符之间加一个很短的随机延迟，并且在点登录之前额外停顿一下。这种细节任何文档都不会写，纯粹是实测出来的。
还有一点，自动登录脚本最好做成"可配置"的，账号、密码来源、要不要记日志都抽出来，别硬编码在脚本里。一来方便切换账号，二来万一脚本要给别人用（比如同一台电脑上的家人账号），改配置就行，不用动代码。这是我做了几版之后才意识到的工程习惯问题。
4.3 协议模拟路线的参数计算与节奏控制
如果你决定走协议模拟，每次登录前需要准备的参数大致有这么几样，我列出来并解释为什么：
- 账号标识：通常直接就是账号，个别情况会做一次哈希。
- 密码密文：这里是重点，如果你已经还原出加密算法，就可以自己用明文算出和客户端一致的密文；如果算法是动态的，还要带上随机数和时间戳一起算。
- 随机串或时间戳：用来防重放，值必须实时生成，且和服务端允许的时间窗口对得上，别用太旧的时间。
- 设备或版本标识：客户端版本号这类字段经常参与校验，版本对不上会被服务端拒绝。
计算顺序很重要：先拿随机串和时间戳，再用它们参与密码加密，最后把整套字段按客户端原本的顺序拼装。顺序错了或者少一个字段，服务端返回的错误往往含糊其辞，让你根本猜不到问题在哪。我调试的时候习惯先把每个字段单独打印出来和抓包结果逐字段比对，全部一致了再发请求，这样一旦失败就能迅速定位到是哪个环节出的问题。
节奏控制方面，别把请求发得太密。一是容易被服务端判定为异常行为，二是你自己调试时也会被日志淹没。我的做法是每次登录之间留一个合理的间隔，失败重试也带上退避，不要无脑循环。另外，建议在协议模拟里加一个"干跑模式"，只计算和打印参数、不真正发包，这样可以先离线验证参数构造是否正确，避免频繁触发服务端的风控。这个模式在开发阶段帮我省了大量时间。
5. 常见问题排查表与避坑经验
5.1 登录失败、解密乱码的典型原因
做这类项目，出问题是常态。我把遇到过的典型故障和排查方向整理成表，方便你对照：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 解密出来是乱码 | 密钥版本不对 / 分组模式不匹配 | 换密钥版本，确认 ECB 还是 CBC |
| 密码框只填进去一半 | 输入节奏太快丢了事件 | 字符间加随机延迟 |
| 协议模拟报参数错误 | 字段缺失或顺序不对 | 逐字段与抓包结果比对 |
| 重放请求失败 | 密文是动态的，带了随机数 | 实时生成随机串再加密 |
| 登录偶尔成功偶尔失败 | 状态判断不可靠 / 风控触发 | 增加稳定判断依据，放慢请求 |
| 换电脑后密文解不出 | 密钥与设备绑定 | 确认密钥是否含机器指纹 |
这张表里，我认为最容易让人走弯路的是第一行和第四行。乱码问题十有八九是版本或者模式错了，别往密文损坏上想；重放失败则几乎一定是你忽略了动态字段。把这两条记住，能帮你省下大把排查时间。
还有一类问题不在这张表里，就是"算法对但解出来差一点"，比如明文末尾多了几个乱码字节。这通常是填充处理的问题，对称加密一般会做 PKCS 系列的填充，解密后要把填充字节去掉。我一开始没做去填充，结果每次明文后面都跟着一串怪字符，还以为算法错了。
5.2 账号安全与合规的红线
技术之外，这块必须单独拎出来讲。第一，所有操作只针对你自己拥有的账号和你在自己设备上保存的凭据，别人的数据、来源不明的密文，一概不碰。第二，还原出来的明文密码属于敏感信息，别明文存盘、别到处粘贴、别截图发群里，临时用完就清掉。第三，自动登录脚本里如果硬编码了密码，那个脚本文件本身就是个风险点，尽量从加密的配置或者运行时输入里取。
第四，从规则层面说，自动化操作有时会触及游戏或者服务的用户协议，这一点你要自己判断清楚。我的态度是：把自动化当成个人效率工具来用，控制在自己的账号范围内、控制频率、不做任何影响服务稳定或他人体验的事。第五，别去研究或者传播任何绕过正规验证机制的思路，那已经超出"数据恢复"的范畴了。守住这几条线，这个项目就始终是个技术学习加上效率优化的正经事，不会跑偏。
我见过有人把好好的技术研究做成了灰色操作，最后账号和名声双双受损，非常不值。技术本身没有对错，用在什么地方、对谁用，才是关键。
6. 实测下来的几点体会
做完这一轮，我最想说的一点是：永远先理解，再动手。我一开始也是急着找现成脚本，结果因为不清楚自己客户端的加密方案，抄来的代码一个都跑不通。后来老老实实从抓包、定位密文、判断算法一步步来，反而进展很快。这个顺序换到任何本地凭据相关的项目上都成立。
第二点体会是关于工具的选择。密码学相关的计算别自己造轮子，标准库里的实现又稳又全，你只需要把密钥、模式、填充这三样配置对。我早期自己手写了一遍对称加密的实现，bug 一堆，后来换成标准库，几分钟就通了。省下来的时间拿去研究业务逻辑更有价值。
第三点，多留日志。每次解密、每次构造参数、每次发包，都把中间结果记下来。排查问题的时候，一份详细的日志抵得上你反复抓包好几次。我现在做这类事情，第一件事就是搭好日志框架，后面所有调试都靠它。
最后分享一个我觉得挺有用的小技巧：把整个流程拆成"解密"和"登录"两个独立的小工具，中间用一份中间格式的数据（比如加密后的临时凭据文件）衔接。这样做的好处是两段可以单独测试、单独更新，哪天客户端的加密方案变了，你只改解密那一半，自动登录那半不受影响。这个解耦的思路，是我从其他工程里迁移过来的习惯，实测在这类项目上同样管用。
