一种安卓脱壳加速方法、装置、存储介质及计算机设备

【技术领域】

本发明涉及安卓加固逆向分析领域，尤其涉及一种安卓脱壳加速方法、装置、存储介质及计算机设备。

【背景技术】

第一代Android加固技术用于保护应用的逻辑不被逆向与分析，最早普遍在恶意软件中使用，其主要基于Java虚拟机提供的动态加载技术。相对第一代加固技术，第二代加固技术在安卓应用程序包文件Apk(Android Package，简称Apk)修改方面已经完善，能做到对开发的零干扰。开发过程中不需要对应用做任何特殊处理，仅需要在最终发布前进行保护即可。而为了实现这个零干扰的流程，保护者需要处理好Android的组件的生命周期。由于第二代加固技术仅仅对文件级别进行加密，其带来的问题是内存中的载荷是连续的，可以被攻击者轻易获取。第三代加固技术对这部分进行了改进，将保护级别降到了函数级别。第三代加固技术强调函数级别的保护，使用虚拟机内的解释器执行代码，不过存在可能被记录的缺陷。第四代加固技术则使用自定义的解释器来避免第三代的缺陷，而自定义的解释器无法对Android系统内的其他函数进行直接调用，必须使用Java的本地接口(JavaNative Interface,简称JNI)接口进行调用。根据以上内容，Android加固技术前后经历了四代技术变更，保护级别在每一代都有所提升，但其固有的安全缺陷和兼容性问题始终未能得到解决。

加固Android应用程序的脱壳技术已经引起了业界的极大关注。研究脱壳技术是Android移动终端安全的首要防线，这样才能在保护日常应用程序的同时也能够防止恶意程序利用加固技术逃避检测去危害网络生态。因此国内外众多的研究人员为加固技术的发展做出了不可磨灭的贡献。

有不少技术研究者在一些会议上演示了手工脱壳应用程序的结果。如Strazzere和Sawyer等人报告了他们的工具Android-unpacker，破解了包括APKProtect、Bangcle、360Mobile和LIAPP在内的四家公司。

往后的研究者们意识到问题根源后也开始纷纷将目光转向脱壳领域。由百度发布的ZjDroid依赖于Xposed并在运行时通过它挂载到BaseDexClassLoader来定位dex文件以获得DexOrJar。

Kang等人提出的Renovo，这个系统考虑到原始代码应该存在于内存中，并在运行时的某个时刻会解密执行。因此Renovo会在运行时监视程序执行和内存写。如果正在执行的代码是新生成的，它就会提取可执行文件的隐藏代码，从而完成脱壳。Fanglu Guo等人提出的Justin采用了脏页执行、内存避免脱壳、堆栈指针检查和命令行参数访问等启发式方法来强化对解包结束的检测。

AppSpear搜集内存中的运行时Dalvik数据结构(Dalvik Data Structure，简称DDS)来重新组装一个正常的Dex文件。一般而言，一个应用程序只能通过某些固定的系统服务完成转换。因此，AppSpear就选择通过监控某些JNI接口并确定何时开始收集Dalvik数据结构。其次，无论加固厂商加密原始数据有多复杂，Dalvik都很少修改原始字节码的语义。Dex加载过程结束后，从DDS中就可观察到原App的字节码的准确内容。最后取出anti-analysis代码并进一步综合Dex文件、清单文件和其他资源文件然后重打包并进行解包分析。

Fupk3是一个Android半自动脱壳机，首先遍历gDvm中的dvmUserDexFiles结构，获取所有cookie；其次对内存中的Dex文件，遍历触发函数，并通过在解析器处插桩，截取解密后的code_item,获取后直接返回不执行该函数。然后对内存中截取出来的数据进行重组，生成Dex文件。最后利用修改过的smali/baksmali对dump下来的dex文件进行修复。Fupk3基于Android系统KTU84P开发，可以对没被虚拟化的Java层函数进行转储。

【发明内容】

有鉴于此，本发明实施例提供了一种安卓脱壳加速方法、装置、存储介质及计算机设备，用以在复杂多变的源码环境下寻找到一个较为通用的脱壳点，并使用构造虚拟参数并进行调用的方式去加载Dex文件中所有的类，通过添加类白名单文件的方式解决脱壳过程中调用所有类方法所带来的时间消耗，过滤掉一些不必要加载的类从而加速逆向安全分析效率，以尽可能的低成本去修改，最好使用安卓系统开发中本身存在的方法或类，避免多安装新的模块和单元使得安卓脱壳更加简便快捷。

一方面，本发明实施例提供了一种安卓脱壳加速方法，包括：

选择函数到达路径并选择脱壳点；

基于过滤机制对调用方法进行精准化调用；

利用调用方法在JNI层完成JAVA层函数的虚拟调用；

对Dex文件进行修复。

可选地，选择函数到达路径并选择脱壳点具体包括：

对Quick code模式或者Interpreter模式进行选择并最终进入ExecuteSwitchImpl函数。

可选地，基于过滤机制对调用方法进行精准化调用具体包括：

获取进程最终依附的类加载器；

设置具有过滤机制的类白名单文件的路径；

对所述类白名单文件的内容进行周期性刷新。

可选地，在JNI层完成JAVA层函数的虚拟调用具体包括：

设置主动调用链标识；

调用ArtMethod的Invoke方法开始调用。

可选地，对Dex文件进行修复具体包括：

获取ArtMethod处转储的二进制文件；

根据二进制文件对Dex进行重组。

另一方面，本发明实施例提供了一种安卓脱壳加速装置，包括：

选择模块，用于选择函数到达路径并选择脱壳点；

第一调用模块，用于基于过滤机制对调用方法进行精准化调用；

第二调用模块，用于利用调用方法在JNI层完成JAVA层函数的虚拟调用；

修复模块，用于对Dex文件进行修复。

可选地，所述选择模块具体用于：

对Quick code模式或者Interpreter模式进行选择并最终进入ExecuteSwitchImpl函数。

可选地，所述第一调用模块具体包括：

第二获取模块，用于获取进程最终依附的类加载器；

设置模块，用于设置具有过滤机制的类白名单文件的路径；

刷新模块，用于对所述类白名单文件的内容进行周期性刷新。

另一方面，本发明实施例提供了一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行上述卓脱壳加速方法。

另一方面，本发明实施例提供了一种计算机设备，包括存储器和处理器，所述存储器用于存储包括程序指定的信息，所述处理器用于控制程序指令的执行，其特征在于，所述程序指令被处理器加载并执行时实现上述安卓脱壳加速方法的步骤。

本发明实施例提供的安卓脱壳加速方法、装置、存储介质和计算机设备的技术方案中，选择函数到达路径并选择脱壳点，基于过滤机制对调用方法进行精准化调用，利用调用方法在JNI层完成JAVA层函数的虚拟调用，对Dex文件进行修复实现了在复杂多变的源码环境下寻找到一个较为通用的脱壳点，并使用构造虚拟参数并进行调用的方式去加载Dex文件中所有的类，通过添加类白名单文件的方式解决脱壳过程中调用所有类方法所带来的时间消耗，过滤掉一些不必要加载的类从而加速逆向安全分析效率，以尽可能的低成本去修改，最好使用安卓系统开发中本身存在的方法或类，避免多安装新的模块和单元使得安卓脱壳更加简便快捷。

【附图说明】

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1为本发明一实施例提供的一种安卓脱壳加速方法的整体流程图；

图2为本发明又一实施例提供的一种安卓脱壳加速方法的整体流程图；

图3为本发明一实施例提供的一种安卓脱壳装置的结构示意图；

图4为本发明实施例提供的一种计算机设备的示意图；

图5为本发明实施例提供的转储成二进制文件的五元组内容构造流程图；

图6为本发明实施例提供的过滤机制类白名单的配置图。

【具体实施方式】

为了更好的理解本发明的技术方案，下面结合附图对本发明实施例进行详细描述。

应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，甲和/或乙，可以表示：单独存在甲，同时存在甲和乙，单独存在乙这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

图1为本发明一实施例提供的一种安卓脱壳加速方法的整体流程图，如图1所示，该方法包括：

步骤101、选择函数到达路径并选择脱壳点。

步骤102、基于过滤机制对调用方法进行精准化调用。

步骤103、利用调用方法在JNI层完成JAVA层函数的虚拟调用。

步骤104、对Dex文件进行修复。

本实施例提供的安卓脱壳加速方法中，选择函数到达路径并选择脱壳点，基于过滤机制对调用方法进行精准化调用，利用调用方法在JNI层完成JAVA层函数的虚拟调用，对Dex文件进行修复实现了在复杂多变的源码环境下寻找到一个较为通用的脱壳点，并使用构造虚拟参数并进行调用的方式去加载Dex文件中所有的类，通过添加类白名单文件的方式解决脱壳过程中调用所有类方法所带来的时间消耗，过滤掉一些不必要加载的类从而加速逆向安全分析效率，以尽可能的低成本去修改，最好使用安卓系统开发中本身存在的方法或类，避免多安装新的模块和单元，使得安卓脱壳更加简便快捷。

图2为本发明又一实施例提供的一种安卓脱壳加速方法的流程图，如图2所示，该方法包括：

步骤201、对Quick code模式或者Interpreter模式进行选择并最终进入ExecuteSwitchImpl函数。

本发明实施例中，Android 8.1.0版本中ART下Android执行Java的方法有两种，一个是Quick code模式，另一个则是Interpreter模式。这两种模式通过PerformCall函数中use_interpreter_entrypoint参数进行抉择，其值为true则进入Interpreter模式。Quickcode模式进入Interpreter模式需要通过art_quick_to_interpreter_bridge这个函数。使用哪种执行方法进行编译只会影响应用的运行速度，不会影响到执行程序时最终是否使用解释器。因此两种方法最终都会进入Execute函数，但是我们最终选择比它稍微晚一点进入的ExecuteSwitchImpl函数，在这里脱壳理论上可以比Execute函数执行路径程度更深。

本发明实施例中，Google在实现解释器实现的默认方式从Android7.0开始逐渐抛弃Goto跳转表，直到8.0版本已经看不到其踪影，开始令默认方式一直使用汇编解释器。Java方法和Native层有着很紧密的联系，其中比较重要的就是ArtMethod对象。对于有Artmethod对象的函数来说，源码中存在一个API(Application Programming Interface，缩写：API；又称为应用程序编程接口)：getDexFile，可以获取到它所属的DexFile对象。这个DexFile对象，里面有Begin()方法和Size()方法，分别是获取在内存里对应的Dex文件的起始地址和文件大小。一个Java方法如果需要执行，它必须要经过解释器解释，在此过程中必经之路就是会进入解释器源码中的Execute函数。

如果加固厂商使用DexClassLoader加载壳的时候没有禁用dex2oat，那么只有初始化函数会运行在解释模式下。如果禁用了dex2oat，则初始化函数和其他函数都运行在解释模式下。因此类的初始化函数与加固厂商有无禁用dex2oat是没有关系的，它都会始终都运行在解释模式下，这么一来必然会进入ART解释器。由上文可知，类的初始化函数也会进入Execute函数。

脱壳点的选择也有好坏之分，好的脱壳点可以让所有加壳的App都进入脱壳流程当中，而坏的脱壳点只能满足部分加固厂商的。因为比如dex2oat这个流程也有dexfile对象出现，但是如果把这里当作通用的脱壳点，则这些禁用掉dex2oat流程的厂商的壳就会脱不下来。由于Execute是内联函数，很难以hook的形式修改Execute的逻辑的。

本发明实施例中，作为一种可选方案，DeClassLoader为常用类加载器，此处不再赘述。

本发明实施例中，作为一种可选方案，dex2oat为常用的优化，此处不再赘述。

步骤202、基于过滤机制对调用方法进行精准化调用。

步骤202具体包括：

步骤2021、获取进程最终依附的类加载器。

如图6所示，本发明实施例中，虚拟调用的优点是能够覆盖Dex中所有的函数，从而完成更彻底的函数粒度的修复。调用组件可以调用所有的函数，从根本上解决代码覆盖率低的缺点，它是一种模拟各种场景的调用方法。当然，这本身也是一种双面刃，它牺牲了时间而换来代码覆盖率的提升。其实主动地去加载所有的类是没有必要的，我们可以选择性地去加载自己想要的函数体，我们在根据用户在Execute和dexfile对象这两个脱壳点接收到的初步脱壳反馈，可以得到Dex中所有类的类名，并把它存储为了类列表txt文件，在众多被函数抽取的方法中选择想主动加载解密的，并创造一个用户可自定义输入想要加载类名的白名单文件，通过此文本的内容实现中脱壳系统的精准调用，同时此步骤可以完成对动态加载Dex中类方法的调用。

本发明实施例中，通过Java反射原理获取加壳App最终依附的ClassLoader，即修正了生命周期以后的ClassLoader，因为我们要通过这个类加载器去加载App自己的Dex当中的类。

首先通过反射调用ActivityThread类的静态函数currentActivityThread获取当前的ActivityThread对象；然后获取ActivityThread对象的mBoundApplicSation成员变量；之后获取mBoundApplication对象的info成员变量，info是个LoadedApk类型；最终获取info对象的mApplication成员变量，类型是Application；最后通过调用Application的getClassLoader方法得到当前进程依附的Classloader。

