View previous topic :: View next topic |
Author |
Message |
BentoFox Newbie cheater
Reputation: 0
Joined: 05 Feb 2011 Posts: 11 Location: Northern Europe
|
Posted: Tue Aug 28, 2018 8:32 am Post subject: Protecting against code injection |
|
|
Hey folks,
first off, I've been a big fan of cheat engine and thoroughly enjoy using it as it's a very interesting topic to learn about and I don't think it's a bad thing to do.
But currently I am working on a multiplayer realtime pvp mobile game and cheaters are giving me a bit of a headache. I cannot validate everything on server side at the moment so my first approach now is to try my best to keep the lesser skilled cheaters out.
That said, I wonder if maybe some other members of the community have some pointers ( ) towards good practice in repelling lesser skilled cheaters.
I code in C# and currently have a few honeypots, obscured values which change at random intervals and mirror fields.
My problem is that I am still able to find the right value and in the end, there is a fixed calculation taking place which can be found - and once that's found the hidden values do no longer matter.
I'll gladly take any advice or pointers you can give.
|
|
Back to top |
|
 |
Dark Byte Site Admin
Reputation: 467
Joined: 09 May 2003 Posts: 25704 Location: The netherlands
|
Posted: Tue Aug 28, 2018 11:02 am Post subject: |
|
|
this is more value changing then code injection
but what you can do is have 3 or more shadow addresses with the same value xor'ed using 3 different keys. (updated at the same time as the values they change)
once every few minutes check if all 3 values contain the same value, and if not imeadiately mark the account as a 'tamperer' (don't ban), and give them shitty luck serverside, or only let them see other flagged accounts only, or bots that are really cheaty
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
Back to top |
|
 |
BentoFox Newbie cheater
Reputation: 0
Joined: 05 Feb 2011 Posts: 11 Location: Northern Europe
|
Posted: Wed Aug 29, 2018 10:38 am Post subject: |
|
|
Thank you for the reply much appreciated.
I do have a few encoded values which I can check against to see if one of the honeypot values (preferably returned in the getter) changed.
But I can't help thinking about the code injection. Whenever I used cheat engine I almost always went straight for the disassembler and built an injection, which also made me aware of all the other accesses going on such as the checks made to different values. Anyway, I've made it so that the (encrypted) check values are only rarely used (externally). This should make it so that it's easy to find a value that works perfectly fine and create a working cheat - but there's a creeping death that happens at some point.
And don't worry, we try not to ban and have some ideas for a sort of softban to make sure that the tamperer isn't seen in the highscore for others and does not get matched against real players. My primary concern is not with those folks who have fun breaking the protection and creating a cheat... my concern is with the people who create a cheat and upload it, even when it's a PvP type game; once that happens everyone can access the cheat and ruin the game for non-cheaters.
Again, thanks for the pointers and some of the ideas how to handle the tamperer.
|
|
Back to top |
|
 |
atom0s Moderator
Reputation: 204
Joined: 25 Jan 2006 Posts: 8579 Location: 127.0.0.1
|
Posted: Wed Aug 29, 2018 1:27 pm Post subject: |
|
|
Things you should be aware of with what you are doing with mobile development:
1. Apps are not safe. - They can be easily downloaded from the store or directly off the phone with/without root. You can get the APK from the app store without even having a device that is needed to access that data.
2. Apple/Google is not your friend. - In most cases they are heavily against protecting your code / app. If you obfuscate things too heavily to a point that it triggers any of their analysis tools, your app will be rejected. Basically leaving you to be required to make your app even more insecure just to even have it in their stores.
3. C# is super insecure. - I assume you are using Unity if you are coding a mobile app in C#. With that, keep in mind that C# is a managed language that can be decompiled easily with tools such as dnSpy/ILSpy/etc. Any tricks, checks, obfuscation, variable encryption etc. that you do will be visible to people that are looking to hack your app.
It is very important that you focus on getting as much as possible synced to the server for validation and trust the client is little as possible with data/values. In some cases, syncing things like position/movement are too intense but, to combat cheating you can validate the distance/speeds that the player is moving on the server instead.
Think outside the box vs. what you think may be the only choice in the matter. Do as much validation as possible on the server side. Avoid instant blocks/bans/softbans etc. as well to avoid telling cheatings what was detected. If someone warps and is instantly banned/blocked, they'll know thats what caused them to be banned. Instead, delay the ban (similar to what most major companies do) in some manner and block them next time they login, or a week later, etc.
_________________
- Retired. |
|
Back to top |
|
 |
BentoFox Newbie cheater
Reputation: 0
Joined: 05 Feb 2011 Posts: 11 Location: Northern Europe
|
Posted: Thu Aug 30, 2018 5:20 am Post subject: |
|
|
Thanks a bunch! I did not know the stores may reject the app if things get too obfuscated, but the game is already in the store and so far all is well.
Also, I'm aware of the need to validate on server side due to client side protection being useless as soon as the app is decompiled by someone; your example and tip to think out of the box is really helpful.
The cheater handling is already delayed and the cheater won't notice anything is wrong unless he or she knows exactly where to look.
Again, thanks for the pointers you both provided, I'll look more into it and try to come up with some less intense server side validation.
|
|
Back to top |
|
 |
|