The good news is most of the data is still in the hive.
The bad news is the root nk record is corrupt, which is preventing the hive from loading. You can read more about NK records here:
Registry hive basics part 2: NK records. Essentially since the root key is corrupt, it can't load any more data since all the other data is underneath that root key.
The Hivex port Richard did has always been super buggy. Hivex is a linux tool, so it's easiest just to use a Linux machine and use the original tool from source (or on Ubuntu you can grab it from apt
apt install libhivex-bin)
Unfortunately again, even an up-to-date hivex build has issues with this hive:
Code:
❯ hivexsh /mnt/d/Stephen/Desktop/COMPONENTS
hivexsh: failed to open hive file: /mnt/d/Stephen/Desktop/COMPONENTS: Operation not supported
If you think this file is a valid Windows binary hive file (_not_
a regedit *.reg file) then please run this command again using the
hivexsh option '-d' and attach the complete output _and_ the hive file
which fails into a bug report at https://bugzilla.redhat.com/
We can get a bit more info running it in debug mode
Code:
❯ hivexsh -d /mnt/d/Stephen/Desktop/COMPONENTS
hivex: hivex_open: created handle 0x55dcf40df370
hivex: hivex_open: mapped file at 0x7f8e92510000
hivex_open: header fields:
file version 1.5
sequence nos 20370 20370
(sequences nos should match if hive was synched at shutdown)
last modified 0
(Windows filetime, x 100 ns since 1601-01-01)
original file name DOWS\System32\config\COMPONENTS
(only 32 chars are stored, name is probably truncated)
root offset 0x20 + 0x1000
end of last page 0x3341000 + 0x1000 (total file size 0x3380000)
checksum 0xb94294a4 (calculated 0xb94294a4)
hivex: hivex_open: root offset = 0x1020
hivex: hivex_open: returning ENOTSUP because: /mnt/d/Stephen/Desktop/COMPONENTS: trailing garbage at end of file (at 0x1
000, after 0 pages)
hivexsh: failed to open hive file: /mnt/d/Stephen/Desktop/COMPONENTS: Operation not supported
I'm actually pretty sure this is the defrag program's fault - or perhaps a chkdsk gone wrong. Let's open the hive in a hex editor.
At offset 0x1000, there's some unusual data in the file:
View attachment 69127
Compared to a "good" hive we should find the root hbin at the same offset
View attachment 69129
The
RSTR and
N.T.F.S are curious...
Moving further down the corrupt hive we see RCRD sections, which are again not part of a normal hive structure:
View attachment 69131
It's not until offset 0x5000 that we start seeing something that resembles correct data:
View attachment 69132
So what is this junk data? Well it's actually (somehow!) part of the NTFS log file. This log file is what makes NTFS a
journaling filesystem, and the logfile contains metadata about filesystem actions (create/modify/edit etc). From Windows Internals 6th Edition:
The NTFS logfile isn't well documented, but there are two data structures used in the file we're interested in here - LFS_RESTART_PAGE and LFS_RECORD_PAGE.
LFS_RESTART_PAGE structs start with the a header with the
RSTR signature, and LFS_RECORD_PAGE's header has the
RCRD signature. Source:
$LogFile (2) - File - NTFS Documentation
What this means is somehow parts of the NTFS logfile have been inserted into the start of the COMPONENTS hive file. How this could have happened I'm not too sure, but I suspect it would be the result of this defrag program.
Can we repair it? Well, put simply - maybe, but it's not worth the effort. Not only is NTFS record data at the start of the hive (we might be able to re-build the root key manually if that was the case), but it's also scattered throughout the hive. We'd have to remove all the instances of the RCRD value, then re-create valid hbins in all the locations manually in the hex editor where the RCRD values were. It's not worth the time...
View attachment 69134
I'd also be very nervous about this corruption being present in other locations - I'd be surprised if it's localised entirely to the COMPONENTS hive, it's just that that's where we're looking first.
