int for(ensic){blog;}

Evtx Parser Version 1.1.1

2011-11-28T16:00:00Z

I'm releasing version 1.1.1 of the Windows Eventlog Parser library and tools collection for Perl. This version fixes a memory leak. I thank Heinz Mueller for reporting the issue and helping with testing. Please see the change log for other smaller changes.

The current version is now available for download.

DFRWS 2012

2011-11-22T16:00:00Z

The next Digital Forensic Research Conference (DFRWS) will held from August 6 to 8, 2012 in Washington, D.C. at the Embassy Suites Downtown hotel. The Call for Papers, workshops, and panels is now open; submissions are due February 20, 2012.

Evtx Parser Version 1.1.0

2011-11-11T16:00:00Z

It's my pleasure to announce a major release of my Evtx parser and tools collection. Version 1.1.0 significantly increases the ability to parse and transform Microsoft's proprietary binary XML dialect. The new version covers about 90% of XML tokens and data types.

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

]]> The library now parses CDATA sections (node type 0x07), XML entity references like & (node type 0x09) and processing instructions (node types 0x0a and 0x0b).

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.

Timers and Times

2011-10-27T16:00:00Z

Microsoft Windows timer objects provide a means to execute code at a certain time or in a periodic interval. From analyzing timers we can make some assumptions about a system's future.

]]> A couple of weeks ago Jamie Levy had presented Timeliner, a set of Volatility plugins that builds a timeline of past events from volatile data. Michael Hale Ligh recently published another plugin for Volatility, that enumerates Windows kernel timer objects. He uses timers to locate hidden kernel modules. I'd like to extend and combine their work by decoding the DueTime member of the KTIMER structure. This could help in extending a timeline into the system's future.

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.

Evtx Parser Version 1.0.8

2011-06-09T16:00:00Z

I'm releasing version 1.0.8 of my Windows Event Log Parser library and tools collection. While there are only minor enhancements to the library, the distribution format has been changed significantly. I apologize for any inconvenience this may cause. The archive is available for download here.

]]> The most important changes from version 1.0.7 are:

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-.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

Mac OS X memory analysis with Volafox

2011-06-07T16:00:00Z

Kyeong-Sik Lee and the Korean Digital Forensic Research Center have released Volafox, a free and open-source tool to analyze Mac OS X memory images. Volafox is based on work by Matthieu Suiche (paper and slides) and the Volatility memory analysis framework.

]]> Volafox is written in pure Python and requires Python 2.5 or later. You simply download and unzip the archive. The tool's usage is straight forward:

$ 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.

Evtx Parser Version 1.0.7

2011-02-07T16:00:00Z

I'm releasing version 1.0.7 of my Windows Event Log Parser. This release fixes a couple of errors and enhances the handling of XML templates. The archive is available for download here.

]]> The most important changes since version 1.0.5 are:

Fixed an error in CRC32 checks. Thanks to Michael Felber for reporting this bug.
Thanks to Andrew Hoog for reporting an error in the documentation.
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().
The contents of all BXmlNodes can now be retrieved as a hex dump by calling get_hexdump().

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.

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: #0 (type 0x81, optional)# #2 (type 0x0e, optional)#

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 ..

Recent Advances in Memory Forensics

2010-10-06T16:00:00Z

My slides from the ZISC Workshop 2010 on Digital Forensics and Security are now available. The speaker notes, unfortunately, are not. I hope my presentation on Recent Advances in Memory Forensics will be interesting anyway.

]]> The presentation features the following papers (in no particular order):

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)

Linking Event Messages and Resource DLLs

2010-10-05T16:00:00Z

Without knowledge about the binary XML template, the data in a record's SubstitutionArray can not be interpreted properly. The template is commonly read from the EVTX file. But in some cases, like a single event records carved from unallocated, the template may not be available. Now there's a method to match an event record to its proper message DLL, based on a GUID.

]]> A while ago I noticed that templates contain a full 16 bytes GUID. I've modified the evtxtemplates sample program to display the GUID, and the template's location in the EVTX file. The updated library and sample program will be available for download soon. Here's a short preview of its output:

$ ./evtxtemplates.pl CbsMsg.evtx
Template {47386119-D465-FA45-F96E-E70FFA54FBF7} at chunk 0, offset 0x07d8:

  #0 (type 0x01)#
  #2 (type 0x01)#
  #4 (type 0x01)#
  #5 (type 0x01)#

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:

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
build a database of templates, their GUIDs and IDs
look-up the proper template from that database, based on the TemplateID
interpret a record's substitution array according to the template

CarvFS on a Mac

2010-08-30T16:00:00Z

CarvFS is a user space file system on top of LibCarvPath and FUSE that makes arbitrary parts of a file system accessible as files. Its main intended use is zero-storage or in-place file carving. I'm frequently using this tool to dissect large structured files and file system images. CarvFS compiles out of the box on Linux; installation on a Mac required a couple of tweaks and patches to sources and CMake files. With the kind help of Rob from the KLPD I eventually succeeded. I'm releasing my set of patches in the hope that it will help others.

]]> You should be able to install this on your Mac with the help of MacPorts and my set of port files.

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.

EvtxParser on Ubuntu Linux

2010-08-09T16:00:00Z

Andrew Hoog has written step-by-step instructions that explain how to install the event log parser and its prerequisites on Ubuntu Linux 10.04. Thank you very much, Andrew!

ZISC Workshop on Digital Forensics 2010

2010-07-14T16:00:00Z

I'm excited to announce that I will speak at the ZISC 2010 Workshop on Digital Forensics and Security. I will report on the latest advancements in forensic memory analysis on Linux, Mac OS X and Microsoft Windows.The workshop will be held on September 13, 2010 at armasuisse in Berne, Switzerland.

]]> The agenda looks really promising and covers a wide variety of research topics in computer forensics, from file systems, to image forensics and teaching of computer forensics. I'm especially looking forward to Darren Bilby's talk on how Google does computer forensics.

Further information is available from the organizers.

Evtx Parser Version 1.0.5

2010-05-07T16:00:00Z

There's a new version of my Windows Event Log Parser available for download. Version 1.0.5 comes with faster calculations of CRC32 check sums and support for additional data types.

]]> The most important changes in version 1.0.5 are as follows:

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.

Slides from SANS Forensics Summit

2010-04-19T16:00:00Z

Unfortunately, SANS had to postpose the London Forensics Summit due to massive travel problems caused by volcanic ash floating around the atmosphere. I intended to answer many questions from the forensic community on the native Windows Event Log file format during the presentation. I'm releasing my slides in the hope that this will answer at least some of the questions, though the narrative is missing.

Evtx Parser Version 1.0.4

2010-03-25T16:00:00Z

Version 1.0.4 of my Microsoft Vista and Windows 2008 Event Log parser is now available for download. This version adds data integrity checking and fixes some errors.

]]> This version fixes a bug that triggered an assertion in line 37 (or 38, depending on your version) of Module Node0x0c.pm. The root cause is quite interesting: Chunks may contain some data behind their last event record. These are either the remains of older records or the beginning of an record that finally grew too large for the remaining space. Commonly these fragments appear as binary garbage and the parser skips over them.

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.