sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy

[sleuthkit-developers] Fls core dumped

[Jaime C. <jc...@id...>]

I was testing usbkey with one FAT16 partition that contained active and=20
deleted directories and files.

I run the fls command against the FAT16 partition and it segmented fault

+ r/r 73217:    D3X100K.txt
+ r/r 73218:    D3Y1M-E.txt
d/d * 5:        _IR004
d/d 6: =20
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO=
OOOOOOOOOOOOOOOOOOOOOOOOOOOO=20

Segmentation fault (core dumped)

gdb output:

#0  0x08063af5 in fatfs_dent_parse_block (fatfs=3D0x807e048, buf=3D0x807f=
038=20
"=E5IR002     \020", len=3D512, addr=3D384, flags=3D7, fs_dent=3D0x808406=
8,
    action=3D0x8070335 <print_dent_act>, ptr=3D0x0) at fatfs_dent.c:464

I can see that buf address has junk in it (buf=3D0x807f038 "=E5IR002     =
\020")

Jimmy

Re: [sleuthkit-developers] Possible suggestion for Event Sequencer Editing

[Brian C. <ca...@sl...>]

On Apr 29, 2005, at 10:55 AM, Surago Jones wrote:

> Hi,
>
> This is a small suggestion, but I'm not sure if it is just something
> that I inadvertently do.
>
> Anyways, in the event sequencer, when adding new events, I have on
> numerous occasion had a mouse spasm whilst selecting the source of an
> event, and an entry in the drop down box would be selected incorrectly
> as the mouse clicked over the 'Add' button which rests right under 
> where
> the drop down box opens up to.

I can see that.  I moved the source pull down over and added a little 
space.

brian

Re: [sleuthkit-developers] Typo error in Autopsy v2.05 Create Timeline results

[Brian C. <ca...@sl...>]

On Apr 29, 2005, at 10:40 AM, Surago Jones wrote:

> Hi,
>
> I have just noticed a typo in the create timeline results page.  It
> states 'Comma delimited files cannot be viewed from withing Autopsy',
> however it should probably say 'within' rather than 'withing'.

Thanks. I just fixed it.

brian

[sleuthkit-developers] Possible suggestion for Event Sequencer Editing

[Surago J. <su...@sj...>]

Hi,

This is a small suggestion, but I'm not sure if it is just something
that I inadvertently do.

Anyways, in the event sequencer, when adding new events, I have on
numerous occasion had a mouse spasm whilst selecting the source of an
event, and an entry in the drop down box would be selected incorrectly
as the mouse clicked over the 'Add' button which rests right under where
the drop down box opens up to.

Lol, yes I know this sounds rather silly, but if the 'Add' button was
possibly further down, or to the side of the drop down box we wouldn't
have this problem.  Alas this would possibly screw with the aesthetics
of the page as well.

Anyways, this is just a suggestion to (maybe?) help improve the product.

Cheers

Surago.

[sleuthkit-developers] Typo error in Autopsy v2.05 Create Timeline results

[Surago J. <su...@sj...>]

Hi,

I have just noticed a typo in the create timeline results page.  It
states 'Comma delimited files cannot be viewed from withing Autopsy',
however it should probably say 'within' rather than 'withing'.

Just a small update, but everything helps to maintain professionalism of
the product. :)

Below is a full cut and past of the result screen, possibly not
required, but at least it should help to know what/where I'm talking
about.

Cheers

Surago.



---

Creating Timeline using all dates (Time Zone: 'GMT-0600')

Timeline saved to
/forensics/ev.locker/sotmforensic/host1/output/timeline_commadelimited_h
ourly.txt

Comma delimited files cannot be viewed from withing Autopsy.
Open it in a spreadsheet or other data processing tool.

---

Re: [sleuthkit-developers] small patch for src/fstools/fatfs.c verbose message

[Brian C. <ca...@sl...>]

Thanks.  I fixed one of the instances in the v2 upgrade, but missed the 
other.  It has been fixed.

thanks,
brian

On Mar 13, 2005, at 4:53 AM, Rudolph Pereira wrote:

> There's a slight error with the verbose message output of
> src/fstools/fatfs.c in sleuthkit 1.73.
> Briefly, the sector numbers outputted by the verbose status messages
> don't actually match the sectors being looked at.
>
> The patch supplied is against the above version.
>
> Thanks
> <fatfs.patch>

[sleuthkit-developers] small patch for src/fstools/fatfs.c verbose message

[Rudolph P. <ru...@us...>]

