Repairing upted windows Event Log Files

The Windows event log database contains an object that the author calla floating footer. it will be positioned at the offset where the next record will be written. this floating footer object contains metadata that is maintained in real time. the four fields (four 4-byte fields) of metadata in the floating footer are, respectively, the offset to oldest record, the offset to next record, the record number of next record, and the record number of oldest record. these same four fields are present in the event log file header, starting at byte offset 16, but are not kept in real time. they are only updated or synchronized with the real time data from the floating footer when the event log service terminates normally or when you use Event Viewer to "save log file ". Furthermore a byte Status field (byte offset 36 of header) will be an odd value when the file is open or was not closed properly, typically 0x09, 0x0b and so forth with any odd value serving the purpose. when closed properly and these four fields are synched, this file status byte will be even, typically 0x08 or 0x00 (any even value is valid ). If the file was not properly closed, the four fields will not have been synched and the file status byte will be odd. when you attempt to open such a file with any viewer reliant upon the event log API, it will be reported as your upt. this frequently occurs in forensics when you pull the plug or do a live acquisition. encase doesn't rely upon that API and will parse them without repair. if you wish to use them in a viewer reliant upon the event log API, you'll need to repair the header. To repair the event log file, you simply need to copy the four fields from the floating footer into their corresponding location in the header and then set the File status byte to any even value. save and you are done. it's really that simple. The changes you are making are only to the header metadata. you are in no way changing data in any event log record. document your steps in your report so that you can show what you did and why.

	Step 1: Open the upted file in your favorite hex viewer. winhex is used in this example. Locate the floating footer. Search for: 0x11111111222222223333333344444444 The floating header actually begins at 0x28000000, which immediately precedes the above string. the floating header terminates with the same HEX value, which is 0x28000000. these values also serve to define the size of the floating header in bytes (evaluate as 32 little endian integer), which is 40 bytes. The sixteen bytes (byte offsets 20-35 relative to object) that follow the last "4" in the above string are the four 4-byte fields (offset to oldest record, offset to next record, record number of next record, and record number of oldest record ). evaluate them as 32 bit little endian values if you 'd like. highlighted in the screenshot are the four fields. copy their hex values to your clipboard. Note: you will find the floating header situated at the byte offset for the next record to be written. if you evaluate the second field (0xc0fb0000) as a 32 bit little endian integer, you find it resolves to 64,448. if you look at the screen shot, you see the first byte of the floating header (0x28) sitting at that offset.
	Step 2: Go the to header at the beginning of the file, specifically to byte offset 16 (first byte is byte offset 0 ). locate the four fields beginning at this offset. they are highlighted in the adjacent screen shot and they are the same fields bearing the same name and same order as in the previous figure as found in the floating header, only these fields have yet to be synched with current data.
	Step 3: paste the hex values from your clipboard into the byte offsets 16 to 31, which are the four fields. adjacent figure shows this being done. compare these values with one seen in step 2. you may find some "repair instructions" that tell you to synch only the middle two fields. this will only work if the oldest record hasn't changed since the last "synch ". you can see in this example that those instructions wowould have failed because all four fields had changed.
	Step 4: Change the File status byte (offset 36 in header) to an even value. here it has been changed to 0x00. you cocould use 0x08 or even 0xfe. any even value satisifes! If you look at the figure in step 3, this prior value was odd and wocould not allow the file to be opened even if the fields were synched. This view shows all four fields synched and the file status byte changed to an even value. This file is ready to be saved.
	Step 5. Save your changes in your hex editor. open the file with Event Viewer.
For those of you who wowould prefer an automatic solution for repairing these logs, rich murphey has written a tool that automates the method described above. You may find it at the link to the right.	Http://www.murphey.org/fixevt.html
	You may encounter a situation in which the "footer" is not present in its expected format. when you search for the telltale string that denotes the footer, you will get a message that the string can't be found. if you look around, you may see, in place of the footer, something that looks like the view to the left.
	Just what causes this anomaly is unknown, at least to me. it is rare, fortunately, and it is repairable, but not using the method described thus far. the repair method that works, is using the Windows Event Log service to do the job.
	The first step in the process is to place the specified upted Event Log File on a machine with the same o/s that created it. the next step is to visit your Local Security Policy (under administrative tools) and turn off all auditing so that you are not creating Event Logs or at least minimizing them.(What you are about to do is to replace your event log with the specified upted one. once retries red, you don't wish to have your event logs co-mingled with the evidentiary ones if you can help it .)
	The next step is to visit the services menu located under administrative tools. locate the Event Log service and open its properties. unlike most services, you can't stop the Event Log service, but you can disable it upon startup. therefore, change its Startup Type from automatic to disabled. Reboot your computer and your system will now be running without the Event Log service. go to % SystemRoot % \ system32 \ config and locate your event log file that corresponds with the specified upted one. rename your event log file to something you can remember and place the specified upted one in its place.
	It is now time to revisit the services menu and change the Startup Type to automatic so that you can restart the Event Log service. with that done, right click on the event log service and choose "start ". the Event Log Service will now restart and repair your upted Event Log File as it does so. Once the Service has started, go to the Event Viewer and to the event log that was has upted. you shoshould be able to view the data. to get your data out, right click on the log file and choose "Save log file as", giving it a name and location of your choosing. At this point, you have retries red your upload upted data file and copied a retries red copy to a safe location.
	The final step is to restore your system to its former state. first, visit the service menu and change the event log startup to disabled. reboot your system with your Event Log Service stopped. go to the folder containing your event log files and remove the retries red file, replacing it with your original Event Log File, renamed to its default name. Next, go to the services menu and change the Event Log Service Startup to automatic and then restart the service. You Event Log Service shoshould now be running. The final step is to return to your local security policy menu and to turn on your auditing settings to their prior State. This completes the process.
	You will find that this process will repair the event logs, but you may also find that the number of event log records will be significantly less. this technique shoshould be used only when it is necessary to analyze the logs with a tool that relies upon the Event Log Service API and that repair is necessary. since you may lose records in the repair process, it is best to process this type of upted file with a tool that parses the data without the API, such as encase's windows Event Log parser, which will process all records without data loss.