sleuthkit-users

[sleuthkit-users] Digital Intelligence Ultra Blockers under Linux(Fedora?)

[J B <je...@ad...>]

I'm having trouble finding my ultrablock under Fedora 4. I think this =
started when I "yum update"ed everything.  I was able to dd from it =
before, then I found the problem with 'fsstat' and updated hoping it =
would fix it.  Brian fixed it for me, but now I think my update caused =
problems with reading the ultrablock.


 If I restart, I can insert my flash drive and it works.  When I power =
on the UltraBlock(usb mass storage) dmesg says



SELinux: initialized (dev sdb1, type vfat), uses genfs_contexts
usb 2-1: new full speed USB device using ohci_hcd and address 2
scsi1 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
  Vendor: QUANTUM   Model: FIREBALLlct20 20  Rev: APL.
  Type:   Direct-Access                      ANSI SCSI revision: 04
SCSI device sdc: 39876480 512-byte hdwr sectors (20417 MB)
sdc: assuming drive cache: write through
SCSI device sdc: 39876480 512-byte hdwr sectors (20417 MB)
sdc: assuming drive cache: write through
 sdc: sdc1 sdc2
Attached scsi disk sdc at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg2 at scsi1, channel 0, id 0, lun 0,  type 0
usb 2-1: reset full speed USB device using ohci_hcd and address 2
usb 2-1: device descriptor read/64, error -110
usb 2-1: device descriptor read/64, error -110
usb 2-1: reset full speed USB device using ohci_hcd and address 2
usb 2-1: device descriptor read/64, error -110
usb 2-1: device descriptor read/64, error -110
usb 2-1: reset full speed USB device using ohci_hcd and address 2
usb 2-1: device descriptor read/8, error -110
usb 2-1: device descriptor read/8, error -110
usb 2-1: reset full speed USB device using ohci_hcd and address 2
usb 2-1: device descriptor read/8, error -110
usb 2-1: device descriptor read/8, error -110
usb 2-1: USB disconnect, address 2
scsi: Device offlined - not ready after error recovery: host 1 channel 0 =
id 0 lun 0
scsi1 (0:0): rejecting I/O to offline device
scsi1 (0:0): rejecting I/O to offline device
scsi1 (0:0): rejecting I/O to offline device
sd 1:0:0:0: SCSI error: return code =3D 0x10000
end_request: I/O error, dev sdc, sector 0
Buffer I/O error on device sdc, logical block 0
scsi1 (0:0): rejecting I/O to offline device
Buffer I/O error on device sdc, logical block 1
Buffer I/O error on device sdc, logical block 2
Buffer I/O error on device sdc, logical block 3
Buffer I/O error on device sdc, logical block 4
Buffer I/O error on device sdc, logical block 5
Buffer I/O error on device sdc, logical block 6
Buffer I/O error on device sdc, logical block 7
scsi1 (0:0): rejecting I/O to offline device
Buffer I/O error on device sdc, logical block 0

any ideas?  What distro gives the rest of you the least problems?  =
Fedora hasn't been good news for me.

Thanks
-Jessop

Re: [sleuthkit-users] Digital Intelligence Ultra Blockers under Linux(Fedora?)

[farmer d. <far...@ya...>]

Hello Jessop,

If you budget allows, then hands-down SMART Linux
(www.asrdata2.com).  Everything has done for you. 
Forensically designed and optimized.  Slackware Linux
makes a great platform as it is very clean, lean, and
uses vanilla kernel from www.kernel.org.

I never recommend RH/FC for Data Forensics work.

regards,

farmerdude



--- J B <je...@ad...> wrote:

