CN116775050A - 一种识别应用程序中sdk的方法、终端及服务器 - Google Patents

Abstract

一种识别应用程序中SDK的方法、终端及服务器，涉及电子技术领域，可以克服目标应用程序的包名混淆以及包结构扁平化带来的影响，提升识别出目标应用程序中包含的SDK的准确性，该方法包括：从目标应用程序的安装包中获取目标应用程序的代码文件；根据代码文件中类文件的路径关系，确定目标应用程序中包含的基础单元，以及各个基础单元对应的类文件；根据各个基础单元对应的类文件之间的依赖关系，建立基础单元之间的关联关系；根据基础单元之间的关联关系确定目标应用程序中包含的SDK；其中关联关系形成闭合环的多个基础单元属于一个SDK。

Description

一种识别应用程序中SDK的方法、终端及服务器

技术领域

本申请涉及电子技术领域，尤其涉及一种识别应用程序中SDK的方法、终端及服务器。

背景技术

随着移动互联网的快速发展，终端上能够安装各式各样的应用程序，为用户提供丰富的功能。应用开发者为了提高开发效率、降低成本，可以集成第三方应用开发者开发的软件开发工具包(Software Development Kit，SDK)，例如开源的第三方SDK。随着第三方SDK被大规模引用，也引入了一定的风险因素，例如隐私泄露、安全漏洞等。

应用程序中集成的SDK一般会以包的形式存在于应用程序的代码中。因此，可以通过检测应用程序的代码中的包名或者包的结构来确定应用程序中可能包含的SDK，也称为潜在SDK。然而，一些第三方应用开发者会采用一定的对抗分析技术来规避该检测方法。例如，将SDK的包名随意转换为无规律、不易读、熵值低的字符串，即混淆SDK的包名。或者，将SDK中的子包随意放置到应用程序的根目录或者其他包下，使得SDK的包结构扁平化，破坏了正常的包结构。这样，如果仍然采用上述检测方法，可能无法检测出应用程序的代码中潜在的SDK。

发明内容

本申请提供的一种识别应用程序中SDK的方法、终端及服务器，可以克服目标应用程序的包名混淆以及包结构扁平化带来的影响，提升识别出目标应用程序中包含的SDK的准确性。

为了实现上述目的，本申请实施例提供了以下技术方案：

第一方面、提供一种识别应用程序中SDK的方法，该方法包括：从目标应用程序的安装包中获取目标应用程序的代码文件；根据目标应用程序的代码文件中类文件的路径关系，确定目标应用程序中包含的基础单元，以及各个基础单元对应的类文件；根据各个基础单元对应的类文件之间的依赖关系，建立基础单元之间的关联关系；根据基础单元之间的关联关系确定目标应用程序中包含的SDK；其中关联关系形成闭合环的多个基础单元属于一个SDK。

综上可见，本申请实施例先根据目标应用程序中类文件的路径关系构建基础单元，并根据基础单元对应的类文件之间的依赖关系确定基础单元的关联关系，根据基础单元的关联关系来识别SDK的。由于本申请实施例提供的SDK识别方法不再依赖目标应用程序中包的包名或包的结构特征，因此能够克服目标应用程序的包名混淆以及包结构扁平化带来的影响，准确识别出目标应用程序中包含的SDK。

另外，本申请实施例中是确定关联关系形成闭合环的多个基础单元属于同一个SDK，能够避免一些恶意SDK单方向继承或调用其他SDK被误识别为同一个SDK，即未识别出该恶意SDK，或者可能低估该恶意SDK敏感行为的风险性的情况发生。由此可见，本申请实施例提供的SDK识别方法能够更加准确识别出不同的SDK，提升风险提示的可靠性。

一种可能的实现方式中，根据目标应用程序的代码文件中类文件的路径关系，确定目标应用程序中包含的基础单元，以及各个基础单元对应的类文件，包括：根据目标应用程序的代码文件中类文件的路径关系，确定根目录下包括一个或多个类文件的包为基础单元，基础单元对应的类文件为基础单元根目录下的全部类文件。

需要强调的是，基础单元对应的类文件不包括基础单元的子包中的类文件。

一般认为，同属于一个包的类文件为同一时间段开发的，而同一时间段开发的类文件被认为属于同一个SDK。可以理解的，开发者一般集中时间开发某个SDK功能，因此当类文件属于同一个时间段时，认为该类文件极大概率属于同一个SDK。需要说明的是，这里类文件的开发时间并不是指该类文件实际被创建的时间，而是采用一定分析方法分析出类文件之间的时序关系。其中分析方法包括这里通过类文件的路径关系进行分析，以及下文中从类文件的依赖关系进行分析。

综上，本申请实施例中确定根目录包括类文件的包为基础单元，并以基础单元为单位构建关联环，相较于以类文件为单位构建关联环，该方法能够避免代码文件中类文件的依赖关系过于繁多而造成关联环更加复杂。可见，本申请实施例确定合适的基础单元用于构建关联环，在保证SDK识别准确性的基础上，还提升了识别的效率。

一种可能的实现方式中，基础单元对应的类文件之间的依赖关系，为根据各个类文件中类与类之间的依赖关系确定的，类与类之间的依赖关系包括继承关系、调用关系、参数引用关系、以及返回关系中的一项或多项。

其中，代码文件中的类文件包含了目标应用程序的业务执行逻辑，其中包含了类文件中类与类的依赖关系。类与类的依赖关系包括但不限于继承关系、调用关系、参数引用关系、以及返回关系等。其中，类与类的调用关系、参数引用关系以及返回关系可以通过类与方法的关系(如参数引用关系、返回关系)，方法与方法之间的关系(如调用关系)间接确定的。由此可见，本申请实施例提供更多的依赖关系，有利于建立更多类与类之间的依赖关系，克服了单纯依靠类与类之间的直接依赖关系建立基础单元之间关联关系的不足，有利于提供SDK的识别的准确率。

一种可能的实现方式中，在根据基础单元之间的关联关系确定目标应用程序中包含的SDK之后，该方法还包括：根据每个SDK包含的类文件，识别出每个SDK调用的敏感API，并生成每个SDK的安全提示；其中敏感API用于获取敏感数据。

也就是说，以SDK为单位，对SDK对应的代码文件进行分析，识别出SDK的敏感行为，例如调用敏感API，执行敏感的广播行为等。其中，敏感API是用于获取敏感数据，例如获取终端的定位、连接到网络、访问终端中的相册等。并对识别出的各个SDK的敏感行为进行自然语言表达，形成SDK的风险报告(也称为安全提示)，用于呈现给用户，以便用户决定是否安装该应用程序，或者是否在安装该应用程序后是否更改针对该应用程序的隐私类系统设置等。

一种可能的实现方式中，该方法还包括：从目标应用程序的安装包中还获取目标应用程序的配置文件；根据目标应用程序的配置文件，从目标应用程序的代码文件中识别出第一类的类文件和第二类的类文件；根据目标应用程序的代码文件中类文件的路径关系，确定目标应用程序中包含的基础单元，以及各个基础单元对应的类文件，具体为：根据目标应用程序的代码文件中第二类的类文件的路径关系，确定目标应用程序中包含的基础单元，以及各个基础单元对应的第二类的类文件。

可以理解的，目标应用程序中大致包括两种来源的程序代码，分别为应用开发者自己开发的程序代码，以及集成的第三方应用开发者提供的程序代码(通常为一个或多个SDK)。可以理解的是，一般情况下，应用开发者自己开发的程序代码的风险性较低，而第三方应用开发者提供的程序代码的风险不可控，风险较高。因此终端还可以针对两种来源的程序代码分别进行SDK识别和/或SDK中敏感行为的分析。

一种可能的实现方式中，根据目标应用程序的配置文件，从目标应用程序的代码文件中识别出第一类的类文件和第二类的类文件，包括：确定目标应用程序的配置文件中声明的类文件为第一类的类文件；确定目标应用程序的配置文件中未声明的类文件为第二类的类文件。

其中，第一类的类文件，为配置文件中声明的类文件，一般认为是应用开发者针对该目标应用程序自己开发的程序代码，这些应用开发者开发自己开发程序代码的敏感行为通常风险较低。第二类的类文件，指配置文件中未声明的类文件，一般认为是第三方服务提供商开发的SDK，这些SDK的敏感行为应该重点关注，风险较高。

可以理解的是，将风险不同的类文件划分为不同的SDK，有利于后续分开评估不同SDK的风险，有利于用户更好的了解目标应用程序中不同SDK的风险性。另外，在对风险较高的类文件识别SDK时，去除风险较低的类文件，有利于提高SDK的识别效率和准确性。

一种可能的实现方式中，在根据目标应用程序的配置文件，从目标应用程序的代码文件中识别出第一类的类文件和第二类的类文件之后，该方法还包括：将第一类的类文件确定为目标应用程序中的一个SDK。

一些实施例中，可以将第一类的类文件的集合确定为一个SDK。这个SDK对应的类文件为目标应用程序中全部的第一类的类文件。或者，在其他一些实施例中，也可以针对第一类的类文件执行与第二类的类文件相同的方法，以识别出第一类的类文件中包含的多个SDK。

第二方面、提供一种终端，包括：处理器和存储器，存储器与处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当处理器从存储器中读取计算机指令，以使得终端执行如上述方面及其中任一种可能的实现方式中所述的方法。

第三方面、提供一种装置，该装置包含在终端中，该装置具有实现上述方面及可能的实现方式中任一方法中终端行为的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括至少一个与上述功能相对应的模块或单元。例如，通信模块或单元、存储模块或单元、以及处理模块或单元等。

第四方面、提供一种计算机可读存储介质，包括计算机指令，当计算机指令在终端上运行时，使得终端执行如上述方面及其中任一种可能的实现方式中所述的方法。

第五方面、提供一种终端上的图形用户界面，所述终端具有显示屏、摄像头、存储器、以及一个或多个处理器，所述一个或多个处理器用于执行存储在所述存储器中的一个或多个计算机程序，所述图形用户界面包括所述终端执行如上述方面及其中任一种可能的实现方式中所述的方法时显示的图形用户界面。

第六方面、提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如上述方面中及其中任一种可能的实现方式中所述的方法。

第七方面、提供一种芯片系统，包括处理器，当处理器执行指令时，处理器执行如上述方面中及其中任一种可能的实现方式中所述的方法。

附图说明

图1为本申请实施例提供的一种通信系统的结构示意图；

图2A为本申请实施例提供的一种终端的结构示意图；

图2B为本申请实施例提供的又一种终端的结构示意图；

图3为本申请实施例提供的一种应用程序的结构示意图；

图4为本申请实施例提供的一种服务器的结构示意图；

图5为本申请实施例提供的一种识别应用程序中SDK的方法的流程示意图；

图6为本申请实施例提供一种确定基础单元的方法的示意图；

图7为本申请实施例提供一种识别应用程序中SDK的方法的示意图；

图8为本申请实施例提供的又一种识别应用程序中SDK的方法的流程示意图；

图9为本申请实施例提供的一种芯片系统的结构示意图。

具体实施方式

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

如图1所示，为本申请实施例提供的一种通信系统，该通信系统包括终端100和服务器200。其中，服务器200为各类终端(如移动终端)提供应用程序安装包下载服务，例如具体为应用服务器。终端100其上能够安装各式各样的应用程序，例如安装有应用商城(也称为应用市场)、浏览器等。用户可以通过终端100上的应用商城或浏览器访问服务器200，并从服务器200处下载应用程序的安装包。

在一些实施例中，可由终端100具体执行本申请实施例提供的识别应用程序中的SDK的方法。当终端从应用商城或浏览器中下载应用程序的安装包后，在终端安装该应用程序前或者在终端安装该应用程序时，终端可以识别该应用程序安装包中的SDK，并分析SDK中的敏感行为(例如获取终端的位置、访问终端的相册、连接网络等)，以提示用户安装该应用程序可能存在的风险，便于用户确定是否安装。或者，当终端安装该应用程序后，终端识别该应用程序安装包中的SDK，并分析SDK中的敏感行为，以提示用户该应用程序可能存在的风险，提示用户是否卸载该应用程序，或者是否针对该应用程序更改隐私安全相关的设置(例如禁止该应用程序获取终端的位置信息，禁止该应用程序访问终端的相册，禁止该应用程序连接Wi-Fi或蜂窝网等)。

在另一些实施例中，可由服务器200具体执行本申请实施例提供的识别应用程序中的SDK的方法。当应用开发者将开发的应用程序的安装包上传到应用服务器后，应用服务器可以对应用程序的安装包进行分析，识别出该应用程序安装包中的SDK，并分析SDK中的敏感行为的风险。当终端从应用服务器下载该应用程序时，应用服务器可以向终端推送该应用程序的风险，以便用户确定是否下载。或者，应用服务器向终端发生该应用程序安装包时，一并向终端推送该应用程序的风险，以便提示用户确定是否安装，或者提示用户是否针对该应用程序更改隐私安全相关的设置。

下面对本申请实施例提供的技术方案进行详细说明。

示例性的，本申请实施例中终端100例如可以为手机、平板电脑、个人计算机(personal computer，PC)、个人数字助理(personal digital assistant，PDA)、智能手表、上网本、可穿戴终端、增强现实技术(augmented reality，AR)设备、虚拟现实(virtualreality，VR)设备、车载设备、智慧屏、智能音响等，本申请对该终端的具体形式不做特殊限制。

请参见图2A，图2A示出了终端100的结构示意图。

终端100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

可以理解的是，本发明实施例示意的结构并不构成对终端100的具体限定。在本申请另一些实施例中，终端100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。

终端100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

