similar to: [PATCH libguestfs 0/2] Use unsafe flag when reading (but NOT writing) hives.

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

A very miscellaneous set of cleanups to how we handle the Windows registry in virt-v2v, firstboot, and inspection code. This should all be straightforward non-controversial refactoring. Some highlights: - Add a new mllib Registry module containing various utility functions that are currently scattered all around. - Only compute the software/system hive paths once during inspection, and

This adds most of the hivex APIs directly to the libguestfs API, so that you can read and write Windows Registry hive files from libguestfs without needing to download and upload hive files from the guest. This is analogous to how Augeas APIs are exposed already (guestfs_aug_*) Also, inspection is now done using the new APIs, which fixes the following bug:

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

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.

The error message: hivex_close: do_hivex_close: you must call 'hivex-open' first to initialize the hivex handle This is the process flow: g = guestfs_create (); guestfs_add_drive_opts (g, diskFile,GUESTFS_ADD_DRIVE_OPTS_FORMAT, "raw",-1); guestfs_launch (g) char **roots = guestfs_inspect_os (g); guestfs_inspect_os returns NULL, guestfs_last_error(g) returns

Modify "tests" to expand any kind of environment variable than just $srcdir; use $datadir and $databuilddir to point to the files in $srcdir/tests/data and $builddir/tests/data, so it is easier to point at the data for the tests. Most of the work (except the $databuilddir and the integration in the Makefile.am) has been done as part of larger changes by Richard W.M. Jones

Hello all, I know that one of the original design goals of libhivex was to be resilient to corrupt, invalid, or malicious registry hives. I've encountered some undefined behavior in libhivex when attempting to open registry files that are too small. I'm not sure if this is a known issue per-se or not, so I figured I'd ask here on the mailing list before I jumped in and started adding

On Friday, 17 February 2017 10:24:58 CET Richard W.M. Jones wrote: > Map the HIVEX_OPEN_UNSAFE flag into the libguestfs API and use it > in various places. The series LGTM. Should virt-win-reg in display/export mode use the unsafe mode as well? Thanks, -- Pino Toscano

This flag will be used to control behavior of libhivex API functions so that they tolerate corruption in hives by either using heuristic recovery from unexpected situations or simply ignore bad registry keys/values whenever possible. --- generator/generator.ml | 8 ++++++++ lib/handle.c | 1 + lib/hivex-internal.h | 1 + 3 files changed, 10 insertions(+) diff --git

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

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

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 involves some significant changes to this test framework. In particular: - Instead of just specifying $srcdir at the start of a FileIn path, you can now specify arbitrary environment variables. This is necessary to allow the tests to run from a tmpdir. - Use COPYING instead of COPYING.LIB, and copy that file into the test suite directory. - Require the static binaries

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.

This involves some significant changes to this test framework. In particular: - Instead of just specifying $srcdir at the start of a FileIn path, you can now specify arbitrary environment variables. This is necessary to allow the tests to run from a tmpdir. - Use COPYING instead of COPYING.LIB, and copy that file into the test suite directory. - Require the static binaries

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