Preventing cheating on Xbox in Kai

Kai Beginner Joined: 06 Dec 2004 Posts: 6 Location: Canada

Hi. As obvious by my post count I'm new here, but I've been into xbox development for awhile and am currently working on a couple different projects for the xbox platform and am an avid gamer.

One problem of the homebrew networking frameworks is they can't detect people cheating in system link games (see: the halo 2 trainer thread). I think it wouldn't be all that hard to eliminate this problem.

it requires an app running on the xbox to be communicating either with the local kaid, or the kai server itself. Prior to the game being loaded, a small authentication app is run. The app receives a seed from the server, and hashes the entire directory of the game against this seed. Then it returns the calculated hash to the server which has predetermined the proper sum. As long as the values match, the game is loaded. otherwise the room the person is in is notified of the discrepancy.

Speed is obviously an issue, as with how the files have to be hashed in order to be secure. The server can decide this by how often it decides to change the seed.

Legality is also an issue, since most xbox apps cannot be freely downloadable. However, the openxdk is gaining ground rather quickly. the only thing it's missing is networking capabilities that could make this all automatic. Heck, to be honest if people were willing to manually enter into their xbox the seed string (via controller), then type back into the chat the calculated sum, people could today be running secure games. I don't suggest this become the norm, but for tournament games or serious rooms people could enforce the rules.

there are still a lot of holes, ie if someone modified the authentication app to hash against a clean copy of the game but then run a modified copy, this would fail. or if people swapped discs after authentication to a burnt, modded copy of a game, again this would fail. reboot-on-eject and using a hash of the application itself in the calculation could hinder these activities, though. EDIT: another component of the hash should be the MAC address. this would prevent people from authenticating on one xbox, and switching xboxes to a modified copy of the game.. oh wait.. new bioses allegedly can change the mac address (ie, the ind-bios - I think it can do that possibly.) Still, thought I'd add that since it or something close to it could still be used.

comments? ideas? people more familiar to the inner workings of the kai protocol probably have a lot to say, and I'm interested in developing a more authenticated protocol so we can again play games with implied trust.

Posted: Tue Dec 07, 2004 8:42 am

Those are some good ideas, but I think the main difficulty stems from the fact that xlink is a free and legal alternative to live, that anyone can use. In order for your system to work, you would require everyone who wanted to play secure games to:

