CN105184118B - 一种基于代码碎片化的Android应用程序加壳保护方法及装置 - Google Patents

一种基于代码碎片化的Android应用程序加壳保护方法及装置 Download PDF

Info

Publication number
CN105184118B
CN105184118B CN201510548193.9A CN201510548193A CN105184118B CN 105184118 B CN105184118 B CN 105184118B CN 201510548193 A CN201510548193 A CN 201510548193A CN 105184118 B CN105184118 B CN 105184118B
Authority
CN
China
Prior art keywords
file
code
application program
executable file
code piece
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.)
Expired - Fee Related
Application number
CN201510548193.9A
Other languages
English (en)
Other versions
CN105184118A (zh
Inventor
樊如霞
汤战勇
张洁
杨蕾
陈晓江
房鼎益
龚晓庆
刘方圆
李政桥
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Northwest University
Original Assignee
Northwest University
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Northwest University filed Critical Northwest University
Priority to CN201510548193.9A priority Critical patent/CN105184118B/zh
Publication of CN105184118A publication Critical patent/CN105184118A/zh
Application granted granted Critical
Publication of CN105184118B publication Critical patent/CN105184118B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • G06F21/125Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107File encryption

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)

Abstract

本发明公开了一种基于代码碎片化的Android应用程序加壳保护方法及装置,该方法首先从待保护的应用程序中提取可执行文件、共享库文件、资源及配置信息等,然后对可执行文件进行代码分片,分别加密,导入到新建的应用程序包中,添加提取的配置信息;继而对加密后代码片解密并分配独立的内存空间,对解密的代码片修复重组为可执行文件,进行运行环境的准备并重构安装包。本发明方法保护强度高,被保护应用程序的可执行文件在其整个生命周期中,始终以碎片化形式存在于进程内存中,大大降低了完整的可执行文件被攻击者窃取到的可能性,也就极大地增加了应用程序被逆向、破解、二次打包等的难度;可以平衡保护强度和性能开销。

Description

