Skip to content

Add support for getting localized strings from sidecar .mta files exported by windows event viewer#284

Open
dev-joss wants to merge 12 commits intoomerbenamram:masterfrom
dev-joss:feat/mta-support
Open

Add support for getting localized strings from sidecar .mta files exported by windows event viewer#284
dev-joss wants to merge 12 commits intoomerbenamram:masterfrom
dev-joss:feat/mta-support

Conversation

@dev-joss
Copy link

Looking for some feedback, and suggestions on how to integrate into evtx_dump (if appropriate)

dev-joss and others added 12 commits February 10, 2026 21:01
localized_message() was calling message_for_record_id() which treated
the sequential record ID as an event value. These are fundamentally
different: record IDs are counters (1, 2, 3…) while event values
identify event types (4624, 4688…). The lookup would return the wrong
message or None.

Extract the actual EventID by walking Event > System > EventID in the
parsed IR tree, then look it up via message_for_event_value().

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
MTA message lookup is a display concern, not a parsing concern. Move the
mta_cache field from ParserSettings to EvtxDump and simplify the
record_message path to use MtaFile::message_for_record directly. Remove
the extract_event_id helper and localized_message method from
EvtxRecord since lookups now go through record_id only.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The MTA lookup functions now extract EventRecordID from the actual
record payload (IR tree or serialized JSON/XML) rather than using the
binary record header's event_record_id, which is a different sequential
counter.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This exploratory test used the old MTA API (message_for_event_value,
message_for_entry_index) which no longer exists after the
EventRecordID refactor.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…scan

The byte length is already read from the payload header, so scanning
for a UTF-16 null terminator was redundant. Use decode_utf16le_bytes
directly after stripping a trailing null pair if present.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace hand-rolled string search with serde_json deserialization,
navigating Event.System.EventRecordID via the Value API.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@omerbenamram
Copy link
Owner

hi - i think a good start would be to define what exactly is this trying to solve (but avoid long AI generated slop). than we need to demonstrate this with some samples. i'll admit i am somewhat unfamiliar with .MTA files - so my main thoughts are whether this needs to live in tree with evtx parser, or this could be chained togather easily as a seperate binary :)

@dev-joss
Copy link
Author

evtx files don't actually contain the user friendly messages that describe the event.

When you export an evtx file from windows event viewer you have the option to include localization, this creates the mta file which contains the descriptions and a mapping from the "EventRecordID" field in the events to the descriptions.

If the mta doesnt exist windows event viewer (or i guess any other app) needs to query the description from the locally installed providers. Often providers dont exist on different system, for example etw providers for intel ethernet sources are installed by intel drivers, so a different system that doesnt have them installed, and the fields of the event may not be publicly documented. This makes them unreadable effectively on any system except the one the evtx was created on.

Yeah totally could be a different binary (or even project) if it doesn't align with the projects intent (or goals)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants