The Castle Doctrine Forums
Discuss the massively-multiplayer home defense game.
You are not logged in.
- Topics: Active | Unanswered
- Index
- » Search
- » Posts by der
Pages: 1
#1 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-06 14:33:56
so I'm not sure if you have any experience cracking PHP scripts, but if you do, please give it a go.
That's exactly what I was doing. I think it is a some sort of game for me.
If I find something interestring, I will email you. This time I just explored it when I was writing an answer, so I couldn't stop myself from using it as an argument.
#2 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-06 13:55:17
and forbid Russian IPs like "212.34.113.235,"
I realized that I have just commited to 'evil Russian' myth, lol 
Also, I trust that both "derlafff@..." and "castle@..." are your email addresses, and
I did it only to check my ideas. Feel free to ban "derlafff@" account, and threat second purchase as a contribution to a good game
I trust that you're not going to use my ticket ID for nefarious purposes
If I wanted to do any bad, I would not reveal myself in this thread
#3 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-06 13:43:18
And being able to compute it for your own email address (which you clearly will be able to do) won't help you compute it for my email address, unless you have the secret key (which you do not).
I don't understand one thing: is there any reason to leave this ticketserver feature opened to the Internet, if only servers under your control can use it?
#4 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-06 13:16:50
Oh, yeah, Der, that was stupid of me. Fixing that hole now by including the email address in the sha1 to generate the key.
Not secure again. I do know your email
#5 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-06 12:25:48
So, if the client and the server shared a key, and that key was really hard for most people to get, that would make client-server communications even harder to mess with and using modded clients much harder. Right now, either of these things are already outside the realm of possibility for all but 5% of the player base. Making it substantially harder would shrink that number significantly.
The game source would ship with a key, but not the key needed to play on the main server. The source already does this in many other instances in terms of protecting the server (the source ships with various dummy keys in place so that you can't, for example, trick my server into thinking that you've paid for an account when you really haven't---only I and the payment processor have the secret key needed to create new accounts on MY server).
What would change is that you couldn't (easily) build from source and play on the main server.
Your ideas of 'shared' keys is not really security. It's security through obscurity. Some people would say it's completely not security.
Yes, it's pretty possible to make a tight protection using this way. Unfortunately you have no skills (or experiance, I have no idea) for that. Thus, your bike lock is decorative, no more.
sha1 (with new line) of your download code is a50ac8a7b6644ee8e0b124ac233642c7fcadb541
My suggestion: find someone who understands security. Even if your method is kind of right, you make silly architecture mistakes.
Or find someone who can move the game process to the server side, if it's too hard for you. Your game is already useless without a server.
Yes, I've been playing with ram dumps on this end. I've already made some progress here (so that at least the text maps don't hang around in ram anymore).
RAM dumps is not the only problem. It's just the simpliest. I still can attach gdb to the game and do whatever I want. This strategy is dead. Everything that process knows is easily recoverable by user.
How do you know that some people aren't peeking at where the vault is with a modded client?
I know that they are doing it, I've seen by myself. And until there is a technical possibility they will continue doing it.
#6 Re: Main Forum » robbed without a tape » 2014-01-03 13:18:24
I have another strange problem that may be connected:
After I die robbing someone house stays busy as If I am still here, so I can't rob it again. I repeat it with another house and it becomes busy too.
Is it limits or subj. bug?
#7 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-03 11:09:17
About delays:
I made a simple 5-minute demo that prooves that they are absolutely OK
It uses http requests, but with sockets it can be even faster
Each time player moves (by keyboard arrows) it downloads 13x13 map piece from server
#8 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-02 15:52:09
've been worried about how slow this round-trip would be...
You should not really care about speed of network: there are online fps shooters! Of course they use client-side predictions, but you can do the same.
This game is step-based, so delay is not as vital as you threat it. With using sockets delays should be minimal.
I also have concerns about RAM (for storing current map states) and CPU (for simulating each move) server-side, especially as we get more players.
That's probably the most important issue, but it is resolvable.
About RAM:
30x30 map with 2 bytes per cell is about 2 Kb.
Let's imagine we have to store another 2 Kb for the rest of needs.
4 Kb * 128 players = 0.5 Gb of RAM for storing all the information.
You can store this data in the database, which will give the ability to restart server without losing progress.
Or you can store it in RAM: it will be a bit faster, but you will need more RAM on the server.
Sounds like a real limit for one budget server. But you have to think about scaling. In other words, you should be able to start 2 or more servers when they are nesessary.
About CPU loading:
As soon as the game is turn-based, calculating of changing the map is needed only on turn. People are slower in this case. I don't think that server will get more than 50 turns per second even if it has 512 clients.
But even 10 t/s can probably kill server (I have no idea, I didn't yet read the source). Moreover, making tons of threads is not the best idea. That's why it's better to process "turn requests" continiously in one thread (or few, depending on the number of cores on server).
Thus, the list of things I imagine have to be done:
Separate (please, don't code 2 different versions, or you will die updating it
) turn logic so it can be used on both client and server. Probably you already have it abstracted in clientWrite server that uses this logic (and only logic, it should not know about textures or anything like that, or it will be slow) and works with clients. Clients sends actions and get a little area near him (probably not strictly 13x13, but only visible tiles. a good example is minecraft anti-cheat plugin which replaces invisible blocks)
Be sure that client can handle with 2 or more servers because they can be overloaded
#9 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-02 14:01:39
I think that such a protection would not change anything. It would only involve you into an infinitive battle with cheaters. No matter how cool your protection is, it is breakable. Even hardly obfustaced Skype with encrypted protocol was broken.
This method can only work when you have more skills and resourses than cheaters. Unfortunately, you are alone while the number of cheaters is growing with popularity of your game.
The idea that I've come up with is to embed a secret algorithm itself in the binary, and mirror that same secret algorithm on the server. The request signatures attached to each client request would then be passed through that secret algorithm, and the server would use the same secret algorithm to verify these request signatures.
This kind of stuff works only against reimplementation of client. Changing your precompiled binary (or even just reading house map directly from process memory) is as easy as changing source. Once we are able to get map, every other protection is useless. So, no studiyng or touching your 'secret algorithm' is needed.
While game is on the client, client is boss and nothing can be done. By changing the game this way you will harm anyone, but not the cheaters. In this case you will harm poor linux gamers. Please, don't do that 
So, I suggest that the only way is to move as much as possible to the server.
Probably permament banning of cheaters would also help.
Pages: 1
- Index
- » Search
- » Posts by der