There's a slight error with the verbose message output of
src/fstools/fatfs.c in sleuthkit 1.73.
Briefly, the sector numbers outputted by the verbose status messages 
don't actually match the sectors being looked at.

The patch supplied is against the above version.

Thanks

Re: [sleuthkit-developers] Possible Suggestion for timeline creation in future versions of Autopsy

[Brian C. <ca...@sl...>]

I can add this to the TODO list.  The basic concept can be achieved=20
using the file name search in the File Mode, but then you can sort only=20=

on one of the times and not a full timeline.

brian


On Feb 15, 2005, at 1:24 AM, Surago Jones wrote:

> Hi all,
>
> Whilst using Autopsy, and testing with a couple different suspect
> images, I have found that now and again I am often running several
> commands from the command line to help the investigation process.
>
> One process I often complete as part of an investigation is to create =
a
> timeline of files and folders that start with a '.' (dot).  I was
> thinking that an additional option in the 'Create Timeline' feature of
> Autopsy could allow an extra step to be run that would run grep to=20
> limit
> the timeline to certain details..
>
> For example, I run the following command to get a timeline of all '.'
> (dot) folders and files...
>
> grep '\/\.' flsdatafile > fls-dotfiles.dat
>
> It would be useful if on the 'Create Timeline' form, if the user could
> click a button (Similar to the pre-defined search options, on the=20
> search
> form) in order to create various useful timelines.   Another example
> would be to create a timeline of only the 'dev' folders.
>
> If this could be templated in some way, then maybe people could
> place/upload their own search options/template on the sleuthkit=20
> website,
> as whilst each investigation differs from each other, there is still
> some common ground.
>
> In the case of the dot files, it currently appears to be a common
> practice of intruders to utilise files and folders starting with a =
dot.
> Obviously, as time progresses and development on the rootkit side of
> things and the forensic side of things this practice may become rare =
as
> it is an easy method for identifying possible suspect files and=20
> folders.
>
> Just an idea I thought would help improve Autopsy's usability.
>
> Cheers
>
> Surago
>
>
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] Possible Suggestion for timeline creation in future versions of Autopsy

[Surago J. <su...@sj...>]

Hi all,

Whilst using Autopsy, and testing with a couple different suspect
images, I have found that now and again I am often running several
commands from the command line to help the investigation process.

One process I often complete as part of an investigation is to create a
timeline of files and folders that start with a '.' (dot).  I was
thinking that an additional option in the 'Create Timeline' feature of
Autopsy could allow an extra step to be run that would run grep to limit
the timeline to certain details..

For example, I run the following command to get a timeline of all '.'
(dot) folders and files...

grep '\/\.' flsdatafile > fls-dotfiles.dat

It would be useful if on the 'Create Timeline' form, if the user could
click a button (Similar to the pre-defined search options, on the search
form) in order to create various useful timelines.   Another example
would be to create a timeline of only the 'dev' folders.

If this could be templated in some way, then maybe people could
place/upload their own search options/template on the sleuthkit website,
as whilst each investigation differs from each other, there is still
some common ground. =20

In the case of the dot files, it currently appears to be a common
practice of intruders to utilise files and folders starting with a dot.
Obviously, as time progresses and development on the rootkit side of
things and the forensic side of things this practice may become rare as
it is an easy method for identifying possible suspect files and folders.

Just an idea I thought would help improve Autopsy's usability.

Cheers=20

Surago

Re: [sleuthkit-developers] Re: [sleuthkit-users] Split Image Question

[David C. <dav...@gm...>]

seq -w will solve that problem a little more elegantly :)


On Wed, 2 Feb 2005 13:41:58 -0800, Seth Arnold <sa...@im...> wrote:
> On Tue, Feb 01, 2005 at 11:38:23AM -0500, Brian Carrier wrote:
> > >1.  I feel that there should be a maximum command line size, but
> > >cannot seem to find one.  I just ran some tests that had over 60KB of
> > >data in arguments (390 file names each over 160 bytes long) and there
> > >were no problems.  This was on OS X, so I'm not sure if other OSes are
> > >different.  Anyone know?
> >
> > Actually, I guess this should be shell dependent and not OS dependent.
> > I am using:
> 
> I don't expect any shells would implement the limit on their own. Some
> experiementation shows that it is around 128k on my SuSE 9.2 system with
> a 2.6 kernel and on my Debian 3.0 system with a 2.2 kernel.
> 
> (The exact limit varies based on the environment as well as command line
> arguments.)
> 
> I've heard that some Unix systems have limits of one megabyte! Others
> (such as an old SCO 3.2.4.2 system I used to use) have much lower limits,
> perhaps 8k or 16k or so.. I've since reclaimed those brain cells.
> 
> For 'numbered files' support, I've found that there are -two- popular
> ways to show lists:
>   foo.1
>   foo.2
>   foo.3
>   ...
>   foo.10
>   foo.11
>   ...
> 
> and
>   foo.001
>   foo.002
>   ...
>   foo.010
>   ...
> 
> I've found that the first style can be easily handled with seq(1):
> for f in `seq 1 100` ; do echo foo.${f} ; done
> The second style is only slightly harder:
> for f in `seq 1 100` ; do F=`printf %03d $f` ; echo foo.${F} ; done
> 
> Analogues in perl are left as an exercise for the reader. :)
> 
> 
>