其中，天线1和天线2用于发射和接收电磁波信号。移动通信模块150可以提供应用在终端100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。无线通信模块160可以提供应用在终端100上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wirelessfidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigationsatellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(nearfield communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

终端100通过GPU，显示屏194，以及应用处理器等实现显示功能。

终端100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展终端100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储终端100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器中的存储器的指令，执行终端100的各种功能应用以及数据处理。

终端100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。终端100可以接收按键输入，产生与终端100的用户设置以及功能控制有关的键信号输入。

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反馈效果。不同的应用场景(例如：时间提醒，接收信息，闹钟，游戏等)也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和终端100的接触和分离。终端100可以支持1个或N个SIM卡接口，N为大于1的正整数。在一些实施例中，终端100采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在终端100中，不能和终端100分离。

终端100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明终端100的软件结构。

请参见图2B，图2B是本发明实施例的终端100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

1、应用程序层

如图2B所示，应用程序层可以包括一系列应用程序包。例如，应用商城、浏览器。当然应用程序层还可以包括日历、图库、音乐、天气、地图、视频等应用程序(图中未示出)。

其中，应用商城/浏览器，可供用户下载其他应用程序。在一些实施例中，应用商城/浏览器，可具体执行本申请实施例提供的识别应用程序中的SDK的方法。

如图3所示，为本申请实施例提供一种应用程序的结构示意图。应用商城/浏览器可以采用图3所示的应用程序的结构，具体包括预处理模块、基础单元构建模块、关联环构建模块、依赖关系模块、SDK识别模块、SDK分析模块。可以理解的是，图3仅为应用商城/浏览器的结构示意，事实上应用商城/浏览器可以包括比图3更多或更少的模块，或者组合某些模块，或者拆分某些模块等。图3中各个模块的具体功能将在下文结合具体的实施例进行详述，这里先不做说明。

2、应用程序框架层

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图2B所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。电话管理器用于提供终端100的通信功能。例如通话状态的管理(包括接通，挂断等)。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端振动，指示灯闪烁等。

3、安卓运行时(Android runtime)和系统库

如图2B所示，Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。其中，核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2D图形引擎是2D绘图的绘图引擎。

4、内核层

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

如图4所示，为本申请实施例提供的一种服务器200的结构示意图。该服务器200包括至少一个处理器210、至少一个存储器220、至少一个通信接口230。可选的，服务器200还可以包括输出设备和输入设备，图中未示出。

处理器210、存储器220和通信接口230通过总线相连接。处理器210可以是一个通用中央处理器(central processing unit，CPU)、微处理器、特定应用集成电路(application-specific integrated circuit，ASIC)，或者一个或多个用于控制本申请方案程序执行的集成电路。处理器210也可以包括多个CPU，并且处理器210可以是一个单核(single-CPU)处理器或多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路或用于处理数据(例如计算机程序指令)的处理核。

可以理解的是，当由服务器200执行本申请实施例提供的识别应用程序中SDK方法时，处理器210中也可以包括预处理模块、基础单元构建模块、关联环构建模块、依赖关系模块、SDK识别模块、SDK分析模块。服务器200中的这些模块实现的功能与图3所示的终端中相对应的模块实现的功能类似，本文将不对服务器200中各个模块的具体功能进行阐述。

存储器220可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器220可以是独立存在，通过总线与处理器210相连接。存储器220也可以和处理器210集成在一起。其中，存储器220用于存储执行本申请方案的应用程序代码，并由处理器210来控制执行。

通信接口230，可用于与其他设备或通信网络通信，如以太网，无线局域网(wireless local area networks，WLAN)等。

在本申请实施例中，服务器200可以通过该通信接口230接收来自终端100的呼叫终端200的请求，与终端100以及终端200建立信令通道，并用于交互与控制相关的信息，例如，转移网络通话的指示等。

输出设备和处理器通信，可以以多种方式来显示信息。例如，输出设备可以是液晶显示器(liquid crystal display，LCD)，发光二级管(light emitting diode，LED)显示设备，阴极射线管(cathode ray tube，CRT)显示设备，或投影仪(projector)等。输入设备和处理器通信，可以以多种方式接收用户的输入。例如，输入设备可以是鼠标、键盘、触摸屏设备或传感设备等。

以下实施例中所涉及的技术方案均可以在具有上述终端100或者服务器200中实现。下文以终端100执行本申请实施例提供的技术方案为例进行说明。如图5所示，为本申请实施例提供的一种识别应用程序中的SDK的方法的流程示意图，该方法包括：

S501、从目标应用程序的安装包中获取目标应用程序的代码文件。

终端在获取到目标应用程序的安装包后，对目标应用程序的安装包进行解压，从解压后的文件中获取目标应用程序的代码文件。以Android的应用程序包为例进行说明。例如，对APK安装包进行解压，从解压后的文件中获取.dex文件，并对.dex文件进行反汇编得到smali代码。

在一个具体的实施例中，可以由终端中的应用商城/浏览器具体执行本步骤以及之后的步骤，或者，也可以由终端中的系统服务(例如安全服务)或者第三方应用程序(例如解压应用或服务，第三方的安全应用或服务)具体执行本步骤以及之后的步骤。具体来说，当终端从应用商城/浏览器上下载目标应用程序的安装包后，应用商城/浏览器可以执行本步骤以及之后的步骤。更具体地，本步骤可由图3中的预处理模块执行。

或者，终端从应用商城/浏览器上下载目标应用程序的安装包后，当检测到终端开始安装该目标应用程序时，终端的系统服务(例如安全服务)或其他第三方应用程序(例如解压应用或服务，第三方的安全应用或服务)可以执行本步骤以及之后的步骤。可以理解的，当由终端的系统服务或其他第三方应用程序执行时，系统服务或其他第三方应用程序可以具有与图3中相似的结构。

S502、根据代码文件中类文件的路径关系，确定目标应用程序中包含的基础单元，以及各个基础单元对应的类文件。

其中，一个基础单元为一个包，且基础单元的根目录下包括一个或多个类文件。基础单元对应的类文件为基础单元的根目录下的全部类文件。需要强调的是，基础单元对应的类文件不包括基础单元的子包中的类文件。

例如，如图6所示，为代码文件中部分包的路径关系示意图。包3的根目录包括类文件a，包3确定为一个基础单元(图中用五角星标记出确定为基础单元的包)，对应类文件a。包4的根目录包括类文件b和类文件c，包4确定为一个基础单元，对应类文件b和类文件c。包5的根目录包括类文件e和包6(即包6为包5的子包)，包5确定为一个基础单元，对应类文件e。包6的根目录包括类文件d，包6确定为一个基础单元，对应类文件d。包7的根目录包括类文件f和包8(即包8为包7的子包)，包7确定为一个基础单元，对应类文件f。其中包1、包2和包8的根目录不包含类文件，不为基础单元。

一般认为，同属于一个包的类文件为同一时间段开发的，而同一时间段开发的类文件被认为属于同一个SDK。可以理解的，开发者一般集中时间开发某个SDK功能，因此当类文件属于同一个时间段时，认为该类文件极大概率属于同一个SDK。需要说明的是，这里类文件的开发时间并不是指该类文件实际被创建的时间，而是采用一定分析方法分析出类文件之间的时序关系。其中分析方法包括这里通过类文件的路径关系进行分析，以及下文中从类文件的依赖关系进行分析。

在一个具体的实施例中，当应用商城/浏览器具体执行本步骤时，更具体的，可由图3中的基础单元构建模块执行本步骤。

S503、根据基础单元对应的类文件之间的依赖关系，建立基础单元之间的关联关系。

其中，代码文件中的类文件包含了目标应用程序的业务执行逻辑，其中包含了类文件中类与类的依赖关系。类与类的依赖关系包括但不限于继承关系、调用关系、参数引用关系、以及返回关系等。其中，类与类的调用关系、参数引用关系以及返回关系可以通过类与方法的关系(如参数引用关系、返回关系)，方法与方法之间的关系(如调用关系)间接确定的。例如，类A中的方法0调用了类B中的方法1，那么类A与类B具有调用关系。又例如，类C下的方法2引用的参数中包括类D，那么类C与类D具有参数引用关系。又例如，类C的方法2的返回值的类型为类E，那么类C和类E为返回关系。由此可见，本申请实施例提供更多的依赖关系，有利于建立更多类与类之间的依赖关系，克服了单纯依靠类与类之间的直接依赖关系建立基础单元之间关联关系的不足，有利于提供SDK的识别的准确率。

可以理解的是，类与类之间的依赖关系也体现了类与类之间的开发时间的时序关系。例如，类A(即子类)继承类文件B(即父类)，那么类B的开发时间早于类A的开发时间。又例如，类A的方法调用类B的方法，那么类A的开发时间晚于类B的开发时间。又例如，类A作为类B中某个方法的参数，那么类A的开发时间早于类B的开发时间。又例如，类A作为一个返回值的类型，被类B的某个方法返回，则类A的开发时间早于类B的开发时间。需要说明的是，这里类的开发时间并不是类实际被创建的时间，而是根据类与类之间的依赖关系分析出类与类之间的时序关系。

举例说明，如下为一个基础单元中部分代码的示例：

由上面的代码可以得出表一所示的类文件中包含的依赖关系，如下：

表一

依赖关系	时序靠后的类	时序靠前的类
			继承	类Laa	类Ljava/lang/Object
参数引用	类Ljava/text/SimpleDateFormat	类Ljava/util/Data
			返回值	类Ljava/text/SimpleDateFormat	类Ljava/lang/String
调用	类Laa	类Ljava/text/SimpleDateFormat

进一步的，类文件之间的依赖关系与类文件中类与类的依赖关系一致。可以理解的是，类文件的依赖关系也体现了类文件的开发时间的时序关系。再次说明，这里类文件的开发时间并不是类文件实际被创建的时间，而是采用一定分析方法分析出类文件之间的时序关系。其中分析方法包括这里从类文件中类之间的依赖关系进行分析，以及上文通过类文件的路径关系进行分析。

再进一步地，基础单元之间的关联关系与基础单元对应的类文件的依赖关系一致。也就是说，基础单元之间的时序关系与基础单元对应的类文件的时序关系一致。可以理解的，基础单元之间的关联关系具有方向性。

为了便于描述，这里用符号“基础单元#类文件”表示基础单元与类文件的对应关系，用“类文件/基础单元A<类文件/基础单元B”用于表示类文件/基础单元A的开发时间早于类文件/基础单元B的开发时间。需要说明的是，符号本身不具有其他含义。

例如，如果基础单元1#类文件A<基础单元2#类文件B，那么基础单元1<基础单元2。也就是说，基础单元1中的类文件A的开发时间早于基础单元2中的类文件B的开发时间，那么基础单元1的开发时间早于基础单元2的开发时间。

又例如，如果基础单元1#类文件A<基础单元2#类文件B；基础单元2#类文件C<基础单元3#类文件D，那么基础单元1<基础单元2，基础单元2<基础单元3，并且能够推测出基础单元1<基础单元3。也就是说，基础单元之间的关联关系具有传递性。可以理解的，基础单元之间的关联关系具有传递性，有利于扩展更多基础单元之间的关联关系，有利于提升识别出SDK的准确性。

又例如，如果基础单元1#类文件A<基础单元2#类文件B；基础单元2#类文件C<基础单元1#类文件B，那么基础单元1<基础单元2，且基础单元2<基础单元1，能够推测出基础单元1＝基础单元2。也就是说，基础单元1和基础单元2可认为是同一个时间开发的，那么基础单元1和基础单元2可认为是属于同一个SDK。

由此可知，当多个基础单元之间的关联关系形成闭合环时，根据基础单元之间的关联关系的传递性可知，这个闭合环的多个基础单元都可以认为属于同一个SDK。

在一个具体的实施例中，当应用商城/浏览器具体执行本步骤时，更具体的，可由图3中的依赖关系模块识别出类文件中类与类的依赖关系。而后由关联环构建模块根据类文件中类与类的依赖关系确定类文件之间的依赖关系，进一步确定基础单元之间的关联关系。

S504、根据基础单元之间的关联关系确定目标应用程序中包含的SDK。其中，一个SDK包括关联关系形成闭合环的多个基础单元。

可选的，在一些实施例中，如果两个闭合环存在相同的基础单元，则这两个闭合环可以合并为一个闭合环，即确定为属于同一个SDK。

如图7所示，为目标应用程序的代码文件中部分包和类文件的结构示意图。当终端执行上述步骤S501至步骤S504之后，得到如图7中的基础单元的关联关系形成的4个闭合环，分别为关联环1，关联环2，关联环3和关联环4。其中，关联环2和关联环3存在相同的基础单元，可以合并为一个关联环。那么，可以确定出三个SDK，分别如图7所示的SDK1、SDK2和SDK3。

在一个具体的实施例中，当应用商城/浏览器具体执行本步骤时，更具体的，可由图3中的SDK识别模块根据关联环构建模块识别的基础单元之间的关联关系确定出目标应用程序中包含的SDK。

S505、根据目标应用程序中各个SDK包含的类文件，确定各个SDK的敏感行为。

步骤S504中已确定出一个SDK包括多个基础单元，每个基础单元对应一个或多个类文件，这一个或多个类文件中的代码文件被认为是相应SDK对应的代码文件。以SDK为单位，对SDK对应的代码文件进行分析，识别出SDK的敏感行为，例如调用敏感API，执行敏感的广播行为等。其中，敏感API是用于获取敏感数据，例如获取终端的定位、连接到网络、访问终端中的相册等。

如表二所示，为一些SDK中包括的敏感行为的示意。

表二

在一个具体的实施例中，当应用商城/浏览器具体执行本步骤时，更具体的，可由图3中的SDK分析模块根据SDK识别模块识别的SDK的信息，识别出各个SDK包含的敏感行为。更进一步的，SDK分析模块对识别出的各个SDK的敏感行为进行自然语言表达，形成SDK的风险报告(也称为安全提示)，用于呈现给用户，以便用户决定是否安装该应用程序，或者是否在安装该应用程序后是否更改针对该应用程序的隐私类系统设置等。

综上可见，本申请实施例先根据目标应用程序中类文件的路径关系构建基础单元，并根据基础单元对应的类文件之间的依赖关系确定基础单元的关联关系，根据基础单元的关联关系来识别SDK的。由于本申请实施例提供的SDK识别方法不再依赖目标应用程序中包的包名或包的结构特征，因此能够克服目标应用程序的包名混淆以及包结构扁平化带来的影响，准确识别出目标应用程序中包含的SDK。

另外，本申请实施例中是确定关联关系形成闭合环的多个基础单元属于同一个SDK，能够避免一些恶意SDK单方向继承或调用其他SDK被误识别为同一个SDK，即未识别出该恶意SDK，或者可能低估该恶意SDK敏感行为的风险性的情况发生。由此可见，本申请实施例提供的SDK识别方法能够更加准确识别出不同的SDK，提升风险提示的可靠性。

再有，本申请实施例中确定根目录包括类文件的包为基础单元，并以基础单元为单位构建关联环，相较于以类文件为单位构建关联环，该方法能够避免代码文件中类文件的依赖关系过于繁多而造成关联环更加复杂。可见，本申请实施例确定合适的基础单元用于构建关联环，在保证SDK识别准确性的基础上，还提升了识别的效率。

目标应用程序中大致包括两种来源的程序代码，分别为应用开发者自己开发的程序代码，以及集成的第三方应用开发者提供的程序代码(通常为一个或多个SDK)。可以理解的是，一般情况下，应用开发者自己开发的程序代码的风险性较低，而第三方应用开发者提供的程序代码的风险不可控，风险较高。因此，在又一些实施例中，终端还可以针对两种来源的程序代码分别进行SDK识别和/或SDK中敏感行为的分析。

如图8所示，为本申请实施例提供的又一种识别应用程序中SDK的方法的流程示意图，该流程包括：

S801、从目标应用程序的安装包中获取目标应用程序的代码文件和配置文件。

终端在获取到目标应用程序的安装包后，对目标应用程序的安装包进行解压，从解压后的文件中获取目标应用程序的代码文件和配置文件。

以Android的应用程序包为例进行说明。例如，对APK安装包进行解压，从解压后的文件中获取.dex文件和AndroidManifest.xml文件。其中，.dex文件为代码文件，进一步的可以对.dex文件进行反汇编得到smali代码。其中，AndroidManifest.xml文件为配置文件，包括：描述目标应用程序的各个组件，包括活动(activity)、服务(service)、广播接收者(broadcast receiver)、内容提供者(content provider)，并声明各个组件实现的类文件等。

S802、根据配置文件，从代码文件中识别出第一类的类文件和第二类的类文件。

可以理解的是，第一类的类文件，为配置文件中声明的类文件，一般认为是应用开发者针对该目标应用程序自己开发的程序代码，这些应用开发者开发自己开发程序代码的敏感行为通常风险较低。一些实施例中，可以将第一类的类文件的集合确定为一个SDK。这个SDK对应的类文件为目标应用程序中全部的第一类的类文件。或者，在其他一些实施例中，也可以针对第一类的类文件执行与第二类的类文件相同的方法，以识别出第一类的类文件中包含的多个SDK。

第二类的类文件，指配置文件中未声明的类文件，一般认为是第三方服务提供商开发的SDK，这些SDK的敏感行为应该重点关注，风险较高。

可以理解的是，将风险不同的类文件划分为不同的SDK，有利于后续分开评估不同SDK的风险，有利于用户更好的了解目标应用程序中不同SDK的风险性。另外，在对风险较高的类文件识别SDK时，去除风险较低的类文件，有利于提高SDK的识别效率和准确性。

S803、根据第二类的类文件的路径关系，确定目标应用程序中包含的基础单元，以及各个基础单元对应的第二类的类文件。

其中，一个基础单元为一个包，且基础单元的根目录下包括一个或多个第二类的类文件。基础单元对应的类文件为基础单元的根目录下的全部的第二类的类文件。需要强调的是，基础单元对应的类文件不包括基础单元的子包中的类文件。

可以理解的是，这里是针对第二类的类文件确定的基础单元，基础单元对应的类文件属于第二类的类文件。

S804、根据基础单元对应的第二类的类文件之间的依赖关系，建立基础单元之间的关联关系。

S805、根据基础单元之间的关联关系确定目标应用程序中包含的SDK。其中，一个SDK包括关联关系形成闭合环的多个基础单元。

可选的，在一些实施例中，如果两个闭合环存在相同的基础单元，则这两个闭合环可以合并为一个闭合环，即确定为属于同一个SDK。

S806、根据目标应用程序中各个SDK包含的类文件，确定各个SDK的敏感行为。

需要注意的是，这里分析的各个SDK的敏感行为可以包括两种类型的SDK，一种类型是步骤802中识别的SDK(即第一类的类文件集合形成的SDK)，另一种类型是步骤S805中识别的SDK(即由第二类的类文件分析得到的多个SDK)。一些实施例中，由于两种类型的SDK的风险性不同，可以分别分开提示两种类型SDK的风险。

步骤S801-步骤S806的其他内容请参考前文步骤S501-步骤S505中相应的内容，这里不再重复赘述。

本申请实施例还提供一种芯片系统，如图9所示，该芯片系统包括至少一个处理器1101和至少一个接口电路1102。处理器1101和接口电路1102可通过线路互联。例如，接口电路1102可用于从其它装置(例如终端100的存储器)接收信号。又例如，接口电路1102可用于向其它装置(例如处理器1101)发送信号。示例性的，接口电路1102可读取存储器中存储的指令，并将该指令发送给处理器1101。当所述指令被处理器1101执行时，可使得终端执行上述实施例中的终端100(比如，手机)执行的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种装置，该装置包含在终端或服务器中，该装置具有实现上述实施例中任一方法中终端或服务器行为的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括至少一个与上述功能相对应的模块或单元。例如，通信模块或单元、存储模块或单元、以及处理模块或单元等。

本申请实施例还提供一种计算机存储介质，包括计算机指令，当计算机指令在终端或服务器上运行时，使得终端或服务器执行如上述实施例中任一方法。

本申请实施例还提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如上述实施例中任一方法。

可以理解的是，上述终端或服务器等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明实施例的范围。

本申请实施例可以根据上述方法示例对上述终端或服务器等进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种识别应用程序中SDK的方法，其特征在于，所述方法包括：

从目标应用程序的安装包中获取所述目标应用程序的代码文件；

根据所述目标应用程序的所述代码文件中类文件的路径关系，确定所述目标应用程序中包含的基础单元，以及各个所述基础单元对应的类文件；

根据各个所述基础单元对应的类文件之间的依赖关系，建立所述基础单元之间的关联关系；

根据所述基础单元之间的关联关系确定所述目标应用程序中包含的SDK；其中关联关系形成闭合环的多个所述基础单元属于一个SDK。

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标应用程序的所述代码文件中类文件的路径关系，确定所述目标应用程序中包含的基础单元，以及各个所述基础单元对应的类文件，包括：

根据所述目标应用程序的所述代码文件中类文件的路径关系，确定根目录下包括一个或多个类文件的包为所述基础单元，所述基础单元对应的类文件为所述基础单元根目录下的全部类文件。

3.根据权利要求1或2所述的方法，其特征在于，

所述基础单元对应的类文件之间的依赖关系，为根据各个类文件中类与类之间的依赖关系确定的，所述类与类之间的依赖关系包括继承关系、调用关系、参数引用关系、以及返回关系中的一项或多项。

4.根据权利要求1-3任一项所述的方法，其特征在于，在所述根据所述基础单元之间的关联关系确定所述目标应用程序中包含的SDK之后，所述方法还包括：

根据每个SDK包含的类文件，识别出每个SDK调用的敏感API，并生成每个SDK的安全提示；其中所述敏感API用于获取敏感数据。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

从所述目标应用程序的安装包中还获取所述目标应用程序的配置文件；

根据所述目标应用程序的所述配置文件，从所述目标应用程序的所述代码文件中识别出第一类的类文件和第二类的类文件；

所述根据所述目标应用程序的所述代码文件中类文件的路径关系，确定所述目标应用程序中包含的基础单元，以及各个基础单元对应的类文件，具体为：

根据所述目标应用程序的所述代码文件中所述第二类的类文件的路径关系，确定所述目标应用程序中包含的基础单元，以及各个基础单元对应的所述第二类的类文件。

6.根据权利要求5所述的方法，其特征在于，所述根据所述目标应用程序的所述配置文件，从所述目标应用程序的所述代码文件中识别出第一类的类文件和第二类的类文件，包括：

确定所述目标应用程序的所述配置文件中声明的类文件为所述第一类的类文件；

确定所述目标应用程序的所述配置文件中未声明的类文件为所述第二类的类文件。

7.根据权利要求5或6所述的方法，其特征在于，在所述根据所述目标应用程序的所述配置文件，从所述目标应用程序的所述代码文件中识别出第一类的类文件和第二类的类文件之后，所述方法还包括：

将所述第一类的类文件确定为所述目标应用程序中的一个SDK。

8.一种终端，其特征在于，包括：处理器和存储器，所述存储器与所述处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述处理器从所述存储器中读取所述计算机指令，以使得所述终端执行如权利要求1-7中任一项所述的识别应用程序中SDK的方法。

9.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在终端上运行时，使得所述终端执行如权利要求1-7中任一项所述的识别应用程序中SDK的方法。

10.一种芯片系统，其特征在于，包括一个或多个处理器，当所述一个或多个处理器执行指令时，所述一个或多个处理器执行如权利要求1-7中任一项所述的识别应用程序中SDK的方法。