sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.

Re: [sleuthkit-users] FAT filesystem timestamp confusion

[Angus M. <an...@n-...>]

On Friday 04 Apr 2003 12:10 am, you wrote:
> Angus Marshall <an...@n-...> said:
> > On Thursday 03 Apr 2003 11:29 pm, Brian Carrier wrote:
> The Sleuth Kit (and I would imagine Linux) reads the time from the FAT
> image and translate it into a UNIX time (which is an offset relative to
> GMT).  It then uses the 'localtime' function that translates the UNIX time
> (a big number) to a human readable format.  That function takes the
> timezone and savings time into account and adjusts accordingly.  Therefore,
> that function is changing the time unless the timezone is set to one that
> does not change.

Interesting - OK, I'll tweak the workstation tomorrow so that it's locked into 
GMT and also change the autopsy config to lock that to GMT too. I'll report 
back sometime over the weekend.


> > I've also noticed a curious behaviopur with FAT12 on the latest sleuthkit
> > release. Files on a floppy were written to it at 21:45BST, with the
> > timezone set to GMT0BST, they show as 2:45 tomorrow in the timeline.
> > (file writes and analysis done on the same machine btw)
>
> What does a 'ls' or 'dir' show?

ls gives the correct modification time of 21:45

Re: [sleuthkit-users] FAT filesystem timestamp confusion

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

Angus Marshall <an...@n-...> said:

> On Thursday 03 Apr 2003 11:29 pm, Brian Carrier wrote:

> >
> > That really doesn't explain the log entry time versus the file time though.
> > The only thing that I can think about is that Windows does not handle day
> > light savings (or BST) well at all!  I sent a message about this to the
> > forensic tool testing list a while back.  In Windows, you can make a file
> > before day light savings takes effect, let the clock roll over and then
> > check the time again and it will be off by an hour!  Windows appears to
> > subtract an hour from all files during these time frames instead of just
> > the ones during those 6 months. (EnCase v3 does the same thing).
> >
> > Therefore, I wonder if the problem is because Linux is changing the time by
> > an hour when it displays it, but since Windows didn't then it is having
> > issues. What happens if you set the timezone to GMT (or even EST) and not
> > one of the timezones that changes (like EST5EDT).  Does that help?
> >
> > brian
> 
> Wow! thanks for the fast reply Brian.
> 
> Setting the zone to GMT does seem to make the filesystem timestamp
> consistent with the file contents, but I'd really like to know why it makes 
> a difference at all on a FAT filesystem in this case. I have to give some 
> initial findings to the police tomorrow and am wary of giving them 
> potentially wrong info. because it could affect an alibi. (Side note, when I 
> mount the image read-only and issue a ls --full-time, I notice that some 
> files have an offset field of 0000 and some have +0100 - could my experience 
> be an artefact of something "clever" in the Linux system I'm using ? ls on 
> the files being questioned above agrees with the results of the timeline 
> analysis btw)

The Sleuth Kit (and I would imagine Linux) reads the time from the FAT image
and translate it into a UNIX time (which is an offset relative to GMT).  It
then uses the 'localtime' function that translates the UNIX time (a big
number) to a human readable format.  That function takes the timezone and
savings time into account and adjusts accordingly.  Therefore, that function
is changing the time unless the timezone is set to one that does not change.


> I've also noticed a curious behaviopur with FAT12 on the latest sleuthkit 
> release. Files on a floppy were written to it at 21:45BST, with the timezone 
> set to GMT0BST, they show as 2:45 tomorrow in the timeline. (file writes and 
> analysis done on the same machine btw)

What does a 'ls' or 'dir' show?

brian

Re: [sleuthkit-users] FAT filesystem timestamp confusion

[Angus M. <an...@n-...>]

On Thursday 03 Apr 2003 11:29 pm, Brian Carrier wrote:
> Angus Marshall <an...@n-...> said:
> > The situation is this - the day in question falls during GMT time, but
> > we're now into BST. I've set the timezone in autopsy to be GB, but have
> > discovered a conflict in one of the files I'm looking at - it's a log
> > file and the application generating it has stamped the time in the file
> > as an hour later than the last write time on the file itself.
> >
> > For reference, I'm running on RedHat Linux 8.0 with a clock that's firmly
> > in BST at the moment.
>
> Angus,
>
> First, FAT does not care about time zones.  Most file systems store the
> time with respect to GMT and when the time is actually read the local OS
> adjusts accordingly.  FAT just saves the time and does not care about the
> timezone, so that is why you will not see a difference when you change the
> timezone in Autopsy.
>
> That really doesn't explain the log entry time versus the file time though.
> The only thing that I can think about is that Windows does not handle day
> light savings (or BST) well at all!  I sent a message about this to the
> forensic tool testing list a while back.  In Windows, you can make a file
> before day light savings takes effect, let the clock roll over and then
> check the time again and it will be off by an hour!  Windows appears to
> subtract an hour from all files during these time frames instead of just
> the ones during those 6 months. (EnCase v3 does the same thing).
>
> Therefore, I wonder if the problem is because Linux is changing the time by
> an hour when it displays it, but since Windows didn't then it is having
> issues. What happens if you set the timezone to GMT (or even EST) and not
> one of the timezones that changes (like EST5EDT).  Does that help?
>
> brian

Wow! thanks for the fast reply Brian.

Setting the zone to GMT does seem to make the filesystem timestamp
consistent with the file contents, but I'd really like to know why it makes 
a difference at all on a FAT filesystem in this case. I have to give some 
initial findings to the police tomorrow and am wary of giving them 
potentially wrong info. because it could affect an alibi. (Side note, when I 
mount the image read-only and issue a ls --full-time, I notice that some 
files have an offset field of 0000 and some have +0100 - could my experience 
be an artefact of something "clever" in the Linux system I'm using ? ls on 
the files being questioned above agrees with the results of the timeline 
analysis btw)


I've also noticed a curious behaviopur with FAT12 on the latest sleuthkit 
release. Files on a floppy were written to it at 21:45BST, with the timezone 
set to GMT0BST, they show as 2:45 tomorrow in the timeline. (file writes and 
analysis done on the same machine btw)

Re: [sleuthkit-users] FAT filesystem timestamp confusion

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

Angus Marshall <an...@n-...> said:
 
> The situation is this - the day in question falls during GMT time, but we're 
> now into BST. I've set the timezone in autopsy to be GB, but have discovered 
> a conflict in one of the files I'm looking at - it's a log file and the 
> application generating it has stamped the time in the file as an hour later 
> than the last write time on the file itself.
> 
> For reference, I'm running on RedHat Linux 8.0 with a clock that's firmly in 
> BST at the moment.

Angus,

First, FAT does not care about time zones.  Most file systems store the time
with respect to GMT and when the time is actually read the local OS adjusts
accordingly.  FAT just saves the time and does not care about the timezone, so
that is why you will not see a difference when you change the timezone in
Autopsy. 

That really doesn't explain the log entry time versus the file time though. 
The only thing that I can think about is that Windows does not handle day
light savings (or BST) well at all!  I sent a message about this to the
forensic tool testing list a while back.  In Windows, you can make a file
before day light savings takes effect, let the clock roll over and then check
the time again and it will be off by an hour!  Windows appears to subtract an
hour from all files during these time frames instead of just the ones during
those 6 months. (EnCase v3 does the same thing).

Therefore, I wonder if the problem is because Linux is changing the time by an
hour when it displays it, but since Windows didn't then it is having issues. 
What happens if you set the timezone to GMT (or even EST) and not one of the
timezones that changes (like EST5EDT).  Does that help?

brian

[sleuthkit-users] Sleuth Kit 1.61 and Autopsy 1.71 Release

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

The Sleuth Kit version 1.61 and Autopsy version 1.71 are now
available.

    http://www.sleuthkit.org/sleuthkit
    http://www.sleuthkit.org/autopsy



What is The Sleuth Kit?
  
The Sleuth Kit was previously known as The @stake Sleuth Kit (TASK)
and is now independent from any organization.  All future releases
will be available from http://www.sleuthkit.org.



What is new in The Sleuth Kit 1.71?

The Sleuth Kit had features added and a  couple of bugs were fixed
(one is major and all users should upgrade).

Major New Features:
- Thumbnails are now created for graphic images in 'sorter'.  
- 'sorter' uses the '-z' flag with 'file' to get the format inside
  compressed files.
- 'hfind' now supports the new NIST NSRL hash format (version 2)
- 'hfind' now supports the Hash Keeper hash format 
- 'ifind -n' now accepts short names for FAT files.
- 'mactime' can create a summary of daily activity with '-i' 
- 'file' was updated due to a vulnerability in it