Re: [sleuthkit-developers] Re: [sleuthkit-users] Split Image Question

[Seth A. <sa...@im...>]

On Tue, Feb 01, 2005 at 11:38:23AM -0500, Brian Carrier wrote:
> >1.  I feel that there should be a maximum command line size, but=20
> >cannot seem to find one.  I just ran some tests that had over 60KB of=20
> >data in arguments (390 file names each over 160 bytes long) and there=20
> >were no problems.  This was on OS X, so I'm not sure if other OSes are=
=20
> >different.  Anyone know?
>=20
> Actually, I guess this should be shell dependent and not OS dependent. =
=20
> I am using:

I don't expect any shells would implement the limit on their own. Some
experiementation shows that it is around 128k on my SuSE 9.2 system with
a 2.6 kernel and on my Debian 3.0 system with a 2.2 kernel.

(The exact limit varies based on the environment as well as command line
arguments.)

I've heard that some Unix systems have limits of one megabyte! Others
(such as an old SCO 3.2.4.2 system I used to use) have much lower limits,
perhaps 8k or 16k or so.. I've since reclaimed those brain cells.

For 'numbered files' support, I've found that there are -two- popular
ways to show lists:
  foo.1
  foo.2
  foo.3
  ...
  foo.10
  foo.11
  ...

and
  foo.001
  foo.002
  ...
  foo.010
  ...

I've found that the first style can be easily handled with seq(1):
for f in `seq 1 100` ; do echo foo.${f} ; done
The second style is only slightly harder:
for f in `seq 1 100` ; do F=3D`printf %03d $f` ; echo foo.${F} ; done

Analogues in perl are left as an exercise for the reader. :)

Re: [sleuthkit-developers] Re: [sleuthkit-users] Split Image Question

[Brian C. <ca...@sl...>]

On Feb 1, 2005, at 11:33 AM, Brian Carrier wrote:

> 1.  I feel that there should be a maximum command line size, but 
> cannot seem to find one.  I just ran some tests that had over 60KB of 
> data in arguments (390 file names each over 160 bytes long) and there 
> were no problems.  This was on OS X, so I'm not sure if other OSes are 
> different.  Anyone know?

Actually, I guess this should be shell dependent and not OS dependent.  
I am using:

% bash --version
bash --version
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin7.0)
Copyright (C) 2002 Free Software Foundation, Inc.

brian

[sleuthkit-developers] Re: [sleuthkit-users] Split Image Question

[Brian C. <ca...@sl...>]

Ok, globbing it is.  I was under the impression that globbing did not 
necessarily return in sorted order, but the documentation says that it 
does.  There seem to be two "issues" at this point:

1.  I feel that there should be a maximum command line size, but cannot 
seem to find one.  I just ran some tests that had over 60KB of data in 
arguments (390 file names each over 160 bytes long) and there were no 
problems.  This was on OS X, so I'm not sure if other OSes are 
different.  Anyone know?

2.  There is a maximum number of files that a process may have open.  
On OS X, it seems to be 253.  I am not opening the file until it is 
needed, but if you run 'dls' on the file system then all images will be 
needed. I would rather not develop some form of caching system with 
book keeping and a FIFO scheme.  Do people have over 250 split images?  
That is 160 GB for CD images and over 500GB  for 2 GB images.  (I can't 
imagine anyone burning 250 CDs).  In the future, this limitation will 
probably have to be removed, but I'm assuming that it will be fine for 
the first version.

brian

Re: [sleuthkit-developers] timeline of windows registry

[Brian C. <ca...@sl...>]

On Jan 12, 2005, at 8:42 AM, Uwe Danz wrote:

> Two questions and some answers ;-)
> 1.) Do someone know good tools to generate a timeline of
>     the windows registry?

I do not, besides reformating the output of other tools into the 
mactime format.


> 2.) Make a change of the timeline-format sense?

Yea, I can work that in.


brian

[sleuthkit-developers] timeline of windows registry

[Uwe D. <uwe...@gm...>]

Two questions and some answers ;-)
1.) Do someone know good tools to generate a timeline of
    the windows registry?
2.) Make a change of the timeline-format sense?

timeline of windows registry:
=============================

I'm trying to correlate the mac-timeline with the registry timeline. 

I searched in the mailing-archives and find only in "sleuthkit--developers"
some ideas about "Registry Viewing Tools (not yet public)" and the samba
project.

I the past I used dumpreg to get a registry copy with timestamps.
But this was not so useful.

Today I generate Registry timelines with
- Import files with Regedit on WinXP,
  (Here one big problem, the ACL of the imported SAM- and SECURITY-HIVE
   must be changed, so the timestamp of SAM, SECURITY, SECURITY\Cache,
   SECURITY\Policy and SECURITY\RXACT will be overridden)
- Total Commander with Registry Plugin to export registry with timestamps
  http://www.ghisler.com/ and http://www.totalcmd.net/plugring/registry.html
- the plugin exports the timestamps of the hives to a TXT file.
  (also all keys and most of the values as ASCII or UNICODE)
- grep and sort make the rest 

The way via Windows, Admin-Rights, Registry, Total-Commander,
Registry-Plugin looks not very respectably.
Does a read-only and open-source windows-registry-timelinie tool exist?

The other point is the format of the timeline:
==============================================
I prefer to use a sort and grep-able time format like the one of the
registry timeline plugin:
2004/04/05,10:57:26,HKEY_USERS\software_forensic_case\Adobe\Acrobat
Reader\5.0\Language\next 

But the sleuthkit tool mactime produce the following format:
Tue Jul 11 1995 16:50:00   33792 m.. -/--wx-wx-wx ... 279-128-3 d:\abc.EXE
                             831 m.. -/--wx-wx-wx ... 280-128-3 d:\abc.TXT
Wed Mar 27 1996 21:59:10     585 m.. -/--wx-wx-wx ... 689-128-1 d:\abc.H

Yes I know the switches -d -y of the mactime tool. But the month as text
is not the best idea for merging and sorting.

I use the following patch:
/opt/sleuthkit/src/timeline> diff mactime.bas mactime.base.org
416c416
< 			  "$yeart/$mon/$mday,$hour:$min:$sec";
---
> 			  "$yeart $digit_to_month{$mon} $mday $digit_to_day{$wday}
$hour:$min:$sec"; 

Is there a chance to change the code of the sleuthkit in this way?
Or instead of - is it possible to insert an additional switch for this
format?

Regards,
   Uwe.

-- 
"The greatest of all faults is to be conscious of none" Thomas 
Carlyle
Please use PGP - my PGP-key-ID: 0x0FD36935 (2048 Bit)
PGP-fingerprint: C9A6 0E4A 9EC5 FF24 4FF8 6BE5 1E02 1C74
key-server: http://the.earth.li/pgp_lookup.html

+++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
AKTION für Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben

[sleuthkit-developers] 64-bit testers

[Brian C. <ca...@ce...>]

I'm looking for people interested in playing with the new TSK version 
that includes support for 64-bit machines.  There are actually very few 
changes, but I have done only limited testing on a machine in the 
sourceforge compile farm.

Let me know if you are interested and I'll send it to you tonight.

brian

[sleuthkit-developers] DD + Hash

[Márcio C. <ma...@di...>]

Hello!

Does anybody have references about tools like DD that calculates hash at the same time? I found dcfldd, but I'm wondering if there is any patch for dd_rescue or something like that.

Thanks a lot!

Márcio.

Re: [sleuthkit-developers] patches for sleuthkit 1.72

[Brian C. <ca...@sl...>]

So, after doing some research on how to do pointer arithmetic on 32-bit 
and 64-bit systems, the 'uintptr_t' type can be used instead of 'int' 
(which is what I was doing).  I will modify the patches to use this 
type because there are some compilers that require some type of casting 
  of pointers.

brian



On Sep 18, 2004, at 12:03 PM, Martin Godisch wrote:

> Hi,
>
> Please consider applying the attached patches to the sleuthkit source.
> They are required to compile sleuthkit on Debian's 64 bit plattforms.
>
> Kind regards,
>
> Martin
> <04_fix_porting.diff><06_fix_cast.diff>

Re: [sleuthkit-developers] patches for sleuthkit 1.72

[Brian C. <ca...@sl...>]

Thanks!  I'll take a look at them.  There were some platforms that 
complained if some of the castings were removed, so I'll incorporate 
these and figure out which ones have issues.

