harlan, you mentioned that it would be easy to blow a case out of the water due to the lack of advanced understanding of Encase scripts….i thought that encase was accpeted in a few different legal systems such as the UK/USA, so therefore if many examiners are relying on these scripts then surely a lack of knowledge of how to edit them for example or interpret them would not be seen as a weakness in the examiners knowledge as far as the evidence and investigation is concerned ?? and you also said this may depend on the case, could you give such an example where a case may fall over or evidence rendered inadmissable in a court of law because of this?
thanks
Alan,
What I was referring to is the fact that few EnCase examiners really know what's going on when they run an EnScript, and they only "see" the evidence in a case that the EnScripts "show" them. For many cases, I am sure that this is sufficient, but what happens when someone has just a little bit of knowledge and uses it to do something or hide data in some way that isn't "seen" by EnScripts?
There are presentations available now that instruct the attendee on methods for using an EnCase-certified examiner's training against them. One of the methods listed is to save data in a file that starts with "MZ" in the first two bytes, and has an .exe or .dll extension. This data is then not picked up by file signature analysis.
Another example would be to "touch" a file to set the MAC times askew, using a command line utility. Doing this one would file may be enough to case doubt as to the validity of MAC times on other files.
Re blowing a case out of the water…if a savvy defense attorney required that the version of EnCase and copies of all EnScripts be provided during discovery, and had a technical expert available, there may be enough information that was missed to cast doubt on the overall process.
My point is that too few analysts know (or seem to care) what is going on "under the hood". There is a gap between what they "see" in the analysis tool and what is actually there on the system they are analyzing…and this gap can vary.
H
thankyou, a very interesting post!
alan
Alan,
What I was referring to is the fact that few EnCase examiners really know what's going on when they run an EnScript, and they only "see" the evidence in a case that the EnScripts "show" them. For many cases, I am sure that this is sufficient, but what happens when someone has just a little bit of knowledge and uses it to do something or hide data in some way that isn't "seen" by EnScripts?
There are presentations available now that instruct the attendee on methods for using an EnCase-certified examiner's training against them. One of the methods listed is to save data in a file that starts with "MZ" in the first two bytes, and has an .exe or .dll extension. This data is then not picked up by file signature analysis.
Another example would be to "touch" a file to set the MAC times askew, using a command line utility. Doing this one would file may be enough to case doubt as to the validity of MAC times on other files.
Re blowing a case out of the water…if a savvy defense attorney required that the version of EnCase and copies of all EnScripts be provided during discovery, and had a technical expert available, there may be enough information that was missed to cast doubt on the overall process.
My point is that too few analysts know (or seem to care) what is going on "under the hood". There is a gap between what they "see" in the analysis tool and what is actually there on the system they are analyzing…and this gap can vary.
H
I don't believe that it is that they don't seem to care, most people just don't know programming languages, or if they do they are now obsolete. Not everyone can be a programmer, and I would bet everything I own that because someone doesn't know about an enscript that they would lose their case, regardless of a technical expert on the other side.
It's not really so much about programming, because if you know *what* you're looking for, you can ask EnCase or someone else to help you out.
All I'm saying is that the EnScripts only show you what they're programmed to show you. If you know what to look for, you'll look beyond what the default EnScripts will show you…
Furthermore one should always keep in mind that each piece of software may or may not function as intended.
I've made the experience that at least some EnScripts have problems for example with decoding timestamps.
So even not having programming knowledge an examiner should at least be able to confirm the result of such a script by other means - and for that it is necessary to know what the script is supposed to do.
We have a similar setup as clownboy. But we mainly use FTK for our examinations and spot-check them against with WinHex Specialist. I have not used EnCase, and see no reason to yet. One disadvantage of the FTK indexer is that it indexes files based on "native" format. This is a big deal on their forums. For example, it will not find keywords in SCRIPT tags of an HTML page. We were able to hide data in a word document from the indexer too. SO the Live Search must be used in those cases, which takes away a big advantage of FTK.
My $0.02.
A
We use EnCase and FTK on a daily basis in our labs.
I have to say that as a whole, FTK is more user-friendly and is thus viewed as a "superior product". We have clients come into our offices to examine, tag and request a production of certain documents on a frequent basis. We typically set them up with FTK, depending on the specific case, because of its slightly better ease-of-use. EnCase really confuses the average person.
I agree with the replys here that state there is no 'magic' single solution to every specific case that comes through the door. A combination of many tools are required to get the most of your processing. I've even found that a knowledge of uncommon or even totally unrelated material can often come in handy in the processing of forensic data. Sometimes it comes in extremely handy to have a few spare IDE cables, a roll of electrical tape, a soldering iron and a custom-made Linux live CD in your toolkit.
The Indexing of data in FTK is an advantage in time-constrained situations, but can hamper the gathering of certain information as mentioned by ac_forensics above. EnCase is generally more powerful, but we have found the Live Search function to be disappointingly lacking in certain functions that one would expect of a search tool.
Also, just a side note, neither FTK nor EnCase seem to be entirely stable no matter what hardware we put them on. FTK will constantly seize during an Index operation and crash, often with little or no clue as to why. EnCase will freeze up during a Live Search or loading of a saved case sometimes for up to several hours before unexpectedly terminating. Needless to say this is extremely frustrating at times. Those are hours of my life I will never get back. I can't wait to experience the joys I've heard of EnCase v.6!
Also, ac_forensics, would it be possible for you to divulge what data you hid in a Word document and the process by which you achieved this? I'd be very interested to take a look at this problem in particular.
A thread started by a fellow Geordie!
Anyway, as it has been mentioned a number of times in this thread; you need to have a kit bag that is stuffed with tools for the different environments into which you will be placed to undertake forensics and/or expert witness work.
For example
- UTK/FTK/PRTK/Rainbow tables (Accessdata)
- Encase (Guidance)
- Winhex Forensics (X-Ways)
- Decompilation/assembler threads IDA Pro
- Decompilation/UXP unpacking, PE Explorer
- IELogs Digital Detecive
- EDM HotPepper
- Notepad
- Adobe acrobat
- ETL + database connectors (for SQL based analysis)
etc
etc
etc