MBAE 1.12.1.136 Experimental

[hake]

Protection is decribed as "New Updated Protection for Chrome and Edge Browsers ".  I guess that this does not apply to chrome.exe of Google Chrome.

[exile360]

Correct, they cannot use a DLL injection protection method as they do for other processes due to Google's new policy regarding such methods, so they must be using some alternative method to attempt to shield it from exploits.  All of the executables listed under the list of shielded applications are injected with MBAE's DLL, but since Google prohibits this, they cannot use that method to shield the browser from exploits.

[Arthi]

Hi,

Yes, we have implemented an alternate approach to offer protection to Chrome and Edge users without DLL injection.

[exile360]

Very cool, I'm glad you guys were able to work out an alternative shielding mechanism.  I hope it proves as effective as the DLL injection method, but even if it doesn't, it's certainly better than no protection at all.

[hake]

@Arthi:  Can you please confirm that your words "we have implemented an alternate approach to offer protection to Chrome and Edge users without DLL injection" mean that MBAE 1.12.1.136 includes this?

Edited November 14, 2018 by hake

[nukecad]

On 11/12/2018 at 8:38 PM, Arthi said:

Hi,

Yes, we have implemented an alternate approach to offer protection to Chrome and Edge users without DLL injection.

Sometimes the best inovations come about because you get forced to do things differently from the 'norm', so have to think of something new.

[Arthi]

5 hours ago, hake said:

@Arthi:  Can you please confirm that your words "we have implemented an alternate approach to offer protection to Chrome and Edge users without DLL injection" mean that MBAE 1.12.1.136 includes this?

Yes this is included in 1.12.1.136 

[hake]

Thank you Arthi.

[cutting_edgetech]

Is it possibly to provide exploit protection with a browser extension, or plugin instead? It may be a lot of work maintaining the extensions, or plugins, but if you only had to do it for a few browsers then it may be an option. Malwarebytes already has a browser extension so maybe additional capabilities could be added to it.

[exile360]

They can't for Chrome as this move was specifically because Google's new policy prohibits it, which also means any browser extensions that use similar methods will be killed off/blocked eventually.  Also, I think part of the problem is that an extension/plugin is trapped inside the browser sort of like operating in a sandbox, which prevents the kind of overall process/thread access/monitoring required to check for exploit behavior in real-time.

[cutting_edgetech]

I don't know how else it could be done unless behavior blocking is used to catch the aftermath after an exploit has already executed. That's not ideal, but better than nothing. May parent child process control will help.

[exile360]

I think they do it by monitoring process activity in memory just as they used to using the DLL injection method (they should be able to see what threads/processes/API calls etc. the process tries to make to look for exploit related behaviors and stop them pre-execution as they're mapped to memory; this is also how their primary Malware Protection component detects malicious processes/files as they attempt to execute in memory, detecting and quarantining them before the process actually enters memory space which would otherwise prevent removal of the file since its process would be running in memory and wouldn't prevent infection).  Of course I'm no developer, so that's just my hypothesis, but I'm probably not too far off the mark.

It may work similarly to how tools like Process Explorer and Process Monitor do, where they use a driver rather than DLL injection to monitor deep level process activity.  If they can do that and see exploit behavior attempts/thread initializations and stop them pre-execution, that would be sufficient to shield those applications which they can't inject a DLL into (like Google Chrome).

[exile360]

Also, regarding a browser extension, I believe Chrome, Edge and pretty much all browsers these days do in fact limit/restrict what plugins/extensions can and cannot see or do and how much control they can have as a means of protecting against more malicious behaviors and exploits by plugins and extensions, at least that's my understanding, but again, I'm no dev so I concede to anyone more versed in the field.

[hake]

I have tried MBAE 1.12.1.136 on Windows 7 (64bit) and find that it seems to have imposed a performance penalty with Google Chrome (latest 32bit version).  Admittedly my hardware is 12 years old (Intel Pentium 4 twin core 3.2GHz processor) but using that slower hardware also emphasises the effects of performance hits.

Reverting to MBAE 1.12.1.109 restores performance to what was previously normal.  Google Chrome has not yet given MBAE 1.12.1.109 the sack.  When that happens, I shall probably give Google Chrome the sack.

Edited November 15, 2018 by hake

[Arthi]

6 hours ago, hake said:

I have tried MBAE 1.12.1.136 on Windows 7 (64bit) and find that it seems to have imposed a performance penalty with Google Chrome (latest 32bit version).  Admittedly my hardware is 12 years old (Intel Pentium 4 twin core 3.2GHz processor) but using that slower hardware also emphasises the effects of performance hits.

Reverting to MBAE 1.12.1.109 restores performance to what was previously normal.  Google Chrome has not yet given MBAE 1.12.1.109 the sack.  When that happens, I shall probably give Google Chrome the sack.

Haha..Thanks hake for your support !! We will look into your issue. Trying to reproduce it at our end.

[hake]

I am using MBAE 1.12.1.137 and it actually seems to be on a par with MBAE 1.12.1.109.  Nothing remarkable of note to observe right now.  It works and you can't say fairer than that.

[hake]

MBAE 1.12.1.137 is working well.  The performance dip in Google Chrome on my slow hardware was due to too many browser extensions which have been pruned down to the essential ones. I am now very satisfied and look forward to further developments.

It would be nice to see evidence in the log that Google Chrome is being protected, even if the details are not yet available to the user.

Edited November 16, 2018 by hake

[exile360]

Yep, plugins in Chrome do tend to eat up a lot of resources.  I noticed similar behavior in the past and eliminated a few I didn't need/use and things improved substantially.