CN106294149A - 一种检测Android应用程序组件通信漏洞的方法 - Google Patents
一种检测Android应用程序组件通信漏洞的方法 Download PDFInfo
- Publication number
- CN106294149A CN106294149A CN201610647400.0A CN201610647400A CN106294149A CN 106294149 A CN106294149 A CN 106294149A CN 201610647400 A CN201610647400 A CN 201610647400A CN 106294149 A CN106294149 A CN 106294149A
- Authority
- CN
- China
- Prior art keywords
- assembly
- test
- intent
- function
- android
- 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.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
- G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明是一种检测Android应用程序组件通信漏洞的方法,属于计算机测试领域;包括:首先定制ROM并刷入测试机;然后检测某个待测应用程序中的暴露组件信息;根据每个暴露组件的Action和Category信息,同时结合Android推荐的Extras的key与value构造测试数据;写入Intent中进行第一次Fuzz测试,检测每个暴露组件的通信漏洞,同时记录系统日志;测试完后分析所有日志信息,提取出真实的Extras详细信息,根据真实Extras的key和value信息,再次为该待测应用程序重新构造测试数据,进行第二次Fuzz测试;通过分析第二次测试返回的数据和日志信息,生成检测报告;优点在于:属于动态方法无需对Android应用程序进行反编译,能够直接给出漏洞攻击的结果;通过两次的Fuzz测试,构造针对性数据,提高测试效果。
Description
技术领域
本发明涉及计算机测试技术领域,具体是一种检测Android(安卓系统)应用程序组件通信漏洞的方法。
背景技术
随着互联网和经济的发展,移动设备越来越普及,随之各种各样的移动应用也越来越丰富。由于Android应用开发门槛较低,开发人员对移动安全没有足够的重视,以及Google Play对应用没有采取严格的安全审核等一系列原因,导致恶意应用越来越多。不仅Android用户面临前所未有的安全风险,Android应用开发者也面临着很大的挑战。Android应用程序组件通信是个非常薄弱的环节,比较容易被恶意应用和利用。
目前关于Android应用程序组件通信漏洞的研究有一部分是通过静态分析的方法来实现。静态分析的方法是:利用逆向工程与源代码分析,对源代码进行静态的审计,来研究应用组件间通信存在的安全漏洞。例如ComDroid是通过Dedexer工具将应用程序进行逆向处理,并利用静态分析方法,分析可能存在的应用组件通信漏洞。
静态分析方法虽然能够分析可能存在的安全漏洞,但是对于特定应用的实际攻击测试却不够深入,不能够直接给出被攻击时出现的结果。且目前很多的应用程序都会做加固和混淆,更重要的是很多组件通信漏洞只能在特定的环境下才会表现出来,所以利用静态方法分析Android应用程序组件通信漏洞局限性很大。
除了静态分析方法,目前也有一些动态的研究。Intent Fuzzer工具就是其中的代表,但是该工具只能实现对于Service和Broadcast Receiver的自动化检测,不能实现自动化检测Activity。而且该工具只能发送空消息,没有日志输出和分析。虽然JarJarBinks是针对Intent Fuzzer的改进,可以构造随机的数据进行Fuzz测试,但是不能够针对特定的应用构造数据,只能够根据Android推荐的Extras项进行测试,并且测试过程不能实现完全自动化,需要人工干预。
现有的动态方法,虽然能够给出一些攻击结果,但是多数不能够构建数据或者只能够根据Android推荐的Extras的key和value信息构造数据,不具有针对性。
综上,现有的静态和动态监测方法还存在不能够完全实现自动化,需要人工干预,没有日志分析,不能够自动提取出漏洞详情,并且测试效率低下的缺点。
发明内容
本发明针对现有技术的不足之处,利用定制ROM结合动态Fuzz的方法进行检测,解决了现有静态方法和动态方法的不足,可以直接给出被攻击时出现的结果,并且能够针对性的构造数据,对应用程序进行组件通信的漏洞检测,具体是一种检测Android应用程序组件通信漏洞的方法。
一种检测Android应用程序组件通信漏洞的方法,具体步骤包括:
步骤一:定制ROM后将ROM刷入测试机;
定制ROM具体为:修改Android源码Framework层的相关函数,将Extras的key和value绑定应用程序包名输出到日志中;
相关函数包括Framework层Intent类和Activity类中的getIntent函数、getExtra函数、getStringExtra函数、getBooleanExtra函数、getCharExtra函数和putExtra函数等;
步骤二、针对用户要检测的某个Android应用程序,在测试机上进行自动安装和启动;
具体为:利用ADB工具安装APK程序到指定的Android设备,开启与Android端的Socket连接;并进行初始化工作,包括创建漏洞数据库和获取APK包名(Package Name)。
漏洞数据库记载了常见的错误、错误描述信息和错误的解决办法等。
步骤三、检测待测应用程序中组件暴露的风险,并记录暴露组件的详细信息;
暴露组件的定义为:待测应用程序中某个组件的配置信息中,组件exported属性值为True或者该组件的配置中包含Intent-filter标签,则定义该组件为暴露组件;
组件类型包括:Activity、Service和Broadcast Receiver;
每个组件的配置信息均包括:组件名、组件exported属性值、Action和Category等信息;
步骤四、针对每个暴露组件,根据该暴露组件配置信息中的Action和Category信息,同时结合Android推荐的Extras的key与value构造测试数据;
步骤五、将构造好的测试数据写入Intent中,对该暴露组件进行Fuzz测试,检测暴露组件的通信漏洞,同时记录系统日志;
写入Intent具体为:构造完当前暴露组件的测试数据后,利用Intent的putExtra函数将Android推荐的Extras的key与value数据加入到Intent中,利用setAction函数将Action信息加入Intent,利用addCategory函数将Category信息加入Intent;
将测试数据写入Intent后,利用ComponentName类和Intent类的setComponent函数将待测应用程序包名(Package Name)和待测暴露组件的信息写入Intent,调用startActivityiForResult(Intent)函数、startService(Intent)函数和sendBroadcast(Intent)函数,对每个暴露组件进行Fuzz测试,并利用系统日志记录该暴露组件的运行状态和返回的数据。
步骤六、依次对下一个暴露组件重复步骤四和步骤五进行测试,直至测完待测应用程序的所有暴露组件;
步骤七、分析测试完该待测应用程序的所有日志信息,提取出该待测应用程序真实的Extras详细信息;
Extras详细信息包括Extras的key、value、数据类型信息和具体的触发函数等。
步骤八、根据真实Extras的key和value信息,结合每个暴露组件配置信息中的Action和Category信息,为该待测应用程序重新构造测试数据,并再次进行测试和记录系统日志;
步骤九、通过分析第二次测试返回的数据和日志信息,生成检测报告;
对日志分析过程为:通过应用程序的PID(进程号)过滤出属于该待测应用程序的日志信息,通过关键字“Exception”“Error”等提取出错误信息,然后与漏洞数据库中的数据进行匹配,从而得到包括风险结果和漏洞检测结果的检测报告;
检测报告具体为:暴露组件可能出现的风险、漏洞的描述、漏洞的详情和解决办法等。
与现有技术相比,本发明的优势在于:
(1)一种检测Android应用程序组件通信漏洞的方法,在Android应用程序运行时检测漏洞,可以直接给出漏洞详情,相比静态方法有了很大改进。
(2)一种检测Android应用程序组件通信漏洞的方法,通过定制ROM和两次的Fuzz测试,构造针对性的测试数据,大幅度的提高测试效果,相比现有的动态和静态方法都有比较大的改进。
(3)一种检测Android应用程序组件通信漏洞的方法,完全实现了自动化测试,并且利用构建漏洞数据库实现了漏洞详情自动提取的功能,并且包含了动态的任务调度,可以同时开启多个测试任务,大大提高了测试效率。
(4)一种检测Android应用程序组件通信漏洞的方法,属于动态方法无需对Android应用程序进行反编译,而且能够同时用于测试原生和非原生Android应用程序,提高了方法的应用场景。
(5)一种检测Android应用程序组件通信漏洞的方法,对于多数漏洞,能够给出详情、描述和解决办法等信息,便于使用者快速找到漏洞并修复。
(6)一种检测Android应用程序组件通信漏洞的方法,可以实现漏洞重现功能,利用定制ROM记录下漏洞触发时Intent所携带的数据,便于漏洞重现。
附图说明
图1是本发明检测Android应用程序组件通信漏洞所用测试机的框架图;
图2是本发明一种检测Android应用程序组件通信漏洞方法的流程图。
具体实施方式
下面将结合附图和具体实施例对本发明作进一步的详细说明。
本发明一种检测Android应用程序组件通信漏洞的方法,利用动态的方法获取Android应用程序组件和配置信息,然后根据每个Android应用程序构造针对性的测试数据,增加构造数据的准确性;利用定制ROM、两次数据构造、两次Fuzz测试、自动化检测和LOG日志分析等手段,改善现有动态方法的测试效果;能够在Android应用程序动态运行时给出漏洞攻击的直接结果,并且整个过程能够完全实现自动化,支持多线程和动态的任务调度,提高了测试效率。
两次Fuzz测试是指,第一次利用Android推荐的Extras的key和value键值构建测试数据,进行Fuzz测试;然后根据第一次日志的内容提取出真实的Extras信息,再次针对该应用程序构建针对性的测试数据,进行第二次Fuzz测试;
如图2所示,一种检测Android应用程序组件通信漏洞的方法,具体步骤如下:
步骤一:定制ROM后将ROM刷入测试机;
定制ROM具体为:通过修改Android源码Framework层的相关函数,将Extras的key和value绑定应用程序包名输出到日志中。
相关函数包括Framework层Intent类和Activity类中的getIntent函数、getExtra函数、getStringExtra函数、getBooleanExtra函数、getCharExtra函数和putExtra函数等;
步骤二、针对用户要检测的某个Android应用程序,在测试机上进行自动安装和启动;
如图1所示,测试机包括电脑端和至少一个Android端;
电脑端包括Socket Server端、APK管理模块、任务调度模块、LOG记录模块、Extras提取模块、漏洞分析模块和漏洞数据库模块;主要实现的功能包括APK的安装与卸载管理、记录测试日志、测试任务调度、日志处理生成最终测试报告等;
Android端包括Socket Client端,组件信息管理模块、测试数据构造模块和Fuzz测试模块;主要实现的功能包括:获取Android应用程序组件信息、分析暴露组件、构造测试数据、调用暴露组件进行Fuzz测试、记录组件返回数据等。
具体为:首先,电脑端根据测试任务和Android设备的状态,发送命令并利用ADB工具安装APK程序到指定的Android设备,然后,电脑端发送命令开启与Android端的Socket连接;并进行其他一些初始化工作,包括创建漏洞数据库,利用Android SDK提供的AAPT工具获取到APK的包名(Package Name)等。
漏洞数据库记载了常见的错误、错误描述信息和错误的解决办法等。
步骤三、检测待测应用程序中组件暴露的风险,并记录暴露组件的详细信息;
暴露组件的定义为:检测待测应用程序的每个组件中exported属性,如果某个组件exported属性值为True或者该组件配置中包含Intent-filter标签,则判断该组件为暴露组件;
具体为:Android端通过调用Android系统提供的PackageManager的getPackageManager,以及APK的包名(Package Name)等API方法,获得该应用程序的所有组件,包括Activity、Service和Broadcast Receiver等;
每个组件的配置信息均包括:组件名、组件exported属性值、Action和Category信息等;某些组件的配置还包括Intent-filter标签;每个组件的exported属性为True或者False;
如果一个组件的配置信息中exported属性为True或者该组件配置中包含Intent-filter标签,则定义该组件为暴露组件,可以被其他应用程序调用,存在安全风险。
步骤四、针对每个暴露组件,根据该暴露组件配置信息中的Action和Category值,同时结合Android推荐的Extras的key和value信息构造该暴露组件的测试数据;
查询Android推荐的Extras的key和value信息,根据携带的数据类型构造相应的数据,包含各种类型的数据,比如整形要包括负数、正数、大整形、小整形等类型,尽可能包括一些边界值。构造数据最理想的情况是构造很少的数据却能产生非常好的结果,目标是在尽量少的测试数据中,包含各种类型的数据。本发明构造数据的思想将枚举和随机有机的结合在一起,利用枚举类型和随机数据的方法尽可能的覆盖更多的测试点;
步骤五、将构造好的测试数据写入Intent中,对该暴露组件进行Fuzz测试,检测暴露组件的通信漏洞,同时记录系统日志;
写入Intent具体为:构造完当前暴露组件的测试数据后,利用Intent的putExtra函数将Android推荐的Extras的key与value数据加入到Intent中,利用setAction函数将Action信息加入Intent,利用addCategory函数将Category信息加入Intent;
将数据写入Intent后,利用ComponentName类和Intent类的setComponent函数将待测应用程序包名(Package Name)和待测暴露组件的信息写入Intent,调用startActivityiForResult(Intent)函数、startService(Intent)函数和sendBroadcast(Intent)函数,对每个暴露组件进行Fuzz测试,并利用系统日志记录组件运行状态和返回的数据。
步骤六、依次对下一个暴露组件重复步骤四和步骤五进行测试,直至测完待测应用程序的所有暴露组件;
在进行测试同时,电脑端开启日志监控程序,记录测试过程中Android系统的详细日志信息;日志监控程序主要是利用Android SDK自带的ADB工具,将日志信息写入本地文件中。
步骤七、分析测试完所有暴露组件的日志信息,提取出该待测应用程序真实的Extras详细信息。
通过对日志文件进行分析,根据设定的Extras格式提取出Extras详细信息,包括Extras的key、value、数据类型和具体触发的函数等。
步骤八、根据真实的Extras的key和value信息,结合每个暴露组件配置信息中的Action和Category信息,为该待测应用程序重新构造测试数据,并再次进行测试和记录系统日志;
针对每个暴露组件,根据该暴露组件配置信息中的Action和Category信息,同时结合真实Extras的key和value信息构造该暴露组件的数据;将所有暴露组件的数据构造后,利用putExtras()、setAction()、addCategory()构造相应的Intent;
然后调用startActivityiForResult(Intent)函数、startService(Intent)函数和sendBroadcast(Intent)等方法,利用写入好的Intent测试当前暴露组件,并记录该暴露组件返回的信息,循环测试,直到所有的暴露组件都测试完成。
两次构造数据的区别在于:第一次根据Android推荐的Extras的key和value信息构造测试数据,而第二次是根据应用程序真实的Extras的key和value信息构造测试数据,更加有针对性,测试效果更好。
步骤九、测试完成后通过分析第二次测试返回的数据和日志信息,生成检测报告;
日志详细的分析过程包括:通过应用程序的PID(进程号)过滤出属于测试应用程序的日志信息,其中PID可以通过Android动态调用API的方式获得;通过关键字“Exception”“Error”等提取出错误信息,然后与漏洞数据库中的数据进行匹配,从而得到漏洞详情、描述和解决办法等详细信息。
检测报告包括风险的结果和漏洞检测的结果;具体为:暴露组件可能出现的风险、漏洞的描述、漏洞的详情和常规解决办法。
漏洞信息的分析共有两个方面:第一是通过分析日志内容,判断是否有信息泄露和程序崩溃等其他错误发生,比如出现空指针异常引起的拒绝服务等错误;第二是根据目标组件返回的数据信息,判断是否有隐私数据泄露。
Claims (5)
1.一种检测Android应用程序组件通信漏洞的方法,其特征在于,具体步骤如下:
步骤一:定制ROM后将ROM刷入测试机;
定制ROM具体为:修改Android源码Framework层的相关函数,将Extras的key和value绑定应用程序包名输出到日志中;
步骤二、针对用户要检测的某个Android应用程序,在测试机上进行自动安装和启动;
步骤三、检测待测应用程序中组件暴露的风险,并记录暴露组件的详细信息;
暴露组件的定义为:待测应用程序中某个组件的配置信息中,组件exported属性值为True或者该组件的配置中包含Intent-filter标签,则定义该组件为暴露组件;
步骤四、针对每个暴露组件,根据该暴露组件配置信息中的Action和Category信息,同时结合Android推荐的Extras的key与value构造测试数据;
步骤五、将构造好的测试数据写入Intent中,对该暴露组件进行Fuzz测试,检测暴露组件的通信漏洞,同时记录系统日志;
写入Intent具体为:构造完当前暴露组件的测试数据后,利用Intent的putExtra函数将Android推荐的Extras的key与value数据加入到Intent中,利用setAction函数将Action信息加入Intent,利用addCategory函数将Category信息加入Intent;
将测试数据写入Intent后,利用ComponentName类和Intent类的setComponent函数将待测应用程序包名(Package Name)和待测暴露组件的信息写入Intent,调用startActivityiForResult(Intent)函数、startService(Intent)函数和sendBroadcast(Intent)函数,对每个暴露组件进行Fuzz测试,并利用系统日志记录该暴露组件的运行状态和返回的数据;
步骤六、依次对下一个暴露组件重复步骤四和步骤五进行测试,直至测完待测应用程序的所有暴露组件;
步骤七、分析测试完该待测应用程序的所有日志信息,提取出该待测应用程序真实的Extras详细信息;
Extras详细信息包括:Extras的key、value、数据类型信息和具体的触发函数;
步骤八、根据真实Extras的key和value信息,结合每个暴露组件配置信息中的Action和Category信息,为该待测应用程序重新构造测试数据,并再次进行测试和记录系统日志;
步骤九、通过分析第二次测试返回的数据和日志信息,生成检测报告。
2.如权利要求1所述的一种检测Android应用程序组件通信漏洞的方法,其特征在于,步骤一中所述的相关函数包括Framework层Intent类和Activity类中的getIntent函数、getExtra函数、getStringExtra函数、getBooleanExtra函数、getCharExtra函数和putExtra函数。
3.如权利要求1所述的一种检测Android应用程序组件通信漏洞的方法,其特征在于,所述的步骤二具体为:利用ADB工具安装APK程序到指定的Android设备,开启与Android端的Socket连接;并进行初始化工作,包括创建漏洞数据库和获取APK包名(Package Name);
漏洞数据库记载了常见的错误、错误描述信息和错误的解决办法。
4.如权利要求1所述的一种检测Android应用程序组件通信漏洞的方法,其特征在于,步骤三中所述的组件类型,包括:Activity、Service和Broadcast Receiver;
每个组件的配置信息均包括:组件名、组件exported属性值、Action和Category;某些组件的配置信息还包括Intent-filter标签。
5.如权利要求1所述的一种检测Android应用程序组件通信漏洞的方法,其特征在于,所述的步骤九中,对日志分析过程为:通过应用程序的进程号过滤出属于该待测应用程序的日志信息,通过关键字“Exception”“Error”提取出错误信息,然后与漏洞数据库中的数据进行匹配,从而得到包括风险结果和漏洞检测结果的检测报告;
检测报告具体为:暴露组件可能出现的风险、漏洞的描述、漏洞的详情和解决办法等。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610647400.0A CN106294149A (zh) | 2016-08-09 | 2016-08-09 | 一种检测Android应用程序组件通信漏洞的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610647400.0A CN106294149A (zh) | 2016-08-09 | 2016-08-09 | 一种检测Android应用程序组件通信漏洞的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN106294149A true CN106294149A (zh) | 2017-01-04 |
Family
ID=57667375
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610647400.0A Pending CN106294149A (zh) | 2016-08-09 | 2016-08-09 | 一种检测Android应用程序组件通信漏洞的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106294149A (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108491327A (zh) * | 2018-03-26 | 2018-09-04 | 中南大学 | 一种安卓应用动态Receiver组件本地拒绝服务漏洞检测方法 |
CN108629184A (zh) * | 2018-05-18 | 2018-10-09 | 北京智游网安科技有限公司 | 一种ios用的sdk安全检测方法 |
CN109508547A (zh) * | 2018-11-16 | 2019-03-22 | 北京城市网邻信息技术有限公司 | 一种应用程序漏洞的定位方法、装置、存储介质及终端 |
CN110008128A (zh) * | 2019-04-11 | 2019-07-12 | 广东工业大学 | 一种Android应用组件劫持漏洞检测方法、系统及相关装置 |
CN111428238A (zh) * | 2020-03-17 | 2020-07-17 | 成都国信安信息产业基地有限公司 | 一种基于安卓组件拒绝服务测试方法、检测终端及介质 |
CN111783092A (zh) * | 2020-06-22 | 2020-10-16 | 湖南大学 | 面向安卓应用程序间通信机制的恶意攻击检测方法及系统 |
CN111913826A (zh) * | 2020-08-18 | 2020-11-10 | 公安部第三研究所 | 一种Android系统漏洞检测的流程控制装置、方法以及存储介质 |
CN112783513A (zh) * | 2021-03-18 | 2021-05-11 | 中国工商银行股份有限公司 | 一种代码风险检查方法、装置及设备 |
CN114792006A (zh) * | 2022-03-29 | 2022-07-26 | 西安电子科技大学 | 基于lstm的安卓跨应用程序共谋安全分析方法及系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120167054A1 (en) * | 2009-10-30 | 2012-06-28 | International Business Machines Corporation | Collecting Program Runtime Information |
CN103984900A (zh) * | 2014-05-19 | 2014-08-13 | 南京赛宁信息技术有限公司 | Android应用漏洞检测方法及系统 |
CN103996007A (zh) * | 2014-05-29 | 2014-08-20 | 诸葛建伟 | Android应用权限泄露漏洞的测试方法及系统 |
CN104537309A (zh) * | 2015-01-23 | 2015-04-22 | 北京奇虎科技有限公司 | 应用程序漏洞检测方法、装置及服务器 |
CN105303112A (zh) * | 2014-06-24 | 2016-02-03 | 腾讯科技(深圳)有限公司 | 组件调用漏洞的检测方法及装置 |
-
2016
- 2016-08-09 CN CN201610647400.0A patent/CN106294149A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120167054A1 (en) * | 2009-10-30 | 2012-06-28 | International Business Machines Corporation | Collecting Program Runtime Information |
CN103984900A (zh) * | 2014-05-19 | 2014-08-13 | 南京赛宁信息技术有限公司 | Android应用漏洞检测方法及系统 |
CN103996007A (zh) * | 2014-05-29 | 2014-08-20 | 诸葛建伟 | Android应用权限泄露漏洞的测试方法及系统 |
CN105303112A (zh) * | 2014-06-24 | 2016-02-03 | 腾讯科技(深圳)有限公司 | 组件调用漏洞的检测方法及装置 |
CN104537309A (zh) * | 2015-01-23 | 2015-04-22 | 北京奇虎科技有限公司 | 应用程序漏洞检测方法、装置及服务器 |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108491327B (zh) * | 2018-03-26 | 2020-08-25 | 中南大学 | 一种安卓应用动态Receiver组件本地拒绝服务漏洞检测方法 |
CN108491327A (zh) * | 2018-03-26 | 2018-09-04 | 中南大学 | 一种安卓应用动态Receiver组件本地拒绝服务漏洞检测方法 |
CN108629184A (zh) * | 2018-05-18 | 2018-10-09 | 北京智游网安科技有限公司 | 一种ios用的sdk安全检测方法 |
CN109508547A (zh) * | 2018-11-16 | 2019-03-22 | 北京城市网邻信息技术有限公司 | 一种应用程序漏洞的定位方法、装置、存储介质及终端 |
CN110008128A (zh) * | 2019-04-11 | 2019-07-12 | 广东工业大学 | 一种Android应用组件劫持漏洞检测方法、系统及相关装置 |
CN111428238B (zh) * | 2020-03-17 | 2023-11-07 | 成都国信安信息产业基地有限公司 | 一种基于安卓组件拒绝服务测试方法、检测终端及介质 |
CN111428238A (zh) * | 2020-03-17 | 2020-07-17 | 成都国信安信息产业基地有限公司 | 一种基于安卓组件拒绝服务测试方法、检测终端及介质 |
CN111783092A (zh) * | 2020-06-22 | 2020-10-16 | 湖南大学 | 面向安卓应用程序间通信机制的恶意攻击检测方法及系统 |
CN111783092B (zh) * | 2020-06-22 | 2023-08-22 | 湖南大学 | 面向安卓应用程序间通信机制的恶意攻击检测方法及系统 |
CN111913826A (zh) * | 2020-08-18 | 2020-11-10 | 公安部第三研究所 | 一种Android系统漏洞检测的流程控制装置、方法以及存储介质 |
CN112783513A (zh) * | 2021-03-18 | 2021-05-11 | 中国工商银行股份有限公司 | 一种代码风险检查方法、装置及设备 |
CN112783513B (zh) * | 2021-03-18 | 2024-02-27 | 中国工商银行股份有限公司 | 一种代码风险检查方法、装置及设备 |
CN114792006A (zh) * | 2022-03-29 | 2022-07-26 | 西安电子科技大学 | 基于lstm的安卓跨应用程序共谋安全分析方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106294149A (zh) | 一种检测Android应用程序组件通信漏洞的方法 | |
CN103577324B (zh) | 移动应用中隐私信息泄露的静态检测方法 | |
Laghari et al. | Fine-tuning spectrum based fault localisation with frequent method item sets | |
US20130117855A1 (en) | Apparatus for automatically inspecting security of applications and method thereof | |
CN106570399B (zh) | 一种跨App组件间隐私泄露的检测方法 | |
CN105956474A (zh) | Android平台软件异常行为检测系统 | |
CN111835756B (zh) | App隐私合规检测方法、装置、计算机设备及存储介质 | |
Kang et al. | A secure-coding and vulnerability check system based on smart-fuzzing and exploit | |
Karim et al. | Mining android apps to recommend permissions | |
Li et al. | Androct: ten years of app call traces in android | |
He et al. | An empirical study of log analysis at Microsoft | |
Panda et al. | A Slice‐Based Change Impact Analysis for Regression Test Case Prioritization of Object‐Oriented Programs | |
Li et al. | Open source software security vulnerability detection based on dynamic behavior features | |
Autili et al. | Software engineering techniques for statically analyzing mobile apps: research trends, characteristics, and potential for industrial adoption | |
Pirch et al. | Tagvet: Vetting malware tags using explainable machine learning | |
Rong et al. | How is logging practice implemented in open source software projects? a preliminary exploration | |
Hao et al. | Constructing benchmarks for supporting explainable evaluations of static application security testing tools | |
Zheng et al. | Locating minimal fault interaction in combinatorial testing | |
Wongwiwatchai et al. | Comprehensive detection of vulnerable personal information leaks in android applications | |
CN108427882B (zh) | 基于行为特征抽取的安卓软件动态分析检测法 | |
Alenezi et al. | Modularity measurement and evolution in object-oriented open-source projects | |
Zhang et al. | Quality assurance technologies of big data applications: A systematic literature review | |
CN111428238B (zh) | 一种基于安卓组件拒绝服务测试方法、检测终端及介质 | |
Motan et al. | Android app testing: A model for generating automated lifecycle tests | |
CN110321130A (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 | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20170104 |
|
RJ01 | Rejection of invention patent application after publication |