[Paper] DeepGo: Predictive Directed Greybox Fuzzing

🤔



# File Hijacking Vulnerability: The Elephant in the Room



## 作者

- Chendong Yu - 中国科学院信息工程研究所 - 
- Yang Xiao - 中国科学院信息工程研究所 - 
- Jie Lu - 中国科学院计算技术研究所 - 
- Yuekang Li - 新南威尔士大学 - 
- Yeting Li - 中国科学院信息工程研究所 - 
- Lian Li - 中国科学院计算技术研究所 - 



## 文件劫持漏洞

> 文件劫持漏洞: 这是一种使攻击者能够通过操纵文件内容或文件路径来破坏安全边界的漏洞



> 攻击要求
>
> - 漏洞软件必须通过敏感操作与被劫持的文件或目录发生交互
> - 攻击者必须能够劫持某些文件或目录



### 案例分析



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

1. Bob创建路径`c:\.git\` 
2. Alice在其家目录`C:\User\Alice\`中调用`git log`
3. `git`如果没有在当前目录内找到`.git`会自动向父文件夹内寻找 此时找到`C:\.git\`
4. 如果Bob在`C:\.git\`内设置了`githooks`则会导致Alice执行Bob的任意代码

> Q1: githooks?
>
> 官方提供的一部分Hook函数 用于在git相关操作之后可以快速执行某些命令



### Empirical Study

- 被劫持文件的来源是什么?
- 哪些类型的操作是危险的漏洞触发操作?
- 当在软件生命周期(安装，卸载，…)何时可以触发文件劫持漏洞?



被劫持的文件有两种来源，现有技术主要侧重于检测第一个来源的漏洞。

- 脆弱程序创建的权限较弱的文件，允许攻击者对其进行操作，占全部漏洞的10.1%(27个)
- 攻击者创建的文件，通过特定的搜索策略被脆弱程序遇到。占绝大多数(89.9%，241个)。

> 当没有提供绝对文件路径时，操作系统或程序通常使用不同的文件搜索策略来定位目标文件。通常，这些搜索策略可能会返回具有弱权限的目录，从而允许攻击者植入恶意文件。在我们的调查中，我们确定了5种搜索策略，它们可能返回具有弱权限的目录。
>
> - 路径搜索顺序(3.4%): 在Windows系统中，当执行命令时，系统首先尝试在当前工作目录(CWD)中找到被调用的可执行文件，然后再搜索PATH环境变量中定义的路径。当CWD的权限较弱时，这种策略会带来安全风险。以Github Cli[19]中的漏洞为例。在执行gh命令时，CLI客户端将尝试在CWD中找到可执行文件git.exe。一旦CWD(例如，C:\ProgramData)具有弱权限，攻击者就可以在该目录中放置恶意可执行文件git.exe。
> - Windows下的Linux路径(4.5%): 具体来说，当Windows系统上不存在Linux路径时，系统会从`C:\`目录搜索。由于`C:\`在默认情况下是可写的，这使得攻击者可以轻松地植入恶意文件。以CVE-2019-5443[11]为例。curl程序读取默认配置文件`/usr/local/ssl/openssl.cnf`。在windows操作系统中，此文件不存在，系统会搜索配置文件`C:\usr\local\ssl\openssl.cnf`。由于路径`C:\`具有弱权限，攻击者可以轻松劫持文件并控制引擎配置，从而导致任意代码执行。
> - 未被包裹的路径(17.1%): 未被包裹的路径是指没有加引号的文件路径。当未加引号的路径包含空格或特殊字符时，Windows系统将截断该路径并使用截断的路径搜索该文件。例如，在CVE-2020-13884[14]中，Citrix Workspace程序调用CreateProcess API以不加引号的路径`C:\ProgramData\Citrix\Citrix Workspace 1911\TrolleyExpress.exe`执行文件TrolleyExpress.exe。但是，Windows系统使用空格截断路径并使用路径`C:\ProgramData\Citrix\Citrix.exe`搜索文件，有效地加载文件`Citrix.exe`而不是`TrolleyExpress.exe`。由于路径`C:\ProgramData\Citrix`具有弱权限，攻击者可以劫持`Citrix.exe`，从而导致权限升级。
> - 符号链接(19.4%): 当访问符号链接时，操作系统按照该链接来定位目标文件或目录。CVE-2022-39845就是这样一个例子，它会导致任意目录删除。具体来说，三星Kies的卸载程序试图删除一个不存在的目录`C:\ProgramData\Samsung\DeviceProfile\Cache`。由于攻击者可以拥有对`C:\ProgramData\Samsung`的写权限，因此攻击者可以针对任意目录(例如C:\)创建符号链接`C:\ProgramData\Samsung\DeviceProfile\Cache`。因此，卸载程序将删除`C:\`中的所有文件。
> - 动态链接库(45.5%): 在搜索动态库的过程中，操作系统在搜索目录中查找这些库。但是，如果在此搜索过程中遇到具有弱权限的目录，则可能会允许攻击者劫持要加载的动态库。DLL劫持是近年来备受关注的问题，我们研究的现有漏洞大多是由DLL劫持引起的。



并非所有被劫持文件的访问都可能导致漏洞。例如，查询文件大小之类的操作通常是安全的。通过我们的研究，我们确定了六种可能导致漏洞的操作类型。

- 移动(1.1%)/创建(8.2%)/删除(10.1%): 这三种类型的操作是危险的，如CVE-2022-39845所述。这种对被劫持的符号链接的操作可能导致数据丢失和文件完整性的破坏。
- 读取(7.1%): 程序通常从配置文件中读取不同的设置，这很容易受到文件劫持攻击。例如，攻击者可能篡改配置文件中的数据库连接字符串，从而将后续查询重定向到恶意数据库。或者，攻击者可以在配置文件中插入有害的文件路径，欺骗程序执行恶意代码。
- 进程创建(28.4%): 进程创建涉及创建一个新进程来执行文件，如果文件可以被劫持，则可能导致任意代码执行。例如，在安装过程中，程序可能首先从互联网下载安装文件，然后启动下载的文件来启动安装过程。劫持下载的文件可以欺骗程序执行任意命令。
- 镜像加载(45.1%): 镜像加载是指加载动态加载的库，即在Windows和Linux上分别加载DLL和SO文件。被劫持的库可能导致任意的代码执行。

> 读取操作会导致更多的FHVuln，并带来比我们想象的更高的风险。这些发现来自于新型的FHVuln，因此无法从现有的FHVuln中观察到。此外，我们对Windows和类unix系统中的FHVuln进行了详细的讨论，确定了它们广泛发生背后的原因，并讨论了减轻它们的责任。我们的发现为未来研究改进检测工具和开发针对FHVulns的有效防御提供了有价值的见解。



文件劫持漏洞可以在软件生命周期的任何阶段触发，大多数漏洞是在软件程序启动阶段触发的。目前还没有一种技术能够处理软件生命周期中的每个阶段来检测fhvuln。

- 安装(17.2%): 安装阶段通常包括检查系统需求、复制文件、设置配置等操作。例如，安装过程经常从安装介质(例如，下载的包)复制文件到硬盘驱动器上的指定位置。值得注意的是，安装过程通常需要较高的权限，这个阶段的文件劫持漏洞特别危险:攻击者可以在安装过程中劫持文件以获得较高的权限。
- 卸载(4.5%): 卸载时触发的漏洞都涉及符号链接。卸载软件时，卸载过程将从系统中删除与该软件相关的所有文件(例如，可执行文件和配置文件)。正如CVE-2022-39845中所讨论的，卸载过程可能会遵循劫持的符号链接删除任意目录，导致数据丢失和系统损坏。
- 升级(1.9%)/修复(3.7%): 例如用较新的或正确的版本替换现有的软件版本。这两个阶段分别触发了5个和10个漏洞。
- 启动(62.3%): 当启动一个程序时，程序通常会执行一系列任务来初始化执行环境，包括定位可执行文件、加载动态库、读取配置设置等。以上所有任务都可能受到文件劫持攻击。
- 使用(10.4%): 使用阶段的操作是特定于程序的，根据程序提供的功能，它们可能会因不同的软件程序而发生重大变化。例如，当用户编辑和保存文档时，文本编辑器可以创建、修改和删除文件。类似地，电子邮件客户端可以在下载和存储电子邮件时创建和删除文件。



## 作者的方法

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

- 事件跟踪生成器在每个阶段执行目标程序并记录执行的文件操作跟踪。
- FHVuln检测器检查每个执行跟踪，如果跟踪对被劫持的文件执行危险操作，将报告FHVuln。
- 路径池维护者收集事件跟踪中遇到的文件，并将它们放入路径池中。在此步骤中，JERRY还检查该文件是引用普通文件还是引用目录。
- 路径劫持者试图劫持并创建路径池中的每个文件。路径劫持者充当没有管理员/根权限的攻击者来模仿劫持行为。由于新的文件是由路径劫持者创建的，事件跟踪生成器再次被触发以发现更多的执行痕迹。这个迭代过程不断重复，直到到达一个不遇到新文件的固定点。

[Paper] File Hijacking Vulnerability: The Elephant in the Room

🤔



# FISHFUZZ: Catch Deeper Bugs by Throwing Larger Nets



## 作者



## 目前的做法

目前定向灰盒测试的做法是

- 距离算法 -> 在较大的数据集中 由于种子-目标距离被分解成为单个标量 以此为指导可能会导致失真
- 定常优先级 -> 定常优先级可能会导致一直探索某些已经充分探索的区域



## 作者的做法

- 新的距离算法 -> 为每个目标设置一个距离度量 而不是所有目标的平均
- 动态目标排序 可以自动丢弃目标
- 队列剔除算法

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

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



### 动态优先级

作者为每个目标设置一个三元组$(hit\_frequency, reached, triggered)$

- $hit\_frequency$表示命中次数
- $reached$表示是否到达目标区域
- $triggered$表示是否触发crash

Fuzzer优先选择$hit\_frequency$较少的目标进行fuzz



### 距离算法

因为基本块距离算法针对每个目标都进行计算的话 会导致计算开销过大 所以作者选用的计算方法是计算目标和函数之间的距离。 

作者首先测算所有函数之间的静态距离 而后保存成静态距离图



作者为每个函数对$(f_i,f)$分配了一个权重$weight$ 

- $weight$表示种子从入口函数$f_i$到被调用函数$f$经过的条件边的最小数量
- 条件边的最小数量由函数$dbb(m_a, m_b)$计算 即基本块$m_a$到基本块$m_b$的距离



$weight(f_i, f) = \begin{cases} \min dbb(m,m_f) \quad if\exist m_f\in f_i \\ \infty \quad\quad\quad\quad\quad\quad\quad otherwise \end{cases}$

其中基本块$m$是函数$f_i$的起始基本块 基本块$m_f$是函数$f_i$中调用函数$f$的基本块 如果$f_i$调用了$f$ 则权重$weight$为基本块$m$和基本块$m_f$​之间的最小距离 否则为无穷



两个函数之间的距离的定义如下 其中$sp(f_a, f_b)$是使用Dijikstra算法的$f_a$和$f_b$之间的最短距离

$dff(f_a, f_b) = \sum_{f_i \in sp(f_a,f_b)} weight(f_i, f_{i+1}) $



种子到函数$f$之间距离的定义如下

$dsf(s,f) = \begin{cases} min_{f_s \in \xi(s) }dff(f_s, f) \quad if\quad f\notin \xi(s) \\ 0 \quad\quad\quad\quad\quad\quad\quad\quad\quad otherwise\end{cases}$





### Inter-function Exploration Phase (函数间探索阶段)

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

在这个阶段，FISHFUZZ选择种子来最大化包含未触发目标的已达到的功能。该阶段的剔除算法如算法1所示。具体来说，给定一个种子队列和一组来自目标程序的函数，FISHFUZZ为每个包含目标的未探索函数设置最接近的种子的preferred = 1(第6行)。在将受青睐的种子提交给程序后，FISHFUZZ更新已探索函数列表并重复该过程。getClosestSeedToFun通过种子函数距离(§3.2)找到最接近函数f的种子s。如果多个种子与f的距离相等，我们会选择执行时间最短的那个。



### Exploitation Phase (利用阶段)

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



> Q1: 作者全文没有提到target是如何注入进去的?
>
> 作者通过SanitizerCoveragePCGRARD.so 针对源代码的bc进行插桩 然后将所有插桩位置记录下来作为target



## 缺点

1. 直接使用Sanitizer的标签作为target 显然缺少漏洞导向的指向性
2. 没有指标显示是否覆盖到target

[Paper] FISHFUZZ: Catch Deeper Bugs by Throwing Larger Nets

👍



# Arbiter：Bridging the Static and Dynamic Divide in Vulnerability Discovery on Binary Programs

## 作者

- Jayakrishna Vadayath - 亚利桑那州立大学 - 
- Moritz Eckert - 法国工程师学校 - 二进制安全
- Kyle Zeng - 亚利桑那州立大学 - 二进制安全
- Nicolaas Weideman - 南加州大学 - 程序修复
- Gokulkrishna Praveen Menon - 亚利桑那州立大学 
- Yanick Fratantonio - Cisco Systems Inc - 漏洞挖掘
- Davide Balzarotti - 法国工程师学校 - 模糊测试、机器学习
- Adam Doupé - 亚利桑那州立大学 - 模糊测试、WEB安全、内核安全
- Tiffany Bao - 亚利桑那州立大学 - 模糊测试、WEB安全、内核安全
- Ruoyu Wang - 亚利桑那州立大学 - 原清华团队
- Christophe Hauser - 南加州大学- 机器学习
- Yan Shoshitaishvili - 亚利桑那州立大学 - 模糊测试、WEB安全、内核安全



## 问题

目前静态分析和动态分析都具有各自的优点和缺点，但是在各自不擅长的领域几乎没有作用。

- 动态执行: 可以快速进行测试、误报率低；但是针对深层代码或者存在多个约束的代码效果很差
- 静态分析: 可以人工审查深层漏洞；但是缺少有效识别漏洞的工具和精度

> Q1: 即使结合了动态执行和静态分析，又能怎么用来挖漏洞呢?
>
> 作者总结了几种漏洞的属性，静态快速扫描特征，然后指定source点和sink点调用符号执行进行测试，如果使用符号执行验证目标路径可达则确定为漏洞。



## 作者的思路

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

首先定义了三种漏洞属性，为静态分析和动态分析提供结合的接口

> 1. 数据流敏感漏洞。对数据流敏感的漏洞可以通过推理source点和sink点之间的数据流来发现。请注意，数据流敏感漏洞的范围严格大于污染型漏洞，污染型漏洞仅包括因未对受污染的用户输入进行清理而导致的漏洞。这些可以通过静态技术实现，具有典型的精度限制，但也允许对数据流进行额外的动态验证以提高精度。
> 2. 易于识别的source或者sink。在漏洞发现过程中，source点决定数据流跟踪的开始，sink点决定数据流跟踪的终止。识别许多漏洞类别的source和sink需要整个二进制文件的精确别名信息，众所周知，这是极其昂贵且不可扩展的。例如，如果source被定义为“从文件 /tmp/secret 读取的任何数据”，则识别所有输入源将需要正确分析打开文件的每个函数和系统调用的参数，以及文件指针、文件描述符的传播，以及相关的数据结构。相反，有些sources或sinks，可以通过检查计算成本低且可扩展的分析生成的工件来识别(例如CFG)。这种sink的一个例子是“库函数 malloc() 的所有调用点”。通过这种类型的source和sink，将程序从source到sink切片是一种经过充分研究的静态技术。尽管通常在静态分析的背景下考虑此属性，但这些切片可以通过动态技术进行处理。这允许动态技术（例如 DSE）对切片过程中的过度近似进行推理，修复此类过度近似，并提高整体系统精度。
> 3. 控制流决定的别名。跟踪数据流几乎总是涉及恢复别名信息，这需要对目标进行昂贵的全二进制分析。然而，我们观察到，许多漏洞合并的数据流根本不涉及指针解引用，或者当它们这样做时，指针总是可以被解析为由控制流确定的一个对象(例如，通过堆栈指针访问的局部变量)。我们认为这种别名的情况是由控制流决定的，这是我们的目标漏洞的先决条件。从静态方面来看，这个属性允许ARBITER自适应地在CFG上前进或后退，而不必担心由不正确的别名信息引起的不精确。从动态方面来看，它极大地简化了由于缺乏动态初始化而导致的别名问题。



> Q2: 单纯这三个属性怎么对接静态分析和动态分析?
>
> 1. 数据流敏感漏洞
>    - 静态分析: 静态分析可以识别程序中的数据流路径，从潜在的输入源（如用户输入）到潜在的漏洞汇（如不安全的函数调用）。静态分析工具可以构建数据依赖图（DDG），并分析数据如何在程序中流动。
>    - 动态分析：动态分析，特别是动态符号执行（DSE），可以用来验证静态分析发现的数据流路径是否在实际执行中确实存在。DSE可以模拟程序的执行，检查数据流是否满足特定的漏洞条件
> 2. 易于识别的source或者sink
>    - 静态分析：静态分析可以利用程序的控制流图（CFG）来识别源和汇。例如，可以识别所有调用特定函数（如`malloc`）的点作为源，或者识别所有可能受到用户输入影响的函数作为汇。
>    - 动态分析：在动态分析中，可以针对这些易于识别的源和汇执行测试用例，以观察数据如何在程序执行过程中流动。这有助于验证静态分析的结果，并发现可能的漏洞触发点。
> 3. 控制流决定的别名
>    - 静态分析：静态分析中，可以利用控制流信息来限制别名分析的范围，因为许多漏洞涉及的数据流不涉及复杂的指针操作。这允许静态分析在不完全解决别名问题的情况下，仍然能够准确地识别潜在的漏洞。
>    - 动态分析：在动态分析中，可以利用控制流信息来简化别名问题。例如，如果一个指针总是指向由控制流确定的特定内存区域，那么在动态执行时可以为这个指针分配一个隔离的内存区域，从而避免复杂的别名问题。



> Q3: 作者提出了一个叫做Vulnerability Description(VD)的概念，具体这个东西是怎么组成的?
>
> VD其实是由漏洞的特征来编写的，简单来说其包含指定的sink点，source点和满足何种条件时确定为漏洞



> Q4: 其中的source和sink点是怎么确定的?
>
> 由VD中的sink和source指定的



> Q5: 哪些工作体现了静态分析，哪些工作体现了动态分析
>
> 首先是sink和source的识别，使用静态分析快速识别sink和source点，然后调用动态符号执行验证是否有可控数据从source点到达sink点



> Q6: 如何实现sink点和source点的静态跟踪? 针对作者说的不使用源代码仅使用二进制程序?
>
> 作者提出了一种静态数据流跟踪的方法`SymDFT`。给定任何起点(通常是函数的开始)，SymDFT以上下文敏感和路径敏感的方式静态地模拟基本块，并对寄存器、内存(作为覆盖全局区域、堆栈和堆的平面内存模型)、系统调用、以及对文件描述符的访问(这捕获了对文件和网络套接字的访问)。
>
> - 遍历策略。在函数级别上，SymDFT按拓扑顺序遍历函数内部的基本块，从而确保始终在访问所有前一个块之后访问一个块。一旦遇到对被调用方的调用，SymDFT将分析被调用方函数，并使用返回的抽象状态在返回站点继续分析。‘
> - 分支策略。在每个分支点，它分叉抽象状态并遵循所有分支，无论分支可行性如何:随着仿真的进行，SymDFT收集符号路径预测(即符号约束)，但它不评估这些约束的可满足性。
> - 状态合并策略。在同一二进制地址的抽象状态被立即合并，其中每个状态被分配一个合并标签，具体和符号表达式被合并成一个if-then-else表达式的形式，合并标签作为条件。
> - 终止策略。为了确保分析终止，SymDFT采用了激进的终止策略:(1)当调用深度超过2个函数时，SymDFT不分析被调用方，而是伪造一个抽象的返回值;(2)每个循环最多访问3次。这种激进的终止策略以降低可靠性和精确性为代价换取了可伸缩性。
>
> 而后根据CFG在其中识别出source点和sink点并且根据此生成数据流图，在数据流图上对source和sink的追踪很简单就是直接寻找子图即可。



> Q7: 作者一直提到欠约束的符号执行(USCE)，这个到底是欠缺哪一部分的约束？
>
> 这里提到的欠约束的符号执行，实际上是一种对符号执行条件要求的弱化，因为如果通过符号执行的方法得到一条从输入到sink点的路径代价是巨大的，所以如果我们选择从中间某个函数开始进行模拟，可以减少一部分的代价，当然这里减少代价是一部分，并且由于前面的静态分析获得的信息不完整的原因而选择欠约束的符号执行，其可以针对某个函数开始符号执行，其将所有未知值（即条件不足无法推断其值的参数）视作欠约束的变量，针对欠约束变量在源码中不同的使用方法给予不同的约束。



> Q8: 别名问题是什么东西
>
> 其实就是两个指针指向同一个地址，这两个指针就称为别名，在汇编层面对于这个别名问题的辨别存在巨大困难。



## 解决了什么问题

作者提到其认为的最大贡献是弥补的静态分析和动态分析之间的空缺，其将静态分析和动态分析链接起来，使用静态分析来指引动态分析的过程，其中的感觉这个VD和漏洞模板是可以替代Checker的功能的。使用特定的漏洞模板来指引Fuzz过程是否能做到?

## 仍然存在什么问题

很显然，程序只能解决作者提到的PC漏洞，即

1. **数据流敏感性**：这类漏洞可以通过分析数据流来发现，即从输入源到漏洞汇的数据流动。这些漏洞可以通过静态技术分析，同时也可以利用动态技术来提高精确度。
2. **易于识别的源或汇**：对于许多漏洞类别，源和汇可以通过检查程序的控制流图（CFG）等静态分析技术来识别。这种属性允许使用静态技术来确定程序中潜在的漏洞点，并且可以通过动态技术进一步验证。
3. **控制流决定的别名**：许多漏洞涉及的数据流不涉及指针解引用，或者当它们涉及时，指针总是可以解析为由控制流确定的一个对象。这种属性允许在静态分析中忽略复杂的别名问题，同时在动态分析中简化了别名问题的处理。

例如未初始化漏洞就无法通过Arbiter检测



## 复现流程

```bash
$ git clone https://github.com/jkrshnmenon/arbiter.git
$ python setup.py build && python setup.py install
$ mkdir test
$ ./vuln_templates/run_arbiter.py -f examples/cve-vuln_templates/vd_cve-2018-10388.py -t examples/cve-binaries/cve-2018-10388 -l test/log/ -j test/json/
```

[Paper] Arbiter：Bridging the Static and Dynamic Divide in Vulnerability Discovery on Binary Programs

🤔



# ARCUS: Symbolic Root Cause Analysis of Exploits in Production Systems
## 作者

- Carter Yagemann - 佐治亚理工学院 - 漏洞检测、成因分析
- Matthew Pruett - 佐治亚理工学院研究所 - 漏洞检测
- Simon P. Chung - 佐治亚理工学院 - 漏洞检测
- Kennon Bittick - 佐治亚理工学院研究所 
- Brendan Saltaformaggio - 佐治亚理工学院 - 漏洞检测、Web方向
- Wenke Lee - 佐治亚理工学院研究所 - Fuzz

> **VulChecker: Graph-based Vulnerability Localization in Source Code**



## 思路

作者针对漏洞的RCA和修复提出了一种新思路，即利用Intel PT技术，来监控程序的错误的控制流，一旦程序被打上错误标记，ARCUS会将其捕捉并发向分析系统。分析系统会利用快照将错误流重建然后根据一系列模板发现冲突点确定漏洞根本成因。主要的检测思路是，在重建快照之后，将攻击者可以控制的参数更改为符号值，然后进行执行观察符号值的传播，一旦符号值污染到关键参数则确定漏洞触发，而后向前寻找符号值是怎么传进来的，在哪里产生的，以确定漏洞根本成因。

基本定位流程为：

1. 识别成为符号的代码指针：符号值向后传播即可
2. 识别污染其成为符号值的基本块：生成控制流依赖图CDG来定位
3. 寻找控制污染块执行的基本块
4. 测试附加约束是否可以修复漏洞

### 堆栈溢出的检测思路

堆栈溢出根本特征是控制流劫持，在重建快照之后，沿着攻击者执行路径进行重建中间状态时观察PC是否被污染成为符号值即可。在发现PC被污染成为符号值之后即确定存在堆栈溢出。从这一点开始，模块查看先前的状态以确定是什么导致符号数据进入PC。由于劫持只能发生在间接控制流传输时，因此先前的状态必须执行以返回、间接调用或间接跳转结束的基本块

**控制流被污染 + 之前的基本块为返回、间接调用或间接跳转结束的基本块**

### 整数溢出检测思路

**操作可能溢出 = 标记溢出的寄存器 + 寄存器传播到另外一个函数时 确定发生整数溢出**



### UAF和Double Free检测思路

**内部针对所有的malloc和free维护一个bin并且记录大小，一旦违背操作规则则发生UAF和Double Free**



### 格式化字符串检测思路

**如果违背指向格式字符串的指针是具体的，且驻留在只读存储器中/字符串的内容是完全具体的/所有附加参数都指向映射的内存地址则为格式化字符串漏洞**