测量吞吐量
在存储测试/基准测试方面，灵活的 I/O 测试器是常用的解决方案。让我们在不加密的情况下模拟 ramdisk 上具有 4K 块大小的简单顺序读/写负载
上述命令将运行很长时间，因此我们过一会儿就停止它。从统计数据中我们可以看到，我们能够以大致相同的吞吐量进行读写1126 MB/s。让我们用加密的 ramdisk 重复测试
哇，速度下降了！我们~147 MB/s现在只能得到现在的速度，速度慢了 7 倍以上！而且这是在一台完全空闲的机器上！
在存储测试/基准测试方面，灵活的 I/O 测试器是常用的解决方案。让我们在不加密的情况下模拟 ramdisk 上具有 4K 块大小的简单顺序读/写负载
上述命令将运行很长时间，因此我们过一会儿就停止它。从统计数据中我们可以看到，我们能够以大致相同的吞吐量进行读写1126 MB/s。让我们用加密的 ramdisk 重复测试
哇，速度下降了！我们~147 MB/s现在只能得到现在的速度，速度慢了 7 倍以上！而且这是在一台完全空闲的机器上！
深入源代码
当尝试使用dm-crypt上面描述的自定义选项时，我们很好奇它们为什么会存在，以及“卸载”到底是怎么回事。最初我们期望dm-crypt它是一个简单的“代理”，它只是在数据流经堆栈时对其进行加密/解密。结果发现dm-crypt它的作用不仅仅是加密内存缓冲区，下面给出了一个（简化的）IO 遍历路径图
当文件系统发出写入请求时，dm-crypt不会立即处理它 - 而是将其放入名为“kcryptd”的工作队列 中。简而言之，内核工作队列只是安排一些工作（在本例中为加密）在以后更方便的时候执行。当“时间”到来时，将请求发送到Linux Crypto API进行实际加密。但是，现代 Linux Crypto API也是异步的，因此根据您的系统将使用哪种特定实现，很可能不会立即处理它，而是再次排队等待“稍后”。当 Linux Crypto API 最终进行加密时，可能会尝试通过将每个请求放入红黑树中来对待处理的写入请求进行排序。然后，一个单独的内核线程再次在“稍后”实际获取树中的所有 IO 请求并将它们发送到堆栈下方。dm-crypt dm-crypt
现在对于读取请求：这次我们需要先从硬件获取加密数据，但dm-crypt不仅仅是向驱动程序请求数据，而是将请求排队到名为“kcryptd_io”的另一个工作队列 中。稍后，当我们真正拥有加密数据时，我们会使用现在熟悉的“kcryptd”工作队列安排它进行解密。“kcryptd”将请求发送到 Linux Crypto API，后者也可能异步解密数据。
当尝试使用dm-crypt上面描述的自定义选项时，我们很好奇它们为什么会存在，以及“卸载”到底是怎么回事。最初我们期望dm-crypt它是一个简单的“代理”，它只是在数据流经堆栈时对其进行加密/解密。结果发现dm-crypt它的作用不仅仅是加密内存缓冲区，下面给出了一个（简化的）IO 遍历路径图
当文件系统发出写入请求时，dm-crypt不会立即处理它 - 而是将其放入名为“kcryptd”的工作队列 中。简而言之，内核工作队列只是安排一些工作（在本例中为加密）在以后更方便的时候执行。当“时间”到来时，将请求发送到Linux Crypto API进行实际加密。但是，现代 Linux Crypto API也是异步的，因此根据您的系统将使用哪种特定实现，很可能不会立即处理它，而是再次排队等待“稍后”。当 Linux Crypto API 最终进行加密时，可能会尝试通过将每个请求放入红黑树中来对待处理的写入请求进行排序。然后，一个单独的内核线程再次在“稍后”实际获取树中的所有 IO 请求并将它们发送到堆栈下方。dm-crypt dm-crypt
现在对于读取请求：这次我们需要先从硬件获取加密数据，但dm-crypt不仅仅是向驱动程序请求数据，而是将请求排队到名为“kcryptd_io”的另一个工作队列 中。稍后，当我们真正拥有加密数据时，我们会使用现在熟悉的“kcryptd”工作队列安排它进行解密。“kcryptd”将请求发送到 Linux Crypto API，后者也可能异步解密数据。
使用全部
让我们一起来看看使用它们的过程。第一步是获取补丁并重新编译内核（或者只是编译dm-crypt我们的xtsproxy模块）。
接下来，让我们在单独的终端中重新启动我们的 IO 工作负载，这样我们就可以确保我们可以在负载下运行时重新配置内核
让我们一起来看看使用它们的过程。第一步是获取补丁并重新编译内核（或者只是编译dm-crypt我们的xtsproxy模块）。
接下来，让我们在单独的终端中重新启动我们的 IO 工作负载，这样我们就可以确保我们可以在负载下运行时重新配置内核
❤1
投入生产
到目前为止，我们一直在使用合成设置，其中缺少完整生产堆栈的某些部分，例如文件系统、实际硬件以及最重要的生产工作负载。为了确保我们不是在优化虚构的东西，下面是这些更改给我们堆栈的缓存部分带来的生产影响的快照
该图表显示了我们其中一台服务器中缓存命中的最坏情况响应时间（第 99 个百分位）的三向比较。绿线来自具有未加密磁盘的服务器，我们将其用作基准。红线来自具有加密磁盘并使用默认 Linux 磁盘加密实现的服务器，蓝线来自具有加密磁盘并启用了我们的优化的服务器。我们可以看到，默认的 Linux 磁盘加密实现在最坏情况下对我们的缓存延迟有显著影响，而修补后的实现与根本没有使用加密没有区别。换句话说，改进的加密实现对我们的缓存响应速度没有任何影响，所以我们基本上是免费获得的！这是一个胜利！
到目前为止，我们一直在使用合成设置，其中缺少完整生产堆栈的某些部分，例如文件系统、实际硬件以及最重要的生产工作负载。为了确保我们不是在优化虚构的东西，下面是这些更改给我们堆栈的缓存部分带来的生产影响的快照
该图表显示了我们其中一台服务器中缓存命中的最坏情况响应时间（第 99 个百分位）的三向比较。绿线来自具有未加密磁盘的服务器，我们将其用作基准。红线来自具有加密磁盘并使用默认 Linux 磁盘加密实现的服务器，蓝线来自具有加密磁盘并启用了我们的优化的服务器。我们可以看到，默认的 Linux 磁盘加密实现在最坏情况下对我们的缓存延迟有显著影响，而修补后的实现与根本没有使用加密没有区别。换句话说，改进的加密实现对我们的缓存响应速度没有任何影响，所以我们基本上是免费获得的！这是一个胜利！
ysoserial-CommonsCollections系列总结篇
前言：
网上分析CommonsCollections调用链的文章也有不少，但是看完分析文章直接手动构造利用链仍有难度，因此这篇文章主要总结本人调试ysoserial的CommonsCollections系列利用链的思考和体会，通过这篇文章希望大家能够了解CommonsCollections不同链之间的共性和区别，能够在看完gadget后可以手动构造利用链，本文主要内容包括以下几点：
1.每条反序列化利用链的构成特点
2.每条链不同类之间衔接的特点及要点
3.对比不同利用链之间的区别以及相似点
4.自己如何根据链接点的特性来构造反序列化exp
5.如何混合搭配链接点从而形成一条新的gadget利用链(例如cc5、cc6、cc7分别扩展2条、2条、1条)
前言：
网上分析CommonsCollections调用链的文章也有不少，但是看完分析文章直接手动构造利用链仍有难度，因此这篇文章主要总结本人调试ysoserial的CommonsCollections系列利用链的思考和体会，通过这篇文章希望大家能够了解CommonsCollections不同链之间的共性和区别，能够在看完gadget后可以手动构造利用链，本文主要内容包括以下几点：
1.每条反序列化利用链的构成特点
2.每条链不同类之间衔接的特点及要点
3.对比不同利用链之间的区别以及相似点
4.自己如何根据链接点的特性来构造反序列化exp
5.如何混合搭配链接点从而形成一条新的gadget利用链(例如cc5、cc6、cc7分别扩展2条、2条、1条)
对于cc1(以下cc即代表commonscollections)来说最外层的Annotationinvocationhandler相当于只是一个容器作用，将动态代理proxy放到其this.memberValues成员方法中去，其中invocationhandler又是一个Annotationinvocationhandler，然后在其readobject方法中就会调用this.memberValues.entryset,从而触发动态代理，从而进入动态代理的invoke函数代码块
因此invoke函数中调用this.memberValues.get即调用lazymap.get，从而到了this.factory.transform()，接下来内部是chainedTransformer+constantTransformer+3层invokeTransformer，因为get的参数是不存在的entryset，所以需要constantTransformer先返回一个Runtime类再通过3个invokeTransformer联合起来反射rce执行命令。
因此invoke函数中调用this.memberValues.get即调用lazymap.get，从而到了this.factory.transform()，接下来内部是chainedTransformer+constantTransformer+3层invokeTransformer，因为get的参数是不存在的entryset，所以需要constantTransformer先返回一个Runtime类再通过3个invokeTransformer联合起来反射rce执行命令。
CommonsCollections2
反序列化调用链如下所示：
PriorityQueue.readObject()
PriorityQueue.heapify()
PriorityQueue.siftDown()
PriorityQueue.siftDownUsingConparator()
TransformingComparator.compare()
InvokerTransformer.transform()
TemplatesImpl.newTranformer()
Method.invoke()
Runtime.exec()
cc2的利用PriorityQueue队列键值反序列化后进行key值比较，可以自定义比较器comparator，因此利用commonscollections4里面的TransformingComparator，在该类的compare函数中又会调用this.transformer.transform来对key进行转换，因为key是从外面直接传进来的，即可控的，这里key其实是一个templatesimpl的实例。
反序列化调用链如下所示：
PriorityQueue.readObject()
PriorityQueue.heapify()
PriorityQueue.siftDown()
PriorityQueue.siftDownUsingConparator()
TransformingComparator.compare()
InvokerTransformer.transform()
TemplatesImpl.newTranformer()
Method.invoke()
Runtime.exec()
cc2的利用PriorityQueue队列键值反序列化后进行key值比较，可以自定义比较器comparator，因此利用commonscollections4里面的TransformingComparator，在该类的compare函数中又会调用this.transformer.transform来对key进行转换，因为key是从外面直接传进来的，即可控的，这里key其实是一个templatesimpl的实例。
在打fastjson1.2.24中就用到了jdk的templatesimpl这个内置类，在其_bytecodes字段中放入恶意类的字节码，将在调用其getTransletInstance中进行实例化，所以这里只需要一个invoketransformer即可，直接反射执行调用templatesImpl的newTransformer或者getoutputProperties来实例化templates的_bytecodes字段中的类进行rce
CommonsCollections2.java
CommonsCollections2.java
PHP-FPM 远程代码执行（CVE-2019-11043）
PHP-FPM 是 PHP 的 FastCGI 实现。在 PHP 版本 7.1.x 低于 7.1.33、7.2.x 低于 7.2.24 和 7.3.x 低于 7.3.11 中，在某些 FPM 设置配置中，可能会导致 FPM 模块将过去分配的缓冲区写入为 FCGI 协议数据保留的空间，从而打开远程代码执行的可能性。
该漏洞最早是在 Real World CTF 2019 Quals（由 Chaitin Tech 组织）期间发现的。它会影响使用 PHP-FPM 时存在某些错误配置的 Nginx 服务器，最常见的易受攻击的配置包括location ~ [^/]\.php(/|$)规则。
PHP-FPM 是 PHP 的 FastCGI 实现。在 PHP 版本 7.1.x 低于 7.1.33、7.2.x 低于 7.2.24 和 7.3.x 低于 7.3.11 中，在某些 FPM 设置配置中，可能会导致 FPM 模块将过去分配的缓冲区写入为 FCGI 协议数据保留的空间，从而打开远程代码执行的可能性。
该漏洞最早是在 Real World CTF 2019 Quals（由 Chaitin Tech 组织）期间发现的。它会影响使用 PHP-FPM 时存在某些错误配置的 Nginx 服务器，最常见的易受攻击的配置包括location ~ [^/]\.php(/|$)规则。
使用 Ghidra 分析 phpStudy 后门
这次事件已过去数日，该响应的也都响应了，虽然网上有很多厂商及组织发表了分析文章，但记载分析过程的不多，我只是想正儿八经用 Ghidra 从头到尾分析下。
1. 工具和平台
主要工具：
Kali
Ghidra 9.0.4
010Editor 9.0.2
样本环境：
Windows7
phpStudy 20180211
2. 分析过程
先在 Windows 7 虚拟机中安装 PhpStudy 20180211，然后把安装完后的目录拷贝到 Kali Linux 中。
根据网上公开的信息：后门存在于 php_xmlrpc.dll 文件中，里面存在“eval”关键字，文件 MD5 为 c339482fd2b233fb0a555b629c0ea5d5。
这次事件已过去数日，该响应的也都响应了，虽然网上有很多厂商及组织发表了分析文章，但记载分析过程的不多，我只是想正儿八经用 Ghidra 从头到尾分析下。
1. 工具和平台
主要工具：
Kali
Ghidra 9.0.4
010Editor 9.0.2
样本环境：
Windows7
phpStudy 20180211
2. 分析过程
先在 Windows 7 虚拟机中安装 PhpStudy 20180211，然后把安装完后的目录拷贝到 Kali Linux 中。
根据网上公开的信息：后门存在于 php_xmlrpc.dll 文件中，里面存在“eval”关键字，文件 MD5 为 c339482fd2b233fb0a555b629c0ea5d5。