Join Us!

Partition Recovery ...
 
Notifications
Clear all

Partition Recovery using Encase/open source software  

  RSS
Christ143uk
(@christ143uk)
Junior Member

Hi,

I was just wondering if anybody had any advice for finding a deleted partition on a .E01 file apart from performing a keyword search for the boot sector. Such as searching for "NTFS" or "FAT" in unallocated clusters.

Or could you advise me of any free software that would be able to search through a .E01 file or an image that has been mounted by FTK Imager.

Thanks in advance.

Quote
Posted : 10/01/2014 12:42 am
jaclaz
(@jaclaz)
Community Legend

Hi,

I was just wondering if anybody had any advice for finding a deleted partition on a .E01 file apart from performing a keyword search for the boot sector. Such as searching for "NTFS" or "FAT" in unallocated clusters.

Or could you advise me of any free software that would be able to search through a .E01 file or an image that has been mounted by FTK Imager.

Thanks in advance.

Depending on the actual OS and the way the image is mounted/accesed, both TESTDISK and DMDE would do, I am not sure that a .E01 image can be mounted as "PhysicalDrive" in Windows, maybe you need to make it into a RAW image (which is definitely supported).
Testdisk
http//www.cgsecurity.org/wiki/TestDisk
Dmde
http//dmde.com/

jaclaz

ReplyQuote
Posted : 10/01/2014 1:21 am
Christ143uk
(@christ143uk)
Junior Member

Jaclaz,

Thank you for your response!

I will have a look into these two programs and see if I can het anywhere with them.

Many thanks

ReplyQuote
Posted : 10/01/2014 1:36 am
athulin
(@athulin)
Community Legend

I was just wondering if anybody had any advice for finding a deleted partition on a .E01 file apart from performing a keyword search for the boot sector. Such as searching for "NTFS" or "FAT" in unallocated clusters.

Any kind of attempt to find a file system (which usually has to be stored in a partition) is to search for key patterns. Doesn't matter if they're key words (like 'NTFS') or other key data, and in a boot sector or in super blocks or whatever. And that pretty much disposes of everything you ask for, so I probably misunderstand what you are really after.

If you know what software created the partitioning system, you also know how it assigns partitions on track boundaries or cylinder boundaries, say. Thus you don't really have to search all allocated sectors – it's enough to search the sectors where key contents would end up if there had been a file system there.

.

ReplyQuote
Posted : 10/01/2014 10:41 pm
jaclaz
(@jaclaz)
Community Legend

If you know what software created the partitioning system, you also know how it assigns partitions on track boundaries or cylinder boundaries, say. Thus you don't really have to search all allocated sectors – it's enough to search the sectors where key contents would end up if there had been a file system there.
.

Allow me to disagree 😯 in the sense that while most *standard* partitioning software will actually allow only cylinder or Mb boundary, if the "narrower field" is "data recovery", AND IF the (say) bootsector data is actually there, THEN looking in a subset of sectors would be enough (and much faster) but if there is no (or corrupted, partially or totally bootsector) that won't simply work, as without the data in the BPB you have no "hints" about size of the volume/partition, and other meaningful sectors (like, still say, the $MFT or Root directory entry/volume label) may be placed on*any* sector (though the most common locations for NTFS are also "fixed" as an example FAT table may put this sector on *any* sector).
This is IMHO even more relevant for disk forensics, where someone may have used a "peculiar" partitioning software (or manually written the partition table).

So, if the idea is to do first a pass for just the "usual suspects" sectors (any sectors multiple of cylinder boundary or of 1 Mb) it could be very good ) as long as you know already what was there before (i.e. what you are looking for) and this search finds it, but in all other cases "full scan" is IMHO needed.

More or less this is what TESTDISK does with the "quick search" vs. "deeper search", and what you can very similarly obtain in DMDE limiting the range to search for.

jaclaz

ReplyQuote
Posted : 10/01/2014 11:29 pm
zoltandfw
(@zoltandfw)
Junior Member

I prefer the old fashioned manual method in a hex viewer. I like to avoid false negatives by scanning the image for all executable signature 0x55AA. That way, I can quickly identify all Volume Boot Record (VBR ), identify the file system, ignore the backup VBRs, quickly ignore the false positives, and then any of the above mentioned tools can be used to recover partitions if needed. That way, I can verify if the tool can recognize all the partitions. I sleep better if I don't need to worry about false negatives. You or the tool might not even know the file system signature, but the 0x55AA will be there.

Brian Carrier showed us years ago that people can come up with strange ways to manipulate the partitions that tools might miss like extended partition in extended partition.

ReplyQuote
Posted : 11/01/2014 2:00 am
jaclaz
(@jaclaz)
Community Legend

… but the 0x55AA will be there.

Not really-really ( , this may apply to Forensics (in the presumption that the disk is fully usable, but not in the case of someone attempting to "hide" something) but definitely not in data recovery, where the issue may exactly be an overwritten/deleted/wiped bootsector or VBR (or just it's signature).

jaclaz

ReplyQuote
Posted : 11/01/2014 3:39 pm
Share: