5:01 p.m.
Greetings.
I am new to this list.
I am writing to you about hivexml. Richard Jones told me that he was considering
abandoning this program. Instead, I am willing to take over maintenance of it.
I am involved in computer forensics. I are in the midst of developing an XML standard to
describe the Windows Registry.
There are several programs that export the windows registry at XML. I have listed them
at:
http://www.forensicswiki.org/wiki/Windows_Registry_XML
The XML produced by hivexml is somewhat difficult to work with. It also has some problems
in that it doesn't properly quote strings, and doesn't atke into account other
important information. I have come up with a new form and would like to modify hivexml to
output and ingest the new form.
My question for this group:
1. Is anybody using hivexml?
2. Is it important to be able to read the old XML format?
3. We have had a hard time building hivexml on non-RedHat systems. Is there any objection
to my making this a standalone program?
I look forward to hearing from the list.
Simson Garfinkel
5:26 p.m.
On Sat, May 07, 2011 at 06:01:13PM -0400, Simson Garfinkel wrote:
I am writing to you about hivexml. Richard Jones told me that he
was considering abandoning this program. Instead, I am willing to
take over maintenance of it.
Not sure "abandoning", but I said that the format is broken, the
program is broken, and I'd like to deprecate both.
1. Is anybody using hivexml?
[speaking for me] No. The regedit format is what we're not using in
all the upstream and RHEL tools.
2. Is it important to be able to read the old XML format?
[speaking for me] no
3. We have had a hard time building hivexml on non-RedHat
systems. Is there any objection to my making this a standalone
program?
Go ahead.
I would suggest (just to avoid confusion) you call your program
something else instead of 'hivexml'.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
5:31 p.m.
On Sat, May 07, 2011 at 11:26:17PM +0100, Richard W.M. Jones wrote:
I would suggest (just to avoid confusion) you call your program
something else instead of 'hivexml'.
To clarify: just because if people are searching for "hivexml" they
might find your program, the old program, and not know the difference.
By having a different name we avoid this confusion.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
5:36 p.m.
On May 7, 2011, at 6:26 PM, Richard W.M. Jones wrote:
On Sat, May 07, 2011 at 06:01:13PM -0400, Simson Garfinkel wrote:
> I am writing to you about hivexml. Richard Jones told me that he
> was considering abandoning this program. Instead, I am willing to
> take over maintenance of it.
Not sure "abandoning", but I said that the format is broken, the
program is broken, and I'd like to deprecate both.
Ah. Your email to me actually had the word "abandoning" in it. Sorry if I jumped
the gun.
> 1. Is anybody using hivexml?
[speaking for me] No. The regedit format is what we're not using in
all the upstream and RHEL tools.
> 2. Is it important to be able to read the old XML format?
[speaking for me] no
Anybody else?
> 3. We have had a hard time building hivexml on non-RedHat
> systems. Is there any objection to my making this a standalone
> program?
Go ahead.
I would suggest (just to avoid confusion) you call your program
something else instead of 'hivexml'.
I think that brands have value. If keeping the old name means retaining backwards XML
compatibility, I'm happy to do so. Keeping the name is a good thing, I think.
6:22 p.m.
Hello Richard and the rest of the list,
I've been working on implementing the changes to hivexml Simson noted in this old
thread. Some of the changes could go into the hivex project as it is now (e.g. I've
corrected the time calculations). Some are substantial revisions to the output XML (not
just element names), which by silent vote doesn't seem like a big deal. However, I
have one major revision that is difficult to implement (for me, at least) while preserving
the multiple language bindings. I admire the project for having such diverse language
support, but I have to change some of the "visitor" function prototypes and that
is making development difficult. (My changes are adding a few structs to track data
offsets.)
How important is it to the hivex project that all of the language bindings remain? If I
were to just not develop for, e.g., Perl and OCaml, would it be better to call the revised
program "hivex" still, or should the version I'm developing just fork into a
slimmer project?
--Alex
On May 7, 2011, at 15:36 , Simson Garfinkel wrote:
On May 7, 2011, at 6:26 PM, Richard W.M. Jones wrote:
> On Sat, May 07, 2011 at 06:01:13PM -0400, Simson Garfinkel wrote:
>> I am writing to you about hivexml. Richard Jones told me that he
>> was considering abandoning this program. Instead, I am willing to
>> take over maintenance of it.
>
> Not sure "abandoning", but I said that the format is broken, the
> program is broken, and I'd like to deprecate both.
Ah. Your email to me actually had the word "abandoning" in it. Sorry if I
jumped the gun.
>
>> 1. Is anybody using hivexml?
>
> [speaking for me] No. The regedit format is what we're not using in
> all the upstream and RHEL tools.
>
>> 2. Is it important to be able to read the old XML format?
>
> [speaking for me] no
Anybody else?
>
>> 3. We have had a hard time building hivexml on non-RedHat
>> systems. Is there any objection to my making this a standalone
>> program?
>
> Go ahead.
>
> I would suggest (just to avoid confusion) you call your program
> something else instead of 'hivexml'.
I think that brands have value. If keeping the old name means retaining backwards XML
compatibility, I'm happy to do so. Keeping the name is a good thing, I think.
3:39 a.m.
On Thu, Jul 28, 2011 at 04:22:07PM -0700, Alex Nelson wrote:
I've been working on implementing the changes to hivexml Simson
noted in this old thread. Some of the changes could go into the
hivex project as it is now (e.g. I've corrected the time
calculations).
It's better to send small patches early, so we don't get any big
surprises later on.
Some are substantial revisions to the output XML
(not just element names), which by silent vote doesn't seem like a
big deal. However, I have one major revision that is difficult to
implement (for me, at least) while preserving the multiple language
bindings. I admire the project for having such diverse language
support, but I have to change some of the "visitor" function
prototypes and that is making development difficult. (My changes
are adding a few structs to track data offsets.)
Do you mean the "hivex_visit" and "hivex_visit_node" functions?
These
are only supported from C. Maybe I'm missing something?
BTW we have to preserve C ABI, so be careful about how you change any
C functions. It should be possible to extend the hivex_visitor struct
without changing the C ABI (this is what the 'len' argument is for).
How important is it to the hivex project that all of the language
bindings remain? If I were to just not develop for, e.g., Perl and
OCaml, would it be better to call the revised program "hivex" still,
or should the version I'm developing just fork into a slimmer
project?
It's very important that all the languages be preserved. However I
don't understand what the problem with visitor functions is, so ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
11:54 p.m.
Hi Richard,
I'm very sorry for the delayed reply, I started this thread right before two
back-to-back conferences.
On Jul 29, 2011, at 03:39 , Richard W.M. Jones wrote:
On Thu, Jul 28, 2011 at 04:22:07PM -0700, Alex Nelson wrote:
> I've been working on implementing the changes to hivexml Simson
> noted in this old thread. Some of the changes could go into the
> hivex project as it is now (e.g. I've corrected the time
> calculations).
It's better to send small patches early, so we don't get any big
surprises later on.
Fair enough; I'll start with the time calculations. Patch
incoming. I'm interested in your response to how I moved some definitions around.
> Some are substantial revisions to the output XML
> (not just element names), which by silent vote doesn't seem like a
> big deal. However, I have one major revision that is difficult to
> implement (for me, at least) while preserving the multiple language
> bindings. I admire the project for having such diverse language
> support, but I have to change some of the "visitor" function
> prototypes and that is making development difficult. (My changes
> are adding a few structs to track data offsets.)
Do you mean the "hivex_visit" and "hivex_visit_node" functions?
These
are only supported from C. Maybe I'm missing something?
BTW we have to preserve C ABI, so be careful about how you change any
C functions. It should be possible to extend the hivex_visitor struct
without changing the C ABI (this is what the 'len' argument is for).
Extending those structs may make sense. I've taken this advice to provide an
example of the output I'd like to generate. Coming in a patch soon, once I can get it
compiling.
Actually, if I can have your help with an automake issue, I would be most grateful. We
would like to upgrade this project as transparently as possible, so I have made no changes
to the autoconf system (which seems fairly different from configure systems we've used
in the past). However, our data offset changeset is having a significant and bizarre
linking error, and I can't see the gcc command that's causing the issue because
it's being "@"-muted. We added the -d flag to `make` (even -dddd) and
couldn't increase the verbosity. How do we disable the "@"-muting and have
the CC lines echo'd in your (auto)make system?
> How important is it to the hivex project that all of the language
> bindings remain? If I were to just not develop for, e.g., Perl and
> OCaml, would it be better to call the revised program "hivex" still,
> or should the version I'm developing just fork into a slimmer
> project?
It's very important that all the languages be preserved. However I
don't understand what the problem with visitor functions is, so ...
Understood.
The time changes just impact the C API, but I may need advice on the data offset
changeset due to the data being populated and reported in different places. More on this
soon.
--Alex
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
4:37 a.m.
On Tue, Aug 09, 2011 at 09:54:36PM -0700, Alex Nelson wrote:
Actually, if I can have your help with an automake issue, I would be
most grateful. We would like to upgrade this project as
transparently as possible, so I have made no changes to the autoconf
system (which seems fairly different from configure systems we've
used in the past). However, our data offset changeset is having a
significant and bizarre linking error, and I can't see the gcc
command that's causing the issue because it's being "@"-muted. We
added the -d flag to `make` (even -dddd) and couldn't increase the
verbosity. How do we disable the "@"-muting and have the CC lines
echo'd in your (auto)make system?
'make V=1' should show the full compile and link commands.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
8:11 p.m.
Simson, et al,
The XML produced by hivexml is somewhat difficult to work with. It
also has
some problems in that it doesn't properly quote strings, and doesn't atke
into account other important information. I have come up with a new form and
would like to modify hivexml to output and ingest the new form.
My question for this group:
1. Is anybody using hivexml?
2. Is it important to be able to read the old XML format?
3. We have had a hard time building hivexml on non-RedHat systems. Is there
any objection to my making this a standalone program?
Are you going to just work on the xml portion of hivex, or all of it?
I've got some suggestions on making (at least) the python bindings
easier to use for forensics scripts. And having the xml generation in
Python would be great.
Elizabeth
2:36 a.m.
On Sun, May 08, 2011 at 09:11:29PM -0400, Elizabeth Schweinsberg wrote:
Simson, et al,
> The XML produced by hivexml is somewhat difficult to work with. It also has
> some problems in that it doesn't properly quote strings, and doesn't atke
> into account other important information. I have come up with a new form and
> would like to modify hivexml to output and ingest the new form.
> My question for this group:
> 1. Is anybody using hivexml?
> 2. Is it important to be able to read the old XML format?
> 3. We have had a hard time building hivexml on non-RedHat systems. Is there
> any objection to my making this a standalone program?
Are you going to just work on the xml portion of hivex, or all of it?
I've got some suggestions on making (at least) the python bindings
easier to use for forensics scripts. And having the xml generation in
Python would be great.
Consider other language bindings, not just Python. We should not
favour one language over others.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
4883
days inactive
4978
days old
9 comments
4 participants
participants (4)
-
Alex Nelson -
Elizabeth Schweinsberg -
Richard W.M. Jones -
Simson Garfinkel