Thread: [sleuthkit-users] Examining RAID-5 with only 1 drive
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users
|
From: DePriest, J. R. <jrd...@gm...> - 2006-11-10 16:50:31
|
This upcoming Monday, I am going to have to assist in an investigation involving a single drive from a RAID system. The drive was pulled two years ago and neither the original system nor the other drives exist any more. This investigation involves litigation so I have to make sure I use due diligence. I am only assuming this is RAID-5 since "the other two drives" were mentioned as being discarded. And since both the system and whatever controller was being used is gone, I can't know for sure. Is it possible for me to get anything useful out of this single drive? Brian's book claims that I might have luck with a simple keyword search, but has anyone had any experience to back it up? I probably cannot discuss what I am looking for per the litigation, but a simple keyword search would be useful and possibly even adequate. Pulling numbers out of the air, I told the person sending me the drive that there is only a 33% chance that useful information is on this drive and a 67% chance that there is nothing on there. That was just based on RAID-5 taking 3 disks... in retrospect, I realize that those numbers aren't right since RAID-5 can survive while a disk is being replaced. So, I don't know what I am really asking for except for other people's experiences and advice on this type of investigation. -- + + + NO CARRIER |
|
From: Colby Gutierrez-K. <co...@ge...> - 2006-11-10 17:39:35
|
On Nov 10, 2006, at 8:50 AM, DePriest, Jason R. wrote: > > I am only assuming this is RAID-5 since "the other two drives" were > mentioned as being discarded. > It could be from a RAID-3, and if it's the parity drive from that set, then the chance of getting anything useful off of it is 0%. If it's one of the other disks from the RAID-3, then chances are about 50% in the best case (see data block size vs actionable data below). > > Is it possible for me to get anything useful out of this single drive? > Yes. > Brian's book claims that I might have luck with a simple keyword > search, but has anyone had any experience to back it up? > Not directly, no. If you're lucky, and it really is from a RAID-5 set, and the block size was set to something large, like say 64KB, and the information you're looking for was plain text, then the chances are better that you'll find enough data intact to pass along. If the blocks are smaller, then chances are slimmer. It depends on what size of data block is actionable for the court case. If it's under 4KB (which is the usual default block size) then I'd say the 33/67 break down is close enough. If larger, then the the 33% chance must shrink. > I probably cannot discuss what I am looking for per the litigation, > but a simple keyword search would be useful and possibly even > adequate. > Huzzah! > Pulling numbers out of the air, I told the person sending me the drive > that there is only a 33% chance that useful information is on this > drive and a 67% chance that there is nothing on there. > > That was just based on RAID-5 taking 3 disks... in retrospect, I > realize that those numbers aren't right since RAID-5 can survive while > a disk is being replaced. > It can only survive if there are at least two remaining members (out of three) because the data on the missing disk can be recovered based on the data and parity information from the other two. Having just one disk doesn't help at all. > So, I don't know what I am really asking for except for other people's > experiences and advice on this type of investigation. > Not much help really. Mostly trying to set expectations. - Colby |
|
From: <rob...@us...> - 2006-11-10 17:48:05
|
Let me try that again...Raid 0 (striped, no parity), not raid 1 (mirroring) :) ROBERT C. CIPRIANI 1LT, SC, FLARNG XO, A/146TH SIG BN "VOICE OF COMMAND" H:(813) 333-2676 W:(727) 329-2000 x74264 "Whenever you do a thing, act as if all the world were watching." - Thomas Jefferson ----- Original Message ----- From: Colby Gutierrez-Kraybill <co...@ge...> Date: Friday, November 10, 2006 12:39 pm Subject: Re: [sleuthkit-users] Examining RAID-5 with only 1 drive > > On Nov 10, 2006, at 8:50 AM, DePriest, Jason R. wrote: > > > > > I am only assuming this is RAID-5 since "the other two drives" were > > mentioned as being discarded. > > > > It could be from a RAID-3, and if it's the parity drive from that set, > then the chance of getting anything useful off of it is 0%. If it's > one of the other disks from the RAID-3, then chances are about 50% > in the best case (see data block size vs actionable data below). > > > > > Is it possible for me to get anything useful out of this single > drive?> > > Yes. > > > Brian's book claims that I might have luck with a simple keyword > > search, but has anyone had any experience to back it up? > > > > Not directly, no. > > If you're lucky, and it really is from a RAID-5 set, and the block > size was set to something large, like say 64KB, and the information > you're looking for was plain text, then the chances are better that > you'll find enough data intact to pass along. If the blocks are > smaller, then chances are slimmer. It depends on what size > of data block is actionable for the court case. If it's under > 4KB (which is the usual default block size) then I'd say the > 33/67 break down is close enough. If larger, then the the 33% > chance must shrink. > > > > I probably cannot discuss what I am looking for per the litigation, > > but a simple keyword search would be useful and possibly even > > adequate. > > > > Huzzah! > > > Pulling numbers out of the air, I told the person sending me the > drive> that there is only a 33% chance that useful information is > on this > > drive and a 67% chance that there is nothing on there. > > > > That was just based on RAID-5 taking 3 disks... in retrospect, I > > realize that those numbers aren't right since RAID-5 can survive > while> a disk is being replaced. > > > > It can only survive if there are at least two remaining members > (out > of three) > because the data on the missing disk can be recovered based on the > dataand parity information from the other two. Having just one > disk doesn't > help at all. > > > So, I don't know what I am really asking for except for other > people's> experiences and advice on this type of investigation. > > > > Not much help really. Mostly trying to set expectations. > > - Colby > > > ------------------------------------------------------------------- > ------ > Using Tomcat but need to do more? Need to support web services, > security?Get stuff done quickly with pre-integrated technology to > make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimohttp://sel.as- > us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
|
From: DePriest, J. R. <jrd...@gm...> - 2006-11-10 21:50:13
|
On 11/10/06, Simson L. Garfinkel's Treo 700p wrote: - - - - - - - - - - 8< - - - - - - - - - - - - - - - - - - - - > >Brian's book claims that I might have luck with a simple keyword > >search, but has anyone had any experience to back it up? > > Yes, but it depends on what you are looking for. What kinds of object are > you looking for? Word file? JPEG? Incriminating sentence? - - - - - - - - - - - - - - - - - - - - - >8 - - - - - - - - - Most likely, the information would either be contained in some sort of email file, HTML file, or plain-text file. -Jason -- + + + NO CARRIER |
|
From: Simson L. Garfinkel's T. 7. <si...@ac...> - 2006-11-10 21:24:24
|
___ Sent with SnapperMail www.snappermail.com ...... Original Message ....... On Fri, 10 Nov 2006 09:39:28 -0800 "Colby Gutierrez-Kraybill" <co...@ge...> wrote: > >On Nov 10, 2006, at 8:50 AM, DePriest, Jason R. wrote: > >> >> I am only assuming this is RAID-5 since "the other two drives" were >> mentioned as being discarded. >> > >It could be from a RAID-3, and if it's the parity drive from that set, >then the chance of getting anything useful off of it is 0%. If it's >one of the other disks from the RAID-3, then chances are about 50% >in the best case (see data block size vs actionable data below). Who uses RAID-3? Most controllers don't even support it... > >> >> Is it possible for me to get anything useful out of this single drive? >> > >Yes. > >> Brian's book claims that I might have luck with a simple keyword >> search, but has anyone had any experience to back it up? >> > >Not directly, no. > >If you're lucky, and it really is from a RAID-5 set, and the block >size was set to something large, like say 64KB, and the information >you're looking for was plain text, then the chances are better that >you'll find enough data intact to pass along. If the blocks are >smaller, then chances are slimmer. It depends on what size >of data block is actionable for the court case. If it's under >4KB (which is the usual default block size) then I'd say the >33/67 break down is close enough. If larger, then the the 33% >chance must shrink. > > >> I probably cannot discuss what I am looking for per the litigation, >> but a simple keyword search would be useful and possibly even >> adequate. >> > >Huzzah! > >> Pulling numbers out of the air, I told the person sending me the drive >> that there is only a 33% chance that useful information is on this >> drive and a 67% chance that there is nothing on there. >> >> That was just based on RAID-5 taking 3 disks... in retrospect, I >> realize that those numbers aren't right since RAID-5 can survive while >> a disk is being replaced. >> > >It can only survive if there are at least two remaining members (out >of three) >because the data on the missing disk can be recovered based on the data >and parity information from the other two. Having just one disk doesn't >help at all. > >> So, I don't know what I am really asking for except for other people's >> experiences and advice on this type of investigation. >> > >Not much help really. Mostly trying to set expectations. > >- Colby > > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >sleuthkit-users mailing list >https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >http://www.sleuthkit.org > |
|
From: Colby Gutierrez-K. <co...@ge...> - 2006-11-10 21:41:38
|
On Nov 10, 2006, at 1:24 PM, Simson L. Garfinkel's Treo 700p wrote: > > ___ > Sent with SnapperMail > www.snappermail.com > > ...... Original Message ....... > On Fri, 10 Nov 2006 09:39:28 -0800 "Colby Gutierrez-Kraybill" > <co...@ge...> wrote: >> >> On Nov 10, 2006, at 8:50 AM, DePriest, Jason R. wrote: >> >>> >>> I am only assuming this is RAID-5 since "the other two drives" were >>> mentioned as being discarded. >>> >> >> It could be from a RAID-3, and if it's the parity drive from that >> set, >> then the chance of getting anything useful off of it is 0%. If it's >> one of the other disks from the RAID-3, then chances are about 50% >> in the best case (see data block size vs actionable data below). > > > Who uses RAID-3? Most controllers don't even support it... The XFX Revo64 3-port does. I don't think it was out 3+ years ago though. Don't know other controllers that support it off the top of my head. Use them a lot because they are transparent to the OS. I also pointed out in a private e-mail that perhaps you could get information off of the parity drive if you already knew the text you were looking for and approached the problem from the angle of retrieving a key (missing info) when you already have the known text (keyword(s)) and the crypt text (parity info) available. Just depends on how hard you're willing to work for it and whether or not you can convince a court that the information really is there. Or maybe I'm being daft. - Colby |
|
From: Simson L. Garfinkel's T. 7. <si...@ac...> - 2006-11-10 22:33:58
|
>I also pointed out in a private e-mail that perhaps you could get >information >off of the parity drive if you already knew the text you were looking >for >and approached the problem from the angle of retrieving a key >(missing info) >when you already have the known text (keyword(s)) and the crypt text >(parity info) available. Neat idea, but don't know if the court would go for yoyr cryptanalysis. ... And one would need to show that not other interpretation was possible... > >Just depends on how hard you're willing to work for it and whether or >not you can convince a court that the information really is there. > >Or maybe I'm being daft. > >- Colby > |
|
From: DePriest, J. R. <jrd...@gm...> - 2006-11-10 22:42:21
|
> Neat idea, but don't know if the court would go for yoyr cryptanalysis. ... > And one would need to show that not other interpretation was possible... > > > >Just depends on how hard you're willing to work for it and whether or > >not you can convince a court that the information really is there. > > > >Or maybe I'm being daft. > > > >- Colby Two other parties have forensic images of the hard disk drive so anything I do they can recreate and hopefully have the same results. I am keeping detailed notes which is why I am not starting until Monday. The work day is almost over here (20 more minutes), so I don't want to be in the middle of something and skip any documentation. I need plenty of time to keep track of what I am doing. I will happily post what my luck is. I actually have the FedEx box at my desk and I've signed the Chain of Custody form so it is in my possession until I'm done with it. It is very tempting to rip it open and dive in, but I have so far resisted the urge. -Jason -- |
|
From: DePriest, J. R. <jrd...@gm...> - 2006-11-14 22:07:00
|
The RAID drive is a SCSI drive pulled from a Compaq server (it's product number has a -002 at the end, not sure what that means) and I do not have a piece of write-blocking hardware for SCSI. I've ordered it to be overnighted, so hopefully tomorrow I can start providing some information about what shows up on the drive. In the mean-time, I am examining a more common IDE drive that was also sent. I already have an IDE write-blocker. -Jason -- + + + NO CARRIER |
|
From: DePriest, J. R. <jrd...@gm...> - 2006-11-15 19:48:57
|
The SCSI drive produces this output:
A70067@ebizsrvb /sleuthkit/sleuthkit/bin
$ ./img_stat -i raw -v /dev/sdd
img_open: Type: raw NumImg: 1 Img1: /dev/sdd
IMAGE FILE INFORMATION
--------------------------------------------
Image Type: raw
Size in bytes: 18209320960
A70067@ebizsrvb /sleuthkit/sleuthkit/bin
$ ./mmls -t dos -i raw -v /dev/sdd
img_open: Type: raw NumImg: 1 Img1: /dev/sdd
dos_load_prim: Table Sector: 0
raw_read_random: byte offset: 0 len: 512
load_pri:0:0 Start: 0 Size: 0 Type: 0
load_pri:0:1 Start: 0 Size: 0 Type: 0
load_pri:0:2 Start: 63 Size: 16002 Type: 18
load_pri:0:3 Start: 0 Size: 0 Type: 0
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000062 0000000062 Unallocated
02: 00:02 0000000063 0000016064 0000016002 Hibernation (0x12)
03: ----- 0000016065 0035565079 0035549015 Unallocated
A70067@ebizsrvb /sleuthkit/sleuthkit/bin
dls and ils produce identical errors:
img_open: Type: raw NumImg: 1 Img1: /dev/sdd
fsopen: Auto detection mode at offset 0
raw_read_random: byte offset: 0 len: 512
raw_read_random: byte offset: 0 len: 512
raw_read_random: byte offset: 1024 len: 1024
raw_read_random: byte offset: 65536 len: 1536
raw_read_random: byte offset: 262144 len: 1536
raw_read_random: byte offset: 8192 len: 1536
iso9660_open img_info: 268566976 ftype: 112 test: 1
raw_read_random: byte offset: 32768 len: 7
get_vol_desc Bad volume descriptor: Magic
number is not CD001Cannot determine file system type
So I am extracting strings from the partition labeled 'Hibernation'
and hopefully that will be good enough.
Any other ideas?
-Jason
--
+ + + NO CARRIER
|
|
From: Simson G. <si...@ac...> - 2006-11-15 19:58:21
Attachments:
smime.p7s
|
> > So I am extracting strings from the partition labeled 'Hibernation' > and hopefully that will be good enough. > Why are you extracting from the Hibernation partition and not from the entire physical device? |
|
From: DePriest, J. R. <jrd...@gm...> - 2006-11-19 23:00:58
|
On 11/15/06, Simson Garfinkel wrote: > > > > So I am extracting strings from the partition labeled 'Hibernation' > > and hopefully that will be good enough. > > > Why are you extracting from the Hibernation partition and not from > the entire physical device? > Oversight. I have extracted the entire thing. I have been told by my boss that the lawyers say the FBI found evidence of file deletion on the drive. My question is this: how can such evidence be found when the file system is not mountable? If there is not a recognized file system to provide the references and pointers to files and file names, how can you know what was deleted and what was still a file? I see large sections of the disk that are just 0x00, but that is normal for areas that have never been written to. Other areas have suspicious patterns such as 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00, etc. I honestly don't know what would cause that naturally. But since I cannot mount the drive and look at the file system directly, I can only make inferences. I imagine the disk was inside a Windows server, so the original file system was likely NTFS. Is there anyway I can force any of the sleuthkit tools to see it as such and extract a real file list from it? Or am I completely out of luck? I cannot search for file names, only strings. What would be the best way to search for the MFT by strings alone? -Jason -- + + + NO CARRIER |
|
From: Simson G. <si...@ac...> - 2006-11-19 23:22:18
Attachments:
smime.p7s
|
On Nov 19, 2006, at 6:00 PM, DePriest, Jason R. wrote: > > I have been told by my boss that the lawyers say the FBI found > evidence of file deletion on the drive. That's a weird statement. What does it mean? That files were deleted? That files relevant to the case were deleted? > > My question is this: how can such evidence be found when the file > system is not mountable? If there is not a recognized file system to > provide the references and pointers to files and file names, how can > you know what was deleted and what was still a file? Depends on what the file system is. If it is FAT32, then the first character of filenames will be changed when they are deleted. You might recover directory entries even if the file system is not recoverable. Or do they mean that they think there has been intentional running of a sanitization tool? > > I see large sections of the disk that are just 0x00, but that is > normal for areas that have never been written to. It's also normal for areas that have 0x00s in them. You will find a lot of them in file systems. > > Other areas have suspicious patterns such as 00 01 02 03 04 05 06 07 > 08 09 0a 0b 0c 0d 0e 0f 00, etc. I honestly don't know what would > cause that naturally. TIFF files. Data. Who knows? > > But since I cannot mount the drive and look at the file system > directly, I can only make inferences. > > I imagine the disk was inside a Windows server, so the original file > system was likely NTFS. Why do you imagine this? > > Is there anyway I can force any of the sleuthkit tools to see it as > such and extract a real file list from it? > > Or am I completely out of luck? I cannot search for file names, > only strings. > > What would be the best way to search for the MFT by strings alone? Honestly, I think that you're going to need to bring in somebody who has more experience than you do at this sort of thing. |
|
From: DePriest, J. R. <jrd...@gm...> - 2006-11-19 23:36:36
|
On 11/19/06, Simson Garfinkel wrote: > > On Nov 19, 2006, at 6:00 PM, DePriest, Jason R. wrote: > > > > > I have been told by my boss that the lawyers say the FBI found > > evidence of file deletion on the drive. > > That's a weird statement. What does it mean? That files were deleted? > That files relevant to the case were deleted? The statement is that relevant files were deleted and that there is evidence of this on the drive I am looking at. The lawyer does not want to give us too many details. She thinks it will damage our impartiality. What I have been told: source code files were copied from a remote site to the server this drive was on. The source code was sent to various other 3rd parties. The source code was deleted from the server. I have been asked: prove it or disprove it. Any other questions about what the code was for or what language it was in or where it was copied from or where it was sent to have met with no answers. > > > > > My question is this: how can such evidence be found when the file > > system is not mountable? If there is not a recognized file system to > > provide the references and pointers to files and file names, how can > > you know what was deleted and what was still a file? > > Depends on what the file system is. If it is FAT32, then the first > character of filenames will be changed when they are deleted. You > might recover directory entries even if the file system is not > recoverable. > > Or do they mean that they think there has been intentional running of > a sanitization tool? This was not clarified. The only person I get information from is my manager who gets information from the lawyer. > > > > > I see large sections of the disk that are just 0x00, but that is > > normal for areas that have never been written to. > > It's also normal for areas that have 0x00s in them. You will find a > lot of them in file systems. > > > > Other areas have suspicious patterns such as 00 01 02 03 04 05 06 07 > > 08 09 0a 0b 0c 0d 0e 0f 00, etc. I honestly don't know what would > > cause that naturally. > > TIFF files. Data. Who knows? > > > > > But since I cannot mount the drive and look at the file system > > directly, I can only make inferences. > > > > I imagine the disk was inside a Windows server, so the original file > > system was likely NTFS. > > Why do you imagine this? > This is from a company server and 95% of our servers run a Windows OS. > > > > Is there anyway I can force any of the sleuthkit tools to see it as > > such and extract a real file list from it? > > > > Or am I completely out of luck? I cannot search for file names, > > only strings. > > > > What would be the best way to search for the MFT by strings alone? > > Honestly, I think that you're going to need to bring in somebody who > has more experience than you do at this sort of thing. > That's what my boss said, but another manager-type in my department assured the lawyers and law enforcement that we could do whatever they wanted before my boss even knew about the case or the work needed. -Jason -- + + + NO CARRIER |
|
From: Svein Y. W. <sv...@wi...> - 2006-11-20 07:40:10
|
> The lawyer does not want to give us too many details. She thinks it > will damage our impartiality. This is interesting. In classic forensics, where the task can be explicitly defined, this attitude is appropriate. For example: - tell me if fingerprint A and B match - tell me if this hair comes from the same person as this blood sample I think the opposite is the case in digital forensics. In digital forensics, the task is (usually) to find the evidence, given a large heap of information. Say for example a 50 Gb hard drive. Since it is impossible for the investigator to know in advance what kind of evidence may be on the drive, he must imagine possible evidence items based on an assumption of what could be on the drive. Valid assumptions can in my opinion only be made if the investigator has access to all possible information about the case. After all, you only find what you look for. Any thoughts? Regards, Svein Willassen -- Researcher Norwegian University of Science and Technology |
|
From: Simson G. <si...@ac...> - 2006-11-20 17:18:20
Attachments:
smime.p7s
|
Hi, Svein. I agree with your reasoning but not with your conclusion. In digital forensics, like classical forensics, it's appropriate to explicitly define the task but not tell the examiner the expected outcome. - Tell me if this child porn document is on this hard drive. - Tell me if this document has a GUID that is consistent with this computer. Giving an examiner a 50GB drive and saying "find something incriminating" is akin to putting an investigator in bedroom and saying "find something." The real issue isn't digital vs. non- digital, but one of clearly defining the expectations of the investigation. On Nov 20, 2006, at 2:40 AM, Svein Yngvar Willassen wrote: > >> The lawyer does not want to give us too many details. She thinks it >> will damage our impartiality. > > This is interesting. In classic forensics, where the task can be > explicitly > defined, this attitude is appropriate. For example: > > - tell me if fingerprint A and B match > - tell me if this hair comes from the same person as this blood sample > > I think the opposite is the case in digital forensics. In digital > forensics, > the task is (usually) to find the evidence, given a large heap of > information. Say for example a 50 Gb hard drive. Since it is > impossible for > the investigator to know in advance what kind of evidence may be on > the > drive, he must imagine possible evidence items based on an > assumption of > what could be on the drive. Valid assumptions can in my opinion > only be made > if the investigator has access to all possible information about > the case. > > After all, you only find what you look for. > > Any thoughts? > > Regards, > > Svein Willassen > -- > Researcher > Norwegian University of Science and Technology > > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
|
From: Svein Y. W. <sv...@wi...> - 2006-11-20 20:55:37
|
> In digital forensics, like classical forensics, it's appropriate to > explicitly define the task but not tell the examiner the expected > outcome. > > - Tell me if this child porn document is on this hard drive. > - Tell me if this document has a GUID that is consistent with this > computer. > > Giving an examiner a 50GB drive and saying "find something > incriminating" is akin to putting an investigator in bedroom and > saying "find something." The real issue isn't digital vs. non- > digital, but one of clearly defining the expectations of the > investigation. During my time in the police and when working as a forensic expert, I've had several of those cases where the task has been clearly defined. They have usually been variations of the theme "find this email" or "find this document". These cases are usually fairly straightforward, although they tend to culminate in difficult questions like "why wasn't it found?" or "how did it get there?" More often then not however, I find that the person that asks me to do the investigation lacks the expertise and experience to give me a clear assignment. This may be because they may not have the necessary computer knowledge (typically a prosecutor, attorney or judge), because they do not have the details of the case themselves, or simply because they do not know exactly what to look for. Imagine investigating the computer used by someone suspected to be involved in a tax fraud. In such a case, one could certainly start browsing the documents stored on the computer in the hope of finding something interesting. But how would you know which document has value as evidence in the specific case? The documents of evidentiary value can only be pinpointed if the investigator knows the specifics of the case. I have indeed several times been asked to "find the evidence" without being given any further clues. In these cases I took the responsibility to go back and obtain further information about the case before starting the investigation. Svein |
|
From: <Fra...@ps...> - 2006-11-20 18:30:43
|
My two cents. (I don't have my glasses so forgive my unproofed response.) This is something that I've not seen a lot of and feel this topic is overdue. As was stated before getting to the disk and finding files is for most security professionals a no brainier. This isn't where the problem exists. It's with the legal system and how specific forensic examinations should be done. There are a number of types of cases which the examiner needs to know what he should focus his examination on. I feel this is imperative. If for example you're given a computer and told "find something" you could be there for an extended amount of time spinning your wheels and hours of chargeable time to a case for almost very little result. That would be the purpose of the chain of custody prior to the forensic examination. With the newly imaged drive the examiner can pretty much run tests to determine certain criteria on the system. As long as the original evidence can be used to make another image and the defense or prosecution can use the original evidence and methods to recreate what has been discovered then I personally see no reason why an examiner cannot be told there may be child porn on this drive. I think what's at question here is not so much the what as the how. How something was discovered. If you have a legal warrant and confiscate a suspects computer then that evidence would be use in that case for the purpose of determining if they can discover supporting data. This is a good reason why this type of forensic examination is very expensive. I would personally charge by the hour at $150 to $300 an hour fot this type of work depending on the case. Nothing less. (rant: I don't really see the necessity of a CFE type of certification because it's not how you use the tools it's how you've collected the data and followed the appropriate CoC.) All the certification in the world isn't going to provide you with enough knowledge as a good auditor. - That's just my two cents SANS. Like the old adage, 'it's not over till the paper work is done". A good example would be in a non-criminal case. An investigation into weather someone is cheating on a spouse. You're given a computer and told 'find something'. In this type of case the forensic examiner would 'need to know' that he's looking for any signs of a cheating spouse. I'm not an attorney, that's just my blurred two cents. Frank Kenisky IV, CISSP, CISA, CISM Information Technical Security Specialist (210) 301-6433 - (210) 887-6985 "Svein Yngvar Willassen" <sv...@wi...> Sent by: sle...@li... 11/20/2006 01:40 AM To <sle...@li...> cc Subject [sleuthkit-users] What information is needed to do a digital forensic analysis? (was: RE: Examining RAID-5 with only 1 drive) > The lawyer does not want to give us too many details. She thinks it > will damage our impartiality. This is interesting. In classic forensics, where the task can be explicitly defined, this attitude is appropriate. For example: - tell me if fingerprint A and B match - tell me if this hair comes from the same person as this blood sample I think the opposite is the case in digital forensics. In digital forensics, the task is (usually) to find the evidence, given a large heap of information. Say for example a 50 Gb hard drive. Since it is impossible for the investigator to know in advance what kind of evidence may be on the drive, he must imagine possible evidence items based on an assumption of what could be on the drive. Valid assumptions can in my opinion only be made if the investigator has access to all possible information about the case. After all, you only find what you look for. Any thoughts? Regards, Svein Willassen -- Researcher Norwegian University of Science and Technology ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ sleuthkit-users mailing list https://lists.sourceforge.net/lists/listinfo/sleuthkit-users http://www.sleuthkit.org |
|
From: Simson L. G. <si...@ac...> - 2006-11-20 02:00:06
|
> The lawyer does not want to give us too many details. She thinks it > will damage our impartiality. > What I have been told: source code files were copied from a remote > site to the server this drive was on. > The source code was sent to various other 3rd parties. > The source code was deleted from the server. > > I have been asked: prove it or disprove it. You can't do either, it turns out. However, you might be able to show that fragments of the source code are on the disk that you have. >> >> Honestly, I think that you're going to need to bring in somebody who >> has more experience than you do at this sort of thing. >> > > That's what my boss said, but another manager-type in my department > assured the lawyers and law enforcement that we could do whatever they > wanted before my boss even knew about the case or the work needed. Ah, the real world... |
|
From: Brian C. <ca...@sl...> - 2006-11-21 05:06:40
|
Simson Garfinkel wrote: > > On Nov 19, 2006, at 6:00 PM, DePriest, Jason R. wrote: > >> >> My question is this: how can such evidence be found when the file >> system is not mountable? If there is not a recognized file system to >> provide the references and pointers to files and file names, how can >> you know what was deleted and what was still a file? > > Depends on what the file system is. If it is FAT32, then the first > character of filenames will be changed when they are deleted. You might > recover directory entries even if the file system is not recoverable. Similarly with NTFS, but it will require you to look at the allocation status in the MFT entry flags. If you know the type of source code, you could do a UTF-16 search for ".cpp" (or similar) to get the file name entries. >> Is there anyway I can force any of the sleuthkit tools to see it as >> such and extract a real file list from it? No, I think you are out of luck. TSK requires at least a minimal amount of basic information from a boot sector / super block and you may not even have that in this case since you are missing two of the RAID drives. You may consider looking into testdisk or gpart to see if they can scavenge any file system traces from the image. brian |
|
From: DePriest, J. R. <jrd...@gm...> - 2006-11-21 05:47:20
|
On 11/21/06, Brian Carrier wrote: > > No, I think you are out of luck. TSK requires at least a minimal amount > of basic information from a boot sector / super block and you may not > even have that in this case since you are missing two of the RAID > drives. You may consider looking into testdisk or gpart to see if they > can scavenge any file system traces from the image. > > brian > I have something magical to report. Active File Recovery 7.1 build 333 (commercial program) found an NTFS partition on the drive. It starts at sector 1120 and is 35544920 sectors long. It has the default NTFS cluster size of 4096. It seems to have an full Windows file system on it with enough directories to actually boot and run. According to AFR, there are exactly 0 (zero) deleted files on it. I am disturbed by that result. I can't seem to get the partition recognized by any of the autopsy tools to verify that number. -Jason -- |
|
From: Brian C. <ca...@sl...> - 2006-11-21 17:33:26
|
DePriest, Jason R. wrote: > Active File Recovery 7.1 build 333 (commercial program) found an NTFS > partition on the drive. > > It starts at sector 1120 and is 35544920 sectors long. It has the > default NTFS cluster size of 4096. > > It seems to have an full Windows file system on it with enough > directories to actually boot and run. > > According to AFR, there are exactly 0 (zero) deleted files on it. > > I am disturbed by that result. I can't seem to get the partition > recognized by any of the autopsy tools to verify that number. Currently, Autopsy does not allow you to specify the location of arbitrary partitions (it requires 'mmls' to find them from a partition table). Since you know the offset, you can run 'fls -o 1120 IMG.img' on the image and see what it comes back with. Is this from the RAID array or the other stand-alone drive? If it is one of the RAID drives, then I assume you'll get a bunch of errors since data will be missing. brian |
|
From: <Fra...@ps...> - 2006-11-27 15:29:39
|
Not sure if this can be done with sleuth-kit, but I've been asked to see if I can recover files from a mini dvd made using a DV camera. Apparently it was finalized but now gives the user a disk failure. When I look at the disk using winxp in explorer it appears empty. Any suggestions on the disk type (ntfs, fat, etc) and where I might start. Thanks Frank Kenisky IV, CISSP, CISA, CISM Information Technical Security Specialist (210) 301-6433 - (210) 887-6985 |
|
From: Brian C. <ca...@sl...> - 2006-11-28 14:21:36
|
I personally don't know much about the DVD format, but I doubt TSK will help. I've used ISOBuster for CDs before and the website says it works for DVDs as well. brian On Nov 27, 2006, at 10:29 AM, Fra...@ps... wrote: > > Not sure if this can be done with sleuth-kit, but I've been asked > to see if I can recover files from a mini dvd made using a DV > camera. Apparently it was finalized but now gives the user a disk > failure. > > When I look at the disk using winxp in explorer it appears empty. > > Any suggestions on the disk type (ntfs, fat, etc) and where I might > start. > > Thanks > > Frank Kenisky IV, CISSP, CISA, CISM > Information Technical Security Specialist > (210) 301-6433 - (210) 887-6985 > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
|
From: <Fra...@ps...> - 2006-11-28 14:48:45
|
Thanks I tried several things and still couldn't see any data. I have a dvd burner on my laptop, downloaded isobuster and couldn't see anything on the disk. I tried using a disk I had previously burned and all the data showed up. I can see that something was written to the disk but I just can't get to it. I've got image scan 2.1 from the fbi but the formats it looks for may not include the ones for burned dvds. Thanks again Frank Kenisky IV, CISSP, CISA, CISM Information Technical Security Specialist (210) 301-6433 - (210) 887-6985 Brian Carrier <ca...@sl...> Sent by: sle...@li... 11/28/2006 08:21 AM To Fra...@ps... cc "DePriest, Jason R." <jrd...@gm...>, sle...@li..., sle...@li... Subject Re: [sleuthkit-users] Examining a dvd disk made using a DV camera I personally don't know much about the DVD format, but I doubt TSK will help. I've used ISOBuster for CDs before and the website says it works for DVDs as well. brian On Nov 27, 2006, at 10:29 AM, Fra...@ps... wrote: > > Not sure if this can be done with sleuth-kit, but I've been asked > to see if I can recover files from a mini dvd made using a DV > camera. Apparently it was finalized but now gives the user a disk > failure. > > When I look at the disk using winxp in explorer it appears empty. > > Any suggestions on the disk type (ntfs, fat, etc) and where I might > start. > > Thanks > > Frank Kenisky IV, CISSP, CISA, CISM > Information Technical Security Specialist > (210) 301-6433 - (210) 887-6985 > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ sleuthkit-users mailing list https://lists.sourceforge.net/lists/listinfo/sleuthkit-users http://www.sleuthkit.org |
Thanks for helping keep SourceForge clean.
X