CN105224869A - 组件测试方法和装置 - Google Patents
组件测试方法和装置 Download PDFInfo
- Publication number
- CN105224869A CN105224869A CN201410262117.7A CN201410262117A CN105224869A CN 105224869 A CN105224869 A CN 105224869A CN 201410262117 A CN201410262117 A CN 201410262117A CN 105224869 A CN105224869 A CN 105224869A
- Authority
- CN
- China
- Prior art keywords
- attribute
- static component
- assembly
- judging
- component
- 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.)
- Granted
Links
Abstract
本发明公开了一种组件测试方法和装置。其中，组件测试方法包括：获取待测试应用程序中的目标组件的组件类型，其中，目标组件为允许被第三方应用程序访问的组件；获取与组件类型对应的测试指令；发送测试指令至安装有待测试应用程序的目标设备；获取目标设备对测试指令的响应结果；以及根据响应结果确定目标组件的状态。通过本发明，解决了现有技术中无法对应用程序进行自动化测试的问题，进而达到了提高测试效率的效果。
Description
技术领域
本发明涉及测试领域，具体而言，涉及一种组件测试方法和装置。
背景技术
随着移动终端平台的兴起，人们的生活越来越依赖移动智能设备，移动平台涌现出成千上万各式各样的应用程序(即，app)。由于系统的开放性，Androidapp的安全性受到越来越多的关注和研究。组件是Androidapp的基础，用于构建app的各类功能和服务，其中活动组件(即，Activity组件)用于可视化界面展现，广播接收器组件(即，BroadcastReceiver组件)用于接收并响应广播，服务组件(即，Service组件)用于实现后台服务，内容提供者组件(即，ContentProvider组件)用于数据访问，可在app之间共享数据。
Android系统提供了一套独有的组件间通信机制，用于app组件间的调用和交互。在同一个app之中或不同app之间，Activity组件、BroadcastReceiver组件和Service组件使用Intent相互调用，使用系统提供的接口ContentResolver访问ContentProvider组件，共同实现app的功能。
组件间的通信由于AndroidManifest文档配置不规范或代码实现不严谨存在两类安全问题：Intent劫持和组件暴露。Intent劫持指组件通过Intent调用其他组件时，由于没有显式地指定接收组件导致Intent可能逃出当前app而被其他app恶意劫持，如图1所示，组件A发送一个Intent消息，在多个目标组件都可以响应的情况下，系统以随机顺序或让用户选择的方式决定哪个组件响应，恶意app的组件B可能先被响应，从而导致钓鱼、信息泄漏等安全风险；组件暴露指组件访问权限完全对外开放，第三方app不需要任何特殊权限就可随时调用暴露组件，如图1中的组件C若是暴露的，恶意app的组件D可随时调用组件C执行相关逻辑，从而导致拒绝服务、数据泄漏或被污染、能力或权限泄漏等安全风险。目标组件(被调用者)不可信导致Intent劫持安全风险，源组件(调用者)不可信导致组件暴露安全风险，图2为组件暴露导致app接收到特定消息即崩溃的示意图，其中，***表示app的名称，在图2中示意性以字符“*”代替。
针对组件权限安全问题，现有技术中已提出若干技术方案，有的采用静态分析AndroidManifest.xml文档和反编译的smali代码完成安全分析，其中，smali代码为APK反编译生成的文件格式，是Android系统的虚拟机指令语言；有的则通过生成测试app模拟发送特定Intent消息进行动态安全测试。目前业界已有几款组件安全分析工具，如静态分析工具ComDroid、CHEX和Woodpecker等，动态测试工具IntentFuzzer、Drozer等。
ComDroid静态检查APK的AndroidManifest.xml文档中组件属性和smali代码中发送Intent的代码点，判定是否存在隐式发送的Intent、隐式启动的Activity组件和Service组件及用于接收系统广播的BroadcastReceiver组件；CHEX静态分析app的所有可用入口，采用数据流分析并获取可用的路径，判定是否存在组件劫持问题，如权限泄漏、Intent劫持和私有数据泄漏等安全风险；Woodpecker静态检测app暴露的组件，模拟数据流分析，识别可能的执行路径并确定可用路径，判定app是否存在使用敏感权限的行为。
IntentFuzzer是一款动态组件权限安全测试工具，以app形式提供可视化测试界面，通过界面点击选择app的某一组件，自动发送空Intent消息，并观察被测app是否存在崩溃或其他异常现象。
Drozer(原Mercury)是一款开源的Android动态安全评估框架，由运行在PC(PersonalComputer，简称PC)上的客户端和运行在Android设备上的服务端代理两个模块组成，通过客户端命令行发送不同指令进行安全测试。Drozer首先进行攻击面分析，静态检查app中的暴露组件，然后采用命令行指令依次测试每个暴露的组件以确认是否出现应用崩溃、数据泄漏及能力泄漏等安全风险。
现有技术方案从静态和动态两个不同侧面进行组件权限安全分析。静态分析方案通过检查AndroidManifest.xml文档和反编译的代码，分析app中存在的Intent劫持、能力泄漏及数据泄漏等安全问题，现有静态分析方案可自动化完成，但存在大量误报，且对组件暴露的检查不全面；动态分析工具IntentFuzzer和Drozer需额外安装app到设备，IntentFuzzer未对非暴露组件进行过滤，且需人工选择点击，效率和准确性较低；Drozer测试框架整体较繁重，在PC客户端远程控制Android设备，组件暴露的判定规则仍有遗漏，且对每个暴露组件需人工命令行指令逐一测试。
现有技术主要采用静态分析配置文档和反编译的源码判定app中的暴露组件，手工选择或命令行指令对每个暴露组件逐一进行安全测试，并由测试人员观察是否存在安全风险，存在以下缺点：
(1)对组件暴露的判定规则不完备；
(2)静态分析方案存在大量误报，影响安全测试效率；
(3)动态测试方案需额外安装app到Android设备；
(4)动态测试方案需大量人工参与，未实现自动化测试和异常识别。
针对相关技术中无法对应用程序进行自动化测试的问题，目前尚未提出有效的解决方案。
发明内容
本发明实施例的主要目的在于提供一种组件测试方法和装置，以解决现有技术中无法对应用程序进行自动化测试的问题。
为了实现上述目的，根据本发明实施例的一个方面，提供了一种组件测试方法。
根据本发明实施例的组件测试方法包括：获取待测试应用程序中的目标组件的组件类型，其中，所述目标组件为允许被第三方应用程序访问的组件；获取与所述组件类型对应的测试指令；发送所述测试指令至安装有所述待测试应用程序的目标设备；获取所述目标设备对所述测试指令的响应结果；以及根据所述响应结果确定所述目标组件的状态。
为了实现上述目的，根据本发明实施例的另一方面，提供了一种组件测试装置。
根据本发明实施例的组件测试装置包括：第一获取单元，用于获取待测试应用程序中的目标组件的组件类型，其中，所述目标组件为允许被第三方应用程序访问的组件；第二获取单元，用于获取与所述组件类型对应的测试指令；发送单元，用于发送所述测试指令至安装有所述待测试应用程序的目标设备；第三获取单元，用于获取所述目标设备对所述测试指令的响应结果；以及第一确定单元，用于根据所述响应结果确定所述目标组件的状态。
在本发明实施例中，采用获取待测试应用程序中的目标组件的组件类型，其中，所述目标组件为允许被第三方应用程序访问的组件；获取与所述组件类型对应的测试指令；发送所述测试指令至安装有所述待测试应用程序的目标设备；获取所述目标设备对所述测试指令的响应结果；以及根据所述响应结果确定所述目标组件的状态。通过对目标组件的组件类型进行获取，进而发送与目标组件的组件类型相对应的测试指令至目标设备，实现了根据不同类型的组件，自动发送相应的测试指令至目标设备，测试过程不需要人工干预，解决了现有技术中无法对应用程序进行自动化测试的问题，进而达到了提高测试效率的效果。
附图说明
构成本申请的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据相关技术的组件权限安全的示意图；
图2是根据相关技术的因组件权限安全导致app崩溃的示意图；
图3a和图3b是执行本发明实施例的组件测试方法的计算机的结构框图；
图4是根据本发明实施例的组件测试方法的流程图；
图5是根据本发明又一实施例的组件测试方法的流程图；
图6是根据本发明又一实施例的组件测试方法的流程图；
图7是根据本发明又一实施例的组件测试方法的流程图；
图8是根据本发明又一实施例的组件测试方法的流程图；
图9是图8中步骤S7061的一种具体实施方式的流程图；
图10是图8中步骤S7061的又一种具体实施方式的流程图；
图11是图8中步骤S7062的一种具体实施方式的流程图；
图12是根据本发明实施例的组件测试装置的示意图；
图13是根据本发明又一实施例的组件测试装置的示意图；
图14是根据本发明又一实施例的组件测试装置的示意图；
图15是根据本发明又一实施例的组件测试装置的示意图；
图16是根据本发明又一实施例的组件测试装置的示意图；
图17是图16中第三确定子单元的一种具体结构的示意图；
图18是图16中第三确定子单元的又一种具体结构的示意图；以及
图19是图16中第四确定子单元的一种具体结构的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
对本发明实施例所涉及的技术术语介绍如下：
Android：是一种基于Linux的自由及开放源代码的操作系统，主要用于移动设备、如智能手机和平板电脑，在智能手机市场占有率达到80％左右；
App：本文指Android平台的应用程序；
APK：是ApplicationPackageFile的缩写，指Android系统的应用程序安装包的文件格式；
组件：指Andriod系统提供给开发者实现app的基础实体，包括活动组件(即，Activity组件)、广播接收器组件(即，BroadcastReceiver组件)、服务组件(即，Service组件)和内容提供者组件(即，ContentProvider组件)四种组件；
组件权限：每个组件可设置访问权限，以控制本app其他组件或其他app的组件对其进行访问，根据不同安全级别可设置为完全开放、仅对可信调用者开放和仅对本app开放等；
Intent：指Androidapp实现组件间通信的实体，Activity组件、BroadcastReceiver组件和Service组件通过Intent实现组件间通信；
AndroidManifest文档：是Androidapp包含的权限、组件申请及定义的配置文件，在开发阶段进行配置，其内容主要包括app向系统预定义和申请的权限(如打电话、收发短信权限)，app预定义的组件信息，app的包名和版本信息等；
拒绝服务：原指目标服务器受到恶意用户攻击停止继续提供正常服务，本文指Android应用受到恶意攻击导致应用在本地终端崩溃、卡死等现象，无法继续提供正常的服务。
实施例1
根据本发明实施例，可以提供了一种可以用于实施本申请装置实施例的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
根据本发明实施例，提供了一种组件测试方法，该组件测试方法可以由计算机或类似的运算装置执行，主要对安卓平台的应用程序中的组件进行测试，图3a和图3b为一种执行本发明实施例的组件测试方法的计算机的结构框图，如图3a和图3b所示，该计算机主要包括测试终端100和目标设备200，测试终端100和目标设备200可以通过局域网、互联网、移动通讯网络等方式进行数据传输，也可以通过进场通讯、蓝牙通讯等方式进行数据传输。其中，在测试终端100上运行本发明实施例所提供的组件测试方法，在目标设备200上安装待测试应用程序，目标设备200可以是图3a中示出的能够安装待测试应用程序的安卓设备，比如手机、平板电脑等，也可以是图3b中示出PC(PersonalComputer)，该PC上具有模拟的安卓设备，并且该模拟的安卓设备上安装有待测试应用程序。本领域普通技术人员可以理解，图3a和图3b所示的结构仅为示意，其并不对上述计算机的结构造成限定。例如，计算机可包括比图3a和图3b中所示更多或者更少的组件，或者具有与图3a和图3b所示不同的配置。
测试终端100用于获取待测试应用程序中的目标组件的组件类型，其中，目标组件为允许被第三方应用程序访问的组件，即，目标组件为暴露的组件，其访问权限完全对外开放，第三方应用程序无需任何特殊权限即可对其进行访问。在获取到目标组件的组件类型之后，测试终端100获取与组件类型对应的测试指令，然后将获取到的测试指令发送至安装有待测试应用程序的目标设备200，再获取目标设备200对测试指令的响应结果，最后根据响应结果确定目标组件的状态，所确定的目标组件的状态主要包括指待测试应用程序出现闪退、弹异常退出确认框、存在数据泄露、存在目录遍历风险等。
在本发明实施例中，待测试应用程序中的目标组件主要分为四类：活动组件(即，Activity组件)、广播接收器组件(即，BroadcastReceiver组件)、服务组件(即，Service组件)和内容提供者组件(即，ContentProvider组件)，其中，内容提供者组件包括静态组件中的内容提供者组件和动态组件中的内容提供者组件，对于目标组件为静态组件中的活动组件、广播接收器组件、服务组件以及动态组件中未通过系统类本地广播管理器(LocalBroadcastManager)注册的广播接收器组件的情况，测试指令为空消息(空Intent)指令，对于目标组件为静态组件中的内容提供者组件的情况，测试指令为访问路径查询指令。
图4是根据本发明实施例的组件测试方法的流程图，如图4所示，该组件测试方法主要包括如下的步骤S401至步骤S405：
S401：获取待测试应用程序中的目标组件的组件类型，其中，目标组件为允许被第三方应用程序访问的组件，即，目标组件为暴露的组件，其访问权限完全对外开放，第三方应用程序无需任何特殊权限即可对其进行访问。
S402：获取与组件类型对应的测试指令，对于目标组件为静态组件中的活动组件、广播接收器组件、服务组件以及动态组件中未通过系统类本地广播管理器(LocalBroadcastManager)注册的广播接收器组件的情况，测试指令为空消息(即，空Intent)指令，对于目标组件为静态组件中的内容提供者组件的情况，测试指令为访问路径查询指令(即，ContentURI)。
S403：发送测试指令至安装有待测试应用程序的目标设备，其中，在发送测试指令至目标设备之前，待测试应用程序已经在目标设备上启动，对于待测试应用程序的安装，可以通过发送命令“adbinstallAPK文件名”至目标设备的方式，经待测试应用程序安装至目标设备，对于待测试应用程序的启动，则可以通过发送命令“adbshellamstar-napp包名/首页activity组件名”至目标设备，来启动待测试应用程序。
S404：获取目标设备对测试指令的响应结果。
S405：根据响应结果确定目标组件的状态。
本发明实施例所提供的组件测试方法，通过对目标组件的组件类型进行获取，进而发送与目标组件的组件类型相对应的测试指令至目标设备，实现了根据不同类型的组件，自动发送相应的测试指令至目标设备，测试过程不需要人工干预，解决了现有技术中无法对应用程序进行自动化测试的问题，进而达到了提高测试效率的效果。
针对目标组件的类型不同，步骤S402至步骤S405分别通过不同的方式来实行对目标组件状态的测试，具体测试方式在图5和图6中示出。
图5是根据本发明又一实施例的组件测试方法的流程图，如图5所示，对于目标组件包括以下至少之一的情况：待测试应用程序的静态组件中的活动组件、广播接收器组件和服务器组件以及待测试应用程序的动态组件中未通过系统类本地广播管理器注册的广播接收器组件，步骤S402可以被细化为步骤S4021：获取测试指令中的空消息指令；步骤S403可以被细化为步骤S4031：发送空消息指令至目标设备；步骤S404可以被细化为步骤S4041：获取目标设备的日志输出；步骤S405可以被细化为步骤S4051和S4052，S4051：判断日志输出中的任一日志记录是否同时包括目标包名和预设标识，其中，目标包名为应用程序的包名；S4052：在判断出日志输出中的任一日志记录同时包括目标包名和预设标识的情况下，确定目标组件处于预设标识对应的状态。
其中，可以以预设标识“hasdied”表示目标组件对应的待测试应用程序出现闪退，则在获取到的日志记录中同时包括该待测试应用程序的包名和预设标识“hasdied”的情况下，则可以确定待测试应用程序出现闪退。可以以预设标识“Forcefinishactivity”表示目标组件对应的待测试应用程序弹出异常退出确认框，则在获取到的日志记录中同时包括该待测试应用程序的包名和预设标识“Forcefinishactivity”的情况下，则可以确定待测试应用程序弹出异常退出确认框。比如某一条日志记录为“I/ActivityManager(1113):Processcom.tencent.mobileqq:MSF(pid3506)hasdied”，其中，该日志记录包括的应用程序包名和预设标识分别为“com.tencent.mobileqq”、“hasdied”，对于此种情况，可以确定名称为“mobileqq”的应用程序出现闪退。又如某一条日志记录为“W/ActivityManager(62):Forcefinishingactivitycom.tencent.qqlive/.activity.VideoListActivity”，其中，该日志记录包括的应用程序包名和预设标识分别为“com.tencent.qqlive”、“Forcefinishactivity”，对于此种情况，可以确定名称为“qqlive””的应用程序弹出异常退出确定框。
图6是根据本发明又一实施例的组件测试方法的流程图，如图6所示，对于目标组件包括待测试应用程序的静态组件中的内容提供者组件的情况，步骤S402可以被细化为步骤S4022：获取测试指令中的访问路径查询指令；步骤S403可以被细化为步骤S4032：发送访问路径查询指令至目标设备的内容接收接口(即，ContentResolver接口)；步骤S404可以被细化为步骤S4042：获取内容接收接口对访问路径查询指令的查询响应；步骤S405可以被细化为步骤S4053和S4054，步骤S4053：判断查询响应是否表示查询失败；步骤S4054在判断出查询响应表示查询失败的情况下，确定目标组件处于安全状态。
对于ContentProvider组件，通过ContentResolver接口执行URI查询返回的结果字符串判定应用程序是否存在数据泄漏或目录遍历风险。
若查询失败说明不存在数据泄漏，并且不存在目录遍历风险，目标组件处于安全状态；否则存在数据泄漏，第三方应用程序可以通过该目标组件读取私有数据，其中，如果查询结果为本地IP地址，比如127.0.0.1localhost，则说明存在目录遍历风险，第三方应用程序可以通过该目标组件遍历应用程序的目录。
通过对目标组件的是否处于安全状态的确定，实现了通过判断目标组件是否存在安全风险，来判断待测试应用程序是否出现异常行为，该异常行为包括APP崩溃、挂起、数据泄漏和目录遍历等。
其中，可以通过adb的shell命令来发送空消息指令或访问路径查询指令至目标设备，上述目标组件的具体类型和定义与空消息指令或访问路径查询指令的对应关系如表1所示：
表1
图7是根据本发明又一实施例的组件测试方法的流程图，如图7所示，在步骤S401获取待测试应用程序中的目标组件的组件类型之前，本发明实施例所提供的组件测试方法还包括通过如下步骤S702至步骤S706来确定目标组件：
S702：解压缩待测试应用程序的安装文件，得到解压缩文件，具体地，待测试应用程序的安装文件是APK文件，该APK文件是一个压缩包文档，可以通过7z.exe进行解压缩，解压缩后的文件夹中含有待测试应用程序的配置文档(即，AndroidManifest.xml二进制文档)和对待测试应用程序的源代码进行编译得到的二进制文件(即，classes.dex)等文件，其中，AndroidManifest.xml是待测试应用程序的核心配置文档，定义了待测试应用程序的大部分组件的详细信息。
S704：反编译解压缩文件，得到反编译文档，具体地，如图8所示，主要是将配置文档转换为xml文档(即，步骤S7041)，以及将二进制文件反编译为java源文件(即，步骤S7042)，其中，可以通过java程序AXMLPrinter2.jar将AndroidManifest.xml二进制文档转换为可视化的XML文档；classes.dex是app源代码编译转换后的二进制文件，可以通过dex2jar，jad.exe等序可反编译生成java源码。
S706：根据反编译文档确定目标组件，具体地，如图8所示，对于将配置文档转换为xml文档的情况，步骤S706可以具体为步骤S7061：根据xml文档确定待测试应用程序的静态组件中的目标组件，对于将二进制文件反编译为java源文件的情况，步骤S706可以具体为步骤S7062：根据java源文件确定待测试应用程序的动态组件中的目标组件。
其中，对于静态组件包括以下至少之一的情况：活动组件、广播接收器组件和服务器组件，根据xml文档确定待测试应用程序的静态组件中的目标组件的具体确定方式可以通过图9中示出的方式来确定，如图9所示，根据xml文档确定待测试应用程序的静态组件中的目标组件主要包括如下步骤S901至步骤S905：
S901：读取xml文档，并解析xml文档的根节点，得到多个静态组件及每个静态组件的属性，然后采用步骤S902至步骤S904来判断第一静态组件是否为目标组件，其中，第一静态组件为多个静态组件中的任一组件，对xml文档的根节点进行解析还可以得到待测试应用程序的包名，具体解析方式可以采用现有技术中的任意一种解析方式，此处不再介绍。
S902：A1判断：判断第一静态组件的属性中是否包括开放属性，开放属性是指exported属性，其中，在判断出第一静态组件的属性中包括开放属性的情况下，执行B1判断，在判断出第一静态组件的属性中不包括开放属性的情况下，执行C1判断。
S903：B1判断：判断开放属性的属性值是否为假，即，判断exported是否等于false，其中，在判断出开放属性的属性值为假的情况下，确定第一静态组件为非目标组件，在判断出开放属性的属性值为真的情况下，执行D1判断。
S904：C1判断：判断第一静态组件的属性中是否包括消息过滤器标签，消息过滤器标签是指intent-filter标签，其中，在判断出第一静态组件的属性中包括消息过滤器标签的情况下，执行D1判断，在判断出第一静态组件的属性中不包括消息过滤器标签的情况下，确定第一静态组件为非目标组件。
S905：D1判断：判断第一静态组件的属性中是否包括权限属性，权限属性是指permission属性(非系统权限且添加签名级别保护的自定义权限，包括readpermission和writepermission)，其中，在判断出第一静态组件的属性中包括权限属性的情况下，确定第一静态组件为非目标组件，在判断出第一静态组件的属性中不包括权限属性的情况下，确定第一静态组件为目标组件。
对于静态组件为内容提供者组件的情况，根据xml文档确定待测试应用程序的静态组件中的目标组件的具体确定方式可以通过图10中示出的方式来确定，如图10所示，根据xml文档确定待测试应用程序的静态组件中的目标组件主要包括如下步骤S1001至步骤S1007：
S1001：读取xml文档，并解析xml文档的根节点，得到多个静态组件及每个静态组件的属性，然后采用步骤S1002至步骤S1007来判断第二静态组件是否为目标组件，其中，第二静态组件为多个静态组件中的任一组件，对xml文档的根节点进行解析还可以得到待测试应用程序的包名，具体解析方式可以采用现有技术中的任意一种解析方式，此处不再介绍。
S1002：A2判断：判断第二静态组件的属性中是否包括开放属性，开放属性是指exported属性，其中，在判断出第二静态组件的属性中包括开放属性的情况下，执行B2判断，在判断出第二静态组件的属性中不包括开放属性的情况下，执行C2判断；
S1003：B2判断：判断开放属性的属性值是否为假，即，判断exported是否等于false，其中，在判断出开放属性的属性值为假的情况下，确定第二静态组件为非目标组件，在判断出开放属性的属性值为真的情况下，执行D2判断；
S1004：C2判断：判断第二静态组件的属性中最小软件开发工具包版本值(即，最小SDK版本，minSDKVersion属性)和目标软件开发工具包版本值(即，targetSDKVersion属性)是否均大于或等于预设值，在本发明实施例中，预设值为安卓系统4.0版本，对应的版本值为17，其中，在判断出第二静态组件的属性中最小软件开发工具包版本值和目标软件开发工具包版本值均大于或等于预设值的情况下，确定第二静态组件为非目标组件，反之，执行E判断；
S1005：D2判断：判断第二静态组件的属性中是否包括权限属性，权限属性是指permission属性(非系统权限且添加签名级别保护的自定义权限，包括readpermission和writepermission)，其中，在判断出第二静态组件的属性中包括权限属性的情况下，确定第二静态组件为非目标组件，在判断出第二静态组件的属性中不包括权限属性的情况下，确定第二静态组件为目标组件；
S1006：E判断：判断第二静态组件的属性中是否包括权限属性，权限属性是指permission属性(非系统权限且添加签名级别保护的自定义权限，包括readpermission和writepermission)，其中，在判断出第二静态组件的属性中包括权限属性的情况下，确定第二静态组件为非目标组件，在判断出第二静态组件的属性中不包括权限属性的情况下，执行F判断；
S1007：F判断：判断第二静态组件的属性中是否存在权限为经过签名级别保护的子路径标签(即，path标签)，即，在判断出第二静态组件的属性中不包括权限属性的情况下，进一步判断第二静态组件的属性中是否存在子路径标签，并且子路径标签的权限(即，path-permission)已经过签名级别保护，其中，在判断出第二静态组件的属性中存在权限为经过签名级别保护的子路径标签的情况下，确定第二静态组件为非目标组件，在判断出第二静态组件的属性中不存在权限为经过签名级别保护的子路径标签的情况下，确定第二静态组件为目标组件。
对于动态组件包括未通过系统类本地广播管理器注册的广播接收器组件的情况，根据java源文件确定待测试应用程序动态组件中的目标组件的具体确定方式可以通过图11中示出的方式来确定，如图11所示，根据java源文件确定待测试应用程序动态组件中的目标组件主要包括如下步骤S1101至步骤S1104：
S1101：读取java源文件的文本内容，得到多个动态组件及每个动态组件的属性，然后采用步骤S1102至步骤S1104来判断第一动态组件是否为目标组件，其中，第一动态组件为多个动态组件中的任一组件。
S1102：判断第一动态组件的属性中是否包括消息过滤器标签，消息过滤器标签是指intent-filter标签，S1103：判断第一动态组件的属性中是否包括非系统预定义的动作标签，动作标签是指action标签，S1104：判断第一动态组件是否通过未添加权限校验的注册接收(RegisiterReceiver)接口动态注册，即，判断第一动态组件是否通过注册接收(RegisiterReceiver)接口动态注册广播，并且所通过的注册接收接口是未权限校验的接口，其中，权限校验是指permision校验，意思是非系统权限且添加签名级别保护的权限，在判断出第一动态组件的属性中包括消息过滤器标签、第一动态组件的属性中包括非系统预定义的动作标签、以及第一动态组件通过未添加权限校验的注册接收接口动态注册的情况下，确定第一动态组件为目标组件。
通过以上描述可以看出，本发明实施例所提供的组件测试方法，采用静态和动态相结合的方式实现，通过归纳Androidapp四类组件暴露的完整规则，静态分析AndroidManifest.xml文档和反编译的源码确定app中哪些组件对外暴露的目标组件，对于app的Activity、Service和BroadcastReceiver暴露组件，自动发送异常Intent触发其响应，并通过系统日志信息自动判定app是否出现异常；对于暴露的ContentProvider组件，审查源码查找可用的ContentURI，并通过ContentResolver接口查询关联数据，输入畸形的ContentURI判定是否存在目录遍历安全风险。相比现有检测方案，本发明实施例所提供的测试方法具有以下几点优势：1、测试过程不需人工干预，自动化完成；2、组件暴露的检查规则更完备准确；3、实现自动化Intent模拟发送和异常识别；4、检测结果不存在误报。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
实施例2
根据本发明实施例，还提供了一种用于实施上述组件测试方法的组件测试装置，该组件测试装置主要用于执行本发明实施例上述内容所提供的组件测试方法，以下对本发明实施例所提供的组件测试装置做具体介绍：
图12是根据本发明实施例的组件测试装置的示意图，如图12所示，该组件测试装置主要包括第一获取单元10、第二获取单元20、发送单元30、第三获取单元40和第一确定单元50，其中：
第一获取单元10用于获取待测试应用程序中的目标组件的组件类型，其中，目标组件为允许被第三方应用程序访问的组件，即，目标组件为暴露的组件，其访问权限完全对外开放，第三方应用程序无需任何特殊权限即可对其进行访问。
第二获取单元20用于获取与组件类型对应的测试指令，对于目标组件为静态组件中的活动组件、广播接收器组件、服务组件以及动态组件中未通过系统类本地广播管理器(LocalBroadcastManager)注册的广播接收器组件的情况，测试指令为空消息(即，空Intent)指令，对于目标组件为静态组件中的内容提供者组件的情况，测试指令为访问路径查询指令(即，ContentURI)。
发送单元30用于发送测试指令至安装有待测试应用程序的目标设备，其中，在发送测试指令至目标设备之前，待测试应用程序已经在目标设备上启动，对于待测试应用程序的安装，可以通过发送命令“adbinstallAPK文件名”至目标设备的方式，经待测试应用程序安装至目标设备，对于待测试应用程序的启动，则可以通过发送命令“adbshellamstar-napp包名/首页activity组件名”至目标设备，来启动待测试应用程序。
第三获取单元40用于获取目标设备对测试指令的响应结果。
第一确定单元50用于根据响应结果确定目标组件的状态。
本发明实施例所提供的组件测试装置，通过对目标组件的组件类型进行获取，进而发送与目标组件的组件类型相对应的测试指令至目标设备，实现了根据不同类型的组件，自动发送相应的测试指令至目标设备，测试过程不需要人工干预，解决了现有技术中无法对应用程序进行自动化测试的问题，进而达到了提高测试效率的效果。
针对目标组件的类型不同，第二获取单元20、发送单元30、第三获取单元40和第一确定单元50分别通过不同的结构组成来实行对目标组件状态的测试，其中，第二获取单元20、发送单元30、第三获取单元40和第一确定单元50的具体结构组成在如图13和图14中示出。
图13是根据本发明又一实施例的组件测试装置的示意图，如图13所示，对于目标组件包括以下至少之一的情况：待测试应用程序的静态组件中的活动组件、广播接收器组件和服务器组件以及待测试应用程序的动态组件中未通过系统类本地广播管理器注册的广播接收器组件，第二获取单元20主要包括第一获取子单元201，发送单元主要包括第一发送子单元301，第三获取单元40主要包括第二获取子单元401，第一确定单元50主要包括第一判断子单元501和第一确定子单元502，其中：
第一获取子单元201用于获取测试指令中的空消息指令。
第一发送子单元301用于发送空消息指令至目标设备。
第二获取子单元401用于获取目标设备的日志输出。
第一判断子单元501用于判断日志输出中的任一日志记录是否同时包括目标包名和预设标识，其中，目标包名为应用程序的包名；第一确定子单元502用于在第一判断子单元判断出日志输出中的任一日志记录同时包括目标包名和预设标识的情况下，确定目标组件处于预设标识对应的状态。
其中，可以以预设标识“hasdied”表示目标组件对应的待测试应用程序出现闪退，则在获取到的日志记录中同时包括该待测试应用程序的包名和预设标识“hasdied”的情况下，则可以确定待测试应用程序出现闪退。可以以预设标识“Forcefinishactivity”表示目标组件对应的待测试应用程序弹出异常退出确认框，则在获取到的日志记录中同时包括该待测试应用程序的包名和预设标识“Forcefinishactivity”的情况下，则可以确定待测试应用程序弹出异常退出确认框。比如某一条日志记录为“I/ActivityManager(1113):Processcom.tencent.mobileqq:MSF(pid3506)hasdied”，其中，该日志记录包括的应用程序包名和预设标识分别为“com.tencent.mobileqq”、“hasdied”，对于此种情况，可以确定名称为“mobileqq”的应用程序出现闪退。又如某一条日志记录为“W/ActivityManager(62):Forcefinishingactivitycom.tencent.qqlive/.activity.VideoListActivity”，其中，该日志记录包括的应用程序包名和预设标识分别为“com.tencent.qqlive”、“Forcefinishactivity”，对于此种情况，可以确定名称为“qqlive””的应用程序弹出异常退出确定框。
图14是根据本发明又一实施例的组件测试装置的示意图，如图14所示，对于目标组件包括待测试应用程序的静态组件中的内容提供者组件的情况，第二获取单元20主要包括第三获取子单元202，发送单元主要包括第二发送子单元302，第三获取单元40主要包括第四获取子单元402，第一确定单元50主要包括第二判断子单元503和第二确定子单元504，其中：
第三获取子单元202用于获取测试指令中的访问路径查询指令。
第二发送子单元302用于发送访问路径查询指令至目标设备的内容接收接口(即，ContentResolver接口)。
第四获取子单元402用于获取内容接收接口对访问路径查询指令的查询响应.
第二判断子单元503用于判断查询响应是否表示查询失败；第二确定子单元504用于在第二判断子单元判断出查询响应表示查询失败的情况下，确定目标组件处于安全状态。
对于ContentProvider组件，通过ContentResolver接口执行URI查询返回的结果字符串判定应用程序是否存在数据泄漏或目录遍历风险。
若查询失败说明不存在数据泄漏，并且不存在目录遍历风险，目标组件处于安全状态；否则存在数据泄漏，第三方应用程序可以通过该目标组件读取私有数据，其中，如果查询结果为本地IP地址，比如127.0.0.1localhost，则说明存在目录遍历风险，第三方应用程序可以通过该目标组件遍历应用程序的目录。
通过对目标组件的是否处于安全状态的确定，实现了通过判断目标组件是否存在安全风险，来判断待测试应用程序是否出现异常行为，该异常行为包括APP崩溃、挂起、数据泄漏和目录遍历等。
其中，可以通过adb的shell命令来发送空消息指令或访问路径查询指令至目标设备，上述目标组件的具体类型和定义与空消息指令或访问路径查询指令的对应关系在上表1中示出。
图15是根据本发明又一实施例的组件测试装置的示意图，如图15所示，与上述实施例中示出的组件测试装置相比，本发明实施例所提供的测试装置还包括解压缩单元60、反编译单元70和第二确定单元80，其中：
解压缩单元60用于解压缩待测试应用程序的安装文件，得到解压缩文件，具体地，待测试应用程序的安装文件是APK文件，该APK文件是一个压缩包文档，可以通过7z.exe进行解压缩，解压缩后的文件夹中含有待测试应用程序的配置文档(即，AndroidManifest.xml二进制文档)和对待测试应用程序的源代码进行编译得到的二进制文件(即，classes.dex)等文件，其中，AndroidManifest.xml是待测试应用程序的核心配置文档，定义了待测试应用程序的大部分组件的详细信息。
反编译单元70用于反编译解压缩文件，得到反编译文档，具体地，如图16所示，主要是利用转换子单元701将配置文档转换为xml文档(即，步骤S7041)，以及利用反编译子单元702将二进制文件反编译为java源文件(即，步骤S7042)，其中，可以通过java程序AXMLPrinter2.jar将AndroidManifest.xml二进制文档转换为可视化的XML文档；classes.dex是app源代码编译转换后的二进制文件，可以通过dex2jar，jad.exe等序可反编译生成java源码。
第二确定单元80用于根据反编译文档确定目标组件，具体地，如图16所示，对于将配置文档转换为xml文档的情况，通过第三确定子单元801根据xml文档确定待测试应用程序的静态组件中的目标组件，对于将二进制文件反编译为java源文件的情况，通过第四确定子单元802根据java源文件确定待测试应用程序的动态组件中的目标组件。
其中，对于静态组件包括以下至少之一的情况：活动组件、广播接收器组件和服务器组件，第三确定子单元801主要通过图17中示出的结构来执行根据xml文档确定待测试应用程序的静态组件中的目标组件，如图17所示，第三确定子单元801主要包括第一读取模块8011和第一判断模块8012，其中：
第一读取模块8011用于读取xml文档，并解析xml文档的根节点，得到多个静态组件及每个静态组件的属性，第一判断模块8012用于通过判断子模块A1、判断子模块B1、判断子模块C1和判断子模块D1判断第一静态组件是否为目标组件，其中，第一静态组件为多个静态组件中的任一组件，对xml文档的根节点进行解析还可以得到待测试应用程序的包名，具体解析方式可以采用现有技术中的任意一种解析方式，此处不再介绍。
判断子模块A1用于判断第一静态组件的属性中是否包括开放属性，开放属性是指exported属性，其中，在判断出第一静态组件的属性中包括开放属性的情况下，调用判断子模块B1，在判断出第一静态组件的属性中不包括开放属性的情况下，调用判断子模块C1。
判断子模块B1用于判断开放属性的属性值是否为假，即，判断exported是否等于false，其中，在判断出开放属性的属性值为假的情况下，确定第一静态组件为非目标组件，在判断出开放属性的属性值为真的情况下，调用判断子模块D1。
判断子模块C1用于判断第一静态组件的属性中是否包括消息过滤器标签，消息过滤器标签是指intent-filter标签，其中，在判断出第一静态组件的属性中包括消息过滤器标签的情况下，执行判断子模块D1，在判断出第一静态组件的属性中不包括消息过滤器标签的情况下，确定第一静态组件为非目标组件。
判断子模块D1用于判断第一静态组件的属性中是否包括权限属性，权限属性是指permission属性(非系统权限且添加签名级别保护的自定义权限，包括readpermission和writepermission)，其中，在判断出第一静态组件的属性中包括权限属性的情况下，确定第一静态组件为非目标组件，在判断出第一静态组件的属性中不包括权限属性的情况下，确定第一静态组件为目标组件。
对于静态组件为内容提供者组件的情况，第三确定子单元801主要通过图18中示出的结构来执行根据xml文档确定待测试应用程序的静态组件中的目标组件，如图18所示，第三确定子单元801主要包括第二读取模块8013和第二判断模块8014，其中：
第二读取模块8013用于读取xml文档，并解析xml文档的根节点，得到多个静态组件及每个静态组件的属性，第二判断模块8014用于通过判断子模块A2、判断子模块B2、判断子模块C2、判断子模块D2、判断子模块E和判断子模块F判断第二静态组件是否为目标组件，其中，第二静态组件为多个静态组件中的任一组件，对xml文档的根节点进行解析还可以得到待测试应用程序的包名，具体解析方式可以采用现有技术中的任意一种解析方式，此处不再介绍。
判断子模块A2用于判断第二静态组件的属性中是否包括开放属性，开放属性是指exported属性，其中，在判断出第二静态组件的属性中包括开放属性的情况下调用判断子模块B2，在判断出第二静态组件的属性中不包括开放属性的情况下，调用判断子模块C2。
判断子模块B2用于判断开放属性的属性值是否为假，即，判断exported是否等于false，其中，在判断出开放属性的属性值为假的情况下，确定第二静态组件为非目标组件，在判断出开放属性的属性值为真的情况下，调用判断子模块D2。
判断子模块C2用于判断第二静态组件的属性中最小软件开发工具包版本值(即，最小SDK版本，minSDKVersion属性)和目标软件开发工具包版本值(即，targetSDKVersion属性)是否均大于或等于预设值，在本发明实施例中，预设值为安卓系统4.0版本，对应的版本值为17，其中，在判断出第二静态组件的属性中最小软件开发工具包版本值和目标软件开发工具包版本值均大于或等于预设值的情况下，确定第二静态组件为非目标组件，反之，调用判断子模块E。
判断子模块D2用于判断第二静态组件的属性中是否包括权限属性，权限属性是指permission属性(非系统权限且添加签名级别保护的自定义权限，包括readpermission和writepermission)，其中，在判断出第二静态组件的属性中包括权限属性的情况下，确定第二静态组件为非目标组件，在判断出第二静态组件的属性中不包括权限属性的情况下，确定第二静态组件为目标组件。
判断子模块E用于判断第二静态组件的属性中是否包括权限属性，权限属性是指permission属性(非系统权限且添加签名级别保护的自定义权限，包括readpermission和writepermission)，其中，在判断出第二静态组件的属性中包括权限属性的情况下，确定第二静态组件为非目标组件，在判断出第二静态组件的属性中不包括权限属性的情况下，调用判断子模块F。
判断子模块F用于判断第二静态组件的属性中是否存在权限为经过签名级别保护的子路径标签(即，path标签)，即，在判断出第二静态组件的属性中不包括权限属性的情况下，进一步判断第二静态组件的属性中是否存在子路径标签，并且子路径标签的权限(即，path-permission)已经过签名级别保护，其中，在判断出第二静态组件的属性中存在权限为经过签名级别保护的子路径标签的情况下，确定第二静态组件为非目标组件，在判断出第二静态组件的属性中不存在权限为经过签名级别保护的子路径标签的情况下，确定第二静态组件为目标组件。
对于动态组件包括未通过系统类本地广播管理器注册的广播接收器组件的情况，第四确定子单元802主要通过图19中示出的结构来执行根据java源文件确定待测试应用程序动态组件中的目标组件，如图19所示，第四确定子单元802主要包括第三读取模块8021和第三判断模块8022，其中：
第三读取模块8021用于读取java源文件的文本内容，得到多个动态组件及每个动态组件的属性。
第三判断模块8022用于通过第一判断子模块80221和确定子模块80222判断第一动态组件是否为目标组件，其中，第一动态组件为多个动态组件中的任一组件：
第一判断子模块80221用于判断第一动态组件的属性中是否包括消息过滤器标签，消息过滤器标签是指intent-filter标签，判断第一动态组件的属性中是否包括非系统预定义的动作标签，动作标签是指action标签，以及判断第一动态组件是否通过未添加权限校验的注册接收(RegisiterReceiver)接口动态注册，即，判断第一动态组件是否通过注册接收(RegisiterReceiver)接口动态注册广播，并且所通过的注册接收接口是未权限校验的接口，其中，权限校验是指permision校验，意思是非系统权限且添加签名级别保护的权限。
确定子模块80222用于在第一判断子模块80221判断出第一动态组件的属性中包括消息过滤器标签、第一动态组件的属性中包括非系统预定义的动作标签、以及第一动态组件通过未添加权限校验的注册接收接口动态注册的情况下，确定第一动态组件为目标组件。
从以上的描述中，可以看出，本发明采用静态和动态相结合的方式实现，通过归纳Androidapp四类组件暴露的完整规则，静态分析AndroidManifest.xml文档和反编译的源码确定app中哪些组件对外暴露的目标组件，对于app的Activity、Service和BroadcastReceiver暴露组件，自动发送异常Intent触发其响应，并通过系统日志信息自动判定app是否出现异常；对于暴露的ContentProvider组件，审查源码查找可用的ContentURI，并通过ContentResolver接口查询关联数据，输入畸形的ContentURI判定是否存在目录遍历安全风险。相比现有检测方案，本发明实施例所提供的测试方法具有以下几点优势：1、测试过程不需人工干预，自动化完成；2、组件暴露的检查规则更完备准确；3、实现自动化Intent模拟发送和异常识别；4、检测结果不存在误报。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的组件测试装置，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
Claims (16)
1.一种组件测试方法，其特征在于，包括：
获取待测试应用程序中的目标组件的组件类型，其中，所述目标组件为允许被第三方应用程序访问的组件；
获取与所述组件类型对应的测试指令；
发送所述测试指令至安装有所述待测试应用程序的目标设备；
获取所述目标设备对所述测试指令的响应结果；以及
根据所述响应结果确定所述目标组件的状态。
2.根据权利要求1所述的组件测试方法，其特征在于，所述目标组件包括以下至少之一：所述待测试应用程序的静态组件中的活动组件、广播接收器组件和服务器组件以及所述待测试应用程序的动态组件中未通过系统类本地广播管理器注册的广播接收器组件，其中，
获取与所述组件类型对应的测试指令包括：获取所述测试指令中的空消息指令；
发送所述测试指令至目标设备包括：发送所述空消息指令至所述目标设备；
获取所述目标设备对所述测试指令的响应结果包括：获取所述目标设备的日志输出；
根据所述响应结果确定所述目标组件的状态包括：判断所述日志输出中的任一日志记录是否同时包括目标包名和预设标识，其中，所述目标包名为所述应用程序的包名；以及在判断出所述日志输出中的任一日志记录同时包括所述目标包名和所述预设标识的情况下，确定所述目标组件处于所述预设标识对应的状态。
3.根据权利要求1所述的组件测试方法，其特征在于，所述目标组件包括所述待测试应用程序的静态组件中的内容提供者组件，其中，
获取与所述组件类型对应的测试指令包括：获取所述测试指令中的访问路径查询指令；
发送所述测试指令至目标设备包括：发送所述访问路径查询指令至所述目标设备的内容接收接口；
获取所述目标设备对所述测试指令的响应结果包括：获取所述内容接收接口对所述访问路径查询指令的查询响应；
根据所述响应结果确定所述目标组件的状态包括：判断所述查询响应是否表示查询失败；以及在判断出所述查询响应表示查询失败的情况下，确定所述目标组件处于安全状态。
4.根据权利要求1所述的组件测试方法，其特征在于，在获取待测试应用程序中的目标组件的组件类型之前，所述组件测试方法还包括通过以下方式确定所述目标组件：
解压缩所述待测试应用程序的安装文件，得到解压缩文件；
反编译所述解压缩文件，得到反编译文档；以及
根据所述反编译文档确定所述目标组件。
5.根据权利要求4所述的组件测试方法，其特征在于，所述解压缩文件包括所述待测试应用程序的配置文档和对所述待测试应用程序的源代码进行编译得到的二进制文件，其中，
反编译所述解压缩文件，得到反编译文档包括：将所述配置文档转换为xml文档；以及将所述二进制文件反编译为java源文件；
根据所述反编译文档确定所述目标组件包括：根据所述xml文档确定所述待测试应用程序的静态组件中的所述目标组件；以及根据所述java源文件确定所述待测试应用程序的动态组件中的所述目标组件。
6.根据权利要求5所述的组件测试方法，其特征在于，所述静态组件包括以下至少之一：活动组件、广播接收器组件和服务器组件，其中，根据所述xml文档确定所述待测试应用程序的静态组件中的所述目标组件包括：
读取所述xml文档，并解析所述xml文档的根节点，得到多个所述静态组件及每个所述静态组件的属性；以及
采用以下方式判断第一静态组件是否为所述目标组件，其中，所述第一静态组件为多个所述静态组件中的任一组件：
A1判断：判断所述第一静态组件的属性中是否包括开放属性，其中，在判断出所述第一静态组件的属性中包括所述开放属性的情况下，执行B1判断，在判断出所述第一静态组件的属性中不包括所述开放属性的情况下，执行C1判断；
所述B1判断：判断所述开放属性的属性值是否为假，其中，在判断出所述开放属性的属性值为假的情况下，确定所述第一静态组件为非目标组件，在判断出所述开放属性的属性值为真的情况下，执行D1判断；
所述C1判断：判断所述第一静态组件的属性中是否包括消息过滤器标签，其中，在判断出所述第一静态组件的属性中包括所述消息过滤器标签的情况下，执行所述D1判断，在判断出所述第一静态组件的属性中不包括所述消息过滤器标签的情况下，确定所述第一静态组件为所述非目标组件；
所述D1判断：判断所述第一静态组件的属性中是否包括权限属性，其中，在判断出所述第一静态组件的属性中包括所述权限属性的情况下，确定所述第一静态组件为所述非目标组件，在判断出所述第一静态组件的属性中不包括所述权限属性的情况下，确定所述第一静态组件为所述目标组件。
7.根据权利要求5所述的组件测试方法，其特征在于，所述静态组件包括内容提供者组件，根据所述xml文档确定所述待测试应用程序的静态组件中的所述目标组件包括：
读取所述xml文档，并解析所述xml文档的根节点，得到多个所述静态组件及每个所述静态组件的属性；以及
采用以下方式判断第二静态组件是否为所述目标组件，其中，所述第二静态组件为多个所述静态组件中的任一组件：
A2判断：判断所述第二静态组件的属性中是否包括开放属性，其中，在判断出所述第二静态组件的属性中包括所述开放属性的情况下，执行B2判断，在判断出所述第二静态组件的属性中不包括所述开放属性的情况下，执行C2判断；
所述B2判断：判断所述开放属性的属性值是否为假，其中，在判断出所述开放属性的属性值为假的情况下，确定所述第二静态组件为非目标组件，在判断出所述开放属性的属性值为真的情况下，执行D2判断；
所述C2判断：判断所述第二静态组件的属性中最小软件开发工具包版本值和目标软件开发工具包版本值是否均大于或等于预设值，其中，在判断出所述第二静态组件的属性中所述最小软件开发工具包版本值和所述目标软件开发工具包版本值均大于或等于所述预设值的情况下，确定所述第二静态组件为所述非目标组件，反之，执行E判断；
所述D2判断：判断所述第二静态组件的属性中是否包括权限属性，其中，在判断出所述第二静态组件的属性中包括所述权限属性的情况下，确定所述第二静态组件为所述非目标组件，在判断出所述第二静态组件的属性中不包括所述权限属性的情况下，确定所述第二静态组件为所述目标组件；
所述E判断：判断所述第二静态组件的属性中是否包括权限属性，其中，在判断出所述第二静态组件的属性中包括所述权限属性的情况下，确定所述第二静态组件为所述非目标组件，在判断出所述第二静态组件的属性中不包括所述权限属性的情况下，执行F判断；
所述F判断：判断所述第二静态组件的属性中是否存在权限为经过签名级别保护的子路径标签，其中，在判断出所述第二静态组件的属性中存在权限为经过签名级别保护的所述子路径标签的情况下，确定所述第二静态组件为所述非目标组件，在判断出所述第二静态组件的属性中不存在权限为经过签名级别保护的所述子路径标签的情况下，确定所述第二静态组件为所述目标组件。
8.根据权利要求5所述的组件测试方法，其特征在于，所述动态组件包括未通过系统类本地广播管理器注册的广播接收器组件，根据所述java源文件确定所述待测试应用程序动态组件中的所述目标组件包括：
读取所述java源文件的文本内容，得到多个所述动态组件及每个所述动态组件的属性；以及
采用以下方式确定第一动态组件是否为所述目标组件，其中，所述第一动态组件为多个所述动态组件中的任一组件：
判断所述第一动态组件的属性中是否包括消息过滤器标签、所述第一动态组件的属性中是否包括非系统预定义的动作标签、以及所述第一动态组件是否通过未添加权限校验的注册接收接口动态注册；
在判断出所述第一动态组件的属性中包括所述消息过滤器标签、所述第一动态组件的属性中包括非系统预定义的所述动作标签、以及所述第一动态组件通过未添加权限校验的所述注册接收接口动态注册的情况下，确定所述第一动态组件为所述目标组件。
9.一种组件测试装置，其特征在于，包括：
第一获取单元，用于获取待测试应用程序中的目标组件的组件类型，其中，所述目标组件为允许被第三方应用程序访问的组件；
第二获取单元，用于获取与所述组件类型对应的测试指令；
发送单元，用于发送所述测试指令至安装有所述待测试应用程序的目标设备；
第三获取单元，用于获取所述目标设备对所述测试指令的响应结果；以及
第一确定单元，用于根据所述响应结果确定所述目标组件的状态。
10.根据权利要求9所述的组件测试装置，其特征在于，所述目标组件包括以下至少之一：所述待测试应用程序的静态组件中的活动组件、广播接收器组件和服务器组件以及所述待测试应用程序的动态组件中未通过系统类本地广播管理器注册的广播接收器组件，其中，
所述第二获取单元包括：第一获取子单元，用于获取所述测试指令中的空消息指令；
所述发送单元包括：第一发送子单元，用于发送所述空消息指令至所述目标设备；
所述第三获取单元包括：第二获取子单元，用于获取所述目标设备的日志输出；
所述第一确定单元包括：第一判断子单元，用于判断所述日志输出中的任一日志记录是否同时包括目标包名和预设标识，其中，所述目标包名为所述应用程序的包名；以及第一确定子单元，用于在所述第一判断子单元判断出所述日志输出中的任一日志记录同时包括所述目标包名和所述预设标识的情况下，确定所述目标组件处于所述预设标识对应的状态。
11.根据权利要求9所述的组件测试装置，其特征在于，所述目标组件包括所述待测试应用程序的静态组件中的内容提供者组件，其中，
所述第二获取单元包括：第三获取子单元，用于获取所述测试指令中的访问路径查询指令；
所述发送单元包括：第二发送子单元，用于发送所述访问路径查询指令至所述目标设备的内容接收接口；
所述第三获取单元包括：第四获取子单元，用于获取所述内容接收接口对所述访问路径查询指令的查询响应；
所述第一确定单元包括：第二判断子单元，用于判断所述查询响应是否表示查询失败；以及第二确定子单元，用于在所述第二判断子单元判断出所述查询响应表示查询失败的情况下，确定所述目标组件处于安全状态。
12.根据权利要求9所述的组件测试装置，其特征在于，所述组件测试装置还包括：
解压缩单元，用于解压缩所述待测试应用程序的安装文件，得到解压缩文件；
反编译单元，用于反编译所述解压缩文件，得到反编译文档；以及
第二确定单元，用于根据所述反编译文档确定所述目标组件。
13.根据权利要求12所述的组件测试装置，其特征在于，所述解压缩文件包括所述待测试应用程序的配置文档和对所述待测试应用程序的源代码进行编译得到的二进制文件，其中，
所述反编译单元包括：转换子单元，用于将所述配置文档转换为xml文档；以及反编译子单元，用于将所述二进制文件反编译为java源文件；
所述第二确定单元包括：第三确定子单元，用于根据所述xml文档确定所述待测试应用程序的静态组件中的所述目标组件；以及第四确定子单元，用于根据所述java源文件确定所述待测试应用程序的动态组件中的所述目标组件。
14.根据权利要求13所述的组件测试装置，其特征在于，所述静态组件包括以下至少之一：活动组件、广播接收器组件和服务器组件，其中，所述第三确定子单元包括：
第一读取模块，用于读取所述xml文档，并解析所述xml文档的根节点，得到多个所述静态组件及每个所述静态组件的属性；以及
第一判断模块，用于通过判断子模块A1、判断子模块B1、判断子模块C1和判断子模块D1判断第一静态组件是否为所述目标组件，其中，所述第一静态组件为多个所述静态组件中的任一组件：
所述判断子模块A1，用于判断所述第一静态组件的属性中是否包括开放属性，其中，在判断出所述第一静态组件的属性中包括所述开放属性的情况下，调用所述判断子模块B1，在判断出所述第一静态组件的属性中不包括所述开放属性的情况下，调用所述判断子模块C1；
所述判断子模块B1，用于判断所述开放属性的属性值是否为假，其中，在判断出所述开放属性的属性值为假的情况下，确定所述第一静态组件为非目标组件，在判断出所述开放属性的属性值为真的情况下，调用所述判断子模块D1；
所述判断子模块C1，用于判断所述第一静态组件的属性中是否包括消息过滤器标签，其中，在判断出所述第一静态组件的属性中包括所述消息过滤器标签的情况下，执行所述判断子模块D1，在判断出所述第一静态组件的属性中不包括所述消息过滤器标签的情况下，确定所述第一静态组件为所述非目标组件；
所述判断子模块D1，用于判断所述第一静态组件的属性中是否包括权限属性，其中，在判断出所述第一静态组件的属性中包括所述权限属性的情况下，确定所述第一静态组件为所述非目标组件，在判断出所述第一静态组件的属性中不包括所述权限属性的情况下，确定所述第一静态组件为所述目标组件。
15.根据权利要求13所述的组件测试装置，其特征在于，所述静态组件包括内容提供者组件，所述第三确定子单元包括：
第二读取模块，用于读取所述xml文档，并解析所述xml文档的根节点，得到多个所述静态组件及每个所述静态组件的属性；以及
第二判断模块，用于通过判断子模块A2、判断子模块B2、判断子模块C2、判断子模块D2、判断子模块E和判断子模块F判断第二静态组件是否为所述目标组件，其中，所述第二静态组件为多个所述静态组件中的任一组件：
所述判断子模块A2，用于判断所述第二静态组件的属性中是否包括开放属性，其中，在判断出所述第二静态组件的属性中包括所述开放属性的情况下调用所述判断子模块B2，在判断出所述第二静态组件的属性中不包括所述开放属性的情况下，调用所述判断子模块C2；
所述判断子模块B2，用于判断所述开放属性的属性值是否为假，其中，在判断出所述开放属性的属性值为假的情况下，确定所述第二静态组件为非目标组件，在判断出所述开放属性的属性值为真的情况下，调用所述判断子模块D2；
所述判断子模块C2，用于判断所述第二静态组件的属性中最小软件开发工具包版本值和目标软件开发工具包版本值是否均大于或等于预设值，其中，在判断出所述第二静态组件的属性中所述最小软件开发工具包版本值和所述目标软件开发工具包版本值均大于或等于所述预设值的情况下，确定所述第二静态组件为所述非目标组件，反之，调用所述判断子模块E；
所述判断子模块D2，用于判断所述第二静态组件的属性中是否包括权限属性，其中，在判断出所述第二静态组件的属性中包括所述权限属性的情况下，确定所述第二静态组件为所述非目标组件，在判断出所述第二静态组件的属性中不包括所述权限属性的情况下，确定所述第二静态组件为所述目标组件；
所述判断子模块E，用于判断所述第二静态组件的属性中是否包括权限属性，其中，在判断出所述第二静态组件的属性中包括所述权限属性的情况下，确定所述第二静态组件为所述非目标组件，在判断出所述第二静态组件的属性中不包括所述权限属性的情况下，调用所述判断子模块F；
所述判断子模块F，用于判断所述第二静态组件的属性中是否存在权限为经过签名级别保护的子路径标签，其中，在判断出所述第二静态组件的属性中存在权限为经过签名级别保护的所述子路径标签的情况下，确定所述第二静态组件为所述非目标组件，在判断出所述第二静态组件的属性中不存在权限为经过签名级别保护的所述子路径标签的情况下，确定所述第二静态组件为所述目标组件。
16.根据权利要求13所述的组件测试装置，其特征在于，所述动态组件包括未通过系统类本地广播管理器注册的广播接收器组件，所述第四确定子单元包括：
第三读取模块，用于读取所述java源文件的文本内容，得到多个所述动态组件及每个所述动态组件的属性；以及
第三判断模块，用于通过第一判断子模块和确定子模块判断第一动态组件是否为所述目标组件，其中，所述第一动态组件为多个所述动态组件中的任一组件：
所述第一判断子模块，用于判断所述第一动态组件的属性中是否包括消息过滤器标签、所述第一动态组件的属性中是否包括非系统预定义的动作标签、以及所述第一动态组件是否通过未添加权限校验的注册接收接口动态注册；
确定子模块，用于在所述第一判断子模块判断出所述第一动态组件的属性中包括所述消息过滤器标签、所述第一动态组件的属性中包括非系统预定义的所述动作标签、以及所述第一动态组件通过未添加权限校验的所述注册接收接口动态注册的情况下，确定所述第一动态组件为所述目标组件。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410262117.7A CN105224869B (zh) | 2014-06-12 | 2014-06-12 | 组件测试方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410262117.7A CN105224869B (zh) | 2014-06-12 | 2014-06-12 | 组件测试方法和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105224869A true CN105224869A (zh) | 2016-01-06 |
| CN105224869B CN105224869B (zh) | 2019-01-08 |
Family
ID=54993831
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410262117.7A Active CN105224869B (zh) | 2014-06-12 | 2014-06-12 | 组件测试方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105224869B (zh) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107967210A (zh) * | 2017-12-04 | 2018-04-27 | 东软集团股份有限公司 | Android组件测试用例生成方法和装置 |
| CN108491327A (zh) * | 2018-03-26 | 2018-09-04 | 中南大学 | 一种安卓应用动态Receiver组件本地拒绝服务漏洞检测方法 |
| CN108694120A (zh) * | 2017-04-12 | 2018-10-23 | 北京京东尚科信息技术有限公司 | 测试服务组件的方法和装置 |
| CN108875356A (zh) * | 2018-05-29 | 2018-11-23 | 努比亚技术有限公司 | 一种数据访问方法、终端及计算机可读存储介质 |
| CN108989350A (zh) * | 2018-08-31 | 2018-12-11 | 北京梆梆安全科技有限公司 | 一种检测拒绝服务漏洞的方法、装置及设备 |
| CN109670308A (zh) * | 2018-12-06 | 2019-04-23 | 北京梆梆安全科技有限公司 | 一种Intent调用风险检测方法及装置 |
| CN109766276A (zh) * | 2018-12-29 | 2019-05-17 | Tcl通力电子（惠州）有限公司 | 开放式平台测试方法、装置、计算机可读存储介质及系统 |
| CN110377499A (zh) * | 2019-06-06 | 2019-10-25 | 北京奇安信科技有限公司 | 一种对应用程序进行测试的方法及装置 |
| CN110443043A (zh) * | 2019-07-31 | 2019-11-12 | 北京奇艺世纪科技有限公司 | 一种对安卓应用程序的漏洞检测方法以及设备 |
| CN112667491A (zh) * | 2019-10-16 | 2021-04-16 | 腾讯科技（深圳）有限公司 | 虚拟机的功能测试方法及装置 |
| CN112988607A (zh) * | 2021-05-11 | 2021-06-18 | 腾讯科技（深圳）有限公司 | 一种应用程序的组件检测方法、装置和存储介质 |
| CN113626312A (zh) * | 2021-07-15 | 2021-11-09 | 荣耀终端有限公司 | 一种测试方法、电子设备以及存储介质 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006059108A (ja) * | 2004-08-19 | 2006-03-02 | Mitsubishi Electric Corp | 情報システム開発試験支援システム |
| US20130067281A1 (en) * | 2011-09-09 | 2013-03-14 | Askey Computer Corp. | Testing system and method for handheld electronic device |
| CN103164336A (zh) * | 2013-02-22 | 2013-06-19 | 广东欧珀移动通信有限公司 | 一种移动终端上应用程序的自动化测试方法及装置 |
| CN103544100A (zh) * | 2012-07-12 | 2014-01-29 | 腾讯科技（深圳）有限公司 | 便携数据处理设备应用程序的测试方法、系统和客户端 |
-
2014
- 2014-06-12 CN CN201410262117.7A patent/CN105224869B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006059108A (ja) * | 2004-08-19 | 2006-03-02 | Mitsubishi Electric Corp | 情報システム開発試験支援システム |
| US20130067281A1 (en) * | 2011-09-09 | 2013-03-14 | Askey Computer Corp. | Testing system and method for handheld electronic device |
| CN103544100A (zh) * | 2012-07-12 | 2014-01-29 | 腾讯科技（深圳）有限公司 | 便携数据处理设备应用程序的测试方法、系统和客户端 |
| CN103164336A (zh) * | 2013-02-22 | 2013-06-19 | 广东欧珀移动通信有限公司 | 一种移动终端上应用程序的自动化测试方法及装置 |
Non-Patent Citations (2)
| Title |
|---|
| 傅建明 等: "《Android组件间通信的安全缺陷静态检测方法》", 《华中科技大学学报自然科学版》 * |
| 曾立鹍 等: "《Android系统应用程序组件安全性分析》", 《软件》 * |
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108694120A (zh) * | 2017-04-12 | 2018-10-23 | 北京京东尚科信息技术有限公司 | 测试服务组件的方法和装置 |
| CN108694120B (zh) * | 2017-04-12 | 2022-04-12 | 北京京东尚科信息技术有限公司 | 测试服务组件的方法和装置 |
| CN107967210A (zh) * | 2017-12-04 | 2018-04-27 | 东软集团股份有限公司 | Android组件测试用例生成方法和装置 |
| CN108491327A (zh) * | 2018-03-26 | 2018-09-04 | 中南大学 | 一种安卓应用动态Receiver组件本地拒绝服务漏洞检测方法 |
| CN108491327B (zh) * | 2018-03-26 | 2020-08-25 | 中南大学 | 一种安卓应用动态Receiver组件本地拒绝服务漏洞检测方法 |
| CN108875356A (zh) * | 2018-05-29 | 2018-11-23 | 努比亚技术有限公司 | 一种数据访问方法、终端及计算机可读存储介质 |
| CN108875356B (zh) * | 2018-05-29 | 2020-12-01 | 杭州滚马网络有限公司 | 一种数据访问方法、终端及计算机可读存储介质 |
| CN108989350A (zh) * | 2018-08-31 | 2018-12-11 | 北京梆梆安全科技有限公司 | 一种检测拒绝服务漏洞的方法、装置及设备 |
| CN108989350B (zh) * | 2018-08-31 | 2021-03-19 | 北京梆梆安全科技有限公司 | 一种检测拒绝服务漏洞的方法、装置及设备 |
| CN109670308A (zh) * | 2018-12-06 | 2019-04-23 | 北京梆梆安全科技有限公司 | 一种Intent调用风险检测方法及装置 |
| CN109766276A (zh) * | 2018-12-29 | 2019-05-17 | Tcl通力电子（惠州）有限公司 | 开放式平台测试方法、装置、计算机可读存储介质及系统 |
| CN109766276B (zh) * | 2018-12-29 | 2024-01-12 | 通力科技股份有限公司 | 开放式平台测试方法、装置、计算机可读存储介质及系统 |
| CN110377499A (zh) * | 2019-06-06 | 2019-10-25 | 北京奇安信科技有限公司 | 一种对应用程序进行测试的方法及装置 |
| CN110443043A (zh) * | 2019-07-31 | 2019-11-12 | 北京奇艺世纪科技有限公司 | 一种对安卓应用程序的漏洞检测方法以及设备 |
| CN112667491B (zh) * | 2019-10-16 | 2023-09-26 | 腾讯科技（深圳）有限公司 | 虚拟机的功能测试方法及装置 |
| CN112667491A (zh) * | 2019-10-16 | 2021-04-16 | 腾讯科技（深圳）有限公司 | 虚拟机的功能测试方法及装置 |
| CN112988607A (zh) * | 2021-05-11 | 2021-06-18 | 腾讯科技（深圳）有限公司 | 一种应用程序的组件检测方法、装置和存储介质 |
| CN113626312A (zh) * | 2021-07-15 | 2021-11-09 | 荣耀终端有限公司 | 一种测试方法、电子设备以及存储介质 |
| CN113626312B (zh) * | 2021-07-15 | 2022-12-06 | 北京荣耀终端有限公司 | 一种测试方法、电子设备以及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105224869B (zh) | 2019-01-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105224869A (zh) | 组件测试方法和装置 | |
| TWI575397B (zh) | 利用運行期代理器及動態安全分析之應用程式逐點保護技術 | |
| CN105303112B (zh) | 组件调用漏洞的检测方法及装置 | |
| CN108984389B (zh) | 一种应用程序测试方法及终端设备 | |
| CN102402479B (zh) | 用于静态分析的中间表示结构 | |
| CN104517054A (zh) | 一种检测恶意apk的方法、装置、客户端和服务器 | |
| CN104537308A (zh) | 提供应用安全审计功能的系统及方法 | |
| CN105426310A (zh) | 一种检测目标进程的性能的方法和装置 | |
| Karim et al. | Mining android apps to recommend permissions | |
| KR20110128632A (ko) | 스마트폰 응용프로그램의 악성행위 탐지 방법 및 장치 | |
| CN105095753A (zh) | 广播安全检测方法、装置 | |
| CN109818972B (zh) | 一种工业控制系统信息安全管理方法、装置及电子设备 | |
| CN114398673A (zh) | 应用程序的合规检测方法、装置、存储介质与电子设备 | |
| CN102446253A (zh) | 一种网页木马检测方法及系统 | |
| CN112632547A (zh) | 一种数据处理方法和相关装置 | |
| Kang et al. | Astraea: Towards an effective and usable application permission system for SDN | |
| CN107798244A (zh) | 一种检测远程代码执行漏洞的方法及装置 | |
| CN113434217B (zh) | 漏洞扫描方法、装置、计算机设备及介质 | |
| CN114880667A (zh) | 一种脚本检测方法及装置 | |
| CN107632912A (zh) | 一种windows系统下的内存诊断测试方法 | |
| Pei et al. | ASCAA: API‐level security certification of android applications | |
| CN109714371B (zh) | 一种工控网络安全检测系统 | |
| CN105320601A (zh) | 一种用于应用程序的测试方法及装置 | |
| CN112583891A (zh) | 接口文档获取方法、装置和服务器 | |
| CN106897622A (zh) | 验证应用漏洞的方法和装置 |
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 | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20210923 Address after: 518000 Tencent Building, No. 1 High-tech Zone, Nanshan District, Shenzhen City, Guangdong Province, 35 Floors Patentee after: TENCENT TECHNOLOGY (SHENZHEN) Co.,Ltd. Patentee after: TENCENT CLOUD COMPUTING (BEIJING) Co.,Ltd. Address before: 2, 518000, East 403 room, SEG science and Technology Park, Zhenxing Road, Shenzhen, Guangdong, Futian District Patentee before: TENCENT TECHNOLOGY (SHENZHEN) Co.,Ltd. |
|
| TR01 | Transfer of patent right |