破解脚本卡密教程

去年冬天，破解一个做独立游戏的脚本教程朋友给我发来一张截图。他的卡密游戏上线三天，后台显示激活量两千，破解但实际付费用户只有四十几个。脚本教程剩下那些，卡密全是破解用破解脚本刷出来的假卡密。他问我能不能看看脚本怎么跑的脚本教程，我花了两个晚上拆了一个流传较广的卡密样本，过程比想象中简单，破解也比想象中无聊。脚本教程

先说清楚一件事：我写这个不是卡密教人去破解别人的东西。恰恰相反，破解你得先知道漏洞在哪，脚本教程才能把门堵上。卡密那个脚本的核心逻辑就一句话——它根本没去碰服务器，而是在本地伪造了一个验证通过的返回值。

脚本到底在干什么

大部分卡密验证走的是这么个流程：客户端把卡密发给服务器，服务器查数据库，返回“有效”或“无效”。脚本作者发现，很多小团队为了省服务器成本，把验证逻辑写在了客户端里。也就是说，你的电脑自己就能判断卡密对不对。那还等什么？直接把判断结果改成“对”就行了。

我拆的那个样本是个Python打包的exe，用pyinstxtractor解包之后，在verify.pyc里找到了关键函数。它长这样：

def check_card(card): if card in valid_cards: return True return False 

就这么直白。脚本作者甚至懒得混淆，变量名都没改。他只需要把valid_cards这个列表替换成一个永远返回True的对象，或者直接hook掉check_card函数，让它在被调用时无条件返回True。整个过程不到二十行代码。

为什么这种事反复发生

我后来跟那个朋友聊，问他为什么把验证放本地。他说一开始想的是“先跑起来再说”，结果一拖就是半年。这其实是很多独立开发者的真实状态——功能优先，安全靠后。等到发现被刷了，损失已经产生了。

另一个案例更离谱。有个工具类软件用了一个在线验证接口，但接口地址硬编码在客户端里。脚本作者直接改hosts文件，把验证域名指向自己的本地服务器，然后返回一个写死的成功响应。软件照样跑，卡密验证形同虚设。这种攻击甚至不需要逆向，改个文本文件就行。

真正有效的防御手段

把验证逻辑放到服务器端，这是底线。客户端只负责发送卡密和接收结果，不参与任何判断。每次启动都重新验证，不要缓存结果。听起来简单，但很多团队就是不做。

再进一步，给验证请求加上签名和时间戳。服务器收到请求后检查签名是否匹配、时间戳是否在合理范围内。这样即使有人抓包重放，也会因为时间戳过期而失败。我见过一个做得不错的方案：每次验证时客户端生成一个随机数，服务器用这个随机数加上密钥做一次哈希，客户端再验证哈希值。脚本作者想伪造响应，得先拿到密钥，而密钥根本不在客户端里。

还有一点容易被忽略——别在错误信息里泄露太多。有的软件验证失败会返回“卡密不存在”或“卡密已过期”，这等于告诉攻击者哪一步出了问题。统一返回“验证失败”就够了。

说回那个朋友

他后来把验证逻辑全部搬到了服务器，加了请求签名，又用了一个简单的频率限制——同一个IP一分钟内超过五次验证失败就暂时封禁。改完之后重新上线，破解脚本还是能跑，但跑出来的卡密全被服务器拒了。那些刷出来的激活量再也没出现过。

他跟我说，早知道这么简单，当初就该花那两天时间。我说你现在知道了，也不算晚。脚本破解这件事，攻防两端拼的从来不是技术深度，而是谁更愿意多走一步。