Wireshark mailing list archives
Re: "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets
From: "Sultan, Hassan via Wireshark-dev" <wireshark-dev () wireshark org>
Date: Wed, 26 Jul 2017 00:58:36 +0000
-----Original Message----- From: Guy Harris [mailto:guy () alum mit edu] Sent: Tuesday, July 25, 2017 5:38 PM To: Developer support list for Wireshark <wireshark-dev () wireshark org> Cc: Sultan, Hassan <sultah () amazon com> Subject: "[UNVERIFIED SENDER]Re: [Wireshark-dev] Hierarchy of fields & offsets On Jul 25, 2017, at 3:26 PM, Sultan, Hassan via Wireshark-dev <wireshark- dev () wireshark org> wrote:FT_BYTES 198 smb2.security_blob(120) :60:76:06:06:2b:06:01:05:05:02:a0:6c:30:6a:a0:3c:30:3a:06:0a:2b:06:01:04:01:8 2:37:02:02:1e:06:09:2a:86:48:82:f7:12:01:02:02:06:09:2a:86:48:86:f7:12:01:02:02:06:0a:2a:86:48:86:f7:12:01:02:02:03:06:0a:2b:06:01:04:01:82:37:02: 02:0a:a3:2a:30:28:a0:26:1b:24:6e:6f:74:5f:64:65:66:69:6e:65:64:5f:69:6e:5f:52: 46:43:34:31:37:38:40:70:6c:65:61:73:65:5f:69:67:6e:6f:72:65 FT_UINT32 190 smb2.olb.offset(2) : 0x00000080 FT_UINT32 192 smb2.olb.length(2) : 120 FT_PROTOCOL 198 gss-api(120) : Notice how smb2.olb.offset & smb2.olb.length are under smb2.security_blob,but their offset starts at 190/192 while smb2.security_blob starts at 198 Now we're not just dealing with data structures, we're dealing with pointers.... If the pointer and length are considered part of the "security blob", then the "security blob" needs to have three subfields - offset, length, and content - and therefore must be an FT_NONE and must not be a contiguous blob. That would require that Wireshark support fields with more than one offset/length pair; if you clicked on them, they'd highlight more than one region of the hex pane.
I'm not sure I understand what you mean here (likely due to me still ramping up on the code). Are you saying that, assuming the blob offset/length fields are part of the blob, using FT_BYTES for the blob here is wrong b/c the 3 fields under it are not within the offset/length defined for the blob, and instead FT_NONE should be used ? Should I understand from this that FT_NONE is purely an abstract grouping without any meaning as to position/length of the fields under it ?
If the pointer and length are *not* considered part of the security blob, then they shouldn't be under smb2.security_blob.
Not sure what the authoritative source would be for that, but looking at the parser in Network Monitor 3 it has them outside the blob : UINT16 SecurityBufferOffset; UINT16 SecurityBufferLength; UINT32 Reserved2; switch { case CurrentProtocolOffset < SecurityBufferOffset: BLOB(SecurityBufferOffset - CurrentProtocolOffset) BufferPadding; } SMBSecurityBlob(SecurityBufferLength) securityBlob Thanks, Hassan ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Hierarchy of fields & offsets Sultan, Hassan via Wireshark-dev (Jul 25)
- Re: Hierarchy of fields & offsets Guy Harris (Jul 25)
- Re: "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets Sultan, Hassan via Wireshark-dev (Jul 25)
- Re: Hierarchy of fields & offsets Guy Harris (Jul 25)
- Re: "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets Sultan, Hassan via Wireshark-dev (Jul 25)
- Re: "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets Guy Harris (Jul 25)
- Re: "[UNVERIFIED SENDER]Re: "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets Sultan, Hassan via Wireshark-dev (Jul 27)
- Re: "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets Sultan, Hassan via Wireshark-dev (Jul 25)
- Re: Hierarchy of fields & offsets Guy Harris (Jul 25)