Author: dzzie@yahoo.com ----------------------------------------------------------------------------- Afternote: I know some of the stuff in here is under a misnomer...I am going leave this as is because it is a true to life work log...first research and conclusions does not always equal reality...there is no shame in that...this document is a stream of thought and experiment that followed...i personally find the chain of events and conclusions as inseresting to analyze as the actual outcome of the playings ! If i ever get around to writing an actual paper on this then dont worry i will fix it all up and make it purdy :P ----------------------------------------------------------------------------- Ok I couldnt resist putting this one up..mabey it is because i am endless geek and find these things amazing so anyway here we go :D This tutorial is about learning and experimenting with the disks File Allocation Tables. Dont worry it is completely safe we are only going to play with floppy disks :) Goals See all files that had previously been on disk Restore Files so they appear in Explorer Reallocate file clusters so that 2 files point to same data area Manually mark valid files as deleted so as to hide thier contents Locate data on disk from FAT cluster data This may be pretty basic from a forensics point of view seeing how there are techniques to completly recover deleted files if the clusters havent been overwritten but i am still building up to that. This has been a matter of fun and experimentation so far...i do plan on reading throguh teh source to tools like TCT and see how they did it. At anyrate it is fun to experiment :D Simplified Format of a floppy ______________________ | Boot Code | <-- 0h - 202h |---------------------| | FAT Table | <-- 202h - 4200h |---------------------| | Data Portion | | | <-- 4200h + |_____________________| for a more indepth description (although i am not sure what percentage of it applies to to floppies check out this excellent resource on formats) http://212.14.34.87/~fkiepski/down/helpy/formats.zip http://212.14.34.87/~fkiepski/helpye.html anyway most fun to experiment and see what we can do then when time is right and we are already stumped and ready for the answers and have our own questions to ask then is the time to truly dive in and seek the knowledge (such is the fundemental flaw in formal education...throwing answers at people as matter of facts when it does not serve to answer any questions for them but is just a matter or work to finish and get through. but that is own rant) anyway ! so the first thing we have to figure out is how to view the raw contents of the disk so far as i know of there are two ways...the somewhat longer yet free way (assuming you have a computer with *nix on it that is) is to image the floppy with dd then browse it with a hexeditor or i jsut discovered i can view raw disk contents with just my hexeditor ! this can be done with a command similar to hexedit /dev/fd0a if you are as much of a windows weenie as I then you will prefer to use a winGUI tool. For matters such as these Winhex is the tool of choice. It is an excellet hexeditor that can also raw edit disks and even ram. Minus these two options i think you could also find a cd imaging software that could image a disk...CDWINR comes to mind but it has been ages since i played with it. Anyway if you could image the floppy then you could edit the raw image and then transfer it back to floppy but that would be very long process for experiments. so anyway now we have raw access to disk contents...format yourself a clean floppy note that if you choose to do a "Quick Format" on the floppy there is good chance you are not going to have an absolute clean image to work with! I just did a quick format to test and i still found the text to the test files on the disk although the filenames were completly wiped from the FAT. Ok so do a complete format then take a peek with teh hexeditor...I can clearly see the bootcode which ends at 202h then a large block of null bytes then starting at offset 4200h all bytes are set F6h it would be a pretty good guess these are the 3 respective area mentioned above of teh disk. so we know the disk is clean...time to save some test files to it. create 2 text files on your desktop one called newfile.txt and the other oldfile.txt or whatever. Write a unique sentence in each such as "this is oldfile"/ "this is newfile" now we open up the floppy in raw mode and search for string "file" here is what we see... 00002600 46 52 45 44 44 4F 20 20 20 20 20 08 00 00 00 00 FREDDO ..... 00002610 00 00 00 00 00 00 0B 50 84 29 00 00 00 00 00 00 .......P„)...... 00002620 4E 45 57 46 49 4C 45 20 54 58 54 20 18 89 98 BD NEWFILE TXT .‰˜˝ 00002630 84 29 84 29 00 00 F4 BD 84 29 02 00 0F 00 00 00 „)„)..ô˝„)...... 00002640 4F 4C 44 46 49 4C 45 20 54 58 54 20 18 1B A6 BD OLDFILE TXT ..Ś˝ 00002650 84 29 84 29 00 00 F8 BD 84 29 03 00 0F 00 00 00 „)„)..ř˝„)...... the first entry from 2600 - 261F is an entry for floppy name held in FAT table the second entry from 2620 - 263F is FAT entry for newfile.txt and you get the idea for the third...observations anyone? a fat entry is a 32 byte field 8 bytes allocated for (short) filename, looks like 4 for extension.note no . and no null terminator...this probably means is fixed field size...lets test by saving 2 more files with > 8 char names and 4 & 5 char extensions :) so i copy 2 new files longnamefile.aaaa and longnamefile.bbbbb lets see what it looks like now. 00002660 42 62 00 62 00 62 00 62 00 62 00 0F 00 53 00 00 Bb.b.b.b.b...S.. 00002670 FF FF FF FF FF FF FF FF FF FF 00 00 FF FF FF FF ˙˙˙˙˙˙˙˙˙˙..˙˙˙˙ 00002680 01 6C 00 6F 00 6E 00 67 00 6E 00 0F 00 53 61 00 .l.o.n.g.n...Sa. 00002690 6D 00 65 00 46 00 69 00 6C 00 00 00 65 00 2E 00 m.e.F.i.l...e... 000026A0 4C 4F 4E 47 4E 41 7E 31 42 42 42 20 00 47 1A BF LONGNA~1BBB .G.ż 000026B0 84 29 84 29 00 00 13 BF 84 29 04 00 12 00 00 00 „)„)...ż„)...... 000026C0 42 61 00 61 00 61 00 61 00 00 00 0F 00 11 FF FF Ba.a.a.a......˙˙ 000026D0 FF FF FF FF FF FF FF FF FF FF 00 00 FF FF FF FF ˙˙˙˙˙˙˙˙˙˙..˙˙˙˙ 000026E0 01 6C 00 6F 00 6E 00 67 00 6E 00 0F 00 11 61 00 .l.o.n.g.n....a. 000026F0 6D 00 65 00 46 00 69 00 6C 00 00 00 65 00 2E 00 m.e.F.i.l...e... 00002700 4C 4F 4E 47 4E 41 7E 31 41 41 41 20 00 0B 1B BF LONGNA~1AAA ...ż 00002710 84 29 84 29 00 00 19 BF 84 29 05 00 11 00 00 00 „)„)...ż„)...... acck this is more than i want to analyze at teh moment...will side track us from where we were going...but is good to see how long filenames are handled...humm 2 more tests just to be thorough and have good baseline for reference...need to see 8 char filename with 4 char extension which i predict will fit into normal entry...need to see long filename with 3 char extension and need to see short filename with 5 char extension...then we will have tested all the bounds (lower bounds anyway ;) ok i will spare you the hex dumps i will just give the observations..i was wrong in my guess standard file name field can contain up to 8 chars..this makes sense from dos filenames...simple extension field can only conatin maxium of 3 characters before it uses extended format. oghh what the heck now i am curious lets see what happens when we use an outrageous huge filename. heh here is new file name "this is my really really long file and we need to see what it does mabey we find coutner variable in fat saying how much size entry is.txt" ok for reference that is 138 characters...or 8Ah 00002840 4B 79 00 20 00 69 00 73 00 2E 00 0F 00 43 74 00 Ky. .i.s.....Ct. 00002850 78 00 74 00 00 00 FF FF FF FF 00 00 FF FF FF FF x.t...˙˙˙˙..˙˙˙˙ 00002860 0A 75 00 63 00 68 00 20 00 73 00 0F 00 43 69 00 .u.c.h. .s...Ci. 00002870 7A 00 65 00 20 00 65 00 6E 00 00 00 74 00 72 00 z.e. .e.n...t.r. 00002880 09 20 00 73 00 61 00 79 00 69 00 0F 00 43 6E 00 . .s.a.y.i...Cn. 00002890 67 00 20 00 68 00 6F 00 77 00 00 00 20 00 6D 00 g. .h.o.w... .m. 000028A0 08 72 00 69 00 61 00 62 00 6C 00 0F 00 43 65 00 .r.i.a.b.l...Ce. 000028B0 20 00 69 00 6E 00 20 00 66 00 00 00 61 00 74 00 .i.n. .f...a.t. 000028C0 07 6E 00 64 00 20 00 63 00 6F 00 0F 00 43 75 00 .n.d. .c.o...Cu. 000028D0 74 00 6E 00 65 00 72 00 20 00 00 00 76 00 61 00 t.n.e.r. ...v.a. 000028E0 06 73 00 20 00 6D 00 61 00 62 00 0F 00 43 65 00 .s. .m.a.b...Ce. 000028F0 79 00 20 00 77 00 65 00 20 00 00 00 66 00 69 00 y. .w.e. ...f.i. 00002900 05 65 00 20 00 77 00 68 00 61 00 0F 00 43 74 00 .e. .w.h.a...Ct. 00002910 20 00 69 00 74 00 20 00 64 00 00 00 6F 00 65 00 .i.t. .d...o.e. 00002920 04 77 00 65 00 20 00 6E 00 65 00 0F 00 43 65 00 .w.e. .n.e...Ce. 00002930 64 00 20 00 74 00 6F 00 20 00 00 00 73 00 65 00 d. .t.o. ...s.e. 00002940 03 6F 00 6E 00 67 00 20 00 66 00 0F 00 43 69 00 .o.n.g. .f...Ci. 00002950 6C 00 65 00 20 00 61 00 6E 00 00 00 64 00 20 00 l.e. .a.n...d. . 00002960 02 61 00 6C 00 6C 00 79 00 20 00 0F 00 43 72 00 .a.l.l.y. ...Cr. 00002970 65 00 61 00 6C 00 6C 00 79 00 00 00 20 00 6C 00 e.a.l.l.y... .l. 00002980 01 74 00 68 00 69 00 73 00 20 00 0F 00 43 69 00 .t.h.i.s. ...Ci. 00002990 73 00 20 00 6D 00 79 00 20 00 00 00 72 00 65 00 s. .m.y. ...r.e. 000029A0 54 48 49 53 49 53 7E 31 54 58 54 20 00 B8 F2 01 THISIS~1TXT .¸ň. 000029B0 85 29 85 29 00 00 D8 01 85 29 0A 00 18 00 00 00 …)…)..Ř.…)...... ok well i know we all have one last question prying on all our minds..can you say it with me? what about directories? ok...last diversion i promise! empty folder called new added 00002A00 4E 45 57 20 20 20 20 20 20 20 20 10 08 5D E7 1E NEW ..]ç. 00002A10 85 29 85 29 00 00 E8 1E 85 29 0C 00 00 00 00 00 …)…)..č.…)...... damn it..one more ok..lets add file to it...acck check this out 00005600 2E 20 20 20 20 20 20 20 20 20 20 10 00 5D E7 1E . ..]ç. 00005610 85 29 85 29 00 00 E8 1E 85 29 0C 00 00 00 00 00 …)…)..č.…)...... 00005620 2E 2E 20 20 20 20 20 20 20 20 20 10 00 5D E7 1E .. ..]ç. 00005630 85 29 85 29 00 00 E8 1E 85 29 00 00 00 00 00 00 …)…)..č.…)...... 00005640 4E 45 57 46 49 4C 45 20 54 58 54 20 18 3C 17 1F NEWFILE TXT .<.. 00005650 85 29 85 29 00 00 F4 BD 84 29 0D 00 0F 00 00 00 …)…)..ô˝„)...... look at the offsets! that is way out the pattern... you know..now dont laugh..one more bit of data to collect this is the last one i can think of right now i promise...but what happens when change the file name of a file? 00005600 2E 20 20 20 20 20 20 20 20 20 20 10 00 5D E7 1E . ..]ç. 00005610 85 29 85 29 00 00 E8 1E 85 29 0C 00 00 00 00 00 …)…)..č.…)...... 00005620 2E 2E 20 20 20 20 20 20 20 20 20 10 00 5D E7 1E .. ..]ç. 00005630 85 29 85 29 00 00 E8 1E 85 29 00 00 00 00 00 00 …)…)..č.…)...... 00005640 4F 4C 44 46 49 4C 45 20 54 58 54 20 18 3C 17 1F OLDFILE TXT .<.. 00005650 85 29 85 29 00 00 F4 BD 84 29 0D 00 0F 00 00 00 …)…)..ô˝„)...... oghh just for the posterity..this file contains the text "this is newfile" 15 characters ( 0Eh ) look at 565C... block size + null terminator? more on this latter..)and what happens if the data block gets fragmented?? thorough research is the backbone of society right? ..is changing name for file in subfolder = changing name of file in root folder? ok just checked...apparently it is...but reason i though to check was that originally when i did this little testing...to create a new file i right clicked and did the new -> text document thing...and when i did that and then subsequently renamed the file windows left a trail and deleted the default name in fat entry and made a new one for the renamed file..weird huh..only variable i can see is that mabey that is because it was a zero length file .. one other thing i have noticed growing as files have been added to disk is this 00001400 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF đ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ 00001410 FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 ˙˙˙˙˙........... i have no idea what this is..but if i had to make a guess it would be that it is like a map file describing which FAT entries were occupied? lets delete one of our files and see if this changes. ok i just delete the file newfile.txt (the second entry in teh table [rember the first entry was for the floppies name]..heh later lets see what happens when we use illegal characters for filenames and entries! dont forget to remind me :) 00001400 F0 FF FF 00 F0 FF FF FF FF FF FF FF FF FF FF FF đ˙˙.đ˙˙˙˙˙˙˙˙˙˙˙ 00001410 FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 ˙˙˙˙˙........... pretty spiffy eghh...but not as cleancut as i had hoped..another thing to rember is since we are workign with floppies..floppies have no recycle bin.. you delete it on a floppy its gone...there may an interm staeg here on fixed drives with recycle bin...will have to partition up a 1mb partition and check it out sometime :) ok we have the data for that part now..will analyze more latter the extended formats..for now on to the actual goals listed in the overview at top...how does that saying go curosity killed the cat? mabey more properly curosity kept cat from dieing from bordom? you decide. anyway on we go...back to the standard short name FAT entry format... from above 00002620 4E 45 57 46 49 4C 45 20 54 58 54 20 18 89 98 BD NEWFILE TXT .‰˜˝ 00002630 84 29 84 29 00 00 F4 BD 84 29 02 00 0F 00 00 00 „)„)..ô˝„)...... now we just deleted newfile.txt...humm what does FAT look likenow? 00002620 E5 45 57 46 49 4C 45 20 54 58 54 20 18 89 98 BD ĺEWFILE TXT .‰˜˝ 00002630 84 29 84 29 00 00 F4 BD 84 29 02 00 0F 00 00 00 „)„)..ô˝„)...... see how first character of filename has been rewritten with character E5 ? that is how files are marked as deleted...if you restore that first character then it is a valid entry to windows again and boom the file reappears in explorer! now that is spiffy for sure heh...the one little :( about it though is that even though the file reappears...it cant be opened ..it is like it dosent know where to find that fiels data (which if you do a search for the phrase that was in that file you will still find it on disk because windows only marks it as freespace and dosent delete the file contents) so mabey take a closer look and see if there is anything else in this entry we would be able to restore to fully restore the file... exists 4E 45 57 46 49 4C 45 20 54 58 54 20 18 89 98 BD NEWFILE TXT .‰˜˝ deleted E5 45 57 46 49 4C 45 20 54 58 54 20 18 89 98 BD ĺEWFILE TXT .‰˜˝ exists 84 29 84 29 00 00 F4 BD 84 29 02 00 0F 00 00 00 „)„)..ô˝„)...... deleted 84 29 84 29 00 00 F4 BD 84 29 02 00 0F 00 00 00 „)„)..ô˝„)...... ok...well thats good...we can clearly see nothing else was modified in the fat entry...humm rember how that map(?) area changed when we deleted it? we do have a before an after of it because we are so organized and observant :)\ lets see what happens if we restore that as well... aweeee fudge..that wasnt enough to restore it..something else on the disk must be changing that our ever observant eyes hath missed :_( since we are hellbent on figuring this out it is time to carry on learn from our failures and not give up...so humm how can we detect every change on disk...well what comes to mind is to start a new test floppy from clena format...save a file to it...then swap it over to our trust *nix box...image it with dd go back to windows...delete the file go back to *nix box image it again then ftp the images over (which will be 1.4mb each of data to sift through....but no prob...i have a handdy dandy windows program to do these great byte level comparisions (and i am sure *nix has like 10 great ones built in but i am still primarily a windows weenie :-\ ok...so we have our plan...and were..err I..am off ! full format floppy copy file to it now over to openbsd system and the following commands dd if=/dev/fd0a of=./exists.img md5 /dev/fd0a > exists.md5 md5 exists.img >> exists.md5 less exists.md5 what this does...(for those not of unix familarity) dd line copies all of the raw data from floppy to the file exists.img md5 raw floppy image and save teh hash to file exists.md5 md5 image file we took of floppy and append to exists.md5 less exists.md5 shows up the contents of the file so we can verify they are same :) for those who dont know md5 is (and if you dont congradulations on hanging in through all this mumbo jumbo so long to be this far down the document!) md5 runs a calculation on the file you feed it and spits out a 32 character string of numbers and letters...if even one little bit (heh pardon the pun:) is different in two files thier md5 hashs (the long string it spits out) will be very different so md5 assures us we got the truth the whole truth and nothing but the truth... anyway...on we go..back to windows..to delete our poor file than yup back to bsd running over the same commands.. dd if=/dev/fd0a of=./deleted.img md5 /dev/fd0a > deleted.md5 md5 exists.img >> deleted.md5 less deleted.md5 yay! all the md5s hashed out (oghh the puns never end) so now ftp them over to windows machine (or if you have no lan then find software to image floppy on windows or if use dual boot machine save to fat filesystem orrr you get the idea up to you to figure it out..do what you have to do..i will meet you back here in 10 minutes ok..) ok now were cooking...no literally..i am cooking come back in 5 more minutes.. some people...pfft ok so were back now i run these two images through my handy dandy byte comparison program which i made a long time ago and is very slow and very memory intensive and you know how old software goes..anyway here is the output ---------------------- |_Offset_|__F1__|__F2__| | | | | | 203 | FF | 0 | | 204 | F | 0 | | 1403 | FF | 0 | | 1404 | F | 0 | | 2600 | 4E | E5 | ---------------------- F1 = file 1 = exists.img F2 = file 2 = deleted.img now that we know where the changes take place let take a peek in the hex editor view of world again to make it a little clearer and visualize... --------------------------------------------------------------------------------- exists.img 00000200 F0 FF FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 đ˙˙˙............ 00001400 F0 FF FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 đ˙˙˙............ 00002600 4E 45 57 46 49 4C 45 20 54 58 54 20 18 64 A5 2A NEWFILE TXT .dĽ* 00002610 85 29 85 29 00 00 F4 BD 84 29 02 00 0F 00 00 00 …)…)..ô˝„)...... ---------------------------------------------------------------------------------- deleted.img 00000200 F0 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 đ˙˙............. 00001400 F0 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 đ˙˙............. 00002600 E5 45 57 46 49 4C 45 20 54 58 54 20 18 64 A5 2A ĺEWFILE TXT .dĽ* 00002610 85 29 85 29 00 00 F4 BD 84 29 02 00 0F 00 00 00 …)…)..ô˝„)...... ---------------------------------------------------------------------------------- so what did we miss ?! now that we have conclusive data on the matter...and hopefully presented in a very non-therotical non-bloated understandable direct way thank you.. what we err..I missed was that there are 2 copies of the FAT table! and ughh i probably misnamed what i was calling fat entries before...looking over the formats guide again we find these to be directory entries..makes sense..anyway by whatever name we call the data..it is the data that tells all...so we will continue on in my misnomers because at least to me they already have concepts tied to them and that is what i am grasping at...so when we changed the byte E5 back to ascii we did good... when we changed the bytes in teh "map" area back to FF we did good...the only thing is that we modifed the back up map...the one windows uses if the main map gets corrupted..so since the maps are identical (*cough* should be anyway *cough*) lets go back to our original floppy and make the changes to that first map area and see what shakes loose. oghh one more thing while were here... rember what byte 261C was? file length right...that byte was not changed and there were no further changes in the file farther down where file content existed just to show it to you...lets do a text search for the files contents and add that in ----------------------------------------------------------------------------------- exist.img 00004200 74 68 69 73 20 69 73 20 6E 65 77 66 69 6C 65 00 this is newfile. ----------------------------------------------------------------------------------- deleted.img 00004200 74 68 69 73 20 69 73 20 6E 65 77 66 69 6C 65 00 this is newfile. ----------------------------------------------------------------------------------- now you have seen it with your own eyes...data of file is still there..ok on to restoring data... ----------------------------------------------------------------------------------- first map area 00000200 F0 FF FF 00 F0 FF FF FF FF FF FF FF FF FF FF FF đ˙˙.đ˙˙˙˙˙˙˙˙˙˙˙ 00000210 FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 ˙˙˙˙˙........... ----------------------------------------------------------------------------------- second backup map area we restored 00001400 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF đ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ 00001410 FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 ˙˙˙˙˙........... ----------------------------------------------------------------------------------- yup there we go incongruence *nods*..lets sync them up shall we..ok moment of truth! save sectors then open disk in explorer and try to access newfile.txt. how does that go? bingo was his name-o ? nice...well now that we have experimented and discovered how it all works from an uneducated external view...now comes the 382038203829038 questions this raises! but see.. now i am more than just curious...now that knowledge means somthign to me...now all that time i will subsequently spen in research will be answering my questions answers to things i have been tryign to understand and make sense off...such learning is the best...it is the most fruitful...carries the deepest sense of realization and is completly painless ! once you have learned in this way....well lets just say it is addictive. so what questions does this leave? ----------------------------------------------------------------------------------- I still want to figure out the intricies of that long filename mubo jumbo How do i locate the offset each file begins at from data in directory entry? What is the best way to automate restoring files? look at clusters find length of datablock and offset and try to determine if file has been overwritten by congruence in datatype ? <-smart logic routines What is the exact relation that FAT "map" and the directory? why was that one folder so far down there... what happens if i rename those default directory entries . and .. in the folder :) what happens if i use illegal characters for filenames or for floppy title? if i change first byte to e5 in directory but dont free up the fat table..will the file ever get overwritten? if i change the first character of the filename to 00 will it show up? so many questions !