😅



### Clang-tidy

---



#### Clang-tidy 与 Static Analyzer的对比

|   Clang-tidy   | Static Analyzer |
| :------------: | :-------------: |
| 使用语法树匹配 |  使用符号执行   |
|   使用了AST    |    使用了AST    |

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202311281034099.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202311281034928.png)



#### Clang-tidy开发流程

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202311281037151.png)



#### 使用手册

```bash
$ bear make # 针对Makefile项目生成compile_command.json
$ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -G Ninja ../ # 针对Cmake项目生成compile_command.json
$ /home/du4t/Desktop/Project/llvm-project/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
```



#### 开发实例

> 开发手册: https://clang.llvm.org/docs/LibASTMatchersReference.html



首先使用脚手架快速创建相关文件 此时相关文件存在于`/home/du4t/Desktop/Project/llvm-project/clang-tools-extra/clang-tidy/misc`中

```bash
$ cd /home/du4t/Desktop/Project/llvm-project/clang-tools-extra/clang-tidy
$ ./add_new_check.py [module] [name]
```



由于Clang-tidy是基于语法树进行检查的 所以第一步就是要搞清对应检查规则的语法树 这里针对测试用例 检查是否存在`memcpy`的`size`字段过大的问题

```c
#include <stdio.h>
#include <stdlib.h>
#include <strings.h>

int main(int argc, char** argv)
{   
    int len = 0x10000;
    void *p = malloc(0x100);
    void *p1 = malloc(0x100);
    memcpy(p, p1, len);
    while(1){
    	len--;
    } 
}

```



使用Clang生成语法树

```c
$ clang -Xclang -ast-dump -fsyntax-only test.c
```

```bash
|-FunctionDecl 0x55d91ce19350 <test.c:5:1, line:14:1> line:5:5 main 'int (int, char **)'
| |-ParmVarDecl 0x55d91ce191f8 <col:10, col:14> col:14 argc 'int'
| |-ParmVarDecl 0x55d91ce19278 <col:20, col:27> col:27 argv 'char **'
| `-CompoundStmt 0x55d91ce1a050 <line:6:1, line:14:1>
|   |-DeclStmt 0x55d91ce194b8 <line:7:5, col:26>
|   | `-VarDecl 0x55d91ce19418 <col:5, col:16> col:9 used len 'int' cinit
|   |   `-UnaryOperator 0x55d91ce194a0 <col:15, col:16> 'int' prefix '-'
|   |     `-IntegerLiteral 0x55d91ce19480 <col:16> 'int' 2147483647
|   |-DeclStmt 0x55d91ce19610 <line:8:5, col:28>
|   | `-VarDecl 0x55d91ce194e8 <col:5, col:27> col:11 used p 'void *' cinit
|   |   `-CallExpr 0x55d91ce195d0 <col:15, col:27> 'void *'
|   |     |-ImplicitCastExpr 0x55d91ce195b8 <col:15> 'void *(*)(unsigned long)' <FunctionToPointerDecay>
|   |     | `-DeclRefExpr 0x55d91ce19550 <col:15> 'void *(unsigned long)' Function 0x55d91cda4c70 'malloc' 'void *(unsigned long)'
|   |     `-ImplicitCastExpr 0x55d91ce195f8 <col:22> 'unsigned long' <IntegralCast>
|   |       `-IntegerLiteral 0x55d91ce19570 <col:22> 'int' 256
|   |-DeclStmt 0x55d91ce19740 <line:9:5, col:29>
|   | `-VarDecl 0x55d91ce19640 <col:5, col:28> col:11 used p1 'void *' cinit
|   |   `-CallExpr 0x55d91ce19700 <col:16, col:28> 'void *'
|   |     |-ImplicitCastExpr 0x55d91ce196e8 <col:16> 'void *(*)(unsigned long)' <FunctionToPointerDecay>
|   |     | `-DeclRefExpr 0x55d91ce196a8 <col:16> 'void *(unsigned long)' Function 0x55d91cda4c70 'malloc' 'void *(unsigned long)'
|   |     `-ImplicitCastExpr 0x55d91ce19728 <col:23> 'unsigned long' <IntegralCast>
|   |       `-IntegerLiteral 0x55d91ce196c8 <col:23> 'int' 256
|   |-CallExpr 0x55d91ce19f10 <line:10:5, col:22> 'void *'
|   | |-ImplicitCastExpr 0x55d91ce19ef8 <col:5> 'void *(*)(void *, const void *, unsigned long)' <FunctionToPointerDecay>
|   | | `-DeclRefExpr 0x55d91ce19e08 <col:5> 'void *(void *, const void *, unsigned long)' Function 0x55d91ce19bc0 'memcpy' 'void *(void *, const void *, unsigned long)'
|   | |-ImplicitCastExpr 0x55d91ce19f48 <col:12> 'void *' <LValueToRValue>
|   | | `-DeclRefExpr 0x55d91ce19e28 <col:12> 'void *' lvalue Var 0x55d91ce194e8 'p' 'void *'
|   | |-ImplicitCastExpr 0x55d91ce19f78 <col:15> 'const void *' <NoOp>
|   | | `-ImplicitCastExpr 0x55d91ce19f60 <col:15> 'void *' <LValueToRValue>
|   | |   `-DeclRefExpr 0x55d91ce19e48 <col:15> 'void *' lvalue Var 0x55d91ce19640 'p1' 'void *'
|   | `-ImplicitCastExpr 0x55d91ce19fa8 <col:19> 'unsigned long' <IntegralCast>
|   |   `-ImplicitCastExpr 0x55d91ce19f90 <col:19> 'int' <LValueToRValue>
|   |     `-DeclRefExpr 0x55d91ce19e68 <col:19> 'int' lvalue Var 0x55d91ce19418 'len' 'int'
|   `-WhileStmt 0x55d91ce1a030 <line:11:5, line:13:5>
|     |-IntegerLiteral 0x55d91ce19fc0 <line:11:11> 'int' 1
|     `-CompoundStmt 0x55d91ce1a018 <col:13, line:13:5>
|       `-UnaryOperator 0x55d91ce1a000 <line:12:6, col:9> 'int' postfix '--'
|         `-DeclRefExpr 0x55d91ce19fe0 <col:6> 'int' lvalue Var 0x55d91ce19418 'len' 'int'
```



由此得出语法树检查规则

```c
//===--- My_testCheck.cpp - clang-tidy ------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//

#include "My_testCheck.h"
#include "clang/AST/ASTContext.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"

using namespace clang::ast_matchers;

namespace clang {
namespace tidy {
namespace misc {

void My_testCheck::registerMatchers(MatchFinder *Finder) {
  // FIXME: Add matchers.
  Finder->addMatcher(callExpr(callee(functionDecl(hasName("memcpy"))), hasArgument(2, declRefExpr().bind("thirdArg"))).bind("memcpy"), this);
}

void My_testCheck::check(const MatchFinder::MatchResult &Result) {
  // FIXME: Add callback implementation.
  const auto *memcpyCall = Result.Nodes.getNodeAs<CallExpr>("memcpy");
  const auto *thirdArg = Result.Nodes.getNodeAs<DeclRefExpr>("thirdArg");

  if (memcpyCall && thirdArg)
  {
    const VarDecl *Var = dyn_cast<VarDecl>(thirdArg->getFoundDecl());
    if (Var && Var->hasInit() && isa<IntegerLiteral>(Var->getInit()))
    {
      const auto *InitValue = cast<IntegerLiteral>(Var->getInit());
      if (InitValue->getValue().getZExtValue() > 0x1000)
      {
        SourceManager &SM = *Result.SourceManager;
        SourceLocation loc = memcpyCall->getSourceRange().getBegin();
        if (loc.isValid())
        {
          diag(loc, "memcpy call has third argument larger than 0x1000")<<loc;
        }
      }
    }   
  }
}

} // namespace misc
} // namespace tidy
} // namespace clang

```



检查结果如下

```bash
$ /home/du4t/Desktop/Project/llvm-project/build_release/bin/clang-tidy --checks="-*, misc-My_test" ./test.c
```

```bash
/home/du4t/Desktop/Test/test.c:10:5: warning: memcpy call has third argument larger than 0x1000 [misc-My_test]
    memcpy(p, p1, len);
    ^~~~~~
Suppressed 1 warnings (1 with check filters).
```



但是由于是静态检查 只能说检查结果差强人意 下面这个样例就是未检出 还是不如`Static Analyzer` 但是好处是`Clang-tidy`是可以兼容`Static Analyzer`的

```c
#include <stdio.h>
#include <stdlib.h>
#include <strings.h>

