第一章的时候大概讲了 Angr 的一些基本概念和使用，我思量着应该要弄点实际的东西来练练才能把这个工具用熟捻。

最经典的使用案例无疑是 angr_ctf 中的那些了：

https://github.com/jakespringer/angr_ctf

题目本身都不是很难，甚至大多都是能靠人力完成的工作。但是即便如此，自动化也有自动化的意义对不对。毕竟我们现在需要的不是马上就能用它解决各种难题，而是把简单的问题解决，然后才能开始做复杂问题。

附件使用的是 https://github.com/ZERO-A-ONE/AngrCTF_FITM 仓库下编译好的版本。因为原仓库下只有源代码，而且编译还需要另外去配环境，所以这里直接用了这位师傅编译好的附件。

一般的基本流程如下：

当然还是得从最简单的开始，题目本身是一个直接用 IDA 读就能读明白的简单程序，但出于练习目的，还是得手写一下脚本。

首先需要创建项目：

创建 state：

创建 SM：

搜索路径：

探索路径时需要给出需要查找到的路径地址，这里我们通过 IDA 可以确定程序输出 “Good Job.” 时的地址为 0x08048675

求解结果：

简单说明一下代码。

程序本身很大，IDA 虽然也有办法反编译，但是速度极慢，但用 Angr 设定好参数就很快了。

前几个步骤是一样的：

我们不妨试试，如果按照上一题的做法会如何：

结果会发现等了很久也没有算出结果，因为分支实在太多了。

因此要对代码做一点改进：

其实只是给 explore 增加了一个 avoid 的参数。当代码模拟执行遇到了该地址时，将会把这段路径放入到 avoided 的一个列表中，用来表示被避开的路径，然后其他照旧，继续执行。

之所以通过添加这样的操作就能够得到答案，其实很简单，是为了避免路径爆炸而必要的。

我们可以用这么一个二插树来表示路径：

我们用 1 来表示正确的路径，0 表示错误的路径。可以看见，在这个树中一共有 8 条不同的路径，而正确的路径只有一个。

假设所有涉及到 0 的路径都会进入到某个地址 x 处。那么如果没有使用 avoid 参数，Angr 就会遍历这 8 条路径，然后求解出最左的那条路径所需的输入。

而如果我们添加了 avoid=x ，那么当 Angr 从根节点进入到右子树时，由于接下来立刻进入到 x 地址处，因此停止分析这条路径，将其加入到 avoided 中，从而将下面的 4 条路径全都舍弃，将所需的时间直接减少了一半。

同理，当它进入左子树时，仍然存在分叉，而进入右子树的分叉会因为相同的原因被舍弃，从而再次减少一半的时间。

在路径极其庞大的情况下，比如说 2^31 条路径，通过这种方法能够极大程度降低消耗。

还是这个模板：

这题的情况和 00_angr_find 有些不太一样。尽管 IDA 将它们反编译后的结果看起来很像，但是在汇编中却有很大差别：

可以看见，这行输出在 main 函数里到处都是，所以其实很难找到真正的那条路径的地址。

同理的，“Try again.” 也一样，因此需要修改 find 参数：

可以发现，find 参数除了能是一个具体的地址外，还可以是一个函数。该函数返回 True 时会将路径记录下来，返回 False 时则表示路径并非我们想找的。

而区别路径的关键在于 state.posix.dumps(1) ，通过该方法，可以将 stdout 中的内容 dump 出来进行比较。如果输出包含了 Good Job. ，我们就认为是想要的路径。这样就能避开直接使用地址了。

当然了，avoid 也可以这么用，读者可以自行试试。

还是老三样：

有些特殊的地方是，输入使用 get_user_input ，而该函数如下：

前文曾提到过，Angr 对 scanf 这类使用格式化字符串的函数支持并不是很好，不过或许是最近的版本更新，直接这样写也同样能得到结果了：

不过既然是学习，还是照例看看最标准的写法应该是什么吧。

根据汇编可以看到，该函数的实际操作是将值储存在寄存器中：

因此我们可以直接将该函数钩取，然后手动设置寄存器的值：

由于现在我们再从 entry_point 进入了，而需要跳过 get_user_input 函数，因此使用 blank_state 来初始化状态，并将开始地址设定在该函数之后的第一条指令处。

接下来创建三个位置的符号向量，将他们设定为寄存器：

此处引入另外一个 claripy 包来创建符号向量： claripy.BVS(name,size) 。创建完成后即可生成 SM 并开始探索了。

完成探索后，最后需要求解符号向量的值：

到这一步其实就差不多轻车熟路一把梭搞定了：

不过这道题实际上和上一题类似，但输入值储存在栈中，因此标准做法其实是将内存符号化进行求解：

