Sync Errors

Tobi · Post by **Tobi** » 24 Apr 2006, 16:15

it would make it somewhat hard yes if you do that... (as an exe in memory != an exe in file)

Still, it would at least triple the size of the executable (if not make it 10 times as large) because you need some way to check linux i386, amd64, powerpc binaries too (ie. you always need all binaries instead of the one you run).

It's probably much more convenient and easier to make too to have some kind of voting system on resync (not working on that atm, patmo98, tho I did experiment with sth like that sometime ago), so that in games with more then 2 players/specs the majority is considered right.

That way you'd need to distribute your hacked exe to all your allies (in a N vs. N game) plus a spec to make it of any use...

BvDorp, not looked at it. I doubt they handle it at all...

AF · Post by AF » 24 Apr 2006, 16:15

May I suggest that cheating using .cheat and codes like .give and .atm, be shoved into the network buffer and treated as synced code? It's a shame that you cant do allied games against 10 AI's all cheating because each AI desyncs the other host as soon as they start cheating.....

Tobi · Post by **Tobi** » 24 Apr 2006, 16:18

I'm pretty sure .cheat and .give (and other chat messages too probably) are already synced... if I remember I'll try it sometime. Maybe the AI cheat interface isn't tho, I don't know that...

Lord JoNil · Post by **Lord JoNil** » 24 Apr 2006, 16:40

The normal cheat interface is synced.

NOiZE · Post by **NOiZE** » 24 Apr 2006, 16:53

.give

gives a unit + loss of sync though :)

incidenta5 · Post by **incidenta5** » 24 Apr 2006, 16:56

I started to play around with some of the code that I mentioned above. It turns out that the way VC8 compiles my demo app, the following happens:

Code: Select all

void main(...)
{
 void *p = func;
 _asm
 {
  call p  // goes to correct function
 }

 //p != actual location of func, it points to a jmp <relative address> which then heads to the function

}

My next thought was to run a checksum on all non-writable pages created by the program. That way, you can do an in memory check without touching the executable and avoid changes that occur in RAM.

I'm still looking into that.[/code]

Tobi · Post by **Tobi** » 24 Apr 2006, 17:04

how will you check binaries on other architectures or operating systems?

Or will you include a list of allowed checksums (making spoofing very easy of course) which is used by the host to allow/disallow clients?

incidenta5 · Post by **incidenta5** » 24 Apr 2006, 17:37

Tobi wrote:how will you check binaries on other architectures or operating systems?

Or will you include a list of allowed checksums (making spoofing very easy of course) which is used by the host to allow/disallow clients?

Perhaps there could be an authentication server which stores checksums of parts of the binaries for different architectures. This server could sign a message stating that one particular client is clean for a particular game.

The way I presented the memory scanning solution, it would be locked to one platform if contained in the client binary itself. To go cross platform, an authentication server would probably be required.

The same method could be applied though, randomly scanning and checksuming memory locations.

AF · Post by AF » 24 Apr 2006, 20:21

Ok so what you're suggetsing is that Springs memory footprint be scanned and checksummed, then compared and verified by an authentification server?

hmm, What if that user has subvirted that part of the inmemory scanning? Thus giving false readings? The technology exists, I read a paper on a rootkit that hooked the memory handlign routines so that when an antivirus read it's signature in the pagefile and inmemory it got garbage and freespace rather than code, why not replace edited spring code with valid spring code? Or circumvent the whole thign and simpyl save the checksums to disk and laod them when asked for them rather than do the checksumming process.

My only solution there is to have the authentification server send binary code over with a unidentified program that the cheater wont have source for, which will then scan the spring bianry as you said. The problem there is your moving code over the network and that has numerous security implementations, ones the cheater may exploit....

jouninkomiko · Post by **jouninkomiko** » 24 Apr 2006, 20:24

Again, if someone really wanted to cheat, all they'd have to do is figure out what a "good" checksum is, and spoof it when its requested. A determined cheater will beat us in far less time than it will take us to write counter measures. Here is what I propose:

Add the ability to resync incrementally by improving the way synchronization is done, and include an application to scan a demo file and detect cheating post-battle. This could even happen via the lobby, with cheaters being given negative ratings.

AF · Post by AF » 24 Apr 2006, 20:29

In an in game situation with more than 2 players, we could just check whose machine has the changes and only resync their machine, which will probably be the cheaters machine if a cheater is present, thus any changes the cheater make have to be done over and over and dont affect the game state on the other machines, as long as the protocol used is secure, they'll have to resort to other methods...

Another situation is that as soon as a desync is found in a game with only 2 players and the above cant be done then the game is rewound to the last synced point and carries on from there, and if sync continues repeatedly to be lost for that aspect then it's reverted to default, for example a krogoth that exists on one machine but not on the other would cease to exist, or both parties could be asked wether the other player can keep it....

