Did you ever take a care about FAT filesystem? Did you experienced over new one that Windows'95 brings? I played with old FAT a long time ago, I did a lots of work with it, like disk recoveries, crashed disks, etc, even repairing disk by phone (filling in all numbers computed in head for partition and boot by talking via phone). I wrote several FAT emulators r/w (guess for what reasons ;-), some recovery utilities, disk swapping tools (changing internal dos/windows stuff for swapping disks, booting from non-primary partitions, etc), on-fly mounting an unmounting disk utils for dos/win. I would say I was quite familiar with FAT.
But things getting changed. I've installed a new Windows on my computer some time ago (you have to do so in current contitions), swapped to FAT32. It is slower a bit, but functional. Before I have my old (today I would say "really old") 1GB disk partitioned into 128MB partitions for having 2kB clusters. I used to have lots of small files, and not to have a big space wasting I had many logical disks on that disk. With FAT32 all these things are forgotten. But even in that time I never checked new disk structures.
But nice spring evening comes, and CIH does its job. Not on my disk, of'coz as I play with viruses for more than 8 years. I don't have any active virii on my computer - for that reasons I use best avir 'round the globe - hiew ;-). Well but friend of mine called me that his office disk crashed (and even his cheef's disk and others as well) and asked me for help. "CIH" - my first idea was. Of course I was right. Moreover, he wasn't the only one who asked me for help at that time. And I get experienced with FAT32 immediately.
Well, let's have a look what is changed under FAT32. Of course, cluster numbers are 32bit. What an advantage. However, as upper 4 bits of cluster number are reserved, gives at maximum 268,435,456 clusters. This makes FAT very long, and slows down a DOS a lot, because it can't load all data into its buffers at once and forgots first entries it loads - and it has to load it again, forgetting newer entries, then to load newer once again: if you are familiar with caching algorhitms of victims - it is a classical example of fifo-bug. I'll divide my tour into some logical sections, covering what is new in all structures. Most of changes are determined by need of accessing big disks. Really big disks. It has something to deal with int13 address-space, bioses, and so on.
There are two main changes. At first, the code itself is changed for supporting a new accessing methods of huge disks. You have to think about of adressing space for accessing sectors on disc. May be some of you remember how the limit of 512MB was famousely broken. Maximum coordinates some time ago were:
However, thinking about maximum 6/6/12 bits or 6/8/10 bits leads to same
results. But some of the BIOSes (IBM based) supports only 4 bits for head,
and, of course 10 bits for track. In result it is 63*16*1024 sectors (each
512 bytes) which is nearly the famouse 512MB limit.
Those disks in old times uses disk managers in order to overcome this limit under all bioses (usualy emulates int13 call using controller commands performing LBA accessing). LBA introduced in that time means Logical Block Adress - avoiding old geometry adressing (track/head/sector) with logical sector number.
Well, 512mb limit is over, but there is another limit - given by maximum accessible number of 3 bytes use for old-style access 63*64*4096 - an 8GB limit. By the way - MS-DOS (and Win95/98 as well, as it still relies on old dos routines) has trouble using head 255, and disks must be mapped as maximum 255 tracks (0..254 which can be handles by msdos). Here you can see, how big is Microsoft's influence to hw manufactures - due to bug in very old OS the still presents hw which overcomes these problems. Moreover - none of disks I seen within last 2 years uses real geometry but instead of it they use internal translation of geometry from logical that is indicated to bios and dos, into physical. Well, it is unbelieveable that todays disk has 255 surfaces which means 128 physical magnetic disks with surfaces on both sides - how you can fit it into disk package aprox inch of height? ;-)
Well, back to 8GB limit of old style adressing (which must be there, otherwise DOS - and its graphical frontend called Windows can't be started). This can't be simply bypassed this way by increasing some bits. A new routines for reading must be introduced. Have a look on current partition table code and read: A old routines 13/02 are still there, but preferable it uses new EDD functions (Enhanced Disk Drive - originaly found in Phonenix BIOS, but available in AWARD as well). It is detected by calling 13/41, and accessible via 13/42 using qword LBA for adressing sectors.
This qword can't be extracted from old adressing bytes as there isn't enought bits to cover all the needed information. Thats why begining relative sector is used which has dword size. Of course, introduces a new limit of 4G sectors = 2TB. Too bad, isn't it? Disk size is rapidly increasing, hope these structures will be changed within next years.
Also there are four new filesystem codes for partition table entries for FAT32 disks:
0Bh- FAT32 (32bit fat, up to 2047GB)
0Ch- FAT32x (same as FAT32, but uses LBA-logical block adress for accessing)
0Eh- DOSX13 (same as 06h - 16bit fat for larger partitions than 32MB, but with LBA accessing)
0Fh- DOSX13x (same as 05h - extended partition, but with LBA accessing)
Logical disc structure
We can now access disk and its sectors. A logical disks follows - organisation is nearly unchaned - for compatibility reasons. A boot sector and reserved sectors take a place, two copies of FAT, and clusters containing directories and files. Now, as in whole FAT32 implementation I can present two news: bad one and good one. Good one is that Microsoft is learning on his old mistakes and corrects them - root directory has no longer fixed position, and is located in separate cluster - so it can be expanded more than limited number of items like in previouse versions was. Bad news is that MS still stays on bad and unreliable filesystem, with slow access, not statisticaly optimized for files typicaly used. Of course, there is NTFS but people still prefer FAT-based filesystems.
Boot sector is no longer a sector. Funny, isn't it? We should better call it boot record (or superblock for linux freaks) because now it is stored in first three sectors. Moreover it is usualy mirrored by default to sectors 6-8 (a hotlink backup of boot sector) but its coordinates are stored in bootsector, so once it lost you generaly can't find a copy :-)
Here are offsets and meaning of values in boot sector(s), presented in linear offset which means offset 0x0200 means sector 1 offset 0x0000. Code is now stored in sectors 0 and 2.
0x0003:OEM ID (8 chars) usualy "MSWIN4.1" (or 4.0 for Win95)
0x000B:bytes per sector (word) always 512 for hard-disks
0x000D:sectors per cluster (byte)
0x000E:reserved sectors at begining (word) usualy 32 but can vary (with sector 0)
0x0010:fat copies (byte) always 2 for hard-disks
0x0015:media descriptor (byte) always F8 for hard-disk
0x0016:sectors per FAT (word) 0 for FAT32, as FAT can be really long
0x0018:sectors per track (word) default contains translation mode values
0x001c:special hidden sectors (dword) usualy 63
0x0020:big total number of sectors (dword)
0x0024:big total sectors per fat (dword)
0x0028:FAT flags (word): 0-based number of Active FAT - i.e. fat beeing in use (bits 0-3) valid only if mirroring (bit 7) is disabled, bit 7 - FAT mirroring enabled, bits 4-6 and 8-15 are reserved. In other words, you can avoid using fat copy that contains physicaly damaged sectors - but someone have to turn it on :)
0x002a:filesystem version major (byte)
0x002b:filesystem version minor (byte) - 0.0 I saw so far
0x002c:first cluster of root directory (dword)
0x0030:FS sector number (word) - usualy 1 - where rest of boot record is stored - FileSystem informations (0FFFFh if there is no FSINFO sector, otherwise must be more than zero and less than reserved sector count)
0x0032:hotlink - backup bootsector (word) - usualy 6 (same as above: 0FFFFh for no backup, 1..reserved-1 otherwise)
0x0040:physical drive number (byte)
0x0042:extended boot record signature (byte) - 0x29
0x0043:volume serial number (dword)
0x0047:volume label (11 chars)
0x0052:filesystem ID (8 chars) - "FAT32 "
0x01fc:signagture (dword) aa550000
0x0200:extended boot signature (dword) - 41615252 "RRaA" (wow! no Mark Zbikowsky and his 'MZ'-everywere anymore, seems Bill employed someone else ;-)
0x03e4:FSINFO signature (dword) - 61417272 "rrAa"
0x03e8:free cluster count (dword) - as it takes long time to go through whole FAT, number of free clusters is stored here (0FFFFFFFFh if unknown)
0x03ec:next free cluster (dword) - to speedup free space lookup
0x03fc:FSINFO ending signature (dword) aa550000
0x05fc:signature (dword) aa550000
FAT - 32bit File Allocation Table
by skipping reserved sectors (usualy 32) you can reach file allocation table. Rest of reserved area is cleared, only boot sector(s) and its backup can be found there so far. But in future, who knows. Signature itself starts with known F8 FF FF 0F pattern. First cluster can't be used (as from passed), its value in fat is initialized to FF FF FF 07. The rest contains fat data itself, starting for cluster 2 at offset 8 in fat. Principle of fat lookup is same as before, but now uses structured 32bit value: 4+28bits, low 28 bits for cluster number (FFFFFFF for end of chain, FFFFFF8 for bad), upper 4 bits are reserved and Microsoft requires to preserve them when modifying FAT entries. Representation in stored form is, for example, FF FF FF 0F for end-cluster.
FAT can be very long - up to several thousands of sectors, which of course slows down all operations. As caching it takes lots of memory, which is unreal with buffers available under DOS. But this makes disks to surrive CIH's attack, as it destroys first 2000 sectors of disk, but if you have FAT32 (really long), second copy of fat is usualy untouched - all you need to do to repair disk after CIH is to copy second fat into first, construct boot sector (copy from other disk an type-in correct values) and write some numbers into partition table. Resulting few minutes of work - and disk is repaired like nothing happened. With infected files of CIH too, of course ;-)
I will not speak about LFN entries, as they are already well known I think. All I want to describe where the 32bit cluster value is stored. Low part of cluster number is at the original location, word at +1a bytes in directory entry. High word is stored at +14 in this entry. Both of them are real index into fat, like under old fat16/12 system. I also should mention, largest possible file on FAT32 is 4GB minus 2 bytes.
My short description is now over. Are you happy about FAT32 features? Where the hell are features? All is done as usual - Microsoft extends all stuff in order to keep it working, keeping all fears alive. There is no way to relyie on old traditions but MS breaks the limits - just like with dos7 and its graphical interface - keeping all the bugs as tradition that came from win 3.1, old dos, cp/m, etc, etc...