通过 state.memory.store(addr,value) 可以对内存进行符号化，从而在路径发现以后进行求解。

这道题同样因为现在的 Angr 功能强大而不需要以前那样复杂的技巧了：

而题目的本意是让我们将内存符号化，其实和上一题一样，直接对内存进行存储就行了：

和上一题不同的地方在于，这次的存储位置为堆内存，我们不能直接给出一个地址然后去存储。

一把梭还是可行的：

而标准做法是：

通过这题就能够理解符号执行的一个好处了。由于它并不是真的去执行，只是模拟执行代码而已，所以对地址本身没有限制，完全可以随意设定内存的使用方法。

另外 endness 参数用于指定储存的端序，而 project.arch.memory_endness 将会反映程序所在平台的默认端序，此处为小端序。

可以发现程序调用了 fopen 去打开文件，对于这种情况，Angr 也同样提供了模拟文件的系统。

同样的，照旧一把梭也能搞定：

不过还是来看看它的模拟文件系统吧：

前几个还是照旧，但是也有一些新东西：

angr.storage.SimFile 提供了一个模拟文件系统，通过 state.fs.insert 可以将该模拟出来的文件插入到 state 符号中。这样在模拟执行时就会用该文件替代真实情况下的文件了。

而 angr.storage.SimFile 的 filename 参数表示文件名，content 参数表示文件内容，size 参数表示文件大小，单位为字节。

在这里就能遇到之前所说的 “路径爆炸” 问题了。

照例试试一把梭：

会发现这次就没办法那么顺利得到答案了，Angr 求解了半天却一直没有给出 “yes” 的回答，因此这次我们必须手动去优化求解的过程。

分析 check_equals_AUPDNNPROEZRJWKB 函数可以发现，该函数实际上是在对输入和 password 对比，而 password 的值是固定的 AUPDNNPROEZRJWKB 。

因此第一种缓解路径爆炸的方法是，只需要探索到进入该路径即可。而此后的求解过程通过人为的方法手动增加。

首先还是创建状态，这里我们跳过了 scanf ：

接下来我们为 buffer 创建符号，并开始探索：

此处地址 0x08048565 对应了 check_equals_AUPDNNPROEZRJWKB 函数的第一行指令。这样就不必进入到会引发路径爆炸的循环中了。

最后，在找到路径以后，为求解器主动添加条件：

我们需要保证的是，在进入 check_equals_AUPDNNPROEZRJWKB 函数时，buffer 处的内容和字符串 AUPDNNPROEZRJWKB 相同，因此直接添加条件即可求解。

而上一题的操作总归来说是解一时之急，因为函数正好在最后的位置，所以停在那边就足够了。但是如果路径爆炸发生在中途，就不能这么做了，我们需要更好的方法解决它。

首先是路径爆炸会发生在 check_equals_XYMKBKUHNIQYNQXE 函数中，它和上一题的函数是一样的。

前几个还是一样：

接下来是对该函数进行钩取：

钩取方法可以通过 @project.hook 宏完成。第一个参数为对应的机器码地址，第二个参数为钩取的指令长度。此处因为我们只需要钩取 call 指令，因此长度为 5。

而钩子下面对应的需要定义钩子函数，此处我们将 buffer 的内容读取出来进行比较，并根据结果使用 claripy.If 来设置 eax 寄存器。

最后探索路径即可：

此方法为第二个缓解路径爆炸的方法，即直接对地址进行钩取。

第 10 题看起来和上一题一样，但是还是那个问题，如果调用点很多该怎么办？虽然 IDA 分析出的结果相似，但是通过交叉引用可以发现：

显然不太可能每次都对地址进行钩取，因此需要有一个方法直接钩取函数：

接下来钩取函数：

首先需要声明一个类，并定义 run 方法，而该方法将取代想要钩取的函数。其参数会和钩取的函数有相同的参数列表，但除此之外还需要一个 self 。

至于 run 函数的实现则各不相同了。这里我们就直接模仿比较函数的最终效果，返回比较的结果。

然后调用 project.hook_symbol 方法直接以函数名为参数对函数进行钩取即可。

发现一把梭能解决：

不过原题的目的是让我们去钩取 scanf 函数。其实做法和上一题一样，这里就不再重复了。不过有一点我们必须抱有疑问，我们知道这类函数的参数数量是不确定的，但如果想要钩取一个函数，我们就需要给定一个确定的参数列表，这样才能定义 run 方法。

这个问题我们留待以后阅读源代码再做考虑。至少目前来看，Angr 已经完善了 scanf 函数的 hook 了，我们可以直接一把梭解决这个问题。

