Every Registry file starts with a 4,096 byte header block. The first 512 bytes of that header tell us about the Registry file as a whole. Contained within this header are the following:
|Offset||Length||Type||What is it?|
|x004||4||uint32||Sequence Number 1|
|x008||4||uint32||Sequence Number 2|
|x00C||8||datetime||Last Modified Date|
|x01C||4||uint32||Type (0=Registry file; 1=Log file)|
|x024||4||uint32||Offset to root key record|
|x028||4||uint32||Offset to first non-used block|
|x090||4||?||??? Value is either 0 or 1|
|x1FC||4||uint32||Checksum (XOR32 of above)|
Here’s what it would look like in a hex editor:
|maj ver||min ver||type (0/1)|
|unknown (1)||Offset root||Offset end||unknown (1)|
|unknown (a)||unknown (b)|
|unknown (a)||unknown (b)|
|unknown (1)||unknown (a+1)||unknown (b)|
|padding (cont)(repeated lines removed)|
Some interesting notes:
There are two sequence numbers at offsets x4 and x8. If everything is operating as planned, these numbers should match. I’m assuming a mismatch tells the system the hive was not unmounted properly. They appear to be incremented each time the file is mounted, so this could provide an interesting forensic artifact. Has the registry been modified since last boot? (has this number changed since last boot) How many times has each user profile logged into this system? (compare the numbers for all NTUSER.DATs) More testing is needed to prove if this will be reliable and useful, but it is interesting.
The last modified time at offset xc does appear to jive with file last modified time in most cases. On a live system I saw discrepancies, which I am sure are related to NTFS caching in RAM and not updating the metadata on disk until unmount. In all cases where I saw a difference, the time inside the file was current and the time in NTFS metadata was lagged. More testing is needed to see if there is a reliable story this artifact tells us.
The version number at offset x14 appears to be either 1.3 or 1.5 on Windows 7 systems. NTUSER.DAT, BCD-Template, COMPONENTS, SAM, and SECURITY are 1.3. DEFAULT, SOFTWARE, and SYSTEM are 1.5. Haven’t identified difference between the two version numbers, though.
The type at offset x1c identifies if this is an actual Registry file or a .log file. The Registry Logs are stored in the same regf format, but different.
The number at offset x20 has been 1 on every file I’ve looked at. Some documentation calls this field “format” and others call it “unknown”. The ones that call it format don’t explain what that means, so I’m going to go with unknown. There is also a number at x2c that is always 1 and is even less known.
The two offsets at offsets x24 and x2c are virtual locations within the Registry content. The file is made up of HBINs that are 4k and each bin has a “hbin” signature at its start. The starting point is the first bin, which starts after the 4k opening header block.
The name at offset x30 is in Unicode. Sometimes it contains a path, sometimes it is just a file name. When it does contain a path, the field isn’t long enough for full path, so it gets truncated. There really doesn’t seem to be much sense to it as a file and its multiple associated log files will have different data in this field – different capitalization, different starting points for the path, and other oddities.
Most of the documentation calls everything after x70 “reserved” or “unknown”. There is clearly a structure there, but I can’t tell what those numbers are referring to. The same two numbers get repeated three times, with the third iteration having the first number incremented by one. The string “rmtm” appears in there, which obviously means something. There is also a number between the second and third iteration that is sometimes o and sometimes 1, but I can’t tell what that is denoting.
Lastly there is a checksum at offset x1fc. Once source identified this as XOR32 of the preceding 508 bytes. I haven’t taken the time to get a xor32 hashing tool to verify that.
In LOG file, the next thing after this header at offset x513, is a the Dirty Vector. It starts with a signature of “DIRT”. What follows is a bitmap where every bit set to 1 indicates an hbin that has changed.
In regular Registry Files the rest of the first opening 4k block, 3584 bytes worth, is just x00 padding.