int main(int argc, char** argv)
{   
    int len = 0x1;
    void *p = malloc(0x100);
    void *p1 = malloc(0x100);
    len += 0x1000;
    memcpy(p, p1, len);
    while(1){
    	len--;
    } 
}

```



如果是需要扫描一个项目的话 需要针对项目编译的`compile_command.json` 此处就体现出另一个弊端 `Clang-tidy`无法输出一个完整的报告 而`Static Analyzer`可以自己生成报告

```bash
$ bear make # 针对Makefile项目生成compile_command.json
$ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -G Ninja ../ # 针对Cmake项目生成compile_command.json
$ /home/du4t/Desktop/Project/llvm-project/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
```

[Misc] Clang-tidy自定义规则

🤔



### UTOPIA: Automatic Generation of Fuzz Driver using Unit Tests

---



#### 现有的生成harness的方法

- 从现有的代码库中根据代码推断API有效序列
- 从Example中提取

#### 现存的问题

- 单纯从API来说会跟别的用户代码逻辑混合 需要区分

#### 前人的工作

- 随机从源码中推断API序列
- 动态执行时观察执行序列

#### 前人工作的局限性

- 习惯于从`consumer code`中推断API
- 对于`consumer code`中的代码逻辑无法区分 容易从中生成错误的API序列或者生成错误的harness逻辑

#### 提出什么方法

- 从Unit Test中自动提取API序列生成harness
- 提出了一个新概念 Root Definition
  - 根据各种分析链回溯 最根源的变量称为Root




#### 新方法的优点

- 在Unit Test中所有API的调用都是显式的 方便在生成harness时从中提取
- Unit Test与Fuzz的目标是接近的 都是为了测试软件 其目的性可以保证

#### 新方法的目的

- 合成出有效的API调用序列
- 合成出有效的API调用参数

#### 提出的方法面临的困难

- 由于存在继承等复杂代码关系 静态分析存在一定困难
- Unit Test的存在形式是多样的 没有一个固定的规范
  - 使用Clang AST语法树进行分析  针对不同框架开发出不同的解析方式即可
- 如何放宽一些检查 如果太严格会阻碍大部分的变异数据 如果太松会导致许多误报

#### 分析方法

- Def-Use(DU) Chain: 定义使用链分析 关注定义之后的每次使用(主要关注存储)
- Inter-procedural Analysis: 函数间调用分析 主要是继承DU链 或者使用第三方库进行分析
- Output Analysis: 对于输出进行Fuzz是没有收益的 在DU链的基础上根据LLVM IR查看变量是否有load/gep指令 判断是否有输出
- FilePath and AllocSize Analysis: 对FilePath和AllocSize进行Fuzz是没有意义的 一个只会影响打开的文件 一个只会影响分配的内存大小 直接固定关注libc中设计到FilePath和AllocSize的函数即可
- LoopCount Analysis: 分析库内循环计数器 对其Fuzz同样是无意义的 可以避免程序超时。如果在DU链中识别到比较指令，则检测该变量是否为循环退出变量(检测到任何对该变量作用的条件分支 则认为其为LoopCount)
- Array<->Length Analysis: 数组与长度对应变量 通过识别DU链中带有索引访问的gep命令中的变量认为其为Array 当循环中的gep变量且其索引操作数为Array、处在循环之中、循环条件不变 则判断为Length [10 in while(i<10)]

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20231030205914.png)



#### harness合成

- 将某些变量的值(Root) 转化成为Fuzz目标
- 排除条件如下
  - 头文件中或者项目文件之外的Root
  - 编译时确定的常数
  - 带有外部函数的返回或者输入参数的函数
  - 初始化赋值为Null的Root
  - 函数指针参数
  - 依赖于之前分析时忽略的变量
  - 文件属性
- 变异策略
  - 变异文件内容而不是文件路径
  - 限制变异分配内存时的参数大小
  - 限制变异循环变量
  - 对数组Fuzz时 创建一个数组并将Fuzz输入分配给数组的每一个元素
  - 限制Fuzz输入比数组大小小1
- Fuzz循环
  - 设置一个固定入口函数用于调用生成的harness
  - 提取出变量原始值作为种子 方便快速提高覆盖率

#### 效果

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20231030095631.png)