一种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框架是单独的文件，则可以通过androidapi，如dexclassloader类和runtime.load等函数，动态加载hook框架)。hook框架可以修改进程空间内的函数，包括frameworkapi与应用代码内的函数。

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

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

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

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

1-2)利用multidex机制。android5.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)利用nativeactivity机制。activity是android应用的界面，从手机桌面启动应用时，会有一个主界面会被打开。androidmanifest.xml中描述了一个activity的属性，可以声明一个activity是nativeactivity，并声明实现该activity的so文件。因此，可将外部代码作为一个so文件，并实现一个nativeactivity。修改androidmanifest.xml，让外部代码实现的nativeactivity作为应用的主界面。当应用从桌面启动时，nativeactivity将被启动，外部代码将会被加载并执行。而后，nativeactivity再启动原来的主界面，维持应用的原有逻辑和流程。

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

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

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

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

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

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

附图说明

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

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

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

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

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

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

具体实施方式

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

如图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，加入应用中。因此，在android5.0及以后的系统中，应用运行时，classesn+1.dex也会随classes.dex一同加载。重打包时，修改了androidmanifest.xml,将原本的application子类applicationold修改为来自外部代码，继承applicationold的applicationnew。作为应用的入口，applicationnew将自动初始化，外部代码得以自动运行。此后，外部代码加载hook框架，并绕过应用保护机制。之后，外部代码通过applicationnew调用父类函数，就可以实现applicationold的初始化。然后，外部代码加载运行重打包插件，修改应用逻辑。最后，执行修改后的代码。

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

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

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