Malware Defender 2.4.4 beta

Discussion in 'other anti-malware software' started by xiaolin, Nov 15, 2009.

Thread Status:
Not open for further replies.
  1. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    Last edited: Nov 15, 2009
  2. tony62

    tony62 Registered Member

    Joined:
    Aug 26, 2005
    Posts:
    214
    Location:
    UK
    Hi xiaolin,

    Is this for NTFS Permissions or built in MD File & Registry protection?

    Also, I believe that the comment column of the rules window should contain a brief note on what each rule actually does.

    Thanks for all your hard work.
     
  3. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    It's NTFS permissions for files and folders, and registry security permissions for registry keys.

    Thanks,
    xiaolin
     
  4. 0strodamus

    0strodamus Registered Member

    Joined:
    Aug 23, 2009
    Posts:
    1,047
    Location:
    United Surveillance States
    The beta is running well here! :)
     
  5. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    Malware Defender 2.4.4 beta3 is released

    The beta version is available for download at http://www.torchsoft.com/download/md_setup_2.4.4_b3.exe

    what's new since beta2?
    - Improved the ability to detect actions of loading DLLs. (changed the implementation from RING3 to RING0)


    NOTE: If you upgrade MD from old versions, it's recommended to restart system after upgrade.
     
  6. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Re: Malware Defender 2.4.4 beta3 is released

    :thumb: :thumb:
     
  7. _kronos_

    _kronos_ Registered Member

    Joined:
    Dec 8, 2008
    Posts:
    126
    Re: Malware Defender 2.4.4 beta3 is released

    Good job!
     
  8. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    occasional bug:

    sometimes when an MD popup appears, the [Deny] button is disabled (grayed-out)

    When this occurs, ticking the "Create permanent rule" box causes the [Deny] button to become enabled, and it remains enabled even if the "Create permanent rule" box is clicked again (to untick the selection).

    I'm saying the bug is the initial grayed-out status of [Deny].
     
  9. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    Does MD recognize/verify an executable file by hash, or simply by its path?

    If by path alone, that would seem like a "weak" protection mechanism.
     
  10. jmonge

    jmonge Registered Member

    Joined:
    Mar 20, 2008
    Posts:
    12,883
    Location:
    Canada
    it is by path:D
     
  11. DOSawaits

    DOSawaits Registered Member

    Joined:
    Dec 11, 2008
    Posts:
    416
    Location:
    Belgium
    I already asked Xiaolin to incorporate this (like System Safety Monitor does) but the response was that it will slow things down, calculation the hash for every process start. The weird thing is, SSM didn't slow anything down on my system while still giving this strong layer of protection against process modification.
     
  12. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    Within threads from back when people were begging to have MD include regkey protection, I read the same response ("that would slow things down").

    It's not a frivolous feature request. Authors of competing security apps understand that it's a meritworthy feature & they include hash-checking functionality.

    The installation default could leave the option unchecked & display a note stating that enabling the feature may impact system performance.
    If "enforce hash checking" were an option, I would choose to enable it.
     
  13. bellgamin

    bellgamin Very Frequent Poster

    Joined:
    Aug 1, 2002
    Posts:
    5,648
    Location:
    Hawaii
    How much hash are we seeking? CRC32? MD5? SHA-1? Or... what?

    I have heard that the stronger the hash (i.e., more complex algorithm), the greater the system impact and the greater the difficulty of mimicry/collision. And vice versa. Thus, CRC32, for instance, is relatively light in terms of system impact - or so I have heard - but it is weaker than, say, SHA-1.

    P.S. I have no idea what I am talking about. :blink:
     
  14. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    I expect CRC would be sufficient.

    There are so many different versions/builds of various components that it's a stretch to imagine malware carrying a payload of all known versions & custom-replacing the original with a same-sized file, but... on the fly, the unloaded dll (or ocx or exe) could be padded to match the filesize of the target file.

    For me, the hashing feature request isn't *just* with concern toward MALware. I've too often seen problems arise due to signed/trusted installers (Adobe) or even MS service packs silently overstepping their bounds in replacing shared components.
     
  15. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    usability pain point:
    While working in MD's main "Rules" tab, both the dialog window titled "Edit File Rule" and the dialog window titled "Edit Registry Rule" fail to remember the MRU (most recently used) location. User is forced to click/expand from root location each time.

    (The other dialogs -- "Edit Dynamic Link Library Rule", "Edit Child Application Rule", etc -- *do* consider MRU, so I hope the behavior of the odd cases is just an oversight.)
     
  16. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    simple NirSoft freeware utility called "InsideClipboard":
    http://www.nirsoft.net/utils/inside_clipboard.html

    MalwareDefender does not recognize this app's clipboard monitoring as a "hook". No hook listed in the MD Hooks tab, no ASK popup when the utility retrieves the clipboard metadata. Okay, if clipboard content (by design) can be retrieved by any app, and the action of this utility is just a "paste" operation (no hook required)...

    ...how to accomplish a "restricted application group" rule which denies access to the clipboard content?

    I searched to find "what COM object" should I restrict access to, but read:
    http://www.apriorit.com/case-studies/clipboard-protection.html
    that clipboard content can be retrieved by various methods, including by kernel mode low-level functions.

    At this point, I'm at a loss. I can't envision how to effect such protection via MD.

    Perhaps the developer intends to limit MD's scope, concentrating on offering anti-hook and anti-rookit protection... and we need to look to other supplementary security apps to achieve "leak protection"?
     
  17. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    bug, or at least undesirable behavior:

    While trying to determine whether the absence of a popup warning of the actions by InsideClipboard is a product of my current ruleset (vs the MD default ruleset) I exported my current ruleset, then restored the default ruleset.

    When I again imported "my_current_ruleset.dat", a dialog warned that "rules with the same name will be overwritten". Yeah, okay, whatever...

    ...execpt NOW 56 rules are present. Prior to the export/import, only 55 existed.
    Conclusion: I apparently disagreed with the presence of one of the default rules, so had deleted it... and now it's back again. Aaaargh, I'm gonna have to stay home from bingo tonight; I'll be stuck sitting here hunting for which rule to RE- delete.

    Also, when MD imported my "current" ruleset, the rule *status* for each of "Trusted Network Rules" was not respected.
    (previously disabled rules are once again status=enabled)

    Yes, I understand why those Microsoft/Verisign rules are present in the default set.
    No, the eternal presence of those rules is not welcome ON MY SYSTEM.
    Yes, I had previously deleted the Microsoft/Verisign rules, and...
    yes, I discovered that MD attempts to prevent user from "shooting himself in the foot" by recreating those rules at each startup if they are not present.
    I thought I had achieved a tolerable middle ground, by setting status=disabled for those rules. That way, MD didn't disturb/revert them at startup.

    Also, following the export / restore defaults / import operation, I now have conflicting rules for some previously-trusted applications (resided within "Trusted Applications" group at time of export) -- rules for identical apps are now present as "Application Rules" entries as well (not assigned to a group).

    What must I do to really REALLY return to my "current" ruleset?
    I'll try Booting to safe mode, delete ~MD\rules.dat, replace it with a renamed copy of my exported *.dat file.
    If that doesn't work, if I can't fully trust that a tediously handcrafted ruleset can be saved/restored... goodbye MD, hello bingo parlor.
     
  18. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    It's not enough to check the hash of .exe files. All executable files (.dll, .sys, .ocx, .cpl, .msc ...) can be infected.

    I will think about adding a feature to compare snapshot of important files. But it will not be implemented in near future.

    Thanks,
    xiaolin
     
  19. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    MD does not have the feature to protect against clipboard monitoring yet.
     
  20. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    It will merge rules when importing a rule file. You can try the rule files managing feature (Rule menu -> Manage rule files).
     
  21. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    Thank you. "Manage Rules --} Set as Active" achieves the desired result.

    I had fully read the helpfile, but it does not mention "Manage Rules".
    Perhaps import/export should be removed from the dropdown (these commands are available within the ManageRules dialog window). At a minimum, the helpfile should state "When performing import command, rules with same name will be overwritten. Consider using the 'Set As Active' command instead."
     
  22. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    406
    usability issue:

    When maintaining application rules (by double-clicking a line item to open the modal window titled "Edit Application Rule")
    many sub-operations are performed via a secondary window
    (e.g. [Child Applications] click "Add" raises a window titled "Edit Child Application Rule").

    The view is immediately updated as each add/edit/copy/paste/delete operation is performed...
    HOWEVER, any changes performed are not "committed" until user closes the secondary window
    and clicks the [OK] button of the "Edit Application Rule" window.
    -=-
    In other words:
    After closing the secondary window, UNLESS user clicks the [OK] button of the "Edit Application Rule" window, all sub-operation changes are discarded.


    desired behavior:
    When user performs ANY change in a secondary window, the app should alert the parent "Edit Application Rule" window (set a flag, mark 'dirty', whatever) so that a confirmation warning is later raised if user attempts to close the parent window without first clicking the [OK] button.
     
  23. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    Thanks for the suggestions. :)
     
  24. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    Malware Defender 2.4.4 final is released

    English version: http://www.torchsoft.com/download/md_setup.exe
    French version: http://www.torchsoft.com/download/md_setup_fra.exe
    German version: http://www.torchsoft.com/download/md_setup_deu.exe
    Italian version: http://www.torchsoft.com/download/md_setup_ita.exe
    Spanish version: http://www.torchsoft.com/download/md_setup_esn.exe
    Russian version: http://www.torchsoft.com/download/md_setup_rus.exe

    What's new?
    - Added protection against changing security permissions of files and registry keys.
    - Improved the ability to detect actions of loading DLLs.
    - Fixed bugs when parsing file paths.
    - Fixed a bug when importing rules.
    - Fixed a bug when removing stale rules.
    - Minor improvements and fixes.


    NOTE: If you upgrade MD from old versions, it's recommended to restart system after upgrade.

    Thanks,
    xiaolin
     
  25. 1boss1

    1boss1 Registered Member

    Joined:
    Jun 26, 2009
    Posts:
    401
    Location:
    Australia
    Thanks xiaolin keep up the great work! :)
     
Loading...
Thread Status:
Not open for further replies.