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

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

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-users] Split Image Question

[LERTI - D. B. <Dav...@le...>]

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

Hi Brian,

I'm mainly using AIR with dcfldd for creating the images. The splitted
images are suffixed with numbers. I'm using the splitted images for two
purposes:

1. I'm acquiring under Linux, and since the support for writing reliably to
NTFS is lacking, I have to write the image to FAT32, EXT2 or EXT3. The
problem is that I sometimes need to use several forensic softwares for a
same case and most of them are running only under Windows.
The drivers for EXT2 are correct but little more and EXT3 is not correctly
supported. Therefore, the common file system among all forensic softwares is
FAT32, with its limitation of 2Go per file.

2. I'm burning the splitted images to DVD for "safe" storage.

The method of acquiring via dcfldd calculates a MD5 for each chunk of data
and another for the whole image.

Concerning the interface with Autopsy, I liked the text file method
suggested by Surago. It can be an alternative to native globbing, which is
fine, too.

Take care,

David.

Brian Carrier wrote:
| As I was adding the new split image features to Autopsy, I realized that
| I do not fully  understand how people use split images.  Is their
| purpose so that you can acquire the image in 650MB or 2GB chunks for
| burning to disk and then import those images into TSK/Autopsy?
|
| My issue is about the Autopsy interface.  Splitting a 60 GB disk into
| 650 MB chunks requires almost 100 chunks and I do not want to have 200
| field boxes where you fill in each file (and I'm assuming that you do
| not want to fill in 200 file names for a 120 GB disk). On the other
| hand, I do not want to require a naming convention where the extension
| is numbered based on its order in the full image (TSK v2 requires you to
| enter the file names of the split images in their respective order)
| because different tools may have different conventions.
|
| So, my question for those who have asked for split image support is what
| should the interface be?  What is a typical number of chunks that may
| occur?   Are there occasions when you need to use split images and
| cannot merge them into one for the analysis (using FAT32 seems to be
| such a case)?  What extensions do you typically have for the split
| images?  Do you typically have the MD5 for the full image or for each
| individual partition?  Anyone who has asked for split image support ...
| please speak up :)
|
| thanks,
| brian
|
|
|
| -------------------------------------------------------
| This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
| Tool for open source databases. Create drag-&-drop reports. Save time
| by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
| Download a FREE copy at http://www.intelliview.com/go/osdn_nl
| _______________________________________________
| sleuthkit-users mailing list
| https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
| http://www.sleuthkit.org
|
|

- --
LERTI - Laboratoire d'Expertise et de
Recherche de Traces Informatiques
http://www.lerti.fr |  mobile : +41 79 746 7305
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/0Rfv6mUNUu+e+URAmcdAKCMFVZC7otQsYdZV6qLdx2duFZmygCff2Pz
oBSOtfBIMBnA9ELrQI/Z5R0=
=2H5B
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] Split Image Question

[Paul B. <p.j...@br...>]

I agree that this is the most common...

Al my split files are either done with split or by using a (currently)
proprietary tool to image a disk under *NIX'es... The last one uses
numerical extensions to number them and so native globbing would do
fine.

Paul Bakker

On Tue, Feb 01, 2005 at 06:55:49PM +1100, David Collett wrote:
> I think that native globbing is fine. Every form of splitting I've
> seen has used alphanumeric ordering so I think this is a perfectly
> reasonable option. The suggestion of showing the user what the order
> will be for confirmation is even better. But I'd say you could not
> bother with an interface to change the order. Rather, if the
> investigator sees that the order is wrong, they can rename the damn
> files and try again ! :)
> 
> Dave
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Split Image Question

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

I think that native globbing is fine. Every form of splitting I've
seen has used alphanumeric ordering so I think this is a perfectly
reasonable option. The suggestion of showing the user what the order
will be for confirmation is even better. But I'd say you could not
bother with an interface to change the order. Rather, if the
investigator sees that the order is wrong, they can rename the damn
files and try again ! :)

Dave

Re: [sleuthkit-users] Split Image Question

[Linux T. <lin...@ya...>]

You should have user specify order.  If you do not you
end up trying to guess, and if guess wrong, user
blames you.  Therefor I think only safe solution is to
have user point to a directory containing all images
in a sequential numbering or manually add in order
they need to (would be long, but so what, it'd be
accurate, and that is only important).

