港台服的《新楓之谷》出来这么多年账号登录方式其实一直没怎么大改账号密码这一套传统登录到现在依然是很多老玩家的主力入口。问题就出在这儿时间一长注册过的账号多、密码又改过几轮很多人手里只剩下一个客户端里记住密码打上的小勾或者某个管理工具里存着的一串密文真要填的时候压根想不起来原文。我这次动手的起因也很简单帮朋友整理几台旧电脑翻出来一堆登录凭据全是加密字符串明文一个都看不到。于是就有了这个项目把传统登录方式里涉及到的密码解密流程摸清楚再顺手把自动登录方式做出来省得每次开游戏都要手动敲一遍。这篇就把我踩过的坑、验证过的步骤、以及背后为什么这么设计完整讲一遍适合手里有自己账号、想搞清楚本地凭据是怎么回事、又想搞自动化登录的朋友参考。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 一堆后来换成标准库几分钟就通了。省下来的时间拿去研究业务逻辑更有价值。第三点多留日志。每次解密、每次构造参数、每次发包都把中间结果记下来。排查问题的时候一份详细的日志抵得上你反复抓包好几次。我现在做这类事情第一件事就是搭好日志框架后面所有调试都靠它。最后分享一个我觉得挺有用的小技巧把整个流程拆成解密和登录两个独立的小工具中间用一份中间格式的数据比如加密后的临时凭据文件衔接。这样做的好处是两段可以单独测试、单独更新哪天客户端的加密方案变了你只改解密那一半自动登录那半不受影响。这个解耦的思路是我从其他工程里迁移过来的习惯实测在这类项目上同样管用。