-
-
[原创]浅谈安卓app加固那点事
-
发表于: 2016-10-12 10:00
-
最近研究了app加固方面,本来这篇文章是给计算机B类论文投稿的,最后他们居然说不收让我投C类.. mdzz拿看雪来吧,以前就在看雪学习了..也没分享点什么出来 = =.. 简单分享下在app加固方面自己的心得,(表哥求不打)
前言:
随着各大主流厂商的智能手机领域渗透到了人们的日常和安卓系统的越来越成熟
app开发人员队伍也逐渐庞大了起来,世面上的两大主流开发:
IOS 和Android app的文件格式呢也就是 .ipa 和 .apk
当XcodeGhost事件以来人们开始关注app安全这个领域,
从开发的角度来讲则是app源代码安全问题,基于代码审计层次的。
从软件保护角度来讲app安全则是对源代码的代码混淆,资源加密,逻辑加固。
从用户的角度来讲就是app本身的安全性,是否会对个人隐私财产造成损失,是否是值得信赖的第三方平台。
一．App加固回溯:
移动平台攻防技术的发展基本是沿着PC端发展轨迹在进行,从windows平台的加壳脱壳反调试反反调试到Andriod的平台apk加固,反调试代码混淆,加强壳
Windows平台下ring3到ring0层的反调试技术已经非常成熟,相对于ipa的加固,android的已经明显要比IOS做的好,世面已经有很多家可以拿出自己产品的app加固方案并投入产品中。
为什么要有app加固这个环节呢 ?
其实就和PC上所说的为什么要有壳这个问题是一类,没有加固的App经过反编译之后,所有资源,算法,代码逻辑,内部封装,赤裸裸的躺在那里,毫无隐私和保密可言. 笼统的说app加固是对原本容易暴露的程序和运行逻辑进行保护，而不影响程序本身的运行结果。详细点说，就是在二进制的程序中植入一段代码，在运行的时候优先取得程序的控制权，做一些额外的工作。大多数病毒就是基于此原理,是应用加固的一种手法对原始二进制原文进行加密/隐藏/混淆，类似于PC上的壳。
二．剖析App加固:
从App的加固技术来看:主流分为dex加密和so加密,目前来看保护dex文件更为重要,应为dex反编译后的java代码可读性更强。
从核心逻辑上来看:一种是动态载入,另一种是vmp相当于自己实现虚拟机但通常只是简单的指令替换,由于兼容性问题目前还没发现遇到dex文件的加固用vmp,这也体现了移动app的加壳思想也不乏有PC上的加壳技术的身影
从加固的范围来看:可以分为dex加固,so和dex加固,核心逻辑加固,因为加固会影响运行效率,所以有些加固只是对核心逻辑进行有效的保护,所以导致多数的维护运行的代码还是在程序里裸奔的
App安全加固的必要性:
有效减少app二次打包,没加固的容易被破解,被重打包,造成仿冒应用泛滥,甚至犯罪分子会增加恶意代码重打包发布,严重影响厂商利益,威胁用户信息安全
而且,随着加固技术的发展,也带来了脱壳技术的提升,有些病毒就是重打包一些热门游戏,向里面增加病毒代码进行传播,还有一点就是加固服务,这个也是针对于打包党的,这种现象造成了攻防相互促进随之也推动之app安全的发展
有些代码会有一些漏洞,apk加固也可以在一定程度上做保护,给开发更多的时间去维护完善代码。重打包的app从外面几乎分辨不出来,大多数的用户识别不出,在有了app加固技术对被破解有很大的保护作用。
三.App安全加固思路:
1. 目前app加固几乎都是利用DexClassLoader通过动态加载dex来实现的但由于这段逻辑本身会暴露dex文件,所以经常配合反调试技术。
2. 逻辑混淆.另一方面还可以对一些文件的特殊内容进行检查,或者检查代码运行时间,来判断是否在被调试。
3. 在resource文件中做一些手脚,可以影响apktools,比如在smali里面加一些代码,可以影响baksmali工具,不过这些都是辅助性的。
4. 防止反编译的技术,多数为代码混淆,替换类名和变量名,使可读性降低。
5. 在对抗一些脱壳工具方面,会在程序中做hook,检查是否有特殊的逻辑存在,甚至自己实现DexClassLoader的
市面上常见的加固工具加固之后,他会把你的dex,so 加密存在apk中,然后运行过程会先运行壳的代码,壳的代码再把原来的这个dex、so 解出来加载,不同的厂商有自己的方案,略有差距,但目前多数都是这个思路.
四．App安全加固案例:
国内在App加固上做的不错的:娜迦科技,梆梆安全,爱加密,阿里聚,360…
⑴我们先看一个早先版本的阿里的dex加密技术
经过加密后的程序会有一些额外的文件：
libmobisecx.so/libmobisecy1.so/ibmobisecz1.so
其中有一个是加过壳的so文件,但不是程序本身的,而是ali加壳解密的核心逻辑,在so中,几乎所有的字符串都是被加密过的,可以通过两段数据解密得到,这样就可以很大程度上防止通过字符串来推测逻辑,应为很多字符串是一些函数名或者参数,在so中许多逻辑都是反射调用Java层实现的,这类代码逻辑不容易弄清,会增大跟踪难度,so层很多函数名都被混淆。此so的反调试技术有检查TracerPid和命令行的gdb gdbserver android_server等,ali的核心逻辑基本都是动态加载解密的,ali的壳在调用DexClassLoader的时候,加载的是不完整的dex,在加载真正的类的时候,会重新修改一些偏移,使文件变得完整。再具体的细节就比较麻烦了…
这里随便拿两张混淆前和混淆后的图片进行比对
这是加固前的
这是加固后的; 一目了然,目录下多了很多东西
不光阿里的混淆,其他厂商的有些加固后,全部的函数名都被改成了没有意义的字符,但通常开发都会保留一份原始未混淆加密的源文件进行维护调试升级
⑵我们再看一个梆梆安全使用的一个app加固
见上图可以看到梆梆采用了so库函数代码混淆,在反调试技术上梆梆使用了多线程‘互相监督’没记错的话这个应该是libsecmain.so是入口可执行程序,fork之后，子进程execl替换了原程序,做起了’专职监护人’在使用这些加固产品之前,有些工作可以自己试着做一下,比如说java代码中字符串加密,自己实现加密算法,全部用加密字符串,在代码中解密
这些简单的工作都会增加Cracker的逆向难度,如图是一个上千万装机量app使用一个加密方式,类似的工具APKProtector就有这样的功能,但也有缺陷,即便脱壳成功,代码的可读性也不是很好
五．App加固的利弊:
任何事物当然有利就有弊,
我的理解App加固产生的影响有两方面,正面和负面
正面:
1.保护自己核心代码算法,提高破解/盗版/二次打包的难度
2.缓解代码注入/动态调试/内存注入攻击
负面：
1.影响兼容性
2.影响程序运行效率.
3.部分流氓、病毒也会使用加壳技术来保护自己
4.部分应用市场会拒绝加壳后的应用上架
在不影响效率的情况下，增加逻辑的复杂性是很不错的选择。
但是如果遇到这种情况就悲催了………
因为app加固之后,应用商店审核起来麻烦,也为了防止被人把加固后的恶意软件或病毒放入应用商店,所以做的限制。
兼容性问题是app加固技术上的一个难题,很多时候为了追求兼容性不得不放弃一些技术,梆梆安全也是和兼容性做了很长的一段斗争才走到今天的。
其实对于很多的静态分析工具来说,如果加了壳,应该得到的是壳的代码,所以分析不出来有用的结果,并且目前很多应用市场要求程序带有自己的加固方案,导致相当一部分app不能上架,或者发布不同的apk,需要维护多版本,例如说360的加固的应用,百度认为不能确保程序的安全性,就不会发布,这样的话不同的发布平台审核的工作量就大了…
目前大的加固厂家兼容性、运行效果都做的还是不错的，需要多试一试
六．App安全未来展望:
一款app的流水线,从开发到内测到平台到消费者再到破解者再到平台再到消费者(shouhaizhe) 如图:
对于一款app的流水线,每一个环节都不可轻视,
1.开发人员一个操作失误,比如说接口调用不当,造成内部数据访问泄漏,源代码被审计,被开发的盯上是个损失,被黑客盯上就没那么简单了
2.用户体验,功能需要完善的地方,这是要整体把握app的架构的时候,不局限于app加固,源代码审计,还要综合测评整个架构,网路、后台、数据交互。
3.第三方平台,这是app营销策略中常见的一种,推广成本较低,在app刚兴起的时候,国内的第三方平台鱼龙混杂,用户毫无安全性可言,好在近年来有了新政策,对于app上线行为规定和法律准则,法律趋近完善
4.当一款app到达了一个cracker的手中,破还是不破?这个选择是要看app的价值和所投入破解的精力而言,其实没有一个程序是坚不可摧的,同样的知识储备只要肯付出时间和精力,都可以crack out出来的,在这方面就是开发人员和cracker的技术较量了,这时就看开发人员的对app加固技术的水准咯.
5.还是app下载渠道问题,这时第三方厂商应该加强对app的审核,app来源的身份认证等
人们的生活越来越智能化,人门娱乐,旅游,出行,社交,饮食,学习,互联网的时代智能手机已经逐渐替代了PC，其中App在其中起着不可替代的作用,正在改变人们的生活方式,app安全也会越来越受安全行业青睐。
参考资料：
京东安全应急响应中心 APP安全加固技术的讨论——安全小课堂第二十八期
http://mp.weixin.qq.com/s?__biz=MjM5OTk2MTMxOQ==&mid=2727827401&idx=1&sn=8af07161433d1050ca67b1241b916f14&scene=4#wechat_redirect
随着各大主流厂商的智能手机领域渗透到了人们的日常和安卓系统的越来越成熟
app开发人员队伍也逐渐庞大了起来,世面上的两大主流开发:
IOS 和Android app的文件格式呢也就是 .ipa 和 .apk
当XcodeGhost事件以来人们开始关注app安全这个领域,
从开发的角度来讲则是app源代码安全问题,基于代码审计层次的。
从软件保护角度来讲app安全则是对源代码的代码混淆,资源加密,逻辑加固。
从用户的角度来讲就是app本身的安全性,是否会对个人隐私财产造成损失,是否是值得信赖的第三方平台。
一．App加固回溯:
移动平台攻防技术的发展基本是沿着PC端发展轨迹在进行,从windows平台的加壳脱壳反调试反反调试到Andriod的平台apk加固,反调试代码混淆,加强壳
Windows平台下ring3到ring0层的反调试技术已经非常成熟,相对于ipa的加固,android的已经明显要比IOS做的好,世面已经有很多家可以拿出自己产品的app加固方案并投入产品中。
为什么要有app加固这个环节呢 ?
其实就和PC上所说的为什么要有壳这个问题是一类,没有加固的App经过反编译之后,所有资源,算法,代码逻辑,内部封装,赤裸裸的躺在那里,毫无隐私和保密可言. 笼统的说app加固是对原本容易暴露的程序和运行逻辑进行保护，而不影响程序本身的运行结果。详细点说，就是在二进制的程序中植入一段代码，在运行的时候优先取得程序的控制权，做一些额外的工作。大多数病毒就是基于此原理,是应用加固的一种手法对原始二进制原文进行加密/隐藏/混淆，类似于PC上的壳。
二．剖析App加固:
从App的加固技术来看:主流分为dex加密和so加密,目前来看保护dex文件更为重要,应为dex反编译后的java代码可读性更强。
从核心逻辑上来看:一种是动态载入,另一种是vmp相当于自己实现虚拟机但通常只是简单的指令替换,由于兼容性问题目前还没发现遇到dex文件的加固用vmp,这也体现了移动app的加壳思想也不乏有PC上的加壳技术的身影
从加固的范围来看:可以分为dex加固,so和dex加固,核心逻辑加固,因为加固会影响运行效率,所以有些加固只是对核心逻辑进行有效的保护,所以导致多数的维护运行的代码还是在程序里裸奔的
App安全加固的必要性:
有效减少app二次打包,没加固的容易被破解,被重打包,造成仿冒应用泛滥,甚至犯罪分子会增加恶意代码重打包发布,严重影响厂商利益,威胁用户信息安全
而且,随着加固技术的发展,也带来了脱壳技术的提升,有些病毒就是重打包一些热门游戏,向里面增加病毒代码进行传播,还有一点就是加固服务,这个也是针对于打包党的,这种现象造成了攻防相互促进随之也推动之app安全的发展
有些代码会有一些漏洞,apk加固也可以在一定程度上做保护,给开发更多的时间去维护完善代码。重打包的app从外面几乎分辨不出来,大多数的用户识别不出,在有了app加固技术对被破解有很大的保护作用。
三.App安全加固思路:
1. 目前app加固几乎都是利用DexClassLoader通过动态加载dex来实现的但由于这段逻辑本身会暴露dex文件,所以经常配合反调试技术。
2. 逻辑混淆.另一方面还可以对一些文件的特殊内容进行检查,或者检查代码运行时间,来判断是否在被调试。
3. 在resource文件中做一些手脚,可以影响apktools,比如在smali里面加一些代码,可以影响baksmali工具,不过这些都是辅助性的。
4. 防止反编译的技术,多数为代码混淆,替换类名和变量名,使可读性降低。
5. 在对抗一些脱壳工具方面,会在程序中做hook,检查是否有特殊的逻辑存在,甚至自己实现DexClassLoader的
市面上常见的加固工具加固之后,他会把你的dex,so 加密存在apk中,然后运行过程会先运行壳的代码,壳的代码再把原来的这个dex、so 解出来加载,不同的厂商有自己的方案,略有差距,但目前多数都是这个思路.
四．App安全加固案例:
国内在App加固上做的不错的:娜迦科技,梆梆安全,爱加密,阿里聚,360…
⑴我们先看一个早先版本的阿里的dex加密技术
经过加密后的程序会有一些额外的文件：
libmobisecx.so/libmobisecy1.so/ibmobisecz1.so
其中有一个是加过壳的so文件,但不是程序本身的,而是ali加壳解密的核心逻辑,在so中,几乎所有的字符串都是被加密过的,可以通过两段数据解密得到,这样就可以很大程度上防止通过字符串来推测逻辑,应为很多字符串是一些函数名或者参数,在so中许多逻辑都是反射调用Java层实现的,这类代码逻辑不容易弄清,会增大跟踪难度,so层很多函数名都被混淆。此so的反调试技术有检查TracerPid和命令行的gdb gdbserver android_server等,ali的核心逻辑基本都是动态加载解密的,ali的壳在调用DexClassLoader的时候,加载的是不完整的dex,在加载真正的类的时候,会重新修改一些偏移,使文件变得完整。再具体的细节就比较麻烦了…
这里随便拿两张混淆前和混淆后的图片进行比对
不光阿里的混淆,其他厂商的有些加固后,全部的函数名都被改成了没有意义的字符,但通常开发都会保留一份原始未混淆加密的源文件进行维护调试升级
⑵我们再看一个梆梆安全使用的一个app加固
见上图可以看到梆梆采用了so库函数代码混淆,在反调试技术上梆梆使用了多线程‘互相监督’没记错的话这个应该是libsecmain.so是入口可执行程序,fork之后，子进程execl替换了原程序,做起了’专职监护人’在使用这些加固产品之前,有些工作可以自己试着做一下,比如说java代码中字符串加密,自己实现加密算法,全部用加密字符串,在代码中解密
这些简单的工作都会增加Cracker的逆向难度,如图是一个上千万装机量app使用一个加密方式,类似的工具APKProtector就有这样的功能,但也有缺陷,即便脱壳成功,代码的可读性也不是很好
五．App加固的利弊:
任何事物当然有利就有弊,
我的理解App加固产生的影响有两方面,正面和负面
正面:
1.保护自己核心代码算法,提高破解/盗版/二次打包的难度
2.缓解代码注入/动态调试/内存注入攻击
负面：
1.影响兼容性
2.影响程序运行效率.
3.部分流氓、病毒也会使用加壳技术来保护自己
4.部分应用市场会拒绝加壳后的应用上架
在不影响效率的情况下，增加逻辑的复杂性是很不错的选择。
但是如果遇到这种情况就悲催了………
因为app加固之后,应用商店审核起来麻烦,也为了防止被人把加固后的恶意软件或病毒放入应用商店,所以做的限制。
兼容性问题是app加固技术上的一个难题,很多时候为了追求兼容性不得不放弃一些技术,梆梆安全也是和兼容性做了很长的一段斗争才走到今天的。
其实对于很多的静态分析工具来说,如果加了壳,应该得到的是壳的代码,所以分析不出来有用的结果,并且目前很多应用市场要求程序带有自己的加固方案,导致相当一部分app不能上架,或者发布不同的apk,需要维护多版本,例如说360的加固的应用,百度认为不能确保程序的安全性,就不会发布,这样的话不同的发布平台审核的工作量就大了…
目前大的加固厂家兼容性、运行效果都做的还是不错的，需要多试一试
六．App安全未来展望:
一款app的流水线,从开发到内测到平台到消费者再到破解者再到平台再到消费者(shouhaizhe) 如图:
对于一款app的流水线,每一个环节都不可轻视,
1.开发人员一个操作失误,比如说接口调用不当,造成内部数据访问泄漏,源代码被审计,被开发的盯上是个损失,被黑客盯上就没那么简单了
2.用户体验,功能需要完善的地方,这是要整体把握app的架构的时候,不局限于app加固,源代码审计,还要综合测评整个架构,网路、后台、数据交互。
3.第三方平台,这是app营销策略中常见的一种,推广成本较低,在app刚兴起的时候,国内的第三方平台鱼龙混杂,用户毫无安全性可言,好在近年来有了新政策,对于app上线行为规定和法律准则,法律趋近完善
4.当一款app到达了一个cracker的手中,破还是不破?这个选择是要看app的价值和所投入破解的精力而言,其实没有一个程序是坚不可摧的,同样的知识储备只要肯付出时间和精力,都可以crack out出来的,在这方面就是开发人员和cracker的技术较量了,这时就看开发人员的对app加固技术的水准咯.
5.还是app下载渠道问题,这时第三方厂商应该加强对app的审核,app来源的身份认证等
人们的生活越来越智能化,人门娱乐,旅游,出行,社交,饮食,学习,互联网的时代智能手机已经逐渐替代了PC，其中App在其中起着不可替代的作用,正在改变人们的生活方式,app安全也会越来越受安全行业青睐。
参考资料：
京东安全应急响应中心 APP安全加固技术的讨论——安全小课堂第二十八期
http://mp.weixin.qq.com/s?__biz=MjM5OTk2MTMxOQ==&mid=2727827401&idx=1&sn=8af07161433d1050ca67b1241b916f14&scene=4#wechat_redirect
[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
版主棒棒哒！正在写论文，看雪是个技术氛围浓厚的好地方;-)
您最后提到的Oakland的SoK文章是？想学习，请问有链接吗 好像没有搜到  |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 大大，请问一下最新的百度加固，oncreate函数是否是vmp了，在dalvik各个关键的函数和指令执行的函数，均没有打印出被抽取的函数指令，请问最新的百度是不是已经实现了oncreate函数的vmp了啊，求偶像指点！！！
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
看雪微信公众号转了你这文章，被人投述，请确认一下你这文章来源是哪里的？真是原创吗？论坛短消息你了。
请PCbots速速联系我 
|
|
|
|
