4

436880927

@Windows_Security MemProtect's DLL blocking abilities is indirect. In user-mode, you need a handle to a process to use generic APIs like NtWriteVirtualMemory/NtMapViewOfSection or a handle to a thread to hijack it.

There are injection methods that can be performed from user-mode that require no handle... shared memory targets.

Furthermore, there are ways to acquire a handle to a process or a thread without explicitly creating or duplicating it yourself.

AVs which have kernel-mode software do not need to dick around with a fancy bypass. They do not have to adhere to MemProtect. If people in the kernel wanted, they can walk the list of registered callbacks to ObRegisterCallbacks... and oh my god... unregister it!

Keep on believing in reviews from others who do not understand the "techno talk", it doesn't mean you're right. I am right and you are wrong, factually.

The fact remains that MemProtect cannot and does not explicitly prevent code injection - if this was the case, I wouldn't be able to inject code with NtWriteVirtualMemory from user-mode with a handle that isn't mine.

Instead of arguing with me or getting your knickers in a twist because I dizz'd your favourite software, read what I am saying and educate yourself. Or smack the report button like everyone else that gets butt-hurt over the truth.
 

Cortex

Level 12
Does anyone remember the original Microsoft AV, well it didn't run in real time it was just a scanner & as I remember wasn't able to update, I think it came with Windows 3.0?/3.11? I ran it run time to time but it never found anything which isn't surprising, it wasn't on Win 95 as again I remember - I've faffed with Defender this last week on this my main PC & actually returned to Norton & HitManPro.Alert It's not for me regardless of how good it now is, (though in my experience over years it had room to improve) just personal opinion though - Maybe I'm getting old (I am) :eek:
 

Andy Ful

Level 49
Verified
Trusted
Content Creator
MemProtect stops DLL-injection, I tested it, so you can say that black is white, but that stays black for me. Same with WD Exploit protection Code Intyegrity Guard a member posted that he could confirm it, so keep on dropping techno talk, but fact remains that all three mechanisms can block DLL-injection.
Memprotect will prevent most DLL injection techniques in the wild. But, both Memprotect and Windows 10 exploit mitigations can be bypassed easily if the attacker can access admin rights.(y)
So, you are right from the practical point of view (so far). But, Opcode is right when saying that AV vendors could bypass browser protection if they wanted to do it (but they probably do not).
 

Windows_Security

Level 23
Verified
Trusted
Content Creator
@Opcode
  1. MemProtect:
    It is easy to test, MemProtect is free, I don't need reviews of others. I downloaded and installed it to check it (have de-installed afterwards, because I use M$ code integrity guard, not a fan-boy either). It has a DLL filtering option now, so maybe you should try it out in practice. BTW it also blocks everything I can check with HitManPro test tool.

  2. Code Integrity Guard
    When I enable it and install an anti-virus or MBAE it blocks the DLL's loading. I can check that with my own eyes (simply with ProcessExplorer). Everyone can reproduce this. Just show me a PoC and I will state your are right.

  3. Protected processes
    Protected processes is designed to prevent side by side infection (link). It would not make sense that when you especially design such a protection mechanism, you would allow third-party software to switch it off and bypass it.

I am aware that stuff always can be bypassed, e.g. protected processes bypass (link), but those loopholes tend to be closed by Microsoft. In science stuff is discovered before it is tested in practice, so I am not saying it can't be done (or you are dead wrong), just don't see it in practice yet. See how easy it is to react politely

On the other side when you can program at C or C++ level, that does not mean you know all the code of the Microsoft OS or have the knowledge of well known white HAT hacker organizations. When you understand what they are doing, does not mean that you can do it yourself or discover the same loop holes. That is why I am asking (politely) for proof: show me the money, put your money where your mouth is.


EDIT: MemProtect logging and blocking loading of DLL's
1565165517964.png
 
Last edited:
4

436880927

Inappropriate Language
Pfftttt... so you want me to stroke you and tell you that everything's going to be alright and that MemProtect can explicitly block code injection when it cannot?

Pathetic.

I am aware that stuff always can be bypassed, e.g. protected processes bypass (link), but those loopholes tend to be closed by Microsoft. So Opcode: see how easy it is to react in a polite way?
If you are already in the kernel, like a good AV will already be, then these mechanisms cannot stop you.

1. Anyone already in the kernel can use DKOM to disable the protected process mechanism and re-enable it after they have performed work. Such has always been the case and Microsoft have never done anything about it because they do not consider it to be a "security issue".

2. MemProtect can be bypassed from user-mode with standard rights generically. It isn't specific to MemProtect. The technique is allowed by Microsoft - they have been aware of it for over a decade and since it doesn't exploit any security features, it is perfectly acceptable.

3. MemProtect's driver uses ObRegisterCallbacks to restrict handle creation or duplication. It does not explicitly block code injection. However, it would be stupid to expect it to block an AV with kernel-mode software from injecting code, because such doesn't even have to try and bypass MemProtect.

So @Windows_Security: are you going to continue dancing like an idiot or listen to what you're being told?
 
4

436880927

There's a lot of very typical security software forum behavior going on: someone doesn't know what they are talking about and has too big of an ego to accept the truth.

Well, it all seems pretty pathetic if you ask me.
 
4

436880927

On the other side when you can program at C or C++ level, that does not mean you know all the code of the Microsoft OS or have the knowledge of well known white hacker organizations. When you understand what they are doing, does not mean that you can do it yourself or discover the same loop holes. That is why I am asking (politely) for proof: show me the money, put your money where your mouth is.


EDIT: MemProtect logging and blocking loading of DLL's
C or C++ has nothing to do with this and neither does "white hacker organizations" (why does your race matter anyway?).

Even if MemProtect is supporting the blocking of DLLs according to the rules configuration with PsSetLoadImageNotifyRoutine/Ex, it still isn't an issue - and it isn't explicit prevention of code injection either because it doesn't just block that. It doesn't change the fact that if someone is at the same privilege level as you, it is a game of cat and mouse.

You might not be aware of it, but blocking "DLL injection" is only half of the solution. What about file-less injection? Oh, and for the record, kernel-mode callbacks like PsSetLoadImageNotifyRoutine/Ex won't stop reflective DLL loading.

I don't need to put my money where my mouth is. I am not going to spend time "putting my money where my mouth is" on a geek security software forum. You are going to have to believe me or disbelieve me. You are more than welcome to hire a consulant and be told I am right or do necessary research and find out that I am right.

Your obsession with MemProtect is concerning to me, but each to their own.
 

Andy Ful

Level 49
Verified
Trusted
Content Creator
I think that further discussion about MemProtect and DLL injections should be continued on the separate thread. It is too specific and too technical for this general thread. The most important information was already posted, and other technical aspects or personal objections will not help (for sure) to understand the main topic.:unsure::emoji_pray:
 
4

436880927

@Andy Ful I recon that you already understand what I have been saying.

Sure, I think MemProtect is crap, but all of that is irrelevant.

All of this started because I mentioned that MemProtect cannot stop others running at the same privilege level - kernel-mode. And I am right.

Sure, there are ways to inject code into another process in user-mode without triggering MemProtect... but it is out of scope to MemProtect because of the design that MemProtect uses. What about targeting shared memory? Yeah, it doesn't cover that one either. Oops!

Generally speaking, MemProtect will work in the real-world. For now.

There doesn't need to be aggro, but I am not the bad guy here. I shouldn't have to explain the same things over and over. It isn't my fault that die hard fans aren't willing to accept simple truths.

If people do not understand the "techno talk" then don't get involved with the discussions. You don't tell people they are wrong when you don't understand them. You educate yourself and return when you understand or stop.

This discussion has turned absolutely bizzarre... and I have gone lightly on people in this thread. On the technical forums - or just go for the Russian ones on the deep web - people get smashed for asking simple questions: now that is rudeness.

Anyway, I will leave it as follows:

1. People at the same privilege level as you can beat you.

2. AVs can inject code into Google Chrome and there is nothing Google can do to indefinitely stop it. This is why they went for the warnings and failed to do what they claimed they would starting with the beginning of 2019.

3. There is more to injecting code than DLL injection. No DLL is required.

4. MemProtect does not explicitly prevent code injection.

Problem solved if people who do not understand stop quoting me with nonsense.
 

Andy Ful

Level 49
Verified
Trusted
Content Creator
@Opcode,
We agree, just try to be more polite. :giggle: I usually like your post until they become too much personal.
Your statements are true from the technical viewpoint, but the real world is sometimes more complicated. For example, Google has other methods to frighten away AV vendors from injecting the code to the web browser. Both parties have to make an agreement for the good of their customers.(y)

Edit.
I understand your objections about MemProtect, but I do not think that it is crap (yet, it would be off-topic discussion here).
 
Last edited:

Handsome Recluse

Level 21
Verified
Insurance: Make Hurricanes, Earthquakes, Tornados, Car Wrecks, Floods etc. the boogieman (which they can be) no matter the statistics and people will buy.
This is ironic since insurance incentivizes shoddy building and probably makes natural disasters even more dangerous.