Advanced Heuristics very slow for some files

Discussion in 'ESET NOD32 Antivirus' started by GAN, Apr 20, 2009.

Thread Status:
Not open for further replies.
  1. GAN

    GAN Registered Member

    Joined:
    Mar 3, 2007
    Posts:
    355
    I been using Nod32 2.x, 3.x and 4.x for some time now and find Advanded Heuristics to be very slow for some files using nod32 v4. Maybe i'm wrong, but i cannot remeber this to be a problem in the past. Either way there must be something completely wrong. One example is the google toobar installer (http://toolbar.google.com/T6/intl/en/index.html). When finished downloading it takes very long to scan this 1.8mb file. If i disable advanced heuristics the problem disappear. If i move the google toolbar installer from one folder to another on my local computer it takes 9 seconds to move the file when advanced heuristics is enabled. When AH is disabled it takes less then a second and too fast to see how long time it takes to move the file. Google toolbar is just one example, but i seen this for several other files as well and it seem like it's always very small executable files where this problem occur. It's strange that it takes 9 seonds to scan a 1.8mb file and would make more sense if this problem occurred with large files. During the scan of those files where this problem occur the CPU goes pretty high as well.

    For the record i use Windows Vista Enterprise SP1 (x64) and Nod32 4.0.417. I have AH enabled for "newly created and modified files" and "web access protection" only. So i have NOT enabled AH on file execution or for the realtime scanner. I tried nod32 on a computer running Vista Home Premium SP1 (x86) as well with the same problem so this is obviously not a 64bit problem.

    Is this normal behavior or is there some problems with the Advanced Heuristics?

    Currently i disabled AH for "newly created and modifed files", but would really like to enable this feature again so would appreciate a response and hopefully a solution.

    Gan
     
  2. danieln

    danieln Eset Staff

    Joined:
    Jan 7, 2009
    Posts:
    112
    The google toolbar installer is a compressed file and inside there are embedded files. Some of the embedded files have embedded files as well.
    The AH decompress the executable, looks at the files inside and performs various analysis. It is the expected function. The scanning time depends on the nature of the scanned files.
     
  3. GAN

    GAN Registered Member

    Joined:
    Mar 3, 2007
    Posts:
    355
    Thanks for the reply, but this does not really explain why it takes that long to scan this and several other similar files. Google toolbar installer is just one example, but seen the same thing for several other files as well as i said. When the google toolbar is scanned there are 2 files scanned so it's obvious some files are extracted. I still think 9 seconds compared to less then 1 second is way to slow. Remember that we are talking about very small files here. Just to compare if i scan another 10mb zip file with 47 files inside it takes just above 2 seconds to scan with AH enabled. Scanning a 1.8mb file where 1-2 files have to be extracted should not take 9 seconds. I have a license for 3 different AV software and the others scan this file much faster and also have heuristics and just as good detection rate according to several tests. Enable AH and the scan takes more then 10 times longer i find very strange. I reported a similar issue in the past with a very small dll and Eset fixed that problem.

    The answer could be something like your answer or Eset could takt a look at this and make it faster. I'm sure Eset could be just as good as many other AV solutions and make it much faster. A bit slower could be accepted, but this is way to slow i think and since this seems to be unique for nod32 i would say it's a problem that could be fixed. I'm not saying i tried every AV software available, but tried several and so far only nod32 use that long to scan this file. Move files from one folder to another with 10 such files and the time it takes to move the folder would increase significantly with AH enabled. There been several other reports where users talk about high CPU usage, slowness and other issues and it might be related. Instead of saying it's due to the nature of the file i think this could be worth taking a look at.

    Gan
     
  4. danieln

    danieln Eset Staff

    Joined:
    Jan 7, 2009
    Posts:
    112
    But did you read what I wrote? How did you discover there are only 2 files inside? Did you unpacked the executable? Maybe you will want to edit your post when you will discover the true number. Yes, the file is small but the files are many.
     
  5. GAN

    GAN Registered Member

    Joined:
    Mar 3, 2007
    Posts:
    355
    I read your post and i did not say the installation package contains only two files. What i said is that nod32 is able scan two objects which means nod32 is not able to extract all of the files. If the installation package contains 100 files is irrelevant if nod32 is not able to extract and scan all of them. Maybe you should read what i wrote once more.

    But i have no interest discussing with you how many files the installar contains which is not really relevant here. If you read what i wrote the time it takes to scan this file is way longer then many other av software i tested and too long to be normal. To decompress a few files to scan should not be that slow. You can scan a 10mb zip file that contains 200 files faster then this. I'm really looking for some help here and not start a pointless discussion about how many files the installation package contains because i don't believe that is the problem here.

    Also for the record this happen only when AH is enabled and it's the exact same number of files scanned when AH is enabled or disabled. So this delay is not related to the number of files at all, but the time it take to scan.
     
    Last edited: Apr 20, 2009
  6. danieln

    danieln Eset Staff

    Joined:
    Jan 7, 2009
    Posts:
    112
    NOD32 is able to extract the files inside when the AH is enabled. Please do not make false statements.
     
  7. GAN

    GAN Registered Member

    Joined:
    Mar 3, 2007
    Posts:
    355
    No AH does not extract any more files compared to when AH is disabled. As reported by nod32 in both cases there are two files scanned.
    I assume you tried with the same file (google toolbar 6 installer) and where did you see that nod32 scanned more then 2 objects? Are you telling me that nod32 scan more files then nod32 will report as scanned? And you know this for sure because? That would mean nod32 contains a bug.

    As far as i know AH will not extract more files, but will use another algorithm in additon when scanning the files that will increase the detection rate. Of course it's slower, but should not be that much slower. When someone from Eset confirm this i'm sure you will withdraw you statement that i post false statements? Instead of telling that i post false statements maybe you should explain how you figured out that nod32 scan more then two objects when the log says two objectes scanned? I'm not convinced that i'm the one posting false information here.

    Would be nice with a statement from Eset about the real reason for this thread and end this silly discussion right now.
     
    Last edited: Apr 20, 2009
  8. danieln

    danieln Eset Staff

    Joined:
    Jan 7, 2009
    Posts:
    112
    I can answer the details later if you will not loose the interest to know them. However now I am interested to know the other examples of the AH LONGSCAN problem.
     
  9. GAN

    GAN Registered Member

    Joined:
    Mar 3, 2007
    Posts:
    355
    I'm not sure what other example you talk about, but it's simple so if you pay attention it should be easy to understand since i already explained everything. When i scan this file with AH disabled it's very fast. With AH enabled it takes about 9 seconds. Nod32 report that ONLY two objects are scanned which is all that i been saying. An example of a file is the google toolbar installer. You claim this is false information and i have no idea how you know better then me what i see on my computer. I don't need to explain anything for you and believe i explained a lot more then you have so far. You just claim to know a lot, but so far proven nothing. Neither do you answer any of my questions and just trying to make this as hard as possible by asking another useless question. If you want some other example files i cannot see why i should bother to provide any since you are obviously not interested in helping or maybe unable to help. When someone that actually want to/can help reply like someone from Eset i will be more then willing providing more examples.

    And you are right about one thing i have no interest in your explaination and seems like you don't have any either. I want some help to solve a problem and you just being a cantankerous person that is trying to ruin my thread with nonsense. Your explanation why it take long to scan is basically nonesense. That's like saying nod32 have a very slow scanner compared to the competitors and there is nothing that can be done about it.

    Unless you have some useful information to solve my problem i suggest you create your own thread with nonesense. Why are doing this? Someone ask for help and you just being a cantankerous person with no useful info whatsoever to solve this problem. I believe your explanation about the long time it take to scan a small file is nonesense and you obviously found that insulting.
     
    Last edited: Apr 20, 2009
  10. MACHINE

    MACHINE Registered Member

    Joined:
    Apr 4, 2009
    Posts:
    12
    GAN is totaly right, I had worse problems on v3 and v4 with files and with start submenus on TOP machines, there is BIG problem in basic code for the AH option. NOD32 v2 didn't have this problem with AdvHeur. They must solve it rapidly because I seen the same problems at mine friends
     
  11. danieln

    danieln Eset Staff

    Joined:
    Jan 7, 2009
    Posts:
    112
    You asked for the explanation and solution.
    You received the explanation. I know my answers did not satisfy you but you asked.
    You received the solution. You may verify, if the scanning time in the latest update is acceptable.

    I see you confuse the number of the scanned objects with the number of the scanned files.
    You scanned one physical file and the AV reported 2 objects (the compressed exe and the decompressed exe with the name of the runtime packer). When scanning with the AH, the engine finds a data of the embedded files and embedded files inside those embedded files. Those hidden files inside the second object are not displayed as the separate objects (their names are not known).
    Just trust me that in this case really everything inside was scanned.

    Really want to know other examples of the problematic files and do not wish to continue to argue.
     
  12. GAN

    GAN Registered Member

    Joined:
    Mar 3, 2007
    Posts:
    355
    Now i'm a bit confused. Yes i can confirm that the scanning of google toolbar installer is much faster after the last update. And it seems like i got a solution now, but that was not the case when i posted my previous post. Does it mean that Eset did something to fix this, excluded something when scanning this file and is it a fix for this file only or a general fix that might solve the same issue for other files as well? Also you make it sound like you had something to do with this fix so just curious....is that correct and do you actually work for Eset even if that is not shown in this forum?
    Maybe you are right that more files are scanned when AH enabled in cases like this even if i find that a bit confusing. That means with AH disabled some part are not scanned with such archives?

    But if you actually want to help and have the resources to do so i'm thankful. So if i understand this correctly if i provde you with more examples you will make sure the problem will be fixed if confirmed a problem by Eset?

    I tried another file with the same problem, but the problem does not exist anymore for that file either so just wonder if there been a update that might fix this problem in general and not only this single file.. I will try to find some of the other files as well. I have seen this many times with small files, but cannot remember all of the cases so might not still have all the files or remember which one of them that caused this problem.

    Gan
     
  13. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,375
    Yes, we've made an exception and this particular file was whitelisted to make downloads faster.
     
  14. GAN

    GAN Registered Member

    Joined:
    Mar 3, 2007
    Posts:
    355
    Thank you for your reply and for the quick fix (whoever it responsible for this to be fixed).

    Gan
     
Thread Status:
Not open for further replies.