CN109408073B

CN109408073B - 一种Android非侵入式应用重打包方法

Info

Publication number: CN109408073B
Application number: CN201811118360.6A
Authority: CN
Inventors: 韩心慧; 黎桐辛; 简容; 武新逢
Original assignee: Peking University
Current assignee: Peking University
Priority date: 2018-09-21
Filing date: 2018-09-21
Publication date: 2021-10-08
Anticipated expiration: 2038-09-21
Also published as: CN109408073A

Abstract

本发明公开一种Android非侵入式应用重打包方法。本方法包括：1)通过不修改目标Android应用代码的方式，向目标应用注入外部代码；所述外部代码在目标应用启动时将被执行，用于加载并运行目标应用的原始代码，以及加载Hook框架与重打包插件；所述重打包插件用于利用加载的Hook框架动态修改设定函数的函数实现、函数调用时的参数或函数返回时的结果，实现目标应用行为和逻辑的改变；2)对修改后的目标应用进行重新签名，得到重打包后的Android应用。本发明适用于加壳与非加壳Android应用，对于加壳应用，本发明不要求脱壳，也不需要修复脱壳后的代码，规避了传统方案的缺陷。

Description

一种Android非侵入式应用重打包方法

技术领域

本发明涉及一种Android非侵入式应用重打包方法，尤其涉及一种支持加壳应用的Android非侵入式应用重打包方法，属于计算机应用技术领域。

背景技术

Android应用重打包技术是Android生态中一类常见且重要的安全技术，该技术可以修改已有应用的代码与逻辑，从而生成一个新的应用。该技术既被用于应用破解、广告插入以及恶意代码注入等行为，也被用于漏洞修补、应用分析、应用保护等工作。

Android应用大多以Java代码编写主要逻辑，修改由Java代码生成的dex文件是Android应用重打包技术的核心。主流的应用重打包方法是将dex中的Dalvik字节码反编译为Smali代码，修改Smali代码，然后重新编译生成新的dex文件，最后对应用进行重新签名。除此以外，也可以将dex反编译为Java或Jimple语言，修改后再重新编译dex并签名。

为了对抗反编译和重打包，出现了Android加壳技术。常见的加壳方式是将原有代码拆分加密，在应用运行过程中还原再执行。除此以外，存在壳将部分Dalvik字节码转换为二进制代码，或转换为自定义虚拟机的指令。

为了重打包加壳后的应用，目前的方法是先脱壳，还原原始代码，然后使用传统应用重打包技术，修改并编译生成新的应用。然而，这种方法的局限在于需要正确的脱壳方法，能完整提取原有代码，并能修复脱壳后的代码，保证应用能够正常运行。但是脱壳本身是一项复杂的工作，且脱壳后的代码通常不能直接正常运行，修复代码同样是一项复杂的工作。

发明内容

基于上述内容，本发明提供了一种Android非侵入式应用重打包方法，通过不修改原有应用代码的代码注入方式，向目标应用注入Hook框架，动态修改应用代码行为，实现对应用的重打包。本发明适用于加壳Android应用与非加壳Android应用，具备通用性。对于加壳应用，本发明不要求脱壳，也不需要修复脱壳后的代码，规避了传统方案的缺陷。

为了实现上述目的，本发明采用以下技术方案：

本发明提供了一种Android非侵入式应用重打包方法，包括：

1)利用不修改原有应用代码的方式，向目标应用注入外部代码。Android应用以zip压缩包的形式存在，压缩包内包含Java编译生成的dex(Dalvik可执行文件)和C/C++编译生成的so(共享库)。不修改原有应用代码是指应用内部的dex和so文件可以被移动和重命名，但不会被修改，保持代码内容不发生改变。注入外部代码是指向目标应用的压缩包内放入新的dex或so文件，并且当目标应用运行时，外部代码会被运行，且原有代码正常运行。注入的外部代码目的是加载Hook框架与重打包插件。Hook框架与重打包插件可以作为外部代码的一部分，也可以作为单独的资源文件或网络文件，由外部代码动态加载。但外部代码的内容需要满足一定的条件：1)和原应用的逻辑相关，才能在注入后被应用运行；2)会执行原应用的部分逻辑，恢复应用的上下文环境，让应用可以正常执行。

外部代码在运行过程中，可以通过动态加载的方式，加载更多dex与so文件(Android有相关API可以动态加载dex或so文件；这里的dex或so可以是任意文件，包括Hook框架和重打包插件)。

2)利用Android开发工具，对修改后的目标应用进行重新签名，让插入外部代码的新应用可以通过Android系统的签名有效性验证，得到重打包后的应用。

3)当该新应用运行时，注入的外部代码加载Hook框架(若Hook框架是外部代码的一部分，则外部代码在加载运行时，Hook框架会一并被加载；若Hook框架是单独的文件，则可以通过Android API，如DexClassLoader类和Runtime.load等函数，动态加载Hook框架)。Hook框架可以修改进程空间内的函数，包括Framework API与应用代码内的函数。

4)应用运行过程中，应用或壳可能存在某种保护机制，检测应用是否被修改，导致重打包后的应用在启动后直接退出，无法正常执行。因此，外部代码将利用Java语言的机制或Hook框架的能力，尝试绕过保护机制(绕过保护机制就是让应用或壳代码相信应用并没有被修改)。绕过保护机制的效果与机制的具体实现方式、机制检查的时机、代码注入的方式有关。

5)Hook框架加载成功后，注入的外部代码加载重打包插件。重打包插件利用Hook框架的能力，动态修改部分函数的实现、函数调用时的参数或函数返回时的结果，实现应用行为和逻辑的改变。

进一步，步骤1)可采用任意不修改原有应用代码的注入方式，本发明包含如下四种方式：

1-1)模仿壳的机制。该方式将外部代码作为应用的主代码(classes.dex),将原本的classes.dex移动或重命名。当应用运行时，外部代码将被加载。Android应用中包含AndroidManifest.xml，其中<application android:name＝“string”>标签描述了应用的Application子类，可看作应用的入口。外部代码将包含AndroidManifest.xml中描述的Application子类，因此外部代码在应用启动时将被执行。之后，外部代码加载并运行原始代码，让应用正常执行。

1-2)利用MultiDex机制。Android 5.0及以后，应用安装包根目录下的classes.dex,classex2.dex,classes3.dex等多个dex在应用执行前会被合并编译生成一个oat文件,应用运行过程中加载并运行oat文件。因此，将外部代码作为一个classes(N+1).dex(N为应用安装包根目录下已有classes*.dex数目)，放入应用安装包中。当应用运行时，外部代码将会自动加载。为了让外部代码在加载后能够自动运行，外部代码中实现了Application子类，并继承原AndroidManifest.xml中描述的Application子类。同时，修改AndroidManifest.xml中application标签，将其指向外部代码的Application子类。当应用运行时，外部代码将被加载并运行，同时，由于外部代码中实现的Application子类继承了原Application，因此，原Application将自动执行，原始代码也将正常加载和执行。

1-3)替换so文件。许多Android应用会利用so文件完成某些操作，壳也会利用so完成代码解密还原等操作。可将外部代码作为一个so文件，替换应用内某个so，而将原本的so移动(即改变路径)或重命名。应用运行过程中，将自动加载并运行外部代码的so。之后，外部代码加载并运行被替换的so，维持应用的原有逻辑和流程。

1-4)利用Native Activity机制。Activity是Android应用的界面，从手机桌面启动应用时，会有一个主界面会被打开。AndroidManifest.xml中描述了一个Activity的属性，可以声明一个Activity是Native Activity，并声明实现该Activity的so文件。因此，可将外部代码作为一个so文件，并实现一个Native Activity。修改AndroidManifest.xml，让外部代码实现的Native Activity作为应用的主界面。当应用从桌面启动时，NativeActivity将被启动，外部代码将会被加载并执行。而后，Native Activity再启动原来的主界面，维持应用的原有逻辑和流程。

进一步，步骤3)中的Hook框架可被集成进步骤1)所注入的外部代码中，在应用运行过程中和外部代码一起加载，也可以是作为一个单独文件保存在应用的资源目录或网络中，由注入的外部代码动态加载。

进一步，步骤4)描述的保护机制包括签名验证、文件完整性验证等。签名验证是验证应用的签名是否为原开发者的签名；文件完整性验证是验证应用内文件数目是否正确，每个文件的内容是否被篡改。

