聊聊手游上线安全验收里几个容易误判的点

上周帮一个项目做上线前的安全复盘,他们前一款游戏栽过跟头:安全检查全过、清单一片绿,上线没几天破解版就在群里传开了,运营追着问“我们不是都做了吗”。翻完他们的清单我发现,问题不在漏做了什么,而在几个项看着做了、其实没做到位。记一下这次复盘里几个最容易误判的点,给同样在做这块的人参考。

先说我看到的问题

他们的清单没什么可挑的:加固、签名校验、pinning、完整性校验,一项不落,每一项后面都打了勾。但我看了两分钟就觉得不对。这些勾打的是"这件事做没做",不是"做没做到位",而这两件事之间的距离,比大多数人以为的大得多。

举个最直接的:清单上"加固"打了勾,可我问了一句"你验证过加固强度吗",对方愣了一下,说"传上加固平台,平台回了'加固完成'"。这就是典型的把"做了"当成了"到位"。加固是分等级的,静态层做得狠不狠(符号清没清、字符串加没加密、.text 段是不是空壳)和运行时检测全不全,完全是两回事。我把他们那个包拖进 IDA 扫了一眼,符号表清得还行,但有几个 SDK 接口名是明文,逆向的人省不少力气。

逐项过下来,踩的坑其实是同一类

过完一整份清单,我发现他们栽的地方几乎都是一个模式:校验逻辑写了,但写在了能被轻易劫持的地方。

签名、完整性、pinning 这三个,他们全做了,而且逻辑没毛病。问题是全写在 C# 层。这意味着什么?意味着一个 frida-multiple-unpinning 脚本,或者 objection 一句 android sslpinning disable,专挑那几个返回 bool 的校验函数,让它无脑返回 true,你的校验就废了。我当时跟他们说了句话,他们记下来了:攻击的从来不是你的校验逻辑,是那个能被劫持的校验函数。 你算法写得再严谨,最后端一个 bool 回托管层,Hook 的人根本不看你怎么算的。

所以这几项的复盘结论是同一条:能下沉 native 就下沉,签名比对在 C++ 里做完,别把结果端回去。就这一段:

// native 直接调 Android API 取签名,比 C# 通过 AndroidJavaObject 调难 hook 得多
jclass pmClass = env->FindClass("android/content/pm/PackageManager");
jmethodID getPackageInfo = env->GetMethodID(pmClass, "getPackageInfo", ...);
// 取到后在 native 层直接比对,不把 bool 返回给托管层

顺带发现两个他们没做的点。一个是校验只在启动时跑一次,绕过一次就永久通过了,我建议在登录、支付这些节点也随机插;另一个是没做包体大小检测,有种很阴的绕过是往破解包里嵌一份完整正版 APK,启动时 Hook 掉签名获取去读那份正版包,校验就过了,特征就是包体明显偏大,登录时上报一下就能标记出来。

协议这块,他们以为 HTTPS 就够了

复盘到协议层,他们挺自信,说上了 HTTPS 加 pinning。但他们前一款游戏被刷,恰恰就出在这:一个领奖接口三天被重放了一万两千次。

这地方很多人转不过弯:HTTPS 防的是中间人,可玩家自己的客户端就是个合法的 TLS 端点。他在自己机器上把一个成功的领奖请求解出来,原样再发一百遍,HTTPS 一点忙都帮不上,因为在协议眼里这就是合法 client 发的合法请求。所以协议层真正要防的不是"抓包",是"同一个请求被重复用"。让客户端每个请求带上时间戳和一次性 nonce 做签名,服务端三道关:超时间窗口丢、nonce 用 SETNX 查重丢、签名对不上丢。

但我也跟他们说清楚了边界:这套的前提是签名密钥不泄露,可密钥就躺在客户端里,secretKey 下沉 native 也只是拖时间,SO 被逆出来算法密钥就都有了。拖不死的。

复盘到最后,结论落在服务端

绕了一圈,我给他们的核心结论其实就一句:跟奖励沾边的判定,一律以服务端为准。 时间、次数、结算,客户端报什么都别直接信。前面加固也好、校验也好,都是在抬成本、拖时间,真正能兜住的只有服务端这一道。

这里有个我一直在用的、有点反直觉的处理方式,顺手也教给他们了。他们之前查加速器作弊,一直在想办法检测那个 hook,查得很累。我说别检测它,直接把它的收益端掉。为什么反而对?因为加速器放大的本来就是客户端自己数出来的那段时长,只要这段时长到服务端不算数,你放大它就毫无意义。跟 hook 拼检测是场没完的军备竞赛,把收益端掉是一次做对、长期有效。结算离线收益的时候,客户端报的时长只当参考,取它和服务端量到的两者里较小的那个:

long clientClaimed  = req.offlineSeconds;              // 客户端自己数的,可能被放大
long serverMeasured = now - player.lastSeenAtServer;   // 服务端按自己的钟算
long settled = Math.Min(clientClaimed, serverMeasured);// 只认较小的那个
GrantIdleReward(settled);

一点经验

这次复盘我最大的感受是,上线安全清单最没用的地方,就是它只回答"做没做"。一份全绿的清单能让所有人心里踏实,但踏实和安全是两码事。

我现在评每一项防护,养成了只问一句话的习惯:绕过它,对方大概要付多少成本,这个成本够不够压过他破解能拿到的收益。压得过,这项就有用;压不过,勾打得再满也只是自我安慰。客户端跑在玩家手机上、天然不可信,这个前提改不了,所以最后拍板那道判断只能放在他碰不到的服务端。加固、校验、协议这些,本质都是在往上垒成本,不是为了绝对挡死,是让动手的人觉得不划算。

那个项目后来把校验下沉了 native、领奖和结算都改成服务端为准,再上线暂时没再听说被刷。当然这不代表就安全了,只是成本被抬到暂时不划算而已。安全这事,大概永远是这么个成本账。

完整的验收清单和几个 FAQ 我整理在字节暗面主站那版里了,这里只记复盘,不铺开。