MRG Rogue Software Test

So even though KIS hips rates how dangerous applications are, it still wouldn't score any higher?

 

Yes, you are right. In default configuration, Defense+ is bypassed. I think Proactive configuration turns on "Image Execution Control", which prevents the bypass.

 

with all due respect, who even cares, anymore. You can read whatever test site you want, you have the right to trust whatever or whomever you wish, but, the reality is, if you are here, then you should have a good idea of what is right, and what is wrong.

 

The conclusion to this must be that the testers had it set at default, which also brings the point that a lot of users who aren't as knowledgeable as some here in these forums will also have the program running at default. Food for thought eh.

 

Indeed. I don't know why Comodo don't simply default their configuration on installation to "Proactive Security". They are recommending to set CIS to this configuration all over their forum.

Anyway, it's pretty rare for a classical HIPS to be able to block everything in "default configuration" or "out of the box" - you often need to make some tweak to it. However, I know that Comodo are actively trying to make their default configuration as secure as possible, while balancing usability/convenience. Apparently CIS version 4 might be a significant break-through with regards to this. Who knows haha.

 

The test may or may not be flawed but we cannot occult the fact that AVs in general have a poor detection of rogue as both Heuristics and Behavior Blocking are ineffective in this case. No one can deny that many average users using reputable AVs have been plagued by AV2009. Therefore it is up to AV companies to innovate so that they improve their products and offer the same level of protection which they claim they provide in their advertisements.

Thanks

 

Can you please explain to us EXACTLY what kind of bug could possibly have caused your program to think a signature which was untrusted was actually trusted? And what steps have you taken to ensure this NEVER happens again?

Imo it is completely unacceptable for a classical HIPS to be bypassed by a bug in the whitelist like this! How many other bugs are there in the OA whitelist which allow malware to completely bypass OA?

 

Yes, I think your concerns are very reasonable.

 

Aside from whether a reputable AV has the ability to detect such programs, I find it difficult to understand why a user that already has a reputable AV would need to go and download AV2009 knowing they've already got an AV. Unfortunately though, it happens.

 

Few average users would know about the problems associated with running multiple AVs together.Just seeing a 'scan' result that shows a heavily infected system is enough to lull many into the trap.

 

Has anyone tested this RegGenie with a2?

I get only one prompt about an upload request.



That's all. I can install and run the program without a2 interventions.
Either they have removed FP detections or...

Cheers

 

That's very interesting. PrevxHelp has already said that RegGenie is definitely rogue. Why would a2 have treated it as a false positive?

 

Probably why.

 

Yes, but if a2 was already detecting it as malware, why would they have to "correct" it? Are you saying PrevxHelp is wrong? Is a2 saying PrevxHelp is wrong?

 

I'm going to guess it was a heuristic detection, i.e. the heuristic signature wasn't designed to pick up that application but another application.

 

Please run an online update. Instead of the upload request you should see a blocking alert window now.

 

Stupidness cannot be fixed with security. Codewise the roque programs probably are not malicious so they cannot be detected by any heuristics, behaviour etc. They can only be detected by signatures and this is what everyone knows, ineffective. I wouldn't blame the AV if it misses some of these programs. Adding some heuristic detections for these would probably result in huge amounts of false positives since normal programs can have the same characteristics. Generic detections might be possible if there is something similar in different versions of the same rogue family.

 

Then when they sell their products, they must specify that they are not 100% effective.
https://www.wilderssecurity.com/showthread.php?t=244213&highlight=blow

They should indicate that they cannot protect against rogue and they should not accept money from these "stupid" people if their product will not be protecting them.

Some say that they do well in AV Comparatives and have won many VB100 so that users are lured and buy their products. Now they must do what they are supposed to do, that is, protecting users irrespective of the threat.

 

They can protect against rogues and they will, but I believe there are simple technological limitations explaining why it is not effective.

 

selling products as 100% effective is just advertsing/marketing and taking it at face value isn't a smart practice ....

with an ever evolving threat quotient where av cos are playing catch-up with malware writers this expectation is like setting on a a wild goose chase

or vice-versa Security cannot be fixed with Stupidness

 

I think quite a few vendors are adding detection for rogue software, but at a much slower rate than for actual malware. Sometimes a push is all it takes, but the AV vendors still have to prioritise.

Elapsed said:

We can turn that around and say "look at what AVIRA detected". They detected 46 rogues out of the 59 listed (I thought it was supposed to be 60, but can only count 59), and I don't consider them to be true malware either. The point is AVIRA did add those detections, and will continue to do so when appropriate. This is probably the same for other vendors, like KL as shown in their VirusWatch list for "not.a.virus:FraudTool" detections.

Someone said a few years ago very few AVs were detecting adware/spyware, but these days most do. The same is happening with rogue detection, but it is, as we have seen, a bit more complex.

 

The detection arrives somewhat late.

However, now the queer RegGenie story of a fake test group comes to an end.

Journal entries
August 10 - a2 doesn't detect anything when I install RegGenie, test failed (I had to restore an image to verify this).
August 16 - a2 successfully blocked RegGenie according to MRG fake tests.
August 21 - a2 doesn't detect anything when I install RegGenie, test failed.
August 22 - a2 detects RegGenie as Fraudtool.Win32.RegTool!IK because of today's signature updates.

Very dubious, for me it looks like MRG fakes their test results to push some products.

Cheers

 

Good work subset!

EDIT: So you attempted running reggenie before MRG conducted their test? Why? Just coincidence? You actually use the program? Is it really a rogue?

 

It's described here

Those are some interesting findings

 

Oh yea, good point, forgot about that! Still though what was subset doing testing A2 against reggenie before the MRG test? Coincidence?