Deleted Partitions & EnCase v7 Partition Finder

Using EnCase V7, I ran partition finder. The search result showed 6 different possible starting partitions. Most curious, all but one are NTFS, but there is also a FAT partition showing.

Check up on what partitions the partion finder actually recognizes. It may be that the list is shorter than you think – I know that the list of partitions in the v6 version was much shorter than I thought.

My thinking, and if I am wrong, please correct me, these were partitions which were used at one time, deleted, then new partitions added later, either through a format, or just someone playing with the partition sizes.

Or … they are files or programs that for some reason contain sectors that look just like partition data. Could there be deleted files corresponding to virtual disks in there? Partition finder may not be able to tell a real partition from one inside a deleted virtual disk image. Or do you have a deleted fdisk.exe (or similar software), which contains data that looks just a master boot record?

What does partition finder actually do? Do you know? Can you find out? In v6 it was very simple-minded, and false positives were only to be expected. Can you identify any of the hits you have received as false positives?

My question, how do you know how to add user partitions so that I have a workable evidence drive?

Do you have any proof that you don't already? Unused space could be an indication, but it needn't be a real one. Anyway, it's a question of examining the data you've got has the partition finder identified real partitions, or is it just data that happens to look like a partition? If you add it, and EnCase can't find anything in there, it may not be a partition. And even if EnCase does find something … can you run something like chkdsk, and get a clean bill of health on the file system? If you can, you probably have a partition.

Also … what software platform are you looking at? Up to and including WinXP partitions created with Microsoft software were positioned according to various rules, such as being allocated on track boundaries. If you have Vista or later, you probably have similar rules (perhaps that a partition only is allocated on Gb boundaries … or something like that. ) Can you use those rules to check if you have found the genuine or spurious partitions?

Do I run my investigation using a partition, then delete that partition, add the next and work that drive?

Once you are convinced that you have a partition, yes. But you should be making that decision, not some piece of software.

What partition-finding software other than EnCase have you tried out?

Is there some way I could find out the when the last partitions were created or deleted?

You may want to read up on partition table structures. If you haven't, find Brian Carrier's book on forensc analysis of file systems. Short answer is that unless the partition table actually registers the creation/deletion date, or it is present in some log inside the file system, you can't. All you can get is the earliest timestamps from the file system inside the partition.

Is it possible user had software which hides an active partition, which also keeps it hidden from EnCase?

There's always a technical possibility. Is it a real possibility? Is there any evidence from Windows Registry or elsewhere that the operating system (I'm assuming you're examining a Windows system) has seen more partitions that you (or EnCase) have found?

Will EnCase read hidden partitions whether or not the partition is hidden from other users?

Um … if you are referring to hidden partitions in the MBR-partitioning format, yes it does. (Wouldn't be much use if it didn't.)

I'd start with the partitions that are in place. If the unused space is very large, I'd examine registry for traces of additional mounted partitions, and use that as starting point for additional examinations.

I would not start on a 'could there be a partition even if I am not seeing one?' trek, unless I had a rule that told me how many hours I could spend looking for something that I had no proof was really there. That rule needs to be written down *before* you start looking, or you risk wasting a lot of time over nothing that could have been used in better ways.

Thank you. The reason I believe there are other partitions is the large amount of Unused Disk Space. It is well over 3 million sectors of a 30 million sector drive. I remember the instructor harping that all the drive should be accounted for before examining. I'm sure the numbers don't always work out even, but they certainly shouldn't be that far off.

I do believe several of the partitions found are false positives, when I try to define the partition, I get no file structure. However, there are link files showing me locations and drive serial numbers within some of the partitions that were identified with the partition finder. I feel certain the partitions did indeed exist at one time, but they are not there now. Unfortunately, I have no other tools to run against it, and I don't know of any, but if you could suggest one, I would be appreciative.

My question for the hidden partitions had to do with Tweak UI. A friend showed it to me once, and he uses it so he can hide certain things from his kids on the computer. Will EnCase identify partitions hidden with tools such as that?

Unfortunately, I have no other tools to run against it, and I don't know of any, but if you could suggest one, I would be appreciative.

Parsing the master partition table and volume boot records is not that hard. Pen and paper and you'd be able to clear the whole thing up quite easily.

Thank you. The reason I believe there are other partitions is the large amount of Unused Disk Space. It is well over 3 million sectors of a 30 million sector drive.

Do I get this right … you are looking at a 15 Gbyte HDD? That's unexpectedly small – I assume it's an old disk.

I remember the instructor harping that all the drive should be accounted for before examining.

Good advice. But once you've identified the unallocated space, it's size and its location you have accounted for it. Judging the size to be excessive, and suspecting deleted contents … is what I call analysis and forming hypotheses, and identifying ways to test and verify those hypotheses. Link files and mount information and such things can be used for that..

However, there are link files showing me locations and drive serial numbers within some of the partitions that were identified with the partition finder. I feel certain the partitions did indeed exist at one time, but they are not there now.

Can you date the link files? If they were created by normal means, it helps identify the time period when the partition was present, right?

If the partition was deleted, … how was it deleted? Just clearing out the partition table entry is the simplest way, but it leaves the entire partition open to recovery. Overwriting any partition structure or file system structures makes it more difficult to recover the volume, but the files themselves are still there. Of course, if the entire partition was overwritten, there's nothing left … but in such cases it's usually fairly obvious that you're looking at empty/zeroed sectors or random contents.

So … try to identify the size of the partition(s), and do some file carving. Look for volume structures, like $MFT, directory structures and so on. I'm not using v7 myself, but I would expect it to have carving tools still. Alternatively, look for 'File Carving Tools' on the forensicwiki, or in the threads in this forum.

My question for the hidden partitions had to do with Tweak UI. A friend showed it to me once, and he uses it so he can hide certain things from his kids on the computer. Will EnCase identify partitions hidden with tools such as that?

How do you hide a partition? With AT-style partitioning, you set a bit in the partition entry, and the convention is that MS tools won't display the presence of those partitions to normal users, and the operating system won't assign a volume letter automatically. Recovery partitions may be made 'invisible' in this way. But it doesn't hide them in any important sense – it's just a software convention.

GPT partitions does the same a single bit that identifies the partition as 'hidden'. I would not expect EnCase to be stopped by that, though I haven't tried it or seen a hidden GPT partitions as far as I recall.

If you have identified some other partition scheme on the disk, you either have to research it yourself, or tell us what it is. Wikipedia has a fairly decent article on 'disk partitioning' where you can find additional information.

More serious hiding techniques typically involve some kind of crypto solution, like Bitlocker or TrueCrypt. These tend to make the partition/volume contents look entirely randomized, so it's often possible to make a guess that they're present. And it's sometimes possible to identify traces of the software used in the boot/system volume.

And of course, there's also the HPA/DCO type of hiding … but that is identified before the disk is even acquired.

There are a couple of suitable tools that you may use to validate your results.
Testdisk
http//www.cgsecurity.org/wiki/TestDisk
Dmde
http//dmde.com/

Strictly speaking, usually what you find are not partitions, but rather volumes.

The primary partitions (all possible four of them) need to be listed in the MBR partition table, once this table has been modified/zeroed the only way to find a preexisting primary partition (or volume) is to look for bootsectors (or PBR/VBR).
If an Extended partition was present, besides the bootsectors in the volume(s) inside it a program may be able to find the EPBR(s), but these kind of sectors are very difficult to identify, in practice the only "hint" that you may have about their nature is having the magic bytes 55AA at offset 510.

AFAIK (cannot say specifically what Encase does) so called "partition recovery" tools parse the whole harddisk for known patterns of bootsectors.

Please consider how, expecially since the rather common use of virtual machines, the probability of finding "random" volumes on a disk are bigger, a normal "plain" .vhd file (Virtual PC) is a RAW image with a sector appended, most VMware images are also RAW, with in some case a few sectors prepended, so it is not uncommon that a lot of "partitions" (actually "volumes") that were actually a "file" are found through a scan.
The OS up to XP/2003 aligned the partitions to cylinder/head (255/63), so it was easier to evaluate if it was a "real" partition or "something else", since Vista by default partitions are aligned to a "round, even" multiple of sectors, normally 2048, so that the position of the VBR found does not give much support for deciding if it was an actual disk partition or volume or not.

jaclaz