The Castle Doctrine Forums

Spyder

Guest

Source code alteration questions

Hello. As I'm sure some of you know there's quite a few people jumping into the source code and making some very easy edits to activate things like wall hacks and such, and basically making it extremely easy to cheat. This'll always be the case if the source code is available so I gotta ask, is there any plan to keep people with altered code from exploiting the game and ruining the fun for others?

Omnipotent

Member

From: California

Registered: 2013-04-02

Posts: 23

Re: Source code alteration questions

Since Jason is aware of this, he will probably be fixing this soon. If he made it check the consistency of each properties.txt file every time it connects, then that would probably be able to stop it. But as far as I know, his plan to prevent this has not yet been released.

jasonrohrer

Administrator

Registered: 2013-04-01

Posts: 1,235

Re: Source code alteration questions

Bottom line:  there is NO WAY to prevent this from happening, whether or not the source code is available.

Yeah, I could modify the client to check properties.txt at launch, but then someone would just re-modify the client to "fake" that check!  Same with signing the client itself.  Ask the DRM people how that's working for them...

The only way to deal with this would be to do EVERYTHING on the server, like each and every robber step, and then only send the client what the robber can see after moving.  As you can imagine, this wouldn't be practical for a bunch of reasons.

So, the way that I'm dealing with this is by recording everything and closing accounts of cheaters (paid accounts).  If someone is walking through walls, the cheat is pretty obvious and can easily be reported (maybe they'll even be a REPORT button in the client for this, and some way to collectively "judge" a given tape as being evidence of a cheat).

If someone is simply turning the visibility shroud off, then it's a bit harder to prove that they're cheating.  But I'm also tracking scouting counts, which helps with that.  If someone breaks through a house on the first try without cutting anything or exploring, that's pretty suspicious.

There are other, community-based ways of dealing with this.  Web of trust, voting out cheaters, etc.  This will be explored more in the future, as the community evolves.  Could be an interesting meta game!

Spyder

Guest

Re: Source code alteration questions

Yea, I figured that would be the case. I'm going to be honest here, that's a bit worrying.

If the game gets even a bit more popular however you're probably going to need a better system in place than manual banning. I also understand that there are cheats like the visibility that are suspicious, but I don't see it fair to ban someone from the game permanently with only a suspicion in place.

Ah well, I guess we'll see what happens - you're a smart guy I'm sure you'll figure something out.

setz

Member

From: NM

Registered: 2013-04-03

Posts: 121

Website

Re: Source code alteration questions

The visibility shroud is definitely one thing that I think I have seen multiple people cheat with. The only problem right now with reporting people is that if I die and lose my house, I lose my tapes and lose the ability to send in my security tapes and/or player name for reporting. Not sure if there will maybe be a way to save or "mark" certain security tapes to save on your account? Maybe even just to be viewed offline?

rmmh

Member

Registered: 2013-04-01

Posts: 10

Re: Source code alteration questions

The server really should verify robbery movelists, to prevent rule-breaking cheaters.

Last edited by rmmh (2013-04-03 22:03:58)

jasonrohrer

Administrator

Registered: 2013-04-01

Posts: 1,235

Re: Source code alteration questions

I can see all tapes, as admin.  So, if you see someone walking through walls, and then you die, as long as you've written the name down, I can find it.

Marking tapes, for review by admins, will be something that will likely be in place in the future.

The problem with the server reviewing robber move lists is that it means that all game rules and logic need to be duplicated on the server.  That means that if I change the game (by adding a new trap or tweaking the behavior of a trap), I would need to change it in two places, which makes the whole thing really fragile and bug-prone.

rmmh

Member

Registered: 2013-04-01

Posts: 10

Re: Source code alteration questions

You could create a "headless" version of the game that takes map/tools/movelist on stdin and produces the appropriate result on stdout.

jasonrohrer

Administrator

Registered: 2013-04-01

Posts: 1,235

Re: Source code alteration questions

Yeah, I have thought about that!

Problem is that the game has non-negligible load time (to parse all the gameElements files).  So, invoking it repeatedly for each check (like, the server PHP code invoking the headless game over and over) would be too slow.

A more attractive idea is to "farm out" robbery logs to be checked in the background by randomly-chosen players' game clients.  A cool idea, but it would require a ton of programming work to pull it off.

DrNoid

Member

Registered: 2013-04-06

Posts: 56

Re: Source code alteration questions

For the games I write as a hobby (a.o. HexTD and a remake of GemTD, at usoog.com) I do the checking of game logs on the server. Since we use Java we can just run the exact same game code on the server and the client. The game logic is completely decoupled from the UI, so the replayChecker runs in its own thread on the server and uses the same code as the normal game. GemTD also runs the gem-choosing RNG on the server so people can't cheat with the RNG. When a game is submitted as a high-score the server adds the RNG seed to the game, so the replay becomes self-contained again.

That works very well, except that for GemTD the games can run really long and checking takes a significant amount of time. I might have to implement distributed client-side checking for that. That would for our case not even be that hard to implement, since the games already have replay-watching implemented, so it would just mean having the game spawn a thread that "watches" a replay in headless mode.

For CastleDoctrine, I think a headless mode that polls a php script for new replays to check would avoid the problem with the overhead of game-start for every replay. You'd have to add the version number to the replays, but it wouldn't need major changes.

As for moving everything to the server... that would basically be how Nethack has operated since the beginning of time For CastleDoctrine it would involve a lot of work, but from a technical point of view I think it could work.

jasonrohrer

Administrator

Registered: 2013-04-01

Posts: 1,235

Re: Source code alteration questions

Good ideas there, DrNoid, especially about the idea of a headless client polling the server for recordings to check.

There are some simple checks that the PHP server can do to catch walking through walls and a few other things.  I'll be putting those in place, for sure.

There's no way to catch people turning the shroud off, though.... except doing everything on the server!

Jaqenn

Guest

Re: Source code alteration questions

The only way to deal with this would be to do EVERYTHING on the server, like each and every robber step, and then only send the client what the robber can see after moving.  As you can imagine, this wouldn't be practical for a bunch of reasons.

When you say 'a bunch of reasons', I'm going to pretend you mean processing time and lag.

There's an additional option that you're leaving out here.  Whenever someone's client connects to the server, they also volunteer in the background as a server-helper.  The server would matchmake different robberies to different server-helpers, which would then manage each and every robber step.  If the connection gets lost the server can step in (or reassign to another helper), process through the list of steps made until that point, and be able to continue acting as the server-helper.

If you're worried about people hacking their server-helpers, farm them out to multiple helpers and check that each gave the same results.  Or have the server randomly spoof being a robbery client to a server-helper and feed it a recording to assure it behaves as expected.

DrNoid

Member

Registered: 2013-04-06

Posts: 56

Re: Source code alteration questions

For replay-checking of robberies and house-provings the processing and delay are not really an issue. It doesn't matter if it takes a minute or 10 to prove you a cheater, you'll be banned all the same. This first check type is also easily farmed out to clients, as mentioned.

Time-delay issues come into play with server-side field-of-view checking, where the player is not sent the entire map of the house, but only the parts he can actually see. Here, after every single step, the player has to wait for the server to process that step, calculate any changes (family, dogs, cats & switches) and send back the now visible parts of the house.

Farming this second check type out to clients is very hard for several reasons:
* 95% of people are behind a (NAT) firewall, meaning peer-to-peer communication with them is simply impossible.
* Latency is most probably going to be much worse. Imagine that a client in the USA has his moves checked by a client in Korea.
But that said, farming this out is probably not even needed, since there is not that much processing required. The grid is only 30x30. It would be interesting to see how many clients are actually in the act of burglary at the same time.

I think the main reason is that it would require a total rewrite of both client and server, and introduce a host of new bugs and problems.

Last edited by DrNoid (2013-04-09 06:12:03)

Matrix

Member

Registered: 2013-04-06

Posts: 137

Re: Source code alteration questions

I think the main reason is that it would require a total rewrite of both client and server, and introduce a host of new bugs and problems.

Pretty much this and the fact that there is a single person making the game, so time spent on infrastructure changes or code rewrites is time not spent on features and bug fixes.