VIRUS-L Digest Friday, 2 Aug 1991 Volume 4 : Issue 135
Today's Topics:
ME
re: High memory (PC)
Scanning DOS files under UNIX ? (PC) (UNIX)
Re: Self-scanning executables (PC)
Re: Virus Scan V57 and V77. (PC)
Info re viruses in shrinkwrap software?
Re: Self-scanning executables (PC)
Re: Brunnstein (CARO) virus catalog files
Need help fighting FORM (PC)
Re: Self-scanning executables (PC)
request information (PC)
OS/2 Viruses (PC) (OS/2)
Rip-off software package (PC)
Proposal for standard virus signatures notation
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Wed, 31 Jul 91 18:25:02 +0100
>From:
[email protected]
Subject: ME
I was somewhat taken back with Ross Greenberg's abraisive response
(issue 125) to my posting (issue 119) about the anti-virus product
review in the UK magazine PC Plus. Without plumbing the depths of
personal abuse I would like to defend myself and respond to a couple
of the 'criticisms' made.
>}Declaration of interests: I work at Thecia System Ltd, we produce an
>}anti-virus product called Virus Clean, which was not invited for inclusion
>}in Hamilton's review.
>
>The crux of the problem, certainly. Did you, by any chance, have the
>opportunity to forward a copy of your code to VB for inclusion in
>their review(s), or did you expect them to track you down?
I think that you are barking up the wrong tree with this time Ross:
This caveat was intended to show that I had no particular axe to grind
(eg regarding unfair treatment of our product) in my comments, and that
I practice what I preach in terms of disclosing my interests.
My discussion was of the review in PC Plus, not of the similar review
recently in the Virus Bulletiin. However if you are interested; Edward
is certainly aware of our product but he did not request a copy for
review. In fact the subject has never come up in our occasional
conversations.
>}I am not suggesting that Mark Hamilton has deliberately misrepresented
>}the products of these companies, but that these relationships should be
>}kept in mind when reading the review.
>
>Ah, but what you write *does* suggest that you have a problem with
>either Hamilton's credibility or VB's or both.
My intention was to raise awareness of magazine readers of the possible
partiality of magazine reviews. Having seen all issues of VB, and even
having contributed (at a time when I had no other commercial interest in
the subject), I have had 2 years to form an opinion. However I shall
not force this on anyone, but rather respect that other people's range
from Ross's unstinting praise (well almost) to outright incredulity.
I was present at one event that Hamilton subsequently reported on, and
my recollection differed from his report in only one area; the behaviour
of Hamilton himself and the subsequent response. This only underlines
the lesson I learnt from seeing events and names mangled in local
newspapers, seek corroboration of any news item that may affect you.
Perhaps my previous posting would have been fairer if I had included
comments about Future Publishing, the publishers of PC PLUS. Suffice
to say that their computer titles range from the very good Amiga Shopper
down to their roguish Computer Express.
My thanks especially to those who responded directly to my previous posting,
if you haven't got a reply yet I promise that I shall send it when I next
login.
Many thanks for your time & attention,
ANTHONY NAGGS
Systems Designer #
Electronics Engineer #
Program Implementor # Silly question #1:
Software Tester # Who lit the fuse for the big bang?
Occasional book & magazine contributor #
& PC Virus Analyser since 1988 #
------------------------------
Date: Wed, 31 Jul 91 18:13:00 -0500
>From: Rich <
[email protected]>
Subject: re: High memory (PC)
>From: "William Walker C60223 x4570" <
[email protected]>
>From: padgett%
[email protected] (A. Padgett Peterson)
>
>There is a portion of extended memory on a '286 or '386, which
>Microsoft calls the High Memory Area (HMA), which is accessible from
>real mode. A good explanation of how it works is given in the article
>"Power Programming" by Ray Duncan, in the June 27, 1989 issue of PC
>Magazine, part of which I've quoted below:
>
>> "Recall the method by which physical addresses are generated in real
>> mode. The contents of a segment register are shifted left 4 bits
>> and added to a 16-bit offset. On an 8086/88 machine, if the result
>> overflows the 20-bit addresses supported by the CPU, the address
>> simply wraps--that is, the upper bits are discarded. 80286- and
>> 80386-based PCs can support larger physical addresses (24 bits and
>> 32 bits, respectively), but this capability is ordinarily not
>> apparent when DOS is running. That's because these machines have
>> special hardware to disable the most-significant address lines in
>> real mode, making the machine behave more like an 8088.
>
>> "Consider what happens, however, on an 80286 when you enable the A20
>> line and place the value FFFFh in one of the segment registers.
>> Enabling the A20 line allows the generation of 21-bit physical
>> addresses. And when FFFFh is shifted left 4 bits and added to a
>> 16-bit offset, the result will fall in the address range FFFF0h-
>> 10FFEFh. In other words, enabling the A20 line allows the first
>> 65,520 bytes of extended memory to be addressed WITHOUT LEAVING REAL
>> MODE." [my emphasis - WWW]
>
>> - Duncan, Ray. Power programming. PC Magazine, V8 I12 (June 27,
>> 1989), p. 321. Copyright Ziff-Davis Publishing Co. 1989
>
>Knowing this, suppose a virus has somehow infected a machine with a
>pre-DOS validator, relocating it as though it was a normal boot sector
>or MBR. Also suppose that it has enabled the A20 line and stored part
>or all of itself in the HMA, with vectors pointing up there. These
>vectors would by necessity have a segment prefix greater than 0F000h.
>Now, when the validator gets control, it would mistakenly believe that
>those vectors pointed into ROM below the 1M line if it only examined
>the segment prefix. But if it calculated the full absolute addresses,
>it would easily see that the vectors pointed into the HMA, not ROM.
>
>Such a virus, though possible, would not be very viable, since running
>HIMEM.SYS or anything which used memory in protected mode would wipe
>out the virus code in the HMA. And, if the virus somehow protected
>itself, these programs would bomb out, giving the user a clue that
>something was wrong.
I recently saw a program (and the .ASM source) which goes TSR and
waits for the user to execute LOGIN (.com, .exe, or .bat). It then
records everything in a hidden file named TESTING<alt-255>.TMP. It
was written at George Washington High School and left on the super-
visor's machines on a Novell Network. Now, taking this into account,
couldn't a virus be written which would place itself in that memory
you were talking about, and remain undetectable to the methods you
were describing above? It could scan for HIMEM.SYS, QEMM, etc, and
if it finds one being executed, move itself to conventional memory
(where it COULD be detected, but won't, since you've already scanned
it with the pre-D thing) and then load the memory driver?
One other point: I got to thinking earlier today (uh oh!).... Since
you can re-write the BIOS table to intercept interrupts (e.g. int 09h
is intercepted by SideKick, to check for the ctrl-alt key combo),
this indicates that the BIOS vector is in RAM. This is copied from
ROM on bootup, right? Can't you write a driver (.sys) file to be
executed in config.sys which would go TSR and then warn you everytime
a program re-directed an interrupt? I mean, you should know SideKick
is doing it, but if something that SHOULDN'T be doing it does it,
it might be a good sign that something's up! (the novel password
stealer intercepted the dos interrupt, 021h, which is itself
intercepted on boot by the novel software. so the hacker re-hooked
it AFTER novel did, so that when a DOS function is called, it goes
through the password stealer, then through Novell, then through the
regular interrupt handler...) Anyway, I've never written a .SYS
file, nor have I seen any information on how to do it. Can someone
point me in the right direction so that I can learn how to write one?
If no one else likes my idea, *I* at least would like it on MY
system....
- ----------------------+
Richard Holland |
|
[email protected] |
[email protected] |
[email protected] |
- ----------------------+
------------------------------
Date: Wed, 31 Jul 91 17:53:52 +0000
>From:
[email protected] (Aidan Saunders)
Subject: Scanning DOS files under UNIX ? (PC) (UNIX)
Are there UNIX scanners around that check DOS files ?
I have a bunch of PC's that use a Sun as a file server holding both
applications & users files. (Well, that's what we're about to set
up!) I would like to run a scanner on the Sun to scan these DOS
files. That way, I can easily automate regular scanning and avoid the
problems caused by stealth (& other) viruses that are active in memory
when scanning.
Have any of you scanner writers tried this ? - or have I missed
something ?
I would guess a Unix version of an existing Dos scanner is not too
difficult.
Any comments?
Aidan
- --
- ----------------------------------------------
ARPA ::
[email protected]
UUCP :: ...!ukc!newcastle.ac.uk!a.c.g.saunders
- ----------------------------------------------
------------------------------
Date: 31 Jul 91 18:57:32 -0400
>From: Kevin Dean <
[email protected]>
Subject: Re: Self-scanning executables (PC)
In digest #132,
[email protected] (Fridrik Skulason) writes:
> Well, this is of just as much use as a simple checksumming algorithm-
> it is very unlikely that a virus will attempt to atteck the
> encryption algorithm itself - trying to "fake" the CRC. A much more
> effective method is to use "stealth" techniques.
> If the implementation of this algorithm detects infection by Frodo
> (4096), it is worth considering...
He is quite right. Stealth viruses intercept the DOS interrupt and
check for file open of the infected executable (which my code has to do
in order to run the self-check) and disinfect the executable before
passing the file open command on to DOS. My algorithm won't detect
that since it will be running on a (now) clean copy of the executable.
I have some ideas on how to detect stealth viruses. I'll test them out
as soon as I can and post the results here.
In digest #133,
[email protected] (John Francis) writes:
> Unfortunately this is nothing more than "Ignorance Protection".
> There has to be some way of calculating the initial CRC when the
> program is built - they don't appear in the executable by magic!
> This must be by some method that is faster than exhaustive search,
> or else nobody will use CRC protection. The same algorithms are
> available to virus writers.
An external program is run on the executable to generate the initial
CRC. This program searches for a predefined string in the executable
and _replaces_ it with the CRC information. Once the string has been
replaced, there is no way to find it again, hence the need for an
exhaustive search. T'ain't easy.
------------------------------
Date: 01 Aug 91 06:59:01 +0000
>From:
[email protected] (Doug McLaren, esquire.)
Subject: Re: Virus Scan V57 and V77. (PC)
[email protected] (Bill Dyer) writes:
>
[email protected] (Andrew Brennan) writes:
>
>While I am here, a question about Stoned. From what I can tell,
>Stoned is a memory resident program that resides in the partition
>table on hard disks and the boot sector on floppies. My question is
>what triggers the thing to infect a floppy from the hard disk? In
>other words, what interupt is it stealing? Second question, can
>Stoned infect other places besides the partition table? We have a PC
>board plugged into one of our suns here at work, and I think the thing
>is infected with Stoned. However, the thing does not have a standard
Yes, and another question about Stoned.
I got it once, a while back. I used Clean and got rid of it, and it
never came back.
But how did I get it? I had been ftp'ing at the time, and had not
actually exchanged any disks recently. I then ran all the programs I
ftp'd through Checkout which Scans and re-Archives w/ Lha. But
Checkout crashed halfway through the set saying my disk was infected
(I never did see the message saying w/ what ...) I ran Scan and it
said Stoned virus found somewhere on my HD. But if Stoned infects
disks only, how did I get it. And how did it crop up from
de-archiving it? (Or did it?) I thought only the Dark Avenger did
that? Any ideas ?
- --
| Doug McLaren | "Good tea ... |
|
[email protected] | nice house." - Worf |
- ----------------------------------------------------
------------------------------
Date: Thu, 01 Aug 91 13:06:31 +0000
>From:
[email protected] (Greg Broiles)
Subject: Info re viruses in shrinkwrap software?
The latest issue of Byte has a cover story on viruses and security software -
a rather disappointing article, truth be told. They do some rudimentary
testing of a few antivirals and come up with a simplistic little
reccommendations-box. Blech. :(
Anyway, in the middle of the aforementioned yukky article, there's one of
those sidebars along the lines of "How not to get viruses", which included
tips like "only use shrinkwrapped software" and "only download software
from trusted sources like BIX" (BIX is Byte's own online service).
I'm planning to write a grouchy letter to the editors re their *wrong*
ideas about virus propagation, and am looking for specific examples of
commercial software that's been infected at the factory or duplication site.
I've read of quite a few examples of this over the years in comp.virus
but never bothered to collect them into a useful list; but I'm in the
mood to now.
So.. if you know of an instance of software being infected before delivery
to customers (leaving aside, for the moment, the issue of stores which re-wrap
software after demos or customer returns), please post it, or mail to me.
I'll summarize to the net once replies die down.
- --
".. organized crime is the price we pay for organization." - Raymond Chandler
Greg Broiles | CI$: 74017,3623 |
[email protected]
PO Box 8988, Portland, OR 97207-8988 | MCIMail: gbroiles
------------------------------
Date: Thu, 01 Aug 91 09:11:00 -0400
>From: Jeff Boyd <
[email protected]>
Subject: Re: Self-scanning executables (PC)
John Francis <
[email protected]> wrote:
> Somewhere on CompuServe, Kevin Dean writes:
>> Cracking the algorithm is not a trivial task: a virus has one chance
>> in four billion (2^32) of successfully infecting a program or, if it
>> decides to fool the algorithm by changing the stored CRC, would lock
>> up a 386 for hours bordering on days to find and change it.
>
> Unfortunately this is nothing more than "Ignorance Protection". There
> has to be some way of calculating the initial CRC when the program is
> built - they don't appear in the executable by magic!
Correct.
> This must be by some method that is faster than exhaustive search, or
> else nobody will use CRC protection.
Correct again.
> The same algorithms are available to virus writers.
Wrong.
> It won't take long to find the encryption code in an executable ...
Wrong.
The insertion of the CRC into the program is a 1-way ticket. Only
exhaustive search can pull it out. Can a virus use the same insertion
technique to plant itself without changing the present CRC (which is
stored in the program) *AND* without changing the file size?
You tell me how easy that would be.
------------------------------
Date: Thu, 01 Aug 91 10:14:12 -0400
>From: Kenneth R. van Wyk <
[email protected]>
Subject: Re: Brunnstein (CARO) virus catalog files
For all you VIRUS-L/comp.virus readers in the Australia region, the
CARO virus catalog files are now also available by anonymous FTP on
suna.mqcc.mq.oz.au [IP number 137.111.161.1] in the directory,
pub/Virus/Brunnstein.
Ken van Wyk
------------------------------
Date: 01 Aug 91 17:37:11 +0000
>From: Tom Killalea <
[email protected]>
Subject: Need help fighting FORM (PC)
FORM is currently causing our PC users major headaches. McAfee Clean
doesn't always clean it (I'm using 7.6v80). Doing SYS to make a
system disk thus overwriting the boot sector works but is a bit of a
kludge. Any ideas ?
Many thanks,
Tom Killalea
Systems Programmer
- --
Tom Killalea | 011 353 1 702 2165 | Trinity College
|
[email protected] |
------------------------------
Date: Thu, 01 Aug 91 16:46:00 -0400
>From: Jeff Boyd <
[email protected]>
Subject: Re: Self-scanning executables (PC)
Padgett Peterson <padgett%
[email protected]> wrote:
> Unfortunately, a "stealth" virus will defeat this method ... the
> routine only "sees" the program as it was, not as it is, the routine
> passes.
The virus must intercept the calls to read the disk image, notice that
the file is already infected, and replace the interrupt return values
with "good-looking" data. Will 4096 really do this? If it can, I don't
understand how anyone has ever discovered it.
------------------------------
Date: Thu, 01 Aug 91 20:12:00 -0600
>From: CESAR <
[email protected]>
Subject: request information (PC)
Hi, I'm write from ITESO University, in last days I wrote to
[email protected], for solicit information abot how we can have the
last versions of SCAN, CLEAN, etc. Which is the cost of license?.
But Mcafee do not answer me, How we can do it?
Thanks in Advance.
I.E. Cesar E. H. White
Public Relations Manager
ITESO University
BITNET: Cesar@iteso
INTERNET:
[email protected]
------------------------------
Date: Fri, 02 Aug 91 18:25:00 +1000
>From: "William J. Caelli" <
[email protected]>
Subject: OS/2 Viruses (PC) (OS/2)
There have been a number of questions about whether or not there have
been any reports of OS/2 viruses - particularly program ( as distinct
from boot-sector ) viruses. Has anyone got any reports of such OS/2
viruses.
Bill Caelli - QUT Australia.
------------------------------
Date: Fri, 02 Aug 91 12:07:41 +0700
>From: "Jan R. Terpstra" <
[email protected]>
Subject: Rip-off software package (PC)
Recently it was brought to my attention that a so called ShareWare
package of anti-virus utitlities is offered by Mauro Bollini of Italy
at US $45. After checking a recent copy of the anti-virus package, it
turns out that it consists of bootlegged copies of several program's
from Frisk, Alan Solomon, McAfee and my own virscan.dat file.
For those of you wanting to persue this matter, I can scoop up a copy
of the complete package as offered by Mauro Bollini. Who, by the way,
also operates a virus exchange BBS in Italy.
<JT>
Jan R. Terpstra (moderator of the FIDONET VIRUS conference in my spare time)
Usual disclaimers apply.
------------------------------
Date: Fri, 02 Aug 91 13:07:50 +0700
>From: "Jan R. Terpstra" <
[email protected]>
Subject: Proposal for standard virus signatures notation
After lengthy discussions with a number of people, three independant
authors of virus scanning products and myself (as the keeper of the
VIRSCAN.DAT virus signature file) have agreed upon a standard notation
for virus signatures. As far as I know at this time, CARO will adopt
this method too. (Klaus?)
The method is non-proprietary and hereby donated to the public domain.
Your comments and suggestions are welcome.
-0-0-0-0-0-0-0-0-0-0-0-0-
A virus signature is a hexadecimal pattern of part of the active code
of the virus, prefarably a unique part to allow positive
identification of a virus. The hexadecimal string must be at least 12
bytes long, with a maximum of 40 bytes. Long signatures are
recommended to decrease the change of flase psotives. The string
should be carefully extracted and preferably not contain often used
sequences of instructions like operating system calls.
A virus signature is represented as a so called "Two-Byte-Hex" string,
i.e. each byte is represented in two ASCII characters in the range
0....9 and/or A....F.
Example: 3E550BDF3D550D45863211FA
For easier reading, spaces between the bytes are allowed.
Example: 3E 55 0B DF 3D 55 0D 45 86 32 11 FA
or: 3E55 0BDF 3D55 0D45 8632 11FA
In a virus signature, wildcards characters may be used to recognize so
called selfmodifying virus code. Below is a description of the
wildcard notation:
?? = Always skip this byte when scanning (don't care).
Signature "1122??445566" should trigger on a the pattern with any value
in the third byte of the signature. "1122CC445566" and "1122FA445566"
triggers, but "1122445566" does not
Multiple ?? are allowed, but to skip more than one byte, usage of the
"*X" notation is recommended.
?n = Always disregard the high nibble of this byte when scanning, but DO test
the low nibble.
Signature "1122?34455" triggers for any value in the high nibble of the
third byte, i.e. "1122A34455" triggers, but "1122AA4455" does not.
n? = Always disregard the low nibble of this byte when scanning, but DO
test the high nibble.
Signature "11223?445566" triggers for any value in the low nibble of the
third byte, i.e. "11223A4455" triggers, but "1122AA4455" does not.
*x = Skip exactly X bytes (X = 1 to F), i.e. the contents of precisely X
bytes are to be disregarded.
Signature "1122*3445566" triggers on "1122AABBCC445566", but not on
but not on "1122AABBCCDD445566" or "1122AA445566".
Note: X1 equals to ??.
%x = Skip 0 to a specified number of bytes. (X = 1 to F), i.e. the contents
of zero up to X bytes are to be disregarded.
Signature "1122%3445566" triggers on "1122445566" and "1122AABB445566"
but not on "1122AABBCCDD4455".
Note: The first TWO bytes of a virus signasture can not contain wildcards.
This allows simplified word hashing tables to be implemented in virus
scanners that use the proposed string format as input.
To minimize the chance of false positives, it is preferred that the
*X and %X notation not be used in the last byte of a virus signature,
though this might be unavoidable for some self-garbling viruses.
Some examples:
55 AA 33 ?? 90 01 FF = Match 55AA33, disregard 1 byte and match 9001FF.
55 AA 33 ?4 90 01 FF = Match 55AA33, disregard the high nibble of the 4th
byte, match "4" in the low nibble and match the 9001FF
pattern.
55 AA 33 4? 90 01 FF = Match 55AA33, disregard the low nibble of the 4th
byte, match "4" in the high nibble and match the
9001FF pattern.
55 AA 33 *7 90 01 FF = Match 55AA33, and match 9001FF if found after exactly
7 bytes from the end of the 55AA33 pattern.
55 AA 33 %A 90 01 FF = Match 55AA33 and match 9001FF if found within 10 bytes
from the end of the 55AA33 pattern.
-0-0-0-0-0-0-0-0-0-0-0-0-
Try this one for yourself: 55 AA %3 EF *4 BE ?? B? ?4 FE :-)
Jan R. Terpstra (keeper of VIRSCAN.DAT in my spare time)
Usual disclaimer applies.
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 135]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
