client protection discussion

[Carl Friedrich]

if you're all for helping decent kids getting a decent server online then this might just be for you

our team was discussing how to protect the client for our new private server, we're targeting 5065 with custom c# 6.0 source

our goal is to protect our client from intermediate and beginners (cause tbh there isn't such a thing as protecting the client, imho, it's only making it as hard as it gets to hack)

we've multiple items in discussion which includes

injecting random client cryptography key:
using our loader to initiate a connection with the server to generate random cryptography key and inject it using the loader
eliminating the chance of getting the key without accessing the process memory and rendering each key useless after the client start, making it just a little bit harder

changing cryptography key at runtime:
we don't know if that is even possible (as in if it's going to be as easy as writing over the old key and the clients crypto class would still use it or does it require reinitializing the class), would still be useless against memory based bots

using the loader to inject a function inside the client to send the server the client process information and what not, could be reversed ofc but it would be our thing, could use some advanced concepts like self modifying code and what not (doubt that anyone would go through this to hack in a private server)

and last there is packing and protecting

we're open for suggestion and discussion, we all have blind spots and our happens to be at reversing


on a side note, we're releasing a pvp server, attacking others grands you composition progress and chance for quality/level upgrades, also killing people grands random drops of progressing items (like if 110 trojan killed 120 fire, a dragon ball may drop), random drops in war inside the castle, etc..
so you can understand how an aimbot could really ruin it

[Super Aids]

If your team is discussing how to protect the client, your team probably isn't capable of it.

[pro4never]

Your ideas are too focused on somehow 'hiding' the client encryption key... no matter what lengths you go to hide or pack that key away it's still on their computer (or transferred to their computer) and is vulnerable to being picked apart by users.

You mentioned you want something capable of blocking common programs and stopping script kiddies. All your dynamic encryption key bs isn't going to be useful against anyone with moderate reverse engineering knowledge and is needlessly complicated to stop those who want to run or slightly modify public tools.

Focus on blocking primary methods someone could hook into or modify your exe and make sure those checks are validated both for positive detection (packet shows they have modified conquer.exe for example) and for non existence (they removed your client protection entirely or blocked the botcheck packet from being sent)


With a few basic steps implemented properly there's very little risk of public tools working. You'll never block someone with enough knowledge and determination but that's no excuse not to patch common METHODS.

[Super Aids]

Originally Posted by pro4never

Your ideas are too focused on somehow 'hiding' the client encryption key... no matter what lengths you go to hide or pack that key away it's still on their computer (or transferred to their computer) and is vulnerable to being picked apart by users.

You mentioned you want something capable of blocking common programs and stopping script kiddies. All your dynamic encryption key bs isn't going to be useful against anyone with moderate reverse engineering knowledge and is needlessly complicated to stop those who want to run or slightly modify public tools.

Focus on blocking primary methods someone could hook into or modify your exe and make sure those checks are validated both for positive detection (packet shows they have modified conquer.exe for example) and for non existence (they removed your client protection entirely or blocked the botcheck packet from being sent)


With a few basic steps implemented properly there's very little risk of public tools working. You'll never block someone with enough knowledge and determination but that's no excuse not to patch common METHODS.

To add onto this.

Originally Posted by unknownone

The problem here is when the person doing the reversing is more knowledgeable than the one attempting to add protection. It takes longer to protect something than to break the protection.

[Carl Friedrich]

