Protection Suggestions 5017

Anyone have any suggestions on antibot/client protection targeted at client version 5017 or below, I know the encryption is XOR, and that there is no blowfish. So how would I go about protection the exe? Any suggestion is great!

Thanks ahead guys!

There's a number of ways but the general advice I've heard has been the following.


#1: Any packing of the client you do is generally easily reversed. Fairly few public/free tools so anyone set on unpacking it can figure out what you used and reverse it easily in most cases.

#2: Any client side protection you write will be infinitely easier to bypass if it does not involve server side protection (they can just use their own client in that case)

#3: Any changes you make in the argument of security should be viewed as a 'barrier to entry'. Anyone dedicated enough will likely overcome your security at some point but your job is to make it not worth their time.



I've heard a number of options thrown around in favor of security and some of the ones I really like would be...

-Overwriting the client spell encryption.
-Check for client hooking/injection
-Pack client (to protect these changes)

-Silent proxy to verify that the user is running your own client. By overwriting spell encryption + other changes you make it difficult for them to just use their own exe without serious work and also remove any packet based bots from the equation.


I'm positive there were other great suggestions being thrown around on the forums before but these are the ones I've seen most commonly suggested that would actually have some effect from the way I see it.

That being said... I've never really been involved in that side of the 'scene' so I'm sure others have better advice.

I appreciate this pro, as always you have good advice. So far the client side protection has all of the above. There is only so much you can do client sided. So now my goal is server sided, any more suggestions guys?

#Bump

Still open for ideas server sided guys. Need all the ideas I can get.

Theoretically detouring SendInput, mouse_event, keyb_event in User32.dll would block all macros and autoclickers while retaining hardware mouse and keyboard events since those are the functions used by software to generate mouse and keyboard events. You could do some detouring at NtSendUserInput since all 3 pass it, though still bypassable at kernal, hooking to the SSDT. But I believe at this level it would involve distinguishing hardware from Windows API events if you wanted to prevent any bypassing.. Not sure how you would do that..

Hook, find the function, detour to a new function with the same arguments as the original that simply returns.. or call exit process, then return.. or make a message box that says to turn yer shenanigans off, then return.

Edit:
Some antiviruses may see this as a threat though, since you may need to hook Windows itself for detours to find the instance of the function that is used.

Oh, serversided? :D
Pie.. or cake.. or both. And since it's serversided it means you control the pie and cake.