步骤2022、设置具有过滤机制的类白名单文件的路径。

本发明实施例中，白名单文件最初设置成/sdcard目录下。但是这样存在一个问题：系统中如果有任意其他App，只要它们被用户赋予了读写sdcard的权限，由于修改源码会让每个安装好的App都会进入脱壳流程，因此它们都会去读这个白名单文件，进而执行我们的加载类的过程。如果路径规定成这样不做任何改变的话，即使其他App中不存在类白名单文件中所描述的类，系统也会尝试去加载，因此会使效率非常的低下。解决方法是巧妙运用App的私有目录来进行存储路径的构造，即使用Application对象的getFilesDir方法来获取私有目录。在私有目录下存储每个App想要加载的类白名单文件就可以完成“进程间隔离访问”。

步骤2023、对所述类白名单文件的内容进行周期性刷新。

本发明实施例中，每隔60刷新读取类白名单文件的内容，给按需更新配置文件内容预留了可观的时间，同时也便于持久地使用。

步骤203、利用调用方法在JNI层完成JAVA层函数的虚拟调用。

步骤203具体包括：

步骤2031、设置主动调用链标识。

本发明实施例中，这里我们只需要设置我们的主动调用链标识，其他参数可以按照其变量类型进行伪造，比如线程参数可以是Null、字符串型参数可以是abc等，为后续判断是否为进入调用链的函数提供必要的识别条件，构造前的第一步都是需要判断欺骗调用链标识。最后调用ArtMethod的Invoke方法来开始“虚拟”调用。

步骤2032、调用ArtMethod的Invoke方法开始调用。

本发明实施例中，ART的运行模式属于预先编译(Ahead-Of-Time，简称AOT)，在Apk安装的时候，每个Java方法都会由dex2oat编译成目标代码，而不再是虚拟机执行的字节码但同时Dex字节码仍然还在OAT过程里存在，所以ART的代码执行既支持QuickCompiledCode模式，也同时支持解释器模式以及JIT执行模式。Invoke可以进入OAT优化，Interpreter模式执行方法。如果当前是Interpreter模式，就调用art::interpreter::EnterInterpreterFromInvoke；如果是OAT模式，就调用art_quick_invoke_stub(简称stub)。EnterInterpreterFromInvoke函数里会判断是Native还是解释器执行。

从Android源码中LinkCode部分可以知道，无论一个类方法是通过解释器执行，还是直接以本地机器指令执行，均要通过ArtMethod类的成员函数GetEntryPointFromCompiledCode获得其Entry点，并且该Entry点不为NULL。不过，Invoke并没有直接在该点设置一个地址值，而是通过stub来间接调用。这是因为ART需要设置一些特殊的寄存器。构造时，判断出是从入口点进入调用链的函数的话，在Invoke函数的开头执行部分直接根据ArtMethod对象的API——GetDexFile函数去回溯Dex文件并进行转储即可。

本发明实施例中，作为一种可选方案，dex2oat为ART中对Dex文件的提前编译操作，结果是生成一个本地可执行的ELF文件，可以直接被本地处理器执行。

步骤204、对Dex文件进行修复。

步骤204包括：

步骤2041、获取ArtMethod处转储的二进制文件。

如图5所示，本发明实施例中，由于到这一步已经成功获取Java方法在Native层对应的ArtMethod对象，我们可以使用它的API：GetDexFile方法来获取dexfile对象，进而可以得到Dex文件在内存中所处的位置和大小，这样就可以成功转储Dex文件。与此同时，我们在此过程中另外附加了一个功能：转储ArtMethod对象的CodeItem字节码部分。因为Java方法在Dex中存储的格式正是CodeItem形式，如果仅仅转储Dex文件并不能解决函数体置空和偏移处理，通过欺骗调用链寻找到深层次的函数调用解密时机才是解决函数抽取型加固保护的重点。最后通过刚刚前一步转储的Dex文件，通过解析Dex文件可以获取Try...catch字段和Handler字段，这两个因素会影响CodeItem整体大小的判断：判断类方法是否有Try...catch字段；在有Try...catch语句时，Java方法的CodeItem字节码的结束地址还需通过先解析Handler字段获取其长度范围才能最终正确计算CodeItem整体的大小；在没有Try...catch语句时，由于结束地址就是整个Java方法对应的末尾，所以这时只需要解析CodeItem首部字段获取CodeItem整体的大小即可。转储格式为二进制bin格式。