既然我们是通过钩取函数来解决某个函数的路径爆炸问题，那么就肯定会遇到这么一种情况：函数的某部分引发路径爆炸，但其他部分在做必要的运算 。

本题就可以发现，循环判断语句嵌在 main 函数中，我们显然不能直接把整个 main 函数 hook 掉，那样就和直接读代码逆向没区别了。

Angr 提供了一种名为 Veritesting 的算法，它能够让符号执行引起在 动态符号执行DSE 和 静态符号执行SSE 之间协同工作从而减少路径爆炸的问题。

在 Angr 中只需要为 project.factory.simgr 添加一个参数 veritesting=True 即可开启。

不过不得不说的是，这个方法看起来好像很万能，其实并没有想象中的那么好用。对于本题的这个体量来说，笔者执行了约 5 次才有一次能够迅速的算出结果。可想而知，对于体积稍微大一些，类似的循环稍微多一些的程序来说，这个方法并不能带来多大的提升，反而会让人难以猜测程序究竟是卡在路径爆炸中还是仍然处于计算。

因此对于一些简单的问题，笔者虽然推荐这个方法，但只要问题稍微复杂一点，它甚至会增加人力负担。

程序本身也并不复杂，和上一题的主要区别在于，这次使用了静态编译去生成二进制文件。

本身 Angr 是在库函数装载时钩取这些函数的，静态编译的程序没有这个过程，因此道理上就会被主动分析，这就会带来很大的消耗了，因此本题需要钩取那些静态编译生成的库函数。

其实差异不大，在上一篇文章中提到过，angr 内置了多个库函数，既然现在它无法自动钩取，由我们手动去做这件事就行了：

这道题的特殊情况在于程序加载了额外的动态库并使用其中的函数。由于这个动态库是用户编写的，Angr 不能找到替代品去 hook 。而我们其实也不方便直接加载它，因为通过 auto_load_libs 会把其他无关紧要的东西一起加载进来。

不过好在，这道题的主要逻辑全都放在了动态库中，这就能简化我们的操作了。

我们可以使用 call_state 来完成操作：

另外，我们将该函数的加载基址设到了 0x400000 。

然后就是对参数的内容进行符号化：

最后就是求解方程了：

不过因为校验返回值的内容并不在库文件，所以我们需要手动通过 add_constraints 来为状态添加约束。

当然，用 res.solver.add 也是可以的：

不过需要区别的是，add_constraints 的约束是对状态所做的，而 res.solver.add 是对约束器做的。在本题中两个方法都行，但不能混用。

这次的题目就比较特殊了，它要求我们用 Angr 自动求解一个 payload，使得最终会溢出到变量 v5 来修改 puts 的参数。

其实思路很朴素，在函数调用 pust 时检查一下参数，看看它是不是 Good Job 字符串的地址即可。

不得不说，Angr 的功能确实强大，连自动化求解 payload 都能做到了。

目的是显然的，通过 __isoc99_scanf 来溢出，让 v5 指向 password_buffer 。

笔者本来是打算直接直接将结果卡在 strncpy ：

最后会发现这个写法是有问题的，Angr 最终会给出 No 。可以发现 Angr 对 find 的判断取决于每次进入基本块的第一个地址。

因为它并不以每一条指令进行判断，而是对每次状态执行一次 step 执行完整个基本块后，再调用 find 的条件进行判断。

不过，如果 find 本身是一个地址的话，却能够正常发现，有点奇怪，这个问题留到以后看源代码吧。

最后笔者试着这样去完成：

它能帮我算出 key 和 v4 的最后四字节，但是中间的前几位却一直算不出结果。如果您知道为什么还请告诉我。

最后还是修改了钩子钩取的地址来完成本题：

可以看见，如果我将判断的地址添加在 0x8048410 处，也就是 strncpy 的 plt 表上，就能够顺利解决这个问题了。

有些迷惑。

unk_4D4C4860 处为 %s

显然就是一个栈溢出了，但是这次需有让 Angr 自动去覆盖返回地址到 print_good 函数：

同样还是最开始那几个，但是注意，本题需要额外添加一个参数：

save_unconstrained=True 会让 Angr 保存那些不受约束的状态。其实默认情况下的状态就是未约束的。将这些路径保存下来以后，进行遍历：

为状态添加约束，去寻找同时满足 next_stack==0x4D4C4749 和 state.regs.eip==0x4D4C4785 的状态，然后给出该状态对应的 stdin 。

其实做完这么多题目，尽管感叹 Angr 确实厉害的同时，也不得不承认它仍然有很多的问题，也并没有想象中那么完美。或许要让它走向更加实用的方向还需要一定的积累吧。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课