add support for WEVT_TEMPLATE evtx template structure parsing about evtx HOT 4 OPEN

My approach with kpulp was to "raid" the target system for DLLs which contain expansion strings and then use those. I've looked into parsing those out from PE structure of associated DLLs that are registered as message template providers which seems quite feasible.
From experience, compiling a "master" database of expansion/template strings is error prone as it is heavily version specific. The template you got from Win2k3 won't work on Win10 and then there are regional language issues to address.

It's a tarpit.

from evtx.

Hi @williballenthin, thanks for your work on this, it looks really cool 😄

It sounds reasonable to extend read_open_start_element - if we can pass it a flag from the parser telling it how to read the string (if it is indeed determined by the evtx version).

I'll need some time to look into this properly - and I'm a little constrained right now since this isn't something I can spend time at work on.

I'll try to get to this in some upcoming weekend.

from evtx.

Yup, I totally understand. To be clear, I hate to open issues that I won't put effort towards myself, so I hope you don't feel that this creates a burden on you.

For me, I think the biggest question is how to express, construct, and document the code that can parse lots of flavors of the evtx format (there's this immediate issue, and then potentially different versions of the evtx format, etc.). The obvious thing to do is have lots of flags and lots of if/else statements, though it starts to get difficult to track, test, etc. So, before I go opening up a PR that adds a new boolean that's passed all around, I wondered if you had any great ideas here.

from evtx.

I agree that adding a lot of if-else branches can get cumbersome, but I think if it's just this small bit of behavior we could probably let it slide.

In general I believe that "duplication is better than the wrong abstraction".

But, if we would need to abstract over it - we would probably need to create some sort of visitor abstraction over the node types, and provide EVTX visitors which behave like the code we have at the moment, and WEVT visitor which can behave differently, and BinXmlDeserializer would be generic over the visitor.

so we would have:

trait BinXmlVisitor {
    // we would need to consider passing a reference to data instead of cursor here, since this can be painful to abstract using cursors
    fn read_open_start_element(data: &[u8], chunk: &Chunk) {
        ...
    }
    fn read_entity_ref_start_element(...) {
        ...
    }
   ...
}

and:

pub struct BinXmlDeserializer<'a, V: BinXmlVisitor> {
    data: &'a [u8],
    offset: u64,
    chunk: Option<&'a EvtxChunk<'a>>,
    // if called from substitution token with value type: Binary XML (0x21)
    is_inside_substitution: bool,
    ansi_codec: EncodingRef,
    deserializer: V
}

I think this would require some refactoring though, and it's probably only worth pursuing if WEVT and EVTX differ by more than a few bits of state.
Is there any spec for where we could reason about the differences between EVTX and WEVT (other than this)?

from evtx.