Home › Forum › Programming › Game Development › DirectX/D3D Development › Question D3D physical hook - any thoughts?
Question D3D physical hook - any thoughts?
Question D3D physical hook - any thoughts?
First of all, sry if i posted in the incorrect section, but i didn't found any "D3D hooks" or "GRAPI substitution" sub-forum, so posting it here...
I am not a PRO, but have a lot of programming experience and i'm pretty familiar with D3D hooking, i've coded my first wallhack (for Warframe) like 3 years ago.
So it's not about D3D coding itself, and not 'bout hooking some graphic rendering API, it's more about overall API substitution methods...
A small intro: when i decided to make a bot for some game, after gathering information i've found that there r few bots available already (free or paid), but all of them had reports of being bannable, so i've started to think - what other options we have to substitute renderer except dll-injection or system-hooks. And i've realized that we don't rly need to inject any code or manipulate process memory to change jump/call addresses - we can just replace the renderer itself with our own wrapper. I still didn't tried to actually do that, but atm i see no reasons why it couldn't be done (yeah, obv. it will add at least 1 cp-instruction to every exported routine and assuming thousands of calls inside every frame such wrapper-library could cause visible fps-drop, but hey, it's not like the game should work on old 1.3 GHz Celeron on S370 MB with integrated GPU anyways =)
So by "physical hook" i mean replacement of the library file inside the actual file-system (not memory) with a wrapper-library. But i still not sure how it could be done in "undetectable" way... I can think of at least two problems: file checks (size, hash (md5, crc32) etc.) and library lists checking (cuz wrapper will call original dll anyways). As to first problem - i still not sure what could be done to passby that, but on other hand such defense seems quite unrealistic to me (there r too much different versions of dx libs). And as to second problem it could be passed via memory mapping - wrapper could load the original dll inside it's own memory page space, so original version willn't be listed in the dll-list.
Has anybody tried to do such dx-substitution? Or maybe u see something that i missed? Or u know better (undetectable) way to intercept API calls? I'll appreciate any constructive opinions on that topic...
I am not a PRO, but have a lot of programming experience and i'm pretty familiar with D3D hooking, i've coded my first wallhack (for Warframe) like 3 years ago.
So it's not about D3D coding itself, and not 'bout hooking some graphic rendering API, it's more about overall API substitution methods...
A small intro: when i decided to make a bot for some game, after gathering information i've found that there r few bots available already (free or paid), but all of them had reports of being bannable, so i've started to think - what other options we have to substitute renderer except dll-injection or system-hooks. And i've realized that we don't rly need to inject any code or manipulate process memory to change jump/call addresses - we can just replace the renderer itself with our own wrapper. I still didn't tried to actually do that, but atm i see no reasons why it couldn't be done (yeah, obv. it will add at least 1 cp-instruction to every exported routine and assuming thousands of calls inside every frame such wrapper-library could cause visible fps-drop, but hey, it's not like the game should work on old 1.3 GHz Celeron on S370 MB with integrated GPU anyways =)
So by "physical hook" i mean replacement of the library file inside the actual file-system (not memory) with a wrapper-library. But i still not sure how it could be done in "undetectable" way... I can think of at least two problems: file checks (size, hash (md5, crc32) etc.) and library lists checking (cuz wrapper will call original dll anyways). As to first problem - i still not sure what could be done to passby that, but on other hand such defense seems quite unrealistic to me (there r too much different versions of dx libs). And as to second problem it could be passed via memory mapping - wrapper could load the original dll inside it's own memory page space, so original version willn't be listed in the dll-list.
Has anybody tried to do such dx-substitution? Or maybe u see something that i missed? Or u know better (undetectable) way to intercept API calls? I'll appreciate any constructive opinions on that topic...
But aren't you still modifying the memory by replacing the DX library with the wrapper?
And no, I don't think such checks are ran to verify the file.
And no, I don't think such checks are ran to verify the file.
Originally Posted by Mayion
But aren't you still modifying the memory by replacing the DX library with the wrapper?
Similar Threads
- 2Last post
- 71Last post
- 5Last post
- 10Last post
- 6Last post