Wireshark-dev: Re: [Wireshark-dev] "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: "Sultan, Hassan" <sultah@xxxxxxxxxx>
Date: Wed, 26 Jul 2017 00:58:36 +0000

> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
> Sent: Tuesday, July 25, 2017 5:38 PM
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> Cc: Sultan, Hassan <sultah@xxxxxxxxxx>
> 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@xxxxxxxxxxxxx> 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:1
> >
> 2: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:6
> > 7: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