My CF teacher gave us an assignment to reconstruct a partition table that was zero'ed out. He gave us the un-zeroed image as well to compare.
I find the 2nd partition which starts on sector 73584, decode the total sectors (73583). This means the partition should go until 147167. In sector 147167 I find a backup VBR for this partition, and in 147168 I find the VBR for the next partition. The un-zeroed out image returns 73584 for this partitions size, but I need to minus 1, so that seems to jibe.
I then run 'dcfldd if=messier-corrupt.img bs=512 skip=73584 count=73583 of=ntfs.dd' to extract the 2nd partition. But, the extracted partition does not contain the backup boot sector. The image ends on what would be sector 167166.
Extracting a third partition, also NTFS, shows the same problem.
Extracting the partitions via FTK Imager gives me different MD5 hashes, but it adds the backup boot sector, where as the dcfldd extraction does not.
Is it correct, then, that the backup VBR in sector 147167 is not technically part of the partition? Where am I going wrong?
My teacher is out of town and incommunicado, so I am turning to the forums. Any help would be appreciated.
I find the 2nd partition which starts on sector 73584, decode the total sectors (73583). This means the partition should go until 147167.
On what grounds do you draw that conclusion? ('at least until but not impossibly even beyond' seems a more appropriate conclusion.)
As I have no information about what type of partition table you expect (BIOS-type? GPT? Other?), what the file systems are (only guesses), or what software was used to create the partitions, I can only note that although a file system lives inside a partition, the fit is not necessarily 'tight' there may easily be slack space at the end. Quite a lot of older partitioning software uses the CHS information provided by the drive (even if it strictly is meaningless), and ensures that partitions start and end on disk track boundaries. That may be something that you could factor into your restoration attempts.
If you are really careful, you may also want to experiment with the formatting/partitioning software that you think was used, and try to set up a partitioning scheme that fits what you see on thee image. Some software provides a limited set of partition sizes, and in those cases, there are obviously a limited set of possibilities to choose from.
I find the 2nd partition which starts on sector 73584, decode the total sectors (73583). This means the partition should go until 147167.
On what grounds do you draw that conclusion? ('at least until but not impossibly even beyond' seems a more appropriate conclusion.)
Because 73584 + 73583 = 147167, and in 147168 is the extended partition table. So, if I understand you correctly, there wouldn't be any slack, regardless of the software used or the file system, or what not. Most likely, Windows XP was used, and the file systems are Fat32, NTFS, and NTFS, in that order. To answer your questions.
I don't know, maybe you didn't understand me, or I am not understanding you.
So, looking at the good partition table, I can see that mmls is pulling it's values from there. NTFS partition 1 is listed as 73584 sectors long in the partition table, but the volume boot record lists 73853.
Another CF teacher says the disparity is that the backup volume boot sector is not part of the NTFS partition, which would explain the disparity.
Can anyone confirm or give a deeper explanation so that I may have a deeper understanding? Going to court and explaining your findings as "Because my teacher said it was so" doesn't go over very well.
"Because my teacher said it was so" doesn't go over very well.
So how does "because someone on a forum whom I have never met said so" fare any better?
Those of us doing this for a living b**t our heads against problems like this on a regular basis. Working out how to overcome them is a key skill.
I personally would be much more disposed to helping you find where the answer is rather than handing it to you on a plate.
Paul
"Because my teacher said it was so" doesn't go over very well.
So how does "because someone on a forum whom I have never met said so" fare any better?
I wrote that tongue-in-cheek, but…
In either case, I would confirm and test any claims. But as it stands, I have nothing to test, just an anomaly that i can not explain that provides me with no further understanding of NTFS or computer forensics.
And I never asked for the answer on a plate, only for understanding.
OK, here are a few resources you might want to look at…
My primary resource for anything NTFS is the documentation maintained by the ntfsprogs team. These guys have reversed engineered NTFS in order to get it working on *nix systems and thankfully have maintained a document of the internal structure of NTFS. You can find it on the
Other sources include
http//
http//
And don't forget Microsoft's own MSDN network where you can glean the odd tidbit
http//support.microsoft.com/
Paul