Notifications
Clear all

smart VS encase

16 Posts
9 Users
0 Likes
1,333 Views
(@Anonymous)
Posts: 0
Guest
Topic starter
 

anyone have any strong opinons? i personally would rather use smart as i feel that i have more control over my searches and have more room to work within if you know what i mean? the price of encase 5 is kinda painful too…

 
Posted : 07/12/2004 8:37 pm
 Andy
(@andy)
Posts: 357
Reputable Member
 

Depends what you are more comfortable with, it’s a personal choice thing. If you use Linux and are comfortable then SMART is the smart choice (sorry :D). I only wish I had time to learn and use SMART more (I have a demo – but can’t justify spending time to learn it at the moment). I do like Linux, but I am no where near as competent in it as I am Windows.

One thing to consider is – will the investigations you conduct be on mainly Linux machines or Windows? If it’s the latter then it might be wise to get to grips with EnCase, and examine in Windows. If you extract files you might need to investigate them in the same environment as your suspect machine. For example MS Word documents, Access, Excel are all best viewed with the same software. Extracting them into Linux might not give you consistent results and/or the formatting may appear wrong.

Also consider your customer(s), they may be more familiar with Windows and some of the concepts you need to explain may be a little alien to them or require translation.

I have mainly used a Windows OS – so I am more comfortable in this environment and use EnCase…….However, I am at present on a FTK boot camp course, and can say I am very impressed with it. I will be using FTK more and trying to get to grips with it as much as I am with EnCase. It appears to have everything EnCase has and perhaps a little more, such as indexing for text searching which is fantastic, and has better support for email investigation.

Andy

 
Posted : 07/12/2004 10:08 pm
(@Anonymous)
Posts: 0
Guest
Topic starter
 

hi,

sorry for the late reply it's been really busy lately. well, the way i see it - if you were to go on-site with the smart linux cd, essentially all you do is boot the suspect system with the smart linux cd and mount the suspect drive as read-only, then mount with your target drive (let's assume an external firewire drive) as read-write and perform the acquire. even better, if your only purpose was to extract a few files from the suspect system, let's say .doc files then you can do cool stuff like boot from the linux cd and load smart linux to ram if you have 512mb ram or > and use the cd-rw on the suspects system to burn the files off without having to carry any hardware with you other than your smart cd and a blank cd or two. i do see where you are coming with the fear of not being able to perform the same tasks in windows, however you can boot back into windows to use the tools you are know already, or simply install vmware or wine on linux and run your win32 applications native. the bottom line is the boot cd itself is so simple then you can't really screw anything up.. if it's for your lab machine then you could install a simple to maintain build such suse or fedora.

anyhow enough </rant> from me. i just personally think encase blows for so many reasons that it should be reason enough to want to learn the other side of the fence incase you are ever called to the stand to defend yourself against someone who is aware of the many flaws of using encase for acquires.

Depends what you are more comfortable with, it’s a personal choice thing. If you use Linux and are comfortable then SMART is the smart choice (sorry :D). I only wish I had time to learn and use SMART more (I have a demo – but can’t justify spending time to learn it at the moment). I do like Linux, but I am no where near as competent in it as I am Windows.

One thing to consider is – will the investigations you conduct be on mainly Linux machines or Windows? If it’s the latter then it might be wise to get to grips with EnCase, and examine in Windows. If you extract files you might need to investigate them in the same environment as your suspect machine. For example MS Word documents, Access, Excel are all best viewed with the same software. Extracting them into Linux might not give you consistent results and/or the formatting may appear wrong.

Also consider your customer(s), they may be more familiar with Windows and some of the concepts you need to explain may be a little alien to them or require translation.

I have mainly used a Windows OS – so I am more comfortable in this environment and use EnCase…….However, I am at present on a FTK boot camp course, and can say I am very impressed with it. I will be using FTK more and trying to get to grips with it as much as I am with EnCase. It appears to have everything EnCase has and perhaps a little more, such as indexing for text searching which is fantastic, and has better support for email investigation.

Andy

 
Posted : 30/03/2005 6:59 pm
(@robogeek)
Posts: 17
Active Member
 

I've never had a successful Encase argument as far as any problems aquiring evidence - in fact I've never had a challenge to the validity other than chain-of-custody arguments.

