0

I've recently set up a mitmproxy on my phone and it seems to work fine. It intercepts that request for https websites and I can view their content.

But I'm trying to intercept data from a banking app I have on my phone. The connection works perfectly fine and I can see all of the requests that get sent from my phone on the console. Except I don't know how to make sense of the response or the payload. It looks a bit like it's encrypted but I'm not sure if it is.

Can the data still be encrypted even though I've installed the mitm cert and am able to view other https responses and payloads?

Updated

As pointed out by schroeder and Robert, the response is likely encoded rather than encrypted. After going through the common encoding algorithms: gzip, deflate, and trying to decompress the payload, I'm unable to figure out which encoding was used for this. Here are some screenshots. I was wondering if someone could point out possibly what encoding was used or whether I'm still stuck with the XY problem.

the request payload from mitmproxy

schroeder
  • 123,438
  • 55
  • 284
  • 319
KZoeps
  • 101
  • 2
  • 4
    This looks like an [XY Problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). You can't read the packets, so you're asking about encryption. It's possible that the payload is encoded. And it's possible that there is application-level encryption. – schroeder Mar 28 '22 at 08:38
  • 2
    Applying a custom encryption on data before sending them through a TLS channel is possible but unusual. More likely is that you don't understand the used encoding or the data is compressed in a way that mitmproxy does not understand. Check the headers of requests and response for possible compression indications and decompile the app to get the used data format. – Robert Mar 28 '22 at 09:33
  • hi @Robert so i looked into the request headers and because of the presence of `accept-encoding: gzip` , i tried decompressing the payload with a gzip decompressor online but it said the format wasn't a gzip. As for the decompiling the app its still in progress but was wondering if you had some pointers in response of the attached screenshot – KZoeps Mar 31 '22 at 13:38
  • Yes, it's possible. Especially for banking: banking has to transmit a bunch of data across *unencrypted* connections (think credit card readers) so it can do its own encryption. You might want to try decompiling/reverse-engineering the app – user253751 Mar 31 '22 at 13:43
  • That's a ***field*** that has encoded/encrypted data. So, your question needs to be completely reframed. It has nothing to do with TLS. You are successfully seeing the unencrypted payload from TLS. Your question ***now*** is "what's this field?" And that's no longer a security question. – schroeder Mar 31 '22 at 13:57
  • Your screenshot shows the request but you are always talking about the response. Just a mistake or is the data in the screenshot unrelated? The screen shot most likely shows a base64 encoded data (the `=` sign at the end is a good indicator for base64 encoded data). – Robert Mar 31 '22 at 14:03

0 Answers0