Malware Defender 2.4.4 beta

Problem solved Back on topic now.

 

I may be going OT, but what do you MD users do when you have new Windows Updates ready to be installed ?

I find it extremely hard for not heaving some clever installation mode like SSM had. It's a never ending clickfest.

It's a shame I will uninstall it, and get over to Comodo Firewall & Defense+ since it's so much more cleverly adjusting to the user's input of flagging something as Trusted, and having a temporary install mode, with MD it keeps on popping up ad infinitum, which leads to the well known "Oh well, lets start clicking allow on every popup" .... In the end, you silently end up giving EVERY dangerous process (eg. svchost.exe etc...) more and more freedom, and ultimately you start to wonder if there's something left that you don't want to allow....

In the meantime, I actually forgot if the license I have is a 1-year or a lifetime one, if it's the latter, I hope to some day get back with MD.

 

never updates widows so no problem here about that

 

Both MalwareDefender and Defense+ have a learning/training mode.
In the default D+ policy set, wuauclt and wupdmgr are members of 'installers' group.
(In case user forgets to switch modes? So that updates can silently occur in the background, without popups, while still in normal mode?)
-=-
For MD, operating in training mode should yield a popup-free WinUpdates session; because MD doesn't perform hash-checking, I would just temporarily disable its protection, though (and perform two post-update restarts before re-enabling it).

since *nothing*
The two apps coexist peacefully (for me, under WinXP Pro SP3).
tip: D+ severely bogs my sandboxied browser operations. MD does not.

Both MalwareDefender and Defense+ enable you to adjust their settings so that they are as visible (intrusive) or transparent as you wish... and both create reasonably granular (vs too permissive) rulesets if you initially (across several restarts, and open/close your various frequently-used apps) operate them in learning mode.

Be careful when using D+ (think carefully before clicking Allow/NoRule)
Unlike MD, the non-permanent D+ allow isn't ALLOW ONCE; it's analagous to the MD option to "create a temp rule which will be automatically deleted when the process exits".

 

I used SSM for several years, beginning shortly after Max Burmistrov made it available for slooooow download in 2002. I was an early registrant when SSM went commercial in 2006.

I still have several old SSM tutorials in my archives. Here is an extract from one of them as pertains to install mode...

During the time that SSM was in install mode, it provided basically "zero protection" from any anomalies of the program being installed.

In other words, in order to suspend pop-ups during install, SSM suspended protection.

You can accomplish more or less the same thing with MD by putting it into learning mode during an installation.

BL: a substantial part of the protection offered by a HIPS is engendered by its pop-up *alerts* whenever it detects suspicious &/or intrusive behavior. Reducing or turning off alerts must, of necessity, reduce the HIPS protective effectiveness. AFAIK the only way A HIPS' protective effectiveness can be maintained, while (at the same time) reducing alert frequencies, is by use of emulators, virtualizers or sandboxes.

(Herbalist -- where are you when we need you?)

 

it makes sense

 

I hope everything is well with him, have not seen him on Wilders for long time.

 

I confess I didn't have a MD license until today, have always be restoring OS images due to software testing and what not. But now today I thought I had better get a license and have done.

 

I believe he left quite awhile ago.

 

Or, you can check posts #32 & #33 in this thread and use a similar approach, where you will get far fewer pop-ups but MD will still guard and alert against common (this is the idea, anyway) malware entry points. I've tested it thoroughly in a vm and it works. All you need to do is enable the "Install mode" rule before launching the unknown app, then disable it when done.

I'm not trying to boast, only trying to illustrate it's possible to configure MD to work for you, rather than against you when installing unknwon apps.

 

MD currently has 3 "modes": normal, learning, and silent.
-=-
After connecting the dots, I see that you are referring to your post #32 "custom Program Install Mode application rule"
and I agree this is preferable to switching to "Learning Mode" during an install.
After the install, I wouldn't bother moving the installer's rule though; instead, I would just delete the rule.

Ah, different ways to skin the same cat.
I don't understand the merit in creating another 'custom' rule to handle installers. By editing the "Installers and Updaters group" rule (once) to suit your permission(s) preference regarding installer apps, handling each new installer only requires:

