CC7 与CC5类似，后半还是LazyMap.get()链子 直接看链子，get()确实很多调用的 java.util.AbstractMap123456789101112131415161718192021222324252627282930313233343536public boolean equals(Object o) { if (o == this) re

CC5 这里从 org.apache.commons.collections.map.LazyMap#get开始找，但是get方法的调用非常多，find usage就有2k+。代码审计老哥直接哭晕在厕所。 commons.collections4的 LazyMap去掉了函数 decorate。 直接看链子 后半还是CC1的LazyMap，前半则是 BadAttributeValueExpExcep

CC2 前几天意识到一个问题，就是链子在序列化之前就触发了的事，这次将序列化和反序列分开，是不是好看一点。 CC2 链区别与其他链子一点的区别在于没有用 Transformer 数组。不用数组是因为比如 shiro 当中的漏洞，它会重写很多动态加载数组的方法，这就可能会导致我们的 EXP 无法通过数组实现。 CC2就是CC4翻版，在使用 InstantiateTransformer初始化 TrAX

CC4 CommonsCollections4 除 4.0 的其他版本去掉了 InvokerTransformer 的 Serializable 继承，导致无法序列化。 环境JDK8u65 maven添加依赖 123456789101112131415161718<dependencies> <dependency> <groupId>com

hexo博客中图片有几种方式存储，网络链接，本地图片 网络链接网络链接说实话其实是最好的，但是需要一个图床储存。 使用格式如下： 1 就是不知道图片那天死了（无法访问）都不知道。加载也是问题，吃网络，不是很需要担心，没那么可怕。 本地文件全局资源文件夹在source目录下创建一个目录存储图片。 1source/image 使用 1![](image/

刚开始学习JAVA还是有点蒙的，但好在坚持下来了。 CC3链与CC1和CC6区别很大，CC3是通过动态加载类机制实现自动执行恶意代码。 恶意类Calc 1234567891011import java.io.IOException;public class Calc { static { try { Runtime.getRu

CC6不受jdk版本约束 CC6 = CC1 + URLDNS 前半还是LazyMap.get() => ChainedTransformer.transform() 直接使用 ChainedTransformer可以解决Runtime类不能反序列化的问题，配合ConstantTransformer类，又可以解决参数传递的问题。 分析org.apache.commons.

官方文档：https://fluid-dev.github.io/hexo-fluid-docs/start/ 评论这个功能需要配合一些第三方的api，因为是使用的github-page，所以就全套了，使用的是gitalk。 gitalk是基于issue的，先建立一个存储库，我建的是一个新库，记得public 1gitalk-comments 访问：https://github.com/se

真的是坑哭了，昨天本来先有空整个美美的blog，但是图片加载不出来。 本地展示hexo s 也是可以的，但只要 hexo d推送，没有任何的报错，仓库里也是有的，但是图片就是404。 我还找个同样主题的博客看了眼，也是可以的，不是404。 当时情况是储存图片的位置为/img，这是按照官方文档储存的。我自己有个github图床也是名叫 img，不知道是不是这个原因。 在自己写的文章的图片也是加载不出