Windows Event Log Tricks

I was at a customer site the other day to look over some data center design plans. Of course like many things in a day in a life of a networking geek, flexibility is the key to getting to beer time quicker. The IT folks where in hot debate about something so I just assumed it was who was the BEST Dr. Who. I walked over wishing I had my long scarf and fist full of jelly babies to pelt folks that didn't agree that Tom Baker is to Dr. Who what Sean Connery is to 007. But no, it was about backups. Backups? Oh man... I know what this means. Arguments about backups are like letters from the Internal Revenue Service; they are never good and someone is in for a surprise two inches shorter then death. The issue was really about trying to restore some corrupted event logs. When I suggested just repairing the fields instead of restoring them and losing time data, folks looked at me like my Dad did when he caught me drag racing in his car. Yeah man! Windows Event Log subsystem is really like the good ole Microsoft Jet database. So many of the little tricks we used to use to keep that dude consistent we can still use to fix our Event Logs if they ever take a nosedive. There's a bunch of ways to do this but here is the method I used to breathe life back into these. Background: Event logs store columns of data. Each log has a header, floating footer (normally the problem child) and of course records. There are normally three files SysEvent.evt, SecEvent.evt and AppEvent.evt. These are stored in the systemRoot\system32\config folder. Normally these files get corrupt when four of the fields between the header and floating footer get inconsistent with each other. Fixing them is really as simple as manually setting the offsets. The floating footer object contains real time metadata. These four fields are four 4-byte fields that are offset to oldest record, the offset to next record, the record number of next record, and the record number of oldest record. Now, these same four fields are also present in the event log file header (non-real time). You can find these because they start at offset 16 and are only updated/sync'ed with the real time data when the event log service gracefully shuts down or you use execute a save log file as command. This is the best part; you are just repairing metadata and not actually data. This is really important to note and understand. I have been an expert witness at trials and douche bag lawyers will key in on that fact that you are changing the data and therefore compromised data. This is certainly not the case. Here's how to recover those files and get folks to man up some beers in your direction. Step 00x01: If you haven't downloaded the awesome tool; WinHex http://www.x-ways.net/winhex/ make sure you go out and get that tool pronto zulu. It'll really come in handy down the road. Step 00x02: Stop the event log service Step 00x03: Now use WinHex to open up the file that is in error. We need to find the floating footer in this sea of hexadecimal. This is identified by hex string 0x11111111. Now look for the header located at 0x28000000. OK now we have located the two objects that are out of sync with each other and therefore corrupting out. Step 00x04: So let's look for the byte right after the string 0x2800000011111111222222223333333344444444. This is the first byte in the 16 byte string that makes up the fields for event ID, next event, oldest event, etc... Now copy these 16 bytes to notepad. What has happened here most of the time is the byte offset (36 in the header) is an odd value. When the file is open or was not closed properly the offset is set to 0x09 or 0x0B, but really and odd value indicates a problem. Just the opposite is true when it is closed properly. The values are set to an even number usually 0x08 or 0x00 but any even value will work. Step 00x05: Now just paste the 16 byte value you copy from above at offset 0x00000016 Step 00x06: Finally, go to offset 36 in the header and change the file status byte to an even value. I normally use 00 but as long as it's even. A simple save, close and restart the event log service. And there you go! I gotta give a big ole shout out to Steve Bunting for publishing this method for forensics use. I use it all the time for forensics and non forensics alike. The good news is we were able to restore these logs on the fly, review the data center design and make it to watch the Brewers play ball over a cold beer! Man is this a great country or what! Jimmy Ray Purser Trivia File Transfer Protocol Doctor Who has resulted in at least five attempts at television spin-offs. The most successful was Torchwood, an anagram of Doctor Who.