IBM
PC DOS 1.00 Index
MBR
and Boot Records IndexThe Starman's Realm Index
This work will list all the details for the most important slack space discoveries on the original distribution diskette. Though purposely not exhuastive, in order to ensure no one can reproduce an exact image file from this data, we do cover most of the executables on the diskette. The format is simple: For each file listed, you'll find a thorough examination of the slack space within its last cluster. Offsets are in hexadecimal starting from 000000 at the beginning of the diskette, or from the beginning of a file stored on the diskette or loaded into memory as specified.
Download this file: DOS10SSE.ZIP which contains .HEX file examples from most of the slack space sectors discussed below, plus DEBUG scripts and a Batch program that will automatically display the contents of all the .HEX files in the package. Each HEX file has the name "ssc##.HEX" which corresponds to the cluster # of the slack space where this fragment was found on the diskette. The *.dsf files are DEBUG script files used by the DISPLAY.BAT program. [ The program will run under any MS-DOS or Windows™ (in a DOS-box) OS with access to DEBUG; this includes Windows™ XP too! ]
IBMBIO.COM left 128 unused bytes in Cluster 5 (Abs. sector 10). They form
a tiny part of an Assembly Code Listing, which appears similar
to the following:
08A1 0752454E414D db 7,"RENAME"
45
08A8 8305 dw RENAME
08AA 064552415345 db 6,"ERASE"
If you have any experience with Assembly programming, your eyes might be
drawn to this data or the many 0D 0A hex bytes when first looking at this
diskette's slack spaces. The first column above contains offset values in
memory, the much wider second column contains the actual hex bytes of the
program's machine code and following that are columns of readable source
code lines. 'db' stands for byte-sized data and 'dw' for word-sized (two
bytes) data. Each letter of a word found within quotes is encoded in the
program ("RENAME" = '52454E414D45'), but that same word without the quote
marks (after the 'dw') was apparently a reference to a label used by the
programmer somewhere else in the source code.
The characters above in red were logically deduced from the assembly code
listing and do indeed correspond to what we found when searching for these
bytes on the diskette; these code bytes exist only in the COMMAND.COM file.
However, even after taking into account the difference between load offsets
found in memory and the offsets of code in a stored file, we couldn't find
any match for the offset values. The location of the bytes listed above
would be at offset 08A1h and following in memory and should therefore be at
07A1h and follwoing in COMMAND.COM, but we found them at the file offsets
of: 0C6Eh through 0C7Ch (in Cluster 25) insted. It may be that the code was
first created as an EXE program, then converted to a COM program later.
IBMDOS.COM leaves 256 unused bytes in Cluster 18 (Abs. sector 23), but
essentially half of them are "00" bytes! Curiously, the 128
remaining bytes are exactly the same as those found above in
IBMBIO.COM's slack space.
COMMAND.COM leaves 353 unused bytes in Cluster 25 (Abs. sector 30), but
this slack space contains at least two separate types of data;
the last 128 bytes of which are yet again for a third time,
exactly the same as those found in clusters 5 and 18 above.
But we also have the first of many .HEX file fragments located here:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
003C90 34 4
003CA0 35 34 45 34 31 34 44 34 35 38 33 30 35 30 36 34 54E414D458305064
003CB0 35 35 32 34 31 35 33 34 35 37 37 30 35 30 35 35 5524153457705055
003CC0 34 35 39 35 30 34 35 41 30 39 30 0D 0A 3A 31 41 4595045A090..:1A
003CD0 30 44 38 35 30 30 30 35 30 34 35 32 34 35 34 44 0D8500050452454D
003CE0 30 34 30 31 30 35 34 33 34 46 35 30 35 39 45 39 040105434F5059E9
003CF0 30 35 30 36 35 30 34 31 35 35 35 33 34 35 33 35 0506504155534535
003D00 30 37 30 30 38 30 30 31 30 44 45 36 0D 0A 3A 30 070080010DE6..:0
003D10 30 30 30 30 30 30 30 30 30 0D 0A 1A 1A 1A 1A 1A 000000000.......
from which we created this .HEX file:
:1A0D6B005268040752454E414D45830506455241534577050554595045A090
:1A0D8500050452454D040105434F5059E90506504155534535070080010DE6
:0000000000
The characters above in red were reconstructed later after identifying the
location of the other bytes; they do not appear in the following display.
After loading this .HEX file into DEBUG [Note: when using DEBUG to convert
.HEX file fragments into machine code, it's always a good idea to include
":0000000000" as the last line or else DEBUG may 'lock-up'], we have:
0D70 45 4E 41 4D 45 83 05 06-45 52 41 53 45 77 05 05 ENAME...ERASEw..
0D80 54 59 50 45 A0 05 04 52-45 4D 04 01 05 43 4F 50 TYPE...REM...COP
0D90 59 E9 05 06 50 41 55 53-45 35 07 00 80 01 0D Y...PAUSE5.....
Unlike the Assembly Code Listing we found in previous slack space sectors,
this piece of a .HEX file is a perfect match in relation to where the same
bytes from COMMAND.COM would be loaded into memory (from offsets 0C70h
through 0C9Fh as stored in its file on disk; see comments under CHKDSK.COM
for the details of how .COM files are loaded into memory).
This is the first of many HEX fragments which are found in the slack space
of the last sector of the only executable they can be identified with on
this diskette. In other words, for every executable on this diskette that
has a HEX fragment in its slack space, its code will be part of that same
executable! This is one of the reasons we concluded that all executables on
the diskette were most likely transferred to it as HEX files first and then
converted to .COM files on the diskette itself.
FORMAT.COM has no slack space; it's exactly 5 sectors long (2,560 bytes).
CHKDSK.COM leaves 141 bytes in Cluster 33 (Abs. sector 38):
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
004D70 3A 30 30 30 30 30 30 30 30 30 30 0D 0A :0000000000..
004D80 44 20 20 0D 0A 20 20 20 20 20 30 41 20 32 34 20 D .. 0A 24
004D90 20 20 20 20 20 20 20 20 20 20 20 20 20 0D 0A 30 ..0
004DA0 36 32 42 20 32 30 20 36 32 20 37 39 20 37 34 20 62B 20 62 79 74
004DB0 36 35 20 37 33 20 20 46 52 45 53 50 43 3A 09 44 65 73 FRESPC:.D
004DC0 42 09 22 20 62 79 74 65 73 20 72 65 6D 61 69 6E B." bytes remain
004DD0 20 61 76 61 69 6C 61 62 6C 65 22 2C 31 33 2C 31 available",13,1
004DE0 30 2C 31 33 2C 31 30 2C 22 24 22 0D 0A 20 20 20 0,13,10,"$"..
004DF0 20 20 32 30 20 37 32 20 36 35 20 36 44 20 36 31 20 72 65 6D 61
We can identify the bytes from offsets 04D9Fh through 04DFFh as part of a
Code Listing (in Assembly) for the CHKDSK program itself! When you view
the data in this format:
062B 206279746573 FRESPC: db " bytes remain available",13,10,13,10,"$"
2072656D61
you can see that "062B" is the offset within the program and since all COM
programs are loaded into offset 100h and following, this string should be
located at offset 52Bh from the beginning of the program's file and that's
exactly where we find the ASCII characters " bytes remain available" with
the trailing 0Dh,0Ah,0Dh,0Ah and "$" (24h) bytes.
We also learn that the author of CHKDSK.COM, must have used the .ASM label
of "FRESPC:" (presumably for "Free Space") to identify this ASCII string.
[Note: The digits "206279746573" and "2072656D61" are simply the ASCII code
for the characters: " bytes" and " rema" at which point the listing was cut
off by a new file in the next cluster.]
SYS.COM has 128 bytes of slack space, but they're all "F6" bytes.
DISKCOPY.COM leaves 320 bytes in Cluster 38 (Abs. sector 43), but the last
29 of them are all "F6" bytes. However, what remains are 291
contiguous bytes which are all part of an executable program
not found anywhere else on the diskette!
These bytes all appear to be part of a program that did "HEX to COM" file
conversions! This assumption is reinforced by the fact that much of the
data found in the slack space areas is in HEX file format! HEX files have
Record "lines" that always begin with a colon (:) [See special discussion
of Hex Data Records on our Forensic Examination page.]
Here we have a disassembly of the code we found, starting at offset 056C2h
of the diskette (offset C2h within Cluster 38; Abs. sector 43); which we
loaded into DEBUG at offsets 01C2 hex and following (you can see from the
location of the error message pointers at 01CC, 01D5, 021B and 0265 that
we made the correct choice):
01C2 3BFD CMP DI,BP
01C4 7602 JBE 01C8
01C6 8BEF MOV BP,DI
01C8 E2EE LOOP 01B8
01CA EBC9 JMP 0195
01CC BA9702 MOV DX,0297 ; -> File not found (error msg.)
01CF B409 MOV AH,09 ; DOS Int 21h Function 9
01D1 CD21 INT 21 ; Display '$'-terminated string
01D3 CD20 INT 20 ; Exit program execution
01D5 BAA602 MOV DX,02A6 ; -> Address out of...(error msg.)
01D8 E94300 JMP 021E ; where message gets displayed.
01DB 81FEE806 CMP SI,06E8
01DF 7509 JNZ 01EA
01E1 CD21 INT 21
01E3 3C01 CMP AL,01
01E5 7434 JZ 021B
01E7 BEE802 MOV SI,02E8
01EA AC LODSB
01EB 3C1A CMP AL,1A
01ED 7433 JZ 0222
01EF C3 RET
01F0 E82000 CALL 0213
01F3 8AD8 MOV BL,AL
01F5 E81B00 CALL 0213
01F8 D0E3 SHL BL,1
01FA D0E3 SHL BL,1
01FC D0E3 SHL BL,1
01FE D0E3 SHL BL,1
0200 0AC3 OR AL,BL
0202 C3 RET
0203 2C30 SUB AL,30
0205 72FB JB 0202
0207 3C0A CMP AL,0A
0209 7206 JB 0211
020B 2C07 SUB AL,07
020D 72F3 JB 0202
020F 3C10 CMP AL,10
0211 F5 CMC
0212 C3 RET
0213 E8C5FF CALL 01DB
0216 E8EAFF CALL 0203
0219 73F7 JNB 0212
021B BA7102 MOV DX,0271 ; -> Error in HEX file... (msg.)
021E B409 MOV AH,09 ; DOS Int 21h Function 9
0220 CD21 INT 21 ; Display '$'-terminated string!
0222 FF367000 PUSH [0070]
0226 C7066500434F MOV WORD PTR [0065],4F43
022C C60667004D MOV BYTE PTR [0067],4D
0231 BA5C00 MOV DX,005C
0234 B416 MOV AH,16
0236 CD21 INT 21
0238 0AC0 OR AL,AL
023A 7529 JNZ 0265
023C 33C0 XOR AX,AX
023E A37D00 MOV [007D],AX
0241 A37F00 MOV [007F],AX
0244 40 INC AX
0245 A36A00 MOV [006A],AX
0248 33D2 XOR DX,DX
024A 1E PUSH DS
024B 06 PUSH ES
024C 1F POP DS
024D B41A MOV AH,1A ; Int 21h Function 1Ah:
024F CD21 INT 21 ; Set Disk Transfer Area
0251 1F POP DS
0252 8BCD MOV CX,BP
0254 B428 MOV AH,28 ; Int 21h Function 28h:
0256 BA5C00 MOV DX,005C
0259 CD21 INT 21 ; Block Write to FCB File
025B 8F067000 POP [0070]
025F B410 MOV AH,10 ; Int 21h Function 10h:
0261 CD21 INT 21 ; Close File using FCB
0263 CD20 INT 20 ; Exit program execution
0265 BACF02 MOV DX,02CF ; -> Disk Directory full (error msg.)
0268 E964FF JMP 01CF ; where message is displayed,
; and program is exited!
0260 48 45 58 43 4F HEXCO
0270 4D 45 72 72 6F 72 20 69-6E 20 48 45 58 20 66 69 MError in HEX fi
0280 6C 65 2D 2D 63 6F 6E 76-65 72 73 69 6F 6E 20 61 le--conversion a
0290 62 6F 72 74 65 64 24 46-69 6C 65 20 6E 6F 74 20 borted$File not
02A0 66 6F 75 6E 64 24 41 64-64 72 65 73 73 20 6F 75 found$Address ou
02B0 74 20 6F 66 20 72 61 6E-67 65 2D 2D 63 6F 6E 76 t of range--conv
02C0 65 72 73 69 6F 6E 20 61-62 6F 72 74 65 64 24 44 ersion aborted$D
02D0 69 73 6B 20 64 69 72 65-63 74 6F 72 79 20 66 75 isk directory fu
02E0 6C 6C 24 ll$
DISKCOMP.COM leaves 412 bytes unused in Cluster 41 (Abs. sector 46). Let's
start with the first 169 bytes which you can use to create a
HEX file similar to this:
:1A051A00206D6F7265206469736B65747465733F2028592F4E29070D0A243C
:1A0534000D0A496E73756666696369656E74206D656D6F7279070D0A240DA7
:16054E000A496E76616C696420706172616D65746572070D0A24A3
:0000000000
The characters above in red were reconstructed later after identifying the
location of the other bytes; they were not used in the following display.
After loading this .HEX file into DEBUG, we have:
0524 65 74 74 65-73 3F 20 28 59 2F 4E 29 ettes? (Y/N)
0530 07 0D 0A 24 0D 0A 49 6E-73 75 66 66 69 63 69 65 ...$..Insufficie
0540 6E 74 20 6D 65 6D 6F 72-79 07 0D 0A 24 0D 0A 49 nt memory...$..I
0550 6E 76 61 6C 69 64 20 70-61 72 61 6D 65 74 65 72 nvalid parameter
0560 07 0D 0A 24 ...$
Further down in the slack space for this file, beginning at offset 005D80h
of the diskette, we find part of another assembly code listing. When you
view these bytes in a text editor, they'll look similar to the following:
6F7279070D0A
24
054D 0D0A496E7661 badfn: db 13,10,"Invalid parameter",7,13,10,"$"
We can see that the source code used a label 'badfn:' which presumably was
short for bad function since the error message is 'Invalid parameter.' The
only file on this diskette that both this piece of assembly listing and the
HEX file fragment above match is DISKCOMP.COM. Even though we find the same
bytes in DISKCOPY.COM, the strings must be located at file offsets 0424h
through 0463h, and that's true only for DISKCOMP.COM.
COMP.COM leaves 428 bytes unused in Cluster 45 (Abs. sector 50). Let's
start with the first 270 bytes which you can use to create a
HEX file fragment similar to this:
A456E7465D4
:1A06F3007220326E642066696C65206E616D65206F72206472697665206912
:1A070D0064070D0A240D0A43616E6E6F7420636F6D706172652066696C65EB
:1A07270020746F20697473656C66070D0A240D0A46696C657320617265204A
:13074100646966666572656E742073697A6573070D0A245E
:0000000000
Note that the last two lines beginning with ':130741' and then all zero
digits (:0000000000), is a good indication this is the end of the file.
program. Sure enough, after converting only the completely full lines of
this HEX file fragment to ASCII characters and searching for the bytes:
"r 2nd file name or drive id", 07h, 0Dh, 0Ah, "$", 0Dh, 0Ah,
"Cannot compare file to itself", 07h, 0Dh, 0Ah, "$", 0Dh, 0Ah,
"Files are different sizes", 07h, 0Dh, 0Ah, and "$", they match only the
last 97 bytes of COMP.COM on this diskette. Note: the 'A' at the very
beginning of the slack space is only half of a 0Ah byte followed by
"Ente" and all of these HEX file bytes occur at memory offsets 06EFh
through 0753h or file offsets 05EFh through 0653h.
The last 128 bytes of this slack space corresponds to part of an assembly
code listing that contains the following fragment:
iskette(s) and strike any key",13,10,"$"
Although there's no indication of where these bytes would be located when
loaded into memory, they are contained in only one file on this diskette:
COMP.COM. Interestingly, these bytes are stored in the file right before
those we found in the HEX file fragment above.
DATE.COM The length of DATE.COM is only 252 bytes; thus, it leaves 260
bytes unused in its single sector; Cluster 46 (Abs. sector 51).
Almost every unused byte is part of this HEX file fragment:
:1A0168008BC8E826008AC4B40003C8B42BCD210AC0750BCD20AC3C2F74219F
:1A0182003C2D741DBAC601B409CD21BC8802E9A0FFE80E0072EE8AE0E807C0
:1A019C00007204D50A8AE0C38A042C3072F93C0AF572F446C3D40A86C40D93
:1A01B6003030E802008AC49250B402CD215892C30D0A496E76616C69
Thought it's comprised of 252 characters, this HEX file fragment creates
only 102 machine code bytes (1Ah = 26 bytes/line). Looking at DATE.COM in
a hex editor, you won't find any ASCII strings before file offset 0C8h.
We confirmed that only part of one readable word ("Invali"; preceded by
0Dh, 0Ah) exists in the last line above. However, all the code bytes do
match those at file offsets 0068h and following, and no other file here.
TIME.COM This small program (of only 250 bytes) leaves 262 bytes unused
in Cluster 47 (Abs. sector 52). As with DATE.COM, almost every
byte of its slack space forms a single HEX file fragment:
:1A016800B42DCD210AC07502CD20BAC401B409CD21BC8602E9B2FFE81C0074
:1A01820072EE74178AE0E813007604D50A8AE0823C0D7405AC3AC375D70C0B
:1A019C00FFC38A043C0D74F92C3072F53C0AF572F046C3D40A86C40D303045
:1A01B600E802008AC49250B402CD215892C30D0A496E76616C696420
This fragment is very similar to the one found after DATE.COM; it creates
102 bytes in memory which end with the string: 0Dh, 0Ah, "Invalid " (from
offsets 01C4h through 01CDh). Each byte in the fragment matches perfectly
with those in TIME.COM (from file offsets 0068h through 00CDh) and as a
single piece of code it doesn't match any other file on the diskette.
MODE.COM leaves 164 bytes unused in Cluster 49 (Abs. sector 54), all but
1 byte of which is the HEX file fragment you see here:
:1A03F200696E746572204572726F722020202020200D0A243031323334357B
:1A040C0036373839240D0A446F20796F752073656520746865207269676805
:1A042600746D6F737420393F2028592F
This fragment creates the following characters in memory (from offsets
03F2h through 0431h): "inter Error " (that's six space characters
after 'Error'), 0Dh, 0Ah, "$0123456789$", 0Dh, 0Ah, "Do you see the
rightmost 9? (Y/". These character strings are found only in MODE.COM on
this diskette.
EDLIN.COM leaves 168 bytes unused in Cluster 54 (Abs. sector 59). If you
look at the last 128 of these bytes, it's a HEX file fragment:
5244E6F20726F6F6D45
:1A09A20020696E206469726563746F727920666F722066696C6524446973E4
:1A09BC006B2066756C6C2D2D66696C65207772697
with many bytes missing from the first and third lines. After converting
these bytes into machine code and examining them for any readable ASCII
strings, we found: "$No room in directory for file$Disk full--file wri"
(the beginning '5' and ending '7' digits are only one-half of a full byte
so we didn't use them). Using the HEX file memory offsets (099Ah through
09CBh) these bytes correspond only to those at file offsets 089Ah through
08CBh of the EDLIN.COM file.
DEBUG.COM leaves 95 bytes unused in Cluster 66 (Abs. sector 71). They're
all part of a HEX file fragment which displays the following
after being loading into DEBUG:
1730 49 42 IB
1740 4D 20 43 6F 72 70 20 31-39 38 31 20 4C 69 63 65 M Corp 1981 Lice
1750 6E 73 65 64 20 4D 61 74-65 72 69 61 6C 20 2D 20 nsed Material -
1760 50 72 6F 67 72 Progr
This would also be how the bytes appear in memory while running a program
that they're a part of. Searching for the same string on the diskette, we
found it in many files, but only in DEBUG.COM is it found at file offsets
0163Eh through 01664h.
LINK.EXE leaves 256 bytes unused in Cluster 151 (Abs. sector 156).
All of these unused bytes are nothing more than machine code bytes which
match perfectly with all the bytes from offsets: 001630h through 00163FFh
of the diskette in the LINK.EXE program itself. We have no real evidence
as to why this "reflection" of the LINK.EXE code exists in its slack space;
did they shrink it? Perhaps the file was simply deleted, then copied back
to the diskette again.
BASIC.COM leaves 384 bytes unused in Cluster 173 (Abs. Sector 178). But
most of those are nothing more than "F6" and "00" bytes. There
is, however, one very important piece of discarded data here:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
016480 C6 07 42 43 C6 07 32 43 C6 07 30 E8 1F FF 32 C0 Æ.BCÆ.2CÆ.0è.ÿ2À
016490 A2 05 01 E9 0C FB 44 45 43 2D 32 30 20 44 6F 77 ¢..é.ûDEC-20 Dow
0164A0 6E 6C 69 6E 6B 20 74 6F 20 42 6F 63 61 20 52 61 nlink to Boca Ra
0164B0 74 6F 6E 20 5B 33 30 30 2D 62 70 73 5D 20 20 20 ton [300-bps]
0164C0 20 39 2D 41 70 72 2D 38 31 0D 0A 0A 00 E9 00 00 9-Apr-81....é..
This is a fitting close to our survey of interesting data found in the slack
space of this diskette. For comments about the communications fragment which
includes a reference to Boca Raton, FL (see offsets 016496h through 0164C8h
above), read the section "Slack Space Data" on our "Forensics Examination"
page. Note: Although the bytes "C6 07 42 43 C6 07" were found in both the
BASIC.COM and BASICA.COM files, we couldn't match up the whole string to
either of them! It may be that BASIC was updated and these bytes are just
remnants of a former version.
Your comments are appreciated !
Last Update: January 26, 2006 (26-01-2006).
You can write to me using this: online reply form. (It opens a new window.)
IBM
PC DOS 1.00 Index
MBR
and Boot Records Index
The Starman's Realm Index