Pentesting with Serialized Java Objects and Burp Suite

Some days ago, I had to test a web application consisting in a Java applet. Like always, I direct all traffic through my favourite HTTP Proxy, Burp Suite, but the applet doesn’t seem to work.

After many trying and with the useful Java console (How to enable Java console:, we succeeded in make the applet work through the proxy. In detail:

  • the applet worked only on Internet Explorer (Firefox doesn’t seem to pass correctly the cookies to the Java applet)
  • the applet raised many exception because Burp Suite unpacked responses, packed in gzip, and the applet expected packed responses.

To make it work, it was necessary to deflag the corresponding option in Burp Suite, flagged by default:

Burp Suite - Proxy options

Burp Suite – Proxy options

After the unflag, the applet begin to work with Burp Suite as a proxy. Good. But now each request is a “Serialized Java Object” and each response is a “Gzipped Serialized Java Object”, not so good for reading (and even worse for pentesting).

Googleling, I found two Burp plugins, created for working with Serialized Java Obects:

The first one was developed times ago, before the new “Burp Extender”. It needs the applet JAR in the Classpath (and so Burp Suite have to be executed with a custom command); it works well but it is not comfortable to use, because it put the deserialized content in the “Edited request” TAB, making difficult to distinguish actually edited requests from the others. It use XStream library ( to transform object in XML.

The second one is newer and, in my opinion, more comfortable for penetration testing. In fact, it add a new TAB “Deserialized Java” in the request and response TAB, when a serialized content is found.

This plugin use a defined Java ClassLoader for deserialization, feeded with the target applet Jar, and XStream to transform object in XML.

Unfortunately, I didn’t succeed in make the newer plugin work correctly. The plugin deserialized correctly but raise an exception in the reserialization phase (when editing a request). It seems that XStream Library needs Class definitions of target applet classes but this plugin doesn’t make use of a custom ClassPath containing target applet JAR, and so, it raised an exception.

So I edited the code of the newer plugin, in order to fix the problem of reserialization and adding some code to unzip gzipped responses.

This new plugin can be found here:

For this plugin, a few things are necessary:

  • The applet JAR of target application (The download can be done viewing HTML response from the page that loads Java applet and searching for the applet tag)
  • XStream library (I used xstream 1.4.2)

Then, for using the plugin, Burp must be executed in this way:

java -Xmx512m -classpath “PATH_BURP_JAR;PATH_XSTREAM_JAR;PATH_APPLET_JAR” burp.StartBurp


  • PATH_BURP_JAR is the path of the JAR of Burp Suite
  • PATH_XSTRAM_JAR is the path of JAR of XStream libray
  • PATH_APPLET_JAR is the path of the JAR of target applet (if there are more JARs, simply add all the JARs to the classpath or put all the JARs in a folder and use a wildcard)

After Burp started, the plugin can be loaded in Burp Extender TAB, as any other plugin.

Now, if the request or response are serialized, a new TAB will show the deserialized object in XML. It is also possible to edit intercepted request and use the Repeater. If the response is serialized (or gzipped and then serialized), a new TAB will show the deserialized object.