-lt

--- Brian Carrier <ca...@sl...> wrote:

> As I was adding the new split image features to
> Autopsy, I realized 
> that I do not fully  understand how people use split
> images.  Is their 
> purpose so that you can acquire the image in 650MB
> or 2GB chunks for 
> burning to disk and then import those images into
> TSK/Autopsy?
> 
> My issue is about the Autopsy interface.  Splitting
> a 60 GB disk into 
> 650 MB chunks requires almost 100 chunks and I do
> not want to have 200 
> field boxes where you fill in each file (and I'm
> assuming that you do 
> not want to fill in 200 file names for a 120 GB
> disk). On the other 
> hand, I do not want to require a naming convention
> where the extension 
> is numbered based on its order in the full image
> (TSK v2 requires you 
> to enter the file names of the split images in their
> respective order) 
> because different tools may have different
> conventions.
> 
> So, my question for those who have asked for split
> image support is 
> what should the interface be?  What is a typical
> number of chunks that 
> may occur?   Are there occasions when you need to
> use split images and 
> cannot merge them into one for the analysis (using
> FAT32 seems to be 
> such a case)?  What extensions do you typically have
> for the split 
> images?  Do you typically have the MD5 for the full
> image or for each 
> individual partition?  Anyone who has asked for
> split image support ... 
> please speak up :)
> 
> thanks,
> brian
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW --
> Interactive Reporting
> Tool for open source databases. Create drag-&-drop
> reports. Save time
> by over 75%! Publish reports on the web. Export to
> DOC, XLS, RTF, etc.
> Download a FREE copy at
> http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

RE: [sleuthkit-users] Split Image Question

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

(Meant to send this to the whole group before, doh.)

Hi Brian,

Whilst I haven't required the support of split images yet, I have had to
configure a host with numerous mount points (images), and whilst I was
setting these up I was thinking that it would be significantly quicker
if one could import the details in a text file of some type. =20

In my situation I previously had a text file with the full path names to
the image files, along with the MD5 hash's, so it would be been an
extremely quick step to configure the host if I was able to import the
details from a text file.  With this method it would be rather simple to
import details for split images (And also avoid the need to have
numerous input boxes)

A second option, I'm not sure if it would be possible to implement
easily with the HTML interface in autopsy, would be to include a Browse
button so one could point to the image files rather than having to type
the full path and filename in.  However I have a funny suspicion this
may not be easily implemented whilst keeping the interface compatible
among different browsers.

Cheers

Surago.

-----Original Message-----
From: sle...@li...
[mailto:sle...@li...] On Behalf Of Brian
Carrier
Sent: Tuesday, 1 February 2005 12:27 p.m.
To: 'sle...@li...'
<sle...@li...>
Subject: [sleuthkit-users] Split Image Question

As I was adding the new split image features to Autopsy, I realized that
I do not fully  understand how people use split images.  Is their
purpose so that you can acquire the image in 650MB or 2GB chunks for
burning to disk and then import those images into TSK/Autopsy?




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time by
over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: [sleuthkit-users] Split Image Question

[Aaron P. <dop...@gm...>]

I think using the native globbing support is an excellent idea.  

As a possible example of the interface, you could start the interface
with a field for entering the directory your image pieces reside in. 
Fill in and Submit.  Next page shows all files in that directory with
check boxes beside each one.  Options are to check or uncheck boxes,
or to use some form of regex to filter and check all files that fit
the filter.  It could be your choice whether you use PCRE or globbing
or whatever.  It really doesn't matter to me.  PCRE is probably more
flexible... Anyway, say you use a filter.  Fill in and click "filter".
 so now on the next page, everything that fits "myimage.*" has it's
check box selected.  But say you picked up some files that weren't
part of the image, so you deselect them.  click "done" and it rebuilds
the image or whatever you have designed for it to do with the pieces
parts.  If you really wanted to, you could have links to move a file
up or down in the order or numbered fields that one could change to
quickly move a file from 39 in the order to 13, but I can't imagine
why anyone would not just have image parts in order...

That's my two cents anyway.

[sleuthkit-users] Split Image Question

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

