Note: This is not any advanced thesis. Its just a small improvement made over an old filesystem technology. Ofcourse now we have better new filesystems. The content format of the thesis over this page is scrambled. Better download the document file for clear view.
Download
Document - Secure Fat32.zip -- 24KB
Abstract The paper brings out a new and altered design model of FAT32, providing security for the files stored on the disk using the stamped User ID and Group ID mechanism. The solution provided is designed with the complete backward compatibility and portability with legacy systems in mind.
I. Introduction
Microsoft Corporation invented a file system called File Allocation Table (FAT) during 1977, for integration with Disk Operating System (DOS). The initial version was FAT12, which primarily focused on its use with Floppy Diskettes allowing 8 MB Storage. Next the Microsoft Corporation came with FAT16, allocating upto 128 MB of storage, which was integrated with DOS 4.0v to support larger sized hard disks.
II. FAT32
The growing needs of Industry with commonly available for 2 GB HDD, Microsoft came up with FAT32 file system of completely new extended architecture, raising the ceiling upto 2 Terabytes.
FAT32 tends to follow the Acyclic Graph directory structure.Each of the files directories was specified using file directory entries, which extended to 32 bytes in size, with Unicode character set support. Differing completely from FAT16, this new file system was not having any reserved sectors for root directory. Instead it was contained in a link in the modified BIOS Parameter Block (BPB) [1]. BPB additionally provided Boot Sector backup in hidden sectors.
III. FAT File System
FAT32 follows a linked allocation of disk space, where first entry is kept in the directory entry and the last entry terminated by special identity. The file system itself is held in the reserved sectors part, with optionally two copies to ensure reliability.
Cluster Group Size Map
Volume Size |
Sectors/Cluster |
Cluster Size |
< 8 GB |
8 |
4 K |
< 16 GB |
16 |
8 K |
< 32 GB |
32 |
16 K |
> 32 GB |
64 |
32 K |
Actually FAT32 implements things in terms of 28 bits long, where upper nibble being reserved by Microsoft for future updates which was not later updated at all. No user based security for files is provided in Microsoft FAT32, leaving all resources open to all users.
IV. SECURE FAT32
Considering the security features available in other file systems such as Ext2, Ext3 of Linux/ UNIX, we desire to extend FAT32 with security issues like:
• User ID Stamping
• User Group ID and other permission considerations
• Extra functionality flags
The idea in extending the system was with the mind of old legacy resources to be backward compatible & portable, so the files created in the new system run with zero security in old systems and files from old systems work in new systems without security. The migration tool, if designed, should help in porting to new mode adoption.
The BPB's last reserved byte's first byte has to be stored with special code of 0xF5 indicating new file system SFAT32 for the disk volume.
The idea turned up with the fact that FAT32 uses special types of slots for storing Unicode character set facility upto 250 characters length. These Long File Name (LFN) slots are similar to short entries carrying 32 bytes. But in order to fool DOS (having compatibility in mind) it followed special attributes mode viz. Read Only, System, Hidden, Volume, Directory are always set, so DOS ignores considering them as illegal entries.
In order to keep our secure information, we are in need of 4 bytes space as listed below:
• 16 Bit User ID
• 16 Bit Group ID
• 12 Bit Permission Flags
But LFN/SN entries have no room for storing this information implicitly. So, we go for a special kind of directory entry called SFAT entry which is a sub kind of LFN (of FAT32). This entry is made for each of the files at the end of SN/LFN stack for the file.
DOS and Windows at first simply ignore SFAT entry as it doesn't contain implementations. So, the backward compatibility is maintained. This technically works since FAT32 stops scanning LFN stack, as it sees the last LFN Record Flag set for n th LFN entry.
The new SFAT32 entry coming next to n th LFN entry contains security information. Each time the file is accessed in SFAT32 implementations this entry is accessed to construct the i-node data. Then the usual security validation mechanism checks for permissions.
SFAT32 ENTRY FORMAT
Position |
Description |
Byte 0 |
SFAT32 Sequence Number |
| |
0
5 |
0x00 Identity of SFAT32 entry |
6 |
Always Set |
7 |
Always Zero |
|
Byte 1 ... 2 |
User ID
Intel Little Endian Format |
Byte 3
4 |
Group ID
Intel Little Endian Format |
Byte 5
6 |
Permission Flags |
Byte 5 |
Byte 6 |
0 |
User Read |
0 |
Others Read |
1 |
User Write |
1 |
Others Write |
2 |
User Execute |
2 |
Others Execute |
3 |
Group Read |
3 |
Set UID on Execution |
4 |
Group Write |
4 |
Set GID on Execution |
5 |
Group Execute |
5 |
Sticky Bit |
6 |
Reserved |
6 |
Reserved |
7 |
Reserved |
7 |
Reserved |
Byte 7
10 |
Reserved
Always 0x00 |
Byte 11 |
Attribute
Always 0x0F |
Byte 12
31 |
Reserved
Always kept 0x00
Used for LFN Entry Compatibility |
SFAT32 system on deletion operation, always ensures marking this entry also as Deleted and Available by setting 0xES for first byte of SFAT32 entry.
V. Conclusion
The security issue was good but implementation in Windows itself is not available or possible since Microsoft has kept Windows a closed source. Instead Microsoft have come up with NTFS in Windows XP/NT, differing from what we thought to occur. But still SFAT32 embedded with VFAT implementation will implementation will help security in other Operating Systems.
VI. Acknowledgement
Microsoft FAT32 White Papers, Thomas Kjoernes whose information regarding FAT32 architecture was helpful.
VII. Appendix
[1] FAT32 Bios Para meter Block
Field |
Size |
Offset |
BytesPerSector |
2 |
0x0B |
SectorsPerCluster |
1 |
0x0D |
ReservedSectors |
2 |
0x0E |
NumberOfFATs |
1 |
0x10 |
RootEntries |
2 |
0x11 |
TotalSectors |
2 |
0x13 |
Media |
1 |
0x15 |
SectorsPerFAT |
2 |
0x16 |
SectorsPerTrack |
2 |
0x18 |
HeadsPerCylinder |
2 |
0x1A |
HiddenSectors |
4 |
0x1C |
TotalSectorsBig |
4 |
0x20 |
SectorsPerFAT |
4 |
0x24 |
Flags |
2 |
0x28 |
Version |
2 |
0x2A |
RootCluster |
4 |
0x2C |
InfoSector |
2 |
0x30 |
BootBackupStart |
2 |
0x32 |
Reserved |
2 |
0x34 |
[2] Normal/Short Entry Format
8 BYTEs |
Blank-padded name
- The first byte tells you some special information:
00h entry is available and no entry beyond this one has been used.
05h first character is actually E5h
2Eh first character is a dot; this is a special entry. It can either be the "dot" or "dot-dot" entry, which is present in all directories except the root directory. The "dot" entry has a cluster number that points to the directory itself. The "dot-dot" entry has a cluster number that points to the parent directory (or null if the parent is the root directory)/
E5h entry has been erased and is available. |
3 BYTE |
Blank-padded extension |
1 BYTE |
Attribute
- This field is bit-mapped. Only bits 0-4 should be used, bits 5-7 are said to be reserved. Note that the special value of 0Fh indicates an LFN entry. The value 0Fh is an otherwise illegal attribute value.
- Older software might think that LFN entries are "Read-Only System Hidden Volume Directories"
00001b Read-Only
00010b System
00100b Hidden
01000b Volume
10000b Directory |
1 BYTE |
Reserved, used by Windows NT, Novell DELWATCH apparently uses this to store the original first character for erased entries. |
1 BYTE |
10-ms unit's "Create Time" refinement (added with VFAT). |
1 WORD |
Creation time (added with VFAT). |
1 WORD |
Creation date (added with VFAT). |
1 WORD |
Access date (added with VFAT). |
1 WORD |
High 16-bits of Cluster # (added with and used for FAT32). |
1 WORD |
Update time (set on creation as well) |
1WORD |
Update date (set on creation as well) |
1 WORD |
16-bit Cluster # |
1 DWORD |
File size in bytes (always zero for directories). |
[3] Long File Name Entry Format
1 BYTE |
LFN Record Sequence Number
- Bits 5:0 hold a 6-bit LFN sequence number (1..63). Note that this number is one-based. This limits the number of LFN entries per long name to 63 entries or 63 * 13 = 819 characters per name.
- The longest filename I was able to create using Windows 95 Explorer was 250 characters.
- Bit 6 is set for the last LFN record in the sequence.
- Bit 7 is set if the LFN record is an erased long name entry or maybe if it is part of an erased long name |
10 BYTEs |
5 UNICODE characters, LFN first part. |
1 BYTE |
Attribute - This field contains the special value of 0Fh, which indicates an LFN entry. |
1 BYTE |
Reserved (probably just set to zero). |
1 BYTE |
Checksum of short name entry, used to validate that the LFN entry belongs to the short name entry following.
According to Ralf Brown's interrupt list, the checksum is computed by adding up all the short name characters and rotating the intermediate value right by one bit position before adding each character. |
12 BYTES |
6 UNICODE characters, LFN second part. |
1 WORD |
Initial cluster number, which is always zero for LFN entries. |
4 BYTES |
2 UNICODE characters, LFN third part. |
[4] FAT32 FILESYSTEM ENTRY CODES
Details |
FAT32 Entry Value |
Available |
00000000 |
Reserved |
00000001 |
User Data |
00000002-0FFFFFF6 |
Bad Cluster |
0FFFFFF7 |
End Marker |
0FFFFFF8-0FFFFFFF |
[5] PACKED TIME
15:11 |
10:5 |
4:0 |
Hour |
Minute |
Second / 2 |
[6] PACKED DATE
15:9 |
8:5 |
4:0 |
Year 1980 |
Month |
Day |
[7] BOOT SECTOR LAYOUT FOR FAT32
Boot Sector Fields |
Size |
Offset |
Jmp |
3 |
0x00 |
OEmName |
8 |
0x03 |
FAT32 |
BPB |
0x0B |
DriveNumber |
1 |
0x40 |
Unused |
1 |
0x41 |
ExtBootSignature |
1 |
0x42 |
SerialNumber |
4 |
0x43 |
VolumeLabel |
11 |
0x47 |
FileSystem |
9 |
0x52 |
BootCode |
422 |
0x5A |
Products Available 
