随着移动互联网的迅猛发展,各种App层出不穷的同时,也催生了大量的提供专业技术服务的2B厂商,这些厂商提供专业的SDK封装了复杂的逻辑实现原理与细节,服务基本涵盖了IM、地图、统计、广告、推送等等各个行业和场景。对于开发者而言,引入这些SDK可大大缩短移动App开发周期,使得开发者可以更专注自己的业务实现。对于SDK厂商而言,则可以通过提供专业技术服务获取收入,可谓是双赢。
但是对市面上的SDK进行抽样检测发现,绝大部分SDK除了基本的混淆外无任何其他安全措施,这给接入的开发者埋下了诸多安全隐患。
笔者建议,SDK厂商在功能实现的同时,也不应该无视其安全性,这不仅仅是对接入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方案
将待保护类的方法进行抽空,并对抽取的指令加密处理,在运行时通过自定义虚拟机执行,从而使得破解者无法得到原始代码逻辑。
效果如下:
从静态分析角度看,和Proguard混淆相比,很明显加固后的原函数实现逻辑已完全不可见,同时将抽取的指令放到JNI层执行,并对指令操作码做了重新映射,提高了动态分析破解的难度。如下所示:
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开发者而言,在聚焦核心功能实现的同时,不应该忽略其安全性,这不仅仅是对SDK的使用者负责,更是避免自己辛辛苦苦开发的SDK成为别人手中炮灰,造成实际经济损失,或被恶意者植入非法代码,影响企业品牌形象与口碑的有效手段。