Thread: [sleuthkit-users] dcat feature request
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users
|
From: nighty <nig...@gm...> - 2004-03-29 15:29:05
|
Hello, I just found something, but I'm not sure, whether it's a bug. I used Autopsy (I tested it on 1.75 and 2.0) and switched to Data Analysi= s=20 Mode in order to check some unit's content. Now it appears, that if I am=20 using a raw image (without filesystem) and want to view more than one uni= t,=20 Autopsy gives me a wrong unit content. I want to give you an example of w= hat=20 Autopsy does, using dcat: dcat -a -f raw /PATH_TO_IMAGE/foo.dd 4000 512 this gives me the ascii output of the 4000th 512 byte unit. Fine! Now, when telling Autopsy to show me 2 units, Autopsy gives me the same=20 output, as if I had done a dcat -a -f raw /PATH_TO_IMAGE/foo.dd 4000 2048 So he does not show me unit 4000-4003, but the 4000th 2048 byte unit. When using a image with a filesystem, there is no problem, only with raw=20 images this occurs. Therefor I suggest, that it would be fine, to give dcat the capability to= =20 show a range of units, similar to what dls does, and of course adjust Aut= opsy=20 to this. So I could perform a dcat -a -f raw /PATH_TO_IMAGE/foo.dd 4000-4003 512 Best regards, Harald Katzer PS.: It would also be a useful feature, when the user could remove images= ,=20 hosts and cases from Autopsy |
|
From: Brian C. <ca...@sl...> - 2004-03-29 16:07:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 29, 2004, at 9:29 AM, nighty wrote: > I just found something, but I'm not sure, whether it's a bug. bug / oversight ... same thing. This functionality for raw types is documented in the man pages etc, but I forgot about it when I added support to Autopsy for raw / swap images. It is now SF bug 925382. > Therefor I suggest, that it would be fine, to give dcat the capability > to > show a range of units, similar to what dls does, and of course adjust > Autopsy > to this. I agree with your suggested fix. I may even make a flag to specify the data unit size. > PS.: It would also be a useful feature, when the user could remove > images, > hosts and cases from Autopsy Yea, I know. I'm just paranoid about having 'rm -rf' commands in my code. Hosts and cases are easy to delete by hand because it is just the directory that needs to be removed. There are no config files that you have to clean up. brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAaEnGOK1gLsdFTIsRAiQSAJ9RHOJ1IwQFseEmyE8q1ZkPEtdnSACdH4Dg NUy76AmmIBnTcExLrXR+1EM= =meXz -----END PGP SIGNATURE----- |
|
From: Eagle I. S. I. <in...@ea...> - 2004-03-30 03:20:11
|
I have a file, called 17g.dd, which is an image of an NTFS drive (not the partition) When I went to add the image, Autopsy would not let me add it as an ntfs file system. I could only add it as raw. When I load the image file into Autopsy, I don't have the ability to do a file type analysis on it, only a keyword search. I'd like to use the File Type feature on this image. Is that possible? Niall. |
|
From: Brian C. <ca...@sl...> - 2004-03-30 05:44:57
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 29, 2004, at 10:20 PM, Eagle Investigative Services, Inc. wrote: > I have a file, called 17g.dd, which is an image of an NTFS drive (not > the > partition) > > When I went to add the image, Autopsy would not let me add it as an > ntfs > file system. I could only add it as raw. Autopsy only supports file system images. For info on splitting the disk into partitions, see: http://www.sleuthkit.org/informer/sleuthkit-informer-2.html#split http://www.sleuthkit.org/informer/sleuthkit-informer-12.html#mmls brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAaQlUOK1gLsdFTIsRAo+GAJ9hi8hpLoKLkigFmh93YgTR2loZqQCfRb6G 2zkxB/ur1VqscyMjRCdOfu4= =/iSj -----END PGP SIGNATURE----- |
|
From: Enda C. <en...@co...> - 2004-03-30 07:59:18
|
Quoting: "Brian Carrier" > On Mar 29, 2004, at 10:20 PM, Eagle Investigative Services, Inc. wrote: > > > I have a file, called 17g.dd, which is an image of an NTFS drive (not > > the > > partition) > > > > When I went to add the image, Autopsy would not let me add it as an > > ntfs > > file system. I could only add it as raw. > > Autopsy only supports file system images. For info on splitting the > disk into partitions, see: What happens Brian if you are working with a corrupt filesystem from a system crash, and the parition is not mountable? is it possible to analyse fragments / chunks of a damaged partition using the filesystem rules? This is fairly common with NTFS where a key part of the fs gets corrupted during a crash, but presumably there is a large portion of the filesystem that is "ok" and still written with the filesystem rules. -Enda |
|
From: Brian C. <ca...@sl...> - 2004-03-30 13:52:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 30, 2004, at 2:55 AM, Enda Cronnolly wrote: > What happens Brian if you are working with a corrupt filesystem from a > system crash, and the parition is not mountable? is it possible to > analyse > fragments / chunks of a damaged partition using the filesystem rules? It depends on why the image is corrupt. TSK doesn't do a full check of the FS before it starts to analyze it. Autopsy checks the image when importing into Autopsy by running the 'fsstat' tool on the image to see if it can read the superblock and other general file system data. That goal of that is to detect when users enter the wrong file system type. TSK tools will process a file system image until they encounter an error. They will not try to fix the error or "guess" what the correct value is. TSK also ignores the "dirty" status of a file system, as marked in the super block (or equivalent). brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAaXuvOK1gLsdFTIsRAsUPAJ9xKoYJ64XBI3/YyZ8zTjXVfsQpSgCfcyWN 3lE0aWjd9r817dsZAmb2iBk= =rXYW -----END PGP SIGNATURE----- |
|
From: Enda C. <en...@co...> - 2004-03-30 20:56:53
|
Quoting: "Brian Carrier" <carrier@sle > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mar 30, 2004, at 2:55 AM, Enda Cronnolly wrote: > > What happens Brian if you are working with a corrupt filesystem from a > > system crash, and the parition is not mountable? is it possible to > > analyse > > fragments / chunks of a damaged partition using the filesystem rules? > > It depends on why the image is corrupt. TSK doesn't do a full check of > the FS before it starts to analyze it. Autopsy checks the image when > importing into Autopsy by running the 'fsstat' tool on the image to see > if it can read the superblock and other general file system data. That > goal of that is to detect when users enter the wrong file system type. Yeah, the autopsy stdout trace quotes: fsstat: Error: /path/sda2.img is not a NTFS file system image on an NTFS disk partition that fails to mount on the command line with error "bad superblock or incorrect filesystem type, or too many filesystems mounted". It would be nice to be able to force the filesystem in autopsy. > TSK tools will process a file system image until they encounter an > error. They will not try to fix the error or "guess" what the correct > value is. TSK also ignores the "dirty" status of a file system, as > marked in the super block (or equivalent). Again, would be *nice* to have conv=noerror type operations. End of wish listing.... ;-) -Enda. |
|
From: Eagle I. S. I. <in...@ea...> - 2004-03-30 16:44:53
|
Splitting the file into the partitions worked. Thanks, Brian, and dorkus, for the help. Niall. -----Original Message----- From: Brian Carrier [mailto:ca...@sl...] Sent: Tuesday, March 30, 2004 12:45 AM To: Eagle Investigative Services, Inc. Cc: sle...@li... Subject: Re: [sleuthkit-users] Image searching qurestion -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 29, 2004, at 10:20 PM, Eagle Investigative Services, Inc. wrote: > I have a file, called 17g.dd, which is an image of an NTFS drive (not > the > partition) > > When I went to add the image, Autopsy would not let me add it as an > ntfs file system. I could only add it as raw. Autopsy only supports file system images. For info on splitting the disk into partitions, see: http://www.sleuthkit.org/informer/sleuthkit-informer-2.html#split http://www.sleuthkit.org/informer/sleuthkit-informer-12.html#mmls brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAaQlUOK1gLsdFTIsRAo+GAJ9hi8hpLoKLkigFmh93YgTR2loZqQCfRb6G 2zkxB/ur1VqscyMjRCdOfu4= =/iSj -----END PGP SIGNATURE----- |
|
From: Brian C. <ca...@sl...> - 2004-03-30 21:22:10
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 30, 2004, at 3:54 PM, Enda Cronnolly wrote: > > Yeah, the autopsy stdout trace quotes: > fsstat: Error: /path/sda2.img is not a NTFS file system image > > on an NTFS disk partition that fails to mount on the command line with > error > "bad superblock or incorrect filesystem type, or too many filesystems > mounted". > > It would be nice to be able to force the filesystem in autopsy. You can comment out lines 1854 and 1855 of src/fstools/ntfs.c, recompile, and see how much further it goes :) >> TSK tools will process a file system image until they encounter an >> error. They will not try to fix the error or "guess" what the correct >> value is. TSK also ignores the "dirty" status of a file system, as >> marked in the super block (or equivalent). > > Again, would be *nice* to have conv=noerror type operations. It is a tough line to walk though. It is simple with 'dd' because each block is independent from the next so an error does not get out of control. With TSK, does the force flag remove all sanity checks from the code or just some? My assumption has been that if there is one big error, then there are more errors and it is going to fail at some point. If you drop all sanity checks, then invalid data could be used and you have to seriously question if the results you are seeing are valid. My advice for this scenario would be to make a copy of the image and run 'fsck' with as much verbose logging as possible. Analyze the clean version and then compare how the two are different. brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAaeUEOK1gLsdFTIsRAioRAJ9bWOR5kEz8QmHMk6Rajfq6sxouNACeK29o 0mcFtepivP+S/vOayhr2YC0= =WL9K -----END PGP SIGNATURE----- |
|
From: Matthew M. S. <msh...@th...> - 2004-03-30 23:56:15
|
> You can comment out lines 1854 and 1855 of src/fstools/ntfs.c, > recompile, and see how much further it goes :) I don't know about the rest of you, but the above statement is why I use open source forensic tools. I'll save that email for future reference. ;) -- Matthew M. Shannon, CISSP Principal Agile Risk Management LLC www.agilerm.net msh...@ag... (c)813.732.5076 (o)813.676.5197 |
|
From: Enda C. <en...@co...> - 2004-03-31 02:53:22
|
> > You can comment out lines 1854 and 1855 of src/fstools/ntfs.c, > > recompile, and see how much further it goes :) > > > I don't know about the rest of you, but the above statement is why I use > open source forensic tools. > > I'll save that email for future reference. ;) to be honest, I know of commercial tool vendors that would email you the same fix in the form of a "new dll" / .so etc, but the reason I use open source tools is because when that didnt work, I could also try commenting lines 285-290,1071-1075, 1440-1444, 1506-1516 ...... -Enda. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X