Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Decoding Gzip/Deflate issues

sikocan | Last updated: Nov 19, 2017 11:53AM UTC

I'm trying to read the contents of packets sent from an Android device and some packets where Burp can detect Gzip compression, it shows the contents, however there are often times I see packets with this information and Burp can't decode or can't detect compression. How can I see the contents of this compressed packet contents? The following is from a Android phone, manufacturer I suspect is collecting/spying on it's users with the activity of the phone to a head office, I'm curious to know what information it collects. Any help is appreciated. I've tried copying and pasting the compressed portion to a file and extracting using decompression software :) It didn't work. For example this packet: OST /tracker-api/tracker/trackerLog HTTP/1.1 Connection: close Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Linux; U; Android 6.0; en-au; 5044T Build/MRA58K) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Mobile Safari/537.36 Host: tracker-global.tclclouds.com Accept-Encoding: gzip, deflate Content-Length: 579 e=v3&data=gDm8W6MSWo42svBtqRQ56SCoDX4m_kjv9HH9hwM5iF1QyXHfvGM5t-RI1vV3uOeSOuGgdCj64MxW 193i3cdbzbnYbixJUZtVgICZ1Mygh6ysINqwCUq_S22ToPgoPPmi9MWJ3Eft7hGWVoanpfHwDH4e ZwYhm4ovkDe8awCTTRV_nLhzogLuRBRRCLBVCJsGWSe9UoT4O8vSzeraqlYFQOTK55B1UjrYQHmm laVLUPzz9OXetIC77b1Z5ngW32binYxrCir_tB3waUA-QEQy2Ht2c1TMc9dlVaC58i0O3-Sw406R CsXZGjHoScC44NavPoDhk_Kwo92U-bvee5m91HuXms91A9xBPzsrz56YU5LA5ege6R0yI7xrwpEA SYxLO8gyqHuSiF-yid34nB0C1wtleV9wEytfhVR0QiySXp60wL4n_8ZRJHZ9IYhmz-TdK6Hyg1st 74zvtTzWYOwp9fi2PAoc3BJawBbNgqSc8w38pe3MIdW21DCSj0M7_J8IOZJj1yYaYEprMuucrWzr Qg== &expect_server_compress=1

PortSwigger Agent | Last updated: Nov 20, 2017 10:47AM UTC

Hi Sikocan, This POST request is not gzip encoded. The Accept-Encoding header is telling the server that the client will accept a response that is gzip encoded. The request itself is not. If it was, it could have a Content-Encoding header. The data parameter is encoded in some application-specific manner. You can decode the base64 data using Decoder, but figuring out the actual data will require manual investigation. If you capture a number of requests, you may be able to figure out the data content. Otherwise, you will need to decompile the Android application.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.