提到静态漏洞检测工具，大部分人印象中都是源码级。然而有些场景是没有源码的，比如固件分析等等。本文介绍一个二进制的静态漏洞检测工具cwe_checker的基本使用方法。其开源于：https://github.com/fkie-cad/cwe_checker

他的安装和使用方式都很简单。

安装

使用docker安装，拉取他的镜像

docker pull fkiecad/cwe_checker:latest

本地安装可以去github仓库看README，这里就不再赘述了。

使用

使用下面这个命令即可用这个镜像里的工具去测试二进制。其中：

• /PATH/TO/BINARY：二进制的路径
• /input：二进制的名字

docker run --rm -v /PATH/TO/BINARY:/input fkiecad/cwe_checker /input

如果运行成功，应该会出现如下界面

摘要：本文针对二进制SCA检测技术短板所面临的一些特殊场景、检测影响及应对措施进行详细分析和说明，希望对使用二进制SCA检测工具的测试和研发人员有所帮助。

本文分享自华为云社区《二进制SCA检测工具---技术短板及应对措施》，作者：安全技术猿。

世间万物都不可能是十全十美的，二进制SCA检测技术也逃不过此宿命，它既有它的长处，能解决其他技术不能或很难解决的问题和场景，同时它自身技术短板也面临着一些无法或很难解决的场景。

我们知道二进制文件在产品包中的类型与形态是非常复杂的，不同语言的二进制文件有各自不同的特点，同时不同开发人员进行软件设计、开发、编译、打包的方式和场景更是千差万别，以产品引用开源软件的方式为例就存在以下场景：patch打补丁版本号不变、产品引用开源软件部分功能场景下的部分编译、自研代码基于开源软件源码的侵入式修改，以及不同开源软件的被动依赖等等场景，在这些复杂的场景下二进制SCA工具检测能力和检测结果正确性会受到极大的挑战和影响。

解决或缓解这些影响的思路无非就两种：外部解决和内部解决。从外部解决的方法是尽可能的减少或避免出现二进制SCA短板场景，从软件的设计、开发编译、打包部署等在不同阶段进行优化和规范，摒弃不合理的做法，尽量避免出现二进制SCA工具的短板场景；另外一个是测试工具及测试方法的优化，把二进制SCA工具用来做它擅长的事，避免出现用大炮打蚊子的事情。从内部解决的方法则是优化工具的能力和算法，尽可能来提升工具的适用场景，减少短板场景。

下面针对二进制SCA工具的技术短板面临的特殊场景的特点、检测影响和应对措施进行详细描述：

解包特殊场景：被测软件包采用了自定义的打包算法或加密过的压缩包
解包影响：解包工具无法正确的进行解包，会导致检测结果遗漏；
应对措施：测试人员可以先用专用工具进行解包，再用tar、zip等工具对解包后的目录重新打包，上传新包进行检测即可。

不同语言特殊场景详解：

可以试试下面的漏扫服务，看看系统是否存在安全风险：>>>漏洞扫描服务

 点击关注，第一时间了解华为云新鲜技术~

源代码在大多数软件安全分析的情况下是不可用的。因此，二进制代码分析被用于许多原因，包括软件取证，恶意软件分析，性能分析和调试。文献中有很多二进制代码分析方法，其中最常用的有符号执行、concolic执行、静态污染分析和动态污染分析为了验证我根据之前一篇文章所提出的一种想法，准备一步步进行实现。首先需要建立自己的污点分析工具，污点分析分为静态和动态。对于动态污点分析已经有一系列工具被提出，本文将进行详细介绍。
为了改善符号执行中发现的一系列问题，研究者们开始污点分析，最早的污点分析是由Funnywei提出的（Bufer Overfow Vulnerability Mining Model [Z/OL]）。污点分析以三元组的形式表现：污点源（source）、污染汇聚点（sink）、无害处理（sanitizer）。接下来用一个例子来详细描述一下污点分析三元组在具体程序中的表现。

