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

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

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

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.

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

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 > >

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

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.

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

--- 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

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

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

* 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 good and we can safely move on. Rationale: there are registry hives there is some garbage

* 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 good and we can safely move on. Rationale: there are registry hives there is some garbage

* 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 good and we can safely move on. Rationale: there are registry hives there is some garbage

On Wed, Oct 29, 2014 at 09:26:30PM -0500, Mahmoud Al-Qudsi wrote: > 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.

It was brought to my attention that dumping a registry hive causes a lot of time spent in disk I/O activity because iconv_open() and iconv_close() are called for every key. Every iconv_open() call causes /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. The iconv_t handles are now cached in the hive_h struct; they are opened on-demand and re-used. On my ~10 year old Lenovo T60, I have

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