• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname

    Register

    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

A malware ploy and its roots in DOS history

Doug Kerr

Well-known member
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.

Best regards,

Doug
 

John Angulat

pro member
Doug, it's a history lesson that should be taught!
Sadly, most computer users under the age of 40 or so haven't a clue how they operate.
DOS? It's a foreign word they'd probably Google, or worse rely upon Wiki for education.
Thanks for taking the time.
The example given is very good, easy for non-users to understand.

...and yes, I'm old school. Like a few others here I grew up on paper tape, card decks and TTY's.
...and I still use DOS
 

fahim mohammed

Well-known member
Doug, I read this yesterday. Definitely a timely and lucid piece from you again.

I was bought up on analog computers and then on dec/unix. Teletypes were used for dungeons and dragons. The s-100 bus, the imsai machines on pcs. The cp/m os. Dates me. I still have a zilog z-80
stashed away somehere, the precursor to the intel chip ( 8080 ? ).

Anyways DOS it was and DOS it still is; eh?

Thanks for sharing.
 

Doug Kerr

Well-known member
I still have a zilog z-80
stashed away somehere, the precursor to the intel chip ( 8080 ? ).
Actually the Zilog Z80 came after the 8080 - sort of on the way to the 8086. My first real computer was a Timex-Sinclair Z80 (with a Z80 CPU). That's how I learned "Intel-style" machine language programming and then assembly language.

It seems a million years ago - or maybe just yesterday!

Best regards,

Doug
 

Martin Evans

New member
Doug, it's a history lesson that should be taught!
Sadly, most computer users under the age of 40 or so haven't a clue how they operate.
DOS? It's a foreign word they'd probably Google, or worse rely upon Wiki for education.
Thanks for taking the time.
The example given is very good, easy for non-users to understand.

...and yes, I'm old school. Like a few others here I grew up on paper tape, card decks and TTY's.
...and I still use DOS

May I add my own thanks to Doug. I too began with CP/M, teaching myself assembly language for the Z80 on the old Amstrad PCW (which my technophobe wife still insists on using for all her word processing!). The PCW also runs a pretty pure version of CP/M and I managed to write a couple of useful small .com utilities. Thanks Doug for explaining the difference between .com and .exe programs. I had never really understood, except that when I found myself offered a free course in programming in 'C' (at Her Majesty's expense) I had to get used to the fact that it created relatively huge .exe files.

Delighted to know that you, John, still use DOS. I still find it essential, because the old database system: PC File (Buttonware) is far superior, for my purposes, to Access or its clones. I have to use PC File for my list of UK maritime museums, and dread the day when it will not be possible to use a quasi-DOS window on a PC.

Martin
 
Top