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...
Originally Posted by Mayion