a. Mod their xbox (hard or soft, it doesn't matter)
b. Wait for a lengthy amount of time for the checksum to be calculated.

(a) is a very harsh restriction, and (b) isn't very nice either, especially if you're loading the game from DVD. You can minimize the scan by having the kai servers specify which files to scan on a per-game basis, for instance on Halo 2, just scan the executable and the MP map files, but that's still several hundred MB.

If Kai someday evolved into an Xbox Live spoofer, then it could invoke the same verification routines MS uses. I don't think a tunnel app will ever be able to eliminate cheating, however. It would be nice if we could find a way, though. Smile

Joined: 30 Jul 2006 Posts: 0

There are 2 sorts of cheating on Kai.

First, config file editing. Not a lot we can do here - I understand your idea re. hashing the game directory - but sadly, all they would need to so is start the clean game, hit reset, popin a DVD with the hacked one one - and the kaiEngine wouldn't know any different. We're always going to struggle against this type of cheating, imo, but I am, as always completely open to suggestions.

Secondly, cheating with trainers. I've spoken to the guy who is responsible for the Evox trainers, and he wasn't aware that his trainers made cheating possible in Halo2, for example. We're looking into ways in which he can disable system link / change mac address in future releases.

Thanks for the post thought - interesting idea - perhaps we should dig deeper into the whole issue in general..

TD

Kai Beginner Joined: 06 Dec 2004 Posts: 6 Location: Canada

Thanks for the comments, both of you made extremely valid points I hadn't fully considered.

I'll continue the random conceptualizing of a security schema, but it's definitely not a very easy task to accomplish.

Cheers,
Tom

Posted: Tue Dec 07, 2004 8:06 pm

Also there's a third form of cheating: glitch exploits. I've never seen someone on Kai do it, but people on Live have complained about Halo 2 cheaters intentionally lagging the game by pressing the standby button on their modems. This causes such interesting effects as flags disappearing from their post and reappearing in enemy hands in the opposite base, or everybody "waking up" dead after the connection is restored.

If this cheat works on Kai, perhaps this could be addressed by logging them out of the orbital server after a given threshold of inactivity? Or is their a gentler way of booting them out of a game?

The timing of this would be tricky, as it only takes a few seconds to snatch a flag and move into cover. But if implemented it may make for some interesting possibilities, for instance:

Host stress analysis - A new status mode called rated-host, to add to the list of looking/hosting/dedicated. The orbital server would detect when a host begins having trouble keeping up with clients, and then stop allowing additional clients to connect. This way, people with slow DSL connections wouldn't get 15 people connecting and lagging it up. Also, people can join a rated host arena and be ensured that whatever game they joined would be playable.

Of course you'll always have lag hiccups when other processes consume b/w on the host's network, but it may be worth an experiment to see how effective it is. That is, if the coding on the back end isn't overly complicated.

Posted: Tue Dec 07, 2004 8:18 pm

I like this topic and that many agree that it could become a larger problem then it already is.

I do think it belongs in a diffrent section of the forum though so i am moving it to general xbox.

Posted: Wed Dec 08, 2004 2:57 pm

Yes it would be nice be able to have some kind of checksum before the game loaded to see if trainers were enabled.

What I have done to help eliminate or find cheaters is to disable all over sheilds on the games that I host that way if you come across someone who has oversheilds then you definetly know that they have a trainer enabled and can take further action without them accusing lag for the problem, and so far it seems to help.

Maybe if more honest players would do this then we could make these cheaters think twice about using trainers.

Also, maybe putting up a post in the main arena stating that all cheaters will be banned and that some players are setting the game options to help identify people using trainers.

Just my 2 cents worth.

Thanks and have a great day.

Kai Beginner Joined: 06 Dec 2004 Posts: 6 Location: Canada

I have another idea, sort of a modification of something myself and a friend were working on..

we're looking at the system link authentication, and basically.. it's a public key scheme where both xboxes generate a public/private keypair. Using these keys they share a secret, namely a DES key. The remainder of the game traffic is encrypted using this game key.

what we've done is disassembled the XBE and are attempting to force our client to generate the same public/private key pair each time, and generate a known value. If we can do this, then we can sniff the DES key and begin to interpret game data, something that has been impossible to date.

sniffing game data could lead to an obvious method of detecting a cheater, if their stats are above norm or causation seems to be lost on them.

(sniffing game data also leads to a lot of new cheats, but it's so damned interesting we're going for it in either case; it will be hard for people to create cheats for this anyways).

Posted: Wed Dec 08, 2004 4:52 pm

Good idea, but aren't you know getting into legal issues re-writting the . xbe or will your program be a stand alone program. Which then brings us to another question, if you can get this to work then wouldn't all kai users be required to download this program in order for them to play with each other which in turn they would have to mod the xbox's?

Like I said, good idea but I dont think it would be very economical, so to speak.

Kai Beginner Joined: 06 Dec 2004 Posts: 6 Location: Canada

EDIT1: originally this post was talking about modifying the client and what would be required for it would work, but forget it.. I just solved the entire thing without modifying a client.

EDIT2: fixing my ascii Smile

Code:

A ====*=====B
|
E

In a normal situation, we have Alice and Bob talking to each other directly, and Eve is standing by listening. Alice and Bob generate a public, private key each. The public keys are sent to one another, so they can encrypt secure messages back and forth. Eve only gets the public keys so Eve can only encrypt messages and cannot tap anything. This was the model I was thinking of previously when I was saying we have to modify the clients to tap the conversation. I was wrong.

Our situation is not like that above. Alice and Bob do not have a direct path to one another, and Eve is not a passive monitor.

A===E===B

^ that is our situation. E is directly in the middle.

So. What does this mean? Eve actually has complete control. What Eve does, is..

Eve generates her own public/private keypair.
When Bob attempts to transmit his public key to alice, Eve saves his public key, and replaces his key with her own before passing the packet to Alice.
When Alice attempts to transmit her public key to Bob, Eve saves her public key and replaces her key with Eve's key before passing the packet to Bob.

Now, between Alice and Bob they generate the DES key. However, each message they send can be read by Eve, since they're both encrypting using Eve's public key. So let's say it's Alice's job to generate the DES key. She generates it, then encrypts it using what she assumes is Bob's public key (but is secretly Eve's). She sends this to Bob via Eve. Eve intercepts this message, decrypts it using her own private key, saves the DES key, encrypts the message using Bob's public key, and sends it to Bob.
Bob decrypts and now they _ALL_ have the DES key, and neither Alice nor Bob are the wiser.

Now Eve can go back to passive monitoring with the DES key, and does not have to continue modifying packets since they're now only encrypted with the shared DES key.

We have a couple things to still fix, mainly the hash algorithm (each packet is hashed) however the fact of the matter is, since we're a direct man in the middle we can effectively stop alice and bob from sharing a secret.

Once exams are done we'll start looking at applying this.

Laughing

Posted: Wed Dec 08, 2004 5:41 pm

Very well put. How will this configure in with lag during the game or would this pre-scan, so to speak, before the game starts and then cancel out.

Once you get this going and you need help testing this out, let me know and I will be more than happy to help in anyway I can, to get these worthless cheaters..

Kai Beginner Joined: 06 Dec 2004 Posts: 6 Location: Canada

Sorry Apache_1 you replied to my message while i was re-writing it Smile

(however the new message is a much cooler idea)

Posted: Wed Dec 08, 2004 5:59 pm

K, so once you think you have this going let me know and we can then try it out on kai and c if it works.

Posted: Wed Dec 08, 2004 9:22 pm

We're watching this closely and checking for developments..