log viewer

I'm not aware of any forensic tools that support transaction log files of Windows registry (except HEX editors D ). The format of these files, however, is pretty simple, so a HEX editor might be a great solution here.

Mounting and unmounting a hive using Regedit may be a solution too, if you need to recover a primary file using a transaction log. This method, however, doesn't allow an examiner to look at past versions of a hive (by applying an old transaction log) or at intermediate versions of a hive (when a user is using a computer actively, a Windows kernel will delay writing to a primary file up to an hour, so there could be 60 intermediate versions of a hive in transaction log files – each one created after a lazy flush period, 1 minute, has expired), because all new log entries will be automatically applied (these words apply to Windows 8.1, Windows Server 2012 R2, and Windows 10 only).

I'm not aware of any forensic tools that support transaction log files of Windows registry (except HEX editors D ). The format of these files, however, is pretty simple, so a HEX editor might be a great solution here.

So simple that there are no tools/parsers/viewers for these files? ? 😯 !

jaclaz

I'm not aware of any forensic tools that support transaction log files of Windows registry (except HEX editors D ). The format of these files, however, is pretty simple, so a HEX editor might be a great solution here.

So simple that there are no tools/parsers/viewers for these files? ? 😯 !

jaclaz

Most reverse engineering efforts were focused on the format of primary files.

Most reverse engineering efforts were focused on the format of primary files.

I know ) , and in the past these .log files had (IMHO) very little relevance and contained so little information that a hex view was more than adequate, but now that they become relevant and potentially they might grow in size noticeably, I don't think that the old approach with a plain hex editor would be adequate.
Since all in all they are AFAIK a form of registry hives, most probably regf (the library by Joachim Metz), or Registry (by Eric Zimmerman) or even the hivex project could be extended/modified to be able to "take care" of these files. ?

jaclaz

This is a pretty interesting conversation…is there value in parsing the .log1 files?

This is a pretty interesting conversation…is there value in parsing the .log1 files?

Before Windows 8.1 and Windows Server 2012 R2, you were likely to find only remnant data in transaction log files (both .LOG1 and .LOG2 can be non-empty). Rarely, if a hive was captured in the mid-update state (e.g. after pulling the plug when a hive was being flushed), you could find data to be written to a primary file in transaction log files. In the last case, if you compare a primary file before and after applying a transaction log, you won't notice significant differences most of the time, because there is only one flush operation between the before and after versions of a primary file, and a flush happens at regular small time internals (some sources state that this interval is 5 seconds by default, but this is not correct, the interval is n*5 seconds by default, where n can be equal to 1, 2, 3, etc., depending on a Windows version being used and on a number of hives mounted).

Starting from Windows 8.1 and Windows Server 2012 R2, when you call NtFlushKey() or when the lazy flusher starts its job, modified parts of a hive are written to a transaction log file and then this hive is considered to be flushed. Later, after the power management subsystem reports that all users (remote and local) are inactive, or after the system starts shutting down, or after an hour (by default) has elapsed since the latest write to a primary file, cumulative modified data is written to a primary file by the reconciler. So, when you read a primary file only, there is a chance that you read old data and you don't see changes happened right before an image was taken (minus one hour in the worst case). Also, transaction log files in the new versions of Windows may contain remnant data too (like a previous value of the shutdown timestamp).

So, yes.

Interesting. I'm going to have to parse a couple of the files. So far, in looking at some of these .LOG1 files, they don't follow the "rules" identified by Peter Nordahl. For example, I looked at two .LOG1 files and figured I had a quick way to get to the first HBIN, but the third file I looked at blew that out of the water…

Interesting. I'm going to have to parse a couple of the files. So far, in looking at some of these .LOG1 files, they don't follow the "rules" identified by Peter Nordahl. For example, I looked at two .LOG1 files and figured I had a quick way to get to the first HBIN, but the third file I looked at blew that out of the water…

Take a look at this.

Take a look at this.

A very good resource ) ! , a terrible (if I may ? ) example of a "pretty simple format" wink .

jaclaz

I have released sample files from a test case to demonstrate the issue.