As with all solutions that have to prove themselves, we will keep a scrutinous eye on this one. Might be it gives this second layer of additional protection others do not have, and that is a valuable asset. You know however going on full heuristics does also mean you are meant to meet the next false positive. So there always should be a mix of detection methods involved. Also what I miss is user interaction when some issue has been detected. At least a hash look-up or an indication of the malware type and subtype, so the user might explore what it is all about what is being flagged. There is a might of difference between finding up some packer heuristics for riskware and a highly dangerous file infector of some sort. But as the protection range of this av might be limited to the typical malware for your peripherals like usb sticks, that go under the normal av detection radar, this will make the evaluation of what is being found even more difficult,
Unfortunately for me it turned my bootable USB into an unbootable USB.
I’ve removed it some time ago. I needed protection from the bad guys.
I didn’t expect the good guys to attack my bootable USB.
As you know, MCShield refused to work on my Vista notebook because of constant program’s crashes. Lately I tried MX One Antivirus but I had to remove it either. The real-time shield is working OK but again I get pop-ups: now they say the program’s antivirus engine was stopped.
I think this separate “2nd layer protection for USB drives” isn’t a protection at all. There must be only one antivirus and it is Avast for me. And I believe that we need only one thing - to realize that suggestion by Andrey,pro.
So I turned the program off and closed in exit. So try it only when I use peripherals, just to be sure there are no conflicts with my resident av solution, that is avast. The more like conflicts between programs are not much discussed about, but they exist. Strange changes to SpywareBlaster after users installed MBAM,
the sudden reapearance of the Skype toolbar after it had been disabled in IE. I agree with you a boot repair is too big an incident from a solution that is no longer beta, it should not happen,
Important thing to note is that MCShield’s heuristics are not what you’re used to see in an average antivirus. When I say heuristics, I do not talk about detections based on compilers, exe compressors, partial signatures, etc. like in the case of an AV, but I’m talking about recognizing “static behavior” (basically, what the files and the folders on a flash drive “look like”). So, the program tries to recognize malware by analyzing the file system; files and folders - their characteristics and relations to other files and folders on the drive. These analyses are based on algorithms designed to be “triggered” by a “behavior” (what they do on a flash drive in the process of infection) of different worm families using various methods to initiate the infection (autorun functionality, exploits or simply tricks to make the user to run malware).
When it comes to FPs, most are made in the part of the code that analyses autorun files and these are almost always “rename FPs” (meaning: the file is not known as a good one, so, to be on the safe side, it’s renamed).
Why is this routine making more FPs than all other (and there are 13 more)? Simply because it goes by the rule: autorun.inf and the related files are bad unless proven to be legit.
Is this the right approach? Well, there are millions of worms using autorun and there’s, let’s say, a few hundred legit programs that do the same.
This seems like a simple choice to me. I might be wrong, but I’ll rather take the blame for renaming a legit file than let a peace of malware slip through.
All other detection routines shouldn’t really be triggered by users files/folders. This can happen (people do “stuff” :)), but it’s not that common.
polonus mentioned that it’s not easy to test this kind of software; I agree.
I’m quite certain there are parts of the code in the scanner that have never been triggered on users’ computers in these 2.5 years.
Basically, what you guys have seen so far is just one small part of MCShield’s possibilities. AntiAutorun, AntiLNK, three AntiReplicator routines, AntiRimecud, two AntiMimics, known bad file/folder names, hashes, AntiEsfury (folder name heur.), general/blended file heuristics (files are checked in 6 ways)…
What I’m trying to say: to test MCS, one needs to take a large flash drive containing a bunch of files and folders (hundreds or thousands) and then connect the drive to PCs infected with various worm families. Simply put: the more malware you get in there, the bettter detection you’ll get. Why? MCS uses, in most of it’s routines, adaptive scanning. A lot of different malware shall trigger more detection code; different parts of this code overlap, meaning that on a heavilly infected drive, one same malicious file might be caught several times (so it won’t get undetected that easily).
A good example is the log argus posted. All malicious files on both drives are identical. On the first drive, malware was just renamed.
On the other drive, malware was detected by at least two detection routines and got deleted.
As I said, the more, the merrier. ;D
SpeedyPC asked: do I need this? Well, let’s put it this way: MCS is going to try to remove malware (files and folders), restore the attributes of your folders in case it suspects they are hidden by malware, and also try to recover (rename, unhide) your files (some worms also mess with users files, not just folders; they can be either renamed and hidden or simply deleted). If you know how malware works/infects and you have time to spare (I’ve seen logs with thousands of treated items - this could take a while to fix), all this can be done manually (assuming that you’re fully patched and everything that needs to be, is disabled).
If the question is: “I have an AV, does it need help?” - than: oh, yes, your AV needs help. Be it some powerful HIPS so you can do the cleanup manually (without getting infected), or some programs like the one I’m trying to “sell” you.
Compatibility? MCS can work alongside any AV. It doesn’t use any drivers or services and it does not protect itself - it is the AV that can cause trouble to MCS (block it while working), but even this won’t cause any real trouble.
Until now, I’ve got two usb sticks that triggered MCShield. Although both are false positives, they were really suspicious. One with a program manufacturer that try to backup things on my computer, and other executables (not setup files).
Pondus, nej, inte riktigt.
I’ve moved to Sweden a few years ago from Serbia.
Tech, if detections are still present, I would appreciate MD5s of those files so I can add them to whitelist (I’ve whitelisted a few files in the last couple of days, could be that they are already fixed).