Bug Fixes:
- A final NTFS Index Buffer was not always being processed, which
  resulted in some files not being shown.  (Debugging help from
  Matthew Shannon).
- NTFS MFT entries with a Magic of 0 were marked as invalid
- 'fls' would crash if a clock skew file was given, the file
  had an inode of 0, and '-l' or '-m' was given.  (Debugging
  help from Josep Homs).
- 'ifind -n' could return the meta data address of a file that had
  a name shorter than the requested one

MD5 (sleuthkit-1.61.tar.gz) = cd6783f8d9a109ffe839912674e2f3cf



What is new in Autopsy 1.71:

Autopsy had user interface improvements and added support for new 
features in The Sleuth Kit.

Major New Features:
- 'autopsy' can be started with no arguments (port 9999 and localhost
  are assumed)
- The path of a directory or file can be entered instead of having to 
  click through directories (suggested by William Salusky)
- The path in each directory listing now contains hyper links that can
  be used to quickly return to previous directories  
- To add a passwd and group file to a timeline, only the image needs to
  be specified (Autopsy will find the inode values)
- When adding images, Autopsy will copy or create symlinks to the
  Evidence Locker instead of forcing the user to
- Added option to extact all graphic images and generate a page of
  thumbnails
- The new 'summary' page from 'mactime' is used when viewing timelines

