Oh, okay... sweet! 
[Theory/Prerelease/POC] New hooking method!
Originally Posted by .::SCHiM::.
Did you know that when you call a function like that, the opcode changes?
I can easily find out if the call made will use a register or an imminent operand as a value. In case of the register, I could trace back mov/add/sub instructions with that particular register (second operand denotes what register to check for) and patch the function. It's possible, I just haven't done it yet
I can easily find out if the call made will use a register or an imminent operand as a value. In case of the register, I could trace back mov/add/sub instructions with that particular register (second operand denotes what register to check for) and patch the function. It's possible, I just haven't done it yet
Originally Posted by Minos43
That would work up until you run into a register that's been filled from a call to another function. Then the only way you could get the contents would be to set a breakpoint.
Ofcourse there's ways of optimizing such a technique, to "release" or revert back to normal the calls from locations that are consitently not the address your looking for. I suppose it could all get very complex very quickly, my point is simply with significant pattern recognition and a clever enough approach there is a way without setting a breakpoint.
Also I believe this is the third time this was mentioned. Once by me, once by you o_O, and now once more by you again...
Originally Posted by why06
Well not the only way. You could scan for every call register opcode and replace it with a jmp to code that would read the specific registers and a compare them with the address of the function your looking for... yeh that wouldn't cause MASSIVE amounts of overhead or a bottleneck.
Ofcourse there's ways of optimizing such a technique, to "release" or revert back to normal the calls from locations that are consitently not the address your looking for. I suppose it could all get very complex very quickly, my point is simply with significant pattern recognition and a clever enough approach there is a way without setting a breakpoint.
Also I believe this is the third time this was mentioned. Once by me, once by you o_O, and now once more by you again...
Even using the method I mentioned ( setting a breakpoint to check the contents ), breakpoints can be used for setting hooks as well, so that also defeats the purpose of releasing this "new" method. He has to some how read whats inside the registers without modifying too much code, or not modifying anything at all.
Also, continuing with what I said before about calling using a register as an operand. I took this from my directx9 test environment as an example:
Code:
00403425 |. 8B08 MOV ECX,DWORD PTR DS:[EAX] 00403427 |. 50 PUSH EAX 00403428 |. FF91 A8000000 CALL DWORD PTR DS:[ECX+A8]
Just like you mentioned, you CAN read the op-codes to see what the instruction is doing but you can't do anything more. So you would take 8B08, convert it into the instruction, now you know what its moving into what register, but you won't be able to find out what it's moving.
FFD0 is the opcode for CALL EAX, I can easily overwrite this with a call to a function that would process all register calls.
Call MyRegisterCallHandler() or whatever.
There since at runtime execution would be tranffered to my processing function I simply code some inline asm to read the EAX register if I find in my list of overwritten calls that FFDO is indeed the opcode for CALL EAX. Since the EAX register was filled with the right address before it calls that address, all one has to do is read the address for EAX in the handler function.
Now like I said this would incur massive overheard, but even in a dynamic call like so the code should remain pretty consistant unless there's some shananiggens going on. So that function can start off hooking every call in the module, and keep track of the return addresses of each call which will be pushed on the stack, if through its filtering the program find that 99% of addresses don't ever jump to our target address, the original code is simply rewritten and we don't handle them anymore.
I'm not talking about just reading the opcodes I'm talking about reading the registers in real time, by essentially Hooking all calls to a sorter function, then using massive amounts of filtering to optimize the code so that eventually only one function is hooked.
Call MyRegisterCallHandler() or whatever.
There since at runtime execution would be tranffered to my processing function I simply code some inline asm to read the EAX register if I find in my list of overwritten calls that FFDO is indeed the opcode for CALL EAX. Since the EAX register was filled with the right address before it calls that address, all one has to do is read the address for EAX in the handler function.
Now like I said this would incur massive overheard, but even in a dynamic call like so the code should remain pretty consistant unless there's some shananiggens going on. So that function can start off hooking every call in the module, and keep track of the return addresses of each call which will be pushed on the stack, if through its filtering the program find that 99% of addresses don't ever jump to our target address, the original code is simply rewritten and we don't handle them anymore.
I'm not talking about just reading the opcodes I'm talking about reading the registers in real time, by essentially Hooking all calls to a sorter function, then using massive amounts of filtering to optimize the code so that eventually only one function is hooked.
Originally Posted by why06
FFD0 is the opcode for CALL EAX, I can easily overwrite this with a call to a function that would process all register calls.
Call MyRegisterCallHandler() or whatever.
There since at runtime execution would be tranffered to my processing function I simply code some inline asm to read the EAX register if I find in my list of overwritten calls that FFDO is indeed the opcode for CALL EAX. Since the EAX register was filled with the right address before it calls that address, all one has to do is read the address for EAX in the handler function.
Now like I said this would incur massive overheard, but even in a dynamic call like so the code should remain pretty consistant unless there's some shananiggens going on. So that function can start off hooking every call in the module, and keep track of the return addresses of each call which will be pushed on the stack, if through its filtering the program find that 99% of addresses don't ever jump to our target address, the original code is simply rewritten and we don't handle them anymore.
I'm not talking about just reading the opcodes I'm talking about reading the registers in real time, by essentially Hooking all calls to a sorter function, then using massive amounts of filtering to optimize the code so that eventually only one function is hooked.
Call MyRegisterCallHandler() or whatever.
There since at runtime execution would be tranffered to my processing function I simply code some inline asm to read the EAX register if I find in my list of overwritten calls that FFDO is indeed the opcode for CALL EAX. Since the EAX register was filled with the right address before it calls that address, all one has to do is read the address for EAX in the handler function.
Now like I said this would incur massive overheard, but even in a dynamic call like so the code should remain pretty consistant unless there's some shananiggens going on. So that function can start off hooking every call in the module, and keep track of the return addresses of each call which will be pushed on the stack, if through its filtering the program find that 99% of addresses don't ever jump to our target address, the original code is simply rewritten and we don't handle them anymore.
I'm not talking about just reading the opcodes I'm talking about reading the registers in real time, by essentially Hooking all calls to a sorter function, then using massive amounts of filtering to optimize the code so that eventually only one function is hooked.
Originally Posted by .::SCHiM::.
The hooking of only one function has already been achieved, But this would certainly come in handy if I ever encounter an register call. However those are rare and a standard compiler will probably not spit out code like that, I've never seen it happen.
Edit: Sorry why06, I skipped your post mentioning calls using a class.
Compilers spit out code like that quite often, especially when a function is in a class. It's a lot of extra work, and I wouldn't recommend doing it since it's so easily detectable, I was just saying it's possible. There are much easier less detectable hooks, Mino mentioned one already.
I find hooking the anti cheat directly makes it quiet easyier than this method.
Example: Hooking ggscan.des and preventing the signature scan from scanning the inject module or editing modules. Makes life alot easyier at times. Also using drivers helps at times to get access to areas as well. (.sys)
Example: Hooking ggscan.des and preventing the signature scan from scanning the inject module or editing modules. Makes life alot easyier at times. Also using drivers helps at times to get access to areas as well. (.sys)
Originally Posted by faceofdevil
I find hooking the anti cheat directly makes it quiet easyier than this method.
Example: Hooking ggscan.des and preventing the signature scan from scanning the inject module or editing modules. Makes life alot easyier at times.
Example: Hooking ggscan.des and preventing the signature scan from scanning the inject module or editing modules. Makes life alot easyier at times.
Originally Posted by faceofdevil
I find hooking the anti cheat directly makes it quiet easyier than this method.
Example: Hooking ggscan.des and preventing the signature scan from scanning the inject module or editing modules. Makes life alot easyier at times. Also using drivers helps at times to get access to areas as well. (.sys)
Example: Hooking ggscan.des and preventing the signature scan from scanning the inject module or editing modules. Makes life alot easyier at times. Also using drivers helps at times to get access to areas as well. (.sys)
