textfiles/virus/virs.vir

////////////////////////////////////////////////////////////////////////////
from Meridian Systems, Haslett (Lansing), Michigan
multi-line service
Dr. Gordon Williams sysop (517) 339-3783
                          (517) 339-0091, etc., overflow

Meridian systems serves as the format for State Senator William Sederburg's
"Political Forum".  Dr. Williams and Dr. Ken Salzman host a Human Services 
Forum.  Dr. Glenn Keeney of MSU's Computer Science department hosts discussion 
of programming and provides downloads from "Computer Language" and "AI Expert" 
magazines. 

UPCO is a local computer user group that contracted BBS services in order to 
support their club.  Message base 8 was opened for discussion of viruses. 

Lawrence Kestenbaum served as a County Commissioner for several years before 
moving on to grad school at Cornell.  He provided a copy of the Jerusalem B 
virus.

Mike Marotta (:-) is a technical writer.  His works have appeared in magazines 
for IBM and Data General users, Defense Computing, Plan & Print, etc.  He is 
the author of a book on codes and ciphers. 
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Msg#:39943 *UPCO Discussion*
09-24-89 13:03:21
From: MIKE MAROTTA
  To: LAWRENCE KESTENBAUM (Rcvd)
Subj: JERUSALEM B
I spent the morning with Jerusalem B and these are my preliminary results.
        Naturally, I made backups, etc.  I even made a new DOS diskette to use.
I gathered to this diskette some utilities such as LW86 (displays assembler 
mnemonics and their syntax), CALC (for hex arithmetic), LIST and BROWSE, 
FSDEBUG and plain old DEBUG, etc.  I used the infected files to build a "dirty"
diskette with NU.EXE, COMP, and some of my own COM and EXE programs.  XDIR.EXE 
was written in C by a friend of mine.  I wrote RED.COM, BLUE.COM and 
PRTSCR.COM.  RED and BLUE are 32 bytes each and change the screen colors. 
PRTSCR is 4 bytes and does a "print screen".
        I found that NU.EXE reaches a top limit of 155k bytes (started at 
148K).  About 5 re-infections seems to be the limit.  COM files were infected 
just once each.  Re-infection, growth in file size) did not occur.
        Here's what I see happening.  You run a dirty program.  It goes to 
MEMORY and alters the image of COMMAND.COM.  When you run a clean program, it 
gets infected.  When the date is Oct 13, 1989 and you run an EXE or a COM, the 
file deletes itself.  Some of these (XDIR, e.g.) ran once on "Oct 13" but then 
erased themselves on the second call.
        Here is what is NOT happening.  You run a dirty program and it infects 
all COM and EXE files.  I ran NU.EXE time after time.  WHile NU got bigger, 
nothing else did.
        If you run a clean program AFTER a dirty program has been run, the 
clean program gets infected.
        Because PRTSCR.COM, etc., are so small, I'll know in a few spare time 
hours, just what the viral code is.  (more later)


Msg#:39950 *UPCO Discussion*
09-25-89 01:05:45
From: MIKE MAROTTA
  To: LAWRENCE KESTENBAUM (Rcvd)
Subj: JERUSALEM B
(Jesuralem is also easy to type and it even contains JESU...)
*
        I spent a total of 8 hours with JB, drank a beer, passed out and here I
am 6 hours later.  Some details.  EXEs keep getting infected, at least some of 
them can.  COMs get infected once.  I wrote a program to output the letter A. 
As a COM file it grew once.   The program to output the letter Z, left as an 
EXE grew until it crashed.  (CLean it took only 32 bytes.  Maybe the small 
size, you see.)  Now, ATTRIB.EXE grows forever, but it starts at, what? 6K? I 
got it up to 22K and still hoggin'.  The increment is 1808 bytes.
*
        I listed the disassembled code (hope that doesn't violate the implicit 
contract I entered into when I took the diskette out of the sleeve) via 
DIS86PC.  (Some work here...Data and Code being equal, DIS86PC had some 
interesting opinions about how to "execute" the "program fragment" COMMAND.COM)
The virus opens with a JUMP, so I took it from that argument, byte 195 forward.
*
        I found the TSR function, a DATE function, lots of read and write 
