If you saw the experiment log that was up in this place then welcome back.

If not, then you missed watching the learnign curve and discover in action,
but you will not get the benifit of the abridged and conclusive version.
So the topic of the day is how to undelete files from a FAT12 partition.
To keep the matter concise and managable we are going to work with floppy
disks to not only limit the amout of data we must sift through but also
so that we dont accidently corrupt or hardrives and loose any data.
First matter of business is to get a quick overview of the disk format. There
are many ways to look at the structure of a disk, but i think the healthiest
way for us to look at it with a couple preconceptions.
1) A floppy is just one large binary file to be read and manipulated, just like
patching an exe
2) Sections of this binary file are read and parsed and everything is in a very
defined and logical standardized format.
3) When a file is deleted its contents are not deleted from the disk, like wise
the record of the file name and location is only marked as "deleted" but is not
overwritten.
ok thats probably enough for now, just rember..this is all logic, no magic !
On to the sections of a disk.
--------------------| Dos Boot Code
|
|____________________|
|
FAT #1
|
|____________________|
|
FAT #2
|
|____________________|
|
Directory
|
|____________________|
| Data Section
|
|____________________|

<-- 1 sector -- Starts at 0

<-- 6 sectors -- Starts at 200h
<-- 6 sectors -- Starts at 1400h
<-- 8 sectors -- Starts at 2600h
<--Remainder of disk -- Starts @ 4200h

a) Dos Boot Code - small executable code found on the disk in the first sector
1 sector = 512 bytes...512 decimal = 200 hex, this is reserved area that
is used to store a system boot loader code if this was a boot disk. If i
tnt
then this code is accessed and this is what pops up the nonSystem disk e
rror
message if you boot with the disk in the floppy. This small program is o
nly
run by the bios on boot up. I tried to replace it with a small asm hello
world
but my guess that the first two bytes being EB 3C or in asm Jmp 3c for t
he
entry point were off..the system just hung..unless even inttrupt functio
ns
are not available yet on boot disk? anyway..it appears that for expplore
r to
access the disk at all it must parse a small section of the boot track.
Here
is the minimum i have found through experiment to be needed to access th
e disk

ome

normally. (so each of these fields must contain data that is parsed in s
manner to access the disk)

00000000
00000010
00000020
00000030

EB
02
00
00

3C
E0
00
00

00
00
00
00

00
40
00
00

00
0B
00
00

00
F0
00
00

00
09
29
00

00
00
D6
00

00
12
05
00

00
00
E1
00

00
02
B8
00

00
00
00
00

02
00
00
00

01
00
00
00

01
00
00
00

00
00
00
00

<..............
..@...........
......)......
................

b) FAT tables. There are two of these each 6 sectors long. The second one is not
read
unless the first one is damaged. The FAT is more or less a map file here
is the
FAT table of a disk containing a single file and that files corrospondin
g
directory entry.
FAT Table
00000200 F0 FF FF FF 0F 00 00 00 00 00 00 00 00 00 00 00

............

Directory Entry
00002600 48 45 4C 4C 4F 20 20 20 41 53 4D 20 18 7F 71 3C
00002610 8B 29 8B 29 00 00 C0 46 89 29 02 00 75 00 00 00

HELLO ASM . q<

) )..F )..u...

The File Allocation Table (FAT) holds a listing of which directory entries are
being used. The FAT format is a packed bit layout which means every entry takes
up 1.5 bytes and the bytes are not contigious. That makes no sense in words i kn
ow
so heres an example. in the FAT table above every 3 bytes is 2 entries. lets loo
k
at the entry FF 0F 00 (bytes 3-5) when we unpack and swap these bits around (we
will
go into more detail and make a program to do it for us latter) the 2 entries we
get
are FFF and 000. FFF means that this cluster contains the End of File (EOF) mark
er.
The 000 value denotes that there is no corrosponding directory entry in the next
slot
yet.
Since the Directory entry is easier to grasp we will start with that. Here is th
e
exerpt from the "DiskDoctor" (note this was written before support for long file
names!)
---------------Each directory entry is 32 bytes long: there are 16 entries
per sector, laid out so:
;These are our values for each over
here
file name
extension
attributes
reserved space
time stamp
date stamp
starting cluster
length (bytes)
-----------------

bytes 0-7
; "HELLO "
bytes 8-10
; "ASM"
byte 11
; 20h
bytes 12-21
; 18 7F 71 3C
bytes 22-23
; C0 46
bytes 24-25
bytes 26-27 (an integer)
bytes 28-31 (a 4-byte integer)

8B 29 8B 29 00 00
; 89 29
; 02 00
; 75 00 00 00

