1

Do network packets capture what gets encrypted in my device before it gets sent to the host? For instance. In instagram when you log in from a mobile device. You submit a post request. In that post request they have username, password and a parameter called "signed_body" it's value is hashed(encrypted) so each user has a unique signed_body value.

So far I'm sniffing packets from my iOS device. I get packets using wireshark. I have bunch of packets. So I was wondering do these packets have the decrypted signed_body value. GOAL = (If they did, I'd get that value and hash it myself and make calls to instagram server in a accepted format).

Just so people get what signed_body looks like. I'm sniffing HTTP protocols using MiTM Proxy. Instagram hashes these signed_body to every user and almost every requests so it's unique everytime. So I was assuming that wireshark gives me all the packets in which one them might be the decrypted key enter image description here

The data is in hex mode. enter image description here

Improve this question
8
  • 1
    Your question is a bit confusing, but if I'm reading correctly, you're misunderstanding how SSL/TLS works. It isn't being encrypted on your router, it's being encrypted on your mobile device. Once it leaves the device there is no way to decrypt it.
    – Xander
    Commented Sep 20, 2016 at 0:00
  • @Xander Gotcha! Nah you read it right. There isn't a way to decrypt that data reading packets?
    – Biplov Dahal
    Commented Sep 20, 2016 at 0:03
  • @Xander I'm farily a begineer to packets/networking. I'm assuming that network packets don't capture what gets encrypted in iphone device, right?
    – Biplov Dahal
    Commented Sep 20, 2016 at 0:04
  • @Xander But the thing I'm trying to say is - To log in you must make a .post request. That's actually when they hash their actual signature_key(decrypted version). Or else it would'nt have been unique for every users right?
    – Biplov Dahal
    Commented Sep 20, 2016 at 0:15
  • My guess is that the string "signed_body" is a MITM proxy thing. i.e. it calls the content of a TLS request as "signed_body". I never used mitmproxy but I believe that you can change that [m:Auto] into [m:hex] and that will give us a better idea of what data is being sent.
    – grochmal
    Commented Sep 20, 2016 at 0:22

1 Answer 1

Reset to default
1

We can see (in the hexdump) that the POST request payload is urlencoded, and contains two values: signed_body and ig_sig_key_version. The former contains a string which is composed of 64 characters (which are likely a hex representation of 32 bytes) followed by a dot and a JSON, the later is an integer. And that is the payload.

TLS transports this payload over an encrypted (and trusted, unless you're in a mitmproxy and you force-trust it) connection. And that is all that TLS does. In simple words, you're confusing OSI layers, TLS protects the transport layer but the payload is on application layer. TLS will transfer any payload in the same way, i.e. had the payload contained clowns= instead of signed_body= TLS would not care at all.

Whatever signed_body is (apart from being a JSON containing your username, password and device info) depends on the instagram app design, yet it definitely is completely unrelated to TLS. They may or may not use some form of crystallographic hash to generate the first 64 characters from the JSON content plus some random number. Or (more likely) they use those 64 characters as a CSRF protection token, which is exchanged with the server on each request.

Improve this answer
6

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .