回顾上上上…篇发布的文章《打造macOS下”最强”的微信取证工具》中使用 frida 工具从内存中获取到了关键数据，frida objc 的能力都来自于 frida-objc-bridge ，本着好奇探索心理想研究下原理，也没找到相关文章资料，倒是找到不少 frida-java-bridge 的文章。那么本文将从了解 Objective-C Runtime 开始，例如它的消息发送机制、Method Swizzling 等，再去探索 frida 中的 frida-objc-bridge 实现原理以及它最关键的 choose 方法的实现。

众所周知，由于移除了__malloc_hook/__free_hook/__realloc_hook等等一众hook全局变量，高版本glibc想要劫持程序流，离不开攻击_IO_FILE。而笔者近期在国外大佬博客中发现一条新的可利用的函数调用链，与house of apple2一样，只需要一次地址任意写，而且适用于目前所有的glibc版本，故在此结合源码和自己的理解总结分享，也感谢roderick师傅和whiter师傅的指导与支持。如果有哪里不对恳请师傅们斧正！

上一部分对afl如何实现反馈进行了较为详细的介绍，本文将对afl如何实现监控进行分析。监控是指afl能够成功运行目标程序、获取目标程序的反馈信息（运行状态）并判定此次运行是否有效（此次运行的样例是否增加了模糊测试的覆盖率、是否崩溃或超时），以更有效的指导下一次模糊测试及保存崩溃。

这是 喵喵 2022 Hackergame WriteUp 的第三篇，主要也是一些难度稍大的题目，以及喵喵的碎碎念。

这是 喵喵 2022 Hackergame WriteUp 的第二篇，主要包括一些难度稍大的题目，以 binary 类型为主。

希望师傅们看了都能有所收获喵~

前面几篇文章将afl的大部分内容都已经覆盖到了（编译、反馈到监控），最后一个部分主要讲afl是如何挑选样本并针对样本的数据进行变异的。通过之前的分析我们已经知道，编译的种子通过链表的形式形成种子队列，种子经过变异后如果能够触发目标程序新的行为，会作为新的种子队列存入到链表中。但是对于新一轮的模糊测试，挑选哪个种子进行变异以及如何变异尚未解决，本文主要阐述afl是如何挑选种子进行变异以及如何变异。

今年六月份见到了 CVE-2022-1134 ，这是 V8 在 Turbofan 中另一个很有意思的攻击面，提交者在这之后很详细的介绍了这个漏洞的利用方式，它的利用方法同之前的 Turbofan 有着很不一样，但却相当有意思的地方。

从今年4月份开始，慢慢接触高版本的glibc，高版本glibc的堆题也使得国内ctf比赛进入到一个新的时期

上一部分对afl-fuzz的总流程进行了概要性的阐述，接下来将会对关键的代码模块进行详细的分析。

先对afl-fuzz过程中反馈与监控机制的实现进行分析，反馈是指afl在对目标程序的模糊测试过程中，目标程序可以将本次运行过程中的状态反馈给afl。本文主要介绍该afl是如何具体实现分支信息的记录以及更高效的运行目标程序的。

PPL表示“受保护的流程”，但在此之前，只有“受保护的流程”。Windows Vista / Server 2008引入了受保护进程的概念，其目的不是保护您的数据或凭据。其最初目标是保护媒体内容并符合DRM（数字版权管理）要求。Microsoft开发了此机制，以便您的媒体播放器可以读取例如蓝光，同时防止您复制其内容。当时的要求是映像文件（即可执行文件）必须使用特殊的Windows Media证书进行数字签名（如Windows Internals的“受保护的过程”部分所述）。

好久以前，在我完成 Glibc2.23 的基本堆利用学习以后，IO_FILE 的利用就被提上日程了，但苦于各种各样的麻烦因素，时至今日，我才终于动笔开始学习这种利用技巧，实属惭愧。

近几年，由于堆利用的条件越来越苛刻，加之几个常用的劫持 hook 被删除，IO 的地位逐渐有超过堆利用的趋势，因此为了跟上这几年的新潮，赶紧回来学习一下 IO 流的利用技巧。

codeql是一款强大的静态扫描工具，通过codeql强大的自定义规则我们可以编写sql语句来搜索源码中我们可能感兴趣的代码。ctf中高版本libc的利用方法中很多都用利用了IO函数，即利用stdin/stdout/stderr->vtable 修改虚表指针指向对我们有用的伪造的vtable又或者其他存在可利用函数的_IO_xxx_jumps虚表，如：house_of_kiwi,因此我便诞生了使用codeql查找libc中所有跳转到IO的函数调用的想法，更方便的分析libc中的利用点，也看看能不能找出house_of_kiwi中使用的malloc_assert->fflush利用点。

第一部分介绍了afl插桩编译的过程，思考了很久才定下第二部分写些什么。本来打算第二部分详细解释插桩部分和forkserver的代码的，但是感觉如果对afl-fuzz的整体流程没有大致掌握的话，直接去描述细节会让人不理解为什么afl这部分要这样去设计，因此决定在第二部分将afl-fuzz的主要流程（main）和部分不是关键代码的函数给说清楚，后续再逐步对关键代码模块进行详细分析，j继而实现对afl模糊测试的解析。