hake

I have a Lifetime MBAM Licence which never expires but have forgotten the associated email address. The licenced MBAM is registered but how can I identify the email address belonging to it?

I liked the UI with MBAM3 but the MBAM4 version is less intuitive. It would never have occurred to me either to look at the detection history card to find the exclusions. The selection of the various scan modes is also well hidden. Avast has a penchant for changing its GUI at frequent intervals with the the general effect of user mystification and gnashing of teeth. I have often thought that if Avast could develop a swear box, it would make a lot of money.

Thank you exile360. Exclusions duly created.

I am running Windows 10 Pro 64 bit and Avast Free 19.8.2393. I have now installed MBAM Premium 3.8.3 in addition. All Avast's four basic shields and all MBAM features are enabled. I had anticipated some performance hit by doing this but none is apparent. I am pondering over possible conflicts between MBAM and Avast but none seem to be present. What I am asking is whether or not there would be any impairment of the operational or security protection efficiency expected with either MBAM or Avast caused by using them in tandem. The processor is an Intel Core-I3 3220 3.3GHz and 8GB of RAM is installed.

I never expected to see this. Bottom-Up ASLR protection is clearly worth having in Windows XP. MBAE 1.12.1.109 is in active use. Mozilla Firefox 45.9 was running inside Sandboxie 3.76. The Firefox process was instantly terminated. interventions by MBAE are very rare on my Windows XP SP3 system or any other of my Windows systems for that matter. I am reassured that MBAE is prowling usefully in the backgound. Would it be fair to say that malware developers would not expect to encounter Bottom-up ASLR protection in this venerable operating system? I don't claim to have configured the most hardened XP system extant but the battlefield is littered with mines and booby traps. There are numerous layers of defence.

The MBAE Advanced Settings to Prevent loading of VBScript Library have been observed to be reinstated for Windows 10.

I have received an email requesting subscription payment for Malwarebytes Anti-Exploit Premium. I am told that it expires on 27 October 2019. The licence ID is 'beta version'. What happens if the subscription is unpaid? Does it stop working or does it enter a more limited mode of operation? I seem to remember that a few years ago I had a paid subsciption for MBAE Premium but then it became Beta so I let the subscription lapse. I guess that the reminder is due to a lapse in the subscription system administration.

For the sake of completeness here is the MBAE screen shot for Windows 7 64bit Ultimate.

Hi Pedro. Please find the screen shot of Application Hardening settings in MBAE 1.13.1.117 running under Windows 10 64bit Professional.

Advanced Settings for 'Prevent loading of VB Script Library' are disabled in Windows 10 but allowed in Windows 7.

Dagnamit! I got confused with editing my comment. Has this forum feature been updated? I don't remember having this problem previously.

To ensure that Windows 8, 8.1 and 10 have bottom-up ASLR enabled, see the following link: - Windows 8 and Later Fail to Properly Apply ASLR. Here's How to Fix.

It appears that to enable bottom-up ASLR for MBAE protected Google Chrome in Windows 7, it is necessary to install EMET. Version 5.52 specifically enables system-wide ASLR which automatically enables system-wide bottom-up ASLR. In other words EMET creates the settings which produce the system-wide ASLR effects. No applications need to be individually protected by EMET so I guess that MBAE protected applications are unaffected. Process Explorer shows no results in the search for handles for emet64.dll. There is no protest by MBAE. My references are: - 1. EMET 5.52 User Guide 2. Clarifying the behavior of mandatory ASLR - Microsoft Security Response Center

I have been blocked from https://noscript.net/ NoScript is a valuable protection aid for Firefox. I overrode the block.

Thanks exile360. All those extra protections are signs that Malwarebytes is keeping its light under a bushel. I guess that it must have been doing this for quite a while. It would seem reasonable for MBAE to protect svchost.exe and the like as such system features are constant known quantities which are profoundly impotant for the overall security of the various versions of Windows. Are such extra protections likely to be included in MBAE 1.12.1.109 or even MBAE 1.12.1.90?

@AndrewPP: EMET 5.52 is still useful with Windows 7. @Living_Computer: MBAE 1.13.1.98 won't let me.

I happily use MBAE 1.12.1.109 on Windows XP SP3 running on a pre SSE2 AMD Athlon XP 3000+ processor which lacks hardware DEP. I run MBAE alongside EMET 4.1u1 but the two anti-exploit systems do not protect the same applications. EMET protects svchost.exe as well as a number of applications not protected by MBAE I also run Comodo Firewall Firewall 2.0.4.20 which detects the following types of attack: Detection of Buffer Overflows which occur in the STACK memory, Detection of Buffer Overflows which occur in the HEAP memory, Detection of ret2libc attacks, Detection of corrupted/bad SEH Chains In addition, I use Avast Free 10.4.2233, OSArmor 1.4.3 and Agnitum Outpost Firewall Pro 9.3. I am confident that I am doing my due diligence to prevent my XP system from being a general security liability for others. This incarnation of Windows XP has been in use since May 2006 and has yet to experience any intrusion or malware activity. Comodo Memory Firewall can still be downloaded and is easy to install and manage. It is also useful on XP systems with hardware DEP. It was initially called Comodo Memory Guardian but some chump at Comodo had the bright idea to change the name and so confused many people. It has no firewall functionality.

I have read that MBAE wil now operate with Malwarebytes Free also installed. Is this correct?

Thank you exile360 for your trouble and interest. I have been trying to get my head round the uncertainty of the operation of ASLR with Windows 8, 8.1 and 10. I think that the issue is centred round the difficulty of forcing ASLR for unsupported (old) applications. There is no authoritative opinion on this subject and many comments on the web are dated around the end of 2017. The really strange thing is that Windows 7 is exempt from the issues. I use EMET 5.52 to enable bottom up ASLR for as many running processes in Windows 7 as I can without any adverse effects. Google Chrome 76 accepts injection of EMET 5.52's emet64.dll. I can thus assure myself of adequate ASLR entropy for Google Chrome in Windows 7.

Thanks Arthi. I have uninstalled Google Chrome from Windows 7. All the best to you.

Thank you AndrewPP. I have read that. I note that Windows 10 imposes a default of 'enabled' for Bottom-up ASLR. I guess that this permissible by the developers of Google Chrome and so I guess that no dll injection is entailed. Windows 7 apparently does not impose such a default of 'enabled' for Bottom-up ASLR and so I am hoping that MBAE would be able to do this, notwithstanding the Google Chrome ban on dll injections into Google Chrome.

Is MBAE still able to achieve enforcement of bottom-up ASLR for Google Chrome? In other words, does bottom-up ASLR enforcement not require dll injection?

On further consideration, MBAE 1.12.1.109 is better with Windows XP than MBAE 1.13 Build 60. I have noticed what seem to be intermittent 'pauses' while Mozllla Firefox ESR 45.9 is running with MBAE 1.13 Build 60.

Hi Pedro. It's called enlightened self-interest. MBAE 1.13 Build 60 also works well with Windows XP (running on 17 year-old pre-SSE2 processor) but I do wonder whether or not an older version (I have been using 1.12.1.109) might be more relevant to XP.

The three month interval since the previous release of MBAE seems to have been well used. MBAE 1.13 Build 60 behaves very well with Windows 7 and Windows 10. Reading between the lines, I guess that a lot more work has been put into the latest MBAE than the brief summary information in the changelog would have us believe.