Introduction
In the old goodtimes there were nothing easier as infecting COM file. But the Microsoft went to market with his Windoze 9x series of betas. This has changed some COM files and near the EOF we started to see string 'ENUNS' followed by word with various value. This is apparently some kind of checksum or other security shit. Many virus coder solved the this problem simply by avoiding the infection of such a modified COM files.

Research part
But as we all know, Microsoft is lame company and its programmers are morons. So let's take a closer look what does such a ENUNS file in action. We will pick up a handy and short file from directory C:\WINDOWS\COMMAND - file choice.com

If we 'll play a little bit with hex editor and we 'll add some extra bytes to the end of the file, after running CHOICE.COM without any command line parameters, we will see

instead of the usual

This means - file is corrupted ...

Let's start debuging this file. After couple of jumps and calls we land in following code

The code above opens the file which is run (choice.com)

Call to the test_ENUNS seem to be quit important. Closer look shows what this procedure does:

The routine seek to EOF-7 and read last 7 bytes of the file to some buffer. Filesize is saved on this occasion.

Location EOF-4 is checked for presence of string 'NS'.

Word at location EOF-2 is subtracted from the file size and result is stored.

From our (virus) point of the view is decising the call to cs:0xC2B.

File pointer is moved to the location (filesize-(word at EOF-2))

Read form inside the file is performed.

Location inside the file is checked for presence of string 'NS'. This is what the program does with the magic 'ENUNS' shit. Quit lame and interesting at the same time. Well as we know what the does, we should try to create some workaround.

What do we need?
There are two requests for elegant solution of the problem

  1. User should see at the EOF-7 the string 'ENUNS' followed by word containing "magic value".
  2. File has to pass its internal controll routine.

Solution
We take common non-overwriting appending COM infector. If we choose some ENUNSed targed and we will infect it in normal way, the proggy with virus on its end will have no 'NS' at EOF-4. In the very rare case it will have 'NS' there, word at EOF-2 sends the file pointer somewhere in deep space 9 and the next check will fail. Therefore solution of the problem is

  1. Read last 7 bytes of file to some buffer
  2. Infect the file as usual
  3. Handle ENUNS protection

As we need to have at least 'NS' at EOF-4, in the line of our elegant solution we will add there 'ENUNS' string. Then we need to adapt the word at EOF-2 in such a way it will point to the location it pointed before the file was infected.

The word located at EOF-2 is subtracted from file size - it could be expressed as follows

uninfected situation:

but when the file is infected the situation is

Resulting pointer is now "somewhat" incorrect from our viral point of the view. This dramatic equation is easy to solve just by moving some shit from left to right side of the equation...

note: under the term "added code" you should understand our 2nd 'ENUNS??' string.

Dear readers, the solution for the ENUNS problem is just to copy the last 7 bytes from the target file to the end of the virus body with only one change - to the value of last word in the file we simply add the size of all appended code including our duplicite ENUNS?? string.

And here comes the demonstration of the above mentioned solution. Download example