CreateIpcQueue: control dll uninjection inside a dll

[xrfang]

Hi All,

I am new to madCodeHook yet feel it extremely easy to use and works on all windows (important to me). Thanks Mathais...

Now having a problem: I want to create an IPC Queue inside the DLL. I have 2 purposes:

1) The main program which injected the DLL maybe closed by the user (according to my design), after that, there is no way to contact the DLL (except run the main program again). I would like to send an IPC message to the DLL to let it unload itself.

If this does not work, I have some alternatives, such as use a service helper, or prevent the program from being closed before the hook is unloaded etc. So this may not be a problem... However,

2) I want to send some data to the DLL. For example, I am hooking the CreateProcess API. Inside of the DLL, there is a list of "banned programs", the main program needs to update the list of banned applications. I think using IPC message is the easiest and preferred way to do this... BTW, this is to be used in a parental control application, not a virus

Thanks for any help!

Shannon

[nildo]

1) The main program which injected the DLL maybe closed by the user (according to my design), after that, there is no way to contact the DLL (except run the main program again). I would like to send an IPC message to the DLL to let it unload itself.

Just use UninjectLibrary at the OnCloseQuery of your form. Something like this:

Code: Select all

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
   CanClose := UninjectLibrary( TheProcess, 'yourdll.DLL' );
end;

2) I want to send some data to the DLL. For example, I am hooking the CreateProcess API. Inside of the DLL, there is a list of "banned programs", the main program needs to update the list of banned applications. I think using IPC message is the easiest and preferred way to do this... BTW, this is to be used in a parental control application, not a virus

The point is that your list should be at your EXE. Then when hooking CreateProcessA/W APIs, you can use IPC to contact your EXE, then your EXE see if the application is not banned, and then send an anwser back to the DLL, to allow or not allow the application for being executed.

Hope this information help you (sorry for the bad english)

[xrfang]

Hi Nildo,

I think you misunderstood...

1) I do NOT have a form. What I want to do is put the uninjectlibrary stuff inside of the DLL (i.e. NOT main program), is this possible?

2) I don't think consulting the main exe for the black list is a good idea. Because this might slow down the execution. Did you do that before? is it a good idea to wait for callback result inside of an api call?

Thanks,
Shannon

1) The main program which injected the DLL maybe closed by the user (according to my design), after that, there is no way to contact the DLL (except run the main program again). I would like to send an IPC message to the DLL to let it unload itself.

Just use UninjectLibrary at the OnCloseQuery of your form. Something like this:

Code: Select all

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
   CanClose := UninjectLibrary( TheProcess, 'yourdll.DLL' );
end;

2) I want to send some data to the DLL. For example, I am hooking the CreateProcess API. Inside of the DLL, there is a list of "banned programs", the main program needs to update the list of banned applications. I think using IPC message is the easiest and preferred way to do this... BTW, this is to be used in a parental control application, not a virus

The point is that your list should be at your EXE. Then when hooking CreateProcessA/W APIs, you can use IPC to contact your EXE, then your EXE see if the application is not banned, and then send an anwser back to the DLL, to allow or not allow the application for being executed.

Hope this information help you (sorry for the bad english)

[dcsoft]

1) I do NOT have a form. What I want to do is put the uninjectlibrary stuff inside of the DLL (i.e. NOT main program), is this possible?

I think what Nildo means is that whatever called InjectLibrary() should be what calls UninjectLibrary(). This should be your main .exe, correct? The DLL should not uninject itself. I don't think it's even possible, i.e. the DLL cannot call UninjectLibrary() of itself.

2) I don't think consulting the main exe for the black list is a good idea. Because this might slow down the execution. Did you do that before? is it a good idea to wait for callback result inside of an api call?

The IPC mechanism isn't the fastest in the world, but is fast enough. Using it when a CreateProcess() occurs should be fine. After all, the time it takes to create the process will be at least an order of magnitude more than even the slowest IPC mechanism.

But one reliable way of sharing data between the .exe and the .dll that I have used is shared memory within the DLL. The .exe can LoadLibrary() or statically link to the .dll and put the black list in the shared memory within the DLL. Since the memory is shared, all instances of the DLL (within each of the hooked processes) can access the black list locally (and not require any remote communication; this is extremely fast.

-- David

[xrfang]

The IPC mechanism isn't the fastest in the world, but is fast enough. Using it when a CreateProcess() occurs should be fine. After all, the time it takes to create the process will be at least an order of magnitude more than even the slowest IPC mechanism.

But what I try to avoid is that I have to keep my monitor program running. I would like the DLL to run on their own. The monitor program run only on demand, for example, to check hook status, change settings, or stop the hook.

Shannon

[dcsoft]

But what I try to avoid is that I have to keep my monitor program running. I would like the DLL to run on their own. The monitor program run only on demand, for example, to check hook status, change settings, or stop the hook.

Sure, in that case, save the blacklist in the the shared memory of the .dll.

-- David

[madshi]

xrfang, I guess you're injecting your dll into all processes system wide, not only in one specific process? In that case you need to understand that there is not "the dll", but there are copies of your dll loaded into each and every process. So each dll would have to set up an IPC queue and since there can only exist one IPC with the same name, each dll would need to use a different IPC name. The exe would then need to contact each dll copy and send each one their own IPC message. You see, this is not a good solution.

Instead I'd go with dcsoft's suggestion of putting the blacklist into shared memory. Personally I'd not use a shared dll section, instead I'd use CreateFileMapping/OpenFileMapping + MapViewOfFile to set up a shared buffer. The application would fill this buffer, the dlls can then open and read it at any time. If all dlls keep a reference of this buffer open, it doesn't matter when the application is closed. The buffer will survive, as long as someone still has a handle open to it.

[dcsoft]

Personally I'd not use a shared dll section, instead I'd use CreateFileMapping/OpenFileMapping + MapViewOfFile to set up a shared buffer.

Yes, that would be a better way to go. The shared dll section has the disadvantage that the memory needs to be pre-allocated, so it is a fixed length buffer. The shared memory file can be of any length. Plus, it's more natural to access the shared memory from various processes instead of LoadLibrary() of the .dll.

Cheers,
David