NOD32 2.5 BETA FP During SpySweeper 4.0 Beta Install

Oh okay

 

Problem is, these issues were identified a while back. Better to ensure the release had no compatibility issues or FPs, then drop. Putting the cart in front of the horse generally doesn't work.

 

Still there with 1.098 defs.

 

The update 1.098 was urgent because of new worms. Please be patient as the fp is going to be fixed shortly.

 

actully...
I execluded spysweeper folder...

then I thought i had a virus on the computer, so i checked with the task manager and "WRSSSDK.exe" taking alot of CPU and messing with the desktop, and i think its no wonder NOD32 detected it as "FP"...

I wont runt 4.0 from Webroot anymore...until webroot tells what that file do.. that file is really messing up my computer...

What does that file do, anyone knows ?

 

AFAIK, WRSSSDK.exe is there to make SpySweeper run better and gives support for limited user accounts.
If you have problems, check to see if your HOSTS file is ok. There is a known problem with large hosts-file and SpySweeper 4.

 

Signature update 1.1099 has fixed the FP on WRSSSDK.exe for me!

 

Same here...

 

Here too, of course.

Thanks, guys!

btw: this is no longer a beta....

 

i try to install new spysweeper 349...but nod keeps getting in the way...the problem is back....i shut down nod but still can't install...

 

Yep, signatures 1.1112 have reintroduced the SpySweeper false positive. To be honest, I'm getting tired of this...

 

Yup... Marcos time to tweak heuristics rather than just patching via signatures. This is getting very tiring and Eset's response time of FPs leaves something to be desired.

11 days since your last post Marcos.


Can't change the thread title Edwin and I'm pretty sure we're all aware that the product has been officially released. Each subsequent SS release is causing a FP.

 

I didn't have this issue till tonight but after downloading newest SS and (trying) to install:

 

Disable AMON
Execute the exe file
AMON-Setup-exclude webroot folder
Enable AMON

 

Yep, thats how to EXCLUDE the folder. But I really like to see the FP's solved. I don't want to exclude folders.

 

Ditto.

Also, tried running the OD scanner? Disabling AMON doesn't help there.

 

What is odd about this scenario is that since using SpySweeper myself, I received the 4.0 early (I am a beta tester and provided feedback). It installed without being detected. After downloading it from the "Official" release page it is picked up as a NewHeur_PE.

I have 4.0.1 (Build 331) Definitions 492, no exclusions and runs fine.

What is the version of the file having the issue?

My WRSSSDK.EXE is 1.0.1.189.

 

Fix a FP isn't an easy things as add a signature for a common malware. Moreover this FP was caused by AH. Eset need to check its AH and fix the problem but without affect the AH's detection. So, it's not a easy work to do in 48 hours. I understand Eset.

 

Cool Daddy is working for this, calm down

 

OK, time for some coffee then...

 

The issue is that it was initially reported three weeks ago. Instead of tweaking the heuristics, they addressed via signatures. There was no update to the AH module. So each subsequent release of SS resulted in the FP.

 

Please remember that adjusting advanced heuristics to minimize a possibility of reporting a false positive for SpySweeper might result in that future versions of some worms would not be detected heuristically. Nothing is as easy as it might look on the first sight.

 

We could wait.