This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Capturing application/binary data

0

I'm running wireshark Version 1.10.6 (v1.10.6 from master-1.10) on Windows Server 2008 R2.

I am trying to check the contents of some data from a proprietary application that is sent with a POST request, as application/binary data. I am seeing the POST data headers:

POST /eddSrv/EddRcvr?x=832893 HTTP/1.0
Accept: */*
Connection: Keep-alive
Content-Type: application/binary
User-Agent: WRA 3787
Host: <myserver.com>:55023
Content-Length: 92

But I am trying to see the 92 bytes specified in Content-Length, and even with a ton of googling, cannot figure out how to look at them. Any help would be greatly appreciated.

Dave

asked 02 Apr '14, 06:19

archer's gravatar image

archer
11113
accept rate: 0%

edited 02 Apr '14, 12:45

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237

Can you share the capture somewhere, e.g. CloudShark?

(02 Apr '14, 06:58) grahamb ♦

I'm afraid not; there is proprietary information in the data. Nothing as sensitive as HIPAA or PCI-DSS, but I can't post it publicly.

(02 Apr '14, 07:23) archer

One Answer:

0

Do you see the payload bytes in the following POST request (you can download the file and analyze it in Wireshark)?

https://www.cloudshark.org/captures/5254ad47c670

If yes: Please post the payload. If it is correct (I will check ;-)), something is 'wrong' with the POST request in your capture file. Probably you did not capture the full frame length and thus the payload is simply not in the capture file.

If no: You need a better understanding how Wireshark and/or HTTP POST works. If so, please follow up here and I'll give you some hints, like 'Follow TCP Stream' if you right click the frame with the POST request.

Regards
Kurt

answered 02 Apr '14, 12:58

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks for the help! Yes, I see your "123456789012345678901234567890". However, you're using application/x-www-form-urlencoded, not application/binary as I am. Would that make a difference? I have tried the Follow TCP Stream function; that's where I got the data in my original post.

Re cloudshark (I've never used it): If I post a packet and let it analyze it, will I be able to delete it after I'm done with it?

(02 Apr '14, 13:04) archer

Re cloudshark (I've never used it): If I post a packet and let it analyze it, will I be able to delete it after I'm done with it?

with a paid account: yes. Otherwise: no.

Would that make a difference?

Hm.. I guess, it shouldn't. But maybe you discovered a problem with 'Follow TCP stream'.

What do you see, if you look directly into the POST frame, not with 'Follow TCP stream'.

If you look at the 'Frame' layer in the frame, what do you see for 'bytes on wire' and 'bytes captured'? The values should be identical.

(02 Apr '14, 13:08) Kurt Knochner ♦

Yes, I'm seeing "bytes on wire" == "bytes captured". But I'm not seeing anything that appears to correspond to the amount of data in the content-length field. I'm beginning to wonder if there's a bug in Wireshark's handling of application/binary data when it doesn't correspond to a specific object type like an attachment. I know the data is there, because our app is working properly and the server is receiving all the data it is supposed to.

(03 Apr '14, 05:36) archer