functions, a few interrrupt vectors and lots of calls to memory locations near 
0000:0000 to 0000:001F.  (Oddly enough the DATE checks only for the YEAR 1987. 
I have yet to find 0A 0D = 10 13 but we'll see what tomorrow brings.)
        You know that looks a lot like 0D 0A, the CR LF pair ...


Msg#:39952 *UPCO Discussion*
09-25-89 01:48:18
From: MIKE MAROTTA
  To: GORDON WILLIAMS (Rcvd)
Subj: VIRUS, CONT.
I just rebooted and set the date to January 13th.  (also a Friday) and the two 
executables I ran deleted themselves.
*
The Jerusalem B virus looks for and sets the file attributes with function 43 
of INT 21.

Msg#:39958 *UPCO Discussion*
09-25-89 18:58:45
From: MIKE MAROTTA
  To: LAWRENCE KESTENBAUM (Rcvd)
Subj: JERUSALEM B
(It's getting easier to type Jerusalem... Let's hope no one invents a 
Massachusetts or Connecticut virus...Then there's Azerbaidzhan and don't forget
Armenia's important city, Ordzhonikidze  though perhaps virus wars would be 
preferable to ethnic rioting...)
*
        I found where JB looks for date and day.  I'm  about 2/3 through now 
and I must say, I have respect for the programmer.  Error trapping and 
failsafes all over the place.  The guy knows how to save a byte, also.  If he 
knew that the argument for a call is something, he moves the whole word into AX
instead of MOV AH,12 and MOV AL,34.  He likes to PUSH and POP.  This is the 
"real programmer's" way.  Me, I just MOV in again what I wished I'd PUSHed. 
The program checks for disk type, and of course, changes the ATTRIButes of the 
file.  Lots of error trapping. And it's TSR.  Neat.
*
        Now the next phase is to write a counter-program.  One that looks in 
these places for this and that code and if the code is there, then you change 
it so it's harmless. I already wrote some of this.  I have a program called 
FOXY that goes to COMMAND.COM on a floppy and changes the program with no 
alteration in size or date.  After being acted upon by FOXY, COMMAND.COM boots 
with a message: "I am alive and I have rights."
*
        By the way, the monstrous size of ATTRIB (now at 66K) indicates 
Jerusalem B does NOT write to the "slack" area of a file.  That in itself is a 
challenge.  You can't do all that error trapping in a 256 bytes. Also, the 
reason that FOXY acts only on floppies (and B: at that!) is to avoid just such 
hassles.  The program is 32 bytes long and only because I allowed dead space 
between the code and the message. I could still tighten it up...  But that 
would leave maybe  16 bytes for error trapping.

Msg#:40038 *UPCO Discussion*
10-01-89 09:33:31
From: MIKE MAROTTA
  To: VIRUS HUNTERS
Subj: JERUSALEM B, CONT.
I must be making progress, I now have more questions than answers....
.       sUMsDos is the virus identifier tag.  At least this string appears at 
the head and tail.  Of course, we have seen that EXE files are always 
re-infected, so this mechanism is not perfect.  Also, near the tail of the 
virus is the string EDLIN.  
        I looked at EDLIN and it has a lot of open space, most of it at the end
of the file.  In all, EDLIN has about 2500 bytes available.  The Jerusalem B 
virus runs 1808 bytes.  (This is hardcoded into the virus in several places, 
e.g., MOV CX,0710 before an INT 21 function call.)  I wonder if EDLIN.COM was 
the first host, or perhaps the first intended host.  
        The string COMMAND.COM also shows up.  However, infection of 
COMMAND.COM doesn't go well.  Mine crashed when I tried to invoke another DOS 
shell.
        It has been suggested that JB does NOT infect COMMAND.COM in order to 
make it less detectable, especially asfter the discovery of the "40th 
Anniversary Virus" which infected the command processor.
        I have expressed by admiration for the great attention given to detail 
in JB, but now I'm not so sure it is all necessary.  Now that I have worked my 
way 100% thru the disassembly, I find many block of code that make no sense. 
They do work, but WHY is hardly clear.  (How many times can you PUSH and POP a 
register, load it, add to it and then not use it?
        As for an antidote, Jerusalem B writes itself to the head of a file, or
if you like, it moves the original program down 1808 bytes.  I believe that a 
program that checks three small blocks of code can identify this virus and then
render it harmless by either filling those bytes with 00s, all 1808 of them, or
if more sophisticated, zero out only the bytes of code that do critical work. 
We'll see.

Msg#:40219 *UPCO Discussion*
10-08-89 21:55:55
From: MIKE MAROTTA
  To: DENNIS HILL
Subj: REPLY TO MSG# 40193 (SCAN VIRUS 40)
I tested SCAN40 on the Jerusalem B and it works.  I also infected SCAN40 and 
before it did anything else, it detected its own infection.
*
        I went back to an article I wrote on viruses in January 1989 and found 
that some of what I "discovered" about JB, I quoted earlier about JA.  
*
        I have some theories about undetectable viruses, by the way, which I 
hesitate to share here.  My concern is for Meridian's "right" to a good public 
image.  
*
One note:  When the Academy of Sciences of the USSR was hit by a virus last 
year (har!  that's what they get for copying software!)  they created an 
anit-virus program which they immediately made a "state secret"  (no SHAREware 
in commieland).  This program identifies "  all twelve known viruses".  Quite a
claim!  (I forget the actual number they said. I almost got logged off taking 
time to look but the article I quoted them in was edited for space their 
hassles were not disclosed to the Data General usership...) Anyway, it seems 
that by the standards of SCAN40, the Reds better get cracking on enhancing that
"state secret" so it can hold its own against the publicly available stuff in 
the USA.

Msg#:40285 *UPCO Discussion*
10-10-89 10:41:58
From: MIKE MAROTTA
  To: DISK DOCTORS
Subj: JERUSALEM B
With COM files you can diable the virus by changing the first instruction from 
JMP 0195 to JMP 0810.  
        This fix can be automated. (I'm working on it, but got bogged down in 
Disk Transfer Areas and File Control Blocks just as the lightning rolled 
through town, so I quit.)
        With EXE files, I haven't figured out a neat fix.  I spent the morning 
reading about EXEs.  They start at location 0100 but then are relocated based 
on data in their headers.  The Waite Group's MS-DOS BIBLE had the nerve to call
this "better" than COM files which are "leftover" from CP/M.

Msg#:40301 *UPCO Discussion*
10-11-89 03:08:58
From: MIKE MAROTTA
  To: GORDON WILLIAMS
Subj: REPLY TO MSG# 40290 (JERUSALEM B)
When it acts on COM (not EXE) files, Jerusalem B prepends itself to the 
program, i.e., it writes itself to the first 1808 bytes, pushing the original 
code down.  The first command in JB is a jump, JMP 195.  If you change this to 
JMP 710  (710h = 1808 base 10) then your computer jumps over the infection and 
continues processing normally.  I did it with DEBUG; you can also use Norton's 
etc.  Change the 0195 to 0710.  (Ah, maybe I should check -- as I recall, Intel
has this funny way of placing the Low byte first, so 0195 is really 9501 and 
0710 is given as 1007.  Anyway, you'll see it, if you look at the infected COM 
file.
*
As I said before, I am still (ahem) hacking my way through the EXEs.  For 
reasons of their own, Intel and Microsoft define EXEs as the "default".  An EXE
file header contains information for loading the program into memory.  So some 
of it is in one segment and some in another.  (I had orginally thought this was
a function of the virus.  (:-))