MemProtect - Support & Discussion

Memprotect's playing tricks on me, here's my current memprotect config:

Spoiler

[#INSTALLMODE]
[LETHAL]
[LOGGING]
[#DEFAULTALLOW]
[MODULEFILTER]
[WHITELIST]
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe
!C:\Windows\System32\csrss.exe>*
!C:\Windows\System32\svchost.exe>*
!C:\Windows\System32\lsass.exe>*
!C:\Windows\System32\RuntimeBroker.exe>*
!C:\Windows\System32\audiodg.exe>*
!C:\Windows\System32\Taskmgr.exe>*
!C:\Program Files\NoVirusThanks\EXERadarPro\*.exe>*
!C:\Program Files\NoVirusThanks\OSArmorDevSvc\*.exe>*
!C:\Windows\explorer.exe>*
C:\Windows\ImmersiveControlPanel\SystemSettings.exe>C:\Windows\explorer.exe
C:\Windows\System32\*.exe>*
C:\Windows\SysWOW64\runonce.exe>C:\Program Files (x86)\REDRAGON GAMING MOUSE\MMMon.exe
C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_*\TiWorker.exe>C:\Windows\System32\makecab.exe
C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_*\TiWorker.exe>C:\Windows\servicing\TrustedInstaller.exe
C:\Windows\servicing\TrustedInstaller.exe>C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_*\TiWorker.exe
C:\Windows\Microsoft.NET\Framework*\v4.0.30319\*.exe>C:\Windows\Microsoft.NET\Framework*\v4.0.30319\*.exe
C:\Program Files*\*\*.exe>C:\Program Files*\*\*.exe
C:\Program Files*\*\*.exe>C:\Windows\explorer.exe
C:\Program Files*\*\*.exe>C:\Windows\notepad.exe
C:\Program Files\NVIDIA Corporation\Display.NvContainer\NVDisplay.Container.exe>C:\Windows\System32\rundll32.exe
C:\Program Files\Shadow Defender\*.exe>C:\Windows\System32\mountvol.exe
C:\Program Files (x86)\Epic Games\Launcher\Portal\Binaries\Win64\EpicGamesLauncher.exe>*
C:\Program Files\Epic Games\Fortnite\FortniteGame\Binaries\Win64\FortniteClient-Win64-Shipping.exe>*
C:\Program Files (x86)\Common Files\BattlEye\BEService.exe>*
C:\Program Files\simplewall\simplewall.exe>C:\Windows\*.exe
C:\Program Files (x86)\Excubits\*\Tools\Admin Tool.exe>C:\Windows\System32\cmd.exe
[BLACKLIST]
$*chrome.exe>*.exe
*chrome.exe>*
*>*chrome.exe
[MODULEWHITELIST]
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Program Files (x86)\Google\Chrome Beta\Application\69.0.3497.81\*.dll
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Windows\System32\*.dll
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Windows\System32\*.drv
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Windows\WinSxS\amd64_microsoft.windows.common-controls*\comctl32.dll
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Windows\WinSxS\amd64_microsoft.windows.gdiplus_*\GdiPlus.dll
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Program Files\NVIDIA Corporation\Ansel\Tools\NvCameraWhitelisting64.dll
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Program Files\NVIDIA Corporation\Display\nvdisps.dll
!C:\Windows\explorer.exe>*
C:\Windows\*.exe>C:\Windows\System32\*.dll
C:\Windows\*.exe>C:\Windows\System32\*.drv
C:\Windows\*.exe>C:\Windows\SYSWOW64\*.dll
C:\Windows\*.exe>C:\Windows\SYSWOW64\*.drv
C:\Windows\*.exe>C:\Windows\WinSxS\*.dll
C:\Windows\*.exe>C:\Windows\*.exe
C:\Windows\*.exe>C:\Program Files*\*\*.dll
C:\Windows\*.exe>C:\Program Files*\*\*.exe
C:\Windows\System32\rundll32.exe>C:\Windows\System32\*.cpl
C:\Windows\*.exe>C:\Windows\assembly\NativeImages_v4.0.30319_??\*.ni.dll
C:\Windows\*.exe>C:\Windows\Microsoft.NET\*.dll
C:\Windows\*.exe>C:\Windows\ShellExperiences\*.dll
C:\Windows\*.exe>C:\Windows\ImmersiveControlPanel\*.dll
C:\Windows\*.exe>C:\Windows\servicing\*.dll
C:\Windows\SystemApps\Microsoft.Windows.SecHealthUI_*\SecHealthUI.exe>C:\Windows\SystemApps\Microsoft.Windows.SecHealthUI_*\*.dll
C:\Program Files*\*\*.exe>C:\Windows\System32\*.dll
C:\Program Files*\*\*.exe>C:\Windows\System32\*.drv
C:\Program Files*\*\*.exe>C:\Windows\SYSWOW64\*.dll
C:\Program Files*\*\*.exe>C:\Windows\SYSWOW64\*.drv
C:\Program Files*\*\*.exe>C:\Windows\WinSxS\*.dll
C:\Program Files*\*\*.exe>C:\Windows\notepad.exe
C:\Program Files*\*\*.exe>C:\Program Files*\*\*.dll
C:\Program Files*\*\*.exe>C:\Program Files*\*\*.exe
C:\Program Files\NVIDIA Corporation\Display.NvContainer\NVDisplay.Container.exe>C:\Windows\System32\rundll32.exe
C:\Program Files\Shadow Defender\*.exe>C:\Windows\System32\mountvol.exe
C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IAStor*.exe>*
C:\Program Files (x86)\SpeedFan\speedfan.exe>C:\Windows\SysWOW64\hhctrl.ocx
C:\Program Files (x86)\SpeedFan\speedfan.exe>C:\Users\User\AppData\Local\Temp\sfa*00001.dll
C:\Program Files (x86)\Excubits\*\Tools\Admin Tool.exe>C:\Windows\System32\cmd.exe
[MODULEBLACKLIST]
*chrome.exe>*
*>*chrome.exe
[EOF]

As you can see, $*chrome.exe>*.exe is before *chrome.exe>* , so chrome trying to access exes should not be logged, while anything else not already whitelisted should be, or at least that's what I'd think would happen, but nope. So, here's what's happening:

Without $*chrome.exe>*.exe rule I get the normal blocks that I'm trying to silence:

Spoiler

*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files\NoVirusThanks\EXERadarPro\RadarPro.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\sihost.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\svchost.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files\NoVirusThanks\OSArmorDevSvc\OSArmorDevUI.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\svchost.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\explorer.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\taskhostw.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\RuntimeBroker.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\Excubits\Bouncer\Tools\BouncerTray_x64.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files\Shadow Defender\DefenderDaemon.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\Skype\Phone\Skype.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\REDRAGON GAMING MOUSE\MMMon.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\Excubits\Pumpernickel\Tools\Tray.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\Excubits\MemProtect\Tools\Tray.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IAStorIcon.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\explorer.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\ApplicationFrameHost.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\RuntimeBroker.exe
*** excubits.com demo ***: 2018/09/06_23:27 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\smartscreen.exe

With $*chrome.exe>*.exe rule, I get only some of the blocks (tested multiple times), but they should all be silenced... and yes I did restart the service

Spoiler

*** excubits.com demo ***: 2018/09/06_23:22 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\sihost.exe
*** excubits.com demo ***: 2018/09/06_23:22 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\svchost.exe
*** excubits.com demo ***: 2018/09/06_23:22 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\svchost.exe
*** excubits.com demo ***: 2018/09/06_23:22 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\taskhostw.exe
*** excubits.com demo ***: 2018/09/06_23:22 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe
*** excubits.com demo ***: 2018/09/06_23:22 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\RuntimeBroker.exe
*** excubits.com demo ***: 2018/09/06_23:22 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\ApplicationFrameHost.exe
*** excubits.com demo ***: 2018/09/06_23:22 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\RuntimeBroker.exe
*** excubits.com demo ***: 2018/09/06_23:22 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\smartscreen.exe

I also tried C:\*.exe , C:*.exe etc. instead of simply *.exe , nothing has worked. As soon as I remove the $*chrome.exe>*.exe rule, all blocks are logged, as soon as I add the rule, only the above blocks are logged, seems like the other ones get silenced, but why not the remaining? *.exe is about as clear as it can get, and yet memprotect is doing pranks... C:\Program Files and x86 are silenced, as well as explorer.exe, while the other ones aren't. If I remove the $*chrome.exe>*.exe rule and change *chrome.exe>* to $*chrome.exe*>*, I STILL get those blocks from system32 and systemapps exes. They're LITERALLY unsilenceable. @WildByDesign Is your chrome://gpu behaviour the same?

 

@Floyd 57 Normally I was not silencing these since I rarely ever access the chrome://gpu page and therefore don't typically see these blockages otherwise. But for curiosity and sake of testing, I decided to test this.

Instead of what you have:

Code:

[BLACKLIST]
$*chrome.exe>*.exe
*chrome.exe>*
*>*chrome.exe

I kept it simple like this:

Code:

[BLACKLIST]
$*chrome.exe>*
*>*chrome.exe

And with this rule change, I was able to silence all blockages of the running process polling that chrome.exe was doing when visiting chrome://gpu page. No blockages showed at all for me with that rule change. Give that a try.

Keep in mind that, from time to time, you should likely remove that $ just to ensure that nothing important is being blocked. Although that would likely only occur if you made major software changes on your system. Typically, once your rules are "golden", they stay "golden". So hopefully this works for you as well.

 

Well, I think this wraps it up, nothing else left to test, time to email Florian with yet another bug :O

It's as simple as this, here's [defaultallow] code where I get 0 blocks, everything's silenced:

Code:

[#INSTALLMODE]
[LETHAL]
[LOGGING]
[DEFAULTALLOW]
[#MODULEFILTER]
[WHITELIST]
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe
[BLACKLIST]
$*chrome.exe>*
[MODULEWHITELIST]
[MODULEBLACKLIST]
[EOF]

Here's [#defaultallow] code where I also get 0 blocks, everything's silenced:

Code:

[#INSTALLMODE]
[LETHAL]
[LOGGING]
[#DEFAULTALLOW]
[#MODULEFILTER]
[WHITELIST]
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe
*>*
[BLACKLIST]
$*chrome.exe>*
[MODULEWHITELIST]
[MODULEBLACKLIST]
[EOF]

The last one is basically equivalent to the first one, *>* is like defaultallow

And here's the code where I get those unsilenceable blocks:

Code:

[#INSTALLMODE]
[#LETHAL]
[LOGGING]
[#DEFAULTALLOW]
[#MODULEFILTER]
[WHITELIST]
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe
[BLACKLIST]
$*chrome.exe>*
[MODULEWHITELIST]
[MODULEBLACKLIST]
[EOF]

With [defaultallow] everything's allowed by default which is not explicitly blacklisted, so the unsilenceable rules that keep getting blocked are not blocked because they're allowed by default (even though they shouldn't be because of the $*chrome.exe>* rule, they should be blocked and silenced, but instead without [defaultallow] or *>* they're blocked but not silenced, whereas with [defaultallow] or *>* they're ALLOWED when they should be blocked or silenced, really makes no sense whatsoever, memprotect acts as if these blocks have never ever been defined by the rules, which is why they don't follow the silence rule and they also follow the allow rule when they have been explicitly blocked by $ rule (check last code section))

However, with [#defaultallow] and no *>* , the bug is exposed

Obviously, since it's #defaultallow and there's no *>* rule, I get hundreds of blocks per second, but if I do a search (CTRL+F in notepad++) with "C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe >" I can see the unsilenceable rules yet again. Which explains why I also see them with my normal config of 80 lines. The latter makes the hundreds of blocks per second with #defaultallow disappear simply because they're allowed, however the unsilenceable rules are still there, because this config is exactly the same as the last one, whether it's 10 or 80 lines, with the only difference being that there are more things whitelisted to make those hundreds of blocks per second not be there (which is also why the last config is with #lethal)

These blocks are silenced by the $*chrome.exe>* rule, like they and the below ones should be:

Spoiler

*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files\NoVirusThanks\EXERadarPro\RadarPro.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files\NoVirusThanks\OSArmorDevSvc\OSArmorDevUI.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\explorer.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\Excubits\Bouncer\Tools\BouncerTray_x64.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files\Shadow Defender\DefenderDaemon.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\Skype\Phone\Skype.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\REDRAGON GAMING MOUSE\MMMon.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\Excubits\Pumpernickel\Tools\Tray.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files (x86)\Excubits\MemProtect\Tools\Tray.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IAStorIcon.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\explorer.exe

$*chrome.exe>* does not silence these blocks no matter what:

Spoiler

*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\sihost.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\svchost.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\svchost.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\taskhostw.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\RuntimeBroker.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\ApplicationFrameHost.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\RuntimeBroker.exe
*** excubits.com demo ***: 2018/09/08_13:03 > MEMORY > C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\smartscreen.exe

So, the bug is, that the above blocks do not seem to follow memprotect's rules. They get allowed with [defaultallow] (or [#defaultallow] with *>*) even when there's a $*chrome.exe>* rule, and they get blocked but not silenced with [#defaultallow] without *>* . So they don't follow $*chrome.exe>* rule again, because they are both not silenced AND blocked because I haven't explicitly defined any rule that allows an exe from program files to access system32 exes, for those blocks it's as if the $*chrome.exe>* rule doesn't exist at all. I even tried some other rules placed before $*chrome.exe>*, such as $*chrome.exe>C:\Windows\System32\* , didn't work either, they're just ignored yet again. These blocks completely ignore any rule that's supposed to block or silence them, they get allowed in defaultallow when they should be blocked (and silenced), and they get blocked in #defaultallow when they should be silenced

I also tried this config without $ to check whether maybe they just ignore $ rule:

Code:

[#INSTALLMODE]
[#LETHAL]
[LOGGING]
[DEFAULTALLOW]
[#MODULEFILTER]
[WHITELIST]
!C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe>C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe
[BLACKLIST]
*chrome.exe>*
[MODULEWHITELIST]
[MODULEBLACKLIST]
[EOF]

And it turns out, that with defaultallow but with *chrome.exe*>* rule they do show in the logs, with $*chrome.exe>* they don't, so they EITHER work as expected with defaultallow (get silenced), OR they ignore the $*chrome.exe>* rule and are allowed because of defaultallow. BUT, one thing is known for sure, they ignore the $ rule in #defaultallow without *>*, and they either work as expected in defaultallow, or they also ignore it and are allowed because of defaultallow. But since #defaultallow with *>* acts the same as defaultallow, and they disappear from the logs in #defaultallow with *>* just like with defaultallow, then that means #defaultallow with *>* also EITHER allows them or they get silenced, but since without *>* they don't get silenced, thus $ rule is ignored, then with *>* they DO get allowed instead of silenced since we already know $ rule is ignored. So in #defaultallow they definitely ignore $ rule, and most likely do in defaultallow too though there's no way to check without defining *>* in blacklist of defaultallow (just like *>* in whitelist of #defaultallow)

 

@Floyd 57 Good catch. I haven't tested this out myself yet but by the sounds of it may be related to rule structure within the MemProtect filtering engine.
It is likely that Florian may provide you with a "debug-enabled" build of MemProtect which will provide much more debug logging (kernel level) to see what is happening and at which point it is happening. This will help him pinpoint and correct the issue. I had done this previously with Bouncer a while back and provided the debug logs to Florian. So hopefully this is easy enough to spot and fix.

 

I'd be great if you can test it out, if you want ofc (no pressure)

Now I just need to wait for Florian to reply to me, will probably take a few working days as usual, and since it's Saturday today (he doesn't check email in Saturday and Sunday, even for emails that otherwise he answers in 20 mins if it's something fast, at least not mine, don't ask me how I know this), the earliest he'll answer is Monday (and that's basically the "zero-day" of email answering, most emails have taken at least 2 days until I got an answer so this is optimistic, ofc there were some exclusions but they were for "fast" replies)

 

I will give it a try later on tonight and let you know if I can reproduce this as well. I just read over everything again to ensure that I understand all the details before I try to implement the same exactly as yours.

One thing that does stand out from the logs is that the ones not silencing are all within C:\Windows\System32\ as the child processes. So that is an interesting detail that may assist Florian when looking into this.

I will give this a try in a few hours and let you know.

 

@Floyd 57 I spent a good amount of time testing with [#DEFAULTALLOW] disabled, ensured that there was no *>* default allow alternative, and also ensured that there were no *chrome.exe>C:\Windows\System32\* whitelist permissions that would interfere with this testing. I did get hundreds of blockages (as expected) but running a search of the log for anything related to chrome.exe>C:\Windows\System32\ yielded no results for me. Unfortunately, I was not able to reproduce this bug on my machine.

 

Depending on which chrome channel you're on, you need to search for precisely "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe > C:\Windows\System32\" or "C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe > C:\Windows\System32\" (there's also Dev and Canary update channels, there's even a Raw build here, but I doubt you're using them) without the quotes ofc. Make sure you start from the top of the search log, make sure you reload the log if using Notepad++ or something similar

 

@Floyd 57 Mine is located in "C:\Program Files\Chromium\Chrome\Application\chrome.exe" and is the current Stable channel build of Chromium, matching the current, official Google Chrome stable release. That is my main browser. I will try again later today with the official Chrome release and see if there is any difference there.

I am able to produce those "C:\Program Files\Chromium\Chrome\Application\chrome.exe>C:\Windows\System32\" related blockages initially. But as soon as I add the silence $ rule to the *chrome.exe>* blacklist rule, such as $*chrome.exe>*, the silencing ends up working correctly and none of those System32 blockages are slipping into the log for me. So I will have to try again later today using official Chrome build and I will also try the current Chrome Beta which you are using to reproduce the issue and I will let you know how it goes.

 

@Floyd 57 I apologizing for not following up yet. I have not had a chance yet to install Chrome Beta channel release to be more specific. I am hoping to be able to do this today and follow up.

If you have a moment, could you also please try installing Chrome Stable channel?

Just to rule out the possibility of it just being specific to a certain milestone release of Chrome. See if you can reproduce with the same profile, same extensions, etc. And I will try later with Chrome Beta to see if I can reproduce.

Did you say that this only started happening with Chrome 69 release?

 

OK, so I think I FINALLY figured it out, after sooooooooooo muchhhhhhhh testing

So, it turns out it's caused by the "Help improve Chrome's features and performance" setting, when it's turned on it causes these blockages to appear

Now I had it turned off, along with all other "send data to google" settings, but when my browser was updated from 69.0.3497.71 to 69.0.3497.81 , these options were reset (I suppose), and I just now found out. Then I tested the options and it turns out that the above one is the one causing this. When you turn it on, you have to relaunch the browser for it to take effect, and then after no more than 5-10 mins MAX you should get the blocks

Lesson learnt: ** google!

 

@Floyd 57 I am so glad that you've figured out the source of this. It is unfortunate that Google would have flipped that setting on for you when you already had it turned off. I just checked my Chrome build and it still remains off. It is crazy how that one simple setting was causing so much activity on your system.

As a matter of fact, that is one thing that I appreciate most about the different Excubits drivers. The fact that the logging is so thorough and gives you a "bird's eye view" of everything going on within your system that a user would typically never have any idea is happening. Then, of course, it puts you in the driver seat to control any and all activity that you wish by creating rules.

On a side note, one of the recent injectors that I have been testing lately against MemProtect in GH Injector (https://guidedhacking.com/threads/gh-dll-injector-v2-5-source-included.8417/) which just recently had a 3.0 release, has a decent GUI and is updated often enough. What I like most is that the process selector does not trigger MemProtect blockages until the actual injection. Other GUI injectors often trigger MemProtect right away and makes it more difficult to test properly. Also it is open-source, so you can make changes and compile if necessary.

 

I mean, it still doesn't solve the silencing issue. Technically it does, cuz now that option is off, but the fact that when these blocks do appear, they aren't silenced, remains, can you emulate that on your system (I suppose not since you already had something like this with the chrome gpu thing but might be worth a try) ?

Yeah, it's all great until your .ini becomes too big (out of KB limit, relevant for Bouncer and Pumpernickel) or until your pc is brought to its knees because memprotect is sucking it dry (with bigger .ini), regardless of how fast your pc may be, got an i9-i7980XE? Hehe just you wait, memprotect will take care of it! Each rule that I make in memprotect is like someone piercing me, each rule is another sword into my heart, each one hurts me as if I'm giving away my child, the pain each letter inflicts me, the suffering each blockage causes me, every day is a fight to survive with memprotect, every day is a struggle, will you live to see the end of the day? The light at the end of the tunnel? Or will the slowness consume you, slowly eating away at your thoughts about a fast pc until you can no longer even imagine what it's like to have one, until you no longer can even start a video game, and then one day you look in the bottom right corner of the screen, and you see... AN ANTIVIRUS!!! RIGHT THERE IN THE NOTIFICATION TRAY!!!!! Sucking away at your soul, telling you that system32 folder is a virus while also eating all your resources, oh wait that's just memprotect ..... And finally, when it has absorbed all of your soul, your pc transforms into a celeron processor, a voodoo graphics card and a 32 bit OS, and then memprotect disappears forever into the shadow realm, and you hear Florian laughing in the background...

(he still hasn't emailed me about what happened with the memprotect performance tests, let's hope it's going well)

(I don't have any children for the record)

Not sure what this is useful for, we know memprotect can defend against dll injections already, right? As long as the malicious dll is not whitelisted access to

 

@Floyd 57 I will have to reply in more detail to all of your questions a bit later in the day. But I was surprised by your "performance" related concerns. That stood out to me because I've never experienced any kind of performance hit or perf degradation in any way from MemProtect. The only performance hit I had ever noticed from other Excubits drivers was when enabling SHA256 scanning which is understandable since the CPU has to process all of that hashing. I've used AppTimer and other programs in the past and never noticed and performance hits. I paid for MemProtect and therefore have a nearly unlimited (only limited by kernel) configuration size and have had upwards of 200+ lines of rules, including dozens of lines of #comments to describe my rules in more detail and to keep things tidy and clean. However, not the slightest hint of performance degradation at all. I have an i7 ultrabook at the moment, but I have tested MemProtect on old netbooks previously as well.

I am wondering if possibly you are blocking things that should not be blocked, therefore causing performance issues based on unwanted blocking and maybe silencing those rules out and therefore not being able to see what all is being blocked?

Anyway, I will catch up with your questions and reply more later in the day.

 

I just installed MemProtect demo on Win10 pro x64 1809.
It seems to be blocking right, but I am a bit confused about the tray application.
If I use the one located here:
C:\Program Files (x86)\Excubits\MemProtect\Tools\64-bit
Then I get the pretty, new blue shield icon, but it doesn't turn grey when memprotect is stopped.
If I use the one on this path:
C:\Program Files (x86)\Excubits\MemProtect\Tools
Then I get the old-style icon, but it changes color according to state.

 

You must copy-paste the Tray.exe and Admin Tool.exe into the Tools folder, so it can use the .ico files as the icons for the tray icon

There's a readme there for a reason :O

Interestingly enough, both the 32-bit and 64-bit tray/admin tools work fine for me, I use the 64-bit just in case

 

So I copied the 64x Tray.exe and Admin Tool.exe into the Tools folder, but it still shows the old-style icon. No big deal.
Actually, it needs to work that way, because the set of changing color icons are all of the old style.

 

Are you sure you closed the old tray.exe process and then opened the new 64-bit tray.exe (with 64-bit admin tool) from the tools folder itself?

 

I did that.
Tell me, do you get changing colors on the new blue shield icon? Just curious. It's not so important, really.

 

No, I use the icon that looks like the connect four game thingy with 4 dots, the spongebob icon

 

Guys I need help with my configs... I'm starting out with MemProtect and it seems to be a really good, convenient and powerful piece of components

Code:

[#INSTALLMODE]
[#LETHAL]
[LOGGING]
[DEFAULTALLOW]
[#MODULEFILTER]
[WHITELIST]
*explorer.exe>C:\Windows\notepad.exe
*>*
[BLACKLIST]
*ProcessHacker.exe>C:\Windows\notepad.exe
[MODULEWHITELIST]
[MODULEBLACKLIST]
[EOF]

I put that and start the MemProtect driver, but I see no logs in the log file and when I open ProcessHacker I can still modify notepad.exe, What am I missing?

 

There is more than one notepad.exe in the Windows-directory & subfolders.
Try:

Code:

[BLACKLIST]
*ProcessHacker.exe>C:\Windows\*notepad.exe

As soon as you launch notepad.exe, entries should begin to appear in the logfile of Memprotect (C:\Windows\Memprotect.log)

And with [#LETHAL] Memprotect is passive and isn't preventing anything, it is only logging.
You need to use [LETHAL] if you want Memprotect to be active. But in general only do this if you are sure that your rules are working and Memprotect is allowing & blocking as expected.

 

Omgosh! you were right! I must keep close attention to [#LETHAL] and those wildcards ! THANK YOU SO MUCH!

 

You're welcome

 

Hi,

The default ini file's Taskmgr line doesn't work in Win 10 v1809. Can't stop Task Manager from killing notepad. And yes I was running notepad from \Windows. And it was in Lethal mode.