CN106778270B - 一种恶意应用程序的检测方法及系统 - Google Patents

Abstract

本发明公开了一种恶意应用程序的检测方法及系统，所述方法包括：监听到安装APK，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息；监听到系统调用表被修改，获取引起系统调用表被修改的第二bundle文件的包名；将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。本发明将OSGI服务应用于Android系统，并当监听到系统调用表被修改时，判断引起修改的bundle文件是否新安装的APK对应的bundle文件，以判定所述APK是否为恶意程序，解决了现有恶意应用程序检测方法无法及时确定新型恶意代码的特征码，以使得对于新型恶意代码处理存在滞后性。

Description

一种恶意应用程序的检测方法及系统

技术领域

本发明涉及智能终端技术领域，特别涉及一种恶意应用程序的检测方法及系统。

背景技术

随着移动终端的不断发展,移动终端的应用场景不再局限于生活娱乐,其在办公、支付和金融等领域的应用也愈发成熟。移动设备开始承载着越来越多的“附属价值”。与此同时,移动设备的迅猛发展所带来的“信息价值”使得基于Android平台的恶意代码也日益增多。早期Android平台的恶意代码大都以恶意扣费、偷跑流量等方式损害消费者利益。而现今恶意代码开始着眼于恶意推广或捆绑安装软件,以窃取用户隐私数据(如通信录)等方式谋求非法利益。然而，目前Android系统的恶意应用程序检测方法普遍是通过静态扫描特征码和校验文件签名等方式来实现恶意代码检测。但是，现有恶意应用程序检测方法无法及时确定新型恶意代码的特征码，以使得对于新型恶意代码处理存在滞后性。

因而现有技术还有待改进和提高。

发明内容

本发明要解决的技术问题在于，针对现有技术的不足，提供一种恶意应用程序的检测方法及系统，以解决现有恶意软件检测方法对于新型恶意代码处理的滞后性高的问题。

为了解决上述技术问题，本发明所采用的技术方案如下：

一种恶意应用程序的检测方法，其包括：

监听到APK安装时，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息及用于监控系统调用表修改的回调接口；

监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名；

将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。

所述恶意应用程序的检测方法，其中，所述监听到APK安装时，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息及用于监控系统调用表修改的回调接口具体包括：

监听到系统安装APK，解析所述APK并将其反编译为jar文件；

向所述jar文件内写入预设元数据以得到所述第一bundle文件，并将所述包名信息以及用于监控系统调用表修改的回调接口注册入所述第一bundle文件内。

所述恶意应用程序的检测方法，其中，所述监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名之前具体包括：

获取BundleContext接口，并通过所述BundleContext接口启动所述第一bundle文件。

所述恶意应用程序的检测方法，其中，所述将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序具体包括：

通过监控系统调用表修改的回调接口回调系统调用表被修改状态，其中，所述被修改状态为已修改和未修改；

当所述系统调用表被修改状态为已修改时，将所述第二bundle文件的包名与第一bundle文件的包名进行比较；

若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。

所述恶意应用程序的检测方法，其中，所述监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名具体包括：

将系统的当前系统调用表与预设的备份系统调用表进行比较；

当两者不同时，判定所述系统调用表被修改，并获取引起系统调用表被修改的第二bundle文件的包名。

一种恶意应用程序的检测系统，其包括：

转换模块，用于监听到APK安装时，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息及用于监控系统调用表修改的回调接口；

获取模块，用于当监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名；

判定模块，用于将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。

所述恶意应用程序的检测系统，其中，所述转换模块具体包括：

解析单元，用于监听到系统安装APK，解析所述APK并将其反编译为jar文件；

写入单元，用于向所述jar文件内写入预设元数据以得到所述第一bundle文件，并将所述包名信息以及用于监控系统调用表修改的回调接口注册入所述第一bundle文件内。

所述恶意应用程序的检测系统，其还包括：

启动模块，用于获取BundleContext接口，并通过所述BundleContext接口启动所述第一bundle文件。

