agray@citasim.UUCP (andrew gray) (10/13/89)
I was just thinking about trojans and such that infect the COMMAND.COM file, and I got a weird idea: I renamed COMMAND.COM to FIZZGIGG.FOO and placed a 'shelll=c:\fizzgigg.foo /p' statement in my CONFIG.SYS file. My system booted exactly like normal. This got me to wondering about COM and EXE files, and whether there would be any way to fool MS-DOS (or command.com) into using other extenders for executable files, and ignoring COM and EXE altogether. Seems to me that this would add a small modicum of protection against trojans or other programs that corrupt executable files. Has this been done? Is it possible? --- "...in the spirit of hobbyist computing" ...apple!spies!citasim!%s Spies in the Wire, PUBLIC ACCESS UNIX (408) 867-7400
c37189h@saha.hut.fi (Suomalainen Harri Olavi) (10/15/89)
In article <00092@citasim.UUCP> agray@citasim.UUCP (andrew gray) writes: > > This got me to wondering about COM and EXE files, and whether there >would be any way to fool MS-DOS (or command.com) into using other extenders >for executable files, and ignoring COM and EXE altogether. > Has this been done? Is it possible? It sure is easy to do. You could do it the following way: 1. Rename file.com or file.exe to eg. file.foo . When you're willing to run it 2. type file.foo . If it has an exe signature it will be considered as an .exe file, if not as .com! I tried it this way and it did work! --- E-mail: c37189h@saha.hut.fi * If you're feeling good, don't * UUCP: ...!mcvax!santra!saha!c37189h * worry - You'll get over it! *
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (10/17/89)
In article <00092@citasim.UUCP> agray@citasim.UUCP (andrew gray) writes:
$ I was just thinking about trojans and such that infect the COMMAND.COM
$file, and I got a weird idea:
$ I renamed COMMAND.COM to FIZZGIGG.FOO and placed a 'shelll=c:\fizzgigg.foo
$/p' statement in my CONFIG.SYS file.
$ My system booted exactly like normal.
$ This got me to wondering about COM and EXE files, and whether there
$would be any way to fool MS-DOS (or command.com) into using other extenders
$for executable files, and ignoring COM and EXE altogether.
$ Seems to me that this would add a small modicum of protection against
$trojans or other programs that corrupt executable files.
This will work fine as long as no programs you run have to shell out
to DOS. If one of them does, though, you're in trouble.
The loader in COMMAND.COM recognizes only two types of files: .COM and
.EXE. When a program tries to shell out, it calls the loader, which tries to
figure out what the *&$% to do with a .FOO file. You don't have this problem
on bootup because it isn't the loader that's loading COMMAND.COM (or
FIZZGIGG.FOO) ... at boot-time, all it does is a straight binary load of
whatever file you tell it to load. It will load and try to execute a
text file if you really want it to.
Anyway, to get DOS to use files other than .COM and .EXE, you'd have to
change COMMAND.COM to recognize your other extensions. The easiest way to
do this would be just to change the bytes .COM and .EXE to whatever you want
to use. Fine, until you try to run a program such as Lotus Symphony's
Access which has the normal extensions built-in ... it will then complain.
Alternatively, you can write your own COMMAND.COM replacement, complete
with a new loader that recognizes more than just .COM and .EXE ... but that
will take time on the order of man-months.
Sorry.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
**************************************************************************
Maybe if we're lucky they will show it again, such a terrible thing to seefrisk@rhi.hi.is (Fridrik Skulason) (10/20/89)
In article <253B310B.23002@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: >In article <00092@citasim.UUCP> agray@citasim.UUCP (andrew gray) writes: >$ I was just thinking about trojans and such that infect the COMMAND.COM >$file, and I got a weird idea: >$ I renamed COMMAND.COM to FIZZGIGG.FOO and placed a 'shelll=c:\fizzgigg.foo >$/p' statement in my CONFIG.SYS file. : : >$would be any way to fool MS-DOS (or command.com) into using other extenders >$for executable files, and ignoring COM and EXE altogether. >$ Seems to me that this would add a small modicum of protection against >$trojans or other programs that corrupt executable files. > > This will work fine as long as no programs you run have to shell out >to DOS. If one of them does, though, you're in trouble. Another problem is that this will not provide much protection. You will be protected against some viruses, in particular so-called "direct-action" viruses, that search the disk for new files to infect, but this will not provide any protection against viruses that stay resident, and infect programs as they are run. Also, a virus could easily find (and infect) COMMAND.COM, evinen if it has been renamed, just by checking the COMSPEC variable. -- Fridrik Skulason University of Iceland frisk@rhi.hi.is Guvf yvar vagragvbanyyl yrsg oynax .................
john@wsl.UUCP (John Allen on wsl) (10/21/89)
In article <253B310B.23002@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: > > The loader in COMMAND.COM recognizes only two types of files: .COM and >.EXE. When a program tries to shell out, it calls the loader, which tries to >figure out what the *&$% to do with a .FOO file. You don't have this problem >on bootup because it isn't the loader that's loading COMMAND.COM (or >FIZZGIGG.FOO) ... at boot-time, all it does is a straight binary load of >whatever file you tell it to load. It will load and try to execute a >text file if you really want it to. > The loader in COMMAND.COM is only used on two occasions:- 1. When issuing a command at the prompt. (it also recogizes .BAT) 2. When execing COMMAND with a /C The MS-DOS exec/load program functiion call will load the file specified and execute it. This function requires the full path name. Therefore any program that provides a shell out faciltiy must use the COMSPEC environment variable or (very bad programming) hard code the name "COMMAND.COM" directly into the app. All programs that shell out do not necessarily use COMMAND.COM.
unkydave@shumv1.uucp (David Bank) (10/22/89)
Actually, COMMAND.COM (the parser) recognizes THREE file extension.
".COM", ".EXE", and ".BAT"
When you enter a command at the command line. DOS first checks to
see if it is an internal command ("CLS" or "VER" for example).
If not, it then checks to see if the command was the name of a
".COM" file. After that, ".EXE" and finally ".BAT"
If nothing comes back, it's time for "bad command or filename"
Unky Dave
unkydave@shumv1.ncsu.edukjeld@iesd.auc.dk (Kjeld Flarup) (10/23/89)
In article <253B310B.23002@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: > Alternatively, you can write your own COMMAND.COM replacement, complete >with a new loader that recognizes more than just .COM and .EXE ... but that >will take time on the order of man-months. I wrote a small and primitive one this weekend. he spawn command in MicroSoft C uses the DOS exec call and will load any file. Anyhow look at the two first bytes in a .exe file, they are always the same and they will not appear first in a .com file because they make very little meaning to execute. -- * I am several thousand pages behind my reading schedule. * Kjeld Flarup Christensen kjeld@iesd.auc.dk
rick@NRC.COM (Rick Wagner) (10/24/89)
In article <4263@ncsuvx.ncsu.edu> unkydave@shumv1.uucp (David Bank) writes: > > Actually, COMMAND.COM (the parser) recognizes THREE file extension. >".COM", ".EXE", and ".BAT" > > When you enter a command at the command line. DOS first checks to >see if it is an internal command ("CLS" or "VER" for example). > > If not, it then checks to see if the command was the name of a >".COM" file. After that, ".EXE" and finally ".BAT" > > If nothing comes back, it's time for "bad command or filename" > >Unky Dave >unkydave@shumv1.ncsu.edu The annoying thing is that it will ignore an explicit extension, using just the root part of the name, and following the search rules above. Once I tried to write a batch file "PLAY.BAT" which would decompress a game file into a temp. directory, and run the program. I wanted the ability to optionally include another batch file in the archive (ZIP-hive?;)), which would do any unique setup and cleanup for the game (such as updating the score file back into to the archive). What I intended was to be able to type PLAY X. Using a a set of searchs on "X", if it found that "X.ARC", or "X.ZIP", etc, existed, it would un-archive it. If the un-archiving yielded a file "X.BAT", it would explicitly run that. Typically the "X.BAT" file would run the game by explicit name ("X.EXE"), and then update the score file when the game finished. What I found instead was when PLAY.BAT tried to invoke X.BAT, explicitly giving the .BAT extension, COMMAND would strip off the .BAT, use its search list, and run the X.EXE file instead. Poop! --rick -- =============================================================================== Rick Wagner Network Research Corp. rick@nrc.com rick@nrcvax.UUCP 2380 North Rose Ave. (805) 485-2700 FAX: (805) 485-8204 Oxnard, CA 93030
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (10/29/89)
Fridrik Skulason writes: $>andrew gray writes: $>$would be any way to fool MS-DOS (or command.com) into using other extenders $>$for executable files, and ignoring COM and EXE altogether. $>$ Seems to me that this would add a small modicum of protection against $>$trojans or other programs that corrupt executable files. $Another problem is that this will not provide much protection. You will be $protected against some viruses, in particular so-called "direct-action" $viruses, that search the disk for new files to infect, but this will not $provide any protection against viruses that stay resident, and infect programs $as they are run. This is true ... does anyone know the rough proportion of viruses that search for files to infect against those which infect programs that you run? $Also, a virus could easily find (and infect) COMMAND.COM, even if it has $been renamed, just by checking the COMSPEC variable. Yes, but don't forget that every time you add some complexity to a program, you add to its size. For a virus, size is a fairly important characteristic. The size cost of adding checks for the COMSPEC variable is not too great; however, if you look at all of the nifty things that one can do to try to confuse viruses (changing file attributes, renaming your files if it works, etc.), a virus which tried to defeat all such mechanisms (or even many of them) would soon grow pretty big, and would then likely have to specialize in infecting only larger .COM or .EXE programs to decrease the likelihood of detection - if you suddenly found that the ASK utility you may use for asking questions in batch files grew from 509 bytes to 8.3K, you'd become suspicious pretty quickly. (BTW, if anyone wants such a program, e-mail me a note saying you want ASK.COM ... this one is public domain and guaranteed free of infection when it leaves my mailbox) -- Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca <std_disclaimer.h> = "\nI'm only an undergraduate!!!\n"; ************************************************************************** ... but I'm too full to swallow my pride ...
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (10/29/89)
In article <270@wsl.UUCP> john@wsl.ie (John Allen on wsl) writes:
$The loader in COMMAND.COM is only used on two occasions:-
$ 1. When issuing a command at the prompt. (it also recogizes .BAT)
No, that's handled by the transient part of COMMAND.
$ 2. When execing COMMAND with a /C
The loader in COMMAND.COM (which stays resident once you've run
COMMAND.COM/P) loads all .EXEs and may load .COMs, too (I'm not sure
on that count, since all you have to do for them is load them straight
from disk to memory). This is the case for DOS versions prior to 4.
In DOS 4, they must have migrated the loader down one step into DOS,
as you can install .EXEs from the config.sys file, which you could not
do previously.
$The MS-DOS exec/load program functiion call will load the file specified
$and execute it. This function requires the full path name. Therefore any
$program that provides a shell out faciltiy must use the COMSPEC environment
$variable or (very bad programming) hard code the name "COMMAND.COM" directly
$into the app. All programs that shell out do not necessarily use COMMAND.COM.
Yes, this function requires the full path name because the entity which
implements the PATH (that being the transient part of COMMAND.COM) may not
be there every time the exec function is called. Hard-coding COMMAND.COM
in is bad programming for more than one reason:
1. Someone may have renamed COMMAND.COM
2. The person may not be using COMMAND.COM
3. If we are not currently in the root directory of the boot disk, this
will fail unless you search for COMMAND.COM on all of the machine's
hard disks ... this will fail if it was booted from a floppy ...
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
**************************************************************************
... but I'm too full to swallow my pride ...Ralf.Brown@B.GP.CS.CMU.EDU (10/29/89)
In article <254A1EE4.6157@maccs.dcss.mcmaster.ca>, cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) wrote: > The loader in COMMAND.COM (which stays resident once you've run >COMMAND.COM/P) loads all .EXEs and may load .COMs, too (I'm not sure >on that count, since all you have to do for them is load them straight >from disk to memory). This is the case for DOS versions prior to 4. >In DOS 4, they must have migrated the loader down one step into DOS, >as you can install .EXEs from the config.sys file, which you could not >do previously. Not true. The loader was in a second transient portion of COMMAND.COM in PC-DOS 2.x *only*. It is a resident part of IBMDOS.COM (or MSDOS.SYS) in MS-DOS 2.x and both MS-DOS and PC-DOS 3.x. The loader loads both .EXE and .COM. (For what it's worth, the loader was in the COMMAND.COM transient portion in DOS 1.x) -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 FAX: available on request Disclaimer? I claimed something? "How to Prove It" by Dana Angluin 6. proof by omission: "The reader may easily supply the details." "The other 253 cases are analogous."
frisk@rhi.hi.is (Fridrik Skulason) (10/30/89)
In article <254A1CA0.5798@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: > > This is true ... does anyone know the rough proportion of viruses that >search for files to infect against those which infect programs that you >run? Here is the list. Viruses marked with * can be considered "common". Those marked with - are very rare. Direct Action viruses: - DataCrime - DataCrime II - 405 - Ghost - South African - SysLock * Vienna Resident: - Agiplan - April 1st. * Cascade - Dbase Fu Manchu - Icelandic * Jerusalem Lehigh Mix1 - Screen Vacsina Both: - Oropax Traceback I have not yet had time to look at the following four "new" viruses: - Aids - Alabama - Dark Avenger - Yankee >a virus which tried to defeat all such >mechanisms (or even many of them) would soon grow pretty big, and would then >likely have to specialize in infecting only larger .COM or .EXE programs >to decrease the likelihood of detection - if you suddenly found that the >ASK utility you may use for asking questions in batch files grew from >509 bytes to 8.3K, you'd become suspicious pretty quickly. Well - the minimum size of a virus is around 400 bytes (assuming it is written in assembly language, like most viruses are). Adding code to remove read-only protection etc. can add 200-300 bytes to the code. The rest of the virus code - the "damage" part - can be anything from 0-3000 bytes in the viruses that are known today. Many of them use a number of tricks to bypass protection methods, but they simply are not very large. Their size is from 405-3555 bytes, in most cases around 1800 bytes. The "Aids" virus, which is written in Turbo-Pascal is of course much larger, around 12K. -frisk -- Fridrik Skulason University of Iceland frisk@rhi.hi.is Guvf yvar vagragvbanyyl yrsg oynax .................