> I'm having trouble finding my ultrablock under
> Fedora 4. I think this started when I "yum update"ed
> everything.  I was able to dd from it before, then I
> found the problem with 'fsstat' and updated hoping
> it would fix it.  Brian fixed it for me, but now I
> think my update caused problems with reading the
> ultrablock.
> 
> 
>  If I restart, I can insert my flash drive and it
> works.  When I power on the UltraBlock(usb mass
> storage) dmesg says
> 
> 
> 
> SELinux: initialized (dev sdb1, type vfat), uses
> genfs_contexts
> usb 2-1: new full speed USB device using ohci_hcd
> and address 2
> scsi1 : SCSI emulation for USB Mass Storage devices
> usb-storage: device found at 2
> usb-storage: waiting for device to settle before
> scanning
>   Vendor: QUANTUM   Model: FIREBALLlct20 20  Rev:
> APL.
>   Type:   Direct-Access                      ANSI
> SCSI revision: 04
> SCSI device sdc: 39876480 512-byte hdwr sectors
> (20417 MB)
> sdc: assuming drive cache: write through
> SCSI device sdc: 39876480 512-byte hdwr sectors
> (20417 MB)
> sdc: assuming drive cache: write through
>  sdc: sdc1 sdc2
> Attached scsi disk sdc at scsi1, channel 0, id 0,
> lun 0
> Attached scsi generic sg2 at scsi1, channel 0, id 0,
> lun 0,  type 0
> usb 2-1: reset full speed USB device using ohci_hcd
> and address 2
> usb 2-1: device descriptor read/64, error -110
> usb 2-1: device descriptor read/64, error -110
> usb 2-1: reset full speed USB device using ohci_hcd
> and address 2
> usb 2-1: device descriptor read/64, error -110
> usb 2-1: device descriptor read/64, error -110
> usb 2-1: reset full speed USB device using ohci_hcd
> and address 2
> usb 2-1: device descriptor read/8, error -110
> usb 2-1: device descriptor read/8, error -110
> usb 2-1: reset full speed USB device using ohci_hcd
> and address 2
> usb 2-1: device descriptor read/8, error -110
> usb 2-1: device descriptor read/8, error -110
> usb 2-1: USB disconnect, address 2
> scsi: Device offlined - not ready after error
> recovery: host 1 channel 0 id 0 lun 0
> scsi1 (0:0): rejecting I/O to offline device
> scsi1 (0:0): rejecting I/O to offline device
> scsi1 (0:0): rejecting I/O to offline device
> sd 1:0:0:0: SCSI error: return code = 0x10000
> end_request: I/O error, dev sdc, sector 0
> Buffer I/O error on device sdc, logical block 0
> scsi1 (0:0): rejecting I/O to offline device
> Buffer I/O error on device sdc, logical block 1
> Buffer I/O error on device sdc, logical block 2
> Buffer I/O error on device sdc, logical block 3
> Buffer I/O error on device sdc, logical block 4
> Buffer I/O error on device sdc, logical block 5
> Buffer I/O error on device sdc, logical block 6
> Buffer I/O error on device sdc, logical block 7
> scsi1 (0:0): rejecting I/O to offline device
> Buffer I/O error on device sdc, logical block 0
> 
> any ideas?  What distro gives the rest of you the
> least problems?  Fedora hasn't been good news for
> me.
> 
> Thanks
> -Jessop
> 


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

[sleuthkit-users] recombine raid images with loopback?

[J B <je...@ad...>]

Suppose you have a raid of 8 9GIG disks.
You have imaged each disk using dd so that you have diskimg0 ... diskimg7

What's the best way to mount this group of images in software so that you
can then operate on it using TSK?  I assume it involves mounting a loopback
device..

it's seems like you'd want to use /dev/loopX in raiddev per disk

but I'm not sure that:
mount -ro /evidence/diskimg0 /whocareswhere -t whatevertype -o 
loop=/dev/loop0, blocksize= (CHUNKSIZE?)
would be appropriate.  Seems like you're mounting the image unneccesarily 
leaving the mounted stub at /whocareswhere when all you really want is to 
tie loop0 to the image...

raiddev /dev/md0
        raid-level      linear
        nr-raid-disks   2
        chunk-size      32
        persistent-superblock 1
        device          /dev/loop0
        raid-disk       0
        device          /dev/loop1
        raid-disk       1


Just curious,

-Jessop

Re: [sleuthkit-users] recombine raid images with loopback?

[Dave G. <all...@ya...>]

Jessop,

The way you're describing your image operation
(imaging each disk individually) will likely not work.
 I've tried it in the wild and it just doesn't work
(unless you're prepared to manually piece together the
data, depending on the RAID config, BTW, I've tried
that too with varying levels of success...not fun).  I
haven't done much acquisition lately, but I believe
the best way to go about it is to boot the to be
imaged system with a Linux distro packaged for
acquisition, such as Helix or perhaps Farmerdude's CD.
 Essentially what's needed is an acquisition of the
RAID as a device, i.e., grabbing an image of the data
spanned across the drives in one image, 2nd i.e., as
if the RAID is just a big drive.  Obviously, speed of
success will be dependent on whether or not your
particular Linux boot CD distro has the a suitable
RAID driver and can 'see' the RAID.  You can force the
issue by manually adding a device and installing
drivers.  I've seen this done, but couldn't begin to
accurately describe the process in detail.  The bottom
line is a need to image the 'RAID', not the drives.  I
hope this can get you started.

Dave Gilbert

--- J B <je...@ad...> wrote:

