btmp

There are some pre-prepared/existing shields that are there but don't make it to the GUI. It seems you've encountered one here. Based off an on older post here is a string which could involve a few others you haven't mentioned yet."C:\Program Files (x86)\Malwarebytes Anti-Exploit\mbae64.exe" /Start 0 "winrar.exe|winzip.exe|7z.exe|cmd.exe|winhlp32.exe|wscript.exe|quicktimeplayer.exe|winamp.exe|vlc.exe|mplayer2.exe|wmplayer.exe|powerpnt.exe|excel.exe|excelc.exe|winword.exe|winwordc.exe|soffice.bin|foxitreader.exe|foxit reader.exe|Foxit PhantomPDF.exe|FoxitPhantomPDF.exe|acrord32.exe|acrobat.exe|java.exe|javaw.exe|javaws.exe|dragon.exe|waterfox.exe|tor.exe|tbb-firefox.exe|palemoon.exe|cyberfox.exe|icedragon.exe|seamonkey.exe|maxthon.exe|mxapploader.exe|opera.exe|opera_plugin_wrapper.exe|opera_wrapper_32.exe|iexplore.exe|MicrosoftEdge.exe|MicrosoftEdgeCP.exe|chrome.exe|old_chrome.exe|firefox.exe|plugin-container.exe|FlashPlayerPlugin*.exe|helpctr.exe|mbae-test.exe" I don't personally see why they shouldn't *all* be listed so that we may view and modify them as needed but..erm yeah there are at least already some protections being applied in this case. And more amusingly I was unable to *actually* edit this via firefox despite filling in the 'required' reason repeatedly. It never showed my actual text in order to let me try to change it! Yet it works the first time via chrome, go figure /sigh.

No new issues noticed with 1.9.1.1254 over the last few hours of testing. Getting a bit annoyed that I have to re-check the ROP gadget detection upon every upgrade though. Why isn't this area of the options getting saved?

Sorry, failed to respond to this area: Those rules are part of the Sandboxie template released here and some tweaked hybrids you might see elsewhere such as Wilders or the Sandboxie forum and they'd ook something like this: The InjectDLL rules found in the template are the ones I was talking about and if already added per the 'default suggestion' could be found in the C:\Windows\Sandboxie.ini:

I'm confused by this comment: The InjectDLL [eg insertion code] of the public Sandboxie template has been around for over a year so I wonder if this change of notification might actually be related to the point where a newer version of MBAE with this, new, added 'hidden' winrar rule went live ( and shifted cmd out of being the first in line) and you then saw the new alert? According to the posts here: https://www.wilderssecurity.com/threads/malwarebytes-anti-exploit.354641/page-134 it (the new version of MBAE) went stable on the 28th so if you updated it around the 29th it would explain it. To avoid spamming your other thread /me cries

The full comment: reads to me as a question, not a statement. While running Sandboxie and MBAE in the current state with the template isn't ideal with the manual injection of the dll, the protections are applied for a shielded app. However due to the extra sandboxie layer in the mix you might encounter more 'false positives' such as I do when running Minecraft under Sandboxie and trying to join a multiplayer server and getting a constant java exploit blocked alert where it then closes minecraft... I haven't seen this with anything but the java rules on my end but I won't say it can't happen with any of the others either.

1.09 Oddities So basically due to the 'dirty' InjectDll= done in the template, by using sandboxie itself to inject the MBAE dll, if MBAE doesn't find a matching rule it seems to go with whatever is the first entry. This used to be 'cmd.exe' but if a matching rule is found that will be used. As the sandboxie exes and other components or programs don't have rules in MBAE you will just see winrar instead for them. Normally MBAE wouldn't inject into programs it doesn't have a rule for this isn't really a problem that can be 'fixed' but if MBAE were to begin properly injecting into sandboxie protected apps by itself then the those InjectDll lines could be removed and the issue would vanish. For now just ignore them as a minor side effect of the InjectDll=.

Sorry for the long delay, yes the newer builds seem to resolve the crashes on exit. Last month I wasn't free much and I sorta forgot to check back here till tonight. :-/ Great work, Much appreciated!

