I'm developing a multi-player game. What's the best way to store the server password in the game exe in such a way that if someone tries to crack the game, the password will be removed? I'm using a custom obfuscator and encrypting the password so nobody can read it.
I'm developing a multi-player game...
Christopher Johnson
James Hernandez
Reconsider your architecture.
Noah Gomez
Never trust the client. If you're using a password then try another way
Nathaniel Bell
im pretty sure you fuck it right in the pussy
Eli Campbell
you have no clue, give up
Logan Edwards
Jow Forums confirmed for mongest of all boards
Easton Hill
The architecture is quite robust, actually. The backend is built using C# for high performance and there's a cheat detection module that checks the game exe's sha1hash every time it runs. The game itself is written in VC++, WebKit and C#. The password module is obfuscated using AES and XOR.
If a client is cracked, the sha1hash will change so the server will detect it. However at that point, I need to overwrite the exe to remove the password from the game. Problem is, in windows an application cannot write to a file that is currently in use.
Carson Fisher
Is the password entered by the user or is it embedded in the game itself?
Just open the exe in a hex editor and see if your password is visible there.
Charles Gray
The sha can be spoofed and the password is impossible to protect.
You cannot ever treat the client as trustworthy. In software architecture the client is always and I mean always malicious.
Assume this.
Nathan Morris
make a function that generates it
Parker Roberts
If someone manages to spoof SHA then the whole internet will break so I wouldn't worry about it. I know Google has already done it but that took an enormous amount of computing power to pull off. I could easily just change it to SHA512 and fix it.
The client is malicious only if the SHA changes. The cheat detection system already looks for this. Every minute the client sends a POST request containing the SHA and gets back a True/False response from the server telling it that it's authorized to connect.
Jason Johnson
> c# high performance
> no garbage collection
Pick one
Dylan Phillips
Nobody is even going to play your game. Takes a lot of marketing
Ayden Murphy
Launch another program from the store directory of the game, allow that program to kill the game, new program overwrites old game. To make sure that they won't get around it, in the game check if the new program is removed ( if it is, don't launch the game at all)
Aaron Thompson
>server password
what the fuck are you on about? just don't use a server password? who exactly are you keeping out if this password is supposed to ship with every copy of the game?
also
>custom obfuscator
>rolling your own crypto
pic related
>cheat detection
client can use opengl/directx wrappers, sniff/modify network traffic, or even use something like a debugger without modifying your exe at all. the sha check will only defeat the simplest attacks (not that your game will ever be popular enough to attract any dedicated cheaters.) all "cheat detection" should just be server-side enforcement of game rules, eg. making sure players don't exceed a certain velocity.
Jaxon Sullivan
>The client is malicious only if the SHA changes.
If i were cheating your game I would find your checksum-returning code and hook it to return the valid hash. Do you know about hardware breakpoints, SEH and VEH hooks that don't modify the target function at all? Someone could hook your hashing function without modifying it, and
void __VEHandlerHashHook(){
RemoveCheats();
(*pfnOriginalHashFunction)();
ReapplyCheats();
}
You're starting a battle nobody has ever won.
Noah Walker
Store the server password in the exe? What does this server password do? As others have pointed out, never trust the client. Though I'm not sure what you mean by server password, anything that is encrypted and needs to be decrypted, is always possible to expose through memory scanners.
I wrote an experimental mmo thing using c# as the server and the client was made in gamemaker. I didnt bother making any anticheat client sided. The server does all the work (not sending player location packets until they are in clear line of sight, not moving clients past a threshold, etc). The point is no matter how much people change the client and or sniff packets and change them, it doesnt help them any.
Hunter Martin
The game is not opensource so I wouldn't worry about anyone compiling a new version.
John Evans
This is to send the player's stats and details about the game exe to the server so it can detect abnormal behavior. The server uses 2 passwords. One is the admin password and one is the game password that is hardcoded in the exe for security.
Jacob Adams
You don't need the source code to modify an executable.
Blake Martinez
I didn't mention compiling a new version, and someone creating cheats doesn't need your game's source, they are fine reversing it with a debugger.
Nathan White
Just following up - if you don't understand the difference between debugging/cracking your game and recompiling it with changes, there is literally no point in writing your anti-cheat - it will be trivial to bypass.
I was originally talking about techniques like
> reverseengineering.stackexchange.com
> codereversing.com
Perhaps start with jbremer.org
Caleb Murphy
i bet your game isn't even playable yet... it's really perfectly fine to save this security shit for once you actually have some players, you know. especially because you don't know anything about security