# Digging through Source Code

**URL:** <https://community.zeek.org/t/digging-through-source-code/4929>\
**Category:** Zeek\
**Created:** [July 3, 2017, 7:44pm UTC](https://community.zeek.org/t/digging-through-source-code/4929 "2017-07-03T19:44:49Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Vlad\_Grigorescu3](https://avatars.discourse-cdn.com/v4/letter/v/dec6dc/32.png) [@Vlad\_Grigorescu3](https://community.zeek.org/u/Vlad_Grigorescu3)\
**Post date:** [July 3, 2017, 7:44pm UTC](https://community.zeek.org/t/digging-through-source-code/4929/1 "2017-07-03T19:44:49Z")

</div>

"Weasel, Gary W Jr CIV DISA RE (US)" \<gary.w.weasel2.civ@mail.mil\> writes:

> case 8:  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ( element-\>data()-\>etype()-\>data()-\>size() )  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rv-\>Assign(11, proc\_cipher\_list(element-\>data()-\>etype()));
> 
> Following the breadcrumb trail in the if statement here...
> 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;element is type KRB\_REQ\_Arg (defined - [https://github.com/bro/bro/blob/master/src/analyzer/protocol/krb/krb-protocol.pac](https://github.com/bro/bro/blob/master/src/analyzer/protocol/krb/krb-protocol.pac))  
> -\> data is type KRB\_REQ\_Arg\_Data (defined - [https://github.com/bro/bro/blob/master/src/analyzer/protocol/krb/krb-protocol.pac](https://github.com/bro/bro/blob/master/src/analyzer/protocol/krb/krb-protocol.pac))  
> -\> etype is type Array (defined - [https://github.com/bro/bro/blob/master/src/analyzer/protocol/asn1/asn1.pac](https://github.com/bro/bro/blob/master/src/analyzer/protocol/asn1/asn1.pac))  
> -\> data is type ASN1Encoding (defined - [https://github.com/bro/bro/blob/master/src/analyzer/protocol/asn1/asn1.pac](https://github.com/bro/bro/blob/master/src/analyzer/protocol/asn1/asn1.pac))  
> -\> size is type ?
> 
> Following this line of thought, I'm a little confused by what "size()"  
> is supposed to mean here, since it's not an attribute. I can infer  
> that it's simply returning the size of the record, but I don't have  
> any information as to how or where that would be defined. I've also  
> tried looking through the source of BinPAC  
> ([https://www.bro.org/sphinx/components/binpac/README.html](https://www.bro.org/sphinx/components/binpac/README.html)) but have  
> come up empty so far.

I'll add on to what Johanna said. Many attributes in Kerberos are  
technically optional (though the Microsoft and MIT implementations don't  
necessarily treat them that way). Other attributes aren't optional, but  
we check to make sure that they were actually seen before accessing the  
underlying data. The if statement is just checking to see if that  
attribute was in the request packet (even though etype isn't optional  
according to the RFC).

> I have a sample of kerberos pcap that populates the msg$pa\_data$encryption\_type vector (from event krb\_tgs\_request), so I know that the aforementioned if statement is returning true - - but the other two vectors "host\_addrs" and "additional"tickets" (that from documentation seem to imply they're parallel with the encryption\_type vector) come up as \<uninitialized\>.

They're not really parallel. What the RFC has is:

> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;etype [8] SEQUENCE OF Int32 -- EncryptionType  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- in preference order --,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;addresses [9] HostAddresses OPTIONAL,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;enc-authorization-data [10] EncryptedData OPTIONAL  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- AuthorizationData --,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;additional-tickets [11] SEQUENCE OF Ticket OPTIONAL  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- NOTE: not empty

addresses (called host\_addrs by Bro) and additional-tickets are listed  
as optional, and likely won't be present in your PCAP (outside of the  
padata, at least).

> This made me question that maybe there was something wrong with the  
> code that was causing it to miss the host\_addr and ticket data, I  
> clearly find this data in my pcap sample under padata. This is my  
> current theory anyway, and wanted to see if I'm making a bad  
> assumption somewhere or if someone can shed light on what's going on  
> here.

The padata is in a separate field (pa\_data). The overall structure is  
that first you have the request itself, with the padata:

> KDC-REQ ::= SEQUENCE {  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- NOTE: first tag is [1], not [0]  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pvno [1] INTEGER (5) ,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;padata [3] SEQUENCE OF PA-DATA OPTIONAL  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- NOTE: not empty --,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;req-body [4] KDC-REQ-BODY  
> }

req-body is then parsed as:

> KDC-REQ-BODY ::= SEQUENCE {  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;kdc-options [0] KDCOptions,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cname [1] PrincipalName OPTIONAL  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- Used only in AS-REQ --,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;realm [2] Realm  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- Server's realm  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- Also client's in AS-REQ --,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sname [3] PrincipalName OPTIONAL,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from [4] KerberosTime OPTIONAL,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;till [5] KerberosTime,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rtime [6] KerberosTime OPTIONAL,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nonce [7] UInt32,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;etype [8] SEQUENCE OF Int32 -- EncryptionType  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- in preference order --,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;addresses [9] HostAddresses OPTIONAL,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;enc-authorization-data [10] EncryptedData OPTIONAL  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- AuthorizationData --,  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;additional-tickets [11] SEQUENCE OF Ticket OPTIONAL  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- NOTE: not empty  
> }

So it's possible that you're seeing these fields in padata, but not in  
the req-body.

Hope that helps. I forgot how complex this all was.

&nbsp;&nbsp;--Vlad

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\
**Post date:** [May 6, 2022, 3:45pm UTC](https://community.zeek.org/t/digging-through-source-code/4929/2 "2022-05-06T15:45:06Z")

</div>