Recovering Deleted Files
Below are links to “How To” guides of EnCase Videos. The Videos all made using EnCase 6.10 and are based on NTFS drives
Partition Information in the MBR
What is File Slack?
This article looks at file slack, where it is, how to find it, and includes a video guide of how to view this data in EnCase 6.10
Requirements
To understand File Slack, one must first understand the basic concepts of Cluster and Sectors.
This article is based on the assumption that the reader understands these concepts. It is also written with the assumption that the hardware under consideration is a standard windows hard drive, with sector size of 512 and a cluster size of 8 sectors.
Clusters and Sectors
As the operating system can only address clusters, rather than sectors which hard drives can, it means that files are stored on a hard drive in units of clusters and not sectors.
Examples:
A 5000 byte file, takes up 9 sectors, however the operating system will allocate the file 2 clusters (16 sectors), as it does not fit into 1 sector. 2 Sectors is 8 KB
A 2500 byte file will fit into 5 sectors, however the operating system will allocate the file 1 full cluster (8 sectors), which is 4 KB
A file which is 10,000 bytes will be allocated 12 KB – 3 sectors.
Different Sizes
From this it can be seen that a file has two different sizes, the logical file size the actual size of the file and the physical file size, the size given to the file on the hard drive.
The physical file size is always greater than or equal to the logical file size (ignoring resident data for the moment).
File Slack
File slack is the difference between the physical file size and logical file size.
E.g for a 5000 byte file, which is given 2 clusters (8192 bytes), the file slack will be 8192 – 5000, which is 3192 bytes. The file slack should always be less than 1 cluster (4096 bytes).
As file slack is literally the space on the hard drive between the logical and physical file size, it means that anything that was in that space before become file slack. As a new file is created by overwriting unallocated space (even if it means deleting a file immediately before the request to write) this means that file slack is essentially old fragments of unallocated file space (RAM slack is not being discussed at this point).
This means that file slack can contain anything at all, from fragments of web pages, emails, and even complete small pictures, to junk text. It is more often than not the latter, however complete EML files, and thumbnail pictures have been recovered than can prove an entire case.
Below is a video showing file slack, using EnCase 6.10. Encase is better at viewing this type of data than FTK.
Encase Forensic, produced by Guidance, is currently on version 6.11 (at the time of publishing). Version 6 was first released in late 2006.
Version 6 has attempted to gain market share in the areas EnCase 5.x could not handle previously – namely email handing and indexing.
Guidance have done this by adding Stellant at the backend, to try an handle compound files and indexing better. Stellant is used by many other tools, not least of which is FT – the arch rival of Guidance
The first versions of EnCase Forensic 6.x, simply did not do what it said on the tin. Attempting to use the indexing feature was utterly futile, cases crashed, time was wasted and and anyone who paid for the upgrade to EnCase 6.0 no doubt felt cheated, again. To be fair the launch of EnCase 6.0 was better than appalling launch of FTK 2.0 (it could hardly be worse). But even Encase 6.11 still does not have the simplicity of use that FTK 1.x has (in relation to indexing emails)
But, Guidance are nothing if not consistent. Regular users of Guidance Software know that the first few versions of EnCase are never going to be stable, they will have bugs and flaws in them, which we, the customers, are the beta testers for.
By EnCase 6.10 the product had started to become far more stable, emails could be expanded and searched – though not through indexing (I would leave this to EnCase Version 7)
The scripts and case processor is effective and easy to work with, but the registry viewer is still poor compared to “Registry Viewer” by Access Data, which came as standard with FTK 1.0.
The disk view, transcript view, record view, search hit view, book marks view, entries view, etc, are all individually well presented; however the huge array of views can be confusing.
Overall EnCase 6.x is better than EnCase 5.x, though it isn’t as good as the marketing says it is.
Below is a very basic video for keyword searching within EnCase
Following on from the previous articles on the MBR, and the MBR Partition Tables, and a video on how to identify the first partition from the MBR, below is a video showing the MBR via EnCase.
Below is a guide on trying to locate the MFT (Master File Table) and MFT Mirror, from the Volume Boot/Boot Sector/BPB
Following on from the articles on the MBR, the MBR Partition Information, and the video showing a general examination of the MBR , below is a video showing how the location of first partition can be extracted from a manual examination of the MBR.
Following on from the previous articles on the MBR, and the MBR Partition Tables, and a video on how to identify the first partition from the MBR, below is a video showing the MBR via EnCase.
When EnCase is used to image a hard drive or the like it produces an image file(s).
The file name is provided by the users, e.g Drive1, A001, or the like, but the extension is automatically named E001.
Encase, by default, breaks the image file into 640mb chunks (this is for historical reasons to allow the image to fit onto multiple CDs), therefore for a standard 80 GB hard drive there will be numerous files. The EnCase image format handles this by changing the extension not the file name.
For example, if the first file in the sequence is A001.E01, then the following files will be
A001.E02, A001.E03, A001.E04, etc. Despite the changing extension the files are all of the same format, and when opening the the image through EnCase, by pointing at the first file, it will automatically look for the files in the same directory. Despite the changing extension the files are commonly referred to as “E01 files”
It is reported that the EnCase image format is based on the ASR Data Expert Witness Compression .
The image of hard drive, by Encase, is a complete bit stream of the acquired media. However, for security reasons the the E01 files contain additional information to prevent changes to the file.
The front of the first E01 file contains “Case Information” – this is information entered into EnCase, by the user, prior to imaging, e.g name of person, case name, description of media, etc, and information automatically created, e.g date/time, version of Encase used, operating system Encase is running on, etc. Then within an EnCase image, at every 32 KB (64 sectors – 1 sector is 512 bytes), there is a CRC checksum, i.e if there is an error within the 32K this will be detected by the CRC.
At the end of the image (i.e in the final E01) the MD5 value for the entire bit stream is stored.
Access Data’s imaging tool – FTK Imager can also produce Encase/E01 image files.