App的安全主要包括以下几种:密钥破解导致本地加密数据被盗。通信密钥被破解，导致接

口数据被盗。伪造的接口数据报告。接口的签名被破解，导致接口的重放攻击。所以归根结底

，其实有几种模式:

 

 

 

代码的反编译。逆向破解。中间进攻的人。用户想要的安全性。对于用户来说，他需要的安全

是他的敏感数据不被泄露，不被第三方知晓。所以客户端数据的安全性一般是通过加密来保证

的。但是，由于数据存在于本地，自然需要加密和解密(如果不需要解密，就没必要保留)。因

此，本地必须有加密和解密密钥。为了保证这个密钥的安全性，本地代码需要重新加密，这一

下子好像进入了一个无限循环，成了鸡生蛋，蛋生鸡的问题，这也是为什么说本地没有绝对

安全的原因。

 

 

本地加密。对于本地加密，我们通常从混乱-proguard开始，这是成本最低的最简单的加密，

它可以有效地杀死一些徘徊在破解边缘的初级破解者，让他们悬崖勒马，转危为安。但是对

于真正想破解的人来说，迷茫只会增加阅读的难度。我相信做开发的同学基本上已经反编译

了别人的应用。通过jadx、apktool、dex2jar等反编译工具，非常方便的找到破解的线索，特

别是对于jadx这样的反编译工件，直接把gradle项目导出到AS来检查代码，不太舒服。

 

 

在更高的层面上，我们通过Dexguard、各种第三方so加固服务、shell服务等来保护它。，这

将大大增加裂化器的裂化成本。对于主流的加固技术，相应的开裂技术也非常成熟。所以，

虽然技术牛逼，但是只要破解者知道你的加固方法，他就很容易找到破解方法，也就是比pro

guard多一个Google进程。说了这些代码的安全性，我们来看看密钥的安全性。如前所述，密

钥将在本地“隐藏”。

 

最底层，关键直接放在Java代码里，基本就是忽悠老板。稍微高一点的级别也放在Java代码

里，但不是直接被你发现的。为了增加自信，他会把密钥拆分成几个部分，然后通过一定的

算法计算合成一个完整的密钥，欺骗自己。如果他再高一点，他会把密钥和加解密放进去，

然后把密钥拆散。通过一定的算法进行组装，并且在更高的层次，所以会做签名验证，加一

个花指令，甚至一些人肉混淆(1，I，L)，一步一步的过滤一批小白，初级，中级，高级破解

。然而，世界上没有利润。如果你的App真的有这样的价值，肯定会吸引那些骨灰饼干。毕

竟人怕出名猪怕壮。

 

 

 

当然，谷歌总是后知后觉。在各厂商提供了TrustZone/TEE硬件加密方案后，Google也推出

了Keystore。当然，至少需要API26来使用。所以目前几乎没有App可以达到26的最低版本，

所以没有办法使用Keystore进行安全存储。