复和重组过程：
[0066] 步骤6. 1，分析可执行文件的文件格式，确定可执行文件中有哪些部分记录了偏 移值，确定每一处记录偏移值的位置，这些偏移值就是需要修复的内容，主要包括：①Dex header 中记录的 String Table、Type Table、Proto Table、Field Table、Method Table、 Class Def Table、Data SectioruMap Section 的偏移；② Map Section 中所记录的各 MapItem 的偏移值，包括 Stringldltem、Protoldltem、ClassDefltem、AnnotationSetltem、 ClassDataltem、AnnotationDirectoryItem ;③进一步地，在 ClassDefItem 中还记载 了 interface、annotation、classData、StaticValues 四个结构的偏移，也需要进行 修复；④ClassDataItem中所记录的directMethods和virtualMethods中的偏移值 也需要修复；⑤ AnnotationDirectoryItem 中记录了每一个 FleidAnnotationltem、 MethodAnnotationltem、ParameterAnnotationItem 的偏移，也需要修复；
[0067] 步骤6. 2,根据每一个偏移值所指的结构所在的代码片确定该偏移值的增量，具体 方法为：
[0068] 步骤6. 21，根据各代码片所在内存空间中的地址，计算出除Dex Header之外的 各个部分距Dex Header所在内存区的首地址（即Header_0ff_vma)的偏移值，分别记为 off!，off2, off3, off4, off5, off6, offT ;
[0069] 步骤6. 22,计算出所述在内存中的除Dex Header之外的各部分的文件偏移与未 经分片时文件偏移的差值，计算方法如下：
[0070] Λ offl = ofTl-String_0fT，Λ off2 = ofT2-Type_0ff，
[0071] off3 = off3-Proto_0ff, Δ off4 = off4-Field_0ff,
[0072] off5 = off5-Method_0ff, Δ off6 = off6-Class_0ff,
[0073] off7 = off7-Data_0ff ；
[0074] 步骤6. 23,读出待修复的偏移值，记为off，比较off与0、String_0ff、Type_ Off、Proto_0ff、Field_0ff、Method_0ff、Class_0ff、Data_0ff 的大小关系：①若 O f ofT〈String_OfT，则该偏移值所指的结构在Dex Header对应的代码片中，其偏移值增 量为〇 ;②若String_Off f off〈Type_Off，则该偏移值所指的结构在String Table对应的 代码片中，其偏移值增量为八(^€1;@若了7?6_(^€5(^代?仰切_(^6则该偏移值所指的结 构在了7口6 1&1316对应的代码片中，其偏移值增量为厶(^€2;@若？1〇切_(^€写（^代？丨61(1_ Off，则该偏移值所指的结构在Proto Table对应的代码片中，其偏移值增量为Λ ofT3 ;⑤ 若Field_Off兰off〈Method_Off，则该偏移值所指的结构在Field Table对应的代码片 中，其偏移值增量为A〇ff4 ;⑥若Method_0ff兰off〈Class_Off，则该偏移值所指的结构在 1〇七11〇(1131316对应的代码片中，其偏移值增量为厶(^€5;@若(：1388_(^€兰(^代03七3_0打， 则该偏移值所指的结构在Class Def Table对应的代码片中，其偏移值增量为Λ ofT6 ;⑧ 若off 3 Data_0ff，则该偏移值所指的结构在Data Section对应的代码片中，其偏移值增 量为Λ OffT ;
[0075] 步骤6. 3,为每一处所记录的偏移值增加对应的增量，并回填到相应位置。
[0076] 步骤7,对修复后的可执行文件进行运行环境的准备；主要包括两个方面的工作：
[0077] 步骤7. 1，可执行文件的加载，具体操作如下：
[0078] 步骤7. 11，定义用于加载内存中以碎片化形式存在的可执行文件的 dexClassLoader，记为 MyDexClassLoader ;
[0079] 步骤7. 12,在protected运行时，将所述步骤4中已导入到其应用程序包中的本地 库文件拷贝到其内部存储，以便MyDexClassLoader进行访问；
[0080] 步骤7. 13,通过MyDexClassLoader加载内存中以碎片化形式存在的可执行文件。
[0081] 步骤7. 2,上下文环境的切换，具体操作如下：
[0082] 步骤7. 21，通过反射调用将当前外壳dex文件执行过程中，该应用默认的 dexClassLoader 替换为 MyDexClassLoader ;
[0083] 步骤7. 22，获取所述步骤4中在Manifest文件中所保存的原始应用程序的 Application类名，记为DelegateApplication，加载该类，并生成对象；
[0084] 步骤7. 23,通过反射调用，将API层所保存的所有Application对象都替换为 DelegateApplication 对象；
[0085] 步骤7. 24,若待保护应用程序中包含Content Provider组件，则遍历API 层的 Content Provider 列表，将每一个 Content Provider 的 mContext 都替换为 DelegateApplication 对象；
[0086] 步骤 7. 25,将控制权交给 DelegateApplication，即启动 DelegateApplication。
[0087] 步骤8,重构Android应用程序安装包：
[0088] 将所述步骤5、6的处理作为保护后应用程序中的共享库文件，步骤7的处理作为 新的可执行文件，最终生成保护后的应用程序。
[0089] 本申请提供一种基于代码碎片化的Android应用程序加壳保护系统，经过本系统 保护后的应用程序在其整个生命周期中，始终让该应用程序的可执行文件以碎片化的形式 存在于内存空间中。在这种情况下，尽管该可执行文件的一些固有特征（如dex头结构中的 魔数字）依然不可避免地暴露给了攻击者，但是攻击者很难定位到内存中所有的代码片， 退一步说，即使攻击者定位到了每一个代码片的位置，他对于每一个代码片的获取的成本 同未经碎片化处理的完整可执行文件的获取成本是一样的，因此，碎片化会让攻击者获取 完整可执行文件的攻击成本成倍地增加。其次，假设攻击者已经获取到了所有的代码片，将 这些代码片还原成原始完整的可执行文件会需要大量的修复工作，这些修复工作往往很耗 时，并且易出错。因此，本方法相对于现有技术，能够提高待保护应用程序的安全性，极大地 增加了攻击者获取应用程序完整可执行文件的难度，从而增强了待保护应用程序主动防护 能力。
[0090] 本发明还提供了一种实现如上述方法的装置，如图5所示，包括依次连接的可执 行文件提取模块、信息提取模块、代码分片加密模块、应用程序包建立模块、代码片解密映 射模块、代码片修复模块、环境准备模块和重构程序模块，其中各模块分别实现前述步骤1 至步骤8中所述