The contents of Registry files are saved in Hive Bins. The previously mentioned header to the Registry file is a 4k block with info about the file as a whole. After that comes a series of blocks that each start with magic signature of “hbin”. These blocks are the containers that all the keys, values, and everything else will will get dumped into.
Each bin has a small header that contains the following.
|offset||length||type||what is it?|
|x04||4||uint32||Offset from start of Registry|
|x08||4||uint32||Size of this bin|
|x14||8||datetime||Last Modified Time|
Hex view looks like this:
|unknown (0)||Last Modified Date||unknown (0)|
Notes of interest:
The first offset at offset x4 provides the location where this bin will start in relation to the registry data, not the registry file. So, for the first bin this will be 0, for the second bin it will be 4,096, even though they are 4,096 and 8,192 into the file due to the 4k header on the file.
The size of the bin is listed at offset x8. This is usually 4k. If larger, it will be a multiple of 4k. As an example, in just one SYSTEM registry file made up of 4,154 bins: 3,711 (89%) were 4k, 90 (2%) were 8k, 40 (1%) were 12k, and 313 (8%) were 16k.
The date field at offset x14 is only present in the first bin. All bins after that have this field set to zero. The value of this field seems to always match the date the regf header.
The other three fields were always zero in all of the files I’ve looked at.