incidenta5 · Post by **incidenta5** » 24 Apr 2006, 21:43

AF wrote:In an in game situation with more than 2 players, we could just check whose machine has the changes and only resync their machine, which will probably be the cheaters machine if a cheater is present, thus any changes the cheater make have to be done over and over and dont affect the game state on the other machines, as long as the protocol used is secure, they'll have to resort to other methods...

Another situation is that as soon as a desync is found in a game with only 2 players and the above cant be done then the game is rewound to the last synced point and carries on from there, and if sync continues repeatedly to be lost for that aspect then it's reverted to default, for example a krogoth that exists on one machine but not on the other would cease to exist, or both parties could be asked wether the other player can keep it....

The way I had thought of it was very specifc. The user never knows exactly which checksum they have to send. There could be a hundred thousand different checksums created on the fly by the client as requested by the server. You could also ask for combinations of memory (i.e. 4 bytes from here, 120 from there, and another 16 bytes from a third source to create the hash; at random)

A closed source verification program might work, but then again; it would be no better than vac/punkbuster at detecting cheats.

The rootkit aspect is very interesting, and there is alot of academic research in that area online (rootkit.com, etc..).

jouninkomiko wrote:Add the ability to resync incrementally by improving the way synchronization is done, and include an application to scan a demo file and detect cheating post-battle. This could even happen via the lobby, with cheaters being given negative ratings.

Whats to keep the cheater from doing something to the unsynced game objects. For example; adding 'extra' info to the screen such as enemy resource totals and build queues. Or the all-seeing-eye?

Postgame analysis could prove useful for things like units firing outside their normal range consistantly etc... (have a vulcan target an air unit via a group ai? At such an angle that it hits an enemy base WAY out of range. <<I've seen this happen on speedmetal occasionally when targeting buildings in the center with a vulcan placed near the edge of the mountain in a players base>>)

Tobi · Post by **Tobi** » 24 Apr 2006, 22:07

I think AF was talking about the checksums used for resyncing, not the anti-cheat checksums.

el_muchacho · Post by **el_muchacho** » 24 Apr 2006, 23:50

incidenta5 wrote:
jouninkomiko wrote:Anyone could easily intercept this by figuring out what each function is supposed to hash to, then intercepting the message when its received and sending the correct number. Building a 100% effective anticheat measure is impossible. I mean, look at what happened with Quake 3 and punkbuster thereafter?
This isn't intended to be 100% foolproof. By making changes break with every update, it will make it inconvenient to cheat.

Also, randomizing which sections are scanned and how much is scanned would mean that the attacker would require access to the original executable, and knowledge of how to pull certain signatures from its functions.

By making it impossible to hash every concievable combination of data, which by the way is version dependant in many cases, you require a certain skillset to 'cheat', thus limiting the number of people who could successfully pull it off without being detected.[/code]

I had described a very similar scheme a while ago, when we had the same kind of discussion. I even suggested that the function that calculates the hash on pseudo-random areas of the memory be delivered as a precompiled closed-source library, which woudl defeat everyone but the most determined cheaters. Now, a said before, one shouldn't target the 5% ultra determined cheater, but the remaining 95%. For it being cross-platform, it's not easy.

edit: I see we've arrived to the same ideas.

el_muchacho · Post by **el_muchacho** » 25 Apr 2006, 00:02

jouninkomiko wrote:Anyone could easily intercept this by figuring out what each function is supposed to hash to, then intercepting the message when its received and sending the correct number. Building a 100% effective anticheat measure is impossible. I mean, look at what happened with Quake 3 and punkbuster thereafter?

What happened to Q3/Punkbuster ?

nerd256 · Post by **nerd256** » 25 Apr 2006, 00:18

If a resynch is put in place, then could we just adopt a "host is the final word" strategy? Then it just becomes less keeping everyone from cheating and just keeping the host from cheating. And this, in turn is just a social problem. If a host is infamous for cheating, I doubt anyone will join his game, eh?

Also, if there was some way to note in the replay what caused the synch errors (ie. highlight the 20 new krogoths in red), this would create a smoking gun.

incidenta5 · Post by **incidenta5** » 25 Apr 2006, 02:26

el_muchacho wrote:
jouninkomiko wrote:Anyone could easily intercept this by figuring out what each function is supposed to hash to, then intercepting the message when its received and sending the correct number. Building a 100% effective anticheat measure is impossible. I mean, look at what happened with Quake 3 and punkbuster thereafter?
What happened to Q3/Punkbuster ?

It seems like every 2-3 weeks they break all existing hacks and about 2-3 days after that, new hacks are written or modified from old ones to work again. This is not including all the private hacks, which are significantly harder to detect since you cannot write a signature module for something you dont know about.

They have started hardware banning people for using certain types of cheats, but the hack creators have released drivers for NT/XP that mask your true hardware signature so you can evade this ban.

Spring RTS Engine

Sync Errors