|
|
"CopyFunction" copies (and relocates) the complete function "func" from the current process to the specified process. For that purpose a new buffer is allocated in the context of the destination process. The result value is the entry point of the copied function in the context of the destination process.
If you set the "processHandle" parameter to zero, the function is copied to shared memory in 9x/ME based systems, respectively to another location in our own process in NT based systems.
Please note that copying a function into another process makes sense only if the function can be completely relocated. That means, the code must not contain jumps/calls to unknown targets. If it does, "CopyFunction" fails and returns "nil" - except if you've set "acceptUnknownTargets" to true. This can make sense if the copied function calls e.g. methods of a COM object, because such calls can not be tracked down, so they're unknown. Nevertheless the function may be fully relocated in such a case. Known targets are all functions, that are exported by a DLL.
|
If you don't need the copied function anymore, please don't forget to free the buffer (that was allocated for the function) with FreeMemEx. Enter the buffer you get from the "buffer" parameter of "CopyFunction". Don't enter the result value of "CopyFunction". There's a difference between the function buffer and the function entry point. Often they are the same, but not always.
Now you might wonder, what the purpose of "CopyFunction" is. Well, there are even two good purposes. First of all: For system wide API hooks the package madCodeHook needs to copy functions to shared memory. And next: You can use "CopyFunction" together with madRemote.CreateRemoteThread to easily execute a function in the context of another process (see also the "RemoteCmdLine" Example).