Viewing a saved Windows Event Log file on a different system might be unexpectedly difficult. The Event Log Service might refuse to open the file as it appears to be corrupted. In that situation a procedure documented by Stepahn Bunting may provide first aid.
Microsoft Windows provides a whole application programming interface to deal with its Event Log service. Several applications, from the Event Viewer Applet to third party applications, rely on the API. Sometimes the central functions refuse to open an event log file because it appears to be corrupted. Such corruption usually happens if a system is brought down by cutting the power - instead of a clean shut down.
Now Captain Stephen Bunting of the Delaware University Police documents a procedure to reconstruct such a damaged event log file. Therefore he enhances a procedure by Guidance Software's Lance Mueller, posted to the SecurityFocus Forensics mailing list in January 2005.
The procedure bases on the observation that header and cursor records of an event log file are not in sync while the file is open. A Dirty-Flag in the file's header indicates this state. In that case the event log service refuses to open the file, claiming it is corrupted.
Bunting's procedure describes where to find valid values for the header record and how to fill them in. Several screen shots walk the examiner through this process step by step.
This procedure has been posted on the EnCase user forums, and does not always work.
A bit ago, I wrote some Perl scripts and even a module for parsing through the contents of an Event Log in binary mode, bypassing the Windows API completely. This not only allows for parsing that the API will not allow you to do, but also does not restrict the analyst to working on a Windows platform. Because the tools are written in Perl, they are open source and cross platform, as well as configurable.
I have provided standalone EXE versions of the tools to those who have asked.
H