Why NOD32 is so Light?

Why NOD32 is so Light?

Help file of Kaspersky:

"Other anti-virus products speed up scanning by excluding both viruses which are less easily detectable or less frequent in the geographic location of the anti-virus vendor, and file formats that require complicated analysis (e.g. PDF) from their databases"

is this the reason?

 

Nah.

NOD32 has been developed with Assembly code rather than high level (e.g. C++) code for other scanners which is why it is so fast.

 

Also Nod32 doesnt have as many unpackers as Kaspersky. Unpacking is an intensive task.

 

Light to me means the effect on daily use with an AV's Real Time scanner running. That is one of the reasons we run NOD on a gaming machine with no noticeable effect while gaming.

http://www.slovakspectator.sk/clanok-358.html

Of course others may have a different experience depending upon
their platform

 

Firecat,

Assembly code guarantees nothing. Poorly executed assembler will run slower than a well conceived implementation using a higher level language.

I'd assume that the origin of the speed of NOD32 is more related to the basic design of the program than the language used in the coding - although some higher level languages will have better native support for the fundamental operations of an AV than others. If you want to be perverse, there's no fundamental reason that the main engine of an AV cannot be written in something like Fortran. It's all 1's and 0's in the end.

Blue

 

NOD32 is efficiently built.
It's smoking fast.
The compromise should be between Speed (NOD32, DrWeb) and a Deep Scan (KAV,McAfee).
Unpacking engine have to be an issue.

For instance, imagine you have AH active all the time for AMON (create, read, write)...but a less deep scan doesn't say less protection. It's like scanning archives in real time I presume...not sure it's a relevant comparison...

One thing is clear, kudos to Eset to have built such a blazing fast scanner without forsaking protection.

 

Maybe NOD32 doesn't use many static unpackers like KAV does,but they do majority of work through emulator. Of course they also use static unpackers.
AH is used for On-Create and for On-Demand scanning (optional for both).
Using AH for all operations would be waste of system power i belive.
When you download from net you get on-create action,when you extract from archive you get on-create,when you copy from optical/floppy media you get on-create and even when you copy from one logical drive to another you get on-create action. But other things are known only to ESET people...

 

also the virus database in nod32 doesnt have outdated or harmless malware. eset keeps the database lean and mean. this also contributes to its lightness.

 

The usual BS, everything which isn't in the Nod signatures are clasified as "outdated or harmless malware", the main reason Kav is slower when scanning is because they can unpack more than 900 different types and not necessary because Kav has a bigger signaturebase.

 

Is all this upacking also occuring with the KAV Real Time scanner or just the On Demand scanner?

 

Signature pattern matching isn't as demanding process as many may think.
Sure it takes some "power",but decompression is usually even more demanding task. And when you have excellent unpacking support you sure get a bit slower because of that.

 

it has to include the RTM. when i used it, it unpacked the bittorrent installer and found something. it also unpacked the wildtangent installer and flagged it as malware. the RTM in KAV is powerful if u ask me. also teh scanning depends on the database u select and the settings.

 

Then is that one of the reasons some folks may find KAV slower then some other AVs for just normal everyday use and not running the On Demand scanner?

 

No, Kav don't waste any time scanning insíde archives in real-time, a very good decision IMO, as they are handled as soon as they are extracted, so there are good reasons for not doing this in real-time. This is also why some can't understand why Kav doesn't detect the eicar zips, just extract. The webscan in Kav 2006 will detect them though.

Btw. I scanned on-demand today and it took 7:26 minutes for 83000 files on a just reinstalled partition, the same partition takes around 5 minutes with Nod 2.5, so yes Nod is faster, but maybe not as much as many think on a fresh install with no previous AV installs.

 

Hi Don Pelotas,

Thanks for the reply!

 

what about installer, like i mentioned KAV scanned a few and found malware. thats still considered unpacking right?

 

Don.

This is in quantitative agreement with my own observations, see here. The only difference is the fileset for my scan was over 1 million files. In other words, I think that relative speed metric is a fairly good number.

Blue

 

I stand corrected.

 

When I was using eScan (KAV engine) I observed that both the RTM and the On-Demand Scanner used the same core engine files to support the GUI. I even experimented with some files packed with UPX and I think one was packed with TELock....Anyhow, it (RealTime Monitor) did scan those files (which had EICAR test virus in them) and detect the testfile.

 

No problem Firecat, I usually say that about five times a day myself.

Good assembly can be very fast, but optimized compilers really aren't bad either. As usual, good algorithms and holistic design can go a long way.

At least you didn't have to survive the language and compiler "wars" of the 70's and 80's (mainly).

Blue

 

I have a question - Given I had a choice to develop using either assembly or optimized high-level language, which one would take less time to finish development? (Assuming that sometimes optimizing for different hardware can be tough)

I know its a question of experience of the developer - but lets assume the developer has equal experience with both....

 

ASM is much more complex.

 

Absolutely.

If it is assembly vs. higher language for any major and complex effort, development time with the higher level language will be significantly lower.

Blue

 

Has this test given some unknown things up that were not so very known to us? Here many of those samples were packed with some different packers where NOD was uncapable to detect them.

http://av-test.mycity.co.yu/uporedna_tabela_en.html

The most informative section you can find it here in test 1. (click from the left of that site).

http://av-test.mycity.co.yu/index_en.html

Just only wanting some honest declarations!

Best regards,
Firefighter!