similar to: [PATCH v3 0/2] hivex: handle corrupted hives better

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

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.

On Wed, Feb 08, 2017 at 04:36:31PM -0500, Dawid Zamirski wrote: > There are some corrupted registry files that have invalid hbin cells > but are still readable. This patch makes the following changes: > > * hivex_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.

Hi Rich, I find it more readable (and safer to review) to avoid lines longer than 80 columns. When reviewing changes that wrap, I've noticed that it is harder to spot certain types of mistakes in the wrapped portion of a long line. >From 930118b380b35bb33e7719b0eb2ab6b31fa2d7e4 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Wed, 13 Apr 2011 16:08:57

There are some corrupted registry files that have invalid hbin cells but are still readable. This patch makes the following changes: * hivex_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

--- hivex/hivexsh.pod | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/hivex/hivexsh.pod b/hivex/hivexsh.pod index 277e3ae..9336798 100644 --- a/hivex/hivexsh.pod +++ b/hivex/hivexsh.pod @@ -100,7 +100,14 @@ or even: Path elements (node names) are matched case insensitively, and characters like space, C<*>, and C<?> have I<no> special

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

--- lib/hivex-internal.h | 8 +++++--- lib/utf16.c | 11 +++++++---- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index 4135f58..64fd49a 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -268,11 +268,13 @@ extern size_t * _hivex_return_offset_list (offset_list *list); extern void _hivex_print_offset_list

--- lib/write.c | 50 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 35 insertions(+), 15 deletions(-) diff --git a/lib/write.c b/lib/write.c index dbb8292..8c4dd8e 100644 --- a/lib/write.c +++ b/lib/write.c @@ -608,9 +608,17 @@ hivex_node_add_child (hive_h *h, hive_node_h parent, const char *name) return 0; } + size_t recoded_name_len; + int use_utf16 = 0; +

On Oct 29, 2014, at 3:39 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > >> Or is it expected that certain sanity checks would be performed prior to >> passing along any files to libhivex? What would those checks be? > > No, hivex should definitely have those checks. > > I'll have a proper look at this in the morning. > > Thanks, > > Rich.

On Windows, there exist at least two APIs for dealing with the Registry: The Win32 API (RegCreateKeyA, RegCreateKeyW, etc.) works with null-terminated ASCII or UTF-16 strings. The native API (ZwCreateKey, etc.), on the other hand works with UTF-16 strings that are stored as buffers+length and may contain null characters. Malware authors have been relying on the Win32 API's inability to

On Sun, Nov 24, 2013 at 11:25:53PM +0100, Hilko Bengen wrote: > --- > lib/write.c | 49 ++++++++++++++++++++++++++++++++++--------------- > 1 file changed, 34 insertions(+), 15 deletions(-) > > diff --git a/lib/write.c b/lib/write.c > index dbb8292..72b1f8a 100644 > --- a/lib/write.c > +++ b/lib/write.c > @@ -608,9 +608,17 @@ hivex_node_add_child (hive_h *h,

On Tue, Feb 14, 2017 at 12:05:20PM -0500, Dawid Zamirski wrote: > * hivex_open: when looping over hbin sections (aka pages), handle a > case where following hbin section may not begin at exactly at the end > of previous one. If this happens, scan the page section until next > one is found and validate it by checking declared offset with actual > one - if they match, all is

Hello, I've been working on a graphical registry hive editing tool in Qt using the hivex C library. While creating it, I noticed that in order to determine if an expansion element should be shown on a node, you have to determine if a node has any children. Currently, in order to determine if a node has any children, you must find every child with hivex_node_children, which is a relatively

Hello Richard As discussed in the IRC channel, when merging a moderately large reg file (~35MB) to a hiv file (~118 MB); hivex generates a huge hiv file (~580 MB). These changes address that by creating a list of unallocated blocks and reassigning unused blocks. I used https://github.com/msuhanov/regf/blob/master/Windows%20registry%20file%20format%20specification.md as a reference for the

On Wed, Feb 15, 2017 at 01:48:29PM -0500, Dawid Zamirski wrote: > On Wed, 2017-02-15 at 16:54 +0000, Richard W.M. Jones wrote: > > On Tue, Feb 14, 2017 at 12:05:20PM -0500, Dawid Zamirski wrote: > > > * hivex_open: when looping over hbin sections (aka pages), handle a > > >   case where following hbin section may not begin at exactly at the > > > end > >

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

On Wed, Feb 15, 2017 at 02:28:41PM -0500, Dawid Zamirski wrote: > Correct, however there's also no guarantee that seeking by 4k in > "garbage" data would not land you in registry data that happens to > evaluate to "hbin" as well. That's why I put "hbin" offset validation > check couple of lines below to make sure that the "hbin" we found