The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

WCF binary decode failure

Imre | Last updated: May 12, 2015 01:45AM UTC

I'm testing a fat client application that passes all its traffic through SSL, WCF binary encoded. It also looks like it is being compressed (Content-Type: x-deflate) which adds another level of PiTA. I'm using the "WCF Binary Helper" extension (props to Brian Holyfield and Nick Coblentz), which has worked fine for all applications that I have previously tested that use this method. However, it doesn't work at all for this one. Both requests and responses stay encoded and the WCF helper doesn't recognize the requests as such so no help there. In place of a screenshot, the application response is essentially the following header followed by encoded gobeldygook. HTTP/1.1 200 OK Content-Length: 1106 Content-Type: application/x-deflate Server: Microsoft-HTTPAPI/2.0 Date: Mon, 11 May 2015 21:39:41 GMT [encoded caca] Any thoughts as to what is going on? Burp is traditionally good at decoding x-deflate and WCF binary.

PortSwigger Agent | Last updated: May 12, 2015 08:02AM UTC

It is possible that the deflate decompression and the WCF decoding aren't playing well together. Have you tried splitting these steps into separate instances Burp? Something like: Browser -> Burp performing deflate decompression -> Burp performing WCF decoding -> target

Burp User | Last updated: May 12, 2015 06:26PM UTC

That sounds promising. How would you do such a thing? There does not appear to be a means to separate steps within Burp.

PortSwigger Agent | Last updated: May 13, 2015 07:57AM UTC

You would run two Burp instances, with the first configured to use the second as its upstream proxy. Then you can apply different processing at each hop, and view the before/after messages.

Burp User | Last updated: Mar 26, 2018 08:10AM UTC