Ask Your Question
0

encapsulated multipart decoding in latest wireshark version

asked 2019-05-02 11:49:14 +0000

updated 2019-05-02 12:41:09 +0000

grahamb gravatar image

Hi, earlier i was using the wireshark version(Version 1.12.4 (v1.12.4-0-gb4861da from master-1.12)) . in that the encapsulated mulipart is porperly decoded and value are seen. but after i upgraded to latest version it is not decoding(Version 3.0.1 (v3.0.1-0-gea351cd8) ). can you please help to understand the reason.

HEX DUMP of the packet:

0000   74 a2 e6 80 17 ff fa 16 3e 57 d1 5e 08 00 45 00
0010   00 ee bc e8 00 00 40 06 21 df 0a 0a e7 e6 0a 0a
0020   9f 48 2b 2c 1f 9a 55 c4 65 5d 40 12 19 45 80 18
0030   00 d1 8e 6f 00 00 01 01 08 0a 00 7e dc d6 62 92
0040   f9 02 0d 0a 61 3d 61 63 63 65 70 74 2d 77 72 61
0050   70 70 65 64 2d 74 79 70 65 73 3a 74 65 78 74 2f
0060   70 6c 61 69 6e 20 6d 65 73 73 61 67 65 2f 69 6d
0070   64 6e 2b 78 6d 6c 20 61 70 70 6c 69 63 61 74 69
0080   6f 6e 2f 76 6e 64 2e 67 73 6d 61 2e 72 63 73 70
0090   75 73 68 6c 6f 63 61 74 69 6f 6e 2b 78 6d 6c 0d
00a0   0a 61 3d 70 61 74 68 3a 6d 73 72 70 3a 2f 2f 31
00b0   30 2e 31 30 2e 34 36 2e 37 36 3a 39 2f 5a 33 64
00c0   63 62 4a 62 45 32 66 56 76 49 49 65 72 3b 74 63
00d0   70 0d 0a 0d 0a 3c 2f 73 64 70 3e 0d 0a 3c 2f 73
00e0   65 73 73 69 6f 6e 3e 0d 0a 2d 2d 2d 62 6f 75 6e
00f0   64 61 72 79 52 4d 53 31 32 33 2d 2d
edit retag flag offensive close merge delete

Comments

What protocol(s) are you expecting to see, i.e. what does 1.12.4 show?

grahamb gravatar imagegrahamb ( 2019-05-02 12:49:19 +0000 )edit

it is HTTP(TCP) .. the encapsulated multipart would be 2 part 1) application/json 2) application/X-CPM-Session

ksmanojkumarcse gravatar imageksmanojkumarcse ( 2019-05-02 14:15:57 +0000 )edit

What you've posted appears to be a fragment of http, i.e. it does not include the http request or response that appears at the start of a message.

It would help if you can share the capture file on a public sharing site and post a link to it back here as a comment.

grahamb gravatar imagegrahamb ( 2019-05-02 15:34:46 +0000 )edit

plz find the pcap below, it has 3 HTTP POST req https://drive.google.com/file/d/1mre8...

ksmanojkumarcse gravatar imageksmanojkumarcse ( 2019-05-02 15:45:11 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2019-05-03 05:48:29 +0000

Guy Harris gravatar image

To quote RFC 2046, section 5.1.1 "Common Syntax" (that's "syntax" of the multipart media type, which is what section 5.1 in general deals with):

The boundary delimiter MUST occur at the beginning of a line, i.e., following a CRLF, and the initial CRLF is considered to be attached to the boundary delimiter line rather than part of the preceding part. The boundary may be followed by zero or more characters of linear whitespace. It is then terminated by either another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part. If no Content-Type field is present it is assumed to be "message/rfc822" in a "multipart/digest" and "text/plain" otherwise.

So:

---boundaryRMS123

Content-Type: application/json

etc. would appear to be a part with no header files, so that the first line of the body is "Content-Type: application/json".

So whatever generated that packet is not generating valid multipart/form-data information - it needs to put the Content-Type: line immediately after the boundary. 1.12.4 is incorrectly dissecting the incorrect data; newer versions are dissecting it correctly.

edit flag offensive delete link more

Comments

Thanx for the clarification

ksmanojkumarcse gravatar imageksmanojkumarcse ( 2019-05-03 06:37:32 +0000 )edit

Having looked at BNF in RFC 2046, I wonder if the makeup of the boundary is correct.

---boundaryRMS123\n is shown as boundary, whereas the boundary parameter of the multipart header says ---boundaryRMS123, so without the trailing \n (which is an illegal character for the boundary anyway). This is however picked up by the dissector as a valid end of the boundary, and the actual trailing CRLF now falls into the body part. As a consequence the body part dissection determines that there are no headers, so Content-Type isn't used.

Jaap gravatar imageJaap ( 2019-05-03 09:23:01 +0000 )edit

Yes - there's an extra newline there.

There's also no CR-LF, or even an LF, at the end of the last boundary in the body.

Guy Harris gravatar imageGuy Harris ( 2019-05-03 18:18:05 +0000 )edit

In the RFC the BNF of the close-delimiter does not require a CRLF after the delimiter, just two dashes.

Jaap gravatar imageJaap ( 2019-05-03 19:50:12 +0000 )edit

I've tweaked the capture data so that the tailing \n is removed. Then the MIME multipart dissector shows the application/json and application/x-cpm-session parts nicely.

Jaap gravatar imageJaap ( 2019-05-09 21:01:01 +0000 )edit
0

answered 2019-05-02 17:04:01 +0000

Jaap gravatar image

Looking at the capture I see three packets (#2, #4 and #6) with HTTP posts containing multipart MIME contents. The multipart parts are shown as data. When selecting these data parts the highlighted bytes in the packet bytes pane show where this field starts. The first bytes are 0d 0a, which I assume does mean there's no header in this multipart part. Only then the Content-Type: application/json is seen, which I assume is considered part of the body of this multipart part. If my assumption is correct that the header is considered empty, I would assume also that there's no handoff to a MIME type dissector and that is why you don't see the json dissection.

I would have to dig into the RFC's and/or dissector code to confirm my suspicion, but if you are in control of the composition of that POST, you could try removing the leading CRLF and see what happens.

edit flag offensive delete link more

Comments

Thanx for the clarification

ksmanojkumarcse gravatar imageksmanojkumarcse ( 2019-05-03 06:37:51 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-05-02 11:49:14 +0000

Seen: 42 times

Last updated: May 02