search for: ntreg_hbin_page

...offsets are checked against hdr->size; from a brief glance I’m unsure but I think there might be an issue if the file is truncated after a page offset. "off < h->size” will return true, but accesses to page contents will be out-of-bounds. So I think that would need to be “off + sizeof(ntreg_hbin_page) < h->size”? For example, truncating a registry file at h->rootoffs and with a purposely-wrong hdr->offset = 0, I think you’ll get past "if (off >= h->endpages)” and you’ll be reading the page out-of-bounds while checking hbin magic. I have to run, but I think there may 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

...goto error; + + DEBUG(2, + "page not found at expected offset 0x%zx, " + "seeking until one is found or EOF is reached", + off); + + int found = 0; + while (off < h->endpages) { + off += 0x1000; + page = (struct ntreg_hbin_page *) ((char *) h->addr + off); + if (page->magic[0] == 'h' && + page->magic[1] == 'b' && + page->magic[2] == 'i' && + page->magic[3] == 'n') { + DEBUG(2, "found next page by se...

...error; + + DEBUG (2, + "page not found at expected offset 0x%zx, " + "seeking until one is found or EOF is reached", + off); + + int found = 0; + while (off < h->endpages) { + off += 0x1000; + page = (struct ntreg_hbin_page *) ((char *) h->addr + off); + if (page->magic[0] == 'h' && + page->magic[1] == 'b' && + page->magic[2] == 'i' && + page->magic[3] == 'n') { + DEBUG (2, "found next page by s...

...goto error; + + DEBUG (2, + "page not found at expected offset 0x%zx, " + "seeking until one is found or EOF is reached", + off); + + int found = 0; + while (off < h->endpages) { + off++; + page = (struct ntreg_hbin_page *) ((char *) h->addr + off); + if (page->magic[0] == 'h' && + page->magic[1] == 'b' && + page->magic[2] == 'i' && + page->magic[3] == 'n') { + DEBUG (2, "found next page by s...

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

...against hdr->size; from a brief > glance I’m unsure but I think there might be an issue if the file is > truncated after a page offset. "off < h->size” will return true, but > accesses to page contents will be out-of-bounds. So I think that > would need to be “off + sizeof(ntreg_hbin_page) < h->size”? I added a second check that the page we're reading in the loop at line ~ 220 doesn't extend beyond the end of the file, which I think should be sufficient. That's the second attached patch. > For example, truncating a registry file at h->rootoffs and with a &...

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.

...< h->endpages) { ^ I suspect this means that GCC might try to turn this into an infinite loop. There are actually a few more of these in the existing code - I'm going to push a patch to fix these in a minute. Rich. > + off += 0x1000; > + page = (struct ntreg_hbin_page *) ((char *) h->addr + off); > + if (page->magic[0] == 'h' && > + page->magic[1] == 'b' && > + page->magic[2] == 'i' && > + page->magic[3] == 'n') { > + DEBUG (2, &...

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

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

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