search

kiddinn / log2timeline

Automatically exported from code.google.com/p/log2timeline
GNU General Public License v3.0
0 stars 3 forks source link

Problem with the mork library - causing the firefox2 module to crash when processing Thunderbird address books. #9

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Run log2timeline against a Thunderbird address book (abook.mab)
2. The tool will crash if the e-mail address contains LE or BE

What is the expected output? What do you see instead?

It's expected that log2timeline does not pick up this file, since it is not a 
Firefox2 history file, and shouldn't crash on the parsing, just continue with 
the work.

The error message is:
[LOG2T] Checking against: Log2t::input::firefox2: VALIDATED
[LOG2T] Starting to parse file <PATH>/abook.mab
...
[LOG2T] Error while parsing: <PATH>/abook.mab error given: Unknown encoding 
'UTF-16<userid>@<email_domain>' at /usr/share/perl5/File/Mork.pm line 346

Original issue reported on code.google.com by ki...@kiddaland.net on 7 Sep 2012 at 6:18

GoogleCodeExporter commented 9 years ago 
The firefox2 module is just designed to parse all Mork databases, that is the 
validation is simply a magic check to see if this is a mork file, if it so, the 
tool will start with parsing the mork file into an object (using the mork 
library). It is on that step that the problem occurs.

Looking at the error:

Unknown encoding 'UTF-16<userid>@<email_domain>' at 
/usr/share/perl5/File/Mork.pm line 346

This bug is not really in log2timeline, it's in the Mork library that it uses. 
Looking at this line that the error occurs in:

                $val = encode_utf8(decode($encoding, $val));

The $val variable is trying to decode a string using the variable "$encoding", 
which is obviously not correctly set, should be "UTF-16" but is set to 
"UTF-16<userid>@<email_domain>", which means that it processed the encoding 
variable wrong.

Let's look at how the encoding variable is set:
                my $encoding = 'UTF-16' . $self->{byte_order};

The variable is therefore fixed to UTF-16, however the byte order is appended 
to it, obviously the byte ordering is done incorrectly. Let's take a look at 
that:

        # recognize the byte order of UTF-16 encoding
        if (! defined ($self->{byte_order}) && $val =~ m/(?:BE|LE)/) {
            $self->{byte_order} = $val;
        }

So if the byte order is not set and the value contains the letters BE or LE 
then we assume we are issuing a byte order, which get's appended then.

This error therefore get's triggered if the library is parsing an address book 
in which the address contains BE or LE in it. Now that we've found the error we 
can start fixing it.

The old line of /usr/share/perl5/File/Mork.pm:
336:         if (! defined ($self->{byte_order}) && $val =~ m/(?:BE|LE)/) {

Should be:
336:         if (! defined ($self->{byte_order}) && $val =~ m/^(?:BE|LE)$/) {

When this line has been changed in the Mork.pm library it does no longer fail 
on this parsing and the library continues to work.

However, this should not fail like this, so I pushed a small code change: 
http://code.google.com/p/log2timeline/source/detail?r=c6480995d28cd59b5c8dfe1b9a
5f37229743e64c to catch this error too, that is so that the tool does not 
fail/crash when/if this error condition comes up.

Need to contact the author of Mork.pm and notify him of this issue so this can 
be fixed on the correct place, otherwise temporary solution can be applied by 
fixing the library by hand.

Original comment by ki...@kiddaland.net on 7 Sep 2012 at 6:24

GoogleCodeExporter commented 9 years ago 
.

Original comment by ki...@kiddaland.net on 7 Sep 2012 at 6:25