View Full Version : Advanced address context question!
Nad_Af
March 17th, 2004, 00:58
Currently, I am writing a DLL but I have a problem.
Suppose that you have two running processes A and B, and you know that in process B the virtual address of a function is XXX, and of a varibale is YYY.
How can you call the function and modify the varible from process A?
What is the first thing to do?
I know I need to use WriteProcessMemory, but how???
Solomon
March 17th, 2004, 02:12
You can't call that function directly from A.
In process A, you have to generate some push/call instructions and write them to process B, then use CreateRemoteThread to trigger your call instructions. or you can use Debug API to attach to process B, then use SetThreadContext to move EIP to your code. I think the 2nd way is difficult to implement.
Quote:
[Originally Posted by Nad_Af]Currently, I am writing a DLL but I have a problem.
Suppose that you have two running processes A and B, and you know that in process B the virtual address of a function is XXX, and of a varibale is YYY.
How can you call the function and modify the varible from process A?
What is the first thing to do?
I know I need to use WriteProcessMemory, but how??? |
dELTA
March 17th, 2004, 09:46
Nad_Af, just to make sure we understand what you mean:
When you say "call the function from process A", do you mean "make process A cause it to be executed in the context of process B" (like Solomon understood it), or do you, for some crazy reason, want to execute the function that is present in the memoryspace of process B, inside the context of process A?
Also, you are talking about some DLL? Is this DLL loaded in both processes? In that case, you can implement some interprocess communication method into the DLL, and in this way more easily accomplish what you want, without any APIs for manipulating memory/threads/context for other processes.
Nad_Af
March 17th, 2004, 17:59
What i mean is that I want to move the execution from PROCESS A, to the function in PROCESS B

. But the DLL is not loaded in the address context of B.
Can I switch the context from A to B?
nikolatesla20
March 17th, 2004, 18:20
Well, you can switch the context in a couple of ways:
1. Write a kernel driver that calls KeAttach and KeAttach. This forces a context switch. However, this will not put the params you want into the function, you'd have to pass those some other way.
2. Create a debugger process that debugs process B, and then you can easily freeze process B at the function, and write the parameters to the stack, and then let the function execute. Catch it again when the function goes to return. NOt too bad. However, if "your" code is in a DLL in process A you won't be able to do debugger because debug requires process A to actually be a debugger.
3. Grab a local copy of all the code of the function for your own use. Takes a little more work since you need to know where the function starts, stops, what other functions it calls, any global variables, etc. Not too practical I guess.
4. If you simply want to call a function and you know that process B won't crash, YOu don't need to be a debugger, you can simply call SuspendThread, and then GetThreadContext(), and then you can actually set the EIP with SetThreadContext too if you want, to force it to go to the function. But this will most likely crash after it's run the function once, so a full debugger is usually a better option, since you also can set a breakpoint to trigger the function call/return. Using only ThreadContext functions you won't necessarily know if you are at a point that is safe.
-nt20
Nad_Af
March 18th, 2004, 16:54
I will tell you the story.
I have made a DLL that captures mouse messages, and when it encounters any, it calls the procedure sotred in Process A, the address of this procedure is passed to the DLL via a function exported. Because the DLL is loaded in the linear space of the process that loads it (Process A), it works fine; however, it doesn't work for messages that don't belong to Process A.
What Can I do to execute it safely?
dELTA
March 18th, 2004, 20:14
So, you are capturing the mouse messages with a SetCapture hook then I presume? I think the clearly best and cleanest solution would be to capture the mouse messages with a global hook instead. Then the dll would be automatically injected into each process, and you could always execute the procedure at the address you are referring to (whatever address now this might be that you are talking about?) directly from the hook procedure, since you will always be in the right context when the hook is activated.
Nad_Af
March 20th, 2004, 01:52
I already have set it using SetWindowsHookEx(), but the global function when executes doesn't run the procedure I passed to the DLL from the process (application), I have put some code to call that procedure from within the Global Hook function.
for example, I called the DLL from Visual Basic, I sent the DLL a function address within my VB app, but when the mouse pointer gets out the window of my VB app. the function is not called at all!
can you help??
dELTA
March 20th, 2004, 09:30
Exactly what is this function that your hook function tries to call inside each application? Where does it get the address from? Please explain in more details what your goal is with this hook, and how you have implemented it, for us to be able to help.
Also, dealing with function pointers inside VB seems like trouble to begin with.

sna
March 20th, 2004, 10:51
The custom callback function has to reside in a DLL, too. Can't you put it inside the same DLL as the hook procedure?
Quote:
[Originally Posted by nikolatesla20]
4. If you simply want to call a function and you know that process B won't crash, YOu don't need to be a debugger, you can simply call SuspendThread, and then GetThreadContext(), and then you can actually set the EIP with SetThreadContext too if you want, to force it to go to the function. But this will most likely crash after it's run the function once, so a full debugger is usually a better option, since you also can set a breakpoint to trigger the function call/return. Using only ThreadContext functions you won't necessarily know if you are at a point that is safe. |
The problem with this approach is that OpenThread() is not implemented on Win95, 98, NT 4.
Another family of techniques, which are not applicable in this case, is the "shatter attacks":
http://www.idefense.com/idpapers/Shatter_Redux.pdf
I say not applicable because a randomly picked system may or may not be receptive to this kind of attack;
And from the sounds of it this is going in production code?
Regards, sna
Nad_Af
March 21st, 2004, 16:19
The hook function catches WM_LBUTTONDOWN and then tries to call the VB function by its address (which is passed to DLL).
Quote:
[Originally Posted by dELTA]Exactly what is this function that your hook function tries to call inside each application? Where does it get the address from? Please explain in more details what your goal is with this hook, and how you have implemented it, for us to be able to help.
Also, dealing with function pointers inside VB seems like trouble to begin with.  |
dELTA
March 22nd, 2004, 09:13
You still haven't told us what this function is that you are trying to call, and more importantly, how its address is "passed to the dll"?
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.