现在Android应用代码破绽扫描工具种类繁多，效果良莠不齐，这些工具有一个配合的特点，都是在应用打包完成后对应用举行解包扫描。这种扫描有异常显著的瑕玷，扫描周期较长，不能向开发者实时反馈代码中存在的平安问题，而且对于问题代码的定位需要手动搜索匹配源码，这样就更不利于开发者对问题代码举行实时的修改。Code Arbiter正是为解决上述两个问题而开发的，专门对Android Studio中的源码举行平安扫描。

1 靠山先容

为实现对Android Studio中的源码举行扫描，最利便的方式即是将扫描工具以IDE插件的形式举行事情。此时一个很自然的想法即是重新构建一个Android Studio插件，然则举行仔细的评估后会发现，这样做难度并不小：

1. 事情量大，许多知识需要学习，如IDE开放API接口、插件UI构建等，同时许多底层模块需要重新构建；
2. 插件的稳定性、检测问题的准确性上都不一定能够到达已有开源工具的效果。

因此我们转而思量在已有破绽检测插件的基础上举行扩展，以知足需求。经由调研，最终入围的两款检测插件是PMD和FindBugs，其中PMD是对Java源码举行扫描，而FindBugs则是对Java源码编译后的class文件举行扫描。思量到可扩展性及检测的准确性，最终选定了FindBugs。FindBugs是一个静态剖析工具，它检查类或者JAR文件，将字节码与一组缺陷模式举行对比来发现可能的问题，可以以自力的JAR包形式运行，也可以作为集成开发工具的插件形式存在。

扩展优化

那么，怎么扩展FindBugs呢？调研发现FindBugs插件具有着极强的可扩展性，只需要将扩展的JAR包导入FindBugs插件，重启，即可完成相关功效的扩展。安装JAR包示意图如下所示。

下面的问题是若何构建可安装的JAR包。继续调研，发现FindBugs有一款专门对平安问题举行检测的扩展插件Find Security Bugs，该插件主要用于对Web平安问题举行检测，也有少少对Android相关平安问题的检测规则。思量以下几个缘故原由，需要对该插件的源码举行重构。

1. 对Android平安问题的检测太少，只包罗外部文件使用、Webview、Broadcast使用等寥寥几项；
2. 检测的细粒度上思量不够完全，会造成大量的误报，无法知足检测精度的要求；
3. 检测问题的上报只支持英文模式，且问题展示的逻辑性不够严谨，不便于开发者举行问题排查。

基于以上三个缘故原由，我们需要对Find Security Bugs的源码举行重写、优化，通过增添检测项来检测尽可能多的平安问题，通过优化检测规则来削减检测的误报，问题展示使用中文举行形貌，同时优化问题形貌的逻辑性，使得开发者能够更易明白并修改相关问题，至此插件实现及优化的方案确定。

2 工具实现先容

FindBugs检测的是class文件，因此当待检测的源码未天生编译文件时，FindBugs会先将源码编译天生.class文件，然后对这个class文件举行剖析。FindBugs会完成对class文件的自动建模，在此模子的基础上对代码举行剖析。按照在现实编写检测代码过程中的总结，把检测的实现方式分成四种方式，下面划分举行先容。

2.1 逐行检查

逐行检查主要是针对代码中使用的一些不平安方式或参数举行检测，实在现方式是重写sawOpcode()方式，下面以Android中使用外部存储问题作为示例举行解说。

Android中获取外部存储文件夹地址的方式主要包罗下面这些方式：

getExternalCacheDir()

检测的方式即是，若是发现存在该方式的挪用，则作为一个问题举行上报，实现完整代码如下所示：

public class ExternalFileAccessDetector extends OpcodeStackDetector { private static final String ANDROID_EXTERNAL_FILE_ACCESS_TYPE = "ANDROID_EXTERNAL_FILE_ACCESS"; private BugReporter bugReporter; public ExternalFileAccessDetector(BugReporter bugReporter) { this.bugReporter = bugReporter;

该类的实现是继续OpcodeStackDetector类，是FindBugs中的一个抽象类，封装了对于获取代码特定参数的方式挪用。sawOpcode方式参数可以明白为待检测代码行的行号，通过printOpCode(seen)可以打印该代码行的详细内容。Constants.INVOKEVIRTUAL示意该行挪用类的实例方式，Constants.INVOKESTATIC示意挪用类的静态方式。getNameConstantOperand方式示意获取被挪用方式的名称，getClassConstantOperand方式示意获取挪用类的名称，getSigConstantOperand方式示意获取方式的所有参数。bugReporter.reportBug用于上报检测到的破绽信息，其中BugInstance的三个参数划分示意：检测器、破绽类型、破绽品级，其中破绽品级分为五个级别，如下表所示：

addClass、addMethod、addSourceLine用于指定该破绽所在的类、方式、行，利便讲述破绽时定位要害代码。

2.2 逐方式检查

逐方式检查首先获取待检测类的所有内容，然后对类中的方式举行逐个检查，多用于对方式体举行检测，实在现的方式主要是通过重写visitClassContext方式，下面以对Android TrustManager的空实现的检测为例举行说明。

TrustManager的空实现，主要是指对于检测Server端证书是否可信的方式checkServerTrusted，是否是空实现。下面展示问题代码，若是是空实现那么将导致客户端吸收随便证书，从而造成加密后的HTTPS新闻被中间人解密。

@Overridepublic void checkServerTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException {

检测的方式是通过遍历类中的所有方式，找到checkServerTrusted方式，对方式整体举行检测，确定其是否为空实现，部门代码如下所示：

public class WeakTrustManagerDetector implements Detector {

classContext.getJavaClass用于获取整个类的所有内容；javaClass.getMethods用于获取该类中的所有方式，以一个方式列表的形式返回；classContext.getMethodGen用于获取该方式的内容；isEmptyImplementation将方式的内容导入该函数举行检测，用于确定方式是否是空实现，该方式的代码如下所示：

private boolean isEmptyImplementation(MethodGen methodGen){ boolean invokeInst = false; boolean loadField = false; for (Iterator itIns = methodGen.getInstructionList().iterator();itIns.hasNext();) {

该方式主要用于检测方式中是否包罗方式挪用、域操作，若是没有包罗则认为是一个空实现的方式。因此该方式对于只包罗 return true/false 语句的方式体同样认为是一个空实现。

知乎的ceo是谁，玩知乎的都是一群什么人

2.3 污点剖析

数据流剖析主要用于剖析特定方式加载的参数是否能够被用户控制，即举行污点剖析。做污点剖析首先需要界说污染源（source点），污染源可以明白为能够被用户控制的输入数据，这里界说的Android污染源主要包罗用户的输入、Intent传入的数据，下面展示界说的部门污染源（source点）：

- EditText

界说好污染源后就需要确定污染的触发点（sink点），可以明白为会触发危险操作的函数。界说sink点的方式有两种，一种是直接从文件中导入，以下令注入为示例，代码如下：

public class CommandInjectionDetector extends BasicInjectionDetector { public CommandInjectionDetector(BugReporter bugReporter) { super(bugReporter);

从代码中可以清晰的看到其导入方式是继续BasicInjectionDetector类，然后再该类的组织方式中通过loadConfiguredSinks方式，导入包罗sink点的文件，下面展示该示例文件中的内容：

java/lang/Runtime.exec(Ljava/lang/String;)Ljava/lang/Process;:0

另一种是自界说导入，实在现是通过笼罩BasicInjectionDetector类中的getInjectionPoint方式，以WebView.loadurl方式为例，示例代码如下所示：

@Override

通过实例化InjectionPoint类组织新的sink点，其组织方式中的第一个参数示意该方式吸收污染数据参数的位置，如方式为webView.loadUrl(url)，其第一个参数就是new int[]{0}，其它的以此类推。

上报发现破绽的情形，则通过笼罩getPriorityFromTaintFrame方式的实现，示例代码如下所示：

@Override

通过fact.getStackValue获取检测的函数变量，若是该变量被污染（isTainted）或 变量是否被污染未知（然则是可控制变量），那么作为一其中危风险（
Priorities.NORMAL_PRIORITY）举行上报，其它的情形则上报为可忽略风险（
Priorities.IGNORE_PRIORITY）。

2.4 自界说代码检测

自界说代码检测实现的前半部门同2.2的逐方式检测类似，均是获取类的内容，然后遍历所有的方式，对方式的内容举行检测，然则在详细代码检测实现上是通过自界说剖析举行。现在自界说检测只应用到Android中内陆拒绝服务的检测。内陆拒绝服务的被触发的重要缘故原由在于对通过Intent获取的参数未举行异常捕捉，因此检测实现的方式即是检测获取参数的代码行是否被try catch包裹（这个存在误差，待改善）。对于其代码剖析，不能使用FindBugs模子举行剖析，而是使用最原始的class代码举行剖析，原始class代码的形式通过javap下令举行查看，下图展示示例代码。

对原始class文件举行剖析存在的缺陷是无法定位详细的代码行，那么在举行问题上报时无法将问题定位到代码行，因此第一步需要在原有模子的基础上对所有包罗Intent获取参数的方式的位置存储到一个Map结构中，利便后面对方式的定位，代码实现如下所示，获取方式所在的行，然后以方式名作为Key值，以代码行相关信息作为Value值，存储到Map中。

private Map<String, List<Location>> get_line_location(Method m, ClassContext classContext){

之后获取Exception包裹的局限，FindBugs中包罗对Exception的建模，因此能够通过其模子能够直接获取其局限并存储到一个列表中，代码如下所示，其中exceptionTable[i].getStartPC用于获取try catch 的起始代码行，exceptionTable[i].getEndPC用于获取try catch 的竣事代码行。

public int[] getExceptionScope(){ try {

在对代码举行逐行检查时，由于使用的是最原始class文件形式，因此需要限制其遍历的局限，限制的方式是通过代码的行号，即上图中每行代码的第一个数值。首先需要获取代码总行数的巨细，获取的方式即是剖析FindBugs建模后的第一行代码，找到要害词code-length后面的数值，即为代码的行数，剖析代码如下所示：

public int get_Code_Length(String firstLineCode){ try{

最后对代码举行逐行遍历，遍历中为防止try catch块被遍历到，使用行号来限制遍历的局限。检测代码行是否包罗通过Intent获取参数，及该行是否被try catch 包裹，若是上述两个条件均被触发，那么就作为一个问题举行上报。示例代码如下，其中get_code_line_index方式用于获取代码的行号，获取的方式是截取代码行的首字符的数值，以确定是否在代码包裹的局限内。

private void analyzeMethod(JavaClass javaClass, Method m, ClassContext classContext) throws CFGBuilderException {

3 注册打包

上面详细叙述了若何组织自己的问题检测代码，完成检测方式的誊写后，下一步就是在配置文件中对检测方式举行注册，才能使检测代码运转起来。

需要在两个文件中举行注册，第一个是findbugs.xml，注册示例如下：

<Detector class="com.h3xstream.findsecbugs.android.LocalDenialOfServiceDetector" reports="LOCAL_DENIAL_SERVICE"/>

其中Detector用于注册该检测方式的位置及其唯一标识，BugPattern用于对检测出的问题举行归类，利便展示，如此处归类到”Android平安问题”中，那么在天生讲述的时刻问题也将被归类到”Android平安问题”中。

第二个是messages.xml注册，注册示例如下，该注册主要是对该问题举行说明，包罗问题的危害及修复方式。

<Detector class="com.h3xstream.findsecbugs.android.LocalDenialOfServiceDetector"><Details>Local Denial of Service.</Details></Detector><BugPattern type="LOCAL_DENIAL_SERVICE"><ShortDescription>内陆拒绝服务</ShortDescription><LongDescription>通过Intent吸收的参数未举行异常捕捉，导致出现异常使得应用溃逃</LongDescription><Details><![CDATA[ <p> <b>危害:</b><br/> <pre> 应用溃逃无法使用，影响用户体验； 被竞争对手行使，举行点对点攻击。 </pre> </p> <p> <b>错误代码:</b><br/> <pre> bundle.getString(""); //未try/catch intent.getStringExtra(""); //未try/catch </pre> </p> <p> <b>解决方案:</b><br/> <pre> 对通过Intent吸收的参数处置时，举行严酷的异常捕捉。 try { bundle.getString(""); intent.getStringExtra("");  }catch (Exception e){} </pre> </p>]]></Details></BugPattern><BugCode abbrev="SECLDOS">内陆拒绝服务</BugCode>

一切完成停当后使用Maven举行打包，就生产了供FindBugs集成开发工具插件使用的JAR包，完成安装并重启，即可使用自界说插件对特定问题举行检测。

最终剖析的效果图如下图所示：

4 结语

本文先容了Android集成开发环境Android Studio的代码实时检测工具Code Arbiter的发生缘故原由及代码实现，最后展示了剖析的效果。通过Code Arbiter在生产环境中的应用，其检测效果照样相当不错，能够发现许多编码过程中存在的问题。然则Code Arbiter仍然存在许多不足，需要优化。后续将在以下两个方面对工具举行改善：

1. 扩大破绽检测局限，使Code Arbiter能够席卷Android编码常见平安问题；
2. 优化破绽检测规则，提高检测的准确性，削减误报。