As I was adding the new split image features to Autopsy, I realized 
that I do not fully  understand how people use split images.  Is their 
purpose so that you can acquire the image in 650MB or 2GB chunks for 
burning to disk and then import those images into TSK/Autopsy?

My issue is about the Autopsy interface.  Splitting a 60 GB disk into 
650 MB chunks requires almost 100 chunks and I do not want to have 200 
field boxes where you fill in each file (and I'm assuming that you do 
not want to fill in 200 file names for a 120 GB disk). On the other 
hand, I do not want to require a naming convention where the extension 
is numbered based on its order in the full image (TSK v2 requires you 
to enter the file names of the split images in their respective order) 
because different tools may have different conventions.

So, my question for those who have asked for split image support is 
what should the interface be?  What is a typical number of chunks that 
may occur?   Are there occasions when you need to use split images and 
cannot merge them into one for the analysis (using FAT32 seems to be 
such a case)?  What extensions do you typically have for the split 
images?  Do you typically have the MD5 for the full image or for each 
individual partition?  Anyone who has asked for split image support ... 
please speak up :)

thanks,
brian

Re: [sleuthkit-users] FileSystem Too Large

[Dott. D. E. C. <do...@vo...>]

It works,

thank a lot.


Donato Caccavella

Il giorno mer, 26-01-2005 alle 19:06 +0100, Brian Carrier ha scritto:
> On Jan 26, 2005, at 12:01 PM, Dott. D.E. Caccavella wrote:
> 
> > Hi to everybody,
> >
> > I have acquired with dd a filesystem FAT32 of 160 GBs, but  analyzing 
> > it
> > with Autopsy, and with the  sleuthkit tools, I have the message error 
> > : "..
> > File Sytem too large.. "
> >
> >
> > what can I do?
> 
> You can wait until version 2 is released (in a few weeks hopefully).... 
>    This is a side effect of the metadata addresses that TSK assigns to 
> FAT directory entries (since FAT does not normally assign addresses to 
> them). They are limited to the INUM_T size on your computer, which is 
> typically 32-bits.  You can try to comment out the size check and see 
> if you run into problems, but be careful.  The check is on line 1877 
> and 1878 of src/fstools/fatfs.c.  Just start each line with '//' and 
> recompile.  It will work on systems that assign the inum_t size to be 
> 64-bits.
> 
> brian
> 
> 

Re: [sleuthkit-users] FileSystem Too Large

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

On Jan 26, 2005, at 12:01 PM, Dott. D.E. Caccavella wrote:

> Hi to everybody,
>
> I have acquired with dd a filesystem FAT32 of 160 GBs, but  analyzing 
> it
> with Autopsy, and with the  sleuthkit tools, I have the message error 
> : "..
> File Sytem too large.. "
>
>
> what can I do?

You can wait until version 2 is released (in a few weeks hopefully).... 
   This is a side effect of the metadata addresses that TSK assigns to 
FAT directory entries (since FAT does not normally assign addresses to 
them). They are limited to the INUM_T size on your computer, which is 
typically 32-bits.  You can try to comment out the size check and see 
if you run into problems, but be careful.  The check is on line 1877 
and 1878 of src/fstools/fatfs.c.  Just start each line with '//' and 
recompile.  It will work on systems that assign the inum_t size to be 
64-bits.

brian

[sleuthkit-users] FileSystem Too Large

[Dott. D.E. C. <do...@vo...>]

Hi to everybody,

I have acquired with dd a filesystem FAT32 of 160 GBs, but  analyzing it
with Autopsy, and with the  sleuthkit tools, I have the message error : "..
File Sytem too large.. "


what can I do?


Thanks for the attention



Donato Caccavella

Re: [sleuthkit-users] previous filesystems

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

You will need to use tools like foremost for that purpose.

brian

On Jan 24, 2005, at 9:26 PM, Aaron Peterson wrote:

> The sluethkit tools are only applicable to the current filesystem,
> correct?  For instance, I can't tell the tools to survey the raw drive
> for files that still exist that were probably part of a previous
> filesystem that has since been overwritten?
>
> Aaron
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

[sleuthkit-users] previous filesystems

[Aaron P. <dop...@gm...>]

