Editing Serialized Java Objects in Burp Suite with BurpJDSer-ng
Hook
When you intercept a Java Web Start application’s traffic and see nothing but binary gibberish where parameters should be, you’re staring at serialized Java objects—opaque by design, but not impenetrable.
Context
Java serialization has been a security testing nightmare for decades. While modern web applications communicate with JSON or Protocol Buffers, countless enterprise systems still rely on Java’s native serialization to exchange complex object graphs between clients and servers. The problem for penetration testers is brutal: these serialized streams are binary blobs that reveal nothing about their contents. You can’t read them, you can’t modify them, and you certainly can’t test how the application handles malformed input without specialized tooling.
Burp Suite extensions have attempted to solve this problem before, notably khai-tran’s original BurpJDSer. But when Burp migrated from the legacy Extender API to the modern Montoya API, these older plugins stopped working with current Burp versions. BurpJDSer-ng emerges as a from-scratch rewrite that preserves the core functionality—deserializing binary Java objects into editable XML—while embracing Burp’s contemporary extension architecture. It’s specifically valuable for testing thick client Java applications, Java Web Start programs, and legacy enterprise systems where serialized objects flow over HTTP.
Technical Insight
BurpJDSer-ng operates as a message editor tab within Burp Suite, automatically detecting serialized Java content in HTTP requests and responses. The plugin’s architecture revolves around three key components: a custom classloader that dynamically loads JAR files specified by the user, XStream for bidirectional Java-to-XML conversion, and integration with Burp’s message editor system.
The classloading mechanism is critical because Java deserialization requires class definitions to reconstruct objects. When your target application sends a serialized object like com.acme.UserProfile, the JVM needs to know what UserProfile looks like—its fields, types, and structure. BurpJDSer-ng solves this by letting you load the client-side JAR files (often discoverable in browser caches or extracted from .jnlp files using tools like jnlpdownloader) into its classloader. Without these JARs, deserialization fails with ClassNotFoundException errors.
XStream handles the translation layer. When BurpJDSer-ng detects a serialized Java stream, it feeds the byte array to XStream, which reconstructs the Java object and renders it as XML. You can edit this XML directly in the Burp interface through the Java Object tab that appears in proxy history, interceptor, repeater, and other appropriate locations. Make your changes, switch tabs or send the request, and BurpJDSer-ng automatically re-serializes the modified XML back into binary Java format. The application receives a valid serialized object with your changes.
The repository includes a working example demonstrating this workflow. Running ./gradlew runExample starts a simple Java application that posts serialized objects to a local server. The corresponding JAR file at ./build/libs/example-main-SNAPSHOT.jar contains the class definitions. Load this JAR in the plugin’s JDSer tab, intercept the example application’s traffic in Burp, and the serialized payload appears as editable XML in the Java Object tab. It’s an elegant sandbox for understanding the plugin before using it against real targets.
The Montoya API integration is what makes this plugin viable for modern Burp Suite versions. The plugin integrates with Burp’s message editor system, automatically creating a custom editor tab when serialized Java content is detected. Changes trigger the serialization pipeline in reverse: XStream converts your edited XML back to Java objects, and standard Java serialization writes it to bytes. This seamless integration means you work within Burp’s familiar interface—no external tools, no copying payloads to command-line utilities.
Gotcha
The most significant limitation is the JAR file discovery requirement. BurpJDSer-ng cannot deserialize classes it doesn’t have definitions for, which means you’re hunting for client-side JARs before you can analyze anything. For applications with dozens of dependencies, this becomes tedious. You load one JAR, attempt deserialization, get a ClassNotFoundException for some nested dependency class, hunt for that JAR, repeat. The README suggests checking browser caches and Burp history (and using jnlpdownloader for .jnlp files), but with obfuscated or stripped JAR files, you might hit dead ends. The plugin’s JDSer tab allows you to add JAR files iteratively when class-not-found errors occur.
XStream itself carries security considerations. While the plugin uses XStream for controlled deserialization scenarios where you’re inspecting data, XStream has historically had vulnerabilities related to processing untrusted XML. This isn’t a direct threat to your testing workflow—you control the XML you’re editing—but it means the plugin should be used carefully. Additionally, XStream’s XML representation may not always be intuitive for complex Java objects.
Finally, BurpJDSer-ng is locked to native Java serialization. If your target uses Kryo, FST, Hessian, or any other JVM serialization library, this plugin offers no help. Modern applications increasingly avoid native Java serialization precisely because of its security reputation, so you may find fewer opportunities to use this tool than you’d hope.
Verdict
Use BurpJDSer-ng if you’re penetration testing Java applications that rely on native serialization—particularly thick clients, Java Web Start apps, or legacy enterprise systems where you can obtain client-side JAR files. It transforms an otherwise opaque testing scenario into something manageable, letting you manipulate object parameters through an XML interface. Skip it if your targets use modern serialization formats (JSON, Protobuf, MessagePack), or if you cannot access the necessary JAR files to enable deserialization. The plugin excels in a specific niche—interactive manipulation of serialized Java objects during manual security assessments—and within that niche, it’s invaluable for making the invisible visible and the immutable editable.
