MemProtect - Support & Discussion

There may be a missing blank line..
Ok, i was too late - it was already mentioned in Post #100
Edit:

There is nothing wrong with the config, but why the BSOD
But now i see you had a similar problem with MemProtect some time ago in the Bouncer-Thread. It seems your system doesn't "like" MemProtect:

This is my layout too. And in Program Files at least Administrator-rights are needed to modify these files. Much better as extracting it into the user-directory where these files can be modified.

 

That is a big question and certainly a legitimate question. Also tricky from a technical standpoint. All of these drivers (NVT ERP included) utilize kernel-mode drivers that intercept API calls deep within the kernel. What makes this even more complicated is that it is very likely that both drivers are intercepting the exact same API call at the exact same time, resulting in some sort of collision/BSOD.

All of Florian's drivers now include support for kernel debugging which can get the more technical users into the nitty gritty details that might be more helpful.

From the Readme with each driver:

Unfortunately that kernel debugging with DbgView is not an area that I am familiar with at all. Florian may likely use that to figure out deeper into the issue.

I know that NVT ERP has a lot of options, so it is possible that one change of a setting within those options may help with this issue, but that is trial and error and may not help in the end. The safest thing, of course, is to avoid security software which intercepts the same API calls, on the same level, at the same time.

Which version of NVT ERP were you experiencing this BSOD with? I may actually try to replicate this later today in a virtual machine because I always like to figure out complicated things. I'll let you know later if I'm able to figure out any workarounds or anything useful for this issue.

 

FWIW, latest ERP version is 3.1_24062015_BUILD1

 

I thinks you can start DbgView from Sysinternal Tools, this show up Debug Messages. You need to set a filter for MemProtect so not too many alerts in DbgView. I tried some time ago, but for me no benefit, I dont understand much of what I see

@Peter2150: OK, maybe too many drivers to protect system at all. NVT ERP and AppGuard, some others? I thinks if you have AppGuard you are pretty well protected, so I wouldnt install and use MemProtect additionaly. AppGuard is also pretty solid.

I can only speak for me personal: I try not to mix too many equal tools together. So If I use NVT I dont use AppGuard, If I use Bouncer I dont use NVT etc. I dont know exactly where all this drivers interact and inject in kernel and-or real mode, so this can end up in trouble if they block each other or interference. It is like with using 2 or 3 AVs, this also causes some problems sometimes.

 

I was thinking (as an example) about protecting explorer.exe in this configuration...

It is easy for me to understand the reason why chrome is blocked from accessing the memory of explorer.exe. And I can say the same about Office products. I also understand the reason for blocking access to KeePass.exe from other processes

But why specifically block KeePass.exe from accessing Explorer.exe and at the same time have [DEFAULTALLOW] ?

I mean, what is the reason for not blocking access to explorer.exe from all processes except some few special processes like Task Manager, AV products etc.?

 

@WildByDesign created a config for protecting some vulnerable applications.
The intention was to only protect these applications and not all others. Therefore [DEFAULTALLOW] was being used
= all applications can access other applications, except applications in the blacklist.
And that's the reason why you can see explorer.exe-rules for only these applications.
4 Protected Apps -- 4 Explorer.exe-rules

 

Thank you for your reply, mood!

What I did not understand in the configuration, was why prevent only the "protected" processes (e.g. KeePass) from writing to explorer.exe but at the same time allow almost all other processes in the system to write to explorer.exe memory.

I mean, I was thinking that the idea to make e.g. KeePass.exe a "protected" process was equal to just prevent other processes from writing to KeePass.exe memory (which I find easy to understand).

So, when using the same logic I'd call preventing other processes from writing to explorer.exe as "making explorer.exe a protected process" - and not "making KeePass.exe a protected process"...

I'm sorry to still disturb you with this; I'd just like to understand the reasoning behind creating "protected processes" by preventing memory access bidirectionally instead of just preventing the memory access inwards...

 

Referring to the good, the bad and the ugly makes it easy to remember/understand

Preventing inward memory access (protecting the good).
This is useful for medium level integrity processes which credentials are misused by exploits and or targeted by malware (e.g. explorer). Protecting programs which handle sensitive information like your password manager, mail and webbrowser (shopping/online banking) are also plausible candidates to protect from the rest of your system.

Preventing outward memory access (caging the bad)
For programs running dynamic content (scripts, macro's, plugin) like webbrowser, media player, office programs and pdf-reader. The documents those programs process contain code, so they can be exploited from the inside. Putting them in a container prevents them infecting the rest of your PC and is a relative easy set and forget form of damage control. Programs which interact with those programs should also be put in a (the same) container (e.g. flash or your password manager).

Preventing bidirectional memory access (isolating the ugly)
When you apply above rules of thumb your email program, webbrowser and password manager automatically become candidates to isolate from the rest of your system.

 

The post above #115 explains it pretty well

 

Thanks for the great parable, Kees! I completely agree with your explanation.

...but why do we categorize KeePass.exe as one of "the ugly" instead of "the good", i.e. what is the "bad" in KeePass.exe that must be caged?

My understanding is that KeePass.exe does not "process documents containing code so that it could be exploited from the inside".... (well, most probably I must be wrong here, which actually seems to be the reason for my confusion originally!).

To end up with this, could you be so kind as to point what exactly is my "blind spot" here? I mean, what is the data processed by KeePass.exe that contains code and makes it possible for KeePass.exe to be exploited from the inside?

 

Keepass processes sensitive information, so it should be protected (the good).

When your browser needs access, you also have to cage Keepass, because you want to close all ways out of the browser.Only when this (my_ assumption is true (browser needing access to Keepass), Keepass requires isolation, which required using the log and granular (trial on errror) refinement of the MemProtect rules (ugly).

So it depends whether browser needs access, when not Keepass is the good, when it requires bidirectional isolation the hassle makes it ugly.

 

I have an issue using MemProtect.
Till today everything worked good but now ..
The windows says that the driver is not Digitally Signed.
When i open the cab file, i see some strange chineese characters.
https://i.stack.imgur.com/UydGn.png
https://i.stack.imgur.com/UydGn.png

What to do ?

Also, on a friend of mine, MemProtect 'lags' the process. We protected a game and everything worked till i day since we started to have 10 fps in the game. Any ideas? Someone bothered with this problems too ?
https://i.stack.imgur.com/UydGn.png

 

are you installed this update?

 

The driver of MemProtect is signed with a SHA2-certificate and the above mentioned update is needed.
If you don't have the update installed, Windows doesn't recognize signed drivers with a SHA2-certificate as correctly signed.

 

How could we know the efficiency about MemProtect ?
Someone had done tests; feedback ?

The default MemProtect.ini is with some lines :

Code:

[LETHAL]
[LOGGING]
[WHITELIST]
*>*
[BLACKLIST]
*taskmgr.exe>*notepad.exe
[EOF]

Indeed, I have a log entry when I kill the "notepad.exe" process by the Task Manager but notepad is ... killed

 

Does the program do what says, namely:

What's the result on the real-life condition vs malwares ?
It serves for something or it's a placebo.