[Request] DLL Injection Approval Callback

[jgh0721]

Hello, I use madcodehook 4.1.0

currently, my proudct is...

Product Service(EXE, x86) ------(call)--------> Injector-x86, injector-x64 ------(inject)---------> target process ( x86, x64 )

btw, DLL Injection approval callback feature's function called to injector not service exe.

so, I want to set approval callback on service to madshi driver.

Request Feature.
- Start Injection, Stop Injection on product service, seprately with injector
- register / unregister dll approval callback on product service, seprately with injector

sorry my english,...

[iconic]

You should be able to use SendIpcMessage() with the "answer" parameter filled from the DLL injector inside your DLL injection approval callback. Your service just has to call CreateIpcQueue() and will host the IPC channel for approval from the injector. Haven't personally used the approval callback yet myself but it should allow you to work this way from what I've discerned from the documentation? Basically, the child process (injector) just asks the parent (service) if a DLL load is allowed, like any other IPC operation example in existence which allows for a returned response. Any control commands can be sent to the service, you just need to include them in the IPC callback within the service and have your injector contact the service process.

http://help.madshi.net/DllInjecting.htm ... ackRoutine

--Iconic

[jgh0721]

If so, always three processes staying on pc. service, injector-x86, injector-x64...

so, i want to change work flow.

before:

service ---------> injector ( immediately injection )

after:

service --------> injector ( load driver, set injection info, not start injection )
service -> set dll approval callback
service -> start injection
service <--- driver approval callback

[madshi]

Sorry for the late reply.

Hmmmm... Doing this with IPC would be possible, but I can't really recommend it, because Microsoft already strongly advises against letting driver land wait on a user land callback. So the whole concept of "DLL injection approval callback" is already against the rules to some extent. Now involving even 2 different user processes, which wait on each other, to delay the driver, doesn't sound like a good concept. We should try our best to keep the overhead of the approval callback as small as possible.

@jgh0721, why does your service not do the injection itself? Why do you start a secondary injector tool?

[jgh0721]

thanks reply.

because of do not direct injection in service, my service is x86(32bit) process. but, i need to control x86, x64 process(and dll) both.
so, i decided that i make injector( x86, x64 both ) and i use it.
or i make service x86 and service x64. very unhappy. besides, my clients dont like many process consist of product.

finally, i want,

driver control -> service ( driver start, stop, dll approval callback, and etc.. )
dll injection -> injector

[madshi]

I understand your wish, it's just that you're the first (and only) user asking for this, and it would be quite a bit of extra work. So I'm not overly enthusiastic about adding this feature.

Would it be very hard to make your service 64bit capable?

[jgh0721]

Thanks for reply.

hmm,... Even if I make the service 64-bit version, I still need an injector because I need to control both 32-bit and 64-bit processes( and dll ).

for example.

32bit os
service( x86 ) : injecting x86 process, receiving ipc message from x86 dll

64bit os
service( x64 ) : injecting x64 process, receiving ipc message from x64 dll, and ipc message from injector-x86,
injector-x86 : injecting x86 process, receiving ipc message from x86 dll, and send/receive ipc message to service

-- OR

64bit os
service(x86) : injecting x86 process, receiving ipc message from x86 dll
service(x64) : injecting x64 process, receiving ipc message from x64 dll

but, currently service process has network connection to server, dbms connection, and so on. so i need information exchange between service.

sorry for such a request.

[madshi]

Actually, if your service is 64bit, it can inject into both 64bit and 32bit processes, and it can receive IPC messages from both 64bit and 32bit processes. Also, a 32bit service can receive IPC messages from both 64bit and 32bit processes. The only limitation is that a 32bit service cannot inject into 64bit processes, because Microsoft artificially blocked some APIs from working in that situation.

[jgh0721]

sorry for late reply...

first, for a while, i attempt to build 64bit service... but, i coudln't make because of using custom qt framework. - i using custom made qt framework 4.8.7 ( backport from qt 5.x )
code : https://gitlab.com/JungGyuHo/QtForWin

second, my company's auto update system don't support seperate installer for os configuration( x86, x64 )

last, Company customers (mainly financial and other security-conscious companies) do not like the installer to include files that are not installed on their PCs.
south korea's IT is very old..

[madshi]

I understand the problem. Unfortunately you're the only user asking for this specific feature, and it would cost me maybe 1-2 days to implement (and test etc). Please understand that developing time consuming special features for just one user doesn't really make too much sense for me, from an economical point of view. Maybe you have a good idea how I can help you without spending so much time on it?

[iconic]

@jgh0721

I'd bite the bullet and write a small x64 service (not using any Qt anything) that is only responsible for injecting and receiving DLL injection approvals, it can do the injection into both 32/64 bit targets alone without any further assistance from other remote processes. Even if it means your x86 service and this skeleton x64 service are running concurrently it's a much lower price to pay as opposed to what you're currently doing. Besides, you've already created a lot more work for yourself by having a 32-bit service on an x64 environment communicating with separate 32-bit and 64-bit injectors, which would be more processes than needed here even given your dilemma.

--Iconic