search for: libhivex

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

On Wed, Oct 29, 2014 at 10:43:59AM -0500, Mahmoud Al-Qudsi wrote: > 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...

hivexml on OS X was failing with a symbol-not-found error while dynamically linking. Adding iconv to libhivex fixes the issue and lets OS X process 'images/large' with hivexml. It took careful iconv autotool additions to get compilation working in Fedora as well, but these two lines build and run on OS X 10.6 and 10.8, and Fedora 17 and 18. Unfortunately, a separate issue is revealed here in OS X...

...API change, I have attached a patch for a new function in the hivex library that implements obtaining a handle to a "deep" node, allowing the user to enter a path like "SOFTWARE\Intel\Infinst\Uninstall" with only a previous call to load the root of, say, HKLM. When I first used libhivex, I assumed hivex_node_get_child would take such a path, but then learned that it only scans the children of the current node for a match. I do realize that hivex_node_get_child has a O(n) where n is the number of keys in the node and this means hivex_node_get_child_deep has a O(mn) where m is the...

The symbols file generated in the Debian package to aid the package maintainer automatically detect future changes shows internal library and helper function names, whereas it should only be exporting hivex_* function names. This page may help with this: http://gcc.gnu.org/wiki/Visibility Symbols: asnprintf at Base 1.2.1 c_isalnum at Base 1.2.1 c_isalpha at Base 1.2.1 c_isascii at Base

> On Nov 11, 2014, at 1:57 AM, Richard W.M. Jones <rjones@redhat.com> wrote: > > Yes I was also meaning to do that after reading lcamtuf's postings. Yup. That's the one. > I just started a run now .. Will let it run for a few days and report > any issues on the list. Thank you. Do you mind running it under valgrind to catch out-of-bound reads? Mahmoud

Hi, On Monday 10 November 2014 18:28:52 Mahmoud Al-Qudsi wrote: > I’m not able to pin it myself from a brief look, but it seems that > under certain conditions a call to hivex_node_delete_child can cause > the allocations from _hivex_get_children to not be freed properly? > > I know that if the return value of _hivex_get_children is -1, no free > is called; but from what I can

> On Nov 11, 2014, at 5:36 AM, Mahmoud Al-Qudsi <mqudsi@neosmart.net> wrote: > I'll test it and be back. And it works perfectly. Thanks, Mahmoud

Hi, libhivex seems to do a great job at parsing hives most of the time, but there are some issues with a few registry keys. These can be worked around in the application that uses libhivex, but I think it'd be better if libhivex handled these itself. 1. UTF16 string in REG_SZ that has garbage after the \0...

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'll have a proper look at this in the morning. > > > > Thanks, > > > > Rich. > > Thanks, Rich. > As far as I can tell, the only sanity chec...

[This email is either empty or too large to be displayed at this time]

...it would be better to use AC_CHECK_FUNCS on some of the libxml functions, but again, I'm not too hot with autoconf and automake. * hivexml has the following run-time failure: dyld: lazy symbol binding failed: Symbol not found: _iconv_open Referenced from: /Users/alex/local/src/hivex/lib/.libs/libhivex.0.dylib Expected in: flat namespace dyld: Symbol not found: _iconv_open Referenced from: /Users/alex/local/src/hivex/lib/.libs/libhivex.0.dylib Expected in: flat namespace Trace/BPT trap: 5 I have the vague idea of how to address the first two, but not the last. I would appreciate any help on th...

...9;./'`hivexml.c mv -f .deps/hivexml-hivexml.Tpo .deps/hivexml-hivexml.Po /bin/bash ../libtool --tag=CC --mode=link gcc -std=gnu99 -DLOCALEBASEDIR=\""/usr/local/share/locale"\" -I../gnulib/lib -I../lib -I/usr/include/libxml2 -g -O2 -o hivexml hivexml-hivexml.o ../lib/libhivex.la -lxml2 libtool: link: gcc -std=gnu99 -DLOCALEBASEDIR=\"/usr/local/share/locale\" -I../gnulib/lib -I../lib -I/usr/include/libxml2 -g -O2 -o .libs/hivexml hivexml-hivexml.o ../lib/.libs/libhivex.so /usr/lib/libxml2.so hivexml-hivexml.o: In function `main': ?SRCDIR?/xml/hivexml.c:96:...

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. Thanks, Rich. As far as I can tell, the only sanity checks in the initial loading of a registry hive are the ma...

...ag with iconv in OS X, where basically this would happen when a hive of any sophistication (greater than hivex/images/small) was processed: >$ xml/hivexml images/large >test.xml >dyld: lazy symbol binding failed: Symbol not found: _iconv_open > Referenced from: /[snip]/hivex/lib/.libs/libhivex.0.dylib > Expected in: flat namespace > >dyld: Symbol not found: _iconv_open > Referenced from: /[snip]/hivex/lib/.libs/libhivex.0.dylib > Expected in: flat namespace > >Trace/BPT trap This is pretty easily resolved in OS X by adding $(LTLIBICONV) to libhivex_la_LDFLAGS in...

...9e9d4000) libacl.so.1 => /lib64/libacl.so.1 (0x00007f2689b64000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f2689960000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2689740000) libaugeas.so.0 => /usr/lib64/libaugeas.so.0 (0x00007f26894f3000) libhivex.so.0 => /usr/lib64/libhivex.so.0 (0x00007f26892e3000) librt.so.1 => /lib64/librt.so.1 (0x00007f26890da000) libpcre.so.0 => /lib64/libpcre.so.0 (0x00007f2688eae000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2688c98000) libc.so.6 => /lib64/libc.so.6...

...ly linked shared library i386 libiconv.dylib (for architecture ppc): Mach-O dynamically linked shared library ppc Make complains, though it could stand to complain with more violence to the build: [snip] Making all in tools make[3]: Nothing to be done for `all'. CC libhivex_la-handle.lo CC libhivex_la-node.lo CC libhivex_la-offset-list.lo CC libhivex_la-utf16.lo CC libhivex_la-util.lo CC libhivex_la-value.lo CC libhivex_la-visit.lo CC libhivex_la-write.lo CCLD libhivex.la...

...ile python/run-python-tests po/Makefile.in regedit/Makefile sh/Makefile diff --git a/images/Makefile.am b/images/Makefile.am index 2adaed3..e176d3c 100644 --- a/images/Makefile.am +++ b/images/Makefile.am @@ -29,7 +29,8 @@ mklarge_LDADD = ../lib/libhivex.la noinst_DATA = large -large: mklarge - ./mklarge $(srcdir)/minimal large +large: minimal mklarge + cp -u $(srcdir)/minimal $(builddir)/minimal + ./mklarge $(builddir)/minimal $(builddir)/large CLEANFILES = $(noinst_DATA) diff --git a/lib/Makefile.am b/lib/Makefile.am index d54aaee..7e5b92...

Whilst cleaning up the lintian reports in preparation for the Debian/Ubuntu hivex package one of the issues is: E: libhivex-perl: binary-or-shlib-defines-rpath ./usr/lib/perl/5.10.1/auto/Win/Hivex/Hivex.so /tmp/buildd/hivex-1.2.1/perl/../lib/.libs I've temporarily dealt with this by using chrpath in the build and a rule to delete the RPATH from "auto/Win/Hivex/Hivex.so". I wonder if this is an oversight...

Thanks, Turned out I need to install libhivex-bin in order to work, however now when I run the command before I am getting the following error: virt-win-reg --merge vm-1057-disk-1.qcow2 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce] "Test"="C:\\Users\\Administrator\\test.bat" --debug launching libgu...