Fred Cisin wrote:
On Sun, 20 Sep 2015, Jon Elson wrote:
Well, one would assume this is also OS specific.
I would guess it
would be incredibly hard to make a "disk" virus that would work on
greatly differing OS's like Linux AND Windows. No telling what would
happen if one of these disk viruses got onto a hard drive on a
Windows system and then the drive was reformatted and loaded with Linux.
Most likely you'd have odd crashes or something.
It is possible to create an executable file that identifies the OS
that it is running on and does a conditional jump to different code,
assuming that the processor uses the same instruction set.
How different the OS's are would determine how much code could be
shared. If they are very different, then the executable file could be
twice as large, with no code in common.
It is even possible to make a disk that is readable as multiple disk
formats, so long as each is expecting the DIRectory tracks to be in
different places.
One of the many projects that I never got ready for market was to make
a multi-platform distribution format for software. "Save a few cents
on media costs by putting all of your platforms on one disk" But,
after August 1981, it eventually became apparent that the need for
such was not going to be around much longer.
If the boot code is short enough, it is even possible to have an FM,
an MFM, and a GCR boot sector in the same boot track, since each will
not even see any except its own. Formatting/recording a track with
mixed densities and/or encodings and multiple sector sizes is not a
supported function in most operating systems, nor even FDCs, but can
be done with some flux transition controllers.
I used the above example when I created a CD which had files to be used
with RT-11 in addition to being a normal CD under Windows. I found that
for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
on the CD were empty. I don't know if that area is reserved for boot code
under Windows when the CD is bootable, but my goal did not require the
CD to be bootable under Windows.
Under RT-11, the first six hard disk blocks (0 to 5) are reserved for boot
code (when that is present) and hard disk blocks from 6 up to 67 are used
for an RT-11 directory. RT-11 rarely uses that large a directory and the
minimum directory is only two hard disk block long. For the CD, that
allowed an RT-11 directory from hard disk blocks 6 to 63 or up to
sector 15.
What may have been unique was that only the RT-11 directory and the
CD ISO directory were distinct. Otherwise, all the files were the same
with each directory pointing to the same location on the ISO image.
In practice, the same CD could be used as a data CD under Windows
in addition to being a boot disk on a real DEC RT-11 system which
supported that operating system. I was actually on the phone at one
point when the first individual who received a copy of the CD used
it to boot RT-11 on a CDROM drive configured to support 512 byte
blocks using a CQD 220/TM host adapter.
The same ISO image file can also be used under both SimH and Ersatz-11
in the same manner, although it is STRONGLY recommended that the
ATTACH or MOUNT command use the ISO image file as READ ONLY.
Ersatz-11 is also able to MOUNT the actual RAW CD on a CDROM
SCSI drive and boot RT-11 from the CD. Of course, the Windows
operating system under which Ersatz-11 is also able to see all the same
files on the CD as well, BUT NOT AT THE SAME TIME - at
least I never did attempt that possibility.
If this can be done with Windows and RT-11 which have completely
different file structures and instructions sets, it certainly seems likely
that other operating systems and system hardware can also be supported.
The one thing that seemed reasonable from a security point of view is
that the CD is READ ONLY, so no virus can be introduced on the
CD after it is burned.
Tim Shoppa did almost the same thing with his RT-11 Freeware CD
when an RT-11 directory was added at the end of the ISO image file
for the CD.
If anyone finds this interesting and has additional questions, please ask.
Jerome Fine