ky331

Out of curiosity, I tried testing FF27.0.1's Print Preview function. On my first Win7x64 SP1 system, with EMET 3, it opened just fine. But on my second Win7x64 SP1 system, with EMET 4.1, something started to pop up, but it immediately disappeared. Moreover, when I tried an actual Print, it generated a printer error message. HOWEVER, the same things happened with both EMET and MBAE disabled, so I don't believe either one was responsible here. [The printer works fine with IE.]

Confirming, as have two others previously, that x.300 is NOT conflicting with EMET 4.x's SimExecFlow mitigation. Whether this was intentionally done, or merely an "accidental" side-benefit of whatever-else you were trying to fix, I consider this a major improvement in your program. Good work!

Just e-mailed you logs of two tests I ran today --- this time, on a 32-bit WinXP Pro SP3 system, on an account with full administator rights. Avast 2014, Emet 2, MBAM Pro 1.75. Apparently, the problem was that I stopped x.200's protection --- thinking that was a prudent move --- before installing x.300 over it. In this scenario, even after manually starting x.300's protection, it would be stopped on subsequent reboots. In contrast, by leaving x.200's protection running, and installing x.300 over it, everything went normally.

"If you have the protection stopped when upgrading from .0200 to .0300 it is normal that the .0300 stays in stopped mode as well". I tried to take [what I assumed to be] a safe approach to the upgrade from .0200 to .0300 ; so I stopped .0200's protection, and furthermore, exited that program, prior to installing .0300. When/if I noticed that .0300 was stopped, I turned it back on. It stayed that way, until I rebooted, only to realize it had shut itself off. I turned it on again, rebooted, but it was off yet again. Trying to revert back to .0200, without removing the C:\ProgramData folder , resulted in .0200 booting in stopped mode as well. Only after removing the C:\ProgramData folder, was I able to get .0200 to start up normally. I'll check momentarily to see if I still have a log file, to zip/e-mail you. [EDIT: Found, and sent.] the particular test was done on a Win7x64 Pro SP1 system, on an account with full administator rights. Avast 8, Emet 3, MBAM Pro 1.75.

Another problem: Perhaps naively, I assumed I could reinstall x.200 over x.300... which seemed to work... except that x.200's protection was initially STOPPED as well. Uninstalling x.200, and even reinstalling/uninstalling x.300, didn't make a difference. What I finally had to do was go to the new C:\ProgramData folder to manually remove the files there (.dat & others), which apparently were storing the STOPPED status, even after UNinstalling x.300, and even after a reboot. I was then able to successfully (re-)install and START x.200

another BIG issue with x.300, after a reboot, the protection is STOPPED... from what I see in the log, it's saying I don't have sufficient administrator rights on my account: (I will be going back to x.200 at this point) mbae-svc-NoMod(215) - 2014/02/15 - 16:22:49 - #1# - LoadReportFile: - 9 - 2676 mbae-svc-NoMod(217) - 2014/02/15 - 16:22:49 - #1# - ServiceStart: 9 - 9 - 2676 mbae-svc-NoMod(820) - 2014/02/15 - 16:22:49 - #2# - InstallDriver: Malwarebytes Anti-Exploit Driver Installed successfuly - 30 - 2676 mbae-svc-NoMod(268) - 2014/02/15 - 16:22:49 - #2# - ServiceStart: Malwarebytes Anti-Exploit Service is started - 213 - 2676 mbae-NoMod(455) - 2014/02/15 - 16:23:26 - #2# - IsAdminRunning: Admin Limited - 35 - 4804 mbae-NoMod(139) - 2014/02/15 - 16:23:27 - #1# - LoadReportFile: - 9 - 4804 mbae-svc-NoMod(1141) - 2014/02/15 - 16:23:28 - #2# - IPCFromClient: GET_NUM_REPORTS - 30 - 5628 mbae-svc-NoMod(1188) - 2014/02/15 - 16:23:28 - #2# - IPCFromClient: GET_NUM_APPLICATIONS - 213 - 5628 mbae-svc-NoMod(1061) - 2014/02/15 - 16:23:28 - #2# - IPCFromClient: CLIENT_RUNNING (4764): <my name> - On - 213 - 5628 mbae-svc-NoMod(1131) - 2014/02/15 - 16:23:29 - #2# - IPCFromClient: GET_APP_CONFIG - 213 - 5628

in x.300, information on the LOGS tab for previously existing entries (carried-over from x.200) is messed-up: instead of showing that an application was protected, it's asserting that an exploit code had been blocked. it seems that NEW entries (created by x.300) are showing normally on the LOGS tab.

Pedro, I see the alpha mentioned above on this page is a new minor build x.300 (as opposed to the previous x.200). Can you elaborate on the changes implemented from one to the next? Is it worth it for x.200 testers to update to x.300, or should we just wait until a newer build is released? EDIT: I just "discovered" a message you had sent me yesterday, answering this question.

Then I would suggest you include a PROMINENT announcement (disclaimer) with the beta, lest EMET 4.x users be very surprised when they soon discover they can't open a browser upon installing/testing the beta [unless they adjust their EMET settings first].

When you release .10 as beta, will you have solved/fixed the EMET 4.1 SimExFlow conflict? Or will you just be "advertising" it as a known issue?

Third (and last) test system: Win7x64 Pro SP1 with EMET 3.0. All running smoothly so far. I intend to continue using/testing this alpha on these 3 systems. So in my testing of 3 systems/configurations, the only issue/conflict noted was with EMET 4.x's SimExecFlow mitigation (which is not included in EMET 2.x nor 3.x). On all 3 systems, WORD (and EXCEL, when I had it) showed up in the LOGS tab, and there was no crash when I started/stopped MBAE with protected programs open

