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:82: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.
If the pointer and length are *not* considered part of the security blob, then they shouldn't be under smb2.security_blob.
