search for: _hivex_get_children

[This email is either empty or too large to be displayed at this time]

Hi, On Monday 10 November 2014 18:28:52 Mahmoud Al-Qudsi wrote: > I’m not able to pin it myself from a brief look, but it seems that > under certain conditions a call to hivex_node_delete_child can cause > the allocations from _hivex_get_children to not be freed properly? > > I know that if the return value of _hivex_get_children is -1, no free > is called; but from what I can see, -1 means there is nothing to be > freed/it’s been taken care of. > > I’ve attached the valgrind log together with the output of > HIVEX_OP...

...ex_open - do not abort with complete failure if we run across a block with invalid size (unless it's the root block). Instead just log the event, and move on. This will allow open hives that have apparent invalid blocks but the ones of potential interest might be perfectly accessible. * _hivex_get_children - similiarly, if the's invalid subkey, just skip it instead of failing so one can continue to browse other valid subkeys. The above is similar to the behavior to Windows regedit where one can load such corrupted hives with e.g. "reg load HKU\Corrupted" and browse/change it despit...

Hello, The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be

...th complete failure if we run across a > block with invalid size (unless it's the root block). Instead just > log the event, and move on. This will allow open hives that have > apparent invalid blocks but the ones of potential interest might be > perfectly accessible. > * _hivex_get_children - similiarly, if the's invalid subkey, just skip > it instead of failing so one can continue to browse other valid > subkeys. > > The above is similar to the behavior to Windows regedit where one can > load such corrupted hives with e.g. "reg load HKU\Corrupted" an...

...r %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...

The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be looking at

The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be looking at

The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be looking at

This is, hopefully, a full fix for handling of li-records. See: https://bugzilla.redhat.com/show_bug.cgi?id=717583 https://bugzilla.redhat.com/show_bug.cgi?id=987463 Rich.

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

Hi, Here is one trivial initialization fix and another patch to convert a huge macro to an inline function. The result of the expansion would show up in an assertion which triggered a -Woverlength-strings warning. Peter Wu (2): Fix garbage return value on error Fix overly long assertion string lib/hivex-internal.h | 28 ++++++++++++++++------------ lib/node.c | 18