similar to: [hivex PATCH] Re-allocating unused blocks before assigning new blocks

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.

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

Hi, I saw https://blog.rapid7.com/2020/09/14/cve-2020-1472-zerologon-critical-privilege-escalation/ and https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472 today and I am wondering what impact if any this has on samba AD domains in particular and samba in general? Is samba using the "vulnerable Netlogon secure channel connection"? Will samba continue to

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

-----Original Message----- From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of Yiorgos Stamoulis Sent: Thursday, October 19, 2006 3:33 PM To: CentOS mailing list Subject: [CentOS] is everyone aware of this? BRUCE STANLEY wrote: > I am having some issues (e.g. System lock ups) with my ATI 9250 Video > card. > > I am thinging about replacing it with

Dear useRs, Following the given codes below, I generated a plot that has 6 regions around a center point (IL), with 5 regions containing a point (L1, L2 to L5) and sixth vacant region. I want background of all the filled regions turned "green", while "red" for the vacant region. Can it be done through a quicker way? Thanks in advance ###Codes start from

--- lib/hivex-internal.h | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index f391b98..d7ce339 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -125,7 +125,19 @@ struct ntreg_hbin_block { struct ntreg_nk_record { int32_t seg_len; /* length (always -ve because used) */ char id[2];

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

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

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

* 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

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

--- lib/value.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/lib/value.c b/lib/value.c index 65404d7..7b2e9d3 100644 --- a/lib/value.c +++ b/lib/value.c @@ -207,14 +207,14 @@ hivex_value_key (hive_h *h, hive_value_h value) struct ntreg_vk_record *vk = (struct ntreg_vk_record *) ((char *) h->addr + value); - /* AFAIK the key is always plain

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 Sat, Jan 11, 2014 at 12:12:47AM +0100, Hilko Bengen wrote: > --- > lib/value.c | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/lib/value.c b/lib/value.c > index 65404d7..e700c84 100644 > --- a/lib/value.c > +++ b/lib/value.c > @@ -207,14 +207,8 @@ hivex_value_key (hive_h *h, hive_value_h value) > struct ntreg_vk_record *vk =