[Libguestfs] Hivex - Trailing garbage at the end of hive file

[Subramanian, Hari]

Hi Rich,

I'm still working on validating whether the trailing zeroes were
introduced by hivex or by windows (though I highly doubt it's hivex). But
since it's part of a more complex workflow which is not that easy to
modify, it's still a work in progress

In the meanwhile, I wanted to be sure that ignoring the condition when
hivex saw these trailing zeroes was the right solution. I applied the
following patch to hivex. Not sure if this is what you had in mind

[ec2-user at ip-10-66-218-126 hivex-1.3.8]$ diff handle.c handle-mod.c
222,226c222,223
< SET_ERRNO (ENOTSUP,
< "%s: trailing garbage at end of file "
< "(at 0x%zx, after %zu pages)",
< filename, off, pages);
< goto error;
---
> printf("hivex: %s: trailing garbage at end of file (at 0x%zx, after %zu
>pages)\n", filename, off, pages);
> break;


I wanted to understand the behavior of hivex when we wrote to the end of
the hive file (added a new entry under ControlSet001\services). When I do
that I get the following error

badsys-1-win-add-reg\ControlSet001\services> ls
hivex: _hivex_get_children: returning EFAULT because: subkey_lf is not a
valid block (0x780020)
ls: Bad address
badsys-1-win-add-reg\ControlSet001\services> quit


Obviously the add/modify was not successful. But regedit parsed the hive
successfully. I'll continue to debug this but thought I should send it to
the list/you as well

Thanks
~ Hari


On 10/4/13 11:21 AM, "Richard W.M. Jones" <rjones at redhat.com> wrote:

>On Fri, Oct 04, 2013 at 03:13:47PM +0000, Subramanian, Hari wrote:
>> Rich,
>> 
>> Our workflow is something like this:
>> 
>> 0. Start with a fresh copy of windows server 2k8
>> 1. We read the system hive and then write to it a bunch of times
>> 2. Boot windows
>> 3. Read from the system hive
>> 
>> Hivex reports the failure at step #3. I also noticed that the size of
>>the
>> registry hive observed in step #3 is the same as step #0. Is it possible
>> that hivex issues write that cause a hive file to shrink in size and
>>while
>> compacting the hive file, it retains the size but zeroes out the end of
>> the file?
>
>Ah so hivex wrote the hive?  That could indicate a bug in hivex or
>perhaps some synchronization issue when uploading it into the guest?
>
>Anyway hivex itself never shrinks the hive.  In fact it only ever
>appends to the end of the hive, extending it if necessary (it's not
>always necessary).  When it extends the hive it's supposed to be
>initializing the hbin correctly.
>
>On the other hand it's anyone's guess what Windows does to the hive in
>step 2.
>
>BTW the source is all open ...
>https://github.com/libguestfs/hivex/blob/master/lib/write.c
>
>> That would point to the trailing zeroes getting introduced in
>> step #1
>> 
>> It's also possible that windows is padding those zeroes in step #2. I'm
>> adding some instrumentation to confirm this
>
>A good start would be logging the size and MD5 checksum of the hive
>before and after each step, and also from within Windows (IIRC there
>is an MD5 checksum program in PowerShell).  That would rule out some
>sort of non-hivex-related corruption when you're downloading or
>uploading the hive.
>
>Rich.
>
>-- 
>Richard Jones, Virtualization Group, Red Hat
>http://people.redhat.com/~rjones
>Fedora Windows cross-compiler. Compile Windows programs, test, and
>build Windows installers. Over 100 libraries supported.
>http://fedoraproject.org/wiki/MinGW