what files do you really need to scan??
herrmann
When I scan my C drive, my program goes really quickly until it reaches a
certain point. At that point, after about 700 files, it comes to a
screeching halt and starts scanning incredibly slow (about 1 file per
second as opposed to the first 700 in 15 seconds). This happens somewhere
in the Windows folder in Windows 95.
My question is, what could be causing this? And do I really need to be
scanning those files? And ultimately, what files should I really be
scanning?
Please e-mail responses.
Thanks in advance.
--
herr...@net-link.net
Graham Cluley
> When I scan my C drive, my program goes really quickly until it reaches
a
> certain point. At that point, after about 700 files, it comes to a
> screeching halt and starts scanning incredibly slow (about 1 file per
> second as opposed to the first 700 in 15 seconds). This happens
somewhere
> in the Windows folder in Windows 95.
> My question is, what could be causing this?
Which anti-virus are you running? That's fairly critical to answering
this question! :)
> And do I really need to be scanning those files?
It's not normally critical to scan 'all files' except when you're doing a
clean-up.
> And ultimately, what files should I really be scanning?
Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC, DOT.
There are a bunch of other more esoteric ones too.
Regards
Graham
---
Graham Cluley CompuServe: GO DRSOLOMON
Senior Technology Consultant, UK Support: sup...@uk.drsolomon.com
Dr Solomon's Anti-Virus Toolkit. US Support: sup...@us.drsolomon.com
Email: gcl...@uk.drsolomon.com UK Tel: +44 (0)1296 318700
NEW:Evaluate Dr Solomon's FindVirus 7.68! Download it from our webpage
Graham Cluley
da...@mcafee.com writes:
> If you have your scanner set to scan zip files, and you are using the
> Microsoft Internet Explorer, some scanners will slow down on the file
> classes.zip, which is a zip file containing over 500 files. McAfee
> for one is working hard to resolve this problem.
Hi Dan
I don't use MS Internet Explorer, what are the files in classes.zip? The
ones which are not "executable" shouldn't need to be scanned. Of course
if there are many, say, DOCs or EXEs then it's a different case entirely.
Tarkan Yetiser
In article <32e7e771...@news.toolcity.net>, jbl...@toolcity.net
wrote:
> On 23 Jan 1997 20:56:53 GMT, "herrmann" <herr...@net-link.net> wrote:
>
> >When I scan my C drive, my program goes really quickly until it reaches a
> >certain point. At that point, after about 700 files, it comes to a
> >screeching halt and starts scanning incredibly slow (about 1 file per
> >second as opposed to the first 700 in 15 seconds). This happens somewhere
> >in the Windows folder in Windows 95.
>
> hard drives (LBA mode) would you? I've noticed, for some reason that
> escapes me, that some older BIOSed machines have a bit of a problem
> with single directories containing a large number of files. If your
What this guy is talking about has nothing to do with the lack of LBA
support, nor the inefficiency of FAT system to deal with large number
of directory entries.
> scanner is choking on something like the "Temporary Internet Files"
> folder, you may find that you're running up against this problem.
> Folders like this sometimes contain thousands of files.
That's more like it.
> You may also find that you're scanning a temporary directory, or a
> "downloads" directory that contains a lot of compressed ZIP files.
> Opening a lot of these puppies can really bog things down too.
This seems to happen to McAfee for the most part :-)
--
Regards
Tarkan Yetiser
VDSARG
http://home.prolog.net/~tyetiser
http://www.ccso.com
An ActiveX control is nothing but a standard Windows DLL
that is executed by the browser as a side effect of the
download. In other words, an ActiveX control is a virus--
a benevolent one we hope, but a virus nonetheless.
-Allen Holub
Pierre Vandevenne
Steven Hoke <sh...@baldcom.net> wrote in article
<32E879...@baldcom.net>...
: I think) had this file with a .ZIP extension. I had a problem with AVP
: scanning it at one time. I think it was choking on the long file names
: (but don't really know what the problem was). Whether these .CLASS files
That was the problem.
--
Pierre Vandevenne, http://www.datarescue.com
IDA Pro multi-os, multi-processor interactive disassembler
Uncle Gazzer
herrmann <herr...@net-link.net> wrote in article
<01bc0970$299a5aa0$2ff11fce@herrmann>...
> When I scan my C drive, my program goes really quickly until it reaches a
> certain point. At that point, after about 700 files, it comes to a
> screeching halt and starts scanning incredibly slow (about 1 file per
> second as opposed to the first 700 in 15 seconds). This happens
somewhere
> in the Windows folder in Windows 95.
> My question is, what could be causing this? And do I really need to be
> scanning those files? And ultimately, what files should I really be
> scanning?
> Please e-mail responses.
> Thanks in advance.
> --
probably compressed files. Some of the executable files in the windows
directory are self extracting files that decompress and execute on the fly.
Jeffrey Bloss
On 23 Jan 1997 20:56:53 GMT, "herrmann" <herr...@net-link.net> wrote:
>When I scan my C drive, my program goes really quickly until it reaches a
>certain point. At that point, after about 700 files, it comes to a
>screeching halt and starts scanning incredibly slow (about 1 file per
>second as opposed to the first 700 in 15 seconds). This happens somewhere
>in the Windows folder in Windows 95.
You wouldn't happen to be running a machine without support for large
hard drives (LBA mode) would you? I've noticed, for some reason that
escapes me, that some older BIOSed machines have a bit of a problem
with single directories containing a large number of files. If your
scanner is choking on something like the "Temporary Internet Files"
folder, you may find that you're running up against this problem.
Folders like this sometimes contain thousands of files.
You may also find that you're scanning a temporary directory, or a
"downloads" directory that contains a lot of compressed ZIP files.
Opening a lot of these puppies can really bog things down too.
---
~~~ Jeffrey Bloss -==- jbl...@toolcity.net
(0 0) http://www.toolcity.net/~jbloss/
--ooO--(_)--Ooo------------------------------------------------
Dan Melchione [McAfee]
Hi Graham,
The classes.zip file contains Java classes. McAfee's scanner (for
example) does not rely on a files extension to determine it's file
type. Instead we do an analysis of the beginning of the file to
determine the file type. Thus if you tell it to scan all files, it
will have to decompress each and every file in the zip.
On Fri, 24 Jan 1997 02:39:36 GMT, ham...@cix.compulink.co.uk ("Graham
Cluley") wrote:
>da...@mcafee.com writes:
>> If you have your scanner set to scan zip files, and you are using the
>> Microsoft Internet Explorer, some scanners will slow down on the file
>> classes.zip, which is a zip file containing over 500 files. McAfee
>> for one is working hard to resolve this problem.
>
>Hi Dan
>
>I don't use MS Internet Explorer, what are the files in classes.zip? The
>ones which are not "executable" shouldn't need to be scanned. Of course
>if there are many, say, DOCs or EXEs then it's a different case entirely.
>
>Regards
>Graham
--
Dan Melchione (mailto:da...@mcafee.com)
McAfee Software, Inc. (http://www.mcafee.com)
Anti-Virus Development (Advanced Research)
Pierre Vandevenne
Hello,
Graham Cluley said
: > classes.zip, which is a zip file containing over 500 files. McAfee
: > for one is working hard to resolve this problem.
: I don't use MS Internet Explorer, what are the files in classes.zip?
The
: ones which are not "executable" shouldn't need to be scanned. Of course
They are the Java base classes. You'll find them in several places : to
give java support to MSIE, in Sun's JDK, in most java sdks (marimba/bongo
for example) etc...
Some scanners dive into those although there is no conventional executable
code in them. Strangely some scanners claiming to detect java viruses
don't even care about classes.zip.
Lastly, while Sun's reference implementation of the JDK is 1.7 MB (version
1), MS view of classes zip is 2.6 MB, apparently with less functionality.
George Wenzel
In article <01bc0970$299a5aa0$2ff11fce@herrmann>, herr...@net-link.net
says...
>When I scan my C drive, my program
This is far too general. *Which* program?
>goes really quickly until it reaches a
>certain point. At that point, after about 700 files, it comes to a
>screeching halt and starts scanning incredibly slow (about 1 file per
>second as opposed to the first 700 in 15 seconds).
This sounds like the problem McAfee has with scanning compressed files.
What anti-virus program are you using, and what files does it slow down
on?
> This happens somewhere
>in the Windows folder in Windows 95.
>My question is, what could be causing this? And do I really need to be
>scanning those files?
More than likely, it's a problem with the scanning software. The files
should still be scanned.
>And ultimately, what files should I really be
>scanning?
There are quite a few. Any .com, .exe, .bat, .dll, .386, .doc, and .dot
file should be scanned, but this is only a partial list. Most anti-virus
products have a list of files that they scan by default.
>Please e-mail responses.
>Thanks in advance.
mini-FAQ e-mailed, with a CC of this post.
Regards,
George Wenzel
--
("`-''-/").___..--''"`-._ George Wenzel
`6_ 6 ) `-. ( ).`-.__.`) <gwenzel @ gpu.srv.ualberta.ca>
(_Y_.)' ._ ) `._ `.``-..-' Club Secretary,
_..`--'_..-_/ /--'_.' ,' University of Alberta Karate Club
(il),-'' (li),' ((!.-' http://www.ualberta.ca/~gwenzel/
GRAHAM CLULEY
> In article <E4HqB...@cix.compulink.co.uk>,
> >
> DOT. There are a bunch of other more esoteric ones too.
>
>
> (A cascade opportunity?)
FON, SMM..
Regards
Graham
---
Graham Cluley CompuServe: GO DRSOLOMON
Senior Technology Consultant, UK Support: sup...@uk.drsolomon.com
Dr Solomon's Anti-Virus Toolkit. US Support: sup...@us.drsolomon.com
Email: gcl...@uk.drsolomon.com UK Tel: +44 (0)1296 318700
Web: http://www.drsolomon.com USA Tel: +1 617-273-7400
Pierre Vandevenne
Patrick Noyens <patrick...@ping.be> wrote in article
<3307ab57...@news.ping.be>...
: On 24 Jan 1997 07:07:52 GMT, "Pierre Vandevenne"
: <pie...@datarescue.com> wrote:
:
: >Some scanners dive into those although there is no conventional
executable
: >code in them. Strangely some scanners claiming to detect java viruses
: >don't even care about classes.zip.
: Hm...I didn't know that...scanning for java viruses...?
: I don't know any Java virus, but it seems possible to create one. Have
: you already seen one ?
As far as I know, there isn't one right now. I was referring to the
advertisement made by some US company a while ago. They were detecting
java viruses even before sun released the sdk officially.
Tarkan Yetiser
In article <01bc09f5$e5286ac0$117a...@compaq.dr-hq.com>,
> As far as I know, there isn't one right now. I was referring to the
> advertisement made by some US company a while ago. They were detecting
> java viruses even before sun released the sdk officially.
Now that's what I call staying on the cutting edge of technology :-)
Marketing technology, that is. Sense what's coming up, and jump on it.
--
Regards
Tarkan Yetiser
VDSARG
http://home.prolog.net/~tyetiser
http://www.ccso.com
A foolish consistency is the hobgoblin of little minds...
Emerson
Tarkan Yetiser
In article <32ee61ce...@news.loxinfo.co.th>,
kra...@my.email.address wrote:
> If you scan in DOS large directories the more files you have the
> slower you will go. Try scanning an NT4 directory.....
> The problem is probably due to the dos filing system, not the actual
> scan.
OK, but there's no excuse for not using a pacifier if something is
likely to take a long time.
Steven Hoke
Dan Melchione [McAfee] wrote:
>
> Hi Graham,
>
> The classes.zip file contains Java classes. McAfee's scanner (for
> example) does not rely on a files extension to determine it's file
> type. Instead we do an analysis of the beginning of the file to
> determine the file type. Thus if you tell it to scan all files, it
> will have to decompress each and every file in the zip.
But that begs the obvious question for those of us that don't know
anything about Java classes. Are those executable files?
--
--==Steve==--
krakan
On Fri, 24 Jan 1997 02:16:18 GMT, ham...@cix.compulink.co.uk ("Graham
Cluley") wrote:
>> When I scan my C drive, my program goes really quickly until it reaches
>a
>> certain point. At that point, after about 700 files, it comes to a
>> screeching halt and starts scanning incredibly slow (about 1 file per
>> second as opposed to the first 700 in 15 seconds). This happens
>somewhere
>> in the Windows folder in Windows 95.
>> My question is, what could be causing this?
>
>Which anti-virus are you running? That's fairly critical to answering
>this question! :)
>
>> And do I really need to be scanning those files?
>
>It's not normally critical to scan 'all files' except when you're doing a
>clean-up.
>
>> And ultimately, what files should I really be scanning?
>
>Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC, DOT.
> There are a bunch of other more esoteric ones too.
>
>Regards
>Graham
>---
>Graham Cluley CompuServe: GO DRSOLOMON
>Senior Technology Consultant, UK Support: sup...@uk.drsolomon.com
>Dr Solomon's Anti-Virus Toolkit. US Support: sup...@us.drsolomon.com
>Email: gcl...@uk.drsolomon.com UK Tel: +44 (0)1296 318700
>NEW:Evaluate Dr Solomon's FindVirus 7.68! Download it from our webpage
If you scan in DOS large directories the more files you have the
George Wenzel
In article <E4IGx...@cix.compulink.co.uk>, san...@cix.compulink.co.uk
says...
>> >Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC,
>> DOT. There are a bunch of other more esoteric ones too.
>>
>>
>> (A cascade opportunity?)
>
>FON, SMM..
.HLP, .386 (ya never know)
Chris Stubbs
gwe...@gpu.srv.ualberta.ca_REMOVE_THIS_TO_SEND_E-MAIL (George Wenzel)
wrote:
>In article <E4IGx...@cix.compulink.co.uk>, san...@cix.compulink.co.uk
>says...
>>> >Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC,
>>> DOT. There are a bunch of other more esoteric ones too.
>>>
>>> .SCR, .VXD, .DVR, .DRV, .XLS.....
>>>
>>> (A cascade opportunity?)
>>
>>FON, SMM..
>.HLP, .386 (ya never know)
CPL, ASM, XLT
MJ DIMMICK
GRAHAM CLULEY (san...@cix.compulink.co.uk) wrote:
: > In article <E4HqB...@cix.compulink.co.uk>,
: > ham...@cix.compulink.co.uk ("Graham Cluley") wrote:
: > >> And ultimately, what files should I really be scanning?
: > >
: > >Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC,
: >
: > .SCR, .VXD, .DVR, .DRV, .XLS.....
: >
: > (A cascade opportunity?)
:
: FON, SMM..
Actually, I do remember hearing that .FON files are executable. Does
anyone know whether the same is true for .TTF (TrueType Font) files?
I believe these are also executable.
--
Michael Dimmick | dimm...@aston.ac.uk | http://www.aston.ac.uk/~dimmicmj
"Outside on the battlements, the guard changed. In fact he changed
into his gardening apron and went off to hoe the beans..."
I really must get out more...
Chris Stubbs
r_jo...@ix.netcom.comX (Rick Joseph) wrote:
>In article <5cipq8$s...@mongol.sasknet.sk.ca>,
>c.st...@sk.sympatico.ca (Chris Stubbs) wrote:
>>gwe...@gpu.srv.ualberta.ca_REMOVE_THIS_TO_SEND_E-MAIL (George Wenzel)
>>wrote:
>>
>>>In article <E4IGx...@cix.compulink.co.uk>, san...@cix.compulink.co.uk
>>>says...
>>>>> >Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC,
>>>>> DOT. There are a bunch of other more esoteric ones too.
>>>>>
>>>>> .SCR, .VXD, .DVR, .DRV, .XLS.....
>>>>>
>>>>> (A cascade opportunity?)
>>>>
>>>>FON, SMM..
>>
>>>.HLP, .386 (ya never know)
>>
>>CPL, ASM, XLT
>>
>APP, .XTP, .CMD, .BTM -- .CGI?
OBJ, LIB, OL:E, WK1
BRUCE M. HARPER
- George Wenzel wrote:
>
> In article <01bc0970$299a5aa0$2ff11fce@herrmann>, herr...@net-link.net
> says...
-
> >When I scan my C drive, my program
>
-
> This is far too general. *Which* program?
>
-
> >goes really quickly until it reaches a
> >certain point. At that point, after about 700 files, it comes to a
> >screeching halt and starts scanning incredibly slow (about 1 file per
> >second as opposed to the first 700 in 15 seconds).
>
-
> This sounds like the problem McAfee has with scanning compressed files.
> What anti-virus program are you using, and what files does it slow down
> on?
>
-
> > This happens somewhere
> >in the Windows folder in Windows 95.
-
> >My question is, what could be causing this? And do I really
need to be
> >scanning those files?
>
> More than likely, it's a problem with the scanning software. The files
> should still be scanned.
>
-
> >And ultimately, what files should I really be
> >scanning?
>
-
> There are quite a few. Any .com, .exe, .bat, .dll, .386, .doc,
and .dot
> file should be scanned, but this is only a partial list. Most anti-virus
> products have a list of files that they scan by default.
>
> >Please e-mail responses.
> >Thanks in advance.
>
-
could be buffers filling up.........whats your memory like and files and
buffer settings etc.
Kevin Dempsey Peterson
On Fri, 24 Jan 1997, Tarkan Yetiser wrote:
> pie...@datarescue.com wrote:
> > As far as I know, there isn't one right now. I was referring to the
> > advertisement made by some US company a while ago. They were detecting
> > java viruses even before sun released the sdk officially.
>
> Now that's what I call staying on the cutting edge of technology :-)
> Marketing technology, that is. Sense what's coming up, and jump on it.
Who needs to pay for that? The following batch program detects all
existing Java viruses:
@echo off
echo No files were infected.
pause
Commercial use of this program requires licensing from the author.
--
kev...@uclink4.berkeley.edu Home: (510)665-9670
ke...@cafe.berkeley.edu Page: (510)726-8960
If you do not find this message non-threatening, yet
authoritative, feel free to stick your head in a pig.
Tarkan Yetiser
In article <Pine.SOL.3.95.970128091512.13439C-
100...@cafe.berkeley.edu>, ke...@cafe.berkeley.edu wrote:
> On Fri, 24 Jan 1997, Tarkan Yetiser wrote:
> > pie...@datarescue.com wrote:
> > > As far as I know, there isn't one right now. I was referring to the
> > > advertisement made by some US company a while ago. They were detecting
> > > java viruses even before sun released the sdk officially.
> >
> > Now that's what I call staying on the cutting edge of technology :-)
> > Marketing technology, that is. Sense what's coming up, and jump on it.
>
> Who needs to pay for that? The following batch program detects all
> existing Java viruses:
>
> @echo off
> echo No files were infected.
> pause
>
> Commercial use of this program requires licensing from the author.
I believe Dr. Solomon holds the patent on 0-information, confused
batch file solutions. Therefore, your license requirement is not
valid.
Steven Hoke
Kyle Smitz wrote:
>
> Someone thinks Virus can infect:
> EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC, DOT, SCR, VXD, DVR, DRV,
> XLS, FON, SMM, HLP, .386, CPL, ASM, XLT, APP, XTP, CMD, BTM ,CGI, OBJ,
> LIB, OL:E, WK1
>
> Is this name as many extenstion as you can?
>
> Viruses which infect files will try to infect executable files which
> have .EXE, .COM, .SYS,
> .BIN, and .OVL extensions. Macro viruses will infected Microsoft word
> documents and also Microsoft Excel documents.
Using your short list would leave you vulnerable, not scanning many
executable files that file virses will infect.
> \\\|///
> \\ - - //
> ( @ @ )
> +-----------------------oOOo-( )-oOOo----------+
> Kyle Smitz |
> mailto:ksm...@sprintmail.com |
> Sprint Internet Passport Technical Support |
> http://village.globaldrum.com/digital/taoism |
> +-------------------------------Oooo-----------+
> oooO ( )
> ( ) ) /
> \ { (_/
> \_)
Isn't this a bit excessive, when your signature exceeds the size of many
of your posts?
--
--==Steve==--
Patrick Noyens
On Fri, 31 Jan 1997 02:03:26 +0000, Kyle Smitz <ksm...@sprintmail.com>
wrote:
>Someone thinks Virus can infect:
>EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC, DOT, SCR, VXD, DVR, DRV,
>XLS, FON, SMM, HLP, .386, CPL, ASM, XLT, APP, XTP, CMD, BTM ,CGI, OBJ,
>LIB, OL:E, WK1
>
>Is this name as many extenstion as you can?
>
>Viruses which infect files will try to infect executable files which
>have .EXE, .COM, .SYS, .BIN, and .OVL extensions. Macro viruses will infected Microsoft word
>documents and also Microsoft Excel documents.
Your list is not complete at all :
For example the Zhengxi virus infects also OBJ- and LIB-files, and
append COM-droppers to ZIP, ARJ, and RAR archives.
Best Regards,
Patrick Noyens
-------------------------------------------------------------------------------
E-mail : patrick...@ping.be
PGP-key available on request.
2048/F8352B91 1995/11/06 Patrick Noyens. 2048 bit KEY <patrick...@ping.be>
Key fingerprint = 3F 9E 8E 05 F5 D2 C3 1E 69 28 CD 6D 21 70 FB CB
1024/E8EB3F19 1995/05/22 Patrick Noyens <patrick...@ping.be>
Key fingerprint = 01 31 60 FF C2 0F D4 A7 D2 83 64 FE 3E 3F 83 79
Kyle Smitz
MJ DIMMICK wrote:
>
> GRAHAM CLULEY (san...@cix.compulink.co.uk) wrote:
> : > In article <E4HqB...@cix.compulink.co.uk>,
> : > ham...@cix.compulink.co.uk ("Graham Cluley") wrote:
> : > >
> : > >Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC,
> : > DOT. There are a bunch of other more esoteric ones too.
OVL - Overlay files?? Not likely.. SYS files, nop, Dynamic Links, nop,
Binaries - Maybe, if so INF as well... CMD NOP, BAT Only Keyboard
remaps, DOC Macro virus...
> : > .SCR, .VXD, .DVR, .DRV, .XLS.....
VXD?? I know windows will crash your computer.. but when did that
consitute it as a virus?
> Actually, I do remember hearing that .FON files are executable. Does
> anyone know whether the same is true for .TTF (TrueType Font) files?
> I believe these are also executable.
Fonts can contain somewhat of a virus, possibly similiar to a keyboard
remap, possibly a little bit more, but I'm not sure how worried I'd get
about their destructive power, and infecting power.. I'm pretty sure
they'd have to be written in...
--
Kyle Smitz
Someone thinks Virus can infect:
EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC, DOT, SCR, VXD, DVR, DRV,
XLS, FON, SMM, HLP, .386, CPL, ASM, XLT, APP, XTP, CMD, BTM ,CGI, OBJ,
LIB, OL:E, WK1
Is this name as many extenstion as you can?
Viruses which infect files will try to infect executable files which
have .EXE, .COM, .SYS,
.BIN, and .OVL extensions. Macro viruses will infected Microsoft word
documents and also Microsoft Excel documents.
--
Bruce Burrell
MJ DIMMICK <dimm...@aston.ac.uk> wrote:
[snip]
> Actually, I do remember hearing that .FON files are executable.
I believe that would be more accurately stated ".FON files conform to the
structure of .EXE files." If you renamed FOO.FON to FOO.EXE and tried to
run it, however, it would fail.
-BPB
Mr P R Walker
In article <32f354b5...@news.ping.be>,
patrick...@ping.be writes:
>For example the Zhengxi virus infects also OBJ- and LIB-files, and
>append COM-droppers to ZIP, ARJ, and RAR archives.
Are you sure about that? The RAR archiver doesn't execute the archives,
it just reads and compresses/decompresses the data. On an SFX archive,
maybe, but then the Zhengxi virus would infect /any/ exe, not just the
SFX ones.
Paul
Patrick Noyens
On 2 Feb 1997 14:40:33 -0000, cs...@csv.warwick.ac.uk (Mr P R Walker)
wrote:
You may want to check the info about Zhengxi on :
http://www.avp.ch/avpve/file/z/zhengxi.stm
Jeffrey Bloss
>> patrick...@ping.be writes:
>>
>>>For example the Zhengxi virus infects also OBJ- and LIB-files, and
>>>append COM-droppers to ZIP, ARJ, and RAR archives.
>>
>>Are you sure about that? The RAR archiver doesn't execute the archives,
>>it just reads and compresses/decompresses the data. On an SFX archive,
>>maybe, but then the Zhengxi virus would infect /any/ exe, not just the
>>SFX ones.
>
>You may want to check the info about Zhengxi on :
Yes, but adding a file to a .ZIP isn't the same as infecting it. The
virus is there OK, but unzipping the file won't activate the critter.
In fact, nothing short of manually executing the randomly maned .COM
file will. Normal AV procedures of scanning uncompressed downloads
will detect the virus before it ever gets a grip on your system.
Chris Stubbs
Kyle Smitz <ksm...@sprintmail.com> wrote:
>MJ DIMMICK wrote:
>>
>> GRAHAM CLULEY (san...@cix.compulink.co.uk) wrote:
>> : > In article <E4HqB...@cix.compulink.co.uk>,
>> : > ham...@cix.compulink.co.uk ("Graham Cluley") wrote:
>> : > >> And ultimately, what files should I really be scanning?
>> : > >
>> : > >Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC,
>> : > DOT. There are a bunch of other more esoteric ones too.
>OVL - Overlay files?? Not likely.. SYS files, nop, Dynamic Links, nop,
>Binaries - Maybe, if so INF as well... CMD NOP, BAT Only Keyboard
>remaps, DOC Macro virus...
OVL virus - Already exists
SYS virus - Already exists
DLL virus - Already exists
INF virus - None exists - Infection probability: Not likely
CMD virus - None exists - Infection probability: Probably not
BAT virus - Already exists
>> : > .SCR, .VXD, .DVR, .DRV, .XLS.....
>VXD?? I know windows will crash your computer.. but when did that
>consitute it as a virus?
VXD virus - Already exists
>> Actually, I do remember hearing that .FON files are executable. Does
>> anyone know whether the same is true for .TTF (TrueType Font) files?
>> I believe these are also executable.
FON virus - None exist - Infection probability: Possible for NewEXE
virus to infect because of NewEXE header. Possibly an existing NewEXE
virus could infect this type.
TTF virus - None exist - Infection probability: Unknown (Do not seem
to contain any executable code)
Steven J. Hoke
Chris Stubbs wrote:
>
> Kyle Smitz <ksm...@sprintmail.com> wrote:
>
> >MJ DIMMICK wrote:
> >>
> >> GRAHAM CLULEY (san...@cix.compulink.co.uk) wrote:
> >> : > In article <E4HqB...@cix.compulink.co.uk>,
> >> : > ham...@cix.compulink.co.uk ("Graham Cluley") wrote:
> >> : > >> And ultimately, what files should I really be scanning?
> >> : > >
> >> : > >Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC,
> >> : > DOT. There are a bunch of other more esoteric ones too.
>
> >OVL - Overlay files?? Not likely.. SYS files, nop, Dynamic Links, nop,
> >Binaries - Maybe, if so INF as well... CMD NOP, BAT Only Keyboard
> >remaps, DOC Macro virus...
>
> OVL virus - Already exists
> SYS virus - Already exists
> DLL virus - Already exists
> INF virus - None exists - Infection probability: Not likely
> CMD virus - None exists - Infection probability: Probably not
> BAT virus - Already exists
>
> >> : > .SCR, .VXD, .DVR, .DRV, .XLS.....
>
> >VXD?? I know windows will crash your computer.. but when did that
> >consitute it as a virus?
>
> VXD virus - Already exists
Don't forget SCR. Windows screen saver files are executable, and Shell
(Tentacle II) infects them.
--
--==Steve==--
Fridrik Skulason
>EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC, DOT, SCR, VXD, DVR, DRV,
>XLS, FON, SMM, HLP, .386, CPL, ASM, XLT, APP, XTP, CMD, BTM ,CGI, OBJ,
>LIB, OL:E, WK1
Well, currently many viruses can (and will) infect EXE, COM, overlays (regardless
of extensions), SYS, BAT, DOC, DOT, OBJ and XLS files.
Some viruses will infect any file that has an EXE structure, such as SCR
files.
Some viruses will infect any file that is executed, regardless of the extension.
Some of the other extensions above, like .LIB can theoretically be infected,
but no *existing* virus can do that.
In addition, any source code (.C, .CPP, PAS, .BAS, .FOR or whatever) file can in
theory be infected by a source code virus.
-frisk
--
Fridrik Skulason Frisk Software International phone: +354-5-617273
Author of F-PROT E-mail: fr...@complex.is fax: +354-5-617274
Patrick Noyens
On 4 Feb 1997 14:47:24 -0000, fr...@complex.is (Fridrik Skulason)
wrote:
>>EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC, DOT, SCR, VXD, DVR, DRV,
>>XLS, FON, SMM, HLP, .386, CPL, ASM, XLT, APP, XTP, CMD, BTM ,CGI, OBJ,
>>LIB, OL:E, WK1
[snip]
>Some viruses will infect any file that is executed, regardless of the extension.
>
>Some of the other extensions above, like .LIB can theoretically be infected,
>but no *existing* virus can do that.
Are you sure about this Frisk ?
I thought the Zhengxi virus infects .LIB files too.
Please correct me if I'm wrong.
(of course it is not ITW, and if it would be in the future, I hope
F-Prot 3.0 is released at that time and is able to detect/disinfect
Zhengxi -)
Unknown
>Are you sure about this Frisk ?
>I thought the Zhengxi virus infects .LIB files too.
>Please correct me if I'm wrong.
>(of course it is not ITW, and if it would be in the future, I hope
>F-Prot 3.0 is released at that time and is able to detect/disinfect
>Zhengxi -)
Just curious about Zhengxi. I mean, the bloody source code is
available now. Other scanners have been able to detect/remove it.
Why is F-Prot lagging behind here? Can't Bontchev fix it? Or Frisk?
Or *someone*?
Patrick Noyens
I don't know about the source, is it really available ?
Did you try to generate an executable from it ?
I think the current F-Prot engine is not capable to detect this virus,
but Frisk or Vesselin could probably comment this better.
I know this is true for Dr. Solomon FINDVIRUS because Igor Muttik
from Dr Solomon Virus Lab told me so, after I posted him a infected
sample.
Best regards,
Fridrik Skulason
>I think the current F-Prot engine is not capable to detect this virus,
>but Frisk or Vesselin could probably comment this better.
That's basically correct, yes. Many encrypted or polymorphic viruses can easily be
detected with the current engine, but others require a code change. With our
new engine, however, even "difficult" viruses like Uruguay, Bomber and Whale can
be easily handled without any code changes whatsoever. Now, if a new polymorphic
virus appears today, detection of it will be added to the new engine, but not
necessarily to the old one, unless it is in the wild (or likely to be). This means
that for now the old engine is lagging somewhat behind the new one, but that situation
will change very soon, when the new scanner, using the new engine is released.
Unknown
>>Just curious about Zhengxi. I mean, the bloody source code is
>>available now. Other scanners have been able to detect/remove it.
>>Why is F-Prot lagging behind here? Can't Bontchev fix it? Or Frisk?
>>Or *someone*?
> I don't know about the source, is it really available ?
>Did you try to generate an executable from it ?
>I think the current F-Prot engine is not capable to detect this virus,
>but Frisk or Vesselin could probably comment this better.
>I know this is true for Dr. Solomon FINDVIRUS because Igor Muttik
>from Dr Solomon Virus Lab told me so, after I posted him a infected
>sample.
Yes, the source is out. So it shouldn't be too hard for any competent
AV author to find some way to detect it. All the secrets are out in
the open...
Corydon Berg
io...@mist.demon.co.uk (Iolo Davidson) wrote:
>Source code is of no value to AV people.
Really? Why is this? I would have thought that the source code
(assuming it was the real source code for the virus) would be gold to
the AV people, or atleast silver. :)
Cory -aka- "WEED Lipps"
http://www.usd.edu/~cwberg/
(--)
"When it pains, it roars" --tJL
George Wenzel
In article <32fe1a82...@news.sfu.ca>, unk...@sfu.ca says...
>Yes, the source is out. So it shouldn't be too hard for any competent
>AV author to find some way to detect it. All the secrets are out in
>the open...
AV people generally don't use source code to detect viruses. Source code
shows what the author _intended_ the virus to do, not necessarily what it
actually does.
--
("`-''-/").___..--''"`-._ George Wenzel
`6_ 6 ) `-. ( ).`-.__.`) <gwenzel @ gpu.srv.ualberta.ca>
(_Y_.)' ._ ) `._ `.``-..-' Club Secretary & Webmaster,
Snorre Fagerland
George Wenzel wrote this (which also Iolo Davidson said earlier):
>
> AV people generally don't use source code to detect viruses. Source code
> shows what the author _intended_ the virus to do, not necessarily what it
> actually does.
> --
The source code shows exactly the same as the disassembly, George & Iolo,
if you are sure that the source really belongs to the virus in question.
I consider myself to be an AV person, and I have had my uses for source
codes.
That doesn't change the fact that distributing source codes is almost as
unethical as distributing live virus code; the source is written information
and cannot infect anyone by itself, still it has the possibility in it to be
changed, mutated and recompiled in a way that live viruses doesn't.
The author or anyone with access to source codes (or disassemblies for that matter)
has to be aware of the end result of their actions. Distributing source is to
contribute to the virus "flora" which is already far too large.
It's not necessarily about law. Not necessarily about freedom either. It is about
collective responsability (You know, the thing that makes you stop when you see a
dying man on the street. You do stop? Not?)
Regards
Snorre Fagerland
Engineer
University of Bergen - Norway
Tarkan Yetiser
In article <32FFA8...@pki.uib.no>, fage...@pki.uib.no wrote:
> George Wenzel wrote this (which also Iolo Davidson said earlier):
> >
> > AV people generally don't use source code to detect viruses. Source code
True.
> > shows what the author _intended_ the virus to do, not necessarily what it
> > actually does.
That's bogus of course.
>
> The source code shows exactly the same as the disassembly, George & Iolo,
> if you are sure that the source really belongs to the virus in question.
> I consider myself to be an AV person, and I have had my uses for source
> codes.
At last, somebody with a realistic assessment. George can't code
anyway, so who cares... But Iolo was saying that the source is not
*necessary* and not used often for AV work, and that's an accurate
statement.
> The author or anyone with access to source codes (or disassemblies for that matter)
> has to be aware of the end result of their actions. Distributing source is to
> contribute to the virus "flora" which is already far too large.
Indeed, availability of source to everyone is a bigger problem than
the possibly non-functional executable.
> It's not necessarily about law. Not necessarily about freedom either. It is about
> collective responsability (You know, the thing that makes you stop when you see a
> dying man on the street. You do stop? Not?)
In fact, it's perfectly within the law and even protected as speech in
most places. People can access any freely available info they wish. By
the same token, people can choose not to provide that info to everyone
if there are undesirable side-effects. However, a society that prides
itself in rights and liberties for its members, should be willing to
takes certain risks in granting such lattitude to people. It's a price
we have to pay. It simply cannot justify becoming part of the problem.
Corydon Berg
io...@mist.demon.co.uk (Iolo Davidson) wrote:
>In article <5dl9i6$2...@sunbird.usd.edu>
> cwb...@sundance.usd.edu "Corydon Berg" writes:
>> io...@mist.demon.co.uk (Iolo Davidson) wrote:
>>
>> >Source code is of no value to AV people.
>>
>> Really? Why is this?
>Because it doesn't tell you what the virus does, only what the
>virus writer thought it would do. That's because virus writers
>tend to be poor programmers. AV researchers do their own
>disassemblies of virus executables instead. That way they get
>the true picture.
Maybe I'm missing something about disassembling, but doesn't
disassembling a program simply provide source code from the program?
Even if I missed something about disassmbling couldn't you assemble
the source code, do what needs to be done, and then disassemble it?
Is there a difference between a virus "caught" from the wild and a
virus you assemble yourself? I can see where one would have ethical
problems with assembling a virus (I would, but then again I'm not a
virus researcher).
Tani Akio Hosokawa
On Sun, 9 Feb 1997, Iolo Davidson wrote:
> > Just curious about Zhengxi. I mean, the bloody source code is
> > available now. Other scanners have been able to detect/remove it.
> > Why is F-Prot lagging behind here? Can't Bontchev fix it? Or Frisk?
> > Or *someone*?
> Source code is of no value to AV people.
If they're unable to determine how the generator works by generating test
samples, and they're too incompetent to analyse the actual virus to get at
the inner workings, surely having the source will help them.
Snorre Fagerland
io...@mist.demon.co.uk (Iolo Davidson) wrote:
>In article <32FFA8...@pki.uib.no>
> fage...@pki.uib.no "Snorre Fagerland" writes:
>>
>> The source code shows exactly the same as the disassembly, George & Iolo,
>No it doesn't.
Ok, I know you are thinking about the errors that are not so visible
in source as they are in disasm, Iolo, and you are right.
Let me rephrase; the source code shows approximately the same as the
disassembly. I do not mean that source codes are of vital importance
in AV work. I am saying that some information from the source codes
can be of use.
1.) If the source has errors, It can help show where the author made
his mistake, and what his intentions were. This gives an idea of what
to expect in the future.
2.) It can help get the general idea behind the virus, which is not
always obvious no matter how good you are to disassemble. You get that
immediately, without having to put down much work in it. For the
generally overworked population of the AV community I imagine this is
of some value. Combined with a disassembly it speeds up the analysis
process considerably.
3.) It can also contain information that can link the author to the
virus. The information in such sources is unreliable, and should be
read with a critical eye.
Regards,
Corydon Berg
Dmitry Gryaznov <er...@dial.pipex.com> wrote:
>Corydon Berg wrote:
>> I would have thought that the source code
>> (assuming it was the real source code for the virus) would be gold to
>> the AV people, or atleast silver. :)
>This means you have very little idea of how the AV people work :)
I never said I did. That's why I read this N/G, to get an idea about
how AV people work :)
>The source code is not even copper to us, let alone silver or gold.
>To give you just one reason: the same .ASM source compiled by different
>assemblers results in different binary files.
This makes sense, but there is still one thing that bothers me. You
are an expert in this field, from what I hear one of the best. But in
your hands the source code for a virus is worthless. At the same time
in the hands of a 2nd rate programmer the same source code is
potentially very destructive. Am I misunderstanding what you said?
I understand (while I think I do anyways) that the binary files of an
assembled program differ based on the CPU you happen to have, but
there is _nothing_ you can do with source code? Or is it that it
would be a waste of time to do anything with a virus until you can see
exactly how it was assembled?
Tarkan Yetiser
In article <5dql1s$l...@sunbird.usd.edu>, cwb...@sundance.usd.edu
wrote:
> Dmitry Gryaznov <er...@dial.pipex.com> wrote:
> >The source code is not even copper to us, let alone silver or gold.
> >To give you just one reason: the same .ASM source compiled by different
> >assemblers results in different binary files.
>
> This makes sense, but there is still one thing that bothers me. You
> are an expert in this field, from what I hear one of the best. But in
> your hands the source code for a virus is worthless. At the same time
> in the hands of a 2nd rate programmer the same source code is
> potentially very destructive. Am I misunderstanding what you said?
I think the point is overstated. Of course, the source could be
useful sometimes. The point is AVers don't have the luxury of relying
on the source, or looking for the source. You get a sample infecting
people's machines, and take the damn thing apart with a disassembler
to see what's going on. Who cares if the source is there or not.
Powerful disassemblers like IDA Pro makes things very convenient. Real
AVers don't use Sourcer ;-) Once you figure out what you need to
detect/remove the beast, it gets logged like the rest and committed to
the oblivion it deserves. OK, maybe a tech report would be in order if
it's ITW.
For macro viruses, it's even simpler. Many use automated tools to
process them wholesale.
For the virus writer, the source matters because his purpose is quite
different. He wants to write another variant based on that virus.
Since he may not be good at this stuff, he would have to rely on the
source. I really doubt the few "expert" virus writers would need
somebody else's code. But luckily, not many of those are around.
Unknown
On Sun, 09 Feb 97 15:43:25 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> Just curious about Zhengxi. I mean, the bloody source code is
>> available now. Other scanners have been able to detect/remove it.
>> Why is F-Prot lagging behind here? Can't Bontchev fix it? Or Frisk?
>> Or *someone*?
>Source code is of no value to AV people.
I'm not an AV person. But I believe Snorre Fagerland and Tarkan
Yetiser are. If they are AV people, and they find use of source code,
then your statement is definitely false. Unless you wish to claim
that they have never found any use for source, and that they are fools
for thinking that they have.
Unknown
On Sun, 9 Feb 1997 19:57:31 -0700,
gwe...@gpu.srv.ualberta.ca_REMOVE_THIS_TO_SEND_E-MAIL (George Wenzel)
wrote:
>AV people generally don't use source code to detect viruses. Source code
>shows what the author _intended_ the virus to do, not necessarily what it
>actually does.
Sounds good to me.
After all, it's quite apparent that the AV authors have no idea what
the virus author even intended, much less what it actually does.
Otherwise it would already be detected.
Unknown
>The source code shows exactly the same as the disassembly, George & Iolo,
>if you are sure that the source really belongs to the virus in question.
>I consider myself to be an AV person, and I have had my uses for source
>codes.
>
>That doesn't change the fact that distributing source codes is almost as
>unethical as distributing live virus code; the source is written information
>and cannot infect anyone by itself, still it has the possibility in it to be
>changed, mutated and recompiled in a way that live viruses doesn't.
>
>The author or anyone with access to source codes (or disassemblies for that matter)
>has to be aware of the end result of their actions. Distributing source is to
>contribute to the virus "flora" which is already far too large.
>
>It's not necessarily about law. Not necessarily about freedom either. It is about
>collective responsability (You know, the thing that makes you stop when you see a
>dying man on the street. You do stop? Not?)
Well, thanks for agreeing with my first point. Since zhengxi source
is out, a cure should be imminent from DSAV and F-Prot. But the rest
of it? All I said was the source is out, so the AV should use it.
Not that distributing source was good or bad, and nobody else
mentioned it either, I don't believe.
Unknown
On Mon, 10 Feb 97 17:12:09 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> The source code shows exactly the same as the disassembly, George & Iolo,
>No it doesn't.
Not in a binary sense, no. But for a polymorphic engine, it shows
what the engine will generate. Which is what you need to detect
products of that engine. So what's the problem?
>> if you are sure that the source really belongs to the virus in question.
>But this aspect is another possible problem of course.
No! Good grief. Can't you just assemble it with a few common
assemblers and compare it to the binary you already have? Surely you
can generate a sample that you can trace through to get the original
virus code, albeit in binary only. I don't believe zhengxi does any
mutation or changing of its internal constituents. So once you have
the unencrypted virus, you can compare it to an assembled source code.
If it's the same, you are 100% certain that it's correct.
Unknown
On Sun, 09 Feb 97 23:41:44 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> >Source code is of no value to AV people.
>> Really? Why is this?
>Because it doesn't tell you what the virus does, only what the
>virus writer thought it would do. That's because virus writers
>tend to be poor programmers. AV researchers do their own
>disassemblies of virus executables instead. That way they get
>the true picture.
Wrong. And I'm not just saying this because it's fun, I'm saying it
because I've just read written (typed) testimonial that it's wrong.
Just another thing - Would you say that the writer of Zhenxi was a
poor programmer?
>> I would have thought that the source code
>> (assuming it was the real source code for the virus)
>Another possible source of error, yes.
I already gave a method of determining whether it was the real source.
Made sense to me.
>> would be gold to the AV people, or atleast silver. :)
>Nope. Source is useless. The idea that it is of value to AV
>researchers is just more self justification rationalisation by
>virus writers.
Anyway...
Unknown
>This means you have very little idea of how the AV people work :)
>The source code is not even copper to us, let alone silver or gold.
>To give you just one reason: the same .ASM source compiled by different
>assemblers results in different binary files.
The binary image is not important in a polymorphic engine! The only
important part is the logic behind it!
Unknown
On Mon, 10 Feb 97 23:32:20 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> Maybe I'm missing something about disassembling, but doesn't
>> disassembling a program simply provide source code from the program?
>Could do (minus the authors erroneous comments), but there are
>lots of ways it can mislead too. One example, source might show
>a register being loaded from a labelled variable, while a
>disassembly would make it obvious that the relevent segment
>register wasn't even pointed at the segment the labelled variable
>was in. That is the kind of mistake virus writers make a lot.
>Virus writers confuse number bases a lot too, ending up using the
>wrong interrupt numbers as a result. That is more obvious in a
>dissassembly than in the source that the author confused himself
>with.
Perhaps it will mislead. On the other hand, it's all there to look
at, along with comments that give a clue as to what the intent was.
Analysing code to determine if the intent was realized is a lot easier
than looking at code to determine the intent AND whether it worked.
Here's a fun thought. You want to write a 3D game with
light-sourcing, perspective, weaving 'n' bobbing, texture-mapping,
etc.. You want to know how it works. You have the source code to
Quake. Do you, a) disassemble the 5+ megs of program, comment it
yourself, determine how everything works, then use that data, or b)
look at the source code, get an idea of how things work, and work from
there? I see a substantial time-savings in the second method.
>> Even if I missed something about disassmbling couldn't you assemble
>> the source code, do what needs to be done, and then disassemble it?
>You get different code from different assemblers/linkers. One
>source of variants. If you want to anylyse a variant that
>actually exists, you get that variant and disassemble it.
We're talking about Zhengxi. Polymorphic. That's what you want to
detect. Any jerk can do a string scan of the virus if it's not
encrypted. What you get from a different assembler won't matter as
regards what the source DOES. Virus writers don't encode an
instruction like LEA SI, [BP+0] and then move it to the encryption
buffer and assume that the assembler will not optimize it to MOV SI,
BP. Polymorphic engines do not do that because it would be stupid.
Instead, they determine the exact bytes to be generated, so the
assembler is NOT important.
>> Is there a difference between a virus "caught" from the wild and a
>> virus you assemble yourself? I can see where one would have ethical
>> problems with assembling a virus (I would, but then again I'm not a
>> virus researcher).
>Not just ethical problems. You can easily create a different
>variant.
If you're in an AV lab, then erase it when you're done looking at it.
Surely you're not going to accidentally post it to UseNet (and have
your account cancelled).
Unknown
>For the virus writer, the source matters because his purpose is quite
>different. He wants to write another variant based on that virus.
>Since he may not be good at this stuff, he would have to rely on the
>source. I really doubt the few "expert" virus writers would need
>somebody else's code. But luckily, not many of those are around.
Maybe they just release their source to their friends and a few virus
magazines that hardly anyone reads? :)
Unknown
On Tue, 11 Feb 97 18:01:47 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> If they're unable to determine how the generator works by generating test
>> samples,
>But of course they are competent to do this.
Zhengxi is *NOT* detected by F-Prot.
>> and they're too incompetent to analyse the actual virus to get
>> at the inner workings,
>And to do this too. More competent than the virus' writer.
Have you talked to all the virus writers on Earth? I'm certain that
God has not bestowed upon all anti-virus authors some great coding
power that dwarfs even the most competent virus writer. I know of
virus writers who competed at ASM '95 whose coding abilities at least
parallel those of Frisk or Bontchev. More likely, they exceed them.
These are professionals in various fields other than virus writing,
just as anti-virus authors are professional programmers. Their
respective creations no bearing on the quality. That would be like
saying a weapons engineer working for the US military is less
competent than a high school physics teacher, because weapons are
designed to hurt people.
>> surely having the source will help them.
>Nope. Complete waste of time.
Anyway...
Unknown
>This makes sense, but there is still one thing that bothers me. You
>are an expert in this field, from what I hear one of the best. But in
>your hands the source code for a virus is worthless. At the same time
>in the hands of a 2nd rate programmer the same source code is
>potentially very destructive. Am I misunderstanding what you said?
>
>I understand (while I think I do anyways) that the binary files of an
>assembled program differ based on the CPU you happen to have, but
>there is _nothing_ you can do with source code? Or is it that it
>would be a waste of time to do anything with a virus until you can see
>exactly how it was assembled?
It's not the CPU, it's the assembler and linker that you use. But
here's an example of how it could potentially be used (this code
fragment was written on the fly, and is therefore not actually in any
virus out there, but it still demonstrates the point).
_ax equ 0 ; the values for some
; registers as they are used
; when encoding instructions
_cx equ 1
_dx equ 2
_bx equ 3
...
mov di, offset e_buffer ; set DI to the offset of the
; encryption buffer
in al, 40h ; get byte from clock timer
test al, 2 ; check bit 1
jz skip_mov_ax ; if it's not set, skip
; encode MOV AX, 1234h
mov ax, (not(((_ax) xor 3465h)+1234h)) xor 1344h
xor ax, 1344h
not ax
sub ax, 1234h
xor ax, 3465h
mov bx, 1234h
call _mov_wreg_imm ; call the generation
; procedure
skip_mov_ax:
...
; encode a MOV word register, constant
; register: AX
; constant: BX
_mov_wreg_imm:
push ax ; save AX on the stack
push ax ; save AX again
in al, 40h
test al, 1 ; check bit 0
pop ax ; restore AX
jz _mov_use_add
or al, 0b8h ; 88h is the mask for
; MOV word register, constant
stosb
mov ax, bx
stosw
pop ax ; restore AX
retn
_mov_use_add:
push bx
mov bx, ax
call _sub_reg_reg ; zero the register
pop bx
call _add_reg_imm ; add the constant to the reg
pop ax
retn
...
e_buffer:
Now, assembler A vs. assembler B (and we'll ignore the most probably
variations), the offset of e_buffer will be different, the offset of
_mov_wreg_imm will be different, the JZ can be encoded as either a
short jump with a 8 bit offset or as a near jump with a 16 bit offset
(only on 386+), the MOV AX, BX can be encoded in two ways (by
reversing the direction bit it can be encoded as either "copy bx to
ax" or "copy ax from bx"), the MOV DI, AX is the same, as is any of
the two register operations, the retn could be encoded as "return
near" or "return near and adjust stack by zero" (C3 or C20000), and
there are others.
Looking from a logical perspective, what the code does is as follows:
get a number from the timer; check a bit; if that bit is clear, skip
the following code, else continue with the following: encode something
to store the value 1234h in the register AX, which will be done either
using a direct MOV register, constant or by SUB reg, reg/ADD reg,
constant.
If you're at all familiar with this sort of code, you immediately see
what's happened. So you make a heuristic with the following rule: the
data will either be MOV AX, 1234h OR SUB AX, AX/ADD AX, 1234h.
If you have to look at the binary and use something like DEBUG, that
will not be as readily apparent. Especially if you don't want to do
value xor 1234h, not, minus 1234h, xor 3465h in your head. Much
easier to see it represented in text, wouldn't you say?
Pierre Vandevenne
unknown said
: buffer and assume that the assembler will not optimize it to MOV SI,
: BP. Polymorphic engines do not do that because it would be stupid.
: Instead, they determine the exact bytes to be generated, so the
: assembler is NOT important.
Alignment may vary. The assembler is, to some extent, important. But not
as much as some posters have said, I agree.
--
Pierre Vandevenne, http://www.datarescue.com
February 5, 1997 - The Day Disassemblers changed forever !
Pierre Vandevenne
Unknown <unk...@sfu.ca> wrote in article
<3301ccb8...@news.sfu.ca>...
: On Mon, 10 Feb 97 17:12:09 GMT, io...@mist.demon.co.uk (Iolo Davidson)
: wrote:
:
: >> The source code shows exactly the same as the disassembly, George &
Iolo,
: >No it doesn't.
:
: Not in a binary sense, no. But for a polymorphic engine, it shows
: what the engine will generate. Which is what you need to detect
: products of that engine. So what's the problem?
The problem is that you have it mostly wrong here. I'd say that nobody
really cares about what the engine will generate as long as it doesn't
blow the emulator built in the a-v program. The reason some polymorphic
viruses are more difficult to handle than others is that they target the
emulator and make its job more difficult.
Your opinion would have been correct some time ago though, when anti-virus
detected polymorphics with procedural methods (trying to suppress
meaningless byte, trying to identify constant nibbles, etc...) but most
scanners don't work like that anymore. (granted, at least one major
product still does but if it stays afloat, this is only due to the
incredible talent of its main programmer).
Pierre Vandevenne
: Well, thanks for agreeing with my first point. Since zhengxi source
: is out, a cure should be imminent from DSAV and F-Prot. But the rest
: of it? All I said was the source is out, so the AV should use it.
Have you ever considered one tenth of a second that the problem might not
be in the understanding of the virus mechanisms but in the scanner's
architecture ?
Mr P R Walker
In article <3301cf16...@news.sfu.ca>,
unk...@sfu.ca (Unknown) writes:
>Quake. Do you, a) disassemble the 5+ megs of program, comment it
>yourself, determine how everything works, then use that data, or b)
You can't really compare Quake and a virus, though...
>>Not just ethical problems. You can easily create a different
>>variant.
>If you're in an AV lab, then erase it when you're done looking at it.
I think you misunderstood (but I'm willing to be corrected by ?Iolo) -
he meant that the assembled source might produce a different object, if
the virus author and he used different assemblers.
--
---
Any unsolicited commercial emails received will be proofread and
returned to source, along with a bill for 150UKP. Sending such
emails to my account will be deemed acceptance of these terms.
Unknown
On 12 Feb 1997 12:51:25 GMT, "Pierre Vandevenne"
<pie...@datarescue.com> wrote:
>The problem is that you have it mostly wrong here. I'd say that nobody
>really cares about what the engine will generate as long as it doesn't
>blow the emulator built in the a-v program. The reason some polymorphic
>viruses are more difficult to handle than others is that they target the
>emulator and make its job more difficult.
>
>Your opinion would have been correct some time ago though, when anti-virus
>detected polymorphics with procedural methods (trying to suppress
>meaningless byte, trying to identify constant nibbles, etc...) but most
>scanners don't work like that anymore. (granted, at least one major
>product still does but if it stays afloat, this is only due to the
>incredible talent of its main programmer).
Seems to me that if you have the source code, you could find a way
around that much quicker...
Unknown
On 12 Feb 1997 12:37:36 GMT, "Pierre Vandevenne"
<pie...@datarescue.com> wrote:
>: buffer and assume that the assembler will not optimize it to MOV SI,
>: BP. Polymorphic engines do not do that because it would be stupid.
>: Instead, they determine the exact bytes to be generated, so the
>: assembler is NOT important.
>Alignment may vary. The assembler is, to some extent, important. But not
>as much as some posters have said, I agree.
For mutation engine analysis, it doesn't matter at all.
>Pierre Vandevenne, http://www.datarescue.com
>February 5, 1997 - The Day Disassemblers changed forever !
What happened on February 5?
Unknown
On 12 Feb 1997 12:57:05 GMT, "Pierre Vandevenne"
<pie...@datarescue.com> wrote:
>: Well, thanks for agreeing with my first point. Since zhengxi source
>: is out, a cure should be imminent from DSAV and F-Prot. But the rest
>: of it? All I said was the source is out, so the AV should use it.
>Have you ever considered one tenth of a second that the problem might not
>be in the understanding of the virus mechanisms but in the scanner's
>architecture ?
What could be so difficult about Zhengxi that the architecture of a
scanner would stop it from detecting it?
Unknown
On 12 Feb 1997 13:35:50 -0000, cs...@csv.warwick.ac.uk (Mr P R Walker)
wrote:
>You can't really compare Quake and a virus, though...
What I'm saying here is that if you have source code, you can more
easily determine how something works.
>>>Not just ethical problems. You can easily create a different
>>>variant.
>>If you're in an AV lab, then erase it when you're done looking at it.
>I think you misunderstood (but I'm willing to be corrected by ?Iolo) -
>he meant that the assembled source might produce a different object, if
>the virus author and he used different assemblers.
My original point was that the binary image wasn't important for
determining the output of a poly engine. I may have been entirely
misled in this.
Pierre Vandevenne
: On 12 Feb 1997 12:57:05 GMT, "Pierre Vandevenne"
: <pie...@datarescue.com> wrote:
: >Have you ever considered one tenth of a second that the problem might
not
: >be in the understanding of the virus mechanisms but in the scanner's
: >architecture ?
:
: What could be so difficult about Zhengxi that the architecture of a
: scanner would stop it from detecting it?
You have the source, I don't. I guess you are in a best position than I am
to find out ?
--
Dmitry Gryaznov
> >To give you just one reason: the same .ASM source compiled by different
> >assemblers results in different binary files.
>
> are an expert in this field, from what I hear one of the best.
Thanks :)
> But in
> your hands the source code for a virus is worthless. At the same time
> in the hands of a 2nd rate programmer the same source code is
> potentially very destructive. Am I misunderstanding what you said?
No, you are not. That "2nd rate programmer" can simply just slightly modify
the source code, compile it - et voila, a new virus (variant) is ready.
BTW, this is exactly how those zillions of variants of Vienna appeared.
> I understand (while I think I do anyways) that the binary files of an
> assembled program differ based on the CPU you happen to have,
Not the CPU but rather - the assembler. You see, Intel instruction set
is very redundant. So that one and the same thing often can be experessed in
quite a few different binary codes (opcodes).
> but
> there is _nothing_ you can do with source code?
I didn't say "nothing". Sometimes it helps to understand what the virus author
_wanted_ to do, but not what s/he has actually _done_ :) Other than that, the value
of the source code to us is virtually nonexistant. Even when I have a source
code and an infected binary together, I _always_ look at the binary code,
and practically never - at the source code. Looking at the binary, I see much more
than what is written in the source code. And, of course, I never compile the
virus source code - what for?
> Or is it that it
> would be a waste of time to do anything with a virus until you can see
> exactly how it was assembled?
This too. We are never sure which particular assembler would be used by a
bad guy to compile the virus and thus what the actual binary, live virus
would be until we see the binary code. So, source code is of practically
no use to "signature" scanners developers.
And to heuristics, behaviour blockers and integrity checkers the source
code is even of less value, if it is possible to apply "less" in the case :)
--
Sincerely, | VirusLab, Dr.Solomon's Software Ltd.
Dmitry O. Gryaznov | Alton House, Office Park, Gatehouse Way,
Senior Research Consultant | Aylesbury, Bucks HP19 3XU, United Kingdom
E-mail: gr...@dial.pipex.com | Tel: +44 (0)1296 318700
WWW: http://www.drsolomon.com | Fax: +44 (0)1296 318734
Pierre Vandevenne
: On 12 Feb 1997 12:37:36 GMT, "Pierre Vandevenne"
: <pie...@datarescue.com> wrote:
:
: >Alignment may vary. The assembler is, to some extent, important. But
not
: >as much as some posters have said, I agree.
:
: For mutation engine analysis, it doesn't matter at all.
What if the mutation engine isn't analyzed :-) What if the a-v author
doesn't even look at the virus code ?
: >Pierre Vandevenne, http://www.datarescue.com
: >February 5, 1997 - The Day Disassemblers changed forever !
:
: What happened on February 5?
Well, that is an extremely good question. The answer is simple and
beautiful at the same time : disassemblers learned to speak.
Before February 5, a disassembler would give that kind of output
sub_0_2C2 proc near
push bp
mov bp, sp
mov ax, 0AAh
push ax
call sub_0_F66
pop cx
xor ax, ax
jmp short $+2
pop bp
retn
sub_0_2C2 endp
Now it gives this.
_main proc near
push bp
mov bp, sp
mov ax, 0AAh
push ax
call _printf
pop cx
xor ax, ax
jmp short $+2
pop bp
retn
_main endp
We called the technology FLIRT for "Fast Library Identification and
Recognition Technology". For one second, we considered calling it the
"Golden Bullet" but the idea was already kind of old and FLIRT is more
romantic.
Have a look at the http://www.datarescue.com/ida.htm, there are a few
evaluation versions, a disassembled sample and a few other things that may
interest you.
Unknown
On 12 Feb 1997 16:59:59 GMT, "Pierre Vandevenne"
<pie...@datarescue.com> wrote:
>: For mutation engine analysis, it doesn't matter at all.
>What if the mutation engine isn't analyzed :-) What if the a-v author
>doesn't even look at the virus code ?
Been thinking about that. I'll be getting back to everyone about
stuff like that.
>: What happened on February 5?
>Well, that is an extremely good question. The answer is simple and
>beautiful at the same time : disassemblers learned to speak.
Sounds interesting. I've used IDA before - hadn't realized that a
major upgrade had occurred. Thanks for the pointer.
-----------------------------------------------
This is my 4-line, netiquette-abiding signature
e-mail: unkn...@geocities.com
-----------------------------------------------
Dmitry Gryaznov
Snorre Fagerland wrote:
>
> io...@mist.demon.co.uk (Iolo Davidson) wrote:
>
> >In article <32FFA8...@pki.uib.no>
> > fage...@pki.uib.no "Snorre Fagerland" writes:
> >>
>
> >No it doesn't.
>
> in source as they are in disasm, Iolo, and you are right.
>
> Let me rephrase; the source code shows approximately the same as the
> disassembly. I do not mean that source codes are of vital importance
> in AV work. I am saying that some information from the source codes
> can be of use.
Now let me rephrase:
*Sometimes* *some* information from *some* virus sources can be of *some*
(very limited) use.
> 1.) If the source has errors, It can help show where the author made
> his mistake, and what his intentions were. This gives an idea of what
> to expect in the future.
Yes, but this is almost never important - serves more your own curiosity
than anything else :)
> 2.) It can help get the general idea behind the virus, which is not
> always obvious no matter how good you are to disassemble. You get that
> immediately, without having to put down much work in it. For the
> generally overworked population of the AV community I imagine this is
> of some value. Combined with a disassembly it speeds up the analysis
> process considerably.
Analysis? What analysis? :) It may come as a surprise to many, but today
a thorough analysis of a virus is *very* rarely necessary for the virus
detection and removal. (That's why we are not always immediately ready to
provide a user with the information on what this or that particular virus
does besides replicating :)) And the really essential analysis - to get
the info needed for your scanner to be able to detect and remove the virus -
is done, with few extremely rare exceptions, semi- or even fully automatically.
> 3.) It can also contain information that can link the author to the
> virus. The information in such sources is unreliable, and should be
> read with a critical eye.
This might be of interest to the law enforcement agencies, not to
the AV developers as such.
cwb...@sundance.usd.edu
In article <33021F...@dial.pipex.com>,
Dmitry Gryaznov <er...@dial.pipex.com> wrote:
> >
> Analysis? What analysis? :) It may come as a surprise to many, but today
> a thorough analysis of a virus is *very* rarely necessary for the virus
> detection and removal. (That's why we are not always immediately ready to
> provide a user with the information on what this or that particular virus
> does besides replicating :)) And the really essential analysis - to get
> the info needed for your scanner to be able to detect and remove the virus -
> is done, with few extremely rare exceptions, semi- or even fully
> automatically.
>
Is this why so many enteries in the F-Prot virus information say "Not
analysed yet"? This isn't a dig at F-Prot, it's just the virus
"encyclopeda" I use most.
This brings me to yet another question. What does an analysis of a virus
consist of? Is it just a disassembling of the thing and finding out its
particulars?
Cory -aka- WEED Lipps
http://www.usd.edu/~cwberg/
(--)
"When it pains, it roars" -- tJL
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Luis Rosales
if you know the library maybe you can understand the parameters and
do this output (of course when it isn't very difficult).
.286+
from:
push bp
mov sp, bp
push 0AAh ; "Number : %d, %X"
push 2
push 45
call sub_0_F66 ; printf
pop cx
pop cx
pop cx
...
...
to:
push bp
mov sp, bp
printf("Number : %d, %X", 2, 45);
xor ax, ax
jmp short $+2
pop bp
Some day a disassembler could give us this output?
Luis
firebug
On Wed, 12 Feb 97 18:28:08 GMT, Iolo Davidson <io...@mist.demon.co.uk> wrote:
>In article <3301ccb8...@news.sfu.ca> unk...@sfu.ca "Unknown" writes:
>> On Mon, 10 Feb 97 17:12:09 GMT, io...@mist.demon.co.uk (Iolo Davidson)
>> wrote:
>>
>> >No it doesn't.
The source shows the same as the disassembly (for something written in
assembly, of course), except you have the advantage of things such as the
author's comments, variable names, separation of code and data, separation
and naming of different subroutines, and selection of the appropriate
mnemonic when several share an opcode. The assembler can guess at those
things, of course, but in any reasonable case it's not going to give better
output than the actual source code.
>> Not in a binary sense, no. But for a polymorphic engine, it shows
>> what the engine will generate.
>
>No, it shows what the author thinks he has written. A
>disassembly is the only thing an AV researcher woul;d rely on.
This is really quite stupid. The source is not required, but how can you
possibly say that it doesn't show exactly what the program does? The source
might be difficult to read or do unintended things, but certainly a
disassembly isn't going to be any better unless some pretty unusual
measures were taken to make the source unreadable.
You don't actually know any programming languages at all (let alone any
assembler), do you?
firebug
On Wed, 12 Feb 1997 19:41:05 -0600, cwb...@sundance.usd.edu <cwb...@sundance.usd.edu> wrote:
>In article <33021F...@dial.pipex.com>,
> Dmitry Gryaznov <er...@dial.pipex.com> wrote:
>> Analysis? What analysis? :) It may come as a surprise to many, but today
>> a thorough analysis of a virus is *very* rarely necessary for the virus
>> detection and removal. (That's why we are not always immediately ready to
>
>consist of? Is it just a disassembling of the thing and finding out its
>particulars?
Judging from the analyses of Bliss by McAfee and Data Fellows, it appears
to consist of making random statements without ever looking at the actual
virus.
Also, while I'm at it, I should mention that selection of a search string
appears to consist of selecting 16 bytes at random from the virus.
Terry
fir...@atlantic.net (firebug) wrote:
>The source shows the same as the disassembly (for something written in
>assembly, of course),
Unless it includes the exact bytes for every instruction (a listing)
the source most definitely does not show what a disassembly does.
A hex dump tells much more than original source does.
> except you have the advantage of things such as the
>author's comments,
Aha, the only good use for source, casual reading material...
> variable names, separation of code and data, separation
>and naming of different subroutines, and selection of the appropriate
>mnemonic when several share an opcode.
What difference do the names of a subroutine and variables make?
It's the output that matters.
> The assembler can guess at those
>things, of course, but in any reasonable case it's not going to give better
>output than the actual source code.
The assembler will give Different output unless the Exact same assembler
and options are used, different output means a different virus.
> The source is not required, but how can you
>possibly say that it doesn't show exactly what the program does?
If it doesn't show the bytes it doesn't.
> The source
>might be difficult to read or do unintended things, but certainly a
>disassembly isn't going to be any better unless some pretty unusual
>measures were taken to make the source unreadable.
I know the same source can generate Many different outputs, so without
the actual hex I can't see how the original source would be useful
unless compared side-by-side with a dissassembly that shows the hex
that shows what's really going on.
Many instructions can be expressed in many different ways. The
A86 assembler uses this fact to 'mark' files as being A86-made.
TASM file.asm gives Different output that TASM /M3 file.asm, the
difference being three byte jumps vs. two byte jumps. What if some
point was being addressed absolutely? Someone just reading source
probably wouldn't notice but the disassembly leaves no question.
I'm not knocking original sources so much, they have value to me
but not for research. They are good for studying motives/intents or
simply collecting for the sake of historical preservation (I know
most of you guys think that's stupid, but maybe when viruses become
a long lost memory it won't seem so stupid...) An original source
captures a moment of creation, but it does not capture what was
actually created so it is probably of no use to researchers.
- Terry
Snorre Fagerland
Hi Dmitri, you wrote:
>Now let me rephrase:
>*Sometimes* *some* information from *some* virus sources can be of *some*
>(very limited) use.
Have no problems with that wording.
>> 1.) If the source has errors, It can help show where the author made
>> his mistake, and what his intentions were. This gives an idea of what
>> to expect in the future.
>Yes, but this is almost never important - serves more your own curiosity
>than anything else :)
Yes - well my curiosity is formidable :)
>> 2.) It can help get the general idea behind the virus, which is not
>> always obvious no matter how good you are to disassemble. You get that
>> immediately, without having to put down much work in it. For the
>> generally overworked population of the AV community I imagine this is
>> of some value. Combined with a disassembly it speeds up the analysis
>> process considerably.
>Analysis? What analysis? :) It may come as a surprise to many, but today
>a thorough analysis of a virus is *very* rarely necessary for the virus
>detection and removal. (That's why we are not always immediately ready to
>provide a user with the information on what this or that particular virus
>does besides replicating :)) And the really essential analysis - to get
>the info needed for your scanner to be able to detect and remove the virus -
>is done, with few extremely rare exceptions, semi- or even fully automatically.
Yes, but this is how it is done with you in DrS and some others, not
all AV developers do this.
However, I am not referring to the simpler run-of-the-mill virus. I am
referring to the cases where you get something with a new approach.
What did you do, Dmitri, with Zhengxi the first time you saw it? Or
Win.Apparition? Or even Spicegirls, which I doubt your automatic virus
analyser understood much of? In these cases you need a manual
analysis, and a source, well, any kind of additional information would
be of help.
Besides, I personally think that all in-the-wild viruses should be
manually analysed in order to get a proper profile of the virus - not
only saying that it will infect *.EXE files and append X bytes, but
also if it does any damage, under what circumstances it does
damage, and whatever other information that might be of interest. But
that is just me. :)
Regards,
Snorre Fagerland
Engineer
University of Bergen - Norway
Pierre Vandevenne
Luis Rosales <94122...@mexico.edu.mx> wrote in article
<5dtbe5$o...@lana.zippo.com>...
: if you know the library maybe you can understand the parameters and
: do this output (of course when it isn't very difficult).
: push bp
: mov sp, bp
: printf("Number : %d, %X", 2, 45);
: xor ax, ax
: jmp short $+2
: pop bp
:
: Some day a disassembler could give us this output?
In theory, they could even do better than that. The problem is how to do
it in a practical way and for a sufficient number of compilers to be
useful in real life. Main problems are : storage and speed. (sounds like
something I have heard before).
But we are not really on topic here. Feel free to e-mail me if you want
more information.
Unknown
On Wed, 12 Feb 97 19:04:32 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>Yeah, that's right, you don't know how emulation works, do you?
>But it doesn't stop you claiming that source is the answer.
I know how emulation works. I didn't know that it was used in F-Prot.
However, would the source not help McAfee, who I would doubt uses
emulation?
>From time to time, some new virus comes along that requires the
>scanner engine to be changed, for whatever reason. This takes
>longer than just adding yet another batch of the same old kind of
>viruses to the search database. The problem is nothing to do
>with analysing the virus, and source is not an issue. The
>problem is writing, testing and publishing new executables. It
>takes some time to get the new stuff through the production
>process.
The source is an issue if you'd like to take a quick look at what the
virus is intended to do. If you're only interested in finding a scan
string, then it probably doesn't matter.
Unknown
On Wed, 12 Feb 97 19:10:12 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> What I'm saying here is that if you have source code, you can more
>> easily determine how something works.
>And everyone else is saying no, where viruses are concerned, you
>don't need source, you need your own disassembly. That's the
>EASY way. Messing with source is simply an opportunity for
>confusion.
Would you believe that they're not all saying that?
Unknown
On Wed, 12 Feb 97 18:44:00 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> Wrong. And I'm not just saying this because it's fun, I'm saying it
>> because I've just read written (typed) testimonial that it's wrong.
>No you've seen one person disagree with me. I happen to have
>done virus research professionally for an anti-virus scanner
>producer. I don't think the person who disagreed with me has
>done that.
A distinction only in your own mind.
>> Just another thing - Would you say that the writer of Zhenxi was a
>> poor programmer?
>Haven't looked at it. I suspect he isn't much or he would be
>doing something worthwhile. He certainly has something wrong
>with him in the area of ethical development.
You never cease to amaze me. You seriously believe that because a
person writes viruses, that person is a poor coder, or that having
underdeveloped ethics (in your opinion) would somehow affect his
coding ability? Does this action of writing viruses somehow make
people stupider than those who are "good" and do not write viruses?
I know professional programmers, graduate engineers, and research
physicists who have written viruses. These people are extremely good
programmers, and extremely bright individuals. In some cases,
brilliant. The fact that they have written viruses changes nothing.
Unknown
On Wed, 12 Feb 97 18:23:24 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> I understand (while I think I do anyways) that the binary files of an
>> assembled program differ based on the CPU you happen to have,
>Eh?
Surely his meaning wasn't that confusing. He was quite obviously (or
perhaps my virus-addled mind is playing tricks on me) making a
slightly skewed reference to the different binary output produced by
differing assemblers/linkers.
Unknown
On Wed, 12 Feb 97 19:03:21 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> Seems to me that if you have the source code, you could find a way
>> around that much quicker...
>Just use your own disassembly, and cut out a source of confusion.
Just out of curiousity, has any AV researcher done a disassembly of
Zhengxi?
Unknown
On Wed, 12 Feb 97 18:52:04 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> The binary image is not important in a polymorphic engine!
>Sure it is. If you knew how Findvirus worked, you would realise
>that it sees though the encryption and recognises the virus by
>the decrypted binary image.
F-Prot and FindVirus do not always "see through" the encryption.
>> The only important part is the logic behind it!
>Virus writers probably don't even look at their own binaries. AV
>people do, because it is possible to find out things the virus
>writer doesn't realise, like easy ways to recognise particular
>polymorphics.
You complain about misinformed postings, yet you're as misinformed as
anyone else. Virus writers *do* look at the binaries.
Unknown
On Wed, 12 Feb 97 18:36:18 GMT, io...@mist.demon.co.uk (Iolo Davidson)
wrote:
>> Zhengxi is *NOT* detected by F-Prot.
>So what? All that means is that the detection routine has taken
>some time to write, test, publish, etc. The product updating
>cycle takes a while even for straightforward viruses. New
>techniques take longer. It happens from time to time. I
>remember when Tequila first came out; it took a while for some
>products to put new methods in place to deal with it. Same with
>macro viruses. The one thing they have *not* been waiting for is
>source.
Other AV products detected Zhengxi long ago. If it's taking that
long, perhaps the programmers at F-Prot aren't very good. Why, if the
programmers at F-Prot aren't very good, maybe all AV authors are
inferior coders. I would also suggest that they have an set of
overdeveloped ethics, which may also be a factor.
>> >And to do this too. More competent than the virus' writer.
>> Have you talked to all the virus writers on Earth?
>I don't have to talk to them. I have seen their code. The vast
>majority are really crappy programmers. Awful.
You really seem to like this mass-labelling thing. Everything from
virus writers to the military.
>> I know of
>> virus writers who competed at ASM '95 whose coding abilities at least
>> parallel those of Frisk or Bontchev. More likely, they exceed them.
>That is what you get for talking to virus writers, or rather
>listening.
The distinction between talking and listening is obvious - why are you
pointing it out? More to the point, what was YOUR point?
Fridrik Skulason
>What I'm saying here is that if you have source code, you can more
>easily determine how something works.
In general, maybe...with something written in C or Pascal, yes indeed.
However, this does not thange the fact that AV developers generally don't
bother to look at virus sources.
>My original point was that the binary image wasn't important for
>determining the output of a poly engine.
Well..that is just plain wrong.
-frisk
--
Fridrik Skulason Frisk Software International phone: +354-5-617273
Author of F-PROT E-mail: fr...@complex.is fax: +354-5-617274
Mr P R Walker
In article <3301fc8e...@news.sfu.ca>,
unk...@sfu.ca (Unknown) writes:
>What I'm saying here is that if you have source code, you can more
>easily determine how something works.
That's the way it works for us mortals, but AV programmers don't
seem to need this :)
>My original point was that the binary image wasn't important for
>determining the output of a poly engine. I may have been entirely
>misled in this.
I would imagine it does play a part - but I've never written a poly
engine, so I don't know for certain.
Moshe Litvin
On Tue, 11 Feb 1997 17:14:25 +0000, Dmitry Gryaznov
<er...@dial.pipex.com> wrote:
>This means you have very little idea of how the AV people work :)
>The source code is not even copper to us, let alone silver or gold.
>To give you just one reason: the same .ASM source compiled by different
>assemblers results in different binary files.
If you compile the virus in a different assembler you can get a
different binary file, that may be functional and yet not recognizable
by a scanner designed to catch the ITW virus. But if the source is out
there, anyone can do it and produce another strain just by recompiling
it. It seem reasonable AV people will try to compile the source with
several assemblers in order to predict the possibly future virus?
Isn't it?
Moshe Litvin
Dmitry Gryaznov
No, it is not. We are not creating viruses or variants of those. Got
to do with our code of ethics. We are ANTI-virus developers, not
virus writers.
And besides, it would be simply impracticable - waste of time.
We've got our hands full with those dozen or so new viruses arriving
daily, so it makes absolutely no sense to generate new ones (or variants).
Tarkan Yetiser
In article <33045a21...@news.netvision.net.il>, no...@none.il
> On Tue, 11 Feb 1997 17:14:25 +0000, Dmitry Gryaznov
> <er...@dial.pipex.com> wrote:
>
> >This means you have very little idea of how the AV people work :)
> >The source code is not even copper to us, let alone silver or gold.
> >To give you just one reason: the same .ASM source compiled by different
> >assemblers results in different binary files.
>
> If you compile the virus in a different assembler you can get a
> different binary file, that may be functional and yet not recognizable
> by a scanner designed to catch the ITW virus. But if the source is out
> there, anyone can do it and produce another strain just by recompiling
> it. It seem reasonable AV people will try to compile the source with
> several assemblers in order to predict the possibly future virus?
> Isn't it?
That's an interesting point Moshe, but I've never heard of AVers doing
that.
--
Regards
Tarkan Yetiser
VDSARG
http://home.prolog.net/~tyetiser
http://www.ccso.com
A foolish consistency is the hobgoblin of little minds...
Emerson
Patrick Noyens
On Fri, 14 Feb 1997 10:27:32 GMT, unkn...@geocities.com (Unknown)
wrote:
>On Wed, 12 Feb 97 19:03:21 GMT, io...@mist.demon.co.uk (Iolo Davidson)
>wrote:
>
>>> Seems to me that if you have the source code, you could find a way
>>> around that much quicker...
>>Just use your own disassembly, and cut out a source of confusion.
>
>Just out of curiousity, has any AV researcher done a disassembly of
>Zhengxi?
Sure !
There are at least 3 AV products that can detect it very accurate.
Eugene Kasperky (AVP) has written a nice paper about it.
take a look at :
http://www.avp.ch/avpve/file/z/zhengxi.stm
There are probably other AV researchers who did a disassembly or even
a complete analysis from it. (VB, FS, IM, ID, PB, DG, RR and VB(2) go
through my mind, there are others)
Patrick Noyens
-------------------------------------------------------------------------------
E-mail : patrick...@ping.be
PGP-key available on request.
Key fingerprint = 01 31 60 FF C2 0F D4 A7 D2 83 64 FE 3E 3F 83 79
Patrick Noyens
On Fri, 14 Feb 1997 10:27:39 GMT, unkn...@geocities.com (Unknown)
wrote:
>On Wed, 12 Feb 97 18:52:04 GMT, io...@mist.demon.co.uk (Iolo Davidson)
>wrote:
>>> The binary image is not important in a polymorphic engine!
>>Sure it is. If you knew how Findvirus worked, you would realise
>>that it sees though the encryption and recognises the virus by
>>the decrypted binary image.
>F-Prot and FindVirus do not always "see through" the encryption.
You're right about this.
This is because of the limitations from the current emulator from
FindVirus (F-Prot 2.XX is an exception). Viruses can contain
anti-debugger code to make the emulation more difficult and even
impossible for the current emulator from FindVirus.
>>> The only important part is the logic behind it!
>>Virus writers probably don't even look at their own binaries. AV
>>people do, because it is possible to find out things the virus
>>writer doesn't realise, like easy ways to recognise particular
>>polymorphics.
>
>You complain about misinformed postings, yet you're as misinformed as
>anyone else. Virus writers *do* look at the binaries.
Probably some of them do, however most of them don't seem to look very
close, because a lot viruses seem to contain bugs.
Dr Alan Solomon
In article <5do104$7...@sunbird.usd.edu>, Corydon Berg (cwb...@sundance.usd.edu) writes:
>io...@mist.demon.co.uk (Iolo Davidson) wrote:
>
>> cwb...@sundance.usd.edu "Corydon Berg" writes:
>
>>> io...@mist.demon.co.uk (Iolo Davidson) wrote:
>>>
>>> >Source code is of no value to AV people.
>>>
>>> Really? Why is this?
>
>>Because it doesn't tell you what the virus does, only what the
>>virus writer thought it would do. That's because virus writers
>>tend to be poor programmers. AV researchers do their own
>>disassemblies of virus executables instead. That way they get
>>the true picture.
>
>Maybe I'm missing something about disassembling, but doesn't
>disassembling a program simply provide source code from the program?
No, it doesn't. It provides a disassembly of the problem. That simply
isn't the same thing.
>Even if I missed something about disassmbling couldn't you assemble
>the source code, do what needs to be done, and then disassemble it?
No. If you have the binary, why make another copy by assembleing the
source? If you don't have the binary, maybe it doesn't exist. If it does
exist, there's no way of knowing what assembler might have been used
unless you have the binary.
--
Alan Solomon, Chairman, AuthenTec Data Recovery and Computer Forensics
Personal: drs...@ibmpcug.co.uk http://www.ibmpcug.co.uk/~drsolly
Business: alan.s...@authentec.sprint.com AOL Keyword SAFETYONLINE
I use Dr Solomon's Antivirus, from Dr Solomon's Software Ltd.
DSSL: http://www.drsolomon.com email: sup...@drsolomon.com
Dr Alan Solomon
In article <5dl9i6$2...@sunbird.usd.edu>, Corydon Berg (cwb...@sundance.usd.edu) writes:
>io...@mist.demon.co.uk (Iolo Davidson) wrote:
>
>>Source code is of no value to AV people.
>
>(assuming it was the real source code for the virus) would be gold to
>the AV people, or atleast silver. :)
No. I used to get viruses in source and binary sometimes, and the source
was so non-useful, I only ever looked at it to read the sometimes-funny
posturings of the virus author in the header and comments. Oh, and I
remember one virus source code where the header gave a vital clue to the
true identity of the author, and I remember Detective Constable Noel
Bontochek doing a little dance when he saw it.
krakan
On Wed, 12 Feb 1997 15:14:16 GMT, unk...@sfu.ca (Unknown) wrote:
>On Sun, 09 Feb 97 15:43:25 GMT, io...@mist.demon.co.uk (Iolo Davidson)
>wrote:
>
>>> Just curious about Zhengxi. I mean, the bloody source code is
>>> available now. Other scanners have been able to detect/remove it.
>>> Why is F-Prot lagging behind here? Can't Bontchev fix it? Or Frisk?
>>> Or *someone*?
>>Source code is of no value to AV people.
>
>I'm not an AV person. But I believe Snorre Fagerland and Tarkan
>Yetiser are. If they are AV people, and they find use of source code,
>then your statement is definitely false. Unless you wish to claim
>that they have never found any use for source, and that they are fools
>for thinking that they have.
>
Having been in software/hardware defsign for some 30 years I am sure
as a programmer that having any related source code can be useful.
Especially as modifications are sure sure to come out...
Fridrik Skulason
In <3301d18f...@news.sfu.ca> unk...@sfu.ca (Unknown) writes:
>what's happened. So you make a heuristic with the following rule: the
>data will either be MOV AX, 1234h OR SUB AX, AX/ADD AX, 1234h.
Uh...why on earth would anyone want to do that ?
>If you have to look at the binary and use something like DEBUG, that
>will not be as readily apparent.
Pardon me, but that is exactly what I do all the time....those things
are very obvious to anyone with 10+ years of experience in looking at programs
with DEBUG.
Fridrik Skulason
In <8557976...@dejanews.com> cwb...@sundance.usd.edu writes:
>Is this why so many enteries in the F-Prot virus information say "Not
>analysed yet"?
simple....back in '89 viruses were few and far between - one could easily afford
to spend hours or even days analysing each new virus....even create a commented
disassembly for each new virus as it appeared.
Today, with over 10 new viruses appearing per day, nobody analyses every single
new virus any more - most viruses just get the minimal analysis required to
determine how to detect and remove them, and that process can be made almost
automatic....we have automatic virus replication systems, automatic virus
analysis systems, automatic disinfection information generators and so on...
but no virus analysis "the old way"...
krakan
On 15 Feb 1997 12:02:18 -0000, fr...@complex.is (Fridrik Skulason)
wrote:
>In article <33045a21...@news.netvision.net.il>, no...@none.il
>
>> It seem reasonable AV people will try to compile the source with
>> several assemblers in order to predict the possibly future virus?
>> Isn't it?
>
>No...it is very unreasonable, and unethical as well, as it would mean that
>we would in effect be creating (if only for our own use) new viruses.
>
>-frisk
>
>--
>Fridrik Skulason Frisk Software International phone: +354-5-617273
>Author of F-PROT E-mail: fr...@complex.is fax: +354-5-617274
unreasonable one thing but to protect my system from a virus I really
am less interested in ethics with regards to people reassembling a
virus in order to catch it better.
Just say its too much work to reassemble/recompile with all the
various assemblers/compilers and I can quite understand it...
David Harley
: >> : > >Off the top of my head: EXE, COM, OV?, SYS, DLL, BIN, CMD, BAT, DOC,
: >> : > DOT. There are a bunch of other more esoteric ones too.
: >OVL - Overlay files?? Not likely.. SYS files, nop, Dynamic Links, nop,
: >Binaries - Maybe, if so INF as well... CMD NOP, BAT Only Keyboard
: >remaps, DOC Macro virus...
The extensions .EXE, .BAT and .COM are actually hardcoded into DOS.
It's trivial to alter these (one minute with DEBUG). It's almost
as trivial to write a shell program to EXEC a program without
reference to its extension, as long as the file structure is
correct. In most cases, a virus would ignore executables with
non-standard names, but not all.
OVL for overlay files is a convention, not mandatory. That's why
Graham specified OV?, but you could use XYZ, if you really wanted to.
Of course, a virus would probably then have to target your specific
application, but that wouldn't be the first time.
A Word document can have any legal extension, or none (so can a
template). [Talking of which, don't forget .WIZ and .WLL]
Ergo, if you want to cover every possibility, you have to scan all
files. I don't think you can guarantee that a particular filetype
will never execute code on your own system, let alone anyone else's.
You might like to consider .CFGs, too. DBF opens up a couple of
possibilities.
Just because you're paranoid, it doesn't mean.........
--
David Harley \ | / alt.comp.virus FAQ
D.Ha...@icrf.icnet.uk \ | / & Anti-Virus Web Page
Support & Security Analyst \ | / Folk London On-Line gig-list
Imperial Cancer Research Fund ____\|/____ http://webworlds.co.uk/dharley/