thanks
brian

On Sep 18, 2004, at 12:03 PM, Martin Godisch wrote:

> Hi,
>
> Please consider applying the attached patches to the sleuthkit source.
> They are required to compile sleuthkit on Debian's 64 bit plattforms.
>
> Kind regards,
>
> Martin
> <04_fix_porting.diff><06_fix_cast.diff>

Re: [sleuthkit-developers] dls questions

[Brian C. <ca...@sl...>]

On Aug 5, 2004, at 2:23 PM, Epsilon wrote:

> Greetings,
>
> When running dls, what is the difference between running dls alone (to
> extract unallocated sectors) and running dls with the "-s" option ("to
> copy only the slack space of the image")?
>
> What exactly is the "-s" option doing?  Does it capture file slack or
> filesystem slack (unallocated sectors)?  Or are filesystem slack and
> unallocated sectors different things?

The -s behavior changed with 1.71, so I'll describe that one.  Normal 
dls extracts out the contents of each unallocated block / cluster etc.  
'dls -s' extracts the data at the end of the last block / cluster of a 
file.  It does this by reading the last data unit of each file, 
clearing the actual content of the file and then writing the full data 
unit.  So, the output will be a multiple of a data unit (cluster / 
block), but only the slack space will be non-zero.  You can convert 
between the address in the slack space image and the original image 
with dcalc.

brian

[sleuthkit-developers] dls questions

[Epsilon <ep...@ya...>]

Greetings,

When running dls, what is the difference between running dls alone (to
extract unallocated sectors) and running dls with the "-s" option ("to
copy only the slack space of the image")?

What exactly is the "-s" option doing?  Does it capture file slack or
filesystem slack (unallocated sectors)?  Or are filesystem slack and
unallocated sectors different things?

FWIW I'm using v1.71.

Thanks,
ep.


		
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now. 
http://messenger.yahoo.com

Re: [sleuthkit-developers] fls error

[Brian C. <ca...@sl...>]

On Aug 5, 2004, at 12:51 PM, Epsilon wrote:

> Greetings,
>
> I'm using TSK v1.71 and seeing this error message from the "fls"
> command:
>
> $ fls -r -f fat32 <image>
> (...lots of output...)
> fls: fatfs_dent_walk: g_curdirptr is set! recursive?

Can you give the line or two prior to this error?  how about when '-v' 
is given?  That output could be huge, so you can send it to me 
directly.

thanks,
brian

[sleuthkit-developers] fls error

[Epsilon <ep...@ya...>]

Greetings,

I'm using TSK v1.71 and seeing this error message from the "fls"
command:

$ fls -r -f fat32 <image>
(...lots of output...)
fls: fatfs_dent_walk: g_curdirptr is set! recursive?

I believe this happens with v1.70 as well.

Thanks in advance,
ep.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [sleuthkit-developers] Problems trying to extract slack using dls

[Brian C. <ca...@sl...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 19, 2004, at 7:31 AM, Kucenski, Matthew A. wrote:

> "read block read error (4096@18446744073709547520): File too large 
> (data
> block)"

Wow.  That is definitely a TSK bug.  It is trying to read at byte 
offset 18,446,744,073,709,547,520 bytes.  Can you run 'dls' with the 
'-v' flag and send the verbose output to me (you can leave it off the 
list because it could be quite large)?  I'll look at it later today.

brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFA+8MhOK1gLsdFTIsRAu1PAJ9xKnMUDNCdFQEQwcTxuQaTSYcR6QCfXy+n
NMYHRFtCf9ZIM3mexrGkAOI=
=amU7
-----END PGP SIGNATURE-----

RE: [sleuthkit-developers] Problems trying to extract slack using dls

[Kucenski, M. A. <Mat...@di...>]

"read block read error (4096@18446744073709547520): File too large (data
block)"

-----Original Message-----
From: Brian Carrier [mailto:ca...@sl...] 
Sent: Friday, July 16, 2004 4:30 PM
To: Kucenski, Matthew A.
Cc: Sleuthkit
Subject: Re: [sleuthkit-developers] Problems trying to extract slack using
dls


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 16, 2004, at 3:29 PM, Kucenski, Matthew A. wrote:

> "read block read error"

What values are in the parentheses?  That shows from where it was 
trying to read.

brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFA+DqyOK1gLsdFTIsRAnoUAJ9MoPLx8r2FrNX9vQN5saUE+J8rQACfb6GU
mX3J9ae+xOjUB08vyUsx7VA=
=Zr9T
-----END PGP SIGNATURE-----