Re: "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets

["Sultan, Hassan via Wireshark-dev" <wireshark-dev () wireshark org>]

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