Hi.
One of products in my company use madCodeHook to hook all processes (system wide).
I installed the product on Windows Server 2022 which has some docker containers running.
Processes running on the host are hooked well but not working for those running in containers.
Is it possible to hook procceses in containers? Have you tried?
Do you have any plan for this?
Thanks.
Hooking processes running in docker containers
Re: Hooking processes running in docker containers
Hello,
Here's the quick explanation of Docker injection, we've updated MCH to support injection for such cases to work with Docker but it's only currently for usermode last I checked (InjectLibrary(non-system-driver-flag-or-processhandle)). Basically, the older versions of MCH relied on the fact that some system DLL components held the exact same base address system-wide, this is true with DLLs such as ntdll.dll, kernel32.dll, user32.dll etc. (per process bitness) but since Docker is a WSL-based virtual container it loads whatever version of say kernel32.dll that it wants and will not match the native host DLL in memory base address wise, as well as file location wise (they both differ from the native host machine). We incorporated dynamic lookups for needed APIs when you are injecting in usermode but the main caveat here, and the most limiting, is that Docker requires the DLL injected to be in its own ecosystem. For example, your DLL would need to be present in the Docker area, say C:\ProgramData\Docker\windowsfilter\2259d266241bbc793ee098234d120f595f20b0de66aaeb5690282a2842528c10\Files\Windows\System32 on my system during tests from 1.5 years ago, otherwise it will not be loaded. Hooking isn't the problem, it's DLL placement and system DLL base address differences.
So, in short, MCH does not officially support Docker at the kernel level IIRC but *should* allow for injection in usermode as long as Docker can see your DLL in its own respective container. It's partially supported currently (but limited based on Docker's requirement of DLL placement needs) but unfortunately won't work for system-wide injection (using the driver) last I knew, which is your requirement based on your question.
--Iconic
Here's the quick explanation of Docker injection, we've updated MCH to support injection for such cases to work with Docker but it's only currently for usermode last I checked (InjectLibrary(non-system-driver-flag-or-processhandle)). Basically, the older versions of MCH relied on the fact that some system DLL components held the exact same base address system-wide, this is true with DLLs such as ntdll.dll, kernel32.dll, user32.dll etc. (per process bitness) but since Docker is a WSL-based virtual container it loads whatever version of say kernel32.dll that it wants and will not match the native host DLL in memory base address wise, as well as file location wise (they both differ from the native host machine). We incorporated dynamic lookups for needed APIs when you are injecting in usermode but the main caveat here, and the most limiting, is that Docker requires the DLL injected to be in its own ecosystem. For example, your DLL would need to be present in the Docker area, say C:\ProgramData\Docker\windowsfilter\2259d266241bbc793ee098234d120f595f20b0de66aaeb5690282a2842528c10\Files\Windows\System32 on my system during tests from 1.5 years ago, otherwise it will not be loaded. Hooking isn't the problem, it's DLL placement and system DLL base address differences.
So, in short, MCH does not officially support Docker at the kernel level IIRC but *should* allow for injection in usermode as long as Docker can see your DLL in its own respective container. It's partially supported currently (but limited based on Docker's requirement of DLL placement needs) but unfortunately won't work for system-wide injection (using the driver) last I knew, which is your requirement based on your question.
--Iconic