sleuthkit-users

[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] 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

[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

[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

[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

[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] 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-developers] Re: [sleuthkit-users] Split Image Question

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

Not sure about others, but I believe on FreeBSD at least (and likely
other BSDs) there is a kernel level argument max as well...  Don't
know that it matters, but thought I'd share anyway :-)  If I had over
100 of any kind of media to reassemble for forensic work I might just
shoot myself instead, heh.

main% sysctl -a |grep argmax
kern.argmax: 65536
main%


On Tue, 1 Feb 2005 11:38:23 -0500, Brian Carrier <ca...@sl...> wrote:
> 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
> 
> -------------------------------------------------------
> 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-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

[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. :)
> 
> 
>