Thanks for the quick response Mr. Pedro! Peter, who I don't actually 'hate' but I do have a small dislike of that I 'obtained early on' via the SBIE forum and still just can't quite let go of....[so it galls me to quote him several times in as many days], made a good point yet again that I wasn't aware of on Wilders where other pieces of decent to good security products also had issues at one point as well. So perhaps I jumped the gun with my original post here and my 'call to voice' but I really would like to see the problem solved soonish as its been around for quite a while. If it's any consolation I already added MBAE (free) to my kids PC alongside SBIE on Win10 but aside from XP the dll issue isn't a security risk so much as it is an 'annoyance on several levels'. Solving the DLL injection would allow all around 'easy' compatibility. I never was able to isolate why MBAE wouldn't work with SBIE 4.x+ on XP [while it works on vista to 10] so while there is no guarantee fixing the DLL injection issue will work suddenly allow them to work together on XP as well it'd be a great start but to let you know ahead of time there might be another issue to look after that but we won't for sure until the other one is solved....

For *some reason* MBAE hasn't been able to inject into SBIE 4.x+ protected processes starting with the earliest of MBAE betas (that I tested). As I was the one to come up with a 'template' that could be applied within Sandboxie and allow them to work together by FORCING the DLL injection via a SBIE string to 'temporarily' overcome this issue I've become more worried as time passes. I'm concerned that my attempts to 'work around' the issue have instead enabled you to avoid addressing it all together. =( With virtually [let's say 90% min though it's likely higher] every other security software solution being able to detect and inject into the processes they are meant to protect, regardless of the presence of Sandboxie, and MBAE somehow NOT being able to reliably do so would you fault me or others for doubting the protection you can offer when the layers of protection are likely to be MUCH more difficult to create and maintain? Don't get me wrong, I haven't lost faith in you (yet) but it's hard to swallow that you can provide advanced Exploit protections if you can't even properly inject into a program protected by another piece of software that no one else seems to have issue working with... So yeah, drunken rant over (for now)....

Tested 1.9.1.1156 and there's a very annoying issue where many Shielded apps throw up an error and crash when attempting to close them. Re-created it on a Windows 7 x64 VM with no other security products. Even notepad.exe being added as 'other' with all other settings left at default crashes when exiting. Here's a procmon log and the MBAE ProgramData directory for the VM that screenshot is from. Notepad_MBAE.zip

In earlier versions the log actually had a lot more helpful info and I for one was sad when it was removed. I liked being able to see the protection types being applied, eg (Bottom up ASLR) While I'm not sure this is actually what you are after I think it might have helped by being able to read a log where such things were recorded. These days, for a user, it's very much a leap of faith that it's actually doing what you have it set up to do [think potential bugs or conflicts with other security programs] especially if you aren't visiting random sites or getting fed bad ads. Never hearing a peep out of MBAE could certainly lead one to wonder. I expect the logs in the ProgramData folder still hold such information but it's not something a user can just open up and read... :-/

I disable them myself but without having the protection status logged by default once again users wouldn't know if it was even working. Perhaps some type of 'heartbeat icon' could be flashed instead of the pop up by default. eg a big green check mark inside the notification icon for 3 seconds after the program starts or something like that so there is a visual notification but not the darned pop up?

I just tested with a clean VM and winrar is getting injected though it doesn't get listed up in the gui shields or log. Looks like it might be due to the previous rule you had. I figured maybe it was confused by the two different rules so I reverted the VM. I installed 1.08.1.2563 first to make a winrar rule then updated it to the beta. While the shield was removed from the gui, the dll was injected into mine so perhaps there is something else involved with your results?

Confirmed here, not something I normally test

It's very likely the rule still exists, just for some reason it's not shown in the gui. I came across a list of created exe rules during the install process while trying to figure out something else. There a couple which are created but don't get shown in the list of the gui, winrar being one of them. "C:\Program Files (x86)\Malwarebytes Anti-Exploit\mbae64.exe" /Start 0 "winrar.exe|winzip.exe|7z.exe|cmd.exe|winhlp32.exe|wscript.exe|quicktimeplayer.exe|winamp.exe|vlc.exe|mplayer2.exe|wmplayer.exe|powerpnt.exe|excel.exe|excelc.exe|winword.exe|winwordc.exe|soffice.bin|foxitreader.exe|foxit reader.exe|Foxit PhantomPDF.exe|FoxitPhantomPDF.exe|acrord32.exe|acrobat.exe|java.exe|javaw.exe|javaws.exe|dragon.exe|waterfox.exe|tor.exe|tbb-firefox.exe|palemoon.exe|cyberfox.exe|icedragon.exe|seamonkey.exe|maxthon.exe|mxapploader.exe|opera.exe|opera_plugin_wrapper.exe|opera_wrapper_32.exe|iexplore.exe|MicrosoftEdge.exe|MicrosoftEdgeCP.exe|chrome.exe|old_chrome.exe|firefox.exe|plugin-container.exe|FlashPlayerPlugin*.exe|helpctr.exe|mbae-test.exe"