Spcavana,
I apologized…what else do you want?
If you feel that I'm being rude and "sharpshooting", then why are you doing the same thing to me?
Please don't continue this in the forum.
If an analyst views a file within a preview pane in EnCase, it would give away the real content of any obfuscated file, no matter of the header or the footer.
One question raised and not yet answered (I think) - the red text. The red text is cluster slack.
Hope that clears things up for you.
Sounds like a bug in the signature analysis to me.
Have you looked at the sectors containing the file in hex view? Check out whats at offset 0. That'd be my first move.
It's not necessarily a bug - if the file contains hex FF FF FF FF at the beginning, the signature analysis will take it to be a DOS Driver.
If that just happens to be the start of the file, it's a mis-hit, not a bug.
I found this file named serials.txt with signature of *DOS System Driver. The file extension is .txt.
This is a kind of read the manual question. Check your EnCase Users Manual … chapter 9 it should be … where file searching is covered.
In short, the * indicates that there's a mismatch between the file extension and the file signature the extension does not match those listed with the signature pattern.
The 'DOS System Driver' signature (as already mentioned) is '0xFF 0xFF 0xFF 0xFF', and the expected signature for this kind of header is '.sys'. Anything else will cause a '* DOS System Driver' message.
This may not mean a thing – EnCase file signatures scheme is so closely tied up with the assumed correct use of file extensions – all .doc files must have file signatures this-and-that – and file signatures are restricted to just a few bytes at the head of a file that it's useful only in certain circumstances.
I suspect 0xFF in this case might be a graphics character – probably part of some kind of border arangement aaround a title – and may make better sense when printed using the right kind of character table.
The preview of the file is unreadable.
Don't know 'preview'. In EnCase terms that's what you do when you look at evidence before you have acquired it to evidence files. What tab/tabs in the View pane are you looking at? If you can restore the file, you are probably just looking in the wrong place, or with some unsual code table set up (check some other Text Styles). Alternatively, your restore program restores the wrong data. Check that file size > 0.
This is interesting, because surely a .txt file can have any 'header' (as someone has said) which to me would indicate that this file should 'Match' from the signature analysis. I always thought EnCase read the extension first, ie. without signature analysis the only graphics you can see in gallery view are those with the appropriate extensions, which in turn denote the 'type'.
If the entire contents are entirely red, would that not indicate that it is overwritten and you are seeing slack from another file ? Or if it is FAT are you seeing an over writing directory entry ? Thirdly, I dont know if this is correct but if EnCase see's a file as 0 bytes in size will it mark all of its contents as 'slack'.
Times like this call for either breaking out your secondary tool or some manual parsing or invariably both.