Create an application rule (pointing to the path of yet-unknown app),
then right-click the newly created rule and "Move to Group" -} "Installers and updaters" group

Do the Feb 2009 posts still accurately reflect your ruleset strategy, wat0114?
If not, what significant changes have you made to your ruleset since then?

According to your screenshot annotations, "Internet Access Applications" and "Microsoft Applications" were custom groups you added.
What magic did you use?
I've been under the impression that custom groups cannot / will not display in the "Rules" treeview.

 

It was experimental, basically to give a bit more protection against unknown, or as yet to be proven installers. The idea was to allow once, rather than create permanent rules that had to be deleted later. At the time, I was testing some malware samples just for interest sake. If you also look at post 33 you will see I've even got alerts for network access attempts - something a lot of malware will attempt during installs, as well as even some "safe" installers I have not used MD for a few months, so I can't really say my startegy would be the same or different now, only that because it was experimental, it's certainly open for modification.

No magic. The customized groups don't show up until you add a rule to them after you create them. It's one of the few "quirky" things about MD

 

custom groups

I have even tried uninstalling/reinstalling MD but the "custom groups" do not show in the treeview.

Rule -} "Application Groups..."
click [New Group]
I've added a group, but the only way to add an application into the group is via the [New Object] button. Even after I do add an application object in this manner, the custom group does not display in the treeview. Additionally, when I right-click an existing application rule -} Move To Group... the flyout does not list any custom group as a possible destination.

FWIW, I get the identical no-show behavior after creating (and populating it with at least one object) file / reg / network group.

 

Try: Right-click-> New rule-> File rule...then check out the screenshot for further procedure. The Group you created earlier should show up in the tree view after this method. BTW, i'm just taking a quick look at this latest version in the vm (VBox)

 

wat0114, Thanks !!!!

 

usability issue:

MSIE 8
google.com homepage
typing into AJAX search-as-you-type text field causes MD to alert "low level keyboard access".
Perhaps correct behavior for MD, but the user faces a problematic choice:
deny (permanent rule) and forever forego search-as-you-type convenience
or
permit (permanent rule) and forever worry, knowing the barn door is open

(or temporarily suspend MD protection, or visit the permissions tab for the application rule & change... but I'm disregarding these as non-desirable options)

In the MD popup, the option to create a temporary rule is grayed-out.

 

What it basically comes down to is you trust IE8 or you don't.

 

I've dropped MD for Windows 7 64bit.

Yes, I feel free from the burden, as I know from so many years of not getting any malware, how light personal computer actually is!!

Don't get me wrong, I love the control, but I also like not having to answer to my always legitimate system.

I still use virtual machines for testing though. Was VB, now Windows XP Mode

Never been so good.

 

I've done the same tony, also using Win 7 x64. Even ditched the software fw in favor of the built-in two way in Window, with my own ruleset. The lifted burden and increased speed is astonishing

 

Basically... whether or not you or I trust IE8 is irrelevant.

Ah, that explains it...

 

I run IE8 in sandboxie and let sandboxie do 99 percent of containment and Isolation, so much easier this way. for me MD is a back up and for system wide protection.

 

Exactly the same here.

 

FWIW, I seldom use internet explorer. I discovered the reported issue after one of my apps launched IE (apparently with disregard for "default browser" setting).

Before reporting the "issue", I did test a sandboxed instance. Same result.

You are reporting that you tested and were not able to reproduce what I described?

 

I'm glad.

 

xiaolin, perhaps you have discussed a Malware Defender feature roadmap on non-English-language forums, but the description offered on your English-language site truly is leading people to believe MD is something other than a policy-based HIPS application.

Malware Defender has been mentioned, described as an "anti-rootkit", here:
"Actual 2009 Antirootkits" thread
http://forum.sysinternals.com/forum_posts.asp?TID=20007

and has been subjected to testing alongside 50 other "anti-rookits" here:

Hidden Dynamic-Link Library Detection Test
http://www.ntinternals.org/dll_detection_test.php

and here:

Hidden Process Detection Test
http://www.ntinternals.org/process_detection_test.php

with the test author reporting that Malware Defender, as an anti-rootkit, "couldn't (even) detect process hidden by oldest process hiding methods including PspCidTable manipulation".