The sluethkit tools are only applicable to the current filesystem,
correct?  For instance, I can't tell the tools to survey the raw drive
for files that still exist that were probably part of a previous
filesystem that has since been overwritten?

Aaron

Re: [sleuthkit-users] Autopsy/sleuthkit support for ISO9660 filesystems

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

On Jan 21, 2005, at 2:17 PM, <sec...@hu...> wrote:

> Can I examine cd CDROM formatted with the ISO9660 filesystem with
> the Sleuthkit tools and/or Autopsy? I am not seeing where it is
> supported nor documented that it isn't supported.

It is not supported.

brian

Re: [sleuthkit-users] Autopsy/sleuthkit support for ISO9660 filesystems

[Matthew M S. <mm...@ta...>]

There are many ways to accomplish this, for more information see my
article on Linux forensics of CDR media.

http://www.agilerm.net/publications_3.html

Let me know if you still have questions.

-- 
Matthew M. Shannon, CIFI, CISSP
Principal 
Agile Risk Management LLC
www.agilerm.net
msh...@ag...
(c)813.732.5076
(o)1.877.AGILE13 (244.5313)


On Fri, 2005-01-21 at 14:17, sec...@hu... wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Can I examine cd CDROM formatted with the ISO9660 filesystem with
> the Sleuthkit tools and/or Autopsy? I am not seeing where it is
> supported nor documented that it isn't supported.
> 
> Also, does anyone know how I can examing CDRW disks that are
> formatted with the drag-and-drop style of open session?
> 
> Thanks,
> 
> SH
> -----BEGIN PGP SIGNATURE-----
> Note: This signature can be verified at https://www.hushtools.com/verify
> Version: Hush 2.4
> 
> wkYEARECAAYFAkHxVVoACgkQRBFe1uc9INqnIACgr8K9WbgTNPkMG2l4KADn6RZWFQ8A
> n1aslCSl7Yjf3kS6YUkwt0rzRACd
> =9Av/
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] Autopsy/sleuthkit support for ISO9660 filesystems

[<sec...@hu...>]

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

Can I examine cd CDROM formatted with the ISO9660 filesystem with
the Sleuthkit tools and/or Autopsy? I am not seeing where it is
supported nor documented that it isn't supported.

Also, does anyone know how I can examing CDRW disks that are
formatted with the drag-and-drop style of open session?

Thanks,

SH
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkHxVVoACgkQRBFe1uc9INqnIACgr8K9WbgTNPkMG2l4KADn6RZWFQ8A
n1aslCSl7Yjf3kS6YUkwt0rzRACd
=9Av/
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] Placement of Locker???

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

On Jan 19, 2005, at 7:38 PM, Linux Tard wrote:

> --- Rich Thompson <te...@ap...> wrote:
>>  But, how would I move the locker in
>> autopsy, without re-installing to specify a
>> different
>> locker location.
>>
>
> Rich - find your 'conf.pl' (Autopsy directory) file
> and edit it to new locker location.  That should work.
>  I dindt test but it looks like that solve it.  I only
> wonder if it hard coded elsewhere in autopsy/sleuth?

The conf.pl file is the only place that it is stored (in fact it is the 
only config file for Autopsy).  Alternatively, you can start autopsy 
with '-d' to specify a different locker directory.

brian

Re: [sleuthkit-users] Placement of Locker???

[Linux T. <lin...@ya...>]

--- Rich Thompson <te...@ap...> wrote:
>  But, how would I move the locker in
> autopsy, without re-installing to specify a
> different
> locker location.
> 

Rich - find your 'conf.pl' (Autopsy directory) file
and edit it to new locker location.  That should work.
 I dindt test but it looks like that solve it.  I only
wonder if it hard coded elsewhere in autopsy/sleuth?

-lt


		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

Re: [sleuthkit-users] RE: sleuthkit-users digest, Vol 1 #240 - 8 msgs

[Steve G. <st...@un...>]

FYI, Grab is based on a program I wrote called AIR (Automated Image & Restore) http://air-imager.sourceforge.net.  If you didn't want to boot into Helix just to run Grab you could install AIR on your forensic workstation.

-Steve
--
Steve Gibson
st...@un...

-------------------
In response to:

