Hooking failure on .net executable

[raashidbhatt]

if hooks = full_hooks; are applied on a .net executable , capemon fails to load . .net Error message pops up .
if hooks are changed to hooks = min_hooks; , it works fine
Sample : ba593b4f4a1ab0b96b2a38e851aed89e

windows 7 sp1, .net 4.0 installed

[kevoreilly]

Thanks for the hash - I'll take a look.

[kevoreilly]

I can't find the sample on vt or bazaar - can you submit to capesandbox.com please?

[swthorn]

Hi!

I found an issue sort of related to this I believe. I was using this sample: https://github.com/PwnDexter/SharpEDRChecker (attached as ZIP file at the bottom of this comment)

By trial-and-error (commenting and uncommenting hooks in the full_hooks definition), I believe I've traced this (or a similar issue) down to the following hook:
HOOK(ntdll, NtProtectVirtualMemory) - https://github.com/kevoreilly/capemon/blob/capemon/hooks.c#L348

When this hook is commented the sample runs fine and prints many things to the console, if its uncommented the sample opens with only a blank console screen and does not appear to execute.

I'm using Windows 10 and I'm on commit ff32e2e. Ubuntu 20.04.02 LTS as the host OS. Note: Only this .NET sample was not working, other .NET samples I have work fine on ff32e2e

It also works fine on capesandbox.com: https://capesandbox.com/analysis/168790 so could be a Windows 10 thing?

If this information helps, great!

SharpEDRChecker.zip

[kevoreilly]

I have confirmed this and removed all extra code from the hook, it still causes the issue. The location of the NtProtectVirtualMemory call is in a ntdll function LdrpCfgProcessLoadConfig which is apparently part of Control Flow Guard. I don't know too much about this but wonder if this is an issue that can be fixed within the monitor or whether it might be inherent to CFG and hooks, with a possible solution being to disable CFG... I'll keep working on it - thanks for the example and info.

[kevoreilly]

It looks like this issue is now fixed - SharpEDRChecker f8dcbc0632b66e21b159a3da95085cd6a22a0b94b8ad40036656aa362afb112f now runs without issue. Not sure which fix in the past few years was the one, but it seems solved.