High CPU usage - certain executable files - packer issue?

Unusually high CPU usage - certain executable files - packer issue?

Hi all,

I'm just setting up a fresh install of Vista SP2 32 bit (integrated servicepack, so it's fresh as can be as such). The system has literally nothing on it, apart from RealVNC remote.

I have EAV 4.2.40 installed, up to date definitions, and pretty much a default installation (haven't touched any settings). When copying over a bunch of files totalling 70MB from one partition to the other (same physical HDD) I noticed CPU usage literally went to 100% (Pentium Dual-Core).

I narrowed it down to these two files which can be obtained with ease:

SetupImgBurn_2.5.1.0.exe (http://www.imgburn.com/index.php?act=download)
vnc-E4_5_3-x86_x64_win32.exe (gah. sorry about the link. bloody realvnc's website doesn't like direct linking... click "proceed to downloads" without entering any details on the following page: http://realvnc.com/cgi-bin/download.cgi?product=enterprise4

and look for...

These two files seem to send the system into an absolute crawl. If i right click and context menu scan them, it takes around 40 seconds for imgburn, 20 or so for VNC. Most other files are instant or 2-3 seconds.

I tried downgrading to 4.0.474 and still seem to have the same issue. Not a big one as it's not all files, but any idea why this is the case? I found a similar thread and I think it is to do with the compression/packer used?


Thanks

 

it could well be an issue with packer used, now that you provided a link hopefully it will be investigated and fixed if required. In the meantime exclude them from scanning

 

I just checked out SetupImgBurn_2.5.1.0.exe and can confirm the same 'crawl' on my pc. The Setup program is a SFX and inside the archive several of the files are UPX packed. I guess that goes somewhat towards explaining the slower unpacking and scanning, but given the small number of files contained in the SFX, I'd expect EAV to be quicker and less CPU intensive.

 

Thanks Cudni and thanks stackz for checking.

 

+1 on ImgBurn... weird issue.

 

Does anyone else have the same issue with this Google updater program?

http://pack.google.com/installer_eula.html?ci_picasa=on&hl=en

 

Gimme a standalone link to download the updater executable. I refuse to install anything plagued by Google Updater, sorry.

 

Fixed my post, the link to RealVNC was asking for details which isn't actually necessary; just click proceed without any input.

Yup. Exact same issue. Right-click scan took 11 seconds though, not as bad.

I tried it out, & if you just click accept, all it does is begin to download Google Updater.exe (~1MB). Don't need to actually run/install anything Google.

As above, this file exhibits the same (though not as bad) symptoms. Thanks henktiggelaar.

 

I had this problem with nod32 for ages and even reported this problem in this forum in the past. Also read from other threads with other users that seems to have the same problem. Seems like this is common with nod32 for files using packers and some installation files. It could happen with very small files as well so not related to the size of the file. I just think you have to accept this for some files when using nod32 unless you want to compromise the security and turn off some features of nod32 that seems to help in some cases. It's not the first time someone discussed this problem with nod32 and still an open issue.

gan

 

You get a double-dose of the high cpu hit when you extract any packed install file from an archive to any destination.

ie. the archive app. (eg. winzip, winrar) uncompresses the file to a temp location -- ekrn scans this file based on 'file create' policy.
Then the archive app. moves the file to the nominated destination -- ekrn scans the file AGAIN based on 'file create' policy

So if the uncompressed file contains a threat packed inside, you also get a double dose of warnings from NOD32.

In these cases I smell the rat and am aware that the file in question contains a threat. I choose ignore/take no action. Then attempt to unpack the sus file using 'Universal Extractor' (or similar) to reveal the threat within.
It's more often than not the packed installer has been encapsulated by a fake setup_install.exe with the threat packed inside executed BEFORE the real setup_install.exe inside does.
So - you simply have to discard the original install_setup.exe and keep the genuine install_setup.exe that was wrapped up inside!!

Bingo

 

Windows 7 Pro x64

I think this issue might be related to Windows Indexing. I have a folder with some files in it and when I open this folder and highlight a file EKRN.exe takes 50% or more cpu usage until Windows Indexing is done. I can remove indexing from this folder and EKRN.exe is ok. These are the steps that I take to make this happen. To remove indexing for a folder right click on folder then left click properties. Click Advanced and then uncheck "Allow files in this folder to have contents indexed in addition to file properties." Then click ok and then Apply. You will then get the option to apply changes to folder or folder, sub folder and files. I choose folder only. I can open some other random folder then go back to the directory I removed Indexing from and I do not get this issue. I can make the issue return by applying indexing on this folder again.