Now testing on a second system, this one is 32-bit XP Pro SP3 with EMET 2.1. Since this older version of EMET does not offer SimExecFlow mitigations, I've encountered no conflicts here... all is running smoothly so far. MBAE even acknowledged/protected WORD 2000 !

A suggestion for future alpha/beta releases: I realize that the point of alpha/beta releases is to TEST the product for performance/safety/reliability... especially given the multitude of esoteric hardware/software configurations that people have: I understand there's no way you can anticipate all possibilities, and so need public assistance in testing them out. HOWEVER, given that MBAE clearly overlaps EMET (in part), and that EMET, being backed by Microsoft, must be viewed as a popular (dare I say "de facto standard") anti-exploit product among a significant number of security-conscious users, I do believe that "in-house" testing on your part requires testing MBAE against a default EMET configuration... at the very least, relative to the most current EMET 4.x... and ideally, relative to other still-supported versions like 3.x... before making even an alpha release available for testing. Put bluntly: Something as basic as IE and FF not opening should have been caught in-house. In order to guarantee the largest user-base, every effort needs to be made to have MBAE fully-compatible with EMET. Just my strong opinion/suggestion.

As for starting/stopping MBAE within an open/running program (after having adjusted SimExecFlow in EMET), it would appear that there's no longer a[n absolute] conflict... but there DOES seem to be a very considerable LAG before I can access the program (e.g., IE) again.

Durew, You've hit it on the nose there: By opening EMET and UNchecking SimExecFlow for: IE FF + Plug-in Container Adobe Reader/Acrobat Windows Media Player all of these now open/run Note: Unchecking FF allows it to open. But since FF soon calls its Plug-in Container, which will hang the page unless also permitted. On that basis, I'd have to wonder about other add-ons that are called through another program (e.g., java being invoked via IE. I doN'T have java on my system, so I can't test things here).

Yes to EMET 4.1. As for the rest on the particular system I was testing: Win7 Pro x64 SP1; Panda Cloud Free 2.3 MBAM 2.0 (Testing --- so far, so good) Windows Firewall OpenDNS Family Shield SpywareBlaster MVPS HOSTS file MCShield 3.0 WinPatrol PLUS SAS (On-demand scanner) WOT (for IE & FF) set to BLOCK untrustworthy sites. KeySrambler (for IE) Zemana Anti-Logger (for all other programs); CryptoPrevent Secunia PSI 1.0 I know, it's a lot. But all seems to work well together. Remark: Use of Zemana Anti-Keylogger is recent, and I'm still evaluating it. Fortunately, it defers to KeyScrambler in IE, so there's no conflict there. But I'll probably get rid of KeySrambler soon enough.

Attached is my preliminary report, which was disastrous . (Since no one else has commented so far, I have to wonder if it's just me and this one system.) I am e-mailing my log file to you momentarily... MBAE alpha.rtf

Just to make it easier to follow here: 1=Traybar Icon disappearing 3=Word/Excel/Powerpoint not showing as protected in Logs tab 4=open shielded application hanging/crashing when MBAE is started/stopped/exited.

For example, it would be good to know which of the known problems (in 0.9) have been addressed in .10 [and which ones are still known to remain], so we can try to test these.

I didn't mean to suggest that private information (e.g, real names) be displayed here... names [and/or other confidential information] can easily be edited-out of logs before posting... or if necessary, the log itself can be sent to you via e-mail. But I do believe a general description of any problems encountered should be posted... and yes, in a separate alpha/experimental thread (or sub-forum) so as not to be confused with other versions.

Why keep problems private (PM/e-mail) rather than report them here? By reporting, others can confirm/refute and offer comments... they won't have to re-report the same thing to you... and if the problem is significant enough, people can decide to opt-out and avoid it.

Sunriseal, The problem that A. Carwile and I experienced was for InstallMate -- specifically, the UNinstaller (and related files) used by WinPatrol. This issue has indeed been addressed/fixed as I noted above. When you mentioned "a bunch of InstallMate files", I assumed (perhaps erroneously) that you were referring to precisely the same issue [and nothing more]. When you subsequently posted your log, it then became clearer that your issue was SweetPacks/SweetIM and Conduit --- you'll note that InstallMate is not mentioned in your log at all. As miekiemoes mentioned, SweetPacks and Conduit are a different matter (than InstallMate/WinPatrol).

Looks like the issue has been FIXED with the release of database 2013.08.15.1

Zip files attached 4BB7A109-FDB5-45E3-9DB9-ECB2EA7B80EE.zip

I suggest we wait for an official response from someone on the MalwareBytes team, now that this issue has been brought to their attention. Given the response on 18 March (above) that it was indeed an F/P then, I would expect the same result now. A PUP is a Potentially Unwanted Program, so there is room for debate there (in general). But I would suspect that no one would consider WinPatrol's UNinstaller to be a PUP. I am taking for granted that MBAM can determine which program (e.g., WinPatrol) is being uninstalled in these cases. If you delete the WinPatrol-related files, you'll "break" WinPatrol's ability to uninstall itself. [This isn't as critical as it sounds... because if you re-install WinPatrol over itself, it will re-create these files, allowing you to then properly uninstall it.] In the event that MBAM decides to stick with this classification, keep in mind that a PUP is ultimately a user-choice: what one person deems "unwanted", another person might consider useful. Knowing that my "PUPs" came from WinPatrol, I intend to keep them regardless.