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....
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....
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
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
What about allocating some memory and copying the new wndproc to it? The function would stay there after the dll is unloaded.
Zaesar: Wouldn't the memory never be freed if you do that?
The memory would be freed when the application exits. Until then its needed because it contains the new wndproc.
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?
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?
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.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?
arcticwarfare338,
I need some time to make an commented example, but I try to post it atleast in the weekend.
regards, Sami
I need some time to make an commented example, but I try to post it atleast in the weekend.
regards, Sami
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.
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.
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.
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....
I've thought WriteProcessMemory, but it returns ERROR_INVALID_ADDRESS when I pass the address I got
from VirtualAllocEx to it....
arcticwarfare338, are you on windows 9x or a NT flavour?
strictly NT platform... :)
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.
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
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
SamiP: Erm, CreateRemoteThread doesn't load any code. It just creates a thread.
Sephiroth3,
Well, I wasn't clear enough CreateRemoteThread makes thread and you can use then LoadLibrary to load your own dll.
Well, I wasn't clear enough CreateRemoteThread makes thread and you can use then LoadLibrary to load your own dll.
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?
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?
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
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
I almost thought I got forgotten... :) Thanks for the example.