|
UPCO discussion on Jerusalem B virus
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
////////////////////////////////////////////////////////////////////////////
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. (:-))
|
|
