Scanning memory takes longer after Comodo install

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 ?

 

Perhaps the Comodo executable is runtime packed and it takes time to emulate the code?

 

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.

 

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.

 

Duh, what does "runtime packed" mean? And what is the "norm" that this is different from, that causes a problem? Thanks!

 

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.

 

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 ?

 

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.