Does anyone know how to exit a program, without the system unloading a dll it is using?

I use a global hook to change the wndproc of another app's window, and the fake WindowProc
is in the dll the hool procedure is in. Is it possible to prevent the system from unloading the dll after
the app exits? Because of course, I want the other app's window to use my fake windowproc
also after I quit, but I don't want an exe running only for this purpose.

Is there a way to do this?
Or does someone have an idea to set another process's window's wndproc some other way?


Every small idea appreciated...

Hi....
Posted on 2003-07-20 03:21:02 by arcticwarfare338
Hi,

If you are using NT/2000/XP use CreateRemoteThread API to load your dll to other processes address space. I can give you more information is this is the case, but if you need your app to work with 9x windowses then I can't help you.

Regards,
Sami
Posted on 2003-07-21 07:58:31 by SamiP
What about allocating some memory and copying the new wndproc to it? The function would stay there after the dll is unloaded.
Posted on 2003-07-22 07:01:58 by Zaesar
Zaesar: Wouldn't the memory never be freed if you do that?
Posted on 2003-07-22 14:16:25 by FearHQ
The memory would be freed when the application exits. Until then its needed because it contains the new wndproc.
Posted on 2003-07-23 08:16:19 by Zaesar
First of all, thanks for the help, guys...

I didn't have time yet to try the shared memory approach, but I suspect it will be freed, when
the app that allocated it exits, I mean, how would the system know that there's a wndproc
in it, that another app is using?

The DLL thing I'm doing now is almost the same, since the WndProc resides in shared memory (DLL),
and when I exit the installer app, before I restore the original wndproc of the other application,
the other app crashes, although it still uses code in shared mem. I guess since the dll's attachment count
dropped to zero, Windows unloaded it without further ado, and didn't check whether an app is using
its code or not ( but then again, how could it check? )

As for the CreateRemoteThread thing bye SamiP, it seems like a good idea, but I can't get it to work.
The other app crashes. Probably at the moment the thread is created, because I get no
feedback from the remote thread.
Here's what I do:
1. OpenProcess to get the Process handle of the poor application to be brutally hacked into....
2. The Thread func is in a DLL, and I wrote a function which only returns the address of the Threadfunc in it,
pass this to CreateRemoteThread, and instanty the other app goes down.

What am I doing wrong?
Posted on 2003-07-23 13:04:44 by arcticwarfare338
I didn't have time yet to try the shared memory approach, but I suspect it will be freed, when
the app that allocated it exits, I mean, how would the system know that there's a wndproc
in it, that another app is using?
I dont think so. The memory is allocated by the dll inside the target process, not by the application that injects the dll. So i think it would be freed when the host process exits. But i've never tryd id.
Posted on 2003-07-24 10:40:34 by Zaesar
arcticwarfare338,

I need some time to make an commented example, but I try to post it atleast in the weekend.

regards, Sami
Posted on 2003-07-24 11:35:52 by SamiP
You don't need to use a DLL. Just use the VirtualAllocEx function to allocate some memory on behalf of the other application and copy your code into it.
Posted on 2003-07-24 12:07:40 by Sephiroth3
Sephiroth3,

Thats true and for simple code thats ok, but for larger projects or if you want to use resources it's not the easyest thing to do. Thats why I prefer dll method. DLL method is not the way to go if you want to hide, a bit, your injected code, but I don't think its the case now.

By far using the CreateRemoteThread API to load your own code to targets address space is the easyest way to go. Attleast when the target is allready running.
Posted on 2003-07-24 15:52:56 by SamiP
The VirtualAllocEx seems a good idea, but how do I copy the windowproc into it, without a DLL and a hook?
I've thought WriteProcessMemory, but it returns ERROR_INVALID_ADDRESS when I pass the address I got
from VirtualAllocEx to it....
Posted on 2003-07-25 05:04:07 by arcticwarfare338
arcticwarfare338, are you on windows 9x or a NT flavour?
Posted on 2003-07-25 05:09:28 by f0dder
strictly NT platform... :)
Posted on 2003-07-25 05:38:56 by arcticwarfare338
Hmm, then VirtualAllocEx ought to work fine - but make sure you have the correct rights to alloc memory and write into the other process - and check error codes on failure.
Posted on 2003-07-25 05:55:05 by f0dder
i just use

ApiHooks (c) EliCZ
http://elicz.cjb.net

and it does what your asking if you use it correctly on both win9x and nt / xp

also i have a friend that did what your trying but i dont have his site but i believe is on this forum somewhere
Posted on 2003-07-25 12:56:53 by devilsclaw
SamiP: Erm, CreateRemoteThread doesn't load any code. It just creates a thread.
Posted on 2003-07-25 19:55:36 by Sephiroth3
Sephiroth3,
Well, I wasn't clear enough CreateRemoteThread makes thread and you can use then LoadLibrary to load your own dll.
Posted on 2003-07-26 08:16:55 by SamiP
yes, i thought that is how it goes, but I still couldn't get CreateRemoteThread to work. Is it possible
that when I get the other process's handle with OpenProcess asking PROCESS_CREATE_THREAD, it
gives me the handle, but it doesn't really have acces right? I told already the other process crashes,
would it crash, if I didn't have the right to create a thread in it, or the CreateRemoteThread function
call would just fail and return zero?
Posted on 2003-07-28 01:16:20 by arcticwarfare338
Sorry to all that this cames so late, but various thing happened in my life that keeped me away from coding.

This is promised example of how to use CreateRemoteThread API. It's not commented as I said before, but the source is pretty simple and I think everyone can understand it atleast with API documentation.

This is only for demonstration purposes, so the twhook.dll must be in c:\twhook.dll or the code must be altered. where tw.exe resides don't matter. Usage is simple, tw.exe takes one parameter and that is targets PID.

SamiP
Posted on 2003-08-14 13:55:47 by SamiP
I almost thought I got forgotten... :) Thanks for the example.
Posted on 2003-08-15 23:30:32 by arcticwarfare338