±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 3 Overall: 36632
New Yesterday: 7 Visitors: 133

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

Imaging software

Discussion of computer forensics employment and career issues.
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page Previous  1, 2, 3, 4, 5 
  

keydet89
Senior Member
 

Re: Imaging software

Post Posted: Feb 15, 06 21:14

andy,

I don't see how this is off-topic at all. In other threads, I've brought up the need within the community for repeatable, verifiable testing.

How does one verify someone else's testing without knowing the specifics of the test?

Harlan  
 
  

farmerdude
Senior Member
 

Post Posted: Feb 16, 06 06:58

GREG,

The E01 is proprietary. Guidance Software could just as easily instruct the other companies to cease and desist just as NTI did with Safeback and AccessData (and hence, no version 3 support in FTK). When I say proprietary I mean with respect to the owner of the format. True, Andrew Rosen created the format in Expert Witness for Macintosh back in the day and then Sean used in Expert Witness for Windows. However, it would see it is a format developed and promoted by GS. I wonder if they have any sort of legal holding on it?

Yes, I was confused ... my old age ... too many days in the hot sun .... Guidance Software made changes with their Case Files, making them incompatible. That's what it was! Thank you for correcting and alerting others reading this thread to my error. I don't know which is worse, an image format incompatible or the case work. One was just pure time to acquire. The other was many hours of analysis and correlation! LOL

It's good to hear that GS came up to speed on Version 5 - instead of throwing away 32KB for a read error it does what other commercial and free programs do, and just toss the bad sector(s). That was a huge error on their behalf for many years.

In the past when you wrote and E01 data was compressed even if you said no compression. I believe this thread exists on the EnCase UBB (or it did when I was a member there back in the day). If you were to look at the E01 side by side with the original you wouldn't match up sector by sector.

I use SMART for Linux for acquisitions (image and cloning). I love the way it aquires, handles errors, and authenticates. Via a terminal I use a variant of 'dd', but I don't go through the block layer so I don't have to worry about the odd sector issue and I have faster transfers.

Testing will show you which is fastest. The most important aspect is to be very well versed in a few different methods because on-site routines become journeys into the unknown and fun! Crossover cable, gig ether, and see the results for yourself. Aside from this, I almost always acquire using 1394 800 ... doesn't eat my CPU ... doesn't tend to slowww down like USB does ...


Almost met me for some training, eh? Ahh, but then someone, perhaps a former student, set you straight! LOL Drop me a line anytime, stop by my site, venture into a training session, etc. I'll be at the Southeast CyberCrime Summit here end of February.


Which Linux file system couldn't FTK interpret? I know Eric has support for both ext2 and ext3. A glitch or another Linux file system type?


ANDY,

I think we'd all like to read more about your testing. What's great about testing is everyone gets different results. Smile Obviously I've found Linux to be faster than EnCase ... or else I wouldn't be using it to acquire in the Enterprise! LOL

