Scanning memory takes longer after Comodo install

Discussion in 'NOD32 version 2 Forum' started by Ocky, Jan 27, 2007.

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

    Ocky Registered Member

    Joined:
    May 6, 2006
    Posts:
    2,677
    Location:
    George, S.Africa
    NOD32 'Scanning Memory' process takes much longer after installation of Comodo firewall.
    For instance scanning a file from the context menu takes nearly 9 seconds,
    8 seconds of which are attributable to the initial 'Scanning Memory' process.
    Not a train smash as the rest of the scan is as fast as always.
    When exiting Comodo, scanning memory takes 1 second or so as in the past.

    Can anyone confirm this ?

    o_O
     
  2. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Perhaps the Comodo executable is runtime packed and it takes time to emulate the code?
     
  3. pemar

    pemar Registered Member

    Joined:
    Oct 4, 2006
    Posts:
    31
    Location:
    Winnipeg, Canada

    I have Zone Alarm Pro installed - "scanning memory" sequence takes about 15 seconds in my case. File itself I couldn't measure - it was very fast - it was bookmarks file 25 Kb - NOD reported scanning in 0 sec. I have tried it on executable (siw.exe - system information for windows), 1.3 MB in size - it took again 13 seconds for memory scanning + 24 seconds for the file.

    Exiting Zone Alarm does not change time of scanning.
     
    Last edited: Jan 27, 2007
  4. sir_carew

    sir_carew Registered Member

    Joined:
    Sep 2, 2003
    Posts:
    884
    Location:
    Santiago, Chile
    Yes, Marcos is correct. I'm using COMODO Firewall Pro and I noted it's runtime packed with a version of PECompact. The only file is runtime packed is cpf.exe, the main executable of COMODO.
    Try to scan cpf.exe with NOD32 Scanner and AH enabled and you'll see it take some time to emulate it.



     
  5. kailasa108

    kailasa108 Registered Member

    Joined:
    Jan 26, 2007
    Posts:
    10
    Location:
    Honolulu
    Duh, what does "runtime packed" mean? :blink: And what is the "norm" that this is different from, that causes a problem? Thanks!
     
  6. sir_carew

    sir_carew Registered Member

    Joined:
    Sep 2, 2003
    Posts:
    884
    Location:
    Santiago, Chile
    Runtime packers in simply words are utilities to pack files to reduce the size of the file or in malicious codes to avoid antivirus detections.
    The problem and difference between runtime packed files and compressed files (i.e RAR or ZIP) is that runtime packed files are unpacked directly to the RAM and compressed files are decompressed to the hard disk.

    You can exclude cpf.exe from AMON to avoid the time of start.

     
  7. Ocky

    Ocky Registered Member

    Joined:
    May 6, 2006
    Posts:
    2,677
    Location:
    George, S.Africa
    I was also in the dark, so many thanks for your explanation
    sir carew !
    I assume decompressing each of the packed files within the
    executable is what causes the delay in memory scanning.
    Does NOD32 use any "special" algorithm to deal with these
    type of compressed executables ?
     
  8. sir_carew

    sir_carew Registered Member

    Joined:
    Sep 2, 2003
    Posts:
    884
    Location:
    Santiago, Chile
    Yours welcome :)
    NOD32 use Advanced Heuristic and signatures to detect packers. For example, most common packers like UPX are added to signatures in order to unpack this quickly. Consider that many legit apps. and malware use UPX. In the other hand, AH is able to unpack many files even if the unpack routine isn't in the database. To do so, NOD32 need to use the CPU and thats why there're some timeout with packed files.
    It's a good technology, because many malware authors modify packers to avoid detections and AH is able to unpack them.
    Maybe an Eset moderator can explain this a little better with a better English too. But that's the basic.
     
Thread Status:
Not open for further replies.