But I have never seen smart until this post. I use other linux tools for non criminal cases and if its a civil case I use alot of my own little goodies.

Unfortunately I won't pay $2000 to evaluate software and see how it holds up under scrutiny.

I'd like to hear from some people who have court tested experience using it.

 
Posted : 31/03/2005 2:47 am
 Andy
(@andy)
Posts: 357
Reputable Member
 

i just personally think encase blows for so many reasons that it should be reason enough to want to learn the other side of the fence incase you are ever called to the stand to defend yourself against someone who is aware of the many flaws of using encase for acquires.

Perhaps you’re not using it correctly?

EnCase is regularly accepted in courts worldwide.

Andy

 
Posted : 31/03/2005 9:13 am
(@gmarshall139)
Posts: 378
Reputable Member
 

Nor have I ever heard of an issue, particularly with the acquisition function. If you have any details of an examination being struck down for any reason related to the use of Encase I'd like to hear about it.

 
Posted : 31/03/2005 2:04 pm
daveg
(@daveg)
Posts: 9
Active Member
 

Greg

There was a serious problem with EnCase when acquiring a disk.

If the disk you were acquiring had a bad sector, Encase didn't deal with it correctly. So your acquistion hash was different EVERY time you acquired the disk.

So an independant expert verifying your work would have a different md5 hash and would claim in court that YOU planted evidence. Or you mixed up disks with a different case, or whatever. Case dismissed.

Dave

 
Posted : 02/04/2005 7:36 pm
(@gmarshall139)
Posts: 378
Reputable Member
 

You are correct in that there was a version [4.18] with a bug relating to dos disk to disk (local) acquisitions. That has since been fixed. There are some other issues though that may result in the same effect.

It's not that Encase didn't deal with bad sectors correctly, it just doesn't deal with it the in the same way as other applications. When encase encounters a bad sector it pads that cluster with 00 hex. Therefore no data will be found in that cluster. If another examiner acquires with a different method, one that doesn't treat bad sectors this way, there will be a different md5 hash. That's why examiners need to document the details of the acquisition process.

To further complicate matters it has been found that read errors are not reported when acquiring through USB and Firewire devices. Thus if an examiner uses two different acquisition methods with the same software version there may still be differing md5 hashes. Encase version 5 allows the examiner to taylor how they want the program to deal with bad sectors. More detailed documentation will be required.

In summary I think there are a number of reasons that different acquisition hashes may be reported. Not the least of them is that an errant magnetic field "flips a bit" or two on the drive between the two examinations. It is also possible that bad cables (or just too long) on someone's machine cause read errors.

It's a good point you bring up and one that all examiners need to know how to explain on the stand no matter what tool you use. If you use DD, and an opposition expert uses Encase and has a different hash you may be accused just the same of altering data. Incidentally I've always heard it's good practice to archive the examination software along with the case files. I suppose it's true due to this very issue.

 
Posted : 03/04/2005 12:41 am
daveg
(@daveg)
Posts: 9
Active Member
 

Greg

I was not refering to the DOS acquistion bug….

Every version of Encase prior to about 4.19a didn't even report 'bad sectors'…it certainly did not "encase encounters a bad sector it pads that cluster with 00 hex."

I proved this. Each time I did an acquistion or a preview & hash, on a drive with bad sectors, I got a different md5. Because of this extreamly serious fault with Encase we started using FTK to create Encase images.

My advice to you is make sure you use 4.20

Dragging this thread back on track 😀 who is going on the SMART training in Reading, UK?

 
Posted : 05/04/2005 8:49 pm
(@gmarshall139)
Posts: 378
Reputable Member
 

Take a look at the NIST test results of various imaging tools: http://www.cftt.nist.gov/disk_imaging.htm

Encase is tested along with safeback and dd. Unfortunately smart was not. Multiple drives were among the test sample including those with known errors. In all cases Encase correctly identified those errors, as did safeback, but not dd. These results are in line with my own experience. DD is useful however, as sometimes a drive is so corrupt that Encase wont image it, or at least not for several days. DD is a great fallback in those cases as it just chugs through errors and all.

So to get back on track I prefer Encase for most acquisitions, but also use dd as a fallback

 
Posted : 06/04/2005 2:18 pm
Page 1 / 2
Share: