hcso1510
In this article it discussed how does one validate or varify an extraction?? Very easy The examiner will need to compare the data collected from the extraction device to what is on the phone. In a sense, compare the data on the phone with the data from the report and if they are the same, you have achieved validation/varification.
As a forensic analyst should this not be your standard procedure? As mentioned earlier in this thread using two different tools can achieve varying amounts of data. I always used XRY and UFED for my main analysis, and occasionally Oxygen if I knew the handset had issues with either piece of software. I would then check the output against the handset, if it was an old model then you could usually visually verify in about 20 minutes, on newer models a dip sample can be conducted. I usually found that SMS messages were the offending item when it came to an incorrect transcribe by the software.
We should all be wary of relying heavily on tools to do the job for us without checking the results thoroughly. Harlan touches on this very point in Chapter 1 of WFAT 3e.
I usually found that SMS messages were the offending item when it came to an incorrect transcribe by the software.
Couldn't agree with you more. Indeed, two handsets with identical model numbers but one may have had upgraded firmware can introduce different results too. Before validation, try running simple some experiment first
http//
We should all be wary of relying heavily on tools to do the job for us without checking the results thoroughly.
Perfect.
Harlan touches on this very point in Chapter 1 of WFAT 3e.
This is a good example of how it is important to ensure an examiner acquires as broad a range of understanding from those sharing experiences relating to
(1) validation
(2) verification
Hash Value
It is equally relevant to understand hash values from the point of view whether acquiring data can reproduce an identical hash value or a different value the second time around when conducting a further logical read from the same exhibit DUT.
SIMIS, in this later version in its evolving development, provided a good lesson to learn about hash values. Introducing hash values to SIMIS isn't the story but about what happened then when an examiner used it at that time. Prior to hash values being included as a feature in SIMIS there was disquiet among law enforcement users that exhibit numbers etc case references kept changing and therefore they wanted to amend the report header details but after the data acquistion process from the exhibit DUT had taken place. So the first read would produce one hash and the second read with changed report details would produce another hash value and further re-reads of the exhibit DUT would constantly generate newer hash values.
An important aspect with hash values is being able to explain the reasons for any change and then verifying the findings uncovered during validation trials.
With that said, I glanced at the document provided by CFTT posted by EyezOn and it appears validation is confirming..
You can also look at the Wikipedia article cited somewhere in this thread (or was it a in blog post cited?). It's rather verbose, but I think the gist of it is that while the goal of both verification and validation is to ensure that the product is as documented, verification is typically an activity performed by the producer of that product, before it is delivered, and validation is typically performed by the recipient of the product, after it has been delivered. And also validation includes verifying that the verification process did the right thing (assuming it it was successful, of course).
In other contexts, verification may be defined as the tests performed to decide if a particular development phase is over, while validation is the final tests to ensure that delivery may take place. (This is pretty typical for software development projects.)
And I have, in a previous life, seen a definition of the term 'validate' that came very, very close to 'verification' in the first sense above. It was a definition approved by the CEO , so that is what that word meant to that particular company.
That is, it's really no good trying to find what these words mean, without knowing who asks for them, and what *that* person or organization means by them.
To someone deciding if a new release of Encase or FTK is good enough to be used for live cases, the most appropriate term may be 'validation'.
To someone deciding if a particular analytical conclusion is correct, it seems 'verification' is ´better.
To someone trying to decide if conclusion A, based on a report from tool X, is valid, both terms appear appropriate, depending on if the focus is on the output from the tool, or if it is on its suitability to support the conclusion.
Checking Tool X against Tool Y has no place in this, unless Tool X has indeed passed a validation on that particular point. If it hasn't, it's very much like Dirk Gently's method of navigation in unfamiliar places look for the first person that appears to know where he's going, and just follow him.
Or, say, like using Windows Timestamp Interpreter 2.0 to test ACME Timestamp Decoder 1.0 if both translate the Windows FILETIME value 0 to 'Not a valid date' or 'Illegal timestamp', does that mean that is the correct value? Not really – it's just hoping that someone else got it right, but without really bothering to verify it.