本文共 694 字，大约阅读时间需要 2 分钟。

一凡的午后，我悠哉地敲着代码喝着茶，突然服务端同事告诉我，发现接口正在被机械式地调用，怀疑有人在用脚本刷接口，这可能是为了从平台导流。我心里有点怀疑，因为接口请求好像都做了加密处理，除非知道加密的密钥和加密方式，否则不可能成功调用。

不过，当我看到接口日志的时候，彻底否定了我的疑虑。日志显示接口调用频率固定为每1秒一次，被关注者的用户id每次调用依次递增，目前业务上的用户id是按照注册时间依次生成的。而且密钥好像一直用一个固定密钥，这明显有刷接口的嫌疑。

经过分析，原因可能是内部人员泄露了密钥和加密算法，或者对方破解了APK。虽然基本排除了内部泄露的可能，但问题依然存在。于是，我想反编译最近版本的APK，结果在反编译某个较早的版本时，发现加密工具类的源码居然完全暴露了。这说明对方可能脱壳了。

于是，我决定用NDK来处理，尽量将敏感数据和加密方式放在C++代码中，因为C++代码编译后生成的SO库相对难以反编译。我创建了一个加密工具类，整合了生成密钥和加密方法的功能，并添加了身份校验机制，只有校验通过的应用才能获取到密钥和执行加密操作。

后来，我发现直接将敏感数据和加密方法放在C++代码中虽然安全，但当破解者反编译SO库并调用相应的方法时，仍然可能获取到密钥和加密方法，所以进一步我增添了身份校验机制，确保只有经过身份验证的应用才能获取到密钥和执行加密操作。

最终的问题修复了，但这次事件让我深刻认识到安全无小事，也锤炼了我对安全防护的认识：加固流程至关重要，必须使用自动化脚本来防止人工错误，不能允许人工打包加固。此外，服务端也需要增加风险报警机制，及时发现异常和攻击行为。