过完一整份清单,我发现他们栽的地方几乎都是一个模式:校验逻辑写了,但写在了能被轻易劫持的地方。签名、完整性、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、领奖和结算都改成服务端为准,再上线暂时没再听说被刷。当然这不代表就安全了,只是成本被抬到暂时不划算而已。安全这事,大概永远是这么个成本账。