Re: working with header data

[Guy Harris <guy () alum mit edu>]

On Oct 14, 2011, at 6:03 AM, Ed Beroset wrote:

> There is a portion of the code called canonify_unencrypted_header().  In order to cryptographically process the ASN.1 
> components of the header, the data must be canonified.  To do this, the dissector must process the pieces of the 
> header in a particular order no matter what order these were actually sent.  Additionally, the entire BER encoding 
> must be processed, and not just the data with a [tag, length, value] triplet.

I.e., what gets run through the CMAC algorithm is a bunch of BER-encoded data, in a different order than the order in 
which the data appears in the header?

> I can think of two ways to do this (and indeed, have done it both ways).  First, I can rely on the ASN.1 parser to 
> break things into their respective fields and then process the components.  This approach has two problems.  The 
> first problem is that because the entire encoding must be processed, the tag and length must be reconstructed which 
> is a bit messy and complex.

Could you use #.FN_BODY for each of the fields in question?  It looks as if, in the code in question, "offset" would be 
the offset of the BER tag for the field; once you've called the appropriate code to dissect the field - %(DEFAULT_BODY) 
might expand to the function body that would have been there without #.FN_BODY, which might be sufficient - "offset" 
will point past it, so you'd have the offset and length of the entire BER-encoded field, and could, for example, copy 
it with tvb_memcpy().

If you need to wrap BER encodings for sequences, etc. around the individual fields to make a canonicalized "composite" 
field, that sounds as if you have to construct a tag in any case.

>  The more serious problem is that to enable filtering based on crypto results (e.g. "c1222.crypto_good == true"), the 
> code must also work on packets that haven't yet been parsed.

Why is that the case?  "c1222.crypto_good" is part of the protocol tree, and gets put there as part of the parsing 
process.  You can put it into the protocol tree at any point in the parsing process, including after all the other 
parsing has been done.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe