hivexregedit(1)

๐Ÿ’… hivexregedit โ€” the manual page, but make it make sense

okay bestie, so this is hivexregedit(1), from the Windows Registry section of the manual (yes, that's the manual name, it's giving "I live in section 1 and I'm proud"). Strap in, because we're merging and exporting Registry changes from regedit-format files and it's actually iconic.


โœจ NAME โœจ

hivexregedit โ€” merge and export Registry changes from regedit-format files. that's it, that's the whole job ๐ŸŽ€


๐ŸŒธ SYNOPSIS ๐ŸŒธ

 hivexregedit --merge [--prefix prefix] [--encoding enc] \
         hivefile [regfile]

 hivexregedit --export [--prefix prefix] hivefile key > regfile

two modes, two moods, both written exactly like that ^^ don't come for me about the backslashes, they're load-bearing ๐Ÿ’…


๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

okay so first things first, real talk: hivexregedit is a low-level tool for manipulating hive files directly. like, straight into the hive, no middleman. if you're trying to merge or export registry changes to actual Windows virtual machines, bestie, use virt-win-reg(1) instead โ€” it's the higher-level bestie and it'll treat you better ๐Ÿซถ

so given a local binary ("hive") file, you get two modes:

  • --merge โ€” imports (merges) changes from a regedit-format file into the hive. it's basically the same energy as using the /s switch in Windows regedit.exe.
  • --export โ€” exports a Registry key (recursively!) into the regedit format.

๐Ÿ”ค ENCODING ๐Ÿ”ค

hivexregedit expects that regedit files have already been re-encoded in the local encoding. usually on Linux hosts, that means UTF-8 with Unix-style line endings. but Windows regedit files are often in UTF-16LE with Windows-style line endings ๐Ÿ˜ญ so you may need to re-encode the whole file before or after processing. no cap, this trips everyone up.

to re-encode a file from Windows format to Linux โ€” i.e. before you process it with the --merge option โ€” you'd do something like this:

 iconv -f utf-16le -t utf-8 < win.reg | dos2unix > linux.reg

to go in the opposite direction โ€” after using --export and before sending the file to a Windows user โ€” do something like this:

 unix2dos < linux.reg | iconv -f utf-8 -t utf-16le > win.reg

for more info about encoding, see Win::Hivex::Regedit(3).

if you're unsure about the current encoding, use the file(1) command. recent versions of Windows regedit.exe produce a UTF-16LE file with Windows-style (CRLF) line endings, like this:

 $ file software.reg
 software.reg: Little-endian UTF-16 Unicode text, with very long lines,
 with CRLF line terminators

this file would need conversion before you could --merge it. periodt. ๐Ÿ”ฅ


๐Ÿš SHELL QUOTING ๐Ÿš

be careful when passing parameters containing \ (backslash) in the shell ๐Ÿ’€ usually you will have to use 'single quotes' or double backslashes (but not both) to protect them from the shell. pick one, don't do both, that's the whole vibe check.


๐Ÿ‘‘ CurrentControlSet etc. ๐Ÿ‘‘

Registry keys like CurrentControlSet don't really exist in the Windows Registry at the level of the hive file, and therefore you cannot modify these. (read that again, bestie, it's important.)

CurrentControlSet is usually an alias for ControlSet001. in some circumstances it might refer to another control set. the way to find out is to look at the HKLM\SYSTEM\Select key:

 $ hivexregedit --export SYSTEM '\Select'
 [\Select]
 "Current"=dword:00000001
 "Default"=dword:00000001
 "Failed"=dword:00000000
 "LastKnownGood"=dword:00000002

Current is the one which Windows will choose when it boots. main character energy tbh.

similarly, other Current... keys in the path may need to be replaced. iykyk โœจ


๐ŸŒˆ EXAMPLE ๐ŸŒˆ

 $ virt-cat WindowsGuest /Windows/System32/config/software > software.hive
 $ hivexregedit --export \
     --prefix 'HKEY_LOCAL_MACHINE\SOFTWARE' \
     software.hive '\Microsoft' > ms-keys.reg

 $ hivexregedit --merge system.hive \
     --prefix 'HKEY_LOCAL_MACHINE\SYSTEM' additions.reg

look at that. beautiful. no notes. ๐ŸŽ€


๐Ÿ’œ OPTIONS ๐Ÿ’œ

  • --help โ€” display help. that's it. it's there for you ๐Ÿซถ
  • --debug โ€” enable debugging in the hivex library. this is useful for diagnosing bugs and also malformed hive files. detective mode: activated ๐Ÿ”
  • --merge
 hivexregedit --merge [--prefix prefix] [--encoding enc] \
         hivefile [regfile]

merge regfile (a regedit-format text file) into the hive hivefile. if regfile is omitted, then the program reads from standard input. (also you can give multiple input files ๐Ÿ‘€ yes really.)

--prefix specifies the Windows Registry prefix. it is almost always necessary to use this when dealing with real hive files.

--encoding specifies the encoding for unmarked strings in the input. it defaults to UTF-16LE which should work for recent versions of Windows. another possibility is to use ASCII.

  • --export
 hivexregedit --export [--prefix prefix] hivefile key > regfile

key is a path within the hive hivefile. (the key should not contain any prefix and should be quoted to defend backslashes from the shell ๐Ÿš). the key is exported, recursively, to standard output in the textual regedit format.

--prefix specifies the Windows Registry prefix. it is almost always necessary to use this when dealing with real hive files.

  • --prefix prefix โ€” hive files and Windows Registry key names are indirectly related. for example, inside the software hive, all keys are stored relative to HKEY_LOCAL_MACHINE\SOFTWARE. thus HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft appears in the hive file as \Microsoft.

the hive format itself does not store this prefix, so you have to supply it based on outside knowledge. (virt-win-reg(1), amongst other things, already knows about this โ€” it's the well-informed friend ๐Ÿ˜Œ).

usually it is sufficient to pass the parameter --prefix 'HKEY_LOCAL_MACHINE\SOFTWARE' or similar when doing merges and exports.

  • --encoding UTF-16LE|ASCII โ€” when merging (only), you may need to specify the encoding for strings to be used in the hive file. this is explained in detail in "ENCODING STRINGS" in Win::Hivex::Regedit(3).

the default is to use UTF-16LE, which should work with recent versions of Windows.

  • --unsafe-printable-strings โ€” when exporting (only), assume strings are UTF-16LE and print them as strings instead of hex sequences. remove the final zero codepoint from strings if present.
โš ๏ธ this is unsafe and does not preserve the fidelity of strings in the original hive, for various reasons โ€” bestie, listen to the warning, it's not a vibe:
  • assumes the original encoding is UTF-16LE. ASCII strings and strings in other encodings will be corrupted by this transformation ๐Ÿ’€
  • assumes that everything which has type 1 or 2 is really a string and that everything else is not a string, but the type field in real hives is not reliable.
  • loses information about whether a zero codepoint followed the string in the hive or not.

this all happens because the hive itself contains no information about how strings are encoded (see "ENCODING STRINGS" in Win::Hivex::Regedit(3)).

you should only use this option for quick hacking and debugging of the hive contents, and never use it if the output is going to be passed into another program or stored in another hive. like, never ever. ๐Ÿ™ˆ

  • --unsafe โ€” use heuristics to tolerate certain levels of corruption within hives.

this is unsafe but may allow to export/merge valid keys/values in an othewise corrupted hive. (yes, "othewise" โ€” that's how it's written in the original, we don't fix it, we respect it ๐Ÿ’…)

  • --max-depth depth โ€” limits the recursion depth of the export. for example, an export with a max depth of 1 will only include values directly under the specified key/prefix. a max depth of 0 will return no values.

exports include all child keys by default (fully recursive), which may take a while if the registry hive is large / bloated ๐Ÿ˜ฎโ€๐Ÿ’จ. this behavior can also be achieved by providing a negative max depth. so: big hive? use --max-depth. simple as. ๐Ÿ”ฅ


๐Ÿงš SEE ALSO ๐Ÿงš

virt-win-reg(1), Win::Hivex::Regedit(3), Win::Hivex(3), hivexsh(1), dos2unix(1), unix2dos(1), iconv(1), <http://libguestfs.org/>.

(the whole squad, assembled ๐Ÿซถ)


โญ AUTHOR โญ

Richard W.M. Jones <http://people.redhat.com/~rjones/> โ€” the icon who wrote this, we stan ๐Ÿ‘‘


Copyright (C) 2010 Red Hat Inc.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.


and that's the whole page, bestie ๐Ÿ’– this little rewrite is serving hivex-1.3.24, dated 2024-09-04, and it's the hivexregedit(1) manual page โ€” now go forth and merge responsibly ๐Ÿฆ‹โœจ

๐Ÿ“ฆ where this page comes from