Prevent winsock injection with MS detours [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

I have read a code somewhere that promises it can protect an applications Winsock functions from packet editors.

I run a game server and this is really good news for me. But is this really possible? Like adding an DLL with the use of detours to my game's executable that will protect my winsock functions from getting hijacked?

Like if they hook an packet editor to my application they are not gonna see anything on the logging of packets?

Or is hiding the process of my application from this kinds of tools a better approach?

Thank you. Please discuss.

The code I found: http://pastebin.com/XtfSHxBL

Answer 1

If you would add such code to your game, I would just NOP it ;)

Get over it.
A client is NOT secure, and cannot EVER be trusted.

Besides, I could just switch a linux router in between, and capture the packets there..

If you don't want your winsock data to be captured, you need to encrypt it with a good assymetric encryption algorithm, like PGP, and that before the data is sent to winsock.

A better idea would be to use isdebuggerpresent to close the program if that is true. But then you need to encrypt the executable, because else I'd just disassemble it with IDA, and either patch isdebuggerpresent to NOP, or 0xe9 it with return false via createremotethread at runtime, which would incidentially not be detectable with a file-checksum check.

However, this way you would still be vulnerable if i hijack the isdebuggerpresent WinAPI function and nop it. That's someting that can be achived with MS detours as well ;)

Answer 2

Anything like that will be trivial to get around. Focus on securing the actual protocol, use encryption, verify everything server-side.

I would post this in a comment but apparently you need reputation to do that.

Answer 3

It is possible, to some extend. However, nothing will stop a persistent hacker.

One possibility I remember (because I investigated an attack to this "secure" function import) was used by the .NET runtime, to protect it from hijacking registry read/open functions (for security reasons related to CAS).
Basically, they decided to hardwire function addresses, specifying direct addresses for a number of windows variants (several service packs). Obviously, this is something you can do proficiently only if you are MS (you patch advapi32, changing the address of Reg* functions? You submit a patch of mscoree as well).

It makes it difficult to catch and intercept those functions (at least, more difficult than just using the IAT), but as I said, I discovered how it was done examining an attack so....

With Detour, you still use the IAT, but you can check if someone fiddled with it, and "recover" (rewrite) the original address. Or at least check it. This is what Punkbuster used to do, IIRC. Mind you, this proves that there is nothing like a secure client (people understood what PB was doing -> they circumvented it).