Pete
As mentioned it was a bug that was apparent in two minor releases of Encase and a minor bug at that. 99.99% of cases wont rely on the time being right to that accuracy and if they did then a competent examiner would probably double check.
Of course what is interesting is that all your posts are on this thread, you dont seem to want to let the matter drop and your profile records you as an out of work engineer - now I may be totally off the mark and overly suspicious (apologies in advance if I am) but that makes me wonder whether you have been on the wrong side of an investigation where you think this bug was relevant.
… makes me wonder whether you have been on the wrong side of an investigation where you think this bug was relevant.
Out of pure curiosity, what would this - if the guess is correct - change? ?
I mean from a pure "scientifical" or "knowledge" point of view?
This bug (whatever it is/was related to) either was there or it wasn't, and was either resolved or it was not (and this fix - if it was implemented - was either cited in the release notes for later version or it was not), no matter what the reasons asking for information about it are.
@Pete
Personally, I don't think that whining or hinting that expert members of the board familiar with Encase are incompetent will help to get an answer (or better answers). roll
jaclaz
I'm both amazed and disappointed that nobody seems to know anything about this defect.
Well, Guidance release notes are not exactly easy to read or search, or useful even when you do find what you look for. There's no way to search for '24149' and get a hit – you have to read the pages. And they are/were all named 'new.chm' so they tended to get overwritten, unless you were paranoid, and always installed encase in separate directories yourself.
Anyway, the entry for 24149 says only 'IM Archive Parser' Yahoo date/time incorrect.
Nothing more.
Presumably refers to interpretation of logs from Yahoo Messenger, but that's just my guess.
Out of pure curiosity, what would this - if the guess is correct - change? ?
Nothing in relation to the bug - but if this was an expert with an issue I expect the replies already posted would have cut this thread down by about 50%, as it is we see the same person, who "seems" to have an axe to grid, not allowing the thead to die.
I have seen this many times over the years when working for both prosecution and defence, where a suspect fixates on a minor point/bug/whatever which has no impact on the strength of the ecase against him and an inordinate amount of time (and money) is spent going over old ground.
I have seen this many times over the years when working for both prosecution and defence, where a suspect fixates on a minor point/bug/whatever which has no impact on the strength of the ecase against him and an inordinate amount of time (and money) is spent going over old ground.
I see. )
But then, wouldn't the "standard" procedure be to re-process the "original" hard disk image again, TWO times, first with the older version, and then with the one that supposedly fixed the bug (if any) and look for differences in results?
I mean, the guys who (inadvertently) introduced the bug are most probably the same ones that "solved/fixed" it later, there is no guarantee of any kind that the solution or fix has been effective or 100% effective, no matter at which length the bug and it's fix are documented in a change log or release note.
@athulin
Nice to know about the "new.chm" naming, a rather smart approach 8O, if I may, since the documents are "release notes" not including previous history, I mean, a "plain", "normal" changelog is "progressive" includes (logs) ALL changes since at least first public release, that is what "allows" to name it "fixed" as changelog.txt.
jaclaz
Nice to know about the "new.chm" naming, a rather smart approach 8O, if I may, since the documents are "release notes" not including previous history,
Colour me embarrassed – those .chm documents *do* contain past release notes – it's just a question of reading all entries in the TOC. The latest version (6.19) I have even allows me to search for the defect ID – pity I didn't try that one first, as the 6.13 version doesn't do that.
I mean, a "plain", "normal" changelog is "progressive" includes (logs) ALL changes since at least first public release, that is what "allows" to name it "fixed" as changelog.txt.
well … but how did you go from release notes to a change log, or even assume the change log is public?
If you go to Guidance support site (which is where everyone with an Encase license starts researching a question like this), and search for defect 21419, you won't get any hit. It was almost certainly entered as a private defect, which means the details won't be availalble to everyone. In such case, if you want details, you ask Guidance Support for info. And after that I didn't really expect there to be any details in the release notes.
Colour me embarrassed – those .chm documents *do* contain past release notes – it's just a question of reading all entries in the TOC. The latest version (6.19) I have even allows me to search for the defect ID – pity I didn't try that one first, as the 6.13 version doesn't do that.
No need to.
It was actually myself that *assumed* that the .chm's you were talking about were a "better, hyperindexed" (and reserved to licensed customers) version of the .pdf "Release Notes"such as (example)
http//
That are actually "named" after the version
Release_Notes_v615.zip
Release_Notes_v6161.zip
release_notes_v618.zip
that are "normal" "release notes" i.e. with no history since the beginning.
jaclaz