一种基于代码碎片化的Android应用程序加壳保护方法及 装置
技术领域
本发明属于计算机软件安全领域,具体涉及一种基于代码碎片化的Android应用程序加壳保护方法。
背景技术
近年来,随着Android智能设备的流行和普及,市面上出现了各种各样的Android应用程序以满足用户的需要。然而,由于该平台自身的开放性、应用市场的低门槛以及其应用程序自身的结构特性,Android应用程序所面临的安全问题日益增加,应用程序被破解、逆向、盗版、二次打包等问题屡见不鲜,其中二次打包的问题尤为严重。研究表明,大部分的恶意应用都是通过将合法的应用进行二次打包的而产生的。
为了解决Android应用程序所面临的这些问题,不少研究者提出了各种各样的应对措施,包括:①二次打包及恶意应用检测技术,目前很多二次打包检测都是基于应用程序相似度来进行的,包括通过模糊哈希技术,生成功能视图关系图、程序依赖关系图,嵌入水印等方法来检测二次打包应用。DroidRanger通过结合基于权限的行为指纹以及基于启发式的过滤框架来检测恶意应用。Drebin通过结合静态分析和机器学习的技术在智能设备上直接检测恶意应用,提供了一种轻量级的恶意应用检测方法。虽然这些检测技术大都能够有效地检测出二次打包应用或恶意应用,但是检测技术作为一种事后响应措施,不能够第一时间为应用提供主动的防护。②代码混淆技术,Google和一些其他商家提出了Proguard和Dexguard的混淆方法。但是,混淆只能够在一定程度上增加逆向攻击、破解的难度,不能够有效地阻止有经验的攻击者通过人工分析的方式达到他的目的。③加壳保护技术,壳作为一种有效的软件保护技术,近几年来,也被用于Android应用程序的保护,如梆梆加固,360加固保等都是目前国内Android加壳系统的典型代表。但是,同早期的x86平台上的加壳系统一样,目前的Android加壳系统也都是将应用程序的可执行文件以完整的形式进行加壳的,导致了易被从内存中窃取的威胁,一旦窃取到完整的可执行文件,攻击者就可以继续执行他所希望的任何攻击。
发明内容
针对上述现有应用程序保护技术存在的缺陷和不足,本发明的目的在于,提供一种新的基于代码碎片化的可执行文件加壳保护方法。该方法根据将Android应用程序的可执行文件以完整形式进行加壳所导致的易被从内存中窃取的威胁的特点,提出了基于代码碎片化的加壳保护方法来增加攻击难度与成本,保护强度高,普遍性好。
为了实现上述目标,本发明采取如下的技术解决方案:
一种基于代码碎片化的Android应用程序加壳保护方法,包括以下步骤:
步骤1,从待保护的Android应用程序中提取可执行文件;
步骤2,从待保护的Android应用程序中提取共享库文件、资源文件以及配置信息;
步骤3,根据步骤1提取出的可执行文件的结构,对可执行文件进行代码分片,然后将各代码片分别进行加密;
步骤4,为待保护的应用程序建立新的应用程序包,作为最终保护后应用的程序包;将加密后的各代码片以及步骤2中提取的共享库文件、资源文件导入到该新的应用程序包中,并在其配置文件中添加提取的配置信息;
步骤5,对加密后的各代码片进行解密并分别映射到相互独立的内存空间中;
步骤6,对解密映射到内存区域中的各代码片进行修复,使这些代码片重组为可执行文件;
步骤7,对修复后的可执行文件进行运行环境的准备;
步骤8,重构Android应用程序安装包。
进一步地,所述的步骤3的具体内容包括:
步骤3.1,根据待保护可执行文件的结构,确定代码分片方案;
步骤3.2,确定要分离的各部分代码片的文件偏移;
步骤3.3,将各部分的代码片内容分别读取到独立的文件中;
步骤3.4,依据低性能消耗原则,使用对称加密算法对各代码片内容进行加密。
进一步地,所述的步骤4的具体内容包括:
步骤4.1,为待保护的应用程序建立新的应用程序包,将加密后的各代码段拷贝到新的应用程序包中的assets目录下;若应用程序中包含本地库,则将库文件拷贝到新的应用程序包中的libs/armeabi目录下;
步骤4.2,将步骤2中提取的资源文件合并至新的应用程序包中;
步骤4.3,将步骤2提取出的配置信息,包括待保护应用程序的Application类名、各组件的配置信息、权限声明在保护后应用程序的配置文件中进行添加,其中,Application类名以Meta-data的形式进行保存;各组件的配置信息以及权限声明作为保护后应用的组件以及权限直接在保护后应用的配置文件中进行配置和声明。
进一步地,所述的步骤5的具体过程包括:
步骤5.1,根据加密后各代码片对应的文件大小确定出各代码片所需的空间大小;
步骤5.2,为各代码片分配内存空间;
步骤5.3,解密各代码片,并将解密后的数据分别直接映射到所述的内存空间中。
进一步地,所述的步骤6的具体过程包括:
步骤6.1,根据可执行文件的文件格式,确定可执行文件中有哪些部分记录了偏移值,这些偏移值就是需要修复的内容;
步骤6.2,根据每一个偏移值所指的结构所在的代码片确定该偏移值的增量;
步骤6.3,为每一处所记录的偏移值增加对应的增量,并回填到相应位置。
一种实现如上述方法的装置,包括依次连接的可执行文件提取模块、信息提取模块、代码分片加密模块、应用程序包建立模块、代码片解密映射模块、代码片修复模块、环境准备模块和重构程序模块,其中各模块分别实现前述步骤1至步骤8中所述的内容。
本发明与现有技术相比,其优点如下:
1.保护强度高,被保护应用程序的可执行文件在其整个生命周期中,始终以碎片化形式存在于进程内存中,大大降低了完整的可执行文件被攻击者窃取到的可能性,也就极大地增加了应用程序被逆向、破解、二次打包等的难度;
2.考虑到移动设备自身的资源限制以及对性能的高要求,本方案提出的代码碎片化加壳的方法不涉及到动态加壳以及解壳的技术,但是达到了和x86平台上的动态加解壳技术基本相同的保护效果;
3.通过分片多少的动态调节可以平衡保护强度和性能开销。
附图说明
图1是本发明方法的整体流程图;
图2是可执行文件的文件组成结构的一种示例;
图3是一个应用程序经过本发明保护前后的包结构对比图;
图4是各代码片的解密及映射过程;
图5是本发明装置的结构连接示意图;
具体实施方式
如图1所示,本发明的基于代码碎片化的Android应用程序加壳保护方法,包括以下步骤:
步骤1,从待保护的Android应用程序中提取可执行文件;
Android应用程序是一个ZIP格式的压缩包,对于一个待保护的Android应用程序,首先需要将其进行解压缩,然后获取到其中的可执行文件。本发明中,应用程序的可执行文件指的是运行在Android Dalvik虚拟机上的可执行文件,即dex文件。
步骤2,从待保护的Android应用程序中提取共享库文件、资源文件以及配置信息;具体步骤包括:
步骤2.1,从解压缩后的Android应用程序包中提取出所有的共享库文件;
步骤2.2,资源文件包括应用程序的图片文件、布局文件等,布局文件是经过编译后打包到应用程序包中的,因此,首先需要利用反编译工具Apktool将应用程序进行反编译,然后再从其中提取这些资源文件;
步骤2.3,本发明中的应用程序配置信息指的是Manifest文件中的配置信息,同样的,从反编译后的应用程序包中获取到Manifest文件,提取出Application类的类名(若该应用程序有用户自定义的Application类)、各组件(包括Activity、Service、Broadcastreceiver、Content Provider)的声明信息、应用程序的权限声明列表。
步骤3,根据步骤1提取出的可执行文件的结构,对可执行文件进行代码分片,然后将各代码片分别进行加密;
步骤3.1,分析待保护可执行文件的文件结构,确定出分片方案,即根据可执行文件的不同构成部分,将其分为不同的代码片段。如图2给出的一种示例中,将其中的DexHeader、String Table、Type Table、Proto Table、Field Table、Method Table、Class DefTable、Data Section这八个部分分离开来;
步骤3.2,确定要分离的各部分代码片的文件偏移,过程为:解析Dex header结构,读取出后面7个部分的文件偏移值,记为String_Off、Type_Off、Proto_Off、Field_Off、Method_Off、Class_Off、Data_Off,则Dex Header部分的内容就是该文件中偏移值0到String_Off之间的部分,String Table部分的内容就是该文件中偏移值String_Off到Type_Off之间的部分,Type Table部分的内容就是该文件中偏移值Type_Off到Proto_Off之间的部分,Proto Table部分的内容就是该文件中偏移值Proto_Off到Field_Off之间的部分,Field Table部分的内容就是该文件中偏移值Field_Off到Method_Off之间的部分,Method Table部分的内容就是该文件中偏移值Method_Off到Class_Off之间的部分,ClassDef Table部分的内容就是该文件中偏移值Class_Off到Data_Off之间的部分,DataSection部分的内容就是该文件中偏移值Data_Off到文件尾之间的部分;
步骤3.3,将各部分的代码片内容分别读取到独立的文件中;如本示例中,将各个部分的内容分别读取到8个独立文件中,记为Header_File、String_File、Type_File、Proto_File、Field_File、Method_File、Class_File、Data_File;
步骤3.4,依据低性能消耗原则,使用对称加密算法对各代码片内容进行加密。在本示例中,设定8个不同的秘钥,使用对称加密算法AES加密算法分别对以上8个文件的内容进行加密,输出加密后的文件,记为Header_File_enc、String_File_enc、Type_File_enc、Proto_File_enc、Field_File_enc、Method_File_enc、Class_File_enc、Data_File_enc。
步骤4,为待保护的应用程序建立新的应用程序包,作为最终保护后应用的程序包;将加密后的各代码片以及步骤2中提取的共享库文件、资源文件导入到该新的应用程序包中,并在其配置文件中添加提取的配置信息;具体过程如下:
一个Android应用程序在经过本发明保护前后,其包结构组成变化如图3所示。经过本发明保护后,其原始dex文件会以加密、碎片化的形式存在,该dex的执行是靠一个外壳dex文件来引导的,为保证该应用在保护过后的功能完整性及一致性,共享库文件、资源文件需要完整地存在于保护后的应用程序包中,而Manifest文件中则需要包含外壳dex以及原始dex的所有配置信息:
步骤4.1,为待保护的应用程序建立新的应用程序包:新建一个Android工程,记为protected,作为保护后的应用程序;将加密后的各代码段拷贝到新的应用程序包中的assets目录下;
若应用程序中包含本地库,则将提取到的所有的库文件直接作为保护后应用的库文件处理,即将其置于protected的libs/armeabi目录下;
步骤4.2,将步骤2中提取的资源文件,如各种布局文件、图片文件等合并至新的应用程序包中;
步骤4.3,将步骤2提取出的原始应用的配置信息,包括Application类名、各组件的声明信息、权限声明在保护后应用程序的配置文件中进行添加;其中,Application类名以Meta-data的形式进行保存;各组件的配置信息以及权限声明作为保护后应用的组件以及权限直接在保护后应用的配置文件中进行配置和声明。
对于Application的声明,由于该类在Android应用程序中的特殊地位——应用入口,不能直接作为protected的Application类进行配置,而需要对其进行后续的特殊处理,在此,只需要将其类名保存起来即可,因此,以Meta-data的形式在Manifest文件中进行保存;各组件可作为protected的组件,直接在Manifest文件中进行声明,因此,只需要将提取出的各声明信息按照组件声明格式拷贝到protected的Manifest文件中即可;同样的,权限声明也可直接作为protected的权限声明信息,以相同方式拷贝即可。
步骤5,对加密后的各代码片进行解密并分别映射到相互独立的内存空间中,具体为:
步骤5.1,根据加密后各代码片对应的文件大小确定出各代码片所需的空间大小,本例中分别记为Header_Size、String_Size、Type_Size、Proto_Size、Field_Size、Method_Size、Class_Size、Data_Size;
步骤5.2,根据各代码片大小分别为其分配相应的内存空间,所分配的每一个内存空间都是一个独立的Virtual Memory Area(VMA),记录每一个代码片所在VMA的首地址,记为Header_Off_vma,String_Off_vma、Type_Off_vma、Proto_Off_vma、Field_Off_vma、Method_Off_vma、Class_Off_vma、Data_Off_vma;
步骤5.3,解密各代码片,并将解密后的数据分别直接映射到所述的内存空间VMA中。
步骤6,对解密映射到内存区域中的各代码片进行修复,使这些代码片重组为可执行文件;内存中的可执行文件目前是以碎片化形式存在的,因此要进行修复和重组过程:
步骤6.1,分析可执行文件的文件格式,确定可执行文件中有哪些部分记录了偏移值,确定每一处记录偏移值的位置,这些偏移值就是需要修复的内容,主要包括:①Dexheader中记录的String Table、Type Table、Proto Table、Field Table、Method Table、Class Def Table、Data Section、Map Section的偏移;②Map Section中所记录的各MapItem的偏移值,包括StringIdItem、ProtoIdItem、ClassDefItem、AnnotationSetItem、ClassDataItem、AnnotationDirectoryItem;③进一步地,在ClassDefItem中还记载了interface、annotation、classData、StaticValues四个结构的偏移,也需要进行修复;④ClassDataItem中所记录的directMethods和virtualMethods中的偏移值也需要修复;⑤AnnotationDirectoryItem中记录了每一个FleidAnnotationItem、MethodAnnotationItem、ParameterAnnotationItem的偏移,也需要修复;
步骤6.2,根据每一个偏移值所指的结构所在的代码片确定该偏移值的增量,具体方法为:
步骤6.21,根据各代码片所在内存空间中的地址,计算出除Dex Header之外的各个部分距Dex Header所在内存区的首地址(即Header_Off_vma)的偏移值,分别记为off1,off2,off3,off4,off5,off6,off7;
步骤6.22,计算出所述在内存中的除Dex Header之外的各部分的文件偏移与未经分片时文件偏移的差值,计算方法如下:
△off1=off1-String_Off,△off2=off2-Type_Off,
off3=off3-Proto_Off,△off4=off4-Field_Off,
off5=off5-Method_Off,△off6=off6-Class_Off,
off7=off7-Data_Off;
步骤6.23,读出待修复的偏移值,记为off,比较off与0、String_Off、Type_Off、Proto_Off、Field_Off、Method_Off、Class_Off、Data_Off的大小关系:①若0≦off<String_Off,则该偏移值所指的结构在Dex Header对应的代码片中,其偏移值增量为0;②若String_Off≦off<Type_Off,则该偏移值所指的结构在String Table对应的代码片中,其偏移值增量为△off1;③若Type_Off≦off<Proto_Off,则该偏移值所指的结构在TypeTable对应的代码片中,其偏移值增量为△off2;④若Proto_Off≦off<Field_Off,则该偏移值所指的结构在Proto Table对应的代码片中,其偏移值增量为△off3;⑤若Field_Off≦off<Method_Off,则该偏移值所指的结构在Field Table对应的代码片中,其偏移值增量为△off4;⑥若Method_Off≦off<Class_Off,则该偏移值所指的结构在Method Table对应的代码片中,其偏移值增量为△off5;⑦若Class_Off≦off<Data_Off,则该偏移值所指的结构在Class Def Table对应的代码片中,其偏移值增量为△off6;⑧若off≧Data_Off,则该偏移值所指的结构在Data Section对应的代码片中,其偏移值增量为△off7;
步骤6.3,为每一处所记录的偏移值增加对应的增量,并回填到相应位置。
步骤7,对修复后的可执行文件进行运行环境的准备;主要包括两个方面的工作:
步骤7.1,可执行文件的加载,具体操作如下:
步骤7.11,定义用于加载内存中以碎片化形式存在的可执行文件的dexClassLoader,记为MyDexClassLoader;
步骤7.12,在protected运行时,将所述步骤4中已导入到其应用程序包中的本地库文件拷贝到其内部存储,以便MyDexClassLoader进行访问;
步骤7.13,通过MyDexClassLoader加载内存中以碎片化形式存在的可执行文件。
步骤7.2,上下文环境的切换,具体操作如下:
步骤7.21,通过反射调用将当前外壳dex文件执行过程中,该应用默认的dexClassLoader替换为MyDexClassLoader;
步骤7.22,获取所述步骤4中在Manifest文件中所保存的原始应用程序的Application类名,记为DelegateApplication,加载该类,并生成对象;
步骤7.23,通过反射调用,将API层所保存的所有Application对象都替换为DelegateApplication对象;
步骤7.24,若待保护应用程序中包含Content Provider组件,则遍历API层的Content Provider列表,将每一个Content Provider的mContext都替换为DelegateApplication对象;
步骤7.25,将控制权交给DelegateApplication,即启动DelegateApplication。
步骤8,重构Android应用程序安装包:
将所述步骤5、6的处理作为保护后应用程序中的共享库文件,步骤7的处理作为新的可执行文件,最终生成保护后的应用程序。
本申请提供一种基于代码碎片化的Android应用程序加壳保护系统,经过本系统保护后的应用程序在其整个生命周期中,始终让该应用程序的可执行文件以碎片化的形式存在于内存空间中。在这种情况下,尽管该可执行文件的一些固有特征(如dex头结构中的魔数字)依然不可避免地暴露给了攻击者,但是攻击者很难定位到内存中所有的代码片,退一步说,即使攻击者定位到了每一个代码片的位置,他对于每一个代码片的获取的成本同未经碎片化处理的完整可执行文件的获取成本是一样的,因此,碎片化会让攻击者获取完整可执行文件的攻击成本成倍地增加。其次,假设攻击者已经获取到了所有的代码片,将这些代码片还原成原始完整的可执行文件会需要大量的修复工作,这些修复工作往往很耗时,并且易出错。因此,本方法相对于现有技术,能够提高待保护应用程序的安全性,极大地增加了攻击者获取应用程序完整可执行文件的难度,从而增强了待保护应用程序主动防护能力。
本发明还提供了一种实现如上述方法的装置,如图5所示,包括依次连接的可执行文件提取模块、信息提取模块、代码分片加密模块、应用程序包建立模块、代码片解密映射模块、代码片修复模块、环境准备模块和重构程序模块,其中各模块分别实现前述步骤1至步骤8中所述的内容;这里是指可执行文件提取模块实现步骤1所述的内容,信息提取模块实现步骤2中所述的内容,代码分片加密模块实现步骤3中所述的内容,应用程序包建立模块实现步骤4中所述的内容,代码片解密映射模块实现步骤5中所述的内容,代码片修复模块实现步骤6中所述的内容,环境准备模块实现步骤7中所述的内容,和重构程序模块实现步骤8中所述的内容。
实验部分:
为了测试本方法保护过后的应用程序的性能消耗情况,以下从保护前后应用程序安装包大小、内存消耗多少以及启动时间3个方面来进行实验评估:
实验环境:Android 4.3版本的模拟器,512M的RAM,256M的内置存储器。
实验对象:4个具有代表性的应用程序,这些应用程序包含了不同的Android组件(如表1所示)。
表1 测试用例所包含的各组件列表
实验1:对应用程序安装包大小的影响
表2中第二列列出了各应用程序保护前后包大小的情况。可以看出应用程序包大小最多增加了18KB,这个增加是很小的。包大小的增加主要是由于保护过后的应用程序中会增加一个外壳dex文件(21KB)和一个本地库文件(18KB)。由于这两个文件大小始终保持相同,并且,在应用程序打包时,会进行压缩,就使得他们所占空间更小,因此,应用程序包大小的增加会始终保持在这个较小的水平。
表2 保护前后各应用包大小及内存消耗情况
实验2:对内存消耗的影响
表2中最后一列列出了各应用程序保护前后内存消耗的情况。内存消耗的增加最多是3.767MB,这主要是由两个因素引起的:①外壳dex以及增加的本地库的内存消耗;②在对每一个代码片段进行映射时,为了保持页对齐,会有一些额外的内存消耗。考虑到现有的移动设备大都提供大于2GB的RAM,因此,不到4MB的内存消耗不会对设备的性能造成明显的影响。
实验3:对应用程序启动时间的影响
表3列出了本方法保护前后的各应用程序分别在第一次、第二次、第三次以及第四次启动时所需的启动时长比较。可以看出,对于所评估的四个应用程序,保护后各自在第一次启动时都表现出较明显的时延。但是,在后续的三次启动过程中,保护后的应用与未保护时表现出基本相同的时长。第一次启动的时长增加主要是由于保护过后,应用程序需要一些额外的类以及依赖库,这些类与依赖库都会在应用第一次执行时被加载,只要系统资源充足,它们就一直会存在于进程内存空间中,因此,一般在该应用后续的启动过程中不需要再加载他们,这也就是后序启动过程没有明显时延的原因。再者,由于本实验是在Android模拟器上进行的,模拟器的计算能力要比真机低很多,而保护过后的应用程序实际上最终都是在真机上运行的,其本身启动速度就会快很多。因此,即使是在第一次启动时,保护过后得应用程序启动时延也不会很明显。
表3 保护前后各应用在四次启动过程中的时长比较

Claims (5)

1.一种基于代码碎片化的Android应用程序加壳保护方法,其特征在于,包括以下步骤:
步骤1,从待保护的Android应用程序中提取可执行文件;
步骤2,从待保护的Android应用程序中提取共享库文件、资源文件以及配置信息;
步骤3,根据步骤1提取出的可执行文件的结构,对可执行文件进行代码分片,然后将各代码片分别进行加密;
步骤3.1,根据待保护可执行文件的结构,确定代码分片方案;
步骤3.2,确定要分离的各部分代码片的文件偏移;
步骤3.3,将各部分的代码片内容分别读取到独立的文件中;
步骤3.4,依据低性能消耗原则,使用对称加密算法对各代码片内容进行加密;
步骤4,为待保护的应用程序建立新的应用程序包,作为最终保护后应用的程序包;将加密后的各代码片以及步骤2中提取的共享库文件、资源文件导入到该新的应用程序包中,并在其配置文件中添加提取的配置信息;
步骤5,对加密后的各代码片进行解密并分别映射到相互独立的内存空间中;
步骤6,对解密映射到内存区域中的各代码片进行修复,使这些代码片重组为可执行文件;
步骤7,对修复后的可执行文件进行运行环境的准备;
步骤8,重构Android应用程序安装包。
2.如权利要求1所述的基于代码碎片化的Android应用程序加壳保护方法,其特征在于,所述的步骤4的具体内容包括:
步骤4.1,为待保护的应用程序建立新的应用程序包,将加密后的各代码段拷贝到新的应用程序包中的assets目录下;若应用程序中包含本地库,则将库文件拷贝到新的应用程序包中的libs/armeabi目录下;
步骤4.2,将步骤2中提取的资源文件合并至新的应用程序包中;
步骤4.3,将步骤2提取出的配置信息,包括待保护应用程序的Application类名、各组件的配置信息、权限声明在保护后应用程序的配置文件中进行添加,其中,Application类名以Meta-data的形式进行保存;各组件的配置信息以及权限声明作为保护后应用的组件以及权限直接在保护后应用的配置文件中进行配置和声明。
3.如权利要求1所述的基于代码碎片化的Android应用程序加壳保护方法,其特征在于,所述的步骤5的具体过程包括:
步骤5.1,根据加密后各代码片对应的文件大小确定出各代码片所需的空间大小;
步骤5.2,为各代码片分配内存空间;
步骤5.3,解密各代码片,并将解密后的数据分别直接映射到所述的内存空间中。
4.如权利要求1所述的基于代码碎片化的Android应用程序加壳保护方法,其特征在于,所述的步骤6的具体过程包括:
步骤6.1,根据可执行文件的文件格式,确定可执行文件中有哪些部分记录了偏移值,这些偏移值就是需要修复的内容;
步骤6.2,根据每一个偏移值所指的结构所在的代码片确定该偏移值的增量;
步骤6.3,为每一处所记录的偏移值增加对应的增量,并回填到相应位置。
5.一种用于实现如权利要求1所述方法的装置,其特征在于,包括依次连接的可执行文件提取模块、信息提取模块、代码分片加密模块、应用程序包建立模块、代码片解密映射模块、代码片修复模块、环境准备模块和重构程序模块,其中各模块分别实现权利要求1中步骤1至步骤8中所述的内容。
CN201510548193.9A 2015-08-31 2015-08-31 一种基于代码碎片化的Android应用程序加壳保护方法及装置 Expired - Fee Related CN105184118B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510548193.9A CN105184118B (zh) 2015-08-31 2015-08-31 一种基于代码碎片化的Android应用程序加壳保护方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510548193.9A CN105184118B (zh) 2015-08-31 2015-08-31 一种基于代码碎片化的Android应用程序加壳保护方法及装置

