search for: dzamirski

* 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

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_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, 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 > >   of previous one. If this happens, scan the page section until > > next > >  

On Wed, 2017-02-15 at 21:14 +0000, Richard W.M. Jones wrote: > 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 > >

On Wed, 2017-02-15 at 22:35 +0000, Richard W.M. Jones wrote: > On Wed, Feb 15, 2017 at 10:29:41PM +0000, Richard W.M. Jones wrote: > > Yes, or even how about this (not tried it): > > > > while (off <= h->endpages - 0x1000) { > >   ... > > } > > In fact this doesn't work either :-( > > I'll have another look at this tomorrow morning.

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 Wed, 2017-02-15 at 18:52 +0000, Richard W.M. Jones wrote: > 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 > >

On Thu, 2017-02-16 at 08:43 +0000, Richard W.M. Jones wrote: > On Wed, Feb 15, 2017 at 10:59:33PM +0000, Richard W.M. Jones wrote: > > > > OK, I ended up turning the warning off.  It appears from the > > info file that the warning is about GCC not being able to make > > an optimization, not a bug in the code. > > > > However I do have a more substantial

On Wed, 2017-02-15 at 16:50 -0500, Dawid Zamirski wrote: > On Wed, 2017-02-15 at 21:14 +0000, Richard W.M. Jones wrote: > > 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 > >

add udev_settle calls to print_partition_table and sgdisk_info_extract_field because the inspect-os calls guestfs_part_get_parttype and guestfs_part_get_gpt_guid for all parition devices found and this causes intermittent with opening block devices that are certainly present yet RESOLVE_DEVICE macro would fail wiht ENOENT. --- daemon/parted.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff

This patch updates the guestfs_inspect_get_drive_mappings API call to also return drive letters for GPT paritions. Previously this worked only for MBR partitions. This is achieved by matching the GPT partition GUID with the info stored in the blob from HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT partions this blob contains a "DMIO:ID:" prefix followed by a 16 byte binary GUID.

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 Fri, 2016-02-05 at 18:08 +0000, Richard W.M. Jones wrote: > On Fri, Feb 05, 2016 at 12:15:32PM -0500, Dawid Zamirski wrote: > > This patch updates the guestfs_inspect_get_drive_mappings API call > > to > > also return drive letters for GPT paritions. Previously this worked > > only for MBR partitions. This is achieved by matching the GPT > > partition > >

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 patch updates the guestfs_inspect_get_drive_mappings API call to also return drive letters for GPT paritions. Previously this worked only for MBR partitions. This is achieved by matching the GPT partition GUID with the info stored in the blob from HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT partions this blob contains a "DMIO:ID:" prefix followed by a 16 byte binary GUID.

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 patch updates the guestfs_inspect_get_drive_mappings API call to also return drive letters for GPT paritions. Previously this worked only for MBR partitions. This is achieved by matching the GPT partition GUID with the info stored in the blob from HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT partions this blob contains a "DMIO:ID:" prefix followed by a 16 byte binary GUID.