@ their was some server (lets not mention names or owners so we don't start a flame war) had something like this, injecting a dll to the client that insure that any hooking attempts will be reported to the server to disconnect the client, after monitoring protection code and server's packets, we kinda constructed the packet and spoofed it on a non protected client, but that's definitly an extra layer we're considering
@, yeah that's true, but no one is omniscient and on a side note, that's BaussHacker?

[Super Aids]

Originally Posted by Carl Friedrich

and on a side note, that's BaussHacker?

Do I know you?

[Carl Friedrich]

Originally Posted by Super Aids

Do I know you?

"we" may not be good with RE, be that as it may, we still have our set of skills
oh and sorry for what happened on hf, you were clearly only trolling on the lounge

[_DreadNought_]

Originally Posted by Super Aids

If your team is discussing how to protect the client, your team probably isn't capable of it.

Woah haha everybody has gotta start somewhere. So what if his team isn't capable of it? At least they can make an effort and start to progress into furthering their abilities into what they require.

which is exactly how i made my first anticheat.

@:
You've got the crypto key idea going but i didn't really read much else about any other protection.

You need to find a way to make sure they cannot login to your server without your anticheat being present, whether that's via crypto or whatever means you're familiar with.

You have a good idea with establishing an anticheat connection to the server, although you can hijack conquers send and just use that connection which seems smart now but i never did and i'm pretty sure there was a good reason for it. so maybe it isn't so smart haha i haven't dabbled in co for a long time

Speedhacks are pretty detectable server side just by measuring times




tl;dr. This is conquer, doing half of what i said above is enough to remove virtually every single hacker/cheater on your server, you're only gonna have a problem if you piss someone off otherwise there simply isn't enough talented developers left around here to bother breaking it unless they're bored and honestly - at that point it isn't worth it because they'll just break your protection every time. aim to stop 99% of the hackers/cheaters, there will always be someone with enough knowledge to break it if they want to but that's just one person.

It's not about making a protection so great nobody can break it, it's more about putting up obstacles

[Ultimation]

Dread, shhhh lol :P

[Carl Friedrich]

@ couldn't say it better myself, but what about digging in with technicalities ?
for instance, modification check, should it be size or date modified or looking up for certain assembly sequence for send/recv function to see if it changed ?
for instance, injection check, would be enumerating the dlls list of the process using os registry key? what if the dll didn't remain loaded long enough and instead used dyn. alloc memory to host itself ?
or maybe search memory for RWX? maybe also creating a watchdog thread? patching write process memory and zwwriteprocessmemory?

[Super Aids]

Originally Posted by Carl Friedrich

"we" may not be good with RE, be that as it may, we still have our set of skills
oh and sorry for what happened on hf, you were clearly only trolling on the lounge

Out of my 20k+ posts only about 11k were in the lounge, so not really. I did have a C# tutorial sticky for years and contributed a lot in private groups.

Also it's not a big deal, me and Omni never got along, I was banned twice before my account was totally closed lmao. It's like 3 years ago now anyway, so.
@, true

[_DreadNought_]

Originally Posted by Ultimation

Dread, shhhh lol :P

i didn't tell him how to do anything :P

Originally Posted by Carl Friedrich

@ couldn't say it better myself, but what about digging in with technicalities ?
for instance, modification check, should it be size or date modified or looking up for certain assembly sequence for send/recv function to see if it changed ?
for instance, injection check, would be enumerating the dlls list of the process using os registry key? what if the dll didn't remain loaded long enough and instead used dyn. alloc memory to host itself ?
or maybe search memory for RWX? maybe also creating a watchdog thread? patching write process memory and zwwriteprocessmemory?

nobody is gonna tell u exactly how to do it, ur gonna have to experiment

honestly anything i've mentioned is all completely public knowledge if you go back and just read through previous anticheat threads on the forums and on google

ps, what language are u writing this in?

[Carl Friedrich]

@ yeah seen those, not a big loss tbh, mostly skids and scammers
@ IKR, quick google search would even get me snippets, excuse my laziness :'D
depends on what i'm going to implement, will try c# with unmanaged exports and intropping, if failed, will go for c++ i guess,
one could argue that it should be c/c++ but we all have our reasons (my c++ is rusty)

[Super Aids]

Originally Posted by Carl Friedrich

@ yeah seen those, not a big loss tbh, mostly skids and scammers
one could argue that it should be c/c++ but we all have our reasons (my c++ is rusty)

It has always been that lmao and definitely no loss. I mean I never went there to get anything, I only went there to troll and contribute.

I would actually argue that it should be D, Nim or Rust instead of ****** C++

[Ultimation]

Easyhook!!! Hint..