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?
x00 4 string Signature “hbin”
x04 4 uint32 Offset from start of Registry
x08 4 uint32 Size of this bin
x0C 4 uint32 unknown (0)
x10 4 uint32 unknown (0)
x14 8 datetime Last Modified Time
x1C 4 uint32 unknown (0)


Hex view looks like this:

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
x00 68 62 69 6E 00 00 00 00 00 10 00 00 00 00 00 00 hbin············
hbin Offset Size unknown (0)
x10 00 00 00 00 53 E6 15 98 E5 3C D0 01 00 00 00 00 ····Sæ·˜å<з····
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.