> -----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
