SDK不加固会有哪些安全隐患

本篇内容主要讲解“SDK不加固会有哪些安全隐患”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“SDK不加固会有哪些安全隐患”吧!

SDK不加固会存在哪些安全隐患？

1.易被竞品或恶意者窥视内部实现细节或内部调用流程，甚至有可能泄露隐私数据

安卓平台SDK绝大部分都是Java语言编写，容易被反编译。如果只是简单的混淆，很容易被窥探到内部实现细节；如果SDK内部有一些涉及隐私的数据，很容易被泄漏。更重要的是，如果这些细节涉及到关键技术实现点的话，无异于泄漏核心技术。

2.被恶意者通过字节码注入等手段植入恶意广告或恶意代码然后重打包发布

由于SDK的特殊性，不像App那样存在签名校验逻辑，因此一旦恶意者在你的SDK中植入了一些恶意代码或恶意广告然后重新发布的话，将很难察觉，严重影响开发厂商的品牌形象与口碑。

3.被破解者绕过关键逻辑造成经济损失

如果SDK存在支付功能，被恶意者分析找到付费逻辑，恰巧涉及付费相关逻辑也未很好的做服务端校验的话，一旦恶意者通过AOP手段去除这些付费逻辑，意味着将可免费使用付费服务。

4.SDK本身可能存在漏洞，易被恶意者利用

SDK开发者在开发中往往把开发重点聚焦在了功能的实现上，在安全性上一般不会过多重视，因此很难保证自己开发的SDK不存在任何漏洞。因此一旦SDK出现一些安全漏洞，同时这些漏洞被恶意者知道进而利用，那就如同埋下了一颗随时可能引爆的地雷。不仅危及用户的数据及隐私安全，一旦出现事故将会严重影响SDK开发厂商的口碑，甚至造成经济赔偿。

如何解决

通过上面对安全隐患分析可知，问题的关键在于恶意者容易窥探到SDK的实现逻辑。因此建议开发者做如下防护措施：

1.关键数据的修改必须通过服务端校验：例如前面提到的付费相关逻辑，涉及余额或支付的金额等数据的修改必须先通过服务端校验，然后将结果同步到客户端；

2.关键逻辑放到Native层实现：将Java层的一些关键逻辑转移到JNI层用C/C++实现，提高反编译门槛；

3.字符串进行加密：代码中的字符串，尤其是敏感信息的字符串必须加密，运行时解密。

但是做到了上面几点还不够，只能防住一般的开发者。在专业的破解者面前，我们辛辛苦苦开发的SDK很可能沦为了他们手中的炮灰，进而造成经济损失。

因此建议接入第三方的安全服务，比如易盾的SDK加固服务。

易盾SDK加固介绍

在介绍易盾SDK加固之前，先介绍下目前市面上绝大部分开发者使用的混淆的方式——Proguard。Proguard是安卓平台使用最广泛的混淆，通过抽象语法树从语法层面进行处理，使得处理后的代码难以阅读和理解。如下所示：

不过将类名和方法名修改为一些无意义的随机字符串，比如“a,b,c”，虽然能够提高破解者阅读与理解成本，但是很显然作用是极其有限的。对于破解者而言，分析出代码的意图只是时间的问题。

那么易盾的SDK加固解决方案是什么样呢？接下来为大家介绍：

1.易盾SDK加固VMP方案

将待保护类的方法进行抽空，并对抽取的指令加密处理，在运行时通过自定义虚拟机执行，从而使得破解者无法得到原始代码逻辑。

效果如下：

2.易盾SDK加固Java2c方案

该方案是将待保护类的方法Native化，同时将原函数实现逻辑转为Native层对应的C/C++代码，运行时直接执行对应的Native函数。效果如下：

加固前示例

加固后示例

从静态分析角度看，和Proguard混淆相比，很明显加固后的方法已Native化，实现逻辑在Java层已完全不可见。Java层原函数逻辑转为了JNI层的C/C++代码实现，同时会对生成的Native层SO进行加密，全方位提高破解难度。

（注：上图为了更清楚的看到加固后的方法已经转为对应Native层实现，未对生成的Native层SO进行加密，实际情况易盾SDK加固Java2c方案会对加固后生成的Native层SO进行加密）

到此，相信大家对“SDK不加固会有哪些安全隐患”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！