Bug Fixes:
- Keyword searching would fail if special characters were not escaped.  
  /, ., [, ^, $, ", and - are now escaped
- The path of a strings file could not have a space in it
- The opening of a case was not being logged in the case log

MD5 (autopsy-1.71.tar.gz) = 931b672fabcdb2145ae51e2885e9b685



What is the April issue of The Sleuth Kit Informer on?

The April issue will cover the 'sorter' tool, including how it works and
how to write rulesets to customize how it handles file types.  

    http://www.sleuthkit.org/informer/


brian

http://www.sleuthkit.org

[sleuthkit-users] FAT filesystem timestamp confusion

[Angus M. <an...@n-...>]

Help! I'm confused by the way sleuthkit (with autopsy) is handling timestamps 
on a FAT32 filesystem.

I need to be able to establish an accurate timeline for one particular day and 
have managed to set things up so that I can get some sort of timelime, but I 
don't really understand how the timezone setting in Autopsy affects the 
results. (The skew concept is fine - I need to correct for a hw clock that's 
15 minutes fast so I've set it to +900).

The situation is this - the day in question falls during GMT time, but we're 
now into BST. I've set the timezone in autopsy to be GB, but have discovered 
a conflict in one of the files I'm looking at - it's a log file and the 
application generating it has stamped the time in the file as an hour later 
than the last write time on the file itself.

For reference, I'm running on RedHat Linux 8.0 with a clock that's firmly in 
BST at the moment.

Re: [sleuthkit-users] spurious binary outputs (SEC: UNCLASSIFIED)

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

Jarrad,

I actually never got the files.  You may want to zip them so that filtering
software doesn't drop them.  What version of TASK are you using?

brian

On Tue, Apr 01, 2003 at 08:51:44AM +1000, Lisman, Jarrad FLGOFF wrote:
> Hi, i wrote this in a few weeks ago, about getting some spurious binary data
> in my body files after creating them using autopsy. The problem seemed to be
> in ils/fls. I sent on part of the body file as requested but I don't know if
> it got through to Brian or not as I have had no reply.
> I have since had this problem on another image BUT when using mac-robber to
> create the body file instead it was fine. Any ideas? I am using RH 8.0,
> might it be another part of the DATEMANIP problem or whatever it was with
> the new version of perl?
> 
> Thanks
> 
> Jarrad
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> sleuthkit-users mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users

[sleuthkit-users] spurious binary outputs (SEC: UNCLASSIFIED)

[Lisman, J. F. <Jar...@de...>]

Hi, i wrote this in a few weeks ago, about getting some spurious binary data
in my body files after creating them using autopsy. The problem seemed to be
in ils/fls. I sent on part of the body file as requested but I don't know if
it got through to Brian or not as I have had no reply.
I have since had this problem on another image BUT when using mac-robber to
create the body file instead it was fine. Any ideas? I am using RH 8.0,
might it be another part of the DATEMANIP problem or whatever it was with
the new version of perl?

Thanks

Jarrad

Re: [sleuthkit-users] Newbie UTF-8 errors with mactime

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

The error is from the Perl DateManip library that mactime uses.  It has
some invalid values that Perl 5.8 does not like.  I emailed the author
a few months ago, but never heard back.   I don't think it is an issue
unless you enter the time in Portuguese.

brian

On Tue, Apr 01, 2003 at 12:17:00AM +1000, sh...@po... wrote:
> When I run mactime on an image I get a mactime report okay, but I also get dozens of error messages similar to:
> 
>   Malformed UTF-8 character.....
>   ..Date/Manip.pm.....
>   ..unexpected non-continuation byte 0x6c immediately after start byte 0xfa...
> 
> The hex chars in the above differ from message to message.
> 
> Are these errors normal? I am running Redhat Linux 8.0 with kernel 2.4.18-14. The file systems and images I am using are ext2. The language on my system is en_AU.UTF-8.
> 
> Thanks in advance.
>  
> Gary Robertson
> 
> 
> 
> This message was sent through MyMail http://www.mymail.com.au
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> sleuthkit-users mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users

[sleuthkit-users] Newbie UTF-8 errors with mactime

[<sh...@po...>]

When I run mactime on an image I get a mactime report okay, but I also get dozens of error messages similar to:

  Malformed UTF-8 character.....
  ..Date/Manip.pm.....
  ..unexpected non-continuation byte 0x6c immediately after start byte 0xfa...

The hex chars in the above differ from message to message.

Are these errors normal? I am running Redhat Linux 8.0 with kernel 2.4.18-14. The file systems and images I am using are ext2. The language on my system is en_AU.UTF-8.

Thanks in advance.
 
Gary Robertson



This message was sent through MyMail http://www.mymail.com.au

Re: [sleuthkit-users] NSRL 2.0

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

I have added support for NSRL 2.0.  If anyone can't wait until next
week, send me an email off list and I will send you the updated files.

brian


On Tue, Mar 25, 2003 at 04:42:00PM -0500, Mik...@da... wrote:
> Hi all. I've just installed TASK/AUTOPSY for some forensic work and I am
> trying to integrate sorter with the NIST NSRL 2.0 'known good' software
> hash. It appears that the current NSRL format is not yet supported;
> However, I noticed a stub in nsrl.c for VER2. Before I reinvent the wheel
> has anyone a patch to support the new format?
> 
> Thanks,
> Mike
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> sleuthkit-users mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users

[sleuthkit-users] Importing Images

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

Autopsy users,

I have modified the way that Autopsy imports partition images in the
next release (1.71).  The current (1.70) method is that the images
directory is created  and the user has to either symlink or copy the
image to the given location.  That is a pain.

I want to have the image in the evidence locker so that everything is
self contained.  So, the next version does more of the work for you.
You enter the full path of where the image currently resides and check
off if you want Autopsy to copy, symlink, or move the image to the
'images' directory.  It does a file system type check and then imports
the image using the selected method.

My user questions:
- Is this better method?

- I am concerned about providing the 'move' option because what if 
something happens and the images are lost.  But, there may not be
enough disk space to always do a copy.  I just don't want to have
people get mad at me because they lost an image somehow.  Thoughts?
I could just provide a warning with the 'move'.

You can reply off list.

brian

Re: [sleuthkit-users] Refining keyword searches

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

On Thu, Mar 27, 2003 at 11:23:05PM -0000, Silent Partner wrote:

> Am revisiting this point..... more in light of your recent postings to the list
> saying that a new version of the tools are being cooked at present..... and
> apologies for not just trying this out myself, have had to wipe my linux
> partitions...
> 
> Is it correct to say that in terms of  a forensic analysis involving Task /
> Autopsy :
> (1) It performs limited searches on files, hidden or unhidden
> (2) Hyperlink to view the not-hidden files
> (3) No support to show the contents of the hidden files found in a basic search
> if discovered.
> (4) Suggest mounting a partition in loopback for extensive searches, but outside
> autopsy, but have no access to the hidden files that the Task/Autopsy tools
> finds in its basic searches.

How are you defining limited?  Sure you can do more on the command line
with grep and find, but I think the Autopsy options are fairly standard
with other forensic tools.  

How are you defining hidden?  Do you mean deleted?  

Autopsy and The Sleuth Kit currently make no attempts at "guessing"
which data belongs to which files.  They only follow pointers and
values that are clearly defined.  So, if a search hits a block that
does not have a meta data structure that points to it, then you will not
get any additional data.  If all of the pointers exist for a deleted
file, then its contents will be shown.


> 
> Also, in forensic analysis, a master image is obtained, checksummed and stored.
> You work from a copy of this. In this instance, shouldn't it be the case that
> task/autopsy undeletes hidden files into the image and re-checksums? or
> automatically creates a duplicate image of this nature in the locker? as long as
> the master is available to have the same process performed on it and can match
> the new checksummed image, then its fine.
> 
> I agree that it is inherently "bad" to tamper with an image. But.... I also
> think its inherently bad for a forensic "evidence" gathering tool not to cater
> for hidden files. Don't crooks delete files with "interesting" info??

The future plan to integrate more advanced file recovery involves making
a separate file that describes the relationships between data units and
files.  Then you can always say that the data was found from the original
image.  Otherwise, you have to show that when you rewrote the image that
you did not overwrite evidence or add evidence etc.  

 
> Any plans to extend the searching capabilities in the Autopsy interface? 

What else are you looking for?  I need to make a second searching option
to search by file instead of image so that keywords across fragmented
data units are found.

brian

Re: [sleuthkit-users] Refining keyword searches

[Silent P. <sp...@si...>]

Quoting: "Brian Carrier"  Sent: Monday, March 17,
> On Sat, Mar 15, 2003 at 09:51:58PM -0000, Silent Partner wrote:
> > Quoting: "Brian Carrier"
> > > Your best bet would be to mount the image in loopback and run a grep
> > > script.  I have no clue exactly what it would be though.  It would look
> > > something like this for one keyword:
> >
> > Task/Autopsy have information regarding hidden / deleted files. When it
works
> > with images, does it undelete such files into the image so that they are
> > available for manual searching if the image is mounted in loopback?
>
> No! That would be very bad since it would modify the image and any
> integrity checks would fail.  TASK isn't an automated file recovery
> tool yet. It gives you all the information about where stuff is on the
> disk, but in general it requires manual recovery.
>
> brian

Am revisiting this point..... more in light of your recent postings to the list
saying that a new version of the tools are being cooked at present..... and
apologies for not just trying this out myself, have had to wipe my linux
partitions...

Is it correct to say that in terms of  a forensic analysis involving Task /
Autopsy :
(1) It performs limited searches on files, hidden or unhidden
(2) Hyperlink to view the not-hidden files
(3) No support to show the contents of the hidden files found in a basic search
if discovered.
(4) Suggest mounting a partition in loopback for extensive searches, but outside
autopsy, but have no access to the hidden files that the Task/Autopsy tools
finds in its basic searches.

Also, in forensic analysis, a master image is obtained, checksummed and stored.
You work from a copy of this. In this instance, shouldn't it be the case that
task/autopsy undeletes hidden files into the image and re-checksums? or
automatically creates a duplicate image of this nature in the locker? as long as
the master is available to have the same process performed on it and can match
the new checksummed image, then its fine.

I agree that it is inherently "bad" to tamper with an image. But.... I also
think its inherently bad for a forensic "evidence" gathering tool not to cater
for hidden files. Don't crooks delete files with "interesting" info??

Any plans to extend the searching capabilities in the Autopsy interface? The
timeline stuff is great, but so much of the evidence gathering process hinges on
searching for info, and trying to discover evidence of info that was once on the
disk that is intentionally concealed.

Sid.

RE: [sleuthkit-users] dd of entire HD

[Altheide, C. B. <Alt...@nv...>]

Even if there is only one partition on the drive, by dd'ing the entire
physical drive, you're grabbing at least 63 sectors of extraneous
(not-partition related) data at the beginning of the drive, and, depending
on the OS/FS, some more at the end, after the logical partition ends.
You'll need to follow the steps outlined in the previously posted Sleuthkit
Informer to do anything useful with that image in Autopsy.

Cory Altheide
Computer Forensics Specialist
NCI Information Systems, Inc.
NNSA Cyber Forensics Center
alt...@nv...

> -----Original Message-----
> From: Eagle Investigative Services [mailto:in...@ea...] 
> Sent: Thursday, March 27, 2003 7:31 AM
> To: sle...@li...
> Subject: RE: [sleuthkit-users] dd of entire HD
> 
> 
> I'm a little confused here.
> 
> In the docs it says Autopsy will read a dd image.
> 
> So what you guys are saying is that if I take a dd image
> of a drive, and have Autopsy look at that image, it can't
> see the whole thing?
> 
> Do I need to split the drive into images matching the
> relative partitions first??
> 
> What if there's only one partition on the drive?
> 
> Thanks,
> 
> Niall.
> 

RE: [sleuthkit-users] dd of entire HD

[Eagle I. S. <in...@ea...>]

I'm a little confused here.

In the docs it says Autopsy will read a dd image.

So what you guys are saying is that if I take a dd image
of a drive, and have Autopsy look at that image, it can't
see the whole thing?

Do I need to split the drive into images matching the
relative partitions first??

What if there's only one partition on the drive?

Thanks,

Niall.

-----Original Message-----
From: sle...@li...
[mailto:sle...@li...]On Behalf Of Paul
Bakker
Sent: Thursday, March 27, 2003 5:28 AM
To: sle...@li...
Subject: [sleuthkit-users] dd of entire HD



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

Hello,

In my knowledge, Autopsy is only able to work with dd images of partitions.
(As it is able to mount these via the loop device)

In a case I am handling now I received the image of an entire harddisk.
* Is Autopsy capable of reading this in?
* Is there a tool that can loopback mount the partitions from within the hd
image?
* Is there a tool that can extract the partitions from the hd image?
  (What to do about unallocated space then (Not partitioned!)? How does one
investigate
  that using Autopsy?)

Paul Bakker

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1

iQA/AwUBPoLSJfjAwPuBNeIlEQLifwCfT2RFEXsrJjLJV0f8YDIDw20NEm8An25o
5a5GS3aSP0cuRn9GtLIM3lxJ
=7byL
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] dd of entire HD

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

The last issue of the Sleuth Kit Informer had an article on splitting
the disk into partitions using 'dd' and 'fdisk'.

	http://sleuthkit.sourceforge.net/informer/sleuthkit-informer-2.html

brian


On Thu, Mar 27, 2003 at 11:28:21AM +0100, Paul Bakker wrote:
>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> In my knowledge, Autopsy is only able to work with dd images of partitions.
> (As it is able to mount these via the loop device)
> 
> In a case I am handling now I received the image of an entire harddisk.
> * Is Autopsy capable of reading this in?
> * Is there a tool that can loopback mount the partitions from within the hd image?
> * Is there a tool that can extract the partitions from the hd image?
>   (What to do about unallocated space then (Not partitioned!)? How does one investigate
>   that using Autopsy?)
> 
> Paul Bakker
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.1.1
> 
> iQA/AwUBPoLSJfjAwPuBNeIlEQLifwCfT2RFEXsrJjLJV0f8YDIDw20NEm8An25o
> 5a5GS3aSP0cuRn9GtLIM3lxJ
> =7byL
> -----END PGP SIGNATURE-----
> 

Re: [sleuthkit-users] dd of entire HD

[David B. <to...@so...>]

Paul,
since you have the partition table you can 'dd' each partition from the
entire disk (for example dd if=disk of=hda1 bs=1024 count=XX skip=XX)
where count and skip can be obtained from the partition table (or each
extended partition table).

[sleuthkit-users] dd of entire HD

[Paul B. <ba...@fo...>]

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

Hello,

In my knowledge, Autopsy is only able to work with dd images of =
partitions.
(As it is able to mount these via the loop device)

In a case I am handling now I received the image of an entire harddisk.
* Is Autopsy capable of reading this in?
* Is there a tool that can loopback mount the partitions from within the =
hd image?
* Is there a tool that can extract the partitions from the hd image?
  (What to do about unallocated space then (Not partitioned!)? How does =
one investigate
  that using Autopsy?)

Paul Bakker

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1

iQA/AwUBPoLSJfjAwPuBNeIlEQLifwCfT2RFEXsrJjLJV0f8YDIDw20NEm8An25o
5a5GS3aSP0cuRn9GtLIM3lxJ
=3D7byL
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] fls core

[Josep M H. <jm...@me...>]

Brian Carrier wrote:

> Replace 'fls.c' in /src/fstools with the attached version.  I was
> missing a NULL pointer check when a clock skew was used.  This will be
> incorporated into the next release.
> 
> brian
> 

Great ! it works.
Thanks for your time.

Best regards ,
Josep M Homs

Re: [sleuthkit-users] fls core

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

On Wed, Mar 26, 2003 at 03:25:04PM +0100, Josep M Homs wrote:

> I'll send to you directly all the debug details in order to don't flood 
> the list.

Replace 'fls.c' in /src/fstools with the attached version.  I was
missing a NULL pointer check when a clock skew was used.  This will be
incorporated into the next release.

brian

Re: [sleuthkit-users] NSRL 2.0

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

Mike,

I didn't realize that it had been released.  I'll work on it this week
(I'm hoping to have a new sleuth kit release out next week).  But,
if you can get to it sooner, a patch would be welcome.

brian


On Tue, Mar 25, 2003 at 04:42:00PM -0500, Mik...@da... wrote:
> Hi all. I've just installed TASK/AUTOPSY for some forensic work and I am
> trying to integrate sorter with the NIST NSRL 2.0 'known good' software
> hash. It appears that the current NSRL format is not yet supported;
> However, I noticed a stub in nsrl.c for VER2. Before I reinvent the wheel
> has anyone a patch to support the new format?
> 
> Thanks,
> Mike
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> sleuthkit-users mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users

[sleuthkit-users] NSRL 2.0

[<Mik...@da...>]

Hi all. I've just installed TASK/AUTOPSY for some forensic work and I am
trying to integrate sorter with the NIST NSRL 2.0 'known good' software
hash. It appears that the current NSRL format is not yet supported;
However, I noticed a stub in nsrl.c for VER2. Before I reinvent the wheel
has anyone a patch to support the new format?

Thanks,
Mike

Re: [sleuthkit-users] fls core

[Josep M H. <jm...@me...>]

Brian Carrier wrote:
> On Tue, Mar 25, 2003 at 05:15:38PM +0100, Josep M Homs wrote:
> 
>>>Also, can you run:
>>>
>>>	# fls -f solaris -la -z CET -s 1 path/c0t0d0s0-root.dd
>>>
>>>Does it core?
>>
>>Yes , it does.
> 
> 
> Strange.  Can you try it with out the '-l' and without the '-a' to  
> figure out which flags are causing the core (since it does not always
> crash).  Can you also run the a version that crashes with the '-v' flag
> to get some more details about where it is crashing?  

The problematic flag seems to be "-l" , with only "-a" dont crash.
I paste the last lines with "-v" :

fs_read_block: read block 56 offs 57344 len 8192 (inode block)
fs_read_block: read block 24 offs 24576 len 8192 (cylinder block)
-/r 214:        .bash_history   2003.03.16 22:19:19 (CET) 
2003.03.16 22:19:19 (CET)       2003.03.16 22:19:19 (CET)       3 
1       0
Segmentation fault (core dumped)
blackbox:/usr/local/bin/task/bin#

> 
> What platform are you running this on?  


FreeBSD 4.8-RC #0: Mon Mar 24 19:52:47 CET 2003


> 
> Or, you can attach it to gdb and get some runtime details:
> 
> 1.  run 'gdb ./fls' from the bin directory
> 2.  type 'set args -f solaris -la -z CET -s 1 path/c0t0d0s0-root.dd'
> 3.  type 'run'
> 4.  When it cores, type 'bt' to get the stack trace and send that output.
> 


OK , so portinstall gdb ;-)
I have to leave now ... i'll send you the output in some hours.


> Thanks!
> 

thanks to you ,
Josep M Homs

> brian
> 

Re: [sleuthkit-users] fls core

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

On Tue, Mar 25, 2003 at 05:15:38PM +0100, Josep M Homs wrote:
> >Also, can you run:
> >
> >	# fls -f solaris -la -z CET -s 1 path/c0t0d0s0-root.dd
> >
> >Does it core?
> 
> Yes , it does.

Strange.  Can you try it with out the '-l' and without the '-a' to  
figure out which flags are causing the core (since it does not always
crash).  Can you also run the a version that crashes with the '-v' flag
to get some more details about where it is crashing?  

What platform are you running this on?  

Or, you can attach it to gdb and get some runtime details:

1.  run 'gdb ./fls' from the bin directory
2.  type 'set args -f solaris -la -z CET -s 1 path/c0t0d0s0-root.dd'
3.  type 'run'
4.  When it cores, type 'bt' to get the stack trace and send that output.

Thanks!

brian