CN105068932B - 一种Android应用程序加壳的检测方法 - Google Patents
一种Android应用程序加壳的检测方法 Download PDFInfo
- Publication number
- CN105068932B CN105068932B CN201510526462.1A CN201510526462A CN105068932B CN 105068932 B CN105068932 B CN 105068932B CN 201510526462 A CN201510526462 A CN 201510526462A CN 105068932 B CN105068932 B CN 105068932B
- Authority
- CN
- China
- Prior art keywords
- shell
- shell adding
- hook
- file
- classes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Stored Programmes (AREA)
Abstract
本发明公布了一种Android应用程序加壳的检测方法,通过一种Android应用程序的脱壳方法,检测经过加壳处理后的APK是否真正达到了加壳保护的效果;包括步骤:在模拟器上安装Hook工具,并对Hook工具的环境进行配置;安装加壳处理后的APK文件;Hook工具对两个系统函数dvmDexFileOpenFromFd和dvmDexFileOpenPartial进行脱壳得到classes.dex文件;将该classes.dex文件与未加壳的classes.dex文件进行对比,检测是否脱壳成功;对该classes.dex文件进行修复。本发明可以验证一些利用了现有的APK加固工具进行加壳后的应用的加壳效用,也是一种新的检测APK文件安全的方法,对业界APK加固以及风险评估市场有很好的促进作用,除了有很大的商业价值之外,也对移动应用安全方面有很大的促进作用。
Description
技术领域
本发明涉及Android应用程序脱壳方法,尤其涉及一种Android应用程序加壳的检测方法,即通过一种基于JNI Hook的Android应用程序的脱壳方法,检测经过加壳处理后的APK(AndroidPackage的缩写,即Android应用安装包)是否真正达到了加壳保护的效果。
背景技术
随着智能手机的热销,手机上网越来越流行,移动互联时代的爆发更是带动智能手机趋于全能化,伴随手机用户爆炸增长、手机上网愈加便利而来的是,手机安全隐患越来越多、问题越来越突出。根据中国互联网络信息中心(CNNIC)发布《第28次中国互联网络发展状况统计报告》。报告显示,截至2012年6月底,中国手机网民规模首次超越台式电脑用户,达到3.88亿,较2011年底增加了约3270万人。手机网民在总体网民中的比例达65.5%。
目前,一方面,智能手机系统已被国外产品垄断:根据艾媒咨询发布的数据显示,2012第二季度,国外操作系统在我国智能手机中的占比已超过90%。其中,美国谷歌公司的Android系统占比最高达63.1%;芬兰诺基亚公司的塞班系统占比19.9%,苹果公司的iOS操作系统占比11.7%。因为Android系统采取免费、开源的市场策略,导致众多山寨手机和平板电脑大量使用Android系统,而这些充斥在市场之上的山寨机以及变成黑客、恶意程序眼中的“肉鸡”。
另一方面,智能手机信息防范能力弱:与传统手机相比智能手机功能强大,信息覆盖范围广,其操作系统依托于移动互联网,信息泄露隐患大。智能手机内部包含大量私人信息或涉密信息,如定位系统、账户密码、图像图片、通讯录、短信息、通话内容等。而智能手机的诸多功能需要时时连入互联网才能实现,对于很多手机来说在传输数据时缺乏有效保护和加密,从而导致黑客非法盗取用户信息也更为容易。以市场占有量最大的Android系统为例,虽然众多手机厂商可以对系统进行“重新包装”,但是由于系统开源,API接口被广泛使用,通过一定的技术手段有意窃听通话记录或是窃取用户信息,完全没有技术障碍。
再者,应用软件缺乏安全审查机制:由于Google Play在中国地区的不稳定性,国内95%的用户都会选择从国内的第三方应用市场下载App程序。但是当下国内的第三方应用市场已经变成了鱼龙混杂,流氓、病毒软件丛生之地。在国内,第三方应用市场里比较几十家,知名的有安卓、安智、应用汇、机锋网等,国内的应用市场基本都是模仿苹果的应用商城,对外承诺有严格的审核机制,但事实是这些审核基本是空架子。
而在移动互联网安全领域,技术标准存在真空,更缺乏法律规范来保障用户的信息安全。互联网的高速发展,智能手机、平板电脑等各种便携移动设备已经充斥了人们的生活,各种移动应用迅速覆盖了包括出行就餐、日常起居,甚至金融理财等各个领域。然而,正所谓“玫瑰虽好,毒刺伤人”。安卓漏洞、App安全早已饱受诟病,诸如手机吸费、隐私盗取以及各类支付风险也都如鬼魅般如影随形。山寨App和广告插件加剧用户隐私暴露风险,木马病毒泛滥移动互联网安全形势严峻等问题已不可忽视。
由于移动互联网的发展迅速,随其而生的安全问题眼下也无法彻底解决。不断增长的手机用户让恶意软件获得了更多的生存的机会。
针对上述移动互联网应用的安全问题,一些Android应用加固(加壳)产品为移动应用提供专业的加固保护方案,其中一种方法是对Java文件进行加壳处理。但是,这些加固产品的加壳处理起到的保护作用是否有效,现有方法还难以进行检测。
发明内容
为了克服上述现有技术的不足,本发明提供一种Android应用程序加壳的检测方法,通过一种基于JNI Hook的Android应用程序的脱壳方法,检测经过加壳处理后的APK(AndroidPackage的缩写,即Android应用安装包)是否真正达到了加壳保护的效果。
为了便于说明,本文约定:
“APK”是AndroidPackage的缩写,即Android应用安装包;
“Dalvik”是指Google公司设计的用于Android平台的Java虚拟机;
“Manifest”是指Android程序运行清单(AndroidManifest.xml)。
本发明的原理是:提供一种新的方法,对一部分现有的APK中的Classes.dex加壳的工具的效用进行检测;主要是对位于/system/lib/libdvm.so中的函数intdvmDexFileOpenFromFd(int fd,DvmDex**ppDvmDex)以及int dvmDexFileOpenPartial(const void*addr,int len,DvmDex**ppDvmDex)进行Hook处理,具体的是通过交互式反汇编工具IDA工具(IDA是IDA PRO的简称,是英文Interactive Disassembler的缩写)分析函数描述符,并分析DvmDex数据结构,保存到本地。对两个函数进行Hook处理后,当函数dvmDexFileOpenFromFd执行dex文件时会跳转到保存到本地的解壳程序,该解壳程序为本发明方法提供的解壳程序(本发明称为脱壳工具),通过该脱壳工具处理Hook函数传入的DvmDex数据结构参数;由于此时由加壳软件添加的解壳程序已经将加壳的classes.dex文件进行解壳,因此此时传入的DvmDex数据结构便包含已经解壳后的classes.dex文件数据。该脱壳工具通过获取DvmDex数据结构中的DexFile结构指针,并调用write函数,将DexFile结构中的成员baseAddr指向的内存数据,写入本地文件,即可得到脱壳后的classes.dex文件;再归还DvmDex数据结构,还原系统对Hook函数的调用,该脱壳工具输出未加壳的dex文件,再返回函数dvmDexFileOpenFromFd继续原来的流程;同理的,dvmDexFileOpenPartial函数是用来处理odex文件的,对它进行Hook处理后,在执行该函数时会执行保存在本地的脱壳工具,此该脱壳工具主要是输出本发明方法得到的未加壳处理的dex文件;输出的dex文件即本发明方案输出的结果,与APK未加壳前的dex文件进行对比;人工检查输出的dex文件也可以检测出是否对加壳后的dex文件脱壳成功,主要是对加壳前的、加壳后的以及利用了本发明方案提供的脱壳工具进行脱壳后的dex文件进行分析,利用APKTool逆向工具查看dex,将dex还原为jar包,再利用APKTool逆向工具查看源码;若加壳后的dex文件无法得到源码,加壳前以及利用本发明的脱壳方法进行脱壳后的dex文件可以查看到源码,说明利用本发明方案脱壳成功;即检测到经过加壳处理后的APK真正达到了加壳保护的效果。
本发明提供的技术方案是:
一种Android应用程序加壳的检测方法,包括如下步骤:
A.在模拟器上,安装采用了本发明提供的Android应用程序脱壳方法的Hook工具;对Hook工具的环境进行配置;
B.安装加壳处理后的APK文件;
C.利用步骤A中的Hook工具,对两个系统函数进行Hook处理(Hook函数dvmDexFileOpenFromFd和Hook函数int dvmDexFileOpenPartial);
进行Hook处理,具体包括如下步骤:
C1.Dalvik虚拟机执行函数int dvmDexFileOpenFromFd(int fd,DvmDex**ppDvmDex),该函数用来处理优化classes.dex文件为odex文件,由于Hook了该函数,所以当Dalvik执行该函数时,会执行本发明方案提供的本地函数;
C2.Hook函数中主要实现了识别函数,如果加固(加壳)的APK文件的解壳程序还原出来的是dex文件,调用脱壳处理程序;
C3.脱壳处理程序主要实现:处理DvmDex数据结构,输出脱壳文件(classes.dex),归还DvmDex数据结构,使程序可以继续原来步骤;
C4.如果解壳程序还原出来的是odex文件,Hook函数调用分支,并实现对函数intdvmDexFileOpenPartial(const void*addr,int len,DvmDex**ppDvmDex)进行Hook,该函数主要是用来处理odex文件,对本方法处理后调用脱壳处理程序,处理DvmDex数据结构,输出脱壳文件classes.dex,归还DvmDex数据结构,系统继续原来步骤;
C5.结束;
D.将Hook工具进行脱壳得到的classes.dex文件与未加壳的classes.dex文件进行对比;
具体地,利用逆向工具(如APkTool、Dex2jar等),将dex文件还原为jar文件,查看jar源码文件,对比两个文件的源码;加壳后的dex文件利用逆向工具是无法查看到源码的(这也是加壳的目的);
也可通过人工检查,验证通过Hook工具进行脱壳得到的classes.dex文件,若能够查看到源码,且能进一步分析源码,说明脱壳(解壳)成功,即实现了脱壳;
若脱壳(解壳)成功,即检测验证了:经过相应的加壳工具进行加壳后,利用本发明方案的脱壳方法,可获得源码并能进一步分析源码;说明该加壳工具的加壳无效;若脱壳(解壳)不成功,即经过相应的加壳工具进行加壳后,利用本发明方案的脱壳方法无法获得源码,则说明该加壳工具的加壳是真正有效的。
E.对输出的classes.dex文件进行修复,结束。
与现有技术相比,本发明的有益效果是:
本发明提供一种Android应用程序加壳的检测方法,通过一种基于JNI Hook的Android应用程序的脱壳方法,检测经过加壳处理后的APK(AndroidPackage的缩写,即Android应用安装包)是否真正达到了加壳保护的效果。具体通过对两个函数dvmDexFileOpenFromFd和dvmDexFileOpenPartial进行Hook处理后,当函数dvmDexFileOpenFromFd执行dex文件时会跳转到保存到本地的解壳程序(本发明称为脱壳工具),通过该脱壳工具处理Hook函数传入的DvmDex数据结构参数;由于此时传入的DvmDex数据结构包含已经解壳后的classes.dex文件数据,该脱壳工具通过获取DvmDex数据结构中的DexFile结构指针,并调用write函数,将DexFile结构中的成员baseAddr指向的内存数据,写入本地文件,得到脱壳后的classes.dex文件;即本发明提供的脱壳工具输出的实际上是未加壳的dex文件;再将Hook工具进行脱壳得到的classes.dex文件与未加壳的classes.dex文件进行对比,从而实现检测加壳保护的效果。利用本发明提供的技术方案,可以验证一些利用了现有的APK加固工具进行加壳后的应用的加壳效用,也是一种新的检测APK文件安全的方法,对业界APK加固以及风险评估市场有很好的促进作用,除了有很大的商业价值之外,也对移动应用安全方面有很大的促进作用。
附图说明
图1是本发明提供的Android应用程序加壳的检测方法的流程框图。
图2是本发明提供检测方法中的Hook工具的实现流程框图。
图3是本发明实施例1执行操作的流程框图。
图4是本发明实施例2执行操作的流程框图。
图5是本发明实施例3执行操作的流程框图。
具体实施方式
下面结合附图,通过实施例进一步描述本发明,但不以任何方式限制本发明的范围。
本发明提供一种Android应用程序加壳的检测方法,通过一种基于JNI Hook的Android应用程序的脱壳方法,检测经过加壳处理后的APK(AndroidPackage的缩写,即Android应用安装包)是否真正达到了加壳保护的效果。
Dalvik虚拟机属于Android运行时环境,它与一些核心库共同承担Android应用程序的运行工作。Dalvik虚拟机是由Dan Bornstein开发的,名字来源于他的祖先曾经居住过的位于冰岛的同名小渔村Dalvik。Dalvik虚拟机起源于Apache Harmony项目,后者是由Apache软件基金会主导的,目标是实现一个独立的、兼容JDK 5的虚拟机,并根据ApacheLicense v2发布。Dalvik虚拟机与Java虚拟机的最显著区别是它们分别具有不同的类文件格式以及指令集。Dalvik虚拟机使用的是dex(Dalvik Executable)格式的类文件,而Java虚拟机使用的是class格式的类文件。一个dex文件可以包含若干个类,而一个class文件只包括一个类。由于一个dex文件可以包含若干个类,因此它就可以将各个类中重复的字符串和其它常数只保存一次,从而节省了空间,这样就适合在内存和处理器速度有限的手机系统中使用。一般来说,包含有相同类的未压缩dex文件稍小于一个已经压缩的jar文件。
本发明实现了Hook工具,Hook本身是在正常的Android应用执行的时候加入了我们想让他执行的模块,相当于是本来是要安装这个应用的,我们在安装的时候放了一个“钩子”,“钓出”我们想要的东西,勾出后可能把这个东西改变一下,然后再放回到我们刚才钓出的地方,让它继续原来的步骤;继续原来的步骤指的就是回到正常的执行上去,这样做不会让用户察觉到;在后台,其实程序并不是用户表面上看到的那样,而是开了个小差执行了别的程序,又回去继续原来的步骤,这个小差就是Hook程序,如果不回到原来正常的执行步骤上去,程序可能就崩溃了,例如,本来是要执行安装的,还没有安装成功就会崩溃,继续原来步骤的作用是回到正常的执行上去。
本发明实现的Hook工具包括Hook函数dvmDexFileOpenFromFd和Hook函数intdvmDexFileOpenPartial;具体地,
Hook函数dvmDexFileOpenFromFd(int fd,DvmDex**ppDvmDex),该函数的主要功能是优化安卓应用程序的dex文件为odex文件,如果解壳程序还原的是dex文件,Dalvik虚拟机(Dalvik Virtual Machine)重新加载执行还原的dex文件,Dalvik会执行函数dvmDexFileOpenFromFd(int fd,DvmDex**ppDvmDex)对dex进行处理,所以Hook该函数,解析DvmDex数据结构,当执行该函数时让系统去执行脱壳处理程序,即保存在本地的核心方法,主要实现输出脱壳后的classes.dex文件功能;
Hook函数int dvmDexFileOpenPartial(const void*addr,int len,DvmDex**ppDvmDex),如果解壳程序还原出来的是odex文件,Dalvik重新加载执行还原的odex文件,Dalvik会运行函数int dvmDexFileOpenPartial(const void*addr,int len,DvmDex**ppDvmDex)对odex进行运行,Hook该函数,解析DvmDex数据结构,当执行该函数时让系统去执行脱壳处理程序,既是保存在本地的核心方法,主要实现输出脱壳后的classes.dex文件功能。
本发明的实施包括:(图2)
A.在模拟器上,安装采用了本发明提供的Android应用程序脱壳方法的Hook工具;对Hook工具的环境进行配置;
配置Hook工具的环境具体包括如下步骤:
A1.创建一个空的工程,由于Hook工具是以插件的形式被加载,不需要界面,所以工具不需要创建Activity,只需要安装;
A2.配置Manifest文件,具体设置如下:
A3.需要指定权限:cydia.permission.SUBSTRATE;
A4.添加meta标签,name为cydia.permission.SUBSTRATE,value为下一步创建的类名的名称,例如:“.Main”;
A5.创建一个类为Main。类中包含static方法initialize,当插件被加载时,该方法中的代码就会运行,完成一些必要的初始化工作;
A6.为了实现Hook,达到修改目标类中的代码的目的,需要得到目标类的一个实例,利用函数void hookClassLoad(String name,MS.ClassLoadHook hook),该函数实现在指定的类(String name)被加载的时候发出通知,执行classLoaded方法,
A7.classLoaded函数中主要实现MS.hookMethod,实现Hook,提供一个回调函数替换原来的函数,这个回调函数是一个实现了MS.MethodHook接口的对象;
A7.通过MS.MethodHook实例实现对原代码的修改;
A8.为了调用原来代码中的函数,创建一个MS.MethodPointer类的实例,它可以在任何时候运行原来的代码,保证程序继续原来步骤,以防止程序崩溃;
A9.Hook工具的环境配置结束;
B.安装加壳处理后的APK文件;
加壳处理后的APK文件主要是对APK中的Java编译后的classses.dex文件进行加壳,Dalvik虚拟机会执行处理classes.dex文件,此时的dex文件中包含加壳工具提供的对应的解壳程序,通过该解壳程序对加壳的dex文件进行还原处理,处理后得到的文件可能是dex格式也可能是odex格式,同时该解壳程序进行重定向处理,使用Dalvik重加载机制,重新加载脱壳后的dex或者odex文件;
针对上述脱壳方法,本发明实施例中应用到的技术是平台Cydia Substrate,该平台提供一个代码修改框架。它可以修改任何主进程的代码,不管是用Java还是C/C++(Native代码)编写的。
安装前,Android应用被打包为APK文件,安装时APK文件解压,在Android平台中Dalvik VM执行APK文件解压后的classes.dex,APK文件的结构包括文件夹META-INF\、文件夹res\、文件AndroidManifest.xml、文件classes.dex、文件resources.arsc、assets文件夹和lib文件夹,具体如下:
B1.META-INF\:该文件夹保存了开发者对应用的数字签名,其中CERT.RSA文件是程序签名使用数字证书的公钥。
B2.res\:存放资源文件的目录,包含了Android应用使用的各类资源文件,包括layout,drawable和raw字目录。
B3.AndroidManifest.xml:程序全局配置文件,它是整个应用的配置清单和组件描述文件。AndroidManifest.xml文件存在每一个apk中,描述了Android应用的全局配置信息。具体包括:程序使用的各类组件的声明,包括Activity,ContentProvider,BroadcastReceiver和Service等;程序的入口点;还有程序为了使用特定API而声明的权限。
B4.classes.dex:Dalvik字节码,它由应用程序的Java源代码编译而来,在运行时首先被动态优化为dex格式的文件,然后由Dalvik虚拟机加载并解释执行。
B5.resources.arsc:编译后的二进制资源文件,该文件包含了应用界面上各组件名称的字符串值,因此目前国内对Android应用软件的汉化工作就包含对这个文件内容的汉化和编辑。
B6.assets文件夹:该文件夹包含了该应用程序使用的一些数据和其他文件,该文件夹下的文件不会被压缩,也不会像res文件夹一样由Android提供的资源类统一管理。并不是所有的应用都会有该文件夹。
B7.lib文件夹:包含了应用程序使用的动态链接库文件,库文件一般使用C或者C++语言开发,以so格式的文件存在。
对APK文件加壳既是对classes.dex加壳,市场上存在的APK加壳工具是利用对classes.dex文件进行加壳处理,实现对APK文件的加壳处理。
C.对Hook工具的两个系统函数(Hook函数dvmDexFileOpenFromFd和Hook函数intdvmDexFileOpenPartial)进行Hook处理;
对于利用Dalvik虚拟机重新加载机制的加壳工具均可以利用本发明提供的Hook工具进行脱壳,得到未加壳的classses.dex。对两个函数进行Hook之后在Dalvik虚拟机执行这两个函数处理dex文件时,例如如果Dalvik利用dvmDexFileOpenFromFd执行dex文件,由于对前者进行了Hook,即是当执行到该函数时会跳转到我们想让他执行的模块中去,这个模块环境就是自己设计的,主要是期望输出未加壳dex文件,然后还有一些恢复处理,主要是使程序继续回到原来跳转的点,继续执行不会崩溃。
进行Hook处理,具体包括如下步骤:
C1.Dalvik虚拟机执行函数int dvmDexFileOpenFromFd(int fd,DvmDex**ppDvmDex),该函数用来处理优化classes.dex文件为odex文件,由于Hook了该函数,所以当Dalvik执行该函数时,会执行本发明方案提供的本地函数;
C2.Hook函数中主要实现了识别函数,如果加壳的APK文件经加壳工具提供的解壳程序还原出来的是dex文件,则调用脱壳工具进行脱壳处理;
C3.脱壳处理主要实现:处理DvmDex数据结构,输出脱壳文件(classes.dex),归还DvmDex数据结构,使程序可以继续原来步骤;
具体地,调用脱壳工具处理HOOK函数传入的DvmDex数据结构参数。由于此时加壳软件添加的解壳程序已经将加壳的classes.dex文件进行解壳,因此此时传入的DvmDex数据结构便包含已经解壳后的classes.dex文件数据。程序通过获取DvmDex数据结构中的DexFile结构指针,并调用write函数,将DexFile结构中的成员baseAddr指向的内存数据,写入本地文件,即可得到脱壳后的classes.dex文件。归还DvmDex数据结构,还原系统对HOOK函数的调用,继续系统原来步骤;
C4.如果通过加壳工具提供的解壳程序还原出来的文件是odex文件,则Hook函数调用分支,并实现对函数int dvmDexFileOpenPartial(const void*addr,int len,DvmDex**ppDvmDex)进行Hook,函数dvmDexFileOpenPartial主要是用来处理odex文件;对函数dvmDexFileOpenPartial进行Hook处理后调用脱壳工具进行脱壳处理;具体是:处理DvmDex数据结构,输出脱壳文件classes.dex,归还DvmDex数据结构,系统继续原来步骤;
C5.结束;
D.将Hook工具进行脱壳得到的classes.dex文件与未加壳的classes.dex文件进行对比;
具体地,利用逆向工具(如APKTool、Dex2jar等),将dex文件还原为jar文件,查看jar源码文件,对比两个文件的源码;加壳后的dex文件利用逆向工具是无法查看到源码的(这也是加壳的目的);
通过人工检查,验证通过Hook工具进行脱壳得到的classes.dex文件,若能够查看到源码,且能进一步分析源码,说明脱壳(解壳)成功,即实现了脱壳;
若脱壳(解壳)成功,即检测验证了:经过相应的加壳工具进行加壳后,利用本发明方案的脱壳方法,可获得源码并能进一步分析源码;
E.对输出的classes.dex文件进行修复,结束。
下面通过实例对本发明做进一步说明。其中,加壳工具本身提供有解壳的过程,使得加壳后的程序能够安装,但是通过加壳工具本身提供的解壳程序解壳出的文件可能是dex文件或odex文件。以下实施例1和2中,实施例1说明的是通过加壳工具本身提供的解壳程序解壳出的文件是dex文件的情况,该情况下,Hook的是dvmDexFileOpenFromFd函数;实施例2说明的是通过加壳工具本身提供的解壳程序解壳出的文件是odex文件的情况,该情况下,Hook的是dvmDexFileOpenPartial函数。实施例3说明通过一类加壳工具加壳后的文件,通过本发明方案提供的脱壳方法,并不能取出解壳后的dex文件,此情况下,说明通过本发明方案的验证,该加壳工具达到了加壳保护的效果。
实施例1:
假定一个用Java语言编写的Android应用检测系统中,利用本发明方案对加壳后的APK应用进行检测,检测加壳后APK应用是否产生效用。
设定加壳后的应用名称为MyApplication。Android应用检测系统名称为AnproAss。检测的具体步骤如下(如图3):
1)在模拟器MyTest中安装应用检测系统AnproAss;
2)AnproAss对系统/system/lib/libdvm.so中的int dvmDexFileOpenFromFd(intfd,DvmDex**ppDvmDex)函数进行Hook;
3)模拟器MyTest安装MyApplication;
4)运行脱壳处理程序(脱壳工具),主要是处理Hook函数传入的DvmDex数据结构参数。此时加壳软件添加的解壳程序已经将加壳的classes.dex文件进行解壳,因此,此时传入的DvmDex数据结构中包含已经解壳后的classes.dex文件数据;获取DvmDex数据结构中的DexFile结构指针,并调用write函数,将DexFile结构中的成员baseAddr指向的内存数据,写入本地文件,即可得到脱壳后的classes.dex文件;归还DvmDex数据结构,还原系统对Hook函数的调用,继续系统原来步骤;
5)取出输出的classes.dex;
6)对比未加壳前的classes.dex文件,应用AnproAss输出的classes.dex与未加壳前的classes.dex,进行修复;
7)如果输出的classes.dex文件通过逆向工具,还原为jar包后,通过查看源码工具对比未加壳前的源码与本发明方案得到的源码,如果人工分析后,本发明方案得到的源码与未加固的源码基本一致,并且可以进一步分析源码,说明本发明方案可以对该方式的加壳进行解壳。
实施例2:
假定一个用Java语言编写的Android应用检测系统中,利用该发明方案对加壳后的APK应用进行检测,检测加壳后APK应用是否产生效用,设定加壳后的应用名称为MyApplication。Android应用检测系统名称为AnproAss。具体步骤如下(如图4):
1)在模拟器MyTest中安装应用检测系统AnproAss;
2)AnproAss对系统/system/lib/libdvm.so中的int dvmDexFileOpenPartial(const void*addr,int len,DvmDex**ppDvmDex)函数进行Hook;
3)模拟器MyTest安装MyApplication;
4)运行脱壳处理程序(脱壳工具),主要是处理Hook函数传入的DvmDex数据结构参数。此时加壳软件添加的解壳程序已经将加壳的classes.dex文件进行解壳,因此,此时传入的DvmDex数据结构中包含已经解壳后的classes.dex文件数据;
获取DvmDex数据结构中的DexFile结构指针,并调用write函数,将DexFile结构中的成员baseAddr指向的内存数据,写入本地文件,即可得到脱壳后的classes.dex文件;
归还DvmDex数据结构,还原系统对Hook函数的调用,继续系统原来步骤;
5)取出输出的classes.dex;
6)对比未加壳前的classes.dex文件,应用AnproAss输出的classes.dex与未加壳前的classes.dex;
7)如果输出的classes.dex文件通过逆向工具,还原为jar包后,通过查看源码工具对比未加壳前的源码与本发明方案得到的源码,如果人工分析后,本发明方案得到的源码与未加固的源码基本一致,并且可以进一步分析源码,说明本发明方案可以对该方式的加壳进行解壳。
实施例3:
假定一个用Java语言编写的Android应用检测系统中,利用该发明方案对加壳后的APK应用进行检测,检测加壳后APK应用是否产生效用,设定加壳后的应用名称为MyApplication。Android应用检测系统名称为AnproAss。具体步骤如下(如图5):
1)在模拟器MyTest中安装应用检测系统AnproAss;
2)安装加壳后的Android应用MyApplication;
3)Dalvik加载加壳的MyApplication的classes.dex文件;
4)Dalvik未重新加载dex或者odex文件;
5)未得到classes.dex文件;
6)本发明方案不可以对该方式的加壳进行脱壳。
经过相应的加壳工具进行加壳后,利用本发明方案的脱壳方法,可获得源码并能进一步分析源码;说明该加壳工具的加壳无效;若脱壳(解壳)不成功,即经过相应的加壳工具进行加壳后,利用本发明方案的脱壳方法无法获得源码,则说明该加壳工具的加壳是真正有效的。上述实施例3采用的加壳工具真正达到了加壳效果;而实施例1和2采用的加壳工具则未达到加壳保护的效果。
需要注意的是,公布实施例的目的在于帮助进一步理解本发明,但是本领域的技术人员可以理解:在不脱离本发明及所附权利要求的精神和范围内,各种替换和修改都是可能的。因此,本发明不应局限于实施例所公开的内容,本发明要求保护的范围以权利要求书界定的范围为准。
Claims (5)
1.一种Android应用程序加壳的检测方法,通过一种Android应用程序的脱壳方法,检测经过加壳处理后的APK是否真正达到了加壳保护的效果;包括如下步骤:
A)在模拟器上安装Hook工具,并对Hook工具的环境进行配置;所述Hook工具采用了所述Android应用程序的脱壳方法;
B)安装加壳处理后的APK文件;
C)利用步骤A)中的Hook工具,对两个系统函数进行Hook处理,进行脱壳得到classes.dex文件;所述两个系统函数为函数dvmDexFileOpenFromFd和Hook函数intdvmDexFileOpenPartial;对两个系统函数进行Hook处理,具体包括如下步骤:
C1.若通过加壳工具本身提供的解壳程序解壳出的文件是dex文件,则Hook的函数是dvmDexFileOpenFromFd方法,转入步骤C3调用脱壳处理程序;
C2.若通过加壳工具本身提供的解壳程序解壳出的文件是odex文件,则Hook的函数是dvmDexFileOpenPartial方法,转入步骤C3调用脱壳处理程序;
C3.脱壳处理程序处理DvmDex数据结构并输出脱壳文件classes.dex;
D)将Hook工具进行脱壳得到的classes.dex文件与未加壳的classes.dex文件进行对比;检测是否脱壳成功;从而得到加壳处理是否达到加壳保护效果的结果;
E)对步骤C)中输出的classes.dex文件进行修复,操作执行结束。
2.如权利要求1所述Android应用程序加壳的检测方法,其特征是,步骤A)配置Hook工具的环境具体包括创建一个空的工程和配置Manifest文件;所述配置Manifest文件具体包括:指定权限、添加meta标签、创建一个包含static方法initialize的类Main、利用方法hookClassLoad实现在指定的类被加载时执行classLoaded方法、所述classLoaded方法实现Hook并提供一个实现了MS.MethodHook接口的对象的回调函数以替换原来的方法、通过MS.MethodHook实例实现对原代码的修改、创建一个MS.MethodPointer类的实例使得在任何时候都能正常运行原代码。
3.如权利要求1所述Android应用程序加壳的检测方法,其特征是,步骤B)所述安装时APK文件被解压缩;所述APK文件的结构包括文件夹META-INF\、文件夹res\、文件AndroidManifest.xml、文件classes.dex、文件resources.arsc、assets文件夹和lib文件夹;APK文件解压后的所述文件classes.dex在Android平台中由Dalvik VM执行。
4.如权利要求1所述Android应用程序加壳的检测方法,其特征是,步骤D)所述对比具体利用逆向工具将所述dex文件还原为jar文件,通过查看jar源码文件来对比Hook工具进行脱壳得到的classes.dex文件与未加壳的classes.dex文件的源码。
5.如权利要求4所述Android应用程序加壳的检测方法,其特征是,所述逆向工具为APKTool或Dex2jar。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510526462.1A CN105068932B (zh) | 2015-08-25 | 2015-08-25 | 一种Android应用程序加壳的检测方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510526462.1A CN105068932B (zh) | 2015-08-25 | 2015-08-25 | 一种Android应用程序加壳的检测方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105068932A CN105068932A (zh) | 2015-11-18 |
CN105068932B true CN105068932B (zh) | 2017-09-26 |
Family
ID=54498309
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510526462.1A Active CN105068932B (zh) | 2015-08-25 | 2015-08-25 | 一种Android应用程序加壳的检测方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105068932B (zh) |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105989252B (zh) * | 2015-12-12 | 2018-10-12 | 武汉安天信息技术有限责任公司 | 一种针对函数级别加壳的脱壳方法及系统 |
CN105844150A (zh) * | 2016-03-23 | 2016-08-10 | 青岛海信传媒网络技术有限公司 | 一种应用程序的数据保护方法和装置 |
CN107341392B (zh) * | 2016-04-29 | 2019-12-06 | 腾讯科技(深圳)有限公司 | Android系统中的文件脱壳方法及装置 |
CN106022098A (zh) * | 2016-05-10 | 2016-10-12 | 青岛海信传媒网络技术有限公司 | 一种应用程序的签名验证方法和装置 |
CN106022130B (zh) * | 2016-05-20 | 2019-03-22 | 中国科学院信息工程研究所 | 加固应用程序的脱壳方法及装置 |
CN107766096A (zh) * | 2016-08-19 | 2018-03-06 | 阿里巴巴集团控股有限公司 | 应用程序安装包的生成方法、应用程序的运行方法及装置 |
CN107784204B (zh) * | 2016-08-31 | 2021-10-22 | 百度在线网络技术(北京)有限公司 | 应用脱壳方法和装置 |
CN106778088A (zh) * | 2016-11-28 | 2017-05-31 | 四川长虹电器股份有限公司 | 基于Hook技术的动态加载方法 |
CN107070967A (zh) * | 2016-12-23 | 2017-08-18 | 沈阳通用软件有限公司 | 一种通用的终端系统加固方法 |
CN108256324A (zh) * | 2016-12-29 | 2018-07-06 | 武汉安天信息技术有限责任公司 | 一种针对加固apk样本的检测方法及系统 |
CN108573149A (zh) * | 2017-03-10 | 2018-09-25 | 武汉安天信息技术有限责任公司 | 一种样本检测方法及装置 |
CN107066886A (zh) * | 2017-04-13 | 2017-08-18 | 深圳海云安网络安全技术有限公司 | 一种Android加固脱壳的检测方法 |
CN107908964B (zh) * | 2017-10-17 | 2021-06-08 | 珠海金山网络游戏科技有限公司 | 一种针对Android平台Unity3D游戏中加壳文件的安全检测方法及装置 |
CN110442327B (zh) * | 2018-05-03 | 2023-06-23 | 阿里巴巴集团控股有限公司 | 一种应用程序构建方法、装置、服务器 |
CN109522719A (zh) * | 2018-11-29 | 2019-03-26 | 北京梆梆安全科技有限公司 | 应用安装包的加固检测方法、装置及移动终端 |
CN111459822B (zh) * | 2020-04-01 | 2023-10-03 | 抖音视界有限公司 | 系统组件数据的提取方法、装置、设备及可读介质 |
CN112527672B (zh) * | 2020-12-21 | 2021-10-22 | 北京深思数盾科技股份有限公司 | 一种针对加壳工具的检测方法及设备 |
CN112540870B (zh) * | 2020-12-28 | 2021-08-24 | 北京深思数盾科技股份有限公司 | 内存校验的验证方法及电子设备 |
CN112883374B (zh) * | 2021-02-02 | 2022-07-01 | 电子科技大学 | 一种基于ART环境下的Android平台应用程序通用脱壳方法及系统 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103886230A (zh) * | 2014-02-24 | 2014-06-25 | 四川长虹电器股份有限公司 | android系统的软件版权保护方法及其系统 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20060094640A (ko) * | 2005-02-25 | 2006-08-30 | 엘지전자 주식회사 | 디코딩 에러 처리 장치 및 방법 |
-
2015
- 2015-08-25 CN CN201510526462.1A patent/CN105068932B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103886230A (zh) * | 2014-02-24 | 2014-06-25 | 四川长虹电器股份有限公司 | android系统的软件版权保护方法及其系统 |
Non-Patent Citations (1)
Title |
---|
PE程序加壳中的反脱壳技术研究;张中华等;《北京工业职业技术学院学报》;20080731;第3卷(第7期);全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN105068932A (zh) | 2015-11-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105068932B (zh) | 一种Android应用程序加壳的检测方法 | |
Wei et al. | Jn-saf: Precise and efficient ndk/jni-aware inter-language static analysis framework for security vetting of android applications with native code | |
Sun et al. | Taintart: A practical multi-level information-flow tracking system for android runtime | |
Bell et al. | Phosphor: Illuminating dynamic data flow in commodity jvms | |
Dinh et al. | Favocado: Fuzzing the Binding Code of JavaScript Engines Using Semantically Correct Test Cases. | |
Zhauniarovich et al. | Stadyna: Addressing the problem of dynamic code updates in the security analysis of android applications | |
Vidas et al. | Curbing android permission creep | |
US8683462B2 (en) | Handling calls to native code in a managed code environment | |
WO2017049800A1 (zh) | 检测应用漏洞代码的方法和装置 | |
US9372991B2 (en) | Detecting malicious computer code in an executing program module | |
Shahriar et al. | Testing of memory leak in android applications | |
CN105608391B (zh) | 多elf文件保护方法及系统 | |
CN109255235B (zh) | 基于用户态沙箱的移动应用第三方库隔离方法 | |
WO2020165447A1 (en) | Securing virtual-machine software applications | |
Armando et al. | Enabling BYOD through secure meta-market | |
Ahmad et al. | StaDART: addressing the problem of dynamic code updates in the security analysis of android applications | |
CN108647061A (zh) | 系统隐藏方法的调用方法、装置和计算设备 | |
Shim et al. | Static and dynamic analysis of Android malware and goodware written with unity framework | |
CN110597496B (zh) | 应用程序的字节码文件获取方法及装置 | |
CN111381816A (zh) | 应用程序的获取方法、装置、设备及存储介质 | |
Arzt et al. | Towards cross-platform cross-language analysis with soot | |
CN107066886A (zh) | 一种Android加固脱壳的检测方法 | |
Stirparo et al. | In-memory credentials robbery on android phones | |
KR101557455B1 (ko) | 응용 프로그램 코드 분석 장치 및 그것을 이용한 코드 분석 방법 | |
Tiwari et al. | Malware detection in android application by rigorous analysis of decompiled source code |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |