163 lines
9.2 KiB
Plaintext
163 lines
9.2 KiB
Plaintext
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<CR><LF>" 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
|