所述恶意应用程序的检测系统，其中，所述判定模块具体包括：

回调单元，用于通过监控系统调用表修改的回调接口回调系统调用表被修改状态，其中，所述被修改状态为已修改和未修改；

第一比较单元，用于当所述系统调用表被修改状态为已修改时，将所述第二bundle文件的包名与第一bundle文件的包名进行比较；

判定单元，用于当两者相同时，判定所述第一bundle文件对应的APK为恶意应用程序。

所述恶意应用程序的检测系统，其中，所述获取模块具体包括：

第二比较单元，用于将系统的当前系统调用表与预设的备份系统调用表进行比较；

获取单元，用于当两者不同时，判定所述当前系统调用表被修改，并获取引起系统调用表被修改的第二bundle文件的包名。

有益效果：与现有技术相比，本发明提供了一种恶意应用程序的检测方法及系统，所述方法包括：监听到APK安装时，将所述APK转换为第一bundle文件；监听到系统调用表被修改，获取引起系统调用表被修改的第二bundle文件的包名；将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。本发明将OSGI服务应用于Android系统，并当监听到系统调用表被修改时，判断引起修改的bundle文件是否新安装的APK对应的bundle文件，以判定所述APK是否为恶意程序，解决了现有恶意应用程序检测方法无法及时确定新型恶意代码的特征码，以使得对于新型恶意代码处理存在滞后性。

附图说明

图1为本发明提供的恶意应用程序的检测方法较佳实施的流程图。

图2为本发明提供的恶意应用程序的检测控制系统的结构原理图。

具体实施方式

本发明提供一种恶意应用程序的检测方法及系统，为使本发明的目的、技术方案及效果更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，模块”、“部件”或“单元”可以混合地使用。

终端设备可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

本发明提供了一种恶意应用程序的检测方法，其应用于具有OSGI服务平台的Android系统的终端设备，所述方法通过采用OSGI服务平台内的bundle功能模块，将新安装的APK转换为bundle文件，并且当系统调用表被修改时，通过判断bundle文件而确定新安装的APK是否为恶意应用程序，实现了恶意应用程序的检测，提高了恶意应用程序检测的及时性以及准确性。

下面结合附图，通过对实施例的描述，对发明内容作进一步说明。

请参照图1，图1为本发明提供的恶意应用程序的检测方法的较佳实施例的流程图。所述方法包括：

S100、监听到APK安装时，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息及用于监控系统调用表修改的回调接口。

具体地，所述APK为AndroidPackage的缩写，其为Android安装包。所述监听到安装APK指的是监听到终端设备安装新的应用程序。所述APK包为zip压缩文件，可以用压缩包管理器打开，如，winrar。所述APK文件包括一个META-INF目录、一个res目录、一个AndroidManifest.xml文件和一个classes.dex。

所述AndroidManifest.xml是每个应用都必须定义和包含的，它描述了应用的名字、版本、权限、引用的库文件等等信息。所述META-INF目录下存放的是签名信息，用来保证APK包的完整性和系统的安全。在编译生成APK包时，对所有需打包的文件进行校验计算，并将计算结果存于META-INF目录下。当Android平台上安装APK包时，应用管理器按照对包里的文件做校验，并且当校验结果与META-INF下的内容不一致，系统拒绝安装所述APK包。这就保证了APK包里的文件不能被随意替换。所述classes.dex是java源码编译后生成的java字节码文件。所述res目录存放资源文件。所述esources.arsc是编译后的二进制资源文件。

示例性的，所述APK的生成过程可以为：首先Android项目中的清单文件Manifest、资源文件等通过Android Asset Packaging Tool工具打包生成R文件和打包的资源文件；将所述R文件和源代码以及引用的类库通过Java编译器编译成class文件和jar文件，再将class文件和jar文件由dx工具编译成dex文件，即Dalvik虚拟机可以识别的字节码；最后将打包的资源文件和dex文件最后通过APK Builder生成APK文件。

