|HOME FORUMS NEWS FAQ SEARCH|
A malware ploy and its roots in DOS history
A clever ploy used to trick recipients of a malicious e-mail into executing a malicious file has its roots in the lack of awareness today of a "historical" aspect of DOS-based operating systems.
Consider an early DOS installation (although in fact this technical detail actually goes back to the CP/M operating system). The user had available a repertoire of DOS "commands". These were short character sequences which, when entered at the "DOS prompt", and triggered by pressing Enter, would cause the computer to perform some housekeeping function.
An example was the command dir ("directory"). When triggered, it would cause the computer to send to the "standard output" (hopefully, a CRT-based display, but in the earliest times often only a character-serial teletypewriter printer) a listing of the contents of the current disk directory.
Doing this of course required a "program", a piece of executable machine-language code. This code was a part of the operating system (the Command Processor, in fact), and thus was already resident in memory.
When the user entered dir, the Command Processor looked for that in its dispatch table, found it, and got from the table the relative memory address of the first machine instruction in the dir code, pointed the CPU instruction register to that, and let 'er rip.
Such commands were known as "internal commands".
Another operating system command was chkdsk ("check disk"), which caused the system to perform certain consistency checks on the file structure of one of the computer's disks. This of course also required some code. As that code was somewhat larger than the code for dir, and the command would be far less frequently used, the code was not embedded in the Command Processor (so it would already be in memory). Rather it was carried in a file, perhaps on the hard disk (if any) or, hopefully, when needed, on the floppy disk currently in place.
Such commands were known as "external commands", and the files carrying their executable machine language files were given file type extension "COM".
When the user entered chkdsk and pressed Enter, the Command Processor looked for "chkdsk" in its dispatch table, and didn't find it. So it then looked on the current disk for a file named chkdsk.com. If it found it, it loaded it into memory (all of it), pointed the CPU instruction register to the first byte of that memory image (where the first instruction of the chkdsk code began), and let 'er rip.
Now perhaps we would purchase a "utility program", one that would give us spiffy directory listings with more detail than the DOS dir command. Perhaps it was called "Directory Plus", and we got it as an executable machine language file named dirplus.com, which we copied onto our hard disk (or onto some of our floppy disks).
As with chkdsk, when we entered dirplus and pressed Enter, the result was that this file was loaded (all of it) into memory, and its execution begun with its first instruction, which began at the first byte of the file. So it was in fact considered a "DOS external command". As a "command", its mandate to the computer was "give us a spiffy directory listing".
Now suppose we bought a word processor, "WordWizard" It came to us as an executable machine language file named wwiz.com. We load that onto disk. When we then entered wwiz at the DOS prompt and pressed Enter, this file was loaded (in its entirety), and its execution begun with its first byte, just as before.
Although we tended to think of this file as being for an "application", to the DOS wonks, it was just another "external command" (and so the file's extension, "COM", seemed right on the mark). As a command, its mandate to the computer was "become a word processor".
Before long, a more sophisticated way of managing "application executable machine language code files" was developed. Here, when an application was summoned, and its executable machine language file found, the operating system loaded a "preface", which then told what portion of the file (only) should be loaded right now into memory, and where the first machine instruction was located in that. Execution stated there, but in the course of the operation of the program, it might call for further portions of the file to be loaded as needed for the routines that were needed (perhaps freeing memory space by overwriting portions of the code that might not be needed again soon).
To allow the operating system to realize which form of executable machine language file it was dealing with, these files are given file type extension "EXE" (executable). Of course, they were no more or less "executable" than the "COM" files.
Still, today, when COM files are mentioned, it is often said that, "Oh no, those are not executable files - only EXE files are." (No, they are the only ones named "executable" (the com files are named "command"").
Today, almost all machine language executable files are of the "EXE" type (although our system will gladly run a COM file if that's what the command processor finds when we enter dirplus and press Enter).
Now to the original excuse for this little history lesson: the malicious ploy.
You receive an e-mail message that has attached a malicious executable file with filetype extension COM.
Incidentally, it need not actually have the "old" executable structure - today's command processors will gladly find a file with either the COM or EXE extension, and determine what structure is has by looking for the signature at the beginning of every EXE file - the ASCII character string "MZ", the initials of Mark Zbikowski, a key developer of the EXE structure. So this could be an executable machine language file of the "EXE" form which the operating system would be happy to execute.Perhaps the filename is cutegirls.com.
Your e-mail handler displays that filename, underlined (just as it might if a JPG file had been attached). That looks to you like an Internet domain name, so perhaps you click on it.
But your e-mail handler knows that this is the filename of an attached file, which it recognizes as of the executable type (EXE subtype). So the e-mail handler, working in connection with the operating system "shell", may decide that what that file, having been clicked upon, needs is to be executed. And it does so.
Maybe the result is that you've become engaged to a cute girl in Nigeria, and the bride price has been charged to your American Express card.