similar to: Hivex - Trailing garbage at the end of hive file

Is there a reason why a previous version of hivex ignored this condition while more recent ones throw an error? I do have some hive files that are failing (I'm yet to validate if they are good or were corrupted some other way). I will do so and share my findings Thanks ~ Hari On 9/24/13 5:20 PM, "Richard W.M. Jones" <rjones@redhat.com> wrote: >On Tue, Sep 24, 2013 at

On Tue, Sep 24, 2013 at 10:14:12PM +0100, Richard W.M. Jones wrote: > [Forwarding to the proper list] > > We use hivex for one of our projects and I see the following diff > committed to the hivex project (source link provided) that ignores > trailing garbage. But this code has been reverted to no ignore this > condition in later version of hivex > > - /* This error

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.

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

(Resending since my message from 2 days ago didn't make it to the list. Perhaps because of the log file attachment) Hi Rich, Sorry about the delayed response. I understand that since hive formats are not open, the current tack of warning about the hive file is a better one To respond to you question about "whether it fails", hivexsh is unable to open the hive file and it prints

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

* Richard W.M. Jones: > diff --git a/lib/hivex.c b/lib/hivex.c > index e3c1e05..9351ac5 100644 > --- a/lib/hivex.c > +++ b/lib/hivex.c > @@ -1471,7 +1471,7 @@ hivex_value_value (hive_h *h, hive_value_h value, > if (h->msglvl >= 2) > fprintf (stderr, "hivex_value_value: warning: big data block is not " > "valid

Signed-off-by: Alex Nelson <ajnelson at cs.ucsc.edu> --- generator/generator.ml | 6 ++++++ lib/hivex.c | 6 ++++++ xml/hivexml.c | 9 +++++++++ 3 files changed, 21 insertions(+), 0 deletions(-) diff --git a/generator/generator.ml b/generator/generator.ml index fc7b483..9e53f4e 100755 --- a/generator/generator.ml +++ b/generator/generator.ml @@ -159,6 +159,12

--- lib/hivex.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 66 insertions(+), 15 deletions(-) diff --git a/lib/hivex.c b/lib/hivex.c index efc27f8..e3c1e05 100644 --- a/lib/hivex.c +++ b/lib/hivex.c @@ -208,6 +208,19 @@ struct ntreg_sk_record { char sec_desc[1]; /* security info follows */ } __attribute__((__packed__)); +struct

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 >

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 major and minor version were being reported in a debug message. This patch adds the version information to the ABI and reports with hivexml. Signed-off-by: Alex Nelson <ajnelson at cs.ucsc.edu> --- generator/generator.ml | 10 ++++++++++ lib/hivex.c | 32 +++++++++++++++++++++++++++----- xml/hivexml.c | 24 ++++++++++++++++++++++++ 3 files changed, 61

On Fri, Oct 04, 2013 at 02:12:08PM +0000, Subramanian, Hari wrote: > To respond to you question about "whether it fails", hivexsh is unable to > open the hive file and it prints this message and exits. I've attached the > verbose logs as requested OK, I understand it now. It is in fact failing, setting errno = ENOSYS and returning an error. > This extract from the logs

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 infrastructure for modified-time reporting has been essentially unused. These changes report the registry time by treating the time fields as Windows filetime fields stored in little-Endian (which means they can be treated as a single 64-bit little-Endian integer). Some of the code changes necessary include: * Exposing the hive_h structure in the hivex header file (via generator.ml) *

On Tue, Sep 24, 2013 at 09:31:26PM +0000, Subramanian, Hari wrote: > Is there a reason why a previous version of hivex ignored this condition > while more recent ones throw an error? We don't understand all aspects of the hive format, so it's better to warn about these things than ignore them. > I do have some hive files that are failing (I'm yet to validate if they > are

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

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

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

I have found a strange issue related to hivex/ntfs-3g. After opening a system hive on a volume mounted by ntfs-3g, any access to the Windows directory results device or resource busy error. The patch below fix it by closing the hive file handle in hivex_open() call in the writable path because the handle never been used after its content been read into memory. --- hivex-1.2.5.orig/lib/hivex.c