//////////////////////////////////////////////////////////////////////////// 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. (:-))