Decoding network traffic from application to server?

Hello again.

So im confused. When i look at network traffic of an application i have been messing around with 90% of the traffic is gibberish. Is this because it is encrypted or because all applications send traffic that looks like gibberish in ascii? Is it possible to decode this traffic? I can only make sense of the http and https requests sent by the app. The rest of the traffic sent to its internet server is crazy nonsense, is it most likely encrypted? I mean lets say it isnt encrypted is there any way to figure out what is being transmitted back and forth between the application and server?

example of the gibberish traffic (ascii interpretation):

Compliments of WireShark:

.. .. …9: .M;.+L.. x[Leh.p. I….^.j .P…… E;..K~.. .6!…A. …….. M….y.j .nM….. a. ….. …..'." N…u\e) (more to it but you get the idea)

This particular packet was a (PSH, ACK) push acknowledge packet. How can i learn to read this network traffic? Now that i look at wireshark it is definitely decodable since wireshark is taking this gibberish and telling me that this piece of gibberish is the source ip and port number and that piece of gibberish is the data sent with the packet. since it deodes everything but the data in the packets thats all i need to figure out. someone please help me figure this out…

(Correct me if I'm wrong here anyone)

I believe that is because it is showing the ascii version of each individual byte in the packet. Each byte has eight 1's or 0's, and depending on the byte's "location" in the packet it means different things (such as the protocol type, where the packet is heading, where it came from, etc…). Wireshark compiles those into a hex format and ascii format for common viewing, but most data is not designed to be read in ascii or hex, so as a result looks like random giberish.

Here's an example of the TCP flags byte:

0 <- CWR 0 <- ECN-Echo 0 <- Urgent 1 <- Ack 0 <- Push 0 <- Reset 1 <- Syn 0 <- Fin

So 00010010, when changed into hex, is 0x12 (Which is displayed just as 12 on the view). 0x12 has no easily readable ascii representation, so wireshark would simply show that one as a dot (".").

As you can see, that particular byte has a plethora of meaning in the TCP structure, but when converted into ascii just looks like a dot.

Hope that makes sense.

Or a less convoluted answer: headers for lower level protocols aren't meant to be human readable. Nor is most of the other information being sent.

I understand, i think. so like lets say it is a game application. when you shoot at another player does the server receive anything human readable i.e. Player'Apescanfly' Usesgun(); Headshot(); Player2'jynx' bloodspatter(); and goesdown(); . Does the application send this information to the server in anyway that i can see and alter? Or is it sending it in all non human readable bits and bytes? Which would mean that there is no way to edit or even view network traffic? thanks for the replies.

apescanfly223 wrote: I understand, i think. so like lets say it is a game application. when you shoot at another player does the server receive anything human readable i.e. Player'Apescanfly' Usesgun(); Headshot(); Player2'jynx' bloodspatter(); and goesdown(); . does the application send this information to the server in anyway that i can see and alter? That what im trying to figure out. thanks so much for the replies.

To get to know things better, i'd reccomend you to go read a bit more about software enigneering in general and about sockets. The socket you're talking about in this case is an UDP.

Answering it fast: It is much better to store information on each individual bit or group of bits rather than storing big text strings, for the packets will be smaller and you'll be saving a lot of unecessary network processing.

PS: My english is not good enough and i don't really know if "network processing" is the right expression in this case. Please correct me if i'm wrong.

chess_rock wrote: The socket you're talking about in this case is an UDP. Not at all a certainty. Believe it or not, it can actually be TCP. So to answer the question about what exactly it sends, it all depends on the construction of course. If you use TCP then there is no need for an identifier for you as the server knows who you are through the connection. If UDP, then you do need an identifier, but it will probably not be your name and instead be just a numerical value. In fact, most things will probably just be values like that, as explained further down.

Answering it fast: It is much better to store information on each individual bit or group of bits rather than storing big text strings, for the packets will be smaller and you'll be saving a lot of unecessary network processing. Partially true; when you chat through a game, for instance, or assign names or anything like that, then you will be sending text (which whether it is encrypted or not will be human readable). This isn't something horrifyingly difficult for neither the network nor the game. What would be slow as fuck though (for the server) would be to receive every in game command as text. This would mean that instead of a quick evaluation of a value that it can map to an action, it would instead have to compare strings. Letter by letter against another word, then do the same if it doesn't match, all through every possibility until you either find a match or default to something else. It's slow.

COM wrote: Partially true; when you chat through a game, for instance, or assign names or anything like that, then you will be sending text

So true, my bad. Forgot to say that you store information into bits when it is possible to do that. This is not the case of chatting in games. Thanks for the corrections COM! :happy: