The Sleuth Kit

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

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 <colby@...>
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
>

___
Sent with SnapperMail
 http://www.snappermail.com

...... Original Message .......
On Fri, 10 Nov 2006 09:39:28 -0800 "Colby Gutierrez-Kraybill" 
<colby@...> 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
>

On Nov 10, 2006, at 1:24 PM, Simson L. Garfinkel's Treo 700p wrote:

>
> ___
> Sent with SnapperMail
> http://www.snappermail.com
>
> ...... Original Message .......
> On Fri, 10 Nov 2006 09:39:28 -0800 "Colby Gutierrez-Kraybill"
> <colby@...> 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

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

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

> 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

--

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

The SCSI drive produces this output:
A70067@... /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@... /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@... /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

>
> 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?

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

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.

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

> 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...

> 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

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
>

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" <svein@...> 
Sent by: sleuthkit-users-bounces@...
11/20/2006 01:40 AM

To
<sleuthkit-users@...>
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

> 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

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

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

--

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

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

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, Frank_Kenisky@... 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

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 <carrier@...> 
Sent by: sleuthkit-users-bounces@...
11/28/2006 08:21 AM

To
Frank_Kenisky@...
cc
"DePriest, Jason R." <jrdepriest@...>, 
sleuthkit-users-bounces@..., 
sleuthkit-users@...
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, Frank_Kenisky@... 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

if you "dd" the disk, do you get any data at all?

  ----- Original Message -----=20
  From: Frank_Kenisky@...
  To: Brian Carrier=20
  Cc: sleuthkit-users-bounces@... ; =
sleuthkit-users@... ; DePriest, Jason R.=20
  Sent: Tuesday, November 28, 2006 9:48 AM
  Subject: Re: [sleuthkit-users] Examining a dvd disk made using a DV =
camera



  Thanks=20

  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.=20

  I've got image scan 2.1 from the fbi but the formats it looks for may =
not include the ones for burned dvds.=20

  Thanks again=20

  Frank Kenisky IV, CISSP, CISA, CISM
  Information Technical Security Specialist
  (210) 301-6433 - (210) 887-6985=20


        Brian Carrier <carrier@...
        Sent by: sleuthkit-users-bounces@...
        11/28/2006 08:21 AM=20
       To Frank_Kenisky@... =20
              cc "DePriest, Jason R." <jrdepriest@...>, =
sleuthkit-users-bounces@..., =
sleuthkit-users@... =20
              Subject Re: [sleuthkit-users] Examining a dvd disk made =
using a DV camera=20

             =20

      =20



  I personally don't know much about the DVD format, but I doubt TSK =20
  will help.  I've used ISOBuster for CDs before and the website says =20
  it works for DVDs as well.

  brian

  On Nov 27, 2006, at 10:29 AM, Frank_Kenisky@... wrote:

  >
  > Not sure if this can be done with sleuth-kit, but I've been asked =20
  > to see if I can recover files from a mini dvd made using a DV =20
  > camera. Apparently it was finalized but now gives the user a disk =20
  > 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
  > =
----------------------------------------------------------------------=20
  > ---
  > Take Surveys. Earn Cash. Influence the Future of IT
  > Join SourceForge.net's Techsay panel and you'll get the chance to =20
  > share your
  > opinions on IT & business topics through brief surveys - and earn =
cash
  > http://www.techsay.com/default.php?=20
  > =
page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV_____________________________=
___=20
  > _______________
  > 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=3Djoin.php&p=3Dsourceforge&CID=3D=
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=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV


-------------------------------------------------------------------------=
-----


  _______________________________________________
  sleuthkit-users mailing list
  https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
  http://www.sleuthkit.org

On 11/28/06, Frank_Kenisky wrote:
>
>
> Thanks
>
> I tried several things and still couldn't see any data.


Do you mean that if you do a hexedit of the disk, all you see are 0x00s?  Or
just that there is no data that you have an application to interpret?

Can you take another mini-dv that you know works properly and see what sort
of luck you have with that?

Maybe dd both of them and compare the hex to look for similarities that
might lead to discovering information about the file system.

Just reading a few articles from a google search makes me wonder if you need
to use tools designed to work with streaming data.  Mini-dv is a tape-based
format, so tools for DVDs and CDs (and hard disk drives) may not work.

What would someone use to forensically examine a DAT or DLT?

> 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.

I'm done with this, I think.

It just gets weirder and weirder, though.

Active File Recovery let me GUI my way into creating a forensic image
of just the partition that it found that looked like a legitimate
operating system.

Sleuthkit was able to work with the resulting image just fine.

Which leads me to unanswered questions, which I will probably never
get answers for.

Why was the partition started on sector 1120 instead of 63?

What was the original server configuration and how did the drive I
have relate to "the other two drives" that were mentioned as being
discarded?

If this was a RAID configuration, what was it so that I could get a
valid partition out of just a single disk?

My conclusion for the lawyers after looking at this drive and an IDE
drive they also sent is: not enough information to provide any
meaningful conclusion.

All my questions, all my work, and all the inconclusive results have
been documented and sent to my manager for approval.

Thanks for everyone's suggestions.

-Jason