所述bundle文件是OSGI模块层定义的模块模型，其具体为一个包含元数据(关于数据的数据)的jar文件，由类文件和相关资源组成。也就是说，所述bundle文件为增加了元数据的jar包。Bundle文件中包含了java类和数据资源，所述数据资源可以是HTML文件、帮助文档以及图标等。所述bundle可以从项目中导入导出，并且能够与项目中的其他bundle共享jar文件。bundle为OSGI框架提供服务，且为OSGI服务框架中唯一需要部署的实体。当bundle开始运行时，会通过OSGI框架向框架中其他bundle提供功能和服务。在本实施例中，所述bundle文件为一个模块化的物理单元，以jar文件形式包含代码、资源和元数据，其中jar文件的边界也作为执行时逻辑模块化的封装边界。

所述OSGI框架为OSGI服务平台的组成部分，所述OSGI框架用于实现并提供OSGI功能的运行环境。所述OSGI服务平台还包括OSGI标准服务，所述OSGI定义用于执行常见任务的可重用API。所述OSGI框架和OSGI标准服务的规范由OSGI联盟管理，其中，OSGI框架在创建基于OSGI的应用时起着核心作用，其是应用的执行环境。

所述OSGI框架是依据OSGI规范定义的三个概念，其分别包括：

模块层：关注于打包和共享代码；所述模块层定义了OSGI模块的概念，并称之为一个bundle。

生命周期层：关注于提供执行时模块管理和对底层OSGI框架的访问；其定义了在OSGI框架中是如何动态安装和管理来的。生命周期层定义了bundle生命周期的操作(如安装、更新、启动、停止和卸载)。所述生命周期的操作使得可以用一种定义明确的方式动态地提供、管理和改进应用程序。

服务层：关注于模块，特别是模块内的组件间的交互和通信；所述服务层支持和促成应用编程模型。其主要涉及面向服务的发布、查找和绑定交互模式，即服务提供者将服务发布到服务注册中心，然后服务客户端通过搜索服务注册中心，查找可供使用的服务。

在本实施例中，所述监听到安装APK，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息具体包括：

S101、监听到系统安装APK，解析所述APK并将其反编译为jar文件；

S102、向所述jar文件内写入预设元数据以得到所述第一bundle文件，并将所述包名信息以及用于监控系统调用表修改的回调接口注册入所述第一bundle文件内。

具体的来说，在所述步骤S101中，所述将APK反编译为jar文件指的是将classes.dex反编译为jar文件。所述反编译为采用dex2jar工具，也就是说，通过dex2jar工具将dex格式转换到Android的Java类的格式，以实现向APK反编译为jar文件。例如，通过dex2jar xxx.APK命令，将APK反编译获取到jar文件。

在所述步骤S102中，所述预设元数据包括可读信息、bundle识别信息和代码可见性信息。所述可读信息为使用者提供该bundle的相关帮助信息，其可以包括：

Bundle-Name:作为bundle的一个缩写名；

Bundle-Description:描述bundle的功能；

Bundle-DocURL:提供有关bundle的文档；

Bundle-Category:定义了一组由逗号分隔的分类名；

Bundle-Vendor:有关bundle提供商的信息；

Bundle-ContactAddress:有关bundle提供商的信息；

Bundle-Copyright:有关bundle提供商的信息。

所述bundle识别信息为是安装到OSGI框架中bundle的唯一标识，所述唯一标识由bundle符号名称和bundle版本号两部分组成。其中，所述bundle符号名称Bundle-SymbolicName与和java中包命名方法一致，例如，采用包名作为符号名称等。所述版本号Bundle-Version为符合OSGI规范的版本号，所述版本号的格式可以为：主版本号.次版本号.微版本号.限定符。值得说明的，bundle识别信息还可以包括Bundle-ManifestVersion，用于在OSGI框架中确定在处理bundle时采用版本信息，如主板本号，次版本号等。