If filename > 8 characters then it changes the entry to a long filename format
If extension > 3 characters then it changes the entry to long filename format
if filename first character is E5h then file has been marked as deleted by windo
ws
note that only this first byte is changed! rest of entry is intact. Only
other change on disk is that the FAT table entry has be zeroed.
Attributes our attribute entry is 20h (32 decimal) or 0010 0000 in binary, as fa
r
as flags are concerned this means bit 5 is set. below is the flag table
from "DiskDoctor"
----------------------------bit number 7654 3210
our value: 20h -> 0010 0000
bit 0 means the file is read only
bit 1 means the file is hidden
bit 2 means it is a system file
bit 3 means it is a volume label, not a file
bit 4 means it is a subdirectory
bit 5 is an archive bit
bits 6 and 7 are unused at present
-------------------------------This shows that this file is marked with the archieve bit set. Goto File proper
ties
from explorer and the associated checkbox is set. Just for fun i set bits 6 and
7 and
unset 5. result...file appears but opens as zero length file. setting bit 5 as w
ell
had no effect. setting the flags for both subdirectory and archieve made the fil
e
appear as a folder. when you opened the folder it was full of folders andfiles t
hat
were named with the contents of the files text..wacky
Starting Cluster is a byte swapped integer mapping which cluster the file begins
at. Note that this is not the physical cluster layout of the disk. Since the
beginning of the disk is used for house keeping the data area is said to start
at cluster 2 which starts at offset 4200h !
our value 02 00 -> byteswap() -> 0002 or cluster 2. The first available data
cluster on disk starting at byte offset 4200h.
Filelength: our value = 75h -> 117 dec = character length
Since each sector (cluster) is 200h long. This file fits nicely inside one clust
er.
Since a cluster is the smallest allocatable chunk given out, there will be 125h
unused space between the end of this file and the beginning of the next one. Als
o
since this file fits all the single cluster the FAT only has to record that the
beginning cluster pointed to by the directory entry is also the sector containin
g
that files End Of File (EOF).
So what happens if a file is longer than one cluster? we know how to find the
beginning of it...how do we locate where the rest of the file lies? Well since f
iles

can be deleted we can not depend on each section of the file being laid out in o
ne
contigious block. To know where to look next the operating system will go back t
o the
File Allocation Table and check to see what cluster holds the next section of th
e file.
The best way to drill this into your (and my) brain is to do a small experiment
and see it all happen. Lets save another file to the disk that is several sector
s
big to see how it changes the disk layout.
one file that fits in single cluster
00000200

F0 FF FF FF 0F 00 00 00 00 00 00 00 00 00 00 00

............

added another file that is 3 clusters long

00000200 F0 FF FF FF 4F 00 05 F0 FF 00 00 00 00 00 00 00

O.........

directory now looks like

00002600
00002610
00002620
00002630

48
8B
4E
8D

45
29
4F
29

4C
8B
4E
8D

4C
29
41
29

4F
00
4D
00

20
00
45
00

20
C0
20
12

20
46
20
03

41
89
44
8D

53
29
41
29

4D 20 18 7F 71 3C HELLO ASM . q<

02 00 75 00 00 00
) )..F )..u...
54 20 18 54 15 03 NONAME DAT .T..
03 00 06 04 00 00
) ).... )......
|____||__________|
byte swapped starting cluster = 3___|
|_______FileLength (604h)

from dir entry file size = 604h -> 1540 bytes

raw data: file goes from offset: 4400h -> 4805h -> diff = 405h -> 1029d bytes
file size saved was 1030 bytes
size on disk = 1,536 bytes ( from explorer properties)
3 sectors = 1536 bytes
2 sectors = 1024 bytes
using 6 bytes of next sector and shanghied all next sector
1 cluster = 1 sector
hello.asm start marker = 02 00 -> byteswap() -> 00 02 starts @ offset 4200
noname.dat start marker = 03 00 -> byteswap() -> 00 03 starts @ offset 4400
examine fat entries
a)
b)
c)

F0 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00
F0 FF FF FF 0F 00 00 00 00 00 00 00 00 00 00 00
F0 FF FF FF 4F 00 05 F0 FF 00 00 00 00 00 00 00

.............
............
O.........

a) contains no files, first 3 bytes reserved (first 2 entries)

b) contains one
part of
der
of FAT)
defined

file, of the byte FF 0F the zero has yet to be filled it will be

the next entry for the next file saved (because of the packed or
so this fat entry is FFF which indicates that the start cluster
in teh directory entry is also the cluster that contains that fi

les

EOF, so not further info is needed on this file.

c) here another file has been added to the disk used above. the file added was
1030bytes long. which means it encompasses 3 clusters. The cluster point
ed
at in directory entry is 03 00 (0003) or the third. then to find the oth
er
2 segments of the file we look at the FAT entry for it. 4x 00 05 F0 FF
unpacked this = 004 005 FFF. this tells us that the next cluster is 4 th
en 5
and that cluster 5 contains the EOF.
Now that we see how that works. Lets jump right into a real world example :)
Below is the FAT to another floppy disk. how many files does this represent?
and what clusters can they be foudn at? (if you havent noticed i like to drill
in the basics and concepts at depth then jump off the deep end :)
Offset
00000200
00000210
00000220
00000230
00000240
00000250
00000260
00000270
00000280
00000290
000002A0
000002B0
000002C0
000002D0
000002E0
000002F0
00000300
00000310
00000320
00000330
00000340
00000350
00000360
00000370

0 1 2 3 4 5 6 7
F0
FF
01
21
C0
03
41
C0
05
61
C0
07
81
C0
09
A1
C0
0B
C1
C0
0D
E1
C0
0F

FF
FF
17
20
02
37
20
04
57
20
06
77
20
08
97
20
0A
B7
20
0C
D7
20
0E
F7

FF
FF
80
02
2D
80
04
4D
80
06
6D
80
08
8D
80
0A
AD
80
0C
CD
80
0E
ED
80

FF
FF
01
23
E0
03
43
E0
05
63
E0
07
83
E0
09
A3
E0
0B
C3
E0
0D
E3
E0
0F

FF
FF
19
40
02
39
40
04
59
40
06
79
40
08
99
40
0A
B9
40
0C
D9
40
0E
F9

FF
0F
A0
02
2F
A0
04
4F
A0
06
6F
A0
08
8F
A0
0A
AF
A0
0C
CF
A0
0E
EF
A0

FF
00
01
25
00
03
45
00
05
65
00
07
85
00
09
A5
00
0B
C5
00
0D
E5
00
0F

FF
01
1B
60
03
3B
60
05
5B
60
07
7B
60
09
9B
60
0B
BB
60
0D
DB
60
0F
FB

8 9 A B C D E F
FF
11
C0
02
31
C0
04
51
C0
06
71
C0
08
91
C0
0A
B1
C0
0C
D1
C0
0E
F1
C0

FF
20
01
27
20
03
47
20
05
67
20
07
87
20
09
A7
20
0B
C7
20
0D
E7
20
0F

FF
01
1D
80
03
3D
80
05
5D
80
07
7D
80
09
9D
80
0B
BD
80
0D
DD
80
0F
FD

FF
13
E0
02
33
E0
04
53
E0
06
73
E0
08
93
E0
0A
B3
E0
0C
D3
E0
0E
F3
E0

FF
40
01
29
40
03
49
40
05
69
40
07
89
40
09
A9
40
0B
C9
40
0D
E9
40
0F

FF
01
1F
A0
03
3F
A0
05
5F
A0
07
7F
A0
09
9F
A0
0B
BF
A0
0D
DF
A0
0F
FF

FF
15
00
02
35
00
04
55
00
06
75
00
08
95
00
0A
B5
00
0C
D5
00
0E
F5
0F

FF
60
02
2B
60
04
4B
60
06
6B
60
08
8B
60
0A
AB
60
0C
CB
60
0E
EB
60
00

.... ..@..`
.. ..........
! .#@.%`.' .).+
.-./..1 .3@.5`
.7 .9.;.=.?..
A .C@.E`.G .I.K
.M.O..Q .S@.U`
.W .Y.[.]._..
a .c@.e`.g .i.k
.m.o..q .s@.u`
.w .y.{.}. ..
. @. `. . .
. . .. . @. `
. . . . . ..
.@.`. ..
.... .@.`
. ......
.@.`. ..
.... .@.`
. ......
.@.`. ..
.... .@.`
. ....

reserved-----|
|-----2 Single Sector Files
|------| |------|
00000200 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000210 FF FF FF FF FF 0F 00 01 11 20 01 13 40 01 15 60

.... ..@..`

Ok the first part of this looks easy

for all the single sector fiels every 3 FF bytes denotes 2 files
that brings us to thats 6 files each one cluster from 2-8
noW scan teh large block for where the next FFF EOF marker is.
nicely enough it is at the end..so there is only
one more file to account for but it is a doozie ;) so what clusters can
it eb foudn in? we dontknow the start cluster becase thats in the directory

entry...but form the FAT we can tell it goes from :

------------format refresher AB CD EF -> DAB EFC
also note that since every 3 bytes = 2 files, and 16 is not divisible by 3
that you cannot get into the easy pattern of relating byte position in editor
to which conversion you are on!
------------0F
11
13
15
17

00
20
40
60
80

01
01
01
01
01

->
->
->
->
->

00F,
011,
013,
015,
017,

010
012
014
016
018

we could go on for quite some time...but i think it is time to automate this

yes no?
so basic logic goes like this...grab hex block, since every 3 bytes carries 2 en
tries
makes sense to use this fact to simplify the parsing.Basic logic outline:
dim b1,b2,b3 as string
'pattern we wish to accomplish
'
AB CD EF -> DAB EFC
'
b1 b2 b3 LoWord = right most character of byte (hex format) converse for Hi
ghWord
for i=0 to ubound(byte) step 3
b1=byte(i)
b2=byte(i+1)
b3=byte(i+3)

next

entry1 = LoWord(b2) & b1

entry2 = b3 & HiWord(b2)

see the sample app for full working version. anyway we find the file contigeous
from 00F - 0FE
since this file is not fragmented at all...even if teh file had been deleted
and the fat entry wiped...we could have recovered the file in its entirity from
disk knowing only the start file offset found in the remainder of the directory
entry.
(rember only the first byte of the directory entry is overwritten when a file is
deleted and none of the data is wiped from disk!) (or didnt we get that far yet?
)