John Edwards would probably find some value in using the GRAB program.
Check out the current HELIX bootable Linux disk. 
It makes the process of "grabbing" a partition very easy.  
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________ sleuthkit-users mailing list https://lists.sourceforge.net/lists/listinfo/sleuthkit-users http://www.sleuthkit.org

[sleuthkit-users] Placement of Locker???

[Rich T. <te...@ap...>]

Quick question...

Is there a way to palce the locker on the target
drive?   So if I image to /dev/sda1 and make folders
for image and locker, then all the stuff would be on
one drive. But, how would I move the locker in
autopsy, without re-installing to specify a different
locker location.

Or am I WAAAAAYYYYYYY off on this one...

TIA,
Rich Thompson 

Re: [sleuthkit-users] RE: sleuthkit-users digest, Vol 1 #240 - 8 msgs

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

On Wed, Jan 19, 2005 at 05:28:54PM -0500, SecMan wrote:
> John Edwards would probably find some value in using the GRAB program.
> Check out the current HELIX bootable Linux disk.=20
> It makes the process of "grabbing" a partition very easy. =20

I didn't get the impression that John wanted the tool for himself, as
much as a suggestion of how to make the process easier for first-time
users (or people who just like to cut and paste commands :).

A quick little: "dd may be used to dump the data from the disk with a
very easy command: dd if=3D/dev/sda1 of=3D~/drive_image bs=3D8192 -- be sure
to replace the /dev/sda1 with the proper device node for your drive and
partition desired [see <foo> for details] and ~/drive_image with a
suitable filename for the image" would go a _long_ way to making it
easier for users completely unfamiliar with dd. (I spent years mystified
by dd; now, if I were only allowed one shell tool on a desert island,
I'd probably take dd with me. :)

[sleuthkit-users] RE: sleuthkit-users digest, Vol 1 #240 - 8 msgs

[SecMan <se...@ta...>]

John Edwards would probably find some value in using the GRAB program.
Check out the current HELIX bootable Linux disk. 
It makes the process of "grabbing" a partition very easy.  

[sleuthkit-users] timelines of windows registry

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

In the past I used dumpreg to get a copy of the registry
with timestamps, but dumpreg has problems with Unicode
and subset of registry hives, etc.

Now I'm generating Registry timelines on windows with
total commander and a registry-plugin. The following
steps are necessary:

- Importing files with Regedit on WinXP,
  (Here is one big problem, the ACLs of the imported
   SAM- and SECURITY-HIVEs need to be changed,
   so the timestamps of SAM, SECURITY, SECURITY\Cache,
   SECURITY\Policy and SECURITY\RXACT will be overwritten)

- Total Commander with Registry Plugin for exporting
  the registry-keys with timestamps
  http://www.ghisler.com/ and
  http://www.totalcmd.net/plugring/registry.html

- the plugin exports the hives' timestamps to a TXT
  file. (all keys and most of the values are exported
  as ASCII or UNICODE)

- grep and sort are taking care of the rest 

The described method - via Windows, Admin-Rights,
Registry-Editor, Total-Commander, and the
Registry-Plugin - is not very straightforward for
forensic purposes.

Does anyone know good tools for generating
timelines of the windows registry?

Are there any existing read-only and open-source
windows-registry-timeline tools?

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 beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl

Re: [sleuthkit-users] Athlon64 exam machine Q????

[Paul S. <pa...@vn...>]

I am running on an AMD64 3200+ with SuSE 9.2.  Everything is working fine=20
here.=20

Paul

On Tuesday 18 January 2005 14:52, Brian Carrier wrote:
> TSK 1.73 fixed the 64-bit Linux compatibility issues, so you should be
> all set.
>
> The odd sector Linux issue was fixed in 2.6.
>
> brian
>
> On Jan 18, 2005, at 10:51 AM, Rich Thompson wrote:
> > Howdy folks,
> >
> > Quick question.  Would there be any issues, or
> > drawbacks to imaging and examning a WinXP drive on an
> > Athlon64 examination machine???  Just built a new
> > machine, and was thinking about playing with the
> > Sluethkit and Autopsy on it.
> >
> > The OS is Suse 9.2.
> >
> > Any odd settings regarding the odd sector issue, or
> > was that fixed with the 2.6 kernel???
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org