所述代码可见性信息用于确定代码的可见性，如代码内部可见或代码外部可见。并且所述代码可见性信息定义可以导出内部代码Export-Package和导入外部代码Import-Package。所述导出内部代码为用于与其他bundle共享而公开的、由逗号分隔的内部bundle包；所述导入外部代码为内部bundle代码需要的、来自其他bundle并由逗号分隔的一组包。

在所述步骤S102中，将所述预设元数据写入反编译得到的jar文件中，以形成bundle文件。并且在生成bundle文件后，将所述APK的包名信息写入所述bundle文件内，这样将所述bundle与APK建立一一对应的，通过bundle文件可以唯一确定一个APK包，即确定一个应用程序，进而为后续根据bundle判定恶意应用程序奠定了基础。在本实施例中，所述bundle文件中还可以注册监控系统调用表修改的回调接口，这样当系统调用表被修改时，所述bundle可以通过回调接口获取所述被修改信息，并根据所述被修改信息确定是否是其自身引起。

S200、监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名。

具体地，所述监听到系统调用表被修改指的是监听到系统的当前系统调用表与备份系统调用表不相同。所述备份系统调用表为系统启动时自动备份的系统调用表。

示例性的，所述监听到系统调用表被修改，获取引起系统调用表被修改的第二bundle文件的包名具体可以包括：

S201、将系统的当前系统调用表与预设的备份系统调用表进行比较；

S202、当两者不同时，判定所述系统调用表被修改，并获取引起系统调用表被修改的第二bundle文件的包名。

具体的来说，在所述步骤S201中，在系统启动时候自动生成系统调用表的备份，并将所述备份系统调用表默认属性设置为只读模式。这样在系统运行过程中，所述备份系统调用表只能被访问，不能被修改，保证了备份系统调用表的准确性。同时，在系统运行过程中，每间隔预定时间将所述备份系统调用表与当前系统调用表进行比较。所述比较过程具体为将备份系统调用表内的信息与当前系统调用表内的信息进行逐一比较，以确定两者之间区别的信息。在本实施例中，所述预设时间为系统预先设置的，例如，2分钟，5分钟等。

在所述步骤S202中，所述当两者不同指的备份系统调用表和当前系统调用表之间存在不同，此时判断系统调用表被修改。并通过将备份系统调用表与当前系统调用表以确定引起系统调用表被修改的第二bundle文件的包名。

在本实施例中，由于在OSGI框架中，所述bundle文件为一个功能模块，从而在将APK转换为bundle文件之后，监听到系统调用表被修改，获取引起系统调用表被修改的第二bundle文件的包名之前还可以包括一个启动bundle的过程，其具体可以为：获取BundleContext接口，并通过所述BundleContext接口启动所述第一bundle文件。

所述BundleContext接口为应用提供执行时操作OSGI框架的接口，其是指模块在框架中运行时的上下文，该上下文提供了模块与框架进行交互的接口。启动bundle时，OSGI框架创建一个与所述bundle相对应的BundleContext对象，即每个bundle对应一个BundleContext。在本实施例中，所述BundleContext对象不能在bundle之间进行传递，这样保障bundle的安全和资源的正确分配。

所述BundleContext接口为OSGI服务平台的生命周期层的核心接口。所述OSGI服务平台的生命周期层的核心接口还包括由Bundle接口和BundleActivator接口。所述Bundle接口代表一个已安装到框架中的bundle文件,并且通过所述Bundle接口可以对允许对bundle文件执行状态操作。也就是说，在OSGI框架中每个bundle文件都对应一个Bundle接口，Bundle接口是对Bundle文件的抽象。每个Bundle接口都对应一个唯一的并且在生命周期中保持不变的ID号码，所述ID号码由框架进行分配。同时，在Bundle接口中定义了bundle信息的获取方法，其可以包括：状态的获取、版本的获取、ID的获取等，还定义了Bundle的管理方法，包括：更新、卸载、启动、停止等。

在本实施例中，在Android系统中嵌入OSGI框架称为OSGIFramework。将所述OSGIFramework实现为Android系统服务Servie。其具体可以采用如下步骤如下：

H10、建立GetFramework继承自Android中的服务Service。

具体地，当所述服务建立完成后，通过Android系统中的服务管理器ServiceManager将所述服务添加进系统服务中。这样每次系统启动时随着系统服务启动起来，该GetFrameworkService服务也启动起来。

H20、在所述服务中通过FrameWorkFactory.newFrameWork()获取OSGI框架实例，并通过Framework.start()方法启动框架实例。

具体地，在Android系统中启动GetFrameworkService服务，通过Android系统binder机制，向应用层提供GetFrameworkService服务的代理(如GetFrameworkServiceProxy)，在通过该OSGI框架服务代理，就可以访问到GetFrameworkService服务中相关接口，以获取框架实例接口，而启动框架实例。

在本实施例中，所述获取BundleContext接口，并通过所述BundleContext接口启动所述第一bundle文件为在嵌入OSGI框架的Android系统中启动应用，其具体可以包括步骤如下：

M10、通过GetFrameworkService服务的GetFrameworkServiceProxy，获取OSGI框架实例。

M20、调用Framework.getBundleContext()获取BundleContext。

M30、调用BundleContext.install(String location)安装bundle文件，直至所有bundle文件安装完毕。

具体地，所述参数location是该bundle文件存放路径，也就是说，当安装成功后，返回已安装的Bundle接口的Bundle ID(Bundle Identifier)。所述Bundle ID是运行期最常用的标识符，其是由OSGI框架自动分配的一个长整型数字，在Bundle接口整个生命周期内(包括Bundle更新、卸载之后)都不会改变，甚至在OSGI框架重启后都能保留下来。BundleID是在Bundle安装过程中由OSGI框架根据Bundle安装时间的先后次序，由小到大进行分配的。可以通过Bundle接口的getBundleId()来获取当前Bundle的ID。

M40、调用安装成功返回Bundle接口的getBundleId()来获取当前Bundle接口的ID，并调用Bundle接口的getSymbolicName()和getVersion()分别获取所述bundle文件的符号名称和版本号。

M50、建立数据库存储每一个Bundle ID、bundle符号名称、bunlde版本号、Import-Package和Export-Package属性。

M60、调用BundleContext.start()启动bundle文件。

S300、将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。

具体地，所述将第二bundle文件的包名与所述第一bundle文件的包名文件进行比较指的是将所述第二bundle文件的符号名和版本号与第一bundle文件的符号名和版本号进行比较。并且当相同时，获取第一bundle文件中携带的APK的包名信息，根据所述包信息确定其对应的APK包，将所述APK包对应的应用程序判定为恶意应用程序。

示例性的，所述将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序具体可以包括：

S301、通过监控系统调用表修改的回调接口回调系统调用表被修改状态，其中，所述被修改状态为已修改和未修改；

S302、当所述系统调用表被修改状态为已修改时，将所述第二bundle文件的包名与第一bundle文件的包名进行比较；

S303、若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。

本发明还提供了一种恶意应用程序的检测系统，如图2所示，其包括：

转换模块100，用于监听到APK安装时，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息及用于监控系统调用表修改的回调接口；

获取模块200，用于当监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名；

判定模块300，用于将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。

所述恶意应用程序的检测系统，其中，所述转换模块具体包括：

解析单元，用于监听到系统安装APK，解析所述APK并将其反编译为jar文件；

写入单元，用于向所述jar文件内写入预设元数据以得到所述第一bundle文件，并将所述包名信息以及用于监控系统调用表修改的回调接口注册入所述第一bundle文件内。

所述恶意应用程序的检测系统，其还包括：

启动模块，用于获取BundleContext接口，并通过所述BundleContext接口启动所述第一bundle文件。

所述恶意应用程序的检测系统，其中，所述判定模块具体包括：

回调单元，用于通过监控系统调用表修改的回调接口回调系统调用表被修改状态，其中，所述被修改状态为已修改和未修改；

第一比较单元，用于当所述系统调用表被修改状态为已修改时，将所述第二bundle文件的包名与第一bundle文件的包名进行比较；

判定单元，用于当两者相同时，判定所述第一bundle文件对应的APK为恶意应用程序。

所述恶意应用程序的检测系统，其中，所述获取模块具体包括：

第二比较单元，用于将系统的当前系统调用表与预设的备份系统调用表进行比较；

获取单元，用于当两者不同时，判定所述当前系统调用表被修改，并获取引起系统调用表被修改的第二bundle文件的包名。

上述恶意应用程序的检测系统的各个模块在上述方法中已经详细说明，在这里就不再一一陈述。

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

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

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

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

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种恶意应用程序的检测方法，其特征在于，其包括：

监听到APK安装时，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息及用于监控系统调用表修改的回调接口；

监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名；

将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。

2.根据权利要求1所述恶意应用程序的检测方法，其特征在于，所述监听到APK安装时，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息及用于监控系统调用表修改的回调接口具体包括：

监听到系统安装APK，解析所述APK并将其反编译为jar文件；

向所述jar文件内写入预设元数据以得到所述第一bundle文件，并将所述包名信息以及用于监控系统调用表修改的回调接口注册入所述第一bundle文件内。

3.根据权利要求1所述恶意应用程序的检测方法，其特征在于，所述监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名之前具体包括：

获取BundleContext接口，并通过所述BundleContext接口启动所述第一bundle文件。

4.根据权利要求3所述恶意应用程序的检测方法，其特征在于，所述将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序具体包括：

通过监控系统调用表修改的回调接口回调系统调用表被修改状态，其中，所述被修改状态为已修改和未修改；

当所述系统调用表被修改状态为已修改时，将所述第二bundle文件的包名与第一bundle文件的包名进行比较；

若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。

5.根据权利要求1所述恶意应用程序的检测方法，其特征在于，所述监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名具体包括：

将系统的当前系统调用表与预设的备份系统调用表进行比较；

当两者不同时，判定所述系统调用表被修改，并获取引起系统调用表被修改的第二bundle文件的包名。

6.一种恶意应用程序的检测系统，其特征在于，其包括：

转换模块，用于监听到APK安装时，将所述APK转换为第一bundle文件，其中，所述第一bundle文件携带所述APK的包名信息及用于监控系统调用表修改的回调接口；

获取模块，用于当监听到系统调用表被修改时，获取引起系统调用表被修改的第二bundle文件的包名；

判定模块，用于将所述第二bundle文件的包名与所述第一bundle文件的包名进行比较，若相同，则判定所述第一bundle文件对应的APK为恶意应用程序。

7.根据权利要求6所述恶意应用程序的检测系统，其特征在于，所述转换模块具体包括：

解析单元，用于监听到系统安装APK，解析所述APK并将其反编译为jar文件；

写入单元，用于向所述jar文件内写入预设元数据以得到所述第一bundle文件，并将所述包名信息以及用于监控系统调用表修改的回调接口注册入所述第一bundle文件内。

8.根据权利要求6所述恶意应用程序的检测系统，其特征在于，其还包括：

启动模块，用于获取BundleContext接口，并通过所述BundleContext接口启动所述第一bundle文件。

9.根据权利要求8所述恶意应用程序的检测系统，其特征在于，所述判定模块具体包括：

回调单元，用于通过监控系统调用表修改的回调接口回调系统调用表被修改状态，其中，所述被修改状态为已修改和未修改；

第一比较单元，用于当所述系统调用表被修改状态为已修改时，将所述第二bundle文件的包名与第一bundle文件的包名进行比较；

判定单元，用于当两者相同时，判定所述第一bundle文件对应的APK为恶意应用程序。

10.根据权利要求6所述恶意应用程序的检测系统，其特征在于，所述获取模块具体包括：

第二比较单元，用于将系统的当前系统调用表与预设的备份系统调用表进行比较；

获取单元，用于当两者不同时，判定所述当前系统调用表被修改，并获取引起系统调用表被修改的第二bundle文件的包名。

Images