Publications (2)

Publication Number Publication Date
CN105184118A CN105184118A (zh) 2015-12-23
CN105184118B true CN105184118B (zh) 2018-02-23

Family

ID=54906192

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510548193.9A Expired - Fee Related CN105184118B (zh) 2015-08-31 2015-08-31 一种基于代码碎片化的Android应用程序加壳保护方法及装置

Country Status (1)

Country Link
CN (1) CN105184118B (zh)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105700936A (zh) * 2016-01-14 2016-06-22 福州靠谱网络有限公司 一种安卓模拟器应用程序运行方法和装置
CN106020725B (zh) * 2016-05-20 2019-07-12 努比亚技术有限公司 应用文件处理装置及方法
CN106169052B (zh) * 2016-07-19 2018-04-06 北京海泰方圆科技股份有限公司 应用程序的处理方法、装置及移动终端
CN106598584B (zh) * 2016-12-08 2020-02-11 广州华多网络科技有限公司 一种处理资源文件的方法、装置和系统
CN108363747A (zh) * 2018-01-26 2018-08-03 厦门亿联网络技术股份有限公司 Assets文件批量拷贝方法
CN108932436B (zh) * 2018-07-06 2020-07-28 四川长虹电器股份有限公司 一种基于安卓系统的app说明书的软件安全加固方法
CN110147329B (zh) * 2019-05-24 2022-06-14 武汉瓯越网视有限公司 一种动态检测模拟器的方法、装置及终端
CN111143790B (zh) * 2019-12-13 2022-07-12 广州方硅信息技术有限公司 代码混淆方法、装置、设备及存储介质
CN114077728B (zh) * 2020-08-12 2023-05-02 电子科技大学 基于静态检测的Android应用生物认证安全性方法
CN112131193B (zh) * 2020-09-17 2023-04-07 上海上讯信息技术股份有限公司 一种应用程序压缩的方法及设备
CN112486922B (zh) * 2020-12-02 2022-12-06 中国人民解放军战略支援部队信息工程大学 基于结构链逆向的内存碎片文件重建方法及系统
CN113849245B (zh) * 2021-09-23 2023-09-12 武汉深之度科技有限公司 一种应用程序运行方法、计算设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102118512A (zh) * 2011-03-28 2011-07-06 阮晓迅 一种手机应用程序防破解方法及系统
CN104021321A (zh) * 2014-06-17 2014-09-03 北京奇虎科技有限公司 软件安装包的加固保护方法和装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104662547A (zh) * 2012-10-19 2015-05-27 迈克菲股份有限公司 移动应用管理

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102118512A (zh) * 2011-03-28 2011-07-06 阮晓迅 一种手机应用程序防破解方法及系统
CN104021321A (zh) * 2014-06-17 2014-09-03 北京奇虎科技有限公司 软件安装包的加固保护方法和装置