> Suppose you have a raid of 8 9GIG disks.
> You have imaged each disk using dd so that you have
> diskimg0 ... diskimg7
> 
> What's the best way to mount this group of images in
> software so that you
> can then operate on it using TSK?  I assume it
> involves mounting a loopback
> device..
> 
> it's seems like you'd want to use /dev/loopX in
> raiddev per disk
> 
> but I'm not sure that:
> mount -ro /evidence/diskimg0 /whocareswhere -t
> whatevertype -o 
> loop=/dev/loop0, blocksize= (CHUNKSIZE?)
> would be appropriate.  Seems like you're mounting
> the image unneccesarily 
> leaving the mounted stub at /whocareswhere when all
> you really want is to 
> tie loop0 to the image...
> 
> raiddev /dev/md0
>         raid-level      linear
>         nr-raid-disks   2
>         chunk-size      32
>         persistent-superblock 1
>         device          /dev/loop0
>         raid-disk       0
>         device          /dev/loop1
>         raid-disk       1
> 
> 
> Just curious,
> 
> -Jessop
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 


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

Re: [sleuthkit-users] recombine raid images with loopback?

[farmer d. <far...@ya...>]

Jessop and Dave,

RAID acquisitions and analysis are a different beast
than stand alone systems.  Identifying, acquiring, and
analyzing RAIDs require a bit of knowledge, a bit of
skill, and a bit of space.  I've been quite successful
in identifying, acquiring, and analyzing RAID arrays
using Linux and associated components and programs. 
This is something covered in advanced training courses
in detail - either my own or ASR Data's.

I've used both the SMART Linux Boot CD and THE
FARMER'S BOOT CD for this.  SMART for Linux, the
program, has a nice graphical RAID Reconstructor
utility to assist those who don't know the RAID
schematics for the system they're looking to analyze. 


I would recommend acquiring every disk individually, a
physical image.  Acquiring only the RAID array may
leave a lot of data behind.  I would make certain
whatever tool you use to acquire doesn't activate the
RAID array.

While you're there, at the system, get ALL the
information you need before leaving.  RAID level,
stripe size, parity, etc.  THIS is the information you
will NEED to build your software RAID array.  Hardware
RAID systems typically include this in the tools
available at boot time.  Software RAID systems contain
this information in the RAID superblock.  I dissected
the superblock for my advanced training class and
found it to provide the needed information for
reconstruction later.  Note that this superblock has
grown from the 2.4 kernel to the 2.6 kernel.  

I don't know if this helps or not, but I hope it does.
 You can use Linux to acquire and analyze RAID arrays.
 Physical disk images are what you want.  If you use
mdadm you don't need a RAIDTAB file, and I would
strongly recommend *not* defining '/etc/raidtab'.

regards,

farmerdude



--- Dave Gilbert <all...@ya...> wrote:

> Jessop,
> 
> The way you're describing your image operation
> (imaging each disk individually) will likely not
> work.
>  I've tried it in the wild and it just doesn't work
> (unless you're prepared to manually piece together
> the
> data, depending on the RAID config, BTW, I've tried
> that too with varying levels of success...not fun). 
> I
> haven't done much acquisition lately, but I believe
> the best way to go about it is to boot the to be
> imaged system with a Linux distro packaged for
> acquisition, such as Helix or perhaps Farmerdude's
> CD.
>  Essentially what's needed is an acquisition of the
> RAID as a device, i.e., grabbing an image of the
> data
> spanned across the drives in one image, 2nd i.e., as
> if the RAID is just a big drive.  Obviously, speed
> of
> success will be dependent on whether or not your
> particular Linux boot CD distro has the a suitable
> RAID driver and can 'see' the RAID.  You can force
> the
> issue by manually adding a device and installing
> drivers.  I've seen this done, but couldn't begin to
> accurately describe the process in detail.  The
> bottom
> line is a need to image the 'RAID', not the drives. 
> I
> hope this can get you started.
> 
> Dave Gilbert
> 
> --- J B <je...@ad...> wrote:
> 
> > Suppose you have a raid of 8 9GIG disks.
> > You have imaged each disk using dd so that you
> have
> > diskimg0 ... diskimg7
> > 
> > What's the best way to mount this group of images
> in
> > software so that you
> > can then operate on it using TSK?  I assume it
> > involves mounting a loopback
> > device..
> > 
> > it's seems like you'd want to use /dev/loopX in
> > raiddev per disk
> > 
> > but I'm not sure that:
> > mount -ro /evidence/diskimg0 /whocareswhere -t
> > whatevertype -o 
> > loop=/dev/loop0, blocksize= (CHUNKSIZE?)
> > would be appropriate.  Seems like you're mounting
> > the image unneccesarily 
> > leaving the mounted stub at /whocareswhere when
> all
> > you really want is to 
> > tie loop0 to the image...
> > 
> > raiddev /dev/md0
> >         raid-level      linear
> >         nr-raid-disks   2
> >         chunk-size      32
> >         persistent-superblock 1
> >         device          /dev/loop0
> >         raid-disk       0
> >         device          /dev/loop1
> >         raid-disk       1
> > 
> > 
> > Just curious,
> > 
> > -Jessop

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

