The current version is now available for download.

Evtx Parser and the Parse::EVTX Perl library is now available for download (ZIP).

I've also added support for arrays of all kinds of integers, single and double precision floating point numbers, GUIDs, FILETIME and the SYSTEMTIME structure.

A couple of months ago I had recived one report about a node type 0x08, but, unfortunately, no data to analyze. So far, I did not succeed in creating this token on Windows 7, using version 7A of the SDK. Even though this appears to be a rare token, I'd like to add a proper handler routine to EvtxParser. I'd greatly appreciate any samples of this binary XML token.

This is also the moment to thank the community for their continued support by reporting bugs, and donating samples. Your samples helped me to improve my understanding of Microsoft's binary XML dialect. My thanks go to Mark Woan for providing specially crafted test data and teaching me how to create test cases. I plan to release my test data set over the next weeks, in order to support tool validation efforts.

If you look closely at the output of Michael's plugin, and also at Mattieu Suiche's debugger script, you will notice the timer's 64bit DueTime, formatted as a pair of two 32bit integers. A correlation between DueTime and time of the real world may not be obvious.

When we deal with timed events, two time scales are important: SystemTime reflects the date and time of the outside world, or the wall clock. However, most internal activity refers to InterruptTime, which starts at boot up and hence reflects the system's uptime. Both scales measure the time in units of 100 ns and express them as 64bit integers (see FILETIME). The current value of both time scales can be found in SharedUserData:

kd> ? SharedUserData
Evaluate expression: 2147352576 = 7ffe0000
kd> dt -r _KUSER_SHARED_DATA 7ffe0000
nt!_KUSER_SHARED_DATA
   +0x000 TickCountLow     : 0x19c7a
   +0x004 TickCountMultiplier : 0xfa00000
   +0x008 InterruptTime    : _KSYSTEM_TIME 0x3`d76bb6e4
     +0x000 LowPart          : 0xd76bb6e4
      +0x004 High1Time        : 0n3
      +0x008 High2Time        : 0n3
   +0x014 SystemTime       : _KSYSTEM_TIME 0x1C6846E`81004d6c
   +0x020 TimeZoneBias     : _KSYSTEM_TIME 0xffffffef`3c773000
...

It is easy to convert SystemTime into a human-readable format

kd> !filetime 0x1C6846E`81004d6c
 5/31/2006 04:55:57.218 (UTC)

Now let's have a look at some kernel timers. Here is a simple example to start with:

kd> dt -r _KTIMER 80e30498
ntdll!_KTIMER
   +0x000 Header           : _DISPATCHER_HEADER
      +0x000 Type             : 0x8 ''
      +0x001 Absolute         : 0 ''
      +0x002 Size             : 0xa ''
      +0x003 Inserted         : 0x1 ''
      +0x004 SignalState      : 0n0
      +0x008 WaitListHead     : _LIST_ENTRY [ 0x80e30460 - 0x80e30460 ]
   +0x010 DueTime          : _ULARGE_INTEGER 0x3`db256384
      +0x000 LowPart          : 0xdb256384
      +0x004 HighPart         : 3
      +0x000 QuadPart         : 0x3`db256384
   +0x018 TimerListEntry   : _LIST_ENTRY [ 0x80e26a10 - 0x80542690 ]
   +0x020 Dpc              : (null) 
   +0x024 Period           : 0n0 

Kernel Timers are waitable objects, hence the KTIMER structure starts with a DISPATCHER_HEADER. A Type of 8 identifies a notification timer. The timer has been inserted into the list of timers, so it is active. DueTime refers to the InterruptTime scale. In order to convert it into a human-readable time stamp, we subtract the current InterruptTime as shown in shared user data, and then add the corresponding SystemTime from the same structure. Finally, we interpret the resulting value as a FILETIME.

kd> !filetime (0x3`db256384 - 0x3`d76bb6e4 + 0x1C6846E`81004d6c)
 5/31/2006 04:56:03.468 (UTC)

This timer was set to expire May 31st, 2006 at 04:56 UTC.

During an investigation I take a closer look at timers that are set to expire hours or even days in the future. One common example for this class of timers is the "time bomb" that uninstalls a trojan horse after a couple of days after it had searched through the user's documents and exfiltrated matching data.

Periodic Timers

Timers can be configured to periodically trigger an action. This can be seen in the following example.

kd> dt -r _KTIMER 80540d70
ntdll!_KTIMER
   +0x000 Header           : _DISPATCHER_HEADER
      +0x000 Type             : 0x8 ''
      +0x001 Absolute         : 0 ''
      +0x002 Size             : 0xa ''
      +0x003 Inserted         : 0x1 ''
      +0x004 SignalState      : 0n1
      +0x008 WaitListHead     : _LIST_ENTRY [ 0x80540d78 - 0x80540d78 ]
   +0x010 DueTime          : _ULARGE_INTEGER 0x3`e9711d2a
   +0x018 TimerListEntry   : _LIST_ENTRY [ 0x80542688 - 0x80542688 ]
   +0x020 Dpc              : 0x80540d98 _KDPC
      +0x000 Type             : 0n19
      +0x002 Number           : 0 ''
      +0x003 Importance       : 0x1 ''
      +0x004 DpcListEntry     : _LIST_ENTRY [ 0x0 - 0x0 ]
      +0x00c DeferredRoutine  : 0x804ef844  void  nt!IopIrpStackProfilerTimer+0
      +0x010 DeferredContext  : 0x80540d20 Void
      +0x014 SystemArgument1  : (null) 
      +0x018 SystemArgument2  : (null) 
      +0x01c Lock             : (null) 
   +0x024 Period           : 0n60000

Note that Period in this example is greater than zero. This timer will invoke the DeferredRoutine every 60 seconds.

We can calculate the time of the next occurrence, using the same formula as before:

kd> !filetime (0x3`e9711d2a - 0x3`d76bb6e4 + 0x1C6846E`81004d6c)
 5/31/2006 04:56:27.453 (UTC)

Periodic timers may lead you to critical parts of a software or system. During investigations, I've seen "watchdog" type code, that re-infects a partly disinfected system, or code that periodically exfiltrates data.

Absolute Timers

The timer in the next example is set to expire at the end of the century, at 12/31/2099 23:00:00.001 UTC, which is 01/01/2100 00:00:00.001 local time. Was this intended by the programmer?

kd> dt -r _KTIMER 80546660
ntdll!_KTIMER
   +0x000 Header           : _DISPATCHER_HEADER
      +0x000 Type             : 0x8 ''
      +0x001 Absolute         : 0x1 ''
      +0x002 Size             : 0xa ''
      +0x003 Inserted         : 0x1 ''
      +0x004 SignalState      : 0n0
      +0x008 WaitListHead     : _LIST_ENTRY [ 0x80546668 - 0x80546668 ]
   +0x010 DueTime          : _ULARGE_INTEGER 0x68ece8`0a46c088
   +0x018 TimerListEntry   : _LIST_ENTRY [ 0x805427a0 - 0x805466f8 ]
   +0x020 Dpc              : 0x805466a0 _KDPC
      +0x000 Type             : 0n19
      +0x002 Number           : 0 ''
      +0x003 Importance       : 0x1 ''
      +0x004 DpcListEntry     : _LIST_ENTRY [ 0x0 - 0x0 ]
      +0x00c DeferredRoutine  : 0x805256c6 void  nt!ExpCenturyDpcRoutine+0
      +0x010 DeferredContext  : (null) 
      +0x014 SystemArgument1  : (null) 
      +0x018 SystemArgument2  : (null) 
      +0x01c Lock             : (null) 
   +0x024 Period           : 0n0

Our first indicator is the name that is associated with the DeferredRoutine: ExpCenturyDpcRoutine. If you examine the Header carefully you will notice that Absolute is different from null.

As we've seen before, InterruptTime is a steadily increasing counter. Even changing the system's clock affects only the difference between InterruptTime and SystemTime, but not InterruptTime in itself. The majority of timer objects are relative to the InterruptTime scale; the corresponding parameter to SetTimer/SetTimerEx is negative.

By calling SetTimer/SetTimerEx with a non-negative FILETIME, the programmer binds the timer's DueTime to the SystemTime scale. Whenever the system's clock gets adjusted, Windows has to adjust these timers as well. In order to recognize the proper timers, Windows maintains the Absolute property in the object's header.

Beside a handler routine for the dawn of a new century you should also find a timer that triggers ExpTimeZoneDpcRoutine whenever daylight saving time starts and ends.

In a forensic examination, an "absolute" timer indicates the programmer's will to tie an event to the real world's clock. Understanding the meaning of that specific date and time to the programmer may become the key to your investigation and reveal the programmer's motive.

Overly large DueTime

During your investigation you are likely to stumble upon overly large DueTimes. The corresponding timer would expire in a few thousand years and WinDbg refuses to convert the date at all.

The value 0x0fffffff`ffffffff interpreted as FILETIME is 06/18/5254 21:21:00. So, one could use the higher bits as flags without problems. I noticed that any offending DueTimes have their most significant nibble set to 0x8. But what does this flag indicate?

I think it could be kind of a "parking brake". By turning the flag on, the timer's expiration would be effectively prevented. The original DueTime is still preserved, so the timer could be reactivated at any time (possibly leading to instant removal from the list, if DueTime has passed).

Here is an example:

kd> dt -r _KTIMER ffb7f500
ntdll!_KTIMER
   +0x000 Header           : _DISPATCHER_HEADER
      +0x000 Type             : 0x8 ''
      +0x001 Absolute         : 0 ''
      +0x002 Size             : 0xa ''
      +0x003 Inserted         : 0x1 ''
      +0x004 SignalState      : 0n0
      +0x008 WaitListHead     : _LIST_ENTRY [ 0xffb7f508 - 0xffb7f508 ]
   +0x010 DueTime          : _ULARGE_INTEGER 0x80000000`50c86d74
   +0x018 TimerListEntry   : _LIST_ENTRY [ 0xff67d128 - 0x80542840 ]
   +0x020 Dpc              : 0xffb7f558 _KDPC
      +0x000 Type             : 0n19
      +0x002 Number           : 0 ''
      +0x003 Importance       : 0x1 ''
      +0x004 DpcListEntry     : _LIST_ENTRY [ 0x340030 - 0x260033 ]
      +0x00c DeferredRoutine  : 0x80525b0c  void  nt!ExpTimerDpcRoutine+0
      +0x010 DeferredContext  : 0xffb7f500 Void
      +0x014 SystemArgument1  : 0x00330030 Void
      +0x018 SystemArgument2  : 0x0033005c Void
      +0x01c Lock             : (null) 
   +0x024 Period           : 0n0

The unmasked DueTime is
0x80000000`50c86d74 && 0x80000000`00000000 =
0x00000000'50c86d74

kd> !filetime ( 0x0`50c86d74 - 0x3`d76bb6e4 + 0x1C6846E`81004d6c)
 5/31/2006 04:30:42.843 (UTC)

Please note that the original DueTime is earlier than the current system time.

All objects derived from BxmlNode will now emit a short hex dump in case of an unknown opcode. Please forward me these dumps if possible in order to help me improve the program.

Evtx.pm now reads the number of the oldest chunk from the file header and exposes it through the OldestChunk property. Please note that the first chunk doesn't have to be the oldest one. The evtxinfo.pl sample program has been modified to indicate the oldest and the currently active chunk, as shown in the following example:

$ evtxinfo.pl rotated.evtx 
Information from file header:
Format version  : 3.1
Flags           : 0x00000000
         File is: clean
     Log is full: no
Current chunk   : 2 of 16
Oldest chunk    : 3
Next Record#    : 5257
Check sum       : pass

Information from chunks:
  Chunk file (first/last)     log (first/last)      Header Data  
- ----- --------------------- --------------------- ------ ------
      1       4681       4976       4902       5197   pass   pass
*     2       4977       5035       5198       5256   pass   pass
>     3        593        888        814       1109   pass   pass
      4        889       1135       1110       1356   pass   pass
      5       1136       1431       1357       1652   pass   pass
...

The asterisk (*) marks the current chunk and the angular bracket (>) indicates the oldest chunk.

Richard W. M. Jones provided online help in POD format for the sample programs. He also initiated a major change to the distribution format and provided me with a makefile. Thank you very much!

From now on distribution files will be named Parse-Evtx-<version>.zip; Parse-Evtx-current.zip will point to the current version. The old name EvtxParse-current.zip will be maintained for backward compatibility.

The library and sample programs can now be installed the usual way:

$ perl Makefile.pl
$ make
$ sudo make install

$ python volafox.py
Memory analyzer for OS X 0.5 - n0fate
Contact: rapfer@gmail.com
usage: python volafox.py -i MEMORY_IMAGE -s KERNEL_IMAGE -o INFORMATION
 
-= CAUTION =-
this program need to physical memory image, kernel image(mach_kernel)
and it support to Intel x86 Architecture only :(
 
INFORMATION:
os_version	 Dawin kernel detail version
machine_info	 Kernel version, cpu, memory information
mount_info	 Mount information
kern_kext_info	 Kernel KEXT(Kernel Extensions) information
kext_info	 KEXT(Kernel Extensions) information
proc_info	 Process list
syscall_info	 Kernel systemcall information

The memory image needs to be in plain format. So, it can not process images that were obtained by ATC-NY's Mac Memory Reader without further format conversion. Having a Mach-O Address Space for this would be a nice addition.

While it should be possible to find the kernel in the memory dump, this has not been implemented (yet) and Volafox requires a separate kernel image.

For starters, I suggest to go with the sample files that were provided by the author: a memory image and the proper Mach kernel. Now let's find out about the OS version first:

$ python volafox.py -i MemoryImage.mem -s mach_kernel -o os_version
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: os_version
Detail dawin kernel version: 10A432

This command displays the ProductBuildVersion that you can also find in /System/Library/CoreServices/SystemVersion.plist.

Here is some more information about the machine:

$ python volafox.py -i MemoryImage.mem -s mach_kernel -o machine_info
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: machine_info
 
-= Mac OS X Basic Information =-
Major Version: 10
Minor Version: 0
Number of Physical CPUs: 2
Size of memory in bytes: 536870912 bytes
Size of physical memory: 536870912 bytes
Number of physical CPUs now available: 2
Max number of physical CPUs now possible: 2
Number of logical CPUs now available: 2
Max number of logical CPUs now possible: 2

Volafox can traverse the list of mounted file systems:

$ python volafox.py -i MemoryImage.mem -s mach_kernel -o mount_info
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: mount_info
 
-= Mount List =-
list entry	fstypename	mount on name	mount from name
0304a290	hfs	/	/dev/disk0s2
03049948	devfs	/dev	devfs
03049000	autofs	/net	map -hosts
0403d520	autofs	/home	map auto_home
00000000	vmhgfs	/Volumes/VMware Shared Folders	.host:/

OS X maintains a doubly-linked list of processes; the list head is reachable via the kernproc symbol (see Mattieu Suiche's paper).

$ python volafox.py -i MemoryImage.mem -s mach_kernel -o proc_info
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: proc_info
 
-= process list =-
list_entry_next	pid	ppid	process name	username
03290d20	0	0	kernel_task		
03290a80	1	0	launchdask	n0fate	
032902a0	2	1	launchctlk	root	
032907e0	10	1	kextddask	root	
03290540	11	1	DirectoryService	root	
03290000	12	1	notifydask	root	
0359bd20	13	1	diskarbitrationd	root	
0359ba80	14	1	configdask	root	
0359b7e0	15	1	syslogdask	root	
0359b540	16	1	distnotedk	root	
0359b000	17	1	mDNSResponder	_mdnsresponder	
0359b2a0	19	1	securitydk	_mdnsresponder	
03a5a7e0	24	1	ntpdhdask	_mdnsresponder	
03bc7d20	26	1	usbmuxdask	_usbmuxd	
03bc7a80	30	1	mdschdask	_mdnsresponder	
03bc77e0	31	1	loginwindow	n0fate	
03bc72a0	32	1	KernelEventAgent	_mdnsresponder	
03bc7000	34	1	hiddhdask	_mdnsresponder	
03bdaa80	35	1	fseventsdk	_mdnsresponder	
03befd20	37	1	dynamic_pager	_mdnsresponder	
03bef7e0	42	1	autofsdask	_mdnsresponder	
03a5a2a0	53	1	taskgatedk	_usbmuxd	
03bdad20	54	1	coreservicesd	root	
03a5a540	55	1	WindowServer	root	
03bda540	57	1	vmware-tools-dae	_mdnsresponder	
03a5a000	74	1	airportdsk	_atsserver	
03befa80	78	1	coreaudiod	_coreaudiod	
03bda2a0	79	1	launchdask	n0fate	
03bef000	83	79	Dockhdask	n0fate	
03bc7540	84	79	SystemUIServer	n0fate	
04166d20	85	79	Finderask	n0fate	
03bef2a0	92	79	fontddask	n0fate	
041667e0	95	79	pboardask	n0fate	
04166000	96	79	quicklookd	n0fate	
044ddd20	99	79	UserEventAgent	n0fate	
044dd000	100	79	ServerScanner	n0fate	
044fed20	105	79	AirPort Base Sta	n0fate	
044dd7e0	106	79	vmware-tools-use	n0fate	
044dd540	108	79	CCacheServer	n0fate	
03bda000	110	79	TISwitcher	n0fate	
0085e758	120	1	backupdask	n0fate

A process can be selected by its PID in order to display a few more details:

$ python volafox.py -i MemoryImage.mem -s mach_kernel -o proc_info -x 120
Memory Image: MemoryImage.mem
Kernel Image: mach_kernel
Information: proc_info
Dump PID: 120
 
-= process: 120=-
list_entry_next	pid	ppid	process name		username
0085e758	120	1	backupdask	n0fate
task_ptr: 3bd81f4
vm_map_t: 41b2520
prev: 46145d8
next: 461402c
start: 100000000
end: 7fffffe00000
neutries: 3a
entries_pageable: 1
pmap_t: 3bf59f8
page directory pointer: 3bf5828
phys.address of dirbase: 4705c2400000000
object to pde: 1
ref count: 1
nx_enabled: 2
task_map: 0
pm_cr3: 0
pm_pdpt: 25c00000259
pm_pml4: 127df00000000000

Volafox also enumerates lists of kernel extensions and system calls. It will raise a flag if a syscall appears to be hooked.

1. Fixed an error in CRC32 checks. Thanks to Michael Felber for reporting this bug.
2. Thanks to Andrew Hoog for reporting an error in the documentation.
3. Precision of the time stamp reported by Type0x11.pm have been increased by one decimal. The outer structure's creation time stamp was not properly parsed by Event.pm. The value can now be accessed as a formatted string through get_time_created().
4. The contents of all BXmlNodes can now be retrieved as a hex dump by calling get_hexdump().
5. Handling of XML templates and NameStrings has been improved to support further research into that subject. Versions up to and including 1.0.5 built strings and template dictionaries on the fly while they parsed a chunk. From now on the dictionaries can be populated based on tables and lists in the chunk header, which is much faster. Template.pm now reports the GUID.
6. The example program evtxtemplates.pl was rewritten to make use of the new features. There is now an option to dump templates in hex, too.

$ ./evtxtemplates.pl --hex sample1.evtx
Template {ECD34601-0225-3E67-B639-D77B70281CE9} at chunk 0, offset 0x0612:
<EventData>
<Data>#0 (type 0x81, optional)#</Data>
<Binary>#2 (type 0x0e, optional)#</Binary></EventData>
  0610:       00 00 00 00 01 46 d3 ec 25 02 67 3e b6 39    .....F..%.g>.9
  0620: d7 7b 70 28 1c e9 78 00 00 00 0f 01 01 00 01 ff  .{p(..x.........
  0630: ff 6c 00 00 00 39 06 00 00 00 00 00 00 44 82 09  .l...9.......D..
  0640: 00 45 00 76 00 65 00 6e 00 74 00 44 00 61 00 74  .E.v.e.n.t.D.a.t
  0650: 00 61 00 00 00 02 01 00 00 1c 00 00 00 61 06 00  .a...........a..
  0660: 00 00 00 00 00 8a 6f 04 00 44 00 61 00 74 00 61  ......o..D.a.t.a
  0670: 00 00 00 02 0e 00 00 81 04 01 02 00 20 00 00 00  ............ ...
  0680: 84 06 00 00 00 00 00 00 21 b8 06 00 42 00 69 00  ........!...B.i.
  0690: 6e 00 61 00 72 00 79 00 00 00 02 0e 02 00 0e 04  n.a.r.y.........
  06a0: 04 00                                            ..              

• Takahiro Haruyama's port of Volatility to EnCase/EnScript, because it brings volatile data analysis techniques to a widely deployed analysis environment
• Matthieu Suiche's paper on Mac OS X Physical Memory Analysis, because it opens up access to volatile data on a new software platform
• Treasure and tragedy in kmem_cache mining for live forensics investigation by Andrew Case, Lodovico Marziale, Cris Neckar, and Golden G. Richard III, because their paper describes a new and efficient method to locate important kernel objects on Linux
• Robust signatures for kernel data structures by Brendan Dolan-Gavitt, Abhinav Srivastava, Patrick Traynor, and Jonathon Giffin, because their work significantly improves the robustness of scanner signatures
• Ruichao Zhang, Lianhai Wang, and Shuhui Zhang, because their paper "Windows Memory Analysis Based on KPCR" combines the concepts of scanning for a data structure and list traversal in order to locate data structures, that were hard to detect otherwise (with a mention of Damien Aumaitre and Bradley Schatz)

$ ./evtxtemplates.pl CbsMsg.evtx
Template {47386119-D465-FA45-F96E-E70FFA54FBF7} at chunk 0, offset 0x07d8:
<CbsPackageInitiateChanges 
  xmlns="http://manifests.microsoft.com/win/2004/08/windows/setup_provider">
  <PackageIdentifier>#0 (type 0x01)#</PackageIdentifier>
  <InitialPackageState>#2 (type 0x01)#</InitialPackageState>
  <IntendedPackageState>#4 (type 0x01)#</IntendedPackageState>
  <Client>#5 (type 0x01)#</Client>
</CbsPackageInitiateChanges>

Note the GUID {47386119-D465-FA45-F96E-E70FFA54FBF7}. The same GUID can be found in the WEVT_TEMPLATE resource of a message DLL (or any other PE file that defines resources for the event log service).

The first group of that GUID (the first 4 bytes) are called the TemplateID and are being referenced by the Create Template Instance token (code 0x0c).

It is now possible to apply the method of Timothy Morgan's GrokEVT to the new event log format:

1. enumerate all (relevant) message DLLs, either by
   1. scanning the file system for PE files with a WEVT_TEMPLATE resource, or
   2. locating these files from their registration with the event log service
2. build a database of templates, their GUIDs and IDs
3. look-up the proper template from that database, based on the TemplateID
4. interpret a record's substitution array according to the template

Download the archive and unzip it into your home. Then run portindex to incorporate the meta-data into your MacPorts installation. Next install the three packages:

sudo port install libcarvpath carvfs carvfs-modewf

MacPorts may install additional packages like sqlite3 or libewf to fulfill any prerequisites. Add the library directory of your MacPort installation (usually /opt/local/lib) to DYLD_FALLBACK_LIBRARY_PATH:

export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib

Finally, you can create a mount point and mount an EWF image:

> mkdir ~/mnt
> carvfs ~/mnt ewf auto myimage.E??
/Users/myname/mnt/2a99939f3a463faab0233bc6303194c8
> ls -l ~/mnt/2a99939f3a463faab0233bc6303194c8/
total 156301496
d--x--x--x 3 root wheel 0 1 Jan 1970 CarvFS/
-r--r--r-- 1 root wheel 80026361856 1 Jan 1970 CarvFS.crv
-rw-rw-rw- 1 root wheel 1134 1 Jan 1970 README

This was my first attempt at writing a port file. Also, CMake was giving me a hard time. While everything is working fine for me now, I realize that the ports and patches may not yet ready for inclusion into the MacPorts repository at this time. I greatly appreciate your comments and fixes.

Further information is available from the organizers.

The various CRC32 check sums are now calculated using Digest::CRC, which is more than five times faster than Digest::Crc32. The gain in speed becomes evident when processing a large event log file through evtxinfo.pl. Thanks to Kristinn Gudjonsson for the suggestion.

Mark Woan provided me with a sample file showing proper usage of type 0x12 data objects. This type clearly is a SYSTEMTIME structure. The parser displays the date/time in ISO 8601 format but suppresses the day-of-the-week field.

I've also added support for arrays of HexInt32 and HexInt64 values. Thanks to Christopher Ahearn for providing a sample file.

In some cases, however, there is a complete event record and it is in the right position. The parser now tries to recreate the XML structure and when Node0x0c.pm attempts to apply the XML template it can't access its definition. The definition was stored at lower offsets and has been irrecoverably overwritten. This, finally triggered the assertion mentioned above. This condition is now handled more gracefully.

I wish to thank Kristinn Gudjonsson for reporting this error and Michael Felber for providing me with test data.

Recently, I discovered an additional CRC32 check sum in the chunk header. This check sum is calculated over the event data portion of a chunk, from chunk offset 0x200 to OfsRecNext. The evtxinfo.pl sample program from now on applies this check to every chunk:

./evtxinfo.pl manipulated-SID.evtx 
Information from file header:
Format version  : 3.1
Flags           : 0x00000000
         File is: clean
     Log is full: no
Current chunk   : 2 of 2
Next Record#    : 161
Check sum       : pass

Information from chunks:
Chunk file (first/last)     log (first/last)      Header Data  
----- --------------------- --------------------- ------ ------
    1          1        113          1        113   pass   pass
    2        114        160        114        160   pass FAILED

For this example, a Security ID within an event record was changed by means of a hex editor. Please note the FAILED data integrity check for the manipulated second chunk. It should be noted that this kind of check will only detect accidental corruption. An adversary would simply have to recalculate the check sums to foil detection of his manipulation.