本发明实施例中，作为一种可选方案，Handler是处于Try...catch字段的末尾的字段。

步骤2042、根据二进制文件对Dex进行重组。

本发明实施例中，最终需要得到的产物是回填好函数体的Dex文件，因此在步骤2041中得到二进制文件以后需要使用脚本去根据与之一起转储的Dex文件格式进行一个解密和重组的过程。通过解析二进制文件将五元组的内容按组读取放入数组中存储，进而通过五元组中offset和code_item_len在新Dex中找到相应的位置，并把ins的内容Base64解密后回填，再把原Dex其余的内容补齐到新Dex中，如此循环。

本发明实施例提供的安卓脱壳加速方法中，选择函数到达路径并选择脱壳点，基于过滤机制对调用方法进行精准化调用，利用调用方法在JNI层完成JAVA层函数的虚拟调用，对Dex文件进行修复实现了在复杂多变的源码环境下寻找到一个较为通用的脱壳点，并使用构造虚拟参数并进行调用的方式去加载Dex文件中所有的类，通过添加类白名单文件的方式解决脱壳过程中调用所有类方法所带来的时间消耗，过滤掉一些不必要加载的类从而加速逆向安全分析效率，以尽可能的低成本去修改，最好使用安卓系统开发中本身存在的方法或类，避免多安装新的模块和单元，使得安卓脱壳更加简便快捷。

本发明一实施例提供了一种安卓脱壳加速装置，装置应用于计算机设备，图3为本发明一实施例提供的一种安卓脱壳装置的结构示意图，如图3所示，该装置包括：选择模块11、第一调用模块12、第二调用模块13、修复模块14。

选择模块11用于选择函数到达路径并选择脱壳点，第一调用模块12用于基于过滤机制对调用方法进行精准化调用，第二调用模块13用于利用调用方法在JNI层完成JAVA层函数的虚拟调用，修复模块14用于对Dex文件进行修复。

本发明实施例中，选择模块11具体用于：对Quick code模式或者Interpreter模式进行选择并最终进入ExecuteSwitchImpl函数。

本发明实施例中，第一调用模块12具体包括：第二获取模块用于获取进程最终依附的类加载器，设置模块用于设置具有过滤机制的类白名单文件的路径，刷新模块用于对所述类白名单文件的内容进行周期性刷新。

本实施例提供的安卓脱壳加速装置可用于实现上述图1或图2中的安卓脱壳加速方法，具体描述可参见上述安卓脱壳加速方法的实施例，此处不再重复描述。

本发明实施例提供的技术方案中，选择函数到达路径并选择脱壳点，基于过滤机制对调用方法进行精准化调用，利用调用方法在JNI层完成JAVA层函数的虚拟调用，对Dex文件进行修复实现了在复杂多变的源码环境下寻找到一个较为通用的脱壳点，并使用构造虚拟参数并进行调用的方式去加载Dex文件中所有的类，通过添加类白名单文件的方式解决脱壳过程中调用所有类方法所带来的时间消耗，过滤掉一些不必要加载的类从而加速逆向安全分析效率，以尽可能的低成本去修改，最好使用安卓系统开发中本身存在的方法或类，避免多安装新的模块和单元使得安卓脱壳更加简便快捷。

图4为本发明实施例提供的一种计算机设备的示意图。如图4所示，该实施例的计算机设备20包括：处理器21、存储器22以及存储在存储22中并可在处理器21上运行的计算机程序23，该计算机程序23被处理器21执行时实现实施例中的应用于安卓脱壳加速方法，为避免重复，此处不一一赘述。或者，该计算机程序被处理器21执行时实现实施例中应用于安卓脱壳加速装置中各模型/单元的功能，为避免重复，此处不一一赘述。

计算机设备20包括，但不仅限于，处理器21、存储器22。本领域技术人员可以理解，5仅仅是计算机设备20的示例，并不构成对计算机设备20的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如计算机设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器21可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器22可以是计算机设备20的内部存储单元，例如计算机设备20的硬盘或内存。存储器22也可以是计算机设备20的外部存储设备，例如计算机设备20上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，存储器22还可以既包括计算机设备20的内部存储单元也包括外部存储设备。存储器22用于存储计算机程序以及计算机设备所需的其他程序和数据。存储器22还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器(Processor)执行本发明各个实施例方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。