Re: [sleuthkit-users] recombine raid images with loopback?

[J B <je...@ad...>]

I like to imagine that you should be able to link a device file to an image 
file, and do what you want with it.  What happened to "everything in unix is 
a file!".

oh well - one day.

Re: [sleuthkit-users] recombine raid images with loopback?

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

I have tried to recreate RAIDs before using loopback and the RAID  
support in the Linux kernel (similar to your raiddev example), but I  
was unsuccessful.  I don't remember the details anymore because I'm  
in the middle of a move and all of my stuff is packed up.  But, it  
may work in newer versions of the kernel.

brian



On Jan 29, 2006, at 10:46 PM, J B wrote:

> Suppose you have a raid of 8 9GIG disks.
> You have imaged each disk using dd so that you have diskimg0 ...  
> diskimg7
>
> What's the best way to mount this group of images in software so  
> that you
> can then operate on it using TSK?  I assume it involves mounting a  
> loopback
> device..
>
> it's seems like you'd want to use /dev/loopX in raiddev per disk
>
> but I'm not sure that:
> mount -ro /evidence/diskimg0 /whocareswhere -t whatevertype -o  
> loop=/dev/loop0, blocksize= (CHUNKSIZE?)
> would be appropriate.  Seems like you're mounting the image  
> unneccesarily leaving the mounted stub at /whocareswhere when all  
> you really want is to tie loop0 to the image...
>
> raiddev /dev/md0
>        raid-level      linear
>        nr-raid-disks   2
>        chunk-size      32
>        persistent-superblock 1
>        device          /dev/loop0
>        raid-disk       0
>        device          /dev/loop1
>        raid-disk       1
>
>
> Just curious,
>
> -Jessop
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] recombine raid images with loopback?

[Aaron S. <aa...@se...>]

I've recombined Linux raids with varying degrees of success. It's
certainly one of the big reasons I use Linux's software raid -- most
hardware raids just don't give you even a glimmer of hope here.

An important detail is to use the appropriate options to stop the md
system from automatically resyncing your raid; if you get the options
wrong the first time and then it tries to resync, it's all over.

A lot of info out there is way out of date. Lots of work MD has taken
place in the 2.6 kernel. This page looks fairly recent:

http://software.cfht.hawaii.edu/linuxpc/RAID_recovery.html

Aaron

On Tue, 2006-01-31 at 12:49 -0500, Brian Carrier wrote:
> I have tried to recreate RAIDs before using loopback and the RAID  
> support in the Linux kernel (similar to your raiddev example), but I  
> was unsuccessful.  I don't remember the details anymore because I'm  
> in the middle of a move and all of my stuff is packed up.  But, it  
> may work in newer versions of the kernel.
> 
> brian
> 
> 
> 
> On Jan 29, 2006, at 10:46 PM, J B wrote:
> 
> > Suppose you have a raid of 8 9GIG disks.
> > You have imaged each disk using dd so that you have diskimg0 ...  
> > diskimg7
> >
> > What's the best way to mount this group of images in software so  
> > that you
> > can then operate on it using TSK?  I assume it involves mounting a  
> > loopback
> > device..
> >
> > it's seems like you'd want to use /dev/loopX in raiddev per disk
> >
> > but I'm not sure that:
> > mount -ro /evidence/diskimg0 /whocareswhere -t whatevertype -o  
> > loop=/dev/loop0, blocksize= (CHUNKSIZE?)
> > would be appropriate.  Seems like you're mounting the image  
> > unneccesarily leaving the mounted stub at /whocareswhere when all  
> > you really want is to tie loop0 to the image...
> >
> > raiddev /dev/md0
> >        raid-level      linear
> >        nr-raid-disks   2
> >        chunk-size      32
> >        persistent-superblock 1
> >        device          /dev/loop0
> >        raid-disk       0
> >        device          /dev/loop1
> >        raid-disk       1
> >
> >
> > Just curious,
> >
> > -Jessop
> >