The first problem I see, aside from not knowing all of the specifics, is you used GRAB and Helix. You used the 2.6 kernel which is slower than the 2.4 kernel for acquiring. At least in my testing and validation runs. (Which is why THE FARMER'S BOOT CD uses 2.4, at least one reason).

Secondly, you used GRAB. Not knocking it (it's based on A.I.R., which is actually simpler to use and seemingly more stable as there have been issues with GRAB recently from user's feedback) but stick in the terminal with 'dd'. Or at least for one test run.

Third, you can see one area of slowdown. GRAB is using 'dd' to acquire, then 'md5sum' to authenticate. I would be curious to see this same test run using GRAB and dcfldd, wherein the acquisition and authentication are simultaneous. OR, using SMART for Linux and GRAB and see if there are time differences.

Oh crap, and then there's another piple to "efense-split" (whatever that is)! So now we have a third pipe and binary .... That's the one heck of a command, Andy! LOL

Please, try again with 'dd', 'dcfldd', and 'SMART'. I'll do the same.

regards,

farmerdude  
 
  

gmarshall139
Senior Member
 

Post Posted: Feb 16, 06 18:45

- farmerdude
Almost met me for some training, eh? Ahh, but then someone, perhaps a former student, set you straight! LOL Drop me a line anytime, stop by my site, venture into a training session, etc. I'll be at the Southeast CyberCrime Summit here end of February.


Nothing like that at all, but now you mention it maybe I should ask around! I had plans for the cybercrime summit, but it looks like it will impossible to get away for another week any time soon.

- farmerdude

Which Linux file system couldn't FTK interpret? I know Eric has support for both ext2 and ext3. A glitch or another Linux file system type?


I was using an older demo version. It's been a while since I looked at FTK.
_________________
Greg Marshall, EnCE 
 
  

farmerdude
Senior Member
 

Re: Imaging software

Post Posted: Feb 21, 06 01:28

When testing it's really only beneficial to have a level playing field. For acquisitions, this would typically mean the latest versions of the tools you're testing/comparing. Try with the latest version of FTK to see if your results differ.

regards,

farmerdude  
 
  

bobby1041
Member
 

Re: Imaging software

Post Posted: Mar 22, 06 22:58

- arashiryu

*DOS app: Ghost can be used but I would recommend against it unless you have no other choice left. There is a switch in Ghost that you can specify to get a sector by sector copy. I assume you have a bootable floppy disk. Make sure the Ghost command in autoexec.bat has the switch included for sector by sector copy.



Ghost does do a sector by sector copy if you use the -ir switch.  
 
  

PaulSanderson
Senior Member
 

Re: Imaging software

Post Posted: Jun 05, 06 14:50

No one has answered farmerdudes request for justification for a proprietary tool so I'll do a quick off the cuff comparison. Note that these are my view points and are based on my requirements and to some extent my knowledge of data recovery.

Most of the above is sort of hinged encase way as I no longer use SafeBack - I don't understand version 3 - they have gone down the route referred to in point 4 below.


What's bad about proprietary tools

They are proprietary(1)
Difficult to use third party tools on image(2)
Difficult to authenticate with a third party tool(3)
Image format may change to something that can not be 'used' by third party tools(4)

what's good

Has built in authentication (hash)
'Seemless' support if appropriate proprietary tool is used
embedded acquisition details (user, media, errors)
image is checked against inbuilt hash every time it is accessed(5)
More recoverable than raw formats(6)



On a personal level I am happy with dd images and I am happy with proprietary. The major factor for me with my proprietary format of choice is the recoverability - although not a design issue it has proven invaluable (and a huge money saver) on a case where a drive failed on the way back from an on-site imaging session. There had been no opportunity on site (covert and time limited) to take a back up of the image. Data recovery when back at the office allowed me to recover on a block by block basis and even though the image was fragmented on the disk I was able to recover each portion and verify the CRC and then join the pieces together and verify the hash.

Probably the most importnat issue is understanding the benefits and limitations of the software you wish to use in conjunction with the image format you want and make a choice based upon that.

n.b. all of the above is subject to change Smile




(1) The format may be proprietary but converting to a dd image is straightforward - I have had tools for this for a number of years - Craig Wilson is about to release one and it can also be done from within encase.

(2) I generally use Encase, FTK and winhex (in no particular order) all of which currently understand encase - so this one only holds if your preferred tool does not support it. If I had a need to investigate with something else (never needed to yet) then I would convert

(3) Winhex, FTK, Crag Wilson, Me and I am sure Andy Rosen (to name a few) can authenticate easily enough

(4) If this happens I will stop using it.

(5) On one occasion an error on a previously good image whas the first indication I had of a failing drive

(6) I have been asked in the past to recover an encase image from a disk that had gone u/s (and had one drive fail on me before having had chance to archive). I could utilise my knowledge of the file format to ensure a full verifiable recovery in both instances. Had this been a dd image the chances are it would not have been fully recoverable.
_________________
Paul Sanderson
SQLite Forensics Book
www.amazon.com/SQLite-...entries*=0

Forensic Toolkit for SQLite
sandersonforensics.com...for-SQLite 
 
  

zyborski
Member
 

Re: Imaging software

Post Posted: Jun 09, 06 22:25

As Paul says, both methods have their pro's and con's.

IMHO - whats really needed is an accepted and accredited open source forensic image format which includes all the 'features' given to us by the commercial tools (such as error checking, case notes, aquisition details, compression, etc) without the requirement for developers to reverse image (and risk possible litigation) before they can add support to their own software.

Obviously, this image format would need to be understood and endorsed by all the major tool manufacturers to aid compatability and acceptance.

Forensic tools could then be developed (by both companies and individuals) which didn't require an intermediate conversion step to be performed before the tool would function as is the case with the current eo1 to dd issue. Perhaps this might also also better cross platform tool development?

There are already a few individuals & organisations offering solutions including this.

Not sure it will happen though.....

Kind Regards
_________________
Zyborski 
 

Page 5 of 5
Page Previous  1, 2, 3, 4, 5