Ethical Hacking Training at InfoSec Institute

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Computer Forensics Computer-Forensics
[Top] [All Lists]

Re: Cluster size

Subject: Re: Cluster size
Date: Mon, 20 Dec 2004 20:44:27 -0500
On Dec 13, 2004, at 7:14 PM, Lily Tse wrote:

Hi,
I know that there are different default cluster sizes an operating
system uses during a high level format depending on how big the volume
is. However, cluster size can be changed easily. Assuming that the all
the VBRs on a hard disk have been destroyed (BIOS parameter block info
is lost), is there any way I can find out the exact cluster size for
FAT16, FAT32, NTFS, EXT2, and EXT3 volumes?

Here are some ideas. All of which require you to go hunting for data structures.


FAT32 has a backup copy of the boot sector in sector 6, so you could try and get it from there. But, if we assume that both are destroyed, you may be able to figure the size out for FAT if you can determine where the primary and backup FAT structures start and end and you can determine the size of the data area. The size of each FAT will tell you roughly how many clusters the file system had in the data area. So, divide the size of the data area by the estimated number of clusters and you should roughly have the cluster size (roughly because not all entries in the last sector of the FAT may have been used). This assumes you know which FAT type it was though and the "official" method for determining FAT type is based on the number of clusters ...

NTFS is a little harder. There is typically a backup copy of the boot sector, so that could give you the size. If we again assume that it is destroyed, you may be able to guess based on the location of key data structures. For example, if the first MFT entry is found at a byte offset that is a multiple of 1,024 but not a multiple of 4,096.

Ext2/3 has backup copies of the superblock all over the file system, so finding the block size could be easier. If we again assume that all copies are destroyed, then you may be able to take advantage of the way that most Ext2/3 file systems are created. They are organized into block groups and the number of blocks in each block group is set to the number of bits in a block (so that the block bitmap is only one block in size). If you can determine the size of the block groups (using the location of standard data structures) then you could figure out the block group size and therefore a potential block size.

brian


-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com


<Prev in Thread] Current Thread [Next in Thread>