污点分析通过对系统中敏感数据进行标记，继而跟踪标记数据在程序中的传播以检测系统安全问题。上图是一段Android应用程序代码，运行该段程序会导致用户的密码数据通过发送信息的方式泄露；污点分析可以有效地检测该问题。污点分析首先要识别引入敏感数据的接口（污染源）并进行污点标记，如上图第4行引入密码数据的passwordText接口为污点源，并对pwd变量进行污点标记。如果被标记的变量又通过程序依赖关系传播给其他变量，那么根据相关传播规则继续标记对应的变量，例如上图中pwd变量的污点标记按照箭头进行传播，所以第5行的leakedPwd变量和第6行的leakedMessage变量都将会被标记，当被标记的变量达到信息泄露的位置（污点汇聚点）时，则根据对应的安全策略进行检测上图中第8行带污点标记的leakedMessage变量可以传播到发送信息的sendTextMessage接口，这就意味着这里是敏感数据会被泄露的地方。在第9行，密码数据通过加密转化后赋值给sanitized变量，继续传播sanitizedPwd变量并不会产生泄露问题，也就是说，如果污点变量经过一个使数据不再携带隐私信息的接口处理（无害处理），那么就可以移除污点数据的污点标记。
总结一下，污染源是将一些不可信或机密的输入数据引入应用程序的地方，这些输入数据可能来自应用程序API或网络接口。污点汇聚点是应用程序中执行安全操作(例如敏感的银行事务)的敏感点，需要对其进行保护，以免应用程序的完整性、机密性和可用性受到侵犯。无害处理指的是通过删除有害操作(如可能导致应用程序运行出其预期操作[7]的恶意程序)，被污染的输入数据不再被认为对应用程序的信息安全有害的过程。
污染分析方法有两种，静态污染分析(STA)和动态污染分析(DTA)。在STA中，分析程序通过检查中间代码而不执行应用程序来测试应用程序。静态污染分析主要是通过两个步骤进行的，包括对中间代码进行反汇编和对得到的汇编代码进行分析。它有时可能使用二进制代码进行应用程序安全分析。然而，由于源代码很少附带COTS软件，这使得STA方法更难对抗恶意程序，从而减少了它的应用。类似地，用STA方法分析二进制代码也经历了复杂和挑战。例如，具有强大规避技术的恶意软件可以很容易地避开STA方法。这些限制促使我们确定替代方法，这些方法可以克服这些缺陷，从而准确可靠地分析应用程序。
另一方面，在DTA中，应用程序将在运行时测试可能的漏洞[12]。STA和DTA方法各有优缺点。例如，在应用程序中进行信息流分析时，DTA可能会受到运行时开销的影响，这可能会导致无法分析所有代码，从而导致无法发现一些潜在的威胁。另一方面，由于STA只分析应用程序代码而不执行它，它可能会受到准确性问题的影响。因此，一些研究人员提出了将这两种技术结合起来分析应用程序缺陷或漏洞的工具：

1. Constructing a hybrid taint analysis framework for diagnosing attacks on binary programs
2. TeICC: targeted execution of inter-component communications in Android
3. A hybrid analysis framework for detecting web application vulnerabilities

一些研究人员在DTA前后使用STA方法：

1. A hybrid analysis framework for detecting web application vulnerabilities
2. Combined approach to solving problems in binary code analysis

例如，在这样做时，在DTA之后使用STA，以查看使用DTA后的分析是否遗漏了任何可疑的东西。可以在DTA之前使用STA来分析应用程序在实际环境中执行代码之前的行为。
通常，DTA方法是在硬件级或代码级实现的。例如，一些DTA方法是在硬件内部实现的。尽管这种实现提供的开销相对最低，但由于它需要对处理器进行重大的架构和微架构更改，因此灵活性较差，实用性较差。通过使用源代码工具来跟踪受污染数据的传播，DTA也可以在软件的代码级执行。这种方法也不太实用，因为在大多数应用程序中，源代码很难用于安全性分析。然而，为了在不修改硬件或源代码的情况下执行数据流跟踪，DTA方法如：

1. Dytan: a generic dynamic taint analysis framework
2. libdft: Practical dynamic data flow tracking for commodity systems
3. Argos: an emulator for fingerprinting zero-day attacks for advertised honeypots with automatic signature generation
4. BitBlaze: A new approach to computer security via binary analysis
5. Dta++: dynamic taint analysis with targeted control-flow propagation

使用二进制代码执行安全分析。这种方法被更广泛地使用，因为它支持各种各样的分析。对于我来说，使用二进制代码的DTA方法是我们感兴趣的焦点。