Also Published As

Publication number Publication date
CN105184118A (zh) 2015-12-23

Similar Documents

Publication Publication Date Title
CN105184118B (zh) 一种基于代码碎片化的Android应用程序加壳保护方法及装置
Lee et al. Occlumency: Privacy-preserving remote deep-learning inference using SGX
Chen et al. DeepAttest: An end-to-end attestation framework for deep neural networks
US8646050B2 (en) System and method for supporting JIT in a secure system with randomly allocated memory ranges
US20120317421A1 (en) Fingerprinting Executable Code
CN107679393B (zh) 基于可信执行环境的Android完整性验证方法和装置
KR101503785B1 (ko) 동적 라이브러리를 보호하는 방법 및 장치
US7962952B2 (en) Information processing apparatus that executes program and program control method for executing program
Liu et al. SecDeep: Secure and performant on-device deep learning inference framework for mobile and IoT devices
CN102467585A (zh) 一种dwg文档的电子签章、验证及撤销签名方法
US8775826B2 (en) Counteracting memory tracing on computing systems by code obfuscation
CN107273723A (zh) 一种基于so文件加壳的Android平台应用软件保护方法
Yang et al. Deepmal: maliciousness-preserving adversarial instruction learning against static malware detection
Vidas The acquisition and analysis of random access memory
CN114238874A (zh) 数字签章验证方法、装置、计算机设备和存储介质
CN104639313B (zh) 一种密码算法的检测方法
CN107122663A (zh) 一种注入攻击检测方法及装置
Lyu et al. An Efficient and Packing‐Resilient Two‐Phase Android Cloned Application Detection Approach
Rathor et al. Quadruple phase watermarking during high level synthesis for securing reusable hardware intellectual property cores
Lanet et al. Memory forensics of a java card dump
CN113569277B (zh) 安全文件数据检查的方法、装置和电子设备
Nechta Robustness analysis for dynamic watermarks
Chen et al. Intellectual Property Protection of Deep Learning Systems via Hardware/Software Co-design
Tian et al. Code fusion information-hiding algorithm based on PE file function migration
Gutierrez et al. Reactive redundancy for data destruction protection (R2D2)

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
CB03 Change of inventor or designer information
CB03 Change of inventor or designer information

Inventor after: Tang Zhanyong

Inventor after: Fan Ruxia

Inventor after: Zhang Jie

Inventor after: Yang Lei

Inventor after: Chen Xiaojiang

Inventor after: Fang Dingyi

Inventor after: Gong Xiaoqing

Inventor after: Liu Fangyuan

Inventor after: Li Zhengqiao

Inventor before: Fan Ruxia

Inventor before: Tang Zhanyong

Inventor before: Zhang Jie

Inventor before: Yang Lei

Inventor before: Chen Xiaojiang

Inventor before: Fang Dingyi

Inventor before: Gong Xiaoqing

Inventor before: Liu Fangyuan

Inventor before: Li Zhengqiao

CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20180223

Termination date: 20200831