MiniSport Laptop Hacker - Vol #20. Feb 1994 To discourage pecuniary interests, Copyright (c)1994 Brian Mork >>> ADMIN Two places are archiving the MLHacker series (Thank you both!). The first is an Internet e-mail server: ham-server@grafex.cupertino.ca.us, in directory \hamradio\newsletters. The second is an ftp only site: ftp.cs.buffalo.ed, in directory \pub\msdos\ham-radio. In either case, look for the file mlhacker.zip. I think my inbound mail was being re- jected on Internet during the month of January. Things appear to be again stable in the Spokane area. Notice my packet address changed. >>> GDU UTILITY The GDU utility provided on your ROM disk C: is worth having! I down- loaded it to my main computer (use FWL and the cable described in MLHacker #4) and tried running it there. It works great, even with a huge IDE disk drive! I've learned a lot about File Allocation Tables, disk space allocation, deleted files, etc. I thought it might be fun to use GDU to walk through a short tour of your RAMdisk FAT. If you mess it up, so what? It's RAMdisk anyway. Clear it out and reformat it. Takes about 45 seconds. Do be sure to first offload important stuff onto 2" disk or to another computer over the serial link (with FWL). Here's the plan. 1) We'll make a normal text file taking up two alloca- tion units. 2) Then use GDU to make another directory entry pointing to the same text. CHKDSK will report this as a "cross linked" file. 3) Then we'll delete one of the files, causing MSDOS to change the entry for each allocation unit of that file in the FAT to available status. CHKDSK will now report the remaining directory entry as having invalid allocation units. 4) We'll go in and manually retake the allocations and CHKDSK will then report a "lost allocation." 5) Finally, we'll tweak the directory entry to point back to the recovered clusters. 1. From the root directory, run the MSDOS DEBUG program and get the "-" prompt. Enter the command "F 0100,08F7 20 48 49 0D 0A". This puts 408 repeats of " HI" into memory starting at address 0100. A total of 2040 (07f8 hex) bytes were stored. For reasons that will be clear in a moment, write out these 07f8H bytes, plus one extra, to a disk file called HI.TXT. Use these DEBUG commands: R CX, 07F9, N HI.TXT, W, Q. Type out HI.TXT and watch all the HIs scroll by on the screen. You'll probably have a few scrap characters at the end. That's because DOS only stores files in chunks of 1024 bytes on this computer. For other, bigger, disk drives, DOS uses bigger chunks, or clusters. My 250 Mb hard drive on another computer uses 4096 byte units. Run GDU and select the "Display FAT Cluster Chain" option. Highlight HI2.TXT and press return. You'll be shown two cluster numbers where your text has been stored. For me, it's cluster numbers 7 and 8. Yours will be different. Write down *your* numbers for future use. Whenever I refer to cluster 7 and 8 below, use your numbers instead. Press ESC (back to the main menu) and select the "List/Edit in Hex and ASCII" option and select the HI.TXT file. You'll be shown a binary im- age of the file, plus an ASCII interpretation (try toggling the F2 key). Scroll down to the end of the file and see the blinking cursor. The cursor blinks at the first byte that does *not* belong to the file. Remember that extra byte I mentioned above? MSDOS uses 1A (control-Z) to mark the end of the file, and we'll replace that extra byte we saved with a control-Z. Use the F8 key to edit the file, move over to the last byte of the file (after the last 0D 0A, just before the previously blinking cursor) and put a 1A in that spot. Press F8 again to save the changes and exit the GDU program. Type out the file again and it will cleanly end after the 408th "HI". 2. The sectors on the disk are used as follows: Description RAMdisk 2" disk ------------------------------------------------ Boot sector 0 0 FAT copy #1 1-5 1-3 FAT copy #2 6-10 4-6 Root directory 11-42 7-13 Clusters 43+ 14+ We need to go into the root directory and make a clone of HI.TXT with a slightly different name, pointing to the same data. First, make a nor- mal copy with the command "COPY HI.TXT HI2.TXT", then delete it with "DEL HI2.TXT". Use GDU to select the "Display/Edit Logical Sectors" option. Choose sector 11 and scroll down until you see the HI.TXT entry in the root directory. Each entry takes two lines (32 bytes) on this display. Look further down the table of files to find rI2.TXT. Use the F8 key to change the E5 back to a 48 (letter H). You just unerased HI2.TXT, but we need to do more. Our goal is to make it point to the same text. The last four bytes of a directory entry give the file size. Both files should say 00 00 07 F9 (read backwards). The two bytes *be- fore* these bytes gives the first cluster that the file uses. Mine says 00 07 and 00 09. Yours will be different depending on where MSDOS de- cided to put your file at (HI.TXT should match the numbers you wrote down above). Use F8 to edit the HI2.TXT entry to match the HI.TXT en- try. Run CHKDSK. CHKDSK will report a cross link on cluster 7. 3. Delete HI.TXT from disk using the command "DEL HI.TXT". CHKDSK now reports that the first cluster number of HI2.TXT is invalid. Why? Cluster 7 and 8 was marked as available (000 hex for both clusters) when MSDOS deleted HI.TXT. When CHKDSK now looks to find the first cluster of HI2.TXT, it finds a 000 indicating that data is in cluster zero. Well there is no cluster zero (they range from 2-55B on the RAMdisk)! That's why MSDOS uses 000 to indicate a deleted, available cluster. An unerased file points to a deleted cluster. That's why CHKDSK says the 000 entry at cluster 7 is invalid. Run CHKDSK with the /F option. It will "fix" this problem. What it actually does is sets the first cluster number and size of HI2.TXT to zero. Problem fixed? Yea, sure, but your data is still out there on disk, unclaimed by any file! 4. We need to go into the FAT and make cluster 7 point to cluster 8, and change cluster 8 to "last cluster" status. But where are the 12-bit FAT entries for cluster 7 and 8? Two formulas give the answer: byte_offset = cluster# * 1.5 FAT_Sector_offset = int ( byte_offset / 384 ) Offset_into_sector = byte_offset - FAT_Sector_offset * 384 [As a quick aside, because of the limited size of the RAMdisk and the 2" disk, MSDOS uses 1.5 bytes for a FAT entry. If you use GDU on your main computer with larger disks, each entry takes an even 2 bytes, making the calculations much easier. In that case use 2 instead of 1.5 and 256 instead of 384, in the above formulas.] My FAT_Sector_offset is zero for both clusters, and my Offset_into_sec- tor comes out to 10.5 and 12. Use your numbers as we progress. Use GDU to edit the (FAT_Sector_offset + 1) sector. For me, it's sector 1. My bytes line up as follows: Byte offset into sector > ...16 15 14 13 12 11 10 09 08 ... Data on disk > ...00 00 00 00 00 00 0F FF 00 ... ^^^^ ^^^^ Cluster entry > 8 7 The goal is to make the first entry point to the second and put FFF into the second one. In my case, I'll change them as shown below. Notice your two cluster numbers may not be sequential. Just go to each one individually and fix it. Byte offset into sector > ...16 15 14 13 12 11 10 09 08 ... Data on disk > ...00 00 00 0F FF 00 8F FF 00 ... ^^^^ ^^^^ Cluster entry > 8 7 5. CHKDSK will report "2 lost clusters in 1 chain". Use GDU to edit the root directory entry for HI2.TXT. Point to the proper first cluster by changing the 11th and 12th byte on the second line of the directory en- try to 07 00 (or whatever your first cluster number was). Everything is almost back to normal. Remember the second FAT stored in sectors 6-10 for the RAMdisk? They don't match. You could go manually fix them, but there's an easier way. Run CHKDSK. This time it will say errors are found, but it doesn't say that it's mismatched FATs and bad file size entries in the directory. Run CHKDSK with the /F option and it will fix up the second FAT copy to match the first and will update the size of HI2.TXT to 2048 bytes (2 clusters). Remember the original HI.TXT was only 2041 bytes. You can go edit change the last four bytes in the di- rectory entry from 00 08 00 00 to F9 07 00 00, if you wish. Whew! What fun. If it's any consolation, it took five disk drive crashes and *days* of time for me to learn what I just related to you. GDU is a great program and works fine on my other computer system. Please provide feedback! * Direct data 1-509-244-9260 * AX.25 KA9SNF@wb7nnf.#ewa.wa.usa * Internet bmork@opus-ovh.spk.wa.us 73, Brian * 6006-B Eaker, Fairchild, WA 99011