madshi.net

Hello
My problem is that some excluded processes are injected.

- OS : Windows 10 64bit ( 1903 )
- madCodeHook: 4.2.0 or 4.1.3

My code is like as below:

(BOOL) InjectLibraryW(
MyDriverName, // LPCWSTR pDriverName,
MyLibFileName, // LPCWSTR pLibFileName,
ALL_SESSIONS, // DWORD dwSession,
INJECT_SYSTEM_PROCESSES | INJECT_METRO_APPS, // DWORD dwOptions,
NULL, //LPCWSTR pIncludeMask,
L"Runtimebroker.exe|svhost.exe|notepad.exe"); // LPCWSTR pExcludeMask,

// PULONG pExcludePIDs,
// PINJECT_APPROVAL_CALLBACK_ROUTINE callback,
// PVOID callbackContext,
// DWORD dwTimeOut)

Some "RuntimeBroker.exe" processes are not injected, Others "RuntimeBroker.exe" processes are injected.
For example, ( in the attached screenshot )
# of all "RuntimeBroker.exe" processes is 6,
4 "RuntimeBroker.exe" processes are not injected (normal).
2 "RuntimeBroker.exe" processes are injected (abnormal).

Is there any solution about this issue?
Thank you

Hello,

That’s more than likely a mitigation issue requiring Microsoft to be the signer of your DLL or something similar to this. Not all instances will require this so it’s confusing unless you look at the security involved per process, mitigation policy enforcement can be viewed in tools like Process Hacker which is both open source and free. I’ll take a further look myself and let you know.

—Iconic

@Iconic, it's the opposite: These RuntimeBroker.exe processes shouldn't be injected *at all* because they are in the exclude list.

@lovenamu, does this happen on all OSs or just specific ones?

Woops, sorry I missed it in his code. I see it now, yeah that definitely shouldn't be injected then as it's an Exclude param. I was instead focusing on why some system processes allow for injections (processes of the same name) while others don't due to mitigations =] I originally answered from my smart phone with a smaller screen, lesson learned, you'll notice the difference in my signature. I can run some exclusion tests this weekend if needed but will wait for the OP to answer your latest inquiries.

@lovenamu:

Maybe in the meanwhile, until we can test and reproduce your issue, you might want to call GetModuleFileName(NULL, .., .., ..) inside the injected process to retrieve the process name and if it's RuntimeBroker.exe you can return FALSE in DLLMain(), that way your DLL, while still injected despite being excluded, is unloaded immediately without performing anything extra such as setting hooks, subclassing, performing IPC communication etc.

--Iconic

madshi wrote: ↑Fri Oct 29, 2021 9:23 am @lovenamu, does this happen on all OSs or just specific ones?

I have tested only on the win10 x64.
I have not the other OS environment.

iconic wrote: ↑Sat Oct 30, 2021 12:33 am @lovenamu:

Maybe in the meanwhile, until we can test and reproduce your issue, you might want to call GetModuleFileName(NULL, .., .., ..) inside the injected process to retrieve the process name and if it's RuntimeBroker.exe you can return FALSE in DLLMain(), that way your DLL, while still injected despite being excluded, is unloaded immediately without performing anything extra such as setting hooks, subclassing, performing IPC communication etc.

--Iconic

Thank you for your workaround.
I hope this issue will be solved soon.

@lovenamu,

Thanks for checking back in, we will run some tests and see what's possibly going wrong here. At least for now you have a workaround, though. I'll update this thread in the next couple of days. I'll also test with Win 10 x64 as you were running this, both 32-bit and 64-bit DLLs for injection, and have the same exclusion list as your code. Please just give us a couple of days to try and reproduce. Thank you!

--Iconic

Two more questions, @lovenamu:

1)

madCodeHook has 2 different ways to inject dlls:

A. In the moment when you call InjectLibrary, madCodeHook loops through all already running processes and injects every one.
B. The madCodeHook injection driver takes care of automatically injecting into any newly created processes.

Can you please double check if both ways are affected by this problem, or maybe only one of them?

2)

The EXE which calls InjectLibrary, is that a normal application, running with admin rights? Or is it a service?

madshi wrote: ↑Tue Nov 02, 2021 8:45 am 1)
A. In the moment when you call InjectLibrary, madCodeHook loops through all already running processes and injects every one.
B. The madCodeHook injection driver takes care of automatically injecting into any newly created processes.

Can you please double check if both ways are affected by this problem, or maybe only one of them?

"Case-B" is more common problem. "Case-B" happens always.
"Case-A" happens sometimes.

madshi wrote: ↑Tue Nov 02, 2021 8:45 am 2)
The EXE which calls InjectLibrary, is that a normal application, running with admin rights? Or is it a service?

My injector program is a Windows service program.

Thank you

I have found another serious issue.
When using the "pIncludeMask" with "chrome.exe" , the partial injection failure happens always.

- Win 10 x64 environment
- Chrome version: 95.0.4638.54 ( latest version )

> (BOOL) InjectLibraryW(
> MyDriverName, // LPCWSTR pDriverName,
> MyLibFileName, // LPCWSTR pLibFileName,
> ALL_SESSIONS, // DWORD dwSession,
> INJECT_SYSTEM_PROCESSES | INJECT_METRO_APPS, // DWORD dwOptions,
> L"chrome.exe", //LPCWSTR pIncludeMask,
> NULL); // LPCWSTR pExcludeMask,

Please, help me.
Thanks in advance.

What does "the partial injection failure happens always" mean? Can you please explain what happens exactly when you use an include mask of "chrome.exe"?

madshi wrote: ↑Thu Nov 04, 2021 9:12 am What does "the partial injection failure happens always" mean? Can you please explain what happens exactly when you use an include mask of "chrome.exe"?

# of chrome process: 10
# of injected (chrome) process: 5
# of not injected (chrome) process: 5
Thank you.

Does injection into all those chrome processes succeed if you use an empty injection mask?

I just tested my own library since my demo is already setup for both 32-bit and 64-bit DLLs that are signed, I had the same result as you so it's not an MCH issue with the Include param. 10 Chrome processes were spawned and only half (5) were actually injected using my library and indepedently testing. This likely has to do with mitigation restrictions and nothing more. Chrome is a sandboxed process so I am not surprised by this at all. I believe right now there is no issue with the Include mask, but I will look into the Exclude mask tomorrow as promised and try to reproduce your issue.

--Iconic

I tested with Process Hacker, you can double-click those Chrome process instances and under the general tab look at "mitigation policies" I was correct in saying there are more enforcements on certain instances of Chrome. See below please:

Chrome processes that can be injected:

DEP (permanent); ASLR (high entropy); CF Guard

Chrome processes that can NOT be injected:

DEP (permanent); ASLR (high entropy); Win32k system calls disabled; Extension points disabled; CF Guard; Signatures restricted (Microsoft only); Non-system fonts disabled; Images restricted (remote images, low mandatory label images)

This issue is because your DLL is not signed by Microsoft most likely, that's the policy that is very clear to me.

--Iconic