进一步，步骤4)中Java语言机制包括反射、接口的动态代理。利用反射，可以通过类名和函数名调用任意Java函数，也可以通过类名和属性名修改类和对象的属性；利用接口的动态代理，可以为某个接口对象实现一个代理对象，代理对象可以访问原始对象的API，同时可以修改请求参数和返回结果。

进一步，步骤5)中重打包插件是根据Hook框架提供的API为基础实现的一段代码，利用Hook框架的能力，修改某些函数的实现、函数调用时的参数或函数返回时的结果，实现对应用行为的动态修改，从而改变应用逻辑或增加新的逻辑。所需修改的函数是由使用该重打包方法的人来定的，Hook框架的能力就是改变函数的实现，或修改函数调用时的参数或函数返回时的结果。一个应用的逻辑是由无数函数与函数间的调用关系决定的。修改函数后，就可以按照使用者的目的，对应用的行为和逻辑进行修改。

与现有技术相比，本发明的积极效果如下：

本发明无需脱壳和修复脱壳后的应用，降低了重打包过程对脱壳的依赖；可以使用Java等高层语言编写重打包插件，无需使用Smali等底层语言修改应用逻辑；支持修改Android Framework API；支持反射、动态加载等操作；支持非加壳应用，也支持各类加壳服务，如内存加密壳、虚拟机壳等。本发明可以用于应用保护、防御策略部署、应用修补等多项工作中。

附图说明

图1为本发明重打包应用的整体流程图；

图2为本发明重打包后应用运行的整体流程图；

图3为本发明模仿壳机制对应用进行重打包后的应用运行流程图；

图4为本发明利用MultiDex机制对应用进行重打包后的应用运行流程图；

图5为本发明利用so文件替换对应用进行重打包后的应用运行流程图；

图6为本发明利用Native Activity机制对应用进行重打包后的应用运行流程图。

具体实施方式

以下参照附图对本发明进行详细说明，但本发明不局限于下面的实施方式

如图1所示为重打包应用的整体流程图。首先，在原有应用的基础上注入外部代码。注入的基本操作包括新增dex或so文件，替换已存在的dex或so文件，并将原dex或so文件移动或重命名；修改AndroidManifest.xml文件以修改应用的某些属性。通过这些基本操作，可以实现发明内容中的模仿壳机制、利用MultiDex机制、替换so文件、利用NativeActivity机制等外部代码注入方式。之后，重新签名修改后的应用，得到可以正常安装的新应用。

如图2所示为重打包后应用运行的整体流程图。首先，根据注入代码方式的不同，应用可能会启动部分原代码。然后，应用将自动加载并运行外部代码。之后，外部代码加载Hook框架。然后，利用Java语言机制与Hook框架的能力，绕过应用的某些保护机制。此后，外部代码可能会运行部分原代码，如运行壳代码让其加载并还原未加壳前的代码。然后，注入的外部代码加载并运行重打包插件，修改某些函数的实现、调用参数以及返回结果。最后，应用正常执行，但执行的是已修改后的代码。

如图3所示为模仿壳机制对应用进行重打包后的应用运行流程图。重打包时，会替换应用的classes.dex，所以应用启动后会自动加载注入的外部代码(classes.dex)。外部代码实现了AndroidManifest.xml指定的Application子类，该子类会被自动初始化，因此外部代码会自动运行。之后，外部代码加载Hook框架，并绕过应用保护机制。此后，外部代码加载原classes.dex(重打包时被重命名了)，并初始化原classes.dex中的Application子类。然后，外部代码加载运行重打包插件，修改应用逻辑。最后，执行修改后的代码。

如图4所示为利用MultiDex机制对应用进行重打包后的应用运行流程图。重打包时，会将外部代码作为classesN+1.dex，加入应用中。因此，在Android 5.0及以后的系统中，应用运行时，classesN+1.dex也会随classes.dex一同加载。重打包时，修改了AndroidManifest.xml,将原本的Application子类Application_old修改为来自外部代码，继承Application_old的Application_new。作为应用的入口，Application_new将自动初始化，外部代码得以自动运行。此后，外部代码加载Hook框架，并绕过应用保护机制。之后，外部代码通过Application_new调用父类函数，就可以实现Application_old的初始化。然后，外部代码加载运行重打包插件，修改应用逻辑。最后，执行修改后的代码。

如图5所示为利用so文件替换对应用进行重打包后的应用运行流程图。重打包时，会用外部代码替换目标so(library.so)。未重打包前的应用正常执行时，会加载并运行library.so。因此，重打包后，应用会加载并运行名为library.so的外部代码。之后，外部代码加载Hook框架，并绕过应用保护机制。然后，外部代码加载原library.so(重打包时被重命名了)。之后，外部代码加载运行重打包插件，修改应用逻辑。最后，执行修改后的代码。

如图6所示为利用Native Activity机制对应用进行重打包后的应用运行流程图。重打包时，修改了AndroidManifest.xml，改变了原有主界面Activity_old的属性，让其不再作为主界面；新增界面Activity_new作为主界面，并声明该Activity为Native Activity，实现该Native Activity逻辑的so为应用新增的外部代码so。当应用从桌面打开时，应用会启动主界面，因此，Activity_new将被启动，外部代码将被加载和运行。之后，外部代码加载Hook框架，绕过应用的保护机制，并加载运行重打包插件，修改应用逻辑。最后，外部代码启动原主界面Activity_old，让修改后的代码得以执行。

尽管为说明目的公开了本发明的具体实施例和附图，其目的在于帮助理解本发明的内容并据以实施，但是本领域的技术人员可以理解：在不脱离本发明及所附的权利要求的精神和范围内，各种替换、变化和修改都是可能的。本发明不应局限于本说明书最佳实施例和附图所公开的内容，本发明要求保护的范围以权利要求书界定的范围为准。

Claims

1.一种Android非侵入式应用重打包方法，其步骤包括：

1)通过不修改目标Android应用代码的方式，向目标Android应用注入外部代码；所述外部代码在所述目标Android应用启动时将被执行，用于加载并运行所述目标Android应用的原始代码，以及加载Hook框架与重打包插件；所述重打包插件用于利用加载的Hook框架动态修改设定函数的函数实现、函数调用时的参数或函数返回时的结果，实现目标Android应用行为和逻辑的改变；其中，向目标Android应用注入外部代码的方法为：

将外部代码作为所述目标Android应用的主代码classes.dex，将所述目标Android应用的原主代码文件重命名或移动；当所述外部代码启动后加载并运行原主代码文件；所述外部代码包含所述目标Android应用的AndroidManifest.xml中描述的Application子类；

或者利用MultiDex机制向目标Android应用注入外部代码，其方法为：将外部代码作为一个classes(N+1).dex放入目标Android应用的安装包中；N为目标Android应用安装包根目录下已有classes*.dex的数目；所述外部代码中设有Application子类，并继承所述目标Android应用的AndroidManifest.xml中描述的Application子类，且修改AndroidManifest.xml中application标签，将其指向外部代码的设置的Application子类；

或者将外部代码作为一个so文件，替换所述目标Android应用内一so文件；将所替换的so文件移动或重命名后保留并在所述外部代码运行后被所述外部代码加载运行；

或者利用Native Activity机制向目标Android应用注入外部代码，其方法为：将外部代码作为一个so文件，并实现为一个能够启动所述目标Android应用原主界面的NativeActivity；修改所述目标Android应用的AndroidManifest.xml，让所述外部代码实现的Native Activity作为所述目标Android应用的主界面；

2)对修改后的目标Android应用进行重新签名，得到重打包后的Android应用。

2.如权利要求1所述的方法，其特征在于，所述Hook框架、重打包插件为所述外部代码的一部分。

3.如权利要求1所述的方法，其特征在于，所述Hook框架、重打包插件为单独的资源文件或网络文件，由所述外部代码动态加载。

4.如权利要求1或2或3所述的方法，其特征在于，所述目标Android应用为加壳的Android应用或未加壳的Android应用。

5.如权利要求1所述的方法，其特征在于，所述外部代码通过Android API加载Hook框架。

6.如权利要求1所述的方法，其特征在于，所述目标Android应用运行过程中，若所述目标Android应用或壳存在保护机制，会检测所述目标Android应用是否被修改，所述外部代码利用Java语言的机制或Hook框架的能力绕过保护机制。