Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Login to post

Java Serialized + Zlib + gzip

chrom | Last updated: Jun 06, 2016 09:07AM UTC

I have this issue and I can't seem to solve it without writing an extension. The java thick client communicates with the server by doing the following on the data part of the HTTP POST request: Client: - Java Serialized Object - gzip compression - zlib compression this reaches the server. So in order to be able to inspect and modify/fuzz the traffic I need to: - Open burp1 instance to insert the "Content-Encoding: deflate" header that is missing. Forward the request to burp2 - Set "unpack deflate / gzip in requests" at burp2. Use any JDSer plugin at this instance. Forward the request to burp3 - Here as I imagine it, I should perform the zlib compression, the gzip compression and send to server. This is the part that I have problems with as nothing that I try works and the server always responds with "java.util.zip.ZipException: incorrect header check java.util.zip.InflaterInputStream.read(InflaterInputStream ..." Should I expect an auto/header recognition of the compression method to burp in the near future? Is there any other way or suggestion that I should approach this? Thanks much.

Burp User | Last updated: Jun 06, 2016 09:17AM UTC

Correction: there is no separate gzip layer. The compression is done with zlib. Therefore the actual problem is that I can't configure burp to automatically re-compress the modified request with zlib.

PortSwigger Agent | Last updated: Jun 06, 2016 01:23PM UTC

You'll probably need to create an extension to handle this. You could implement it as a custom HTTP editor tab, which unpacks the underlying data for viewing/editing by the user, and then puts it back together again for sending. Problems with decompressing and recompressing messages between thick clients and servers often occur because they aren't strictly standards compliant, because they don't need to be. Because the app controls both ends of the communication, it can make assumptions about details of the compression implementation that normally need to be negotiated or correctly described in headers etc. So you might end up having to hard-code the compression to work in a specific way, based on trial and error.

You need to Log in to post a reply. Or register here, for free.