Im trying to hook the ID3D12GraphicsCommandList::CopyTextureRegion method with MinHook but the problem is that the method is inside ID3D12GraphicsCommandList which makes it hard to hook.
Here is my current approach which unfortunatley is 0
// not working, CopyTextureRegionHook is 0
auto CopyTextureRegionHook = GetProcAddress(GetModuleHandleA("d3d12.dll"), "CopyTextureRegion");
MH_CreateHook(reinterpret_cast<void**>(CopyTextureRegionHook), &HK_CopyTextureRegion, reinterpret_cast<void**>(&oCopyTextureRegion));
MH_EnableHook(CopyTextureRegionHook);
Hooking methods like D3D12CreateDevice, D3D12CoreRegisterLayers.. work because they are not in a interface like ID3D12GraphicsCommandList
How would I properly hook CopyTextureRegion?
Because you're dealing with an interface, you won't be able to hook the function directly in memory since it's dependent on the pointer to the interface. In which case you have to utilize a technique called VMT(Virtual Method Table) hooking. In order to achieve this, you'll need to be able to retrieve the pointer to the interface in memory, then locate the virtual method table index(offset) of the function pointer. Which then you'll have to overwrite with your own function address. Your hooked function will have to comply with the calling convention of the original.
Related
I am currently creating my own GUI-Library based on SFML.
At the moment i am working on a Button. So when creating a button you also have to specify a callback which is a function, executed on the button click.
Now, I'm answering me what the disadvantages are of using just a pointer to a function as a button-callback, because I don't know any popular GUI-Library doing it so simply, too.
If the callback function is a long process, I would execute it in a new thread, but i'm not sure about that in the moment.
So, what would be reasons, not to use such simple solution and especially, what would be a better way?
It's a tricky problem!
Function pointers are simple to implement on the sender side, but they are difficult to use on the receiver side because they they don't have any context.
One issue is that a function pointer cannot point to a member function. That's why you often see (C-style) frameworks pass an arbitrary void *userData to their callbacks, so you can cast your this pointer and retrieve it in that way. This still needs you to write a static wrapper function to cast the pointer back and call the member function.
A more modern solution would be to use std::function. This can contain a regular function pointer, a member function pointer, but also a lambda or a functor.
However, when you add context like this (or in some other way), you quickly run into difficulties with lifetimes. When the receiving class is destroyed before the sender, what is supposed to happen? If you don't do anything, this situation will result in undefined behaviour. A solution is to track on the receiver side to which events the receiver is subscribed, and unbind them before the receiver is destroyed. And this needs to be done in both directions: when the sender is destroyed, it also needs to notify the receiver that it should forget about the sender, otherwise the receiver would later try to unbind an event that no longer exists.
And I haven't even begun to think about multithreading yet...
There are libraries that solve these problems in various ways, for example eventpp (just found through a web search, this is not an endorsement).
Another one to mention would be the Qt toolkit, which went so far as to write their own small signals and slots extension to the C++ language (implemented as a code generator and a pile of macros) to solve this problem in a very ergonomical way.
what the disadvantages are of using just a pointer to a function as a button-callback
Passing some context argument to that function would come handy.
I mean, the UI may have a lot of buttons performing the same action on various objects. Think maybe of "send message" button next to each nick in a friend list.
So you may want your buttom to pass some context arguments to the call.
But since we're talking C++, this'd better be abstracted as
struct IButtonAction
{
virtual void OnAttached() = 0;
virtual void OnDetached() = 0;
virtual void OnClick() = 0;
};
And let the client code implement this interface storing whichever Arg1, Arg2, etc in each instance object.
The button class would call OnAttached/OnDetached when it begins/ends using the pointer to an instance of this callback interface. These calls must be paired. Client implementation of these methods may perform lifetime management and synchronization with OnClick, if required.
OnClick method performs the action.
I don't think the button should bother with threads. It's the responsibility of the client code to decide whether to spawn a thread for a lengthy action.
I wanted to build some sort of API monitor by hooking all ntdll functions using Detours API. Each hooked function will call the original implementation and than
add notice for this call inside std base data structure.
However, I encountered a scenario of recursive hooking where my hooked function is indirectly calling itself.
Therefore, I tried to use the Tls memory to set a bit per thread that indicate that current function is called from hooked function, so avoid calling the hook again (execute the original function only).
But my recursive hook guard also uses some calls for memory allocation function like NtAllocateVirtualMemory, and therefore I'm currently avoid hooking those functions.
Perhaps anybody has encountered a similar issue and implemented hook reentrancy guard in a way that doesn't triggered any memory allocation function (which might be impossible since even if you call a new function and your stack
memory is insufficient, it should allocate more memory).
thanks
Generally, whenever we want to wrap a Window/Thread in a C++ object, we do so by passing the this pointer via SetWindowLong/GetWindowLong or SetProp/GetProp for a Window, and as lpParameter for CreateThread/etc.
My question is specific to Hooks. What is the elegant approach to pass the 'this' pointer to SetWindowsHookEx's callback procedures, or in other words How to wrap a hook's callback procedure ?
Since SetWindowsHookEx does not accept any UserData argument, I don't see much options apart from using un-encapsulated i.e. global/static/TLS data.
You are expected to have just one instance of a given hook, so global data is not an issue.
If you are developing a library allowing multiple hook instances that can be dynamically added or removed, do not add multiple hooks at the OS level. Instead, add a library-level hook procedure that walks the list of hook instances. Since you maintain this list, you can track whatever "user data" alongside each entry you want.
The 'most elegant approach' is to use a thunk. It's a small piece of code generated at runtime that holds your this pointer. This is the approach that ATL uses even for regular windows.
See
What is a thunk?
How to generate the code for thunks
C++ WinAPI Wrapper Object using thunks (x32 and x64)
So I've been playing around with C++ and injecting DLLs, fairly new to this but learning fairly quickly. I'm trying to hook EndScene and just cannot get it working. I've tried using a pattern scan to find and then hook it, I've tried creating a dummy d3d device and finding the EndScene through its VTable. Each time it fails i get an Access Violation so I can only assume I have the wrong address for the function or maybe I'm missing something completely. I have tried a lot of different ways but due to limited knowledge need a little more help.
DWORD dEndScene = 0x10066D50;
HMODULE hBaseAddress = GetModuleHandle("d3d9.dll");
BYTE* pEndFunction = (BYTE*)reinterpret_cast<uintptr_t>(hBaseAddress);
pEndFunction = pEndFunction + dEndScene;
fEndScene = (oEndScene)DetourFunction(pEndFunction, (PBYTE)EndScene);
The vtable is likely write protected. You can use VirtualProtect.
And some slightly different approaches:
Is it possible to replace Direct3DCreate9(Ex) before its created? Then you just make proxy objects for the interfaces you want, which can then just delegate normally, do stuff before/after, or do something different entirely.
Or if you can get the IDirect3DDevice9 instance pointer, by getting then editing the vtable it references (again VirtualProtect, but avoids needing to know where the function lives in advance, which might change in various cases).
I have a dll which requires me to set a callback function for it (actually it's a camera sdk and it will callback my function when it receives a picture).
I want to have multiple (user input) cameras but I can't.
Since I should make unknown number of callback functions.
The easy way is to make a class (camera) which have a function for its callback.
but I cannot pass the pointer of member of the class to the dll (it only accept (void)(image*))
Any possible solution?
Try creating a global list of all the function objects to be called, then add a single function that calls each of the callbacks with the required data. Something like this:
std::vector<ICallback*> g_callbacks;
void callback_wrapper( image * image )
{
for(unsigned int i=0; i<g_callbacks.size(); ++i)
{
g_callbacks[i]->process( image );
}
}
Then you set the callback used by the SDK to the callback_wrapper function.
Depending on the OS, you may be able to create dynamic functions for each callback object. I've done exactly that for callbacks from legacy code which didn't have any facility to pass a value to the callback.
Create a small prototype forwarding function with the type the library expects which then calls the real callback function with an easily seen extra parameter
void Call01020304 () {
CallWithValue(0x01020304);
}
Compile it and look at the hex for the assembly. It should be obvious where the constant is.
You then use VirtualAlloc + PAGE_EXECUTE_READWRITE or mmap + PROT_EXEC to allocate some memory which can be executed. Allocation is usually in 4K blocks, so create a class to manage the functions, as you will be allocating enough for many in one go.
When you need a new callback function with a unique value, copy the bytes of the prototype with appropriately changed value into your executable memory, and return the pointer to it as the callback function.
Does camera SDK support multiple cameras connection? If not, you need to talk with SDK provider.
If SDK supports multiple connection, it must provide the way to recognize the camera in callback function. But actual answer is in SDK itself. What is the "image" type, maybe it contains camera ID? Maybe camera ID is supplied when a client code makes callback subscription? Something like this:
void Callback0(image*);
void Callback1(image*);
SubscribeImageCallback(0, Callback0); // camera 0
SubscribeImageCallback(1, Callback1); // camera 1
Actual answer to your question depends on the camera SDK interface.