Thread: [sleuthkit-users] XFS image file analysis
Brought to you by:
carrier
From: Sagar B. <sag...@gm...> - 2012-12-04 02:42:50
|
Hi all, I'm new here. I recently started using sleuthkit/autopsy for the analysis of Window XP NTFS/FAT32 hard disk image files. Sleuthkit/autopsy works pretty decent even with ext fs. But, I was wondering, what would I need to do to load an XFS image file? Apologize for being naive about it. Please shade some light. Thanks, Sagar Belure |
From: Derrick K. <dk...@gm...> - 2012-12-04 05:08:57
|
Hello. Neither Sleuth Kit nor Autopsy support XFS currently. If you are looking to interpret XFS you may want to look at the standard linux xfsprogs. On the proprietary tool side I believe the only one that supports it is X-Ways. Derrick On Mon, Dec 3, 2012 at 7:42 PM, Sagar Belure <sag...@gm...> wrote: > Hi all, > > I'm new here. I recently started using sleuthkit/autopsy for the analysis of > Window XP NTFS/FAT32 hard disk image files. > Sleuthkit/autopsy works pretty decent even with ext fs. But, I was > wondering, what would I need to do to load an XFS image file? > > Apologize for being naive about it. > > Please shade some light. > > Thanks, > Sagar Belure > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
From: Sagar B. <sag...@gm...> - 2012-12-04 07:17:27
|
Hi Derrick, Thank you for so quick response. Also, is there any way I can mount the image file using xfsprogs? Thanks, Sagar Belure On Tue, Dec 4, 2012 at 10:38 AM, Derrick Karpo <dk...@gm...> wrote: > Hello. > > Neither Sleuth Kit nor Autopsy support XFS currently. If you are > looking to interpret XFS you may want to look at the standard linux > xfsprogs. On the proprietary tool side I believe the only one that > supports it is X-Ways. > > Derrick > > > On Mon, Dec 3, 2012 at 7:42 PM, Sagar Belure <sag...@gm...> > wrote: > > Hi all, > > > > I'm new here. I recently started using sleuthkit/autopsy for the > analysis of > > Window XP NTFS/FAT32 hard disk image files. > > Sleuthkit/autopsy works pretty decent even with ext fs. But, I was > > wondering, what would I need to do to load an XFS image file? > > > > Apologize for being naive about it. > > > > Please shade some light. > > > > Thanks, > > Sagar Belure > > > > > > > ------------------------------------------------------------------------------ > > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > > Remotely access PCs and mobile devices and provide instant support > > Improve your efficiency, and focus on delivering more value-add services > > Discover what IT Professionals Know. Rescue delivers > > http://p.sf.net/sfu/logmein_12329d2d > > _______________________________________________ > > sleuthkit-users mailing list > > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > > http://www.sleuthkit.org > > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
From: Derrick K. <dk...@gm...> - 2012-12-04 22:42:42
|
Hello. You can mount the image using 'mount -t xfs -o ro,loop ....' while specifying the appropriate offset (if required) for the XFS filesystem. It's really no different than mounting and examining any other filesystem which your native tools (Sleuth Kit in this case) don't support. Just note that you are only looking at the fs logically but once it is mounted you can run some of the Sleuth Kit tools against the mounted location to gather timeline data etc. You should read up on the various 'xfs_*' tools which are included with xfsprogs as ones such as 'xfs_ncheck' may be useful to you. Derrick On Tue, Dec 4, 2012 at 12:16 AM, Sagar Belure <sag...@gm...> wrote: > Hi Derrick, > > Thank you for so quick response. > Also, is there any way I can mount the image file using xfsprogs? > > Thanks, > Sagar Belure > > > > > On Tue, Dec 4, 2012 at 10:38 AM, Derrick Karpo <dk...@gm...> wrote: >> >> Hello. >> >> Neither Sleuth Kit nor Autopsy support XFS currently. If you are >> looking to interpret XFS you may want to look at the standard linux >> xfsprogs. On the proprietary tool side I believe the only one that >> supports it is X-Ways. >> >> Derrick >> >> >> On Mon, Dec 3, 2012 at 7:42 PM, Sagar Belure <sag...@gm...> >> wrote: >> > Hi all, >> > >> > I'm new here. I recently started using sleuthkit/autopsy for the >> > analysis of >> > Window XP NTFS/FAT32 hard disk image files. >> > Sleuthkit/autopsy works pretty decent even with ext fs. But, I was >> > wondering, what would I need to do to load an XFS image file? >> > >> > Apologize for being naive about it. >> > >> > Please shade some light. >> > >> > Thanks, >> > Sagar Belure >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> > Remotely access PCs and mobile devices and provide instant support >> > Improve your efficiency, and focus on delivering more value-add services >> > Discover what IT Professionals Know. Rescue delivers >> > http://p.sf.net/sfu/logmein_12329d2d >> > _______________________________________________ >> > sleuthkit-users mailing list >> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >> > http://www.sleuthkit.org >> > >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> sleuthkit-users mailing list >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >> http://www.sleuthkit.org > > |
From: Sagar B. <sag...@gm...> - 2012-12-05 04:37:15
|
Hi Derrick, Yes. But that would require <device> as a parameter not image file. I don't have hard disk but hard disk image. I'm not really sure how do operate on XFS filesystem image file. Thanks, Sagar Belure On Wed, Dec 5, 2012 at 4:12 AM, Derrick Karpo <dk...@gm...> wrote: > Hello. > > You can mount the image using 'mount -t xfs -o ro,loop ....' while > specifying the appropriate offset (if required) for the XFS > filesystem. It's really no different than mounting and examining any > other filesystem which your native tools (Sleuth Kit in this case) > don't support. Just note that you are only looking at the fs > logically but once it is mounted you can run some of the Sleuth Kit > tools against the mounted location to gather timeline data etc. You > should read up on the various 'xfs_*' tools which are included with > xfsprogs as ones such as 'xfs_ncheck' may be useful to you. > > Derrick > > > On Tue, Dec 4, 2012 at 12:16 AM, Sagar Belure <sag...@gm...> > wrote: > > Hi Derrick, > > > > Thank you for so quick response. > > Also, is there any way I can mount the image file using xfsprogs? > > > > Thanks, > > Sagar Belure > > > > > > > > > > On Tue, Dec 4, 2012 at 10:38 AM, Derrick Karpo <dk...@gm...> wrote: > >> > >> Hello. > >> > >> Neither Sleuth Kit nor Autopsy support XFS currently. If you are > >> looking to interpret XFS you may want to look at the standard linux > >> xfsprogs. On the proprietary tool side I believe the only one that > >> supports it is X-Ways. > >> > >> Derrick > >> > >> > >> On Mon, Dec 3, 2012 at 7:42 PM, Sagar Belure <sag...@gm...> > >> wrote: > >> > Hi all, > >> > > >> > I'm new here. I recently started using sleuthkit/autopsy for the > >> > analysis of > >> > Window XP NTFS/FAT32 hard disk image files. > >> > Sleuthkit/autopsy works pretty decent even with ext fs. But, I was > >> > wondering, what would I need to do to load an XFS image file? > >> > > >> > Apologize for being naive about it. > >> > > >> > Please shade some light. > >> > > >> > Thanks, > >> > Sagar Belure > >> > > >> > > >> > > >> > > ------------------------------------------------------------------------------ > >> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > >> > Remotely access PCs and mobile devices and provide instant support > >> > Improve your efficiency, and focus on delivering more value-add > services > >> > Discover what IT Professionals Know. Rescue delivers > >> > http://p.sf.net/sfu/logmein_12329d2d > >> > _______________________________________________ > >> > sleuthkit-users mailing list > >> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > >> > http://www.sleuthkit.org > >> > > >> > >> > >> > ------------------------------------------------------------------------------ > >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > >> Remotely access PCs and mobile devices and provide instant support > >> Improve your efficiency, and focus on delivering more value-add services > >> Discover what IT Professionals Know. Rescue delivers > >> http://p.sf.net/sfu/logmein_12329d2d > >> _______________________________________________ > >> sleuthkit-users mailing list > >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > >> http://www.sleuthkit.org > > > > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
From: RB <ao...@gm...> - 2012-12-05 04:51:23
|
On Tue, Dec 4, 2012 at 9:36 PM, Sagar Belure <sag...@gm...> wrote: > Yes. But that would require <device> as a parameter not image file. > I don't have hard disk but hard disk image. You can handle that either by using 'losetup' to set up a loopback block device at a specific offset in your image file, or use the '-o loop,offset=XYZ' option to 'mount', which does the same thing. Mounting an image "-o loop,offset=XYZ" just runs losetup in the background, and all losetup is doing in this case is creating a convenience mapping - you tell it that a block device you want to handle is at byte offset XYZ in the image and it will transparently translate all accesses to start at that address. > I'm not really sure how do operate on XFS filesystem image file. See above, unless you imaged the XFS filesystem with "xfsdump". |
From: Derrick K. <dk...@gm...> - 2012-12-05 05:14:19
|
Exactly! Without going too far off topic, here's a sample image with an XFS partition at byte offset 16065. You can use mmls to find the offset of the partition, crudely confirm that the partition is XFS using dd, then mount it with the appropriate offset. This should be enough to get you going. $ mmls /tmp/bleck.img DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000000062 0000000063 Unallocated 02: 00:00 0000000063 0000016064 0000016002 Linux (0x83) 03: 00:01 0000016065 0000079999 0000063935 Linux (0x83) $ dd if=/tmp/bleck.img skip=16065 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes (512 B) copied00000000 58 46 53 42 00 00 10 00 00 00 00 00 00 00 1f 37 |XFSB...........7| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 90 d9 91 d9 e7 e7 45 44 ba b1 f8 91 a3 2c e3 63 |......ED.....,.c| 00000030 00 00 00 00 00 00 00 04 00 00 00 00 00 00 4b 80 |..............K.| 00000040 00 00 00 00 00 00 4b 81 00 00 00 00 00 00 4b 82 |......K.......K.| 00000050 00 00 00 01 00 00 1f 37 00 00 00 01 00 00 00 00 |.......7........| 00000060 00 00 04 b0 b4 a4 02 00 01 00 00 10 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 0c 09 08 04 0d 00 00 19 |................| 00000080 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 3d |.......@.......=| 00000090 00 00 00 00 00 00 1a 7f 00 00 00 00 00 00 00 00 |................| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 01 00 00 00 0a 00 00 00 0a |................| 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 $ sudo mount -t xfs -o ro,loop,offset=$((16065*512)) /tmp/bleck.img /mnt $ ls /mnt this-is-a-test.txt RB's suggestion of using the loopback is also a good idea. You can setup a loopback device at the appropriate offset, then use the loopback device for further processing. $ sudo /sbin/losetup -o $((16065*512)) /dev/loop0 /tmp/bleck.img $ sudo xfs_ncheck /dev/loop0 19332 this-is-a-test.txt $ sudo mount /dev/loop0 /mnt $ ls /mnt this-is-a-test.txt Derrick On Tue, Dec 4, 2012 at 9:51 PM, RB <ao...@gm...> wrote: > On Tue, Dec 4, 2012 at 9:36 PM, Sagar Belure <sag...@gm...> wrote: >> Yes. But that would require <device> as a parameter not image file. >> I don't have hard disk but hard disk image. > > You can handle that either by using 'losetup' to set up a loopback > block device at a specific offset in your image file, or use the '-o > loop,offset=XYZ' option to 'mount', which does the same thing. > Mounting an image "-o loop,offset=XYZ" just runs losetup in the > background, and all losetup is doing in this case is creating a > convenience mapping - you tell it that a block device you want to > handle is at byte offset XYZ in the image and it will transparently > translate all accesses to start at that address. > >> I'm not really sure how do operate on XFS filesystem image file. > > See above, unless you imaged the XFS filesystem with "xfsdump". |
From: Sagar B. <sag...@gm...> - 2012-12-05 06:10:06
|
Hi Derrick/RB, Nice. Thank you so much for taking time and replying in so details. Really appreciate it. And I think, I didn't explain it fully in the beginning. Apologize for that. This is a RAID image, and I don't have fully understanding of it fully. Well here is the output for the commands by Derrick: $ mmls /home/forensic/forensic-images/xfs-1tb.img DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000000062 0000000063 Unallocated 02: 00:00 0000000063 1953520064 1953520002 Linux RAID (0xFD) $ dd if=/home/forensic/forensic-images/xfs-1tb.img skip=16065 count=1 | hexdump -C 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.0157509 s, 32.5 kB/s $ sudo mount -t xfs -o ro,loop,offset=$((16065*512)) /home/forensic/forensic-images/xfs-1tb.img /mnt/temp/ mount: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Following RB's method, I get: $ sudo /sbin/losetup -o $((16065*512)) /dev/loop0 /home/forensic/forensic-images/xfs-1tb.img losetup: /dev/loop0: device is busy $ sudo /sbin/losetup -o $((16065*512)) /dev/loop1 /home/forensic/forensic-images/xfs-1tb.img $ sudo xfs_ncheck /dev/loop1 xfs_ncheck: /dev/loop1 is not a valid XFS filesystem (unexpected SB magic number 0x00000000) $ sudo mount /dev/loop1 /mnt/temp/ mount: you must specify the filesystem type $ sudo mount -t xfs /dev/loop1 /mnt/temp/ mount: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Thanks, Sagar Belure On Wed, Dec 5, 2012 at 10:44 AM, Derrick Karpo <dk...@gm...> wrote: > Exactly! Without going too far off topic, here's a sample image with > an XFS partition at byte offset 16065. You can use mmls to find the > offset of the partition, crudely confirm that the partition is XFS > using dd, then mount it with the appropriate offset. This should be > enough to get you going. > > > > $ mmls /tmp/bleck.img > DOS Partition Table > Offset Sector: 0 > Units are in 512-byte sectors > > Slot Start End Length Description > 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) > 01: ----- 0000000000 0000000062 0000000063 Unallocated > 02: 00:00 0000000063 0000016064 0000016002 Linux (0x83) > 03: 00:01 0000016065 0000079999 0000063935 Linux (0x83) > > > > $ dd if=/tmp/bleck.img skip=16065 count=1 | hexdump -C > 1+0 records in > 1+0 records out > 512 bytes (512 B) copied00000000 58 46 53 42 00 00 10 00 00 00 00 00 > 00 00 1f 37 |XFSB...........7| > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000020 90 d9 91 d9 e7 e7 45 44 ba b1 f8 91 a3 2c e3 63 > |......ED.....,.c| > 00000030 00 00 00 00 00 00 00 04 00 00 00 00 00 00 4b 80 > |..............K.| > 00000040 00 00 00 00 00 00 4b 81 00 00 00 00 00 00 4b 82 > |......K.......K.| > 00000050 00 00 00 01 00 00 1f 37 00 00 00 01 00 00 00 00 > |.......7........| > 00000060 00 00 04 b0 b4 a4 02 00 01 00 00 10 00 00 00 00 > |................| > 00000070 00 00 00 00 00 00 00 00 0c 09 08 04 0d 00 00 19 > |................| > 00000080 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 3d > |.......@.......=| > 00000090 00 00 00 00 00 00 1a 7f 00 00 00 00 00 00 00 00 > |................| > 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 000000b0 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 > |................| > 000000c0 00 00 00 00 00 00 00 01 00 00 00 0a 00 00 00 0a > |................| > 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000200 > > > > $ sudo mount -t xfs -o ro,loop,offset=$((16065*512)) /tmp/bleck.img /mnt > $ ls /mnt > this-is-a-test.txt > > > RB's suggestion of using the loopback is also a good idea. You can > setup a loopback device at the appropriate offset, then use the > loopback device for further processing. > > $ sudo /sbin/losetup -o $((16065*512)) /dev/loop0 /tmp/bleck.img > $ sudo xfs_ncheck /dev/loop0 > 19332 this-is-a-test.txt > $ sudo mount /dev/loop0 /mnt > $ ls /mnt > this-is-a-test.txt > > Derrick > > > On Tue, Dec 4, 2012 at 9:51 PM, RB <ao...@gm...> wrote: > > On Tue, Dec 4, 2012 at 9:36 PM, Sagar Belure <sag...@gm...> > wrote: > >> Yes. But that would require <device> as a parameter not image file. > >> I don't have hard disk but hard disk image. > > > > You can handle that either by using 'losetup' to set up a loopback > > block device at a specific offset in your image file, or use the '-o > > loop,offset=XYZ' option to 'mount', which does the same thing. > > Mounting an image "-o loop,offset=XYZ" just runs losetup in the > > background, and all losetup is doing in this case is creating a > > convenience mapping - you tell it that a block device you want to > > handle is at byte offset XYZ in the image and it will transparently > > translate all accesses to start at that address. > > > >> I'm not really sure how do operate on XFS filesystem image file. > > > > See above, unless you imaged the XFS filesystem with "xfsdump". > |
From: RB <ao...@gm...> - 2012-12-07 13:41:27
|
On Tue, Dec 4, 2012 at 11:09 PM, Sagar Belure <sag...@gm...> wrote: > $ sudo mount -t xfs -o ro,loop,offset=$((16065*512)) > /home/forensic/forensic-images/xfs-1tb.img /mnt/temp/ > mount: wrong fs type, bad option, bad superblock on /dev/loop1, This is wrong, because you used his offset (16065) instead of your offset (63). |
From: Ketil F. <ke...@fr...> - 2012-12-05 15:20:17
|
> > $ mmls /tmp/bleck.img $ sudo mount -t xfs -o ro,loop,offset=$((16065*512)) /tmp/bleck.img /mnt > or > $ sudo /sbin/losetup -o $((16065*512)) /dev/loop0 /tmp/bleck.img > $ sudo mount /dev/loop0 /mnt I find partx (or even kpartx) is a handy tool. It sets up the partition devices if you have an image of an entire disk, so you can mount them directly. # losetup /dev/loop0 /tmp/bleck.img # partx -a /dev/loop0 # mount -t xfs -o ro /dev/loop0p1 /mnt Cheers, Ketil |
From: Sagar B. <sag...@gm...> - 2012-12-07 05:07:38
|
Hi Ketil, I'm not really sure, what I'm doing wrong. # losetup /dev/loop0 /home/forensic/forensic-images/xfs-1tb.img # partx -a /dev/loop0 HDIO_GETGEO: Inappropriate ioctl for device # mount -t xfs -o ro /dev/loop0 /mnt/temp mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Thanks, Sagar Belure On Wed, Dec 5, 2012 at 8:19 PM, Ketil Froyn <ke...@fr...> wrote: > $ mmls /tmp/bleck.img > > $ sudo mount -t xfs -o ro,loop,offset=$((16065*512)) /tmp/bleck.img /mnt >> > or > >> $ sudo /sbin/losetup -o $((16065*512)) /dev/loop0 /tmp/bleck.img >> > $ sudo mount /dev/loop0 /mnt > > > I find partx (or even kpartx) is a handy tool. It sets up the partition > devices if you have an image of an entire disk, so you can mount them > directly. > > # losetup /dev/loop0 /tmp/bleck.img > # partx -a /dev/loop0 > # mount -t xfs -o ro /dev/loop0p1 /mnt > > Cheers, Ketil > |
From: Ketil F. <ke...@fr...> - 2012-12-07 07:58:35
|
You're trying to mount /dev/loop0, but you should be trying to mount a partition, like /dev/loop0p1 or /dev/loop0p2. These are created by the partx command. But did partx fail or is that just a warning? An alternative is to use kpartx, but then you'll find the partition devices are named like /dev/mapper/loop0p1 instead. -Ketil On Dec 7, 2012 6:07 AM, "Sagar Belure" <sag...@gm...> wrote: > Hi Ketil, > > I'm not really sure, what I'm doing wrong. > # losetup /dev/loop0 /home/forensic/forensic-images/xfs-1tb.img > # partx -a /dev/loop0 > HDIO_GETGEO: Inappropriate ioctl for device > # mount -t xfs -o ro /dev/loop0 /mnt/temp > mount: wrong fs type, bad option, bad superblock on /dev/loop0, > missing codepage or helper program, or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > > > Thanks, > Sagar Belure > > > > On Wed, Dec 5, 2012 at 8:19 PM, Ketil Froyn <ke...@fr...> wrote: > >> $ mmls /tmp/bleck.img >> >> $ sudo mount -t xfs -o ro,loop,offset=$((16065*512)) /tmp/bleck.img /mnt >>> >> or >> >>> $ sudo /sbin/losetup -o $((16065*512)) /dev/loop0 /tmp/bleck.img >>> >> $ sudo mount /dev/loop0 /mnt >> >> >> I find partx (or even kpartx) is a handy tool. It sets up the partition >> devices if you have an image of an entire disk, so you can mount them >> directly. >> >> # losetup /dev/loop0 /tmp/bleck.img >> # partx -a /dev/loop0 >> # mount -t xfs -o ro /dev/loop0p1 /mnt >> >> Cheers, Ketil >> > > |
From: Sagar B. <sag...@gm...> - 2012-12-07 09:12:19
|
It seems partx failed, that's the reason I don't see any partition like /dev/loop0p1 or /dev/loop0p2: # mount -t xfs -o ro /dev/loop<tab> loop0 loop1 loop2 loop3 loop4 loop5 loop6 loop7 Thanks, Sagar Belure On Fri, Dec 7, 2012 at 1:20 PM, Ketil Froyn <ke...@fr...> wrote: > You're trying to mount /dev/loop0, but you should be trying to mount a > partition, like /dev/loop0p1 or /dev/loop0p2. These are created by the > partx command. > > But did partx fail or is that just a warning? An alternative is to use > kpartx, but then you'll find the partition devices are named like > /dev/mapper/loop0p1 instead. > > -Ketil > On Dec 7, 2012 6:07 AM, "Sagar Belure" <sag...@gm...> wrote: > >> Hi Ketil, >> >> I'm not really sure, what I'm doing wrong. >> # losetup /dev/loop0 /home/forensic/forensic-images/xfs-1tb.img >> # partx -a /dev/loop0 >> HDIO_GETGEO: Inappropriate ioctl for device >> # mount -t xfs -o ro /dev/loop0 /mnt/temp >> mount: wrong fs type, bad option, bad superblock on /dev/loop0, >> missing codepage or helper program, or other error >> In some cases useful info is found in syslog - try >> dmesg | tail or so >> >> >> Thanks, >> Sagar Belure >> >> >> >> On Wed, Dec 5, 2012 at 8:19 PM, Ketil Froyn <ke...@fr...> wrote: >> >>> $ mmls /tmp/bleck.img >>> >>> $ sudo mount -t xfs -o ro,loop,offset=$((16065*512)) /tmp/bleck.img /mnt >>>> >>> or >>> >>>> $ sudo /sbin/losetup -o $((16065*512)) /dev/loop0 /tmp/bleck.img >>>> >>> $ sudo mount /dev/loop0 /mnt >>> >>> >>> I find partx (or even kpartx) is a handy tool. It sets up the partition >>> devices if you have an image of an entire disk, so you can mount them >>> directly. >>> >>> # losetup /dev/loop0 /tmp/bleck.img >>> # partx -a /dev/loop0 >>> # mount -t xfs -o ro /dev/loop0p1 /mnt >>> >>> Cheers, Ketil >>> >> >> |
From: RB <ao...@gm...> - 2012-12-07 13:38:27
|
On Tue, Dec 4, 2012 at 11:09 PM, Sagar Belure <sag...@gm...> wrote: > Well here is the output for the commands by Derrick: > $ mmls /home/forensic/forensic-images/xfs-1tb.img > > DOS Partition Table > Offset Sector: 0 > Units are in 512-byte sectors > > Slot Start End Length Description > 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) > 01: ----- 0000000000 0000000062 0000000063 Unallocated > 02: 00:00 0000000063 1953520064 1953520002 Linux RAID (0xFD) So what kind of RAID is it, 0, 1, 5...? Unless it's just RAID1 you're going to need all members of the original disk set. |
From: Sagar B. <sag...@gm...> - 2012-12-10 12:15:08
|
Hi, On Fri, Dec 7, 2012 at 7:08 PM, RB <ao...@gm...> wrote: > On Tue, Dec 4, 2012 at 11:09 PM, Sagar Belure <sag...@gm...> > wrote: > > Well here is the output for the commands by Derrick: > > $ mmls /home/forensic/forensic-images/xfs-1tb.img > > > > DOS Partition Table > > Offset Sector: 0 > > Units are in 512-byte sectors > > > > Slot Start End Length Description > > 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) > > 01: ----- 0000000000 0000000062 0000000063 Unallocated > > 02: 00:00 0000000063 1953520064 1953520002 Linux RAID (0xFD) > > So what kind of RAID is it, 0, 1, 5...? Unless it's just RAID1 you're > going to need all members of the original disk set. > It is RAID 1. Thanks, Sagar Belure |