Code: Web Hiscore module or include file

**Michael Hartlef** · 18-09-2008, 11:40

Ok, here is the next thing that imho doesn't depend on the type of game. I think a generic webbased hiscore module or include file would be great to store results of a game onto a webspace and so reload them into the game. It should have this functionality:

1) Store a hiscore into a list onto a webspace
2) Load a hiscore list from a website

If you would like to work on this then please say so.

Michael

**ErosOlmi** · 18-09-2008, 13:32

That is something I was thinking about since a lot of time.
Develop it is quite easy but the hardest part was to think a system where it is not possible to cheat: I do not want false scores. Of course if we release obfuscated or bundled code it is more easy but if it is source code everyone can cheat it.

I will think on that because I would like to have it as native thinBasic official module and serve the web connection directly using thinbasic.com domain.
My original idea was to create a sort of certificate system able to certificate and recon both the game (and game versions) and the user sending results.

**kryton9** · 19-09-2008, 01:04

Mike, having a scoring system is a great idea and something I think we all have been thinking about, but as Eros mentioned... with access to the code, it would be easy for someone to cheat or even worse cause problems. I will be very much interested to see any solutions Eros comes up with.

**ISAWHIM** · 30-09-2008, 11:45

They get assigned a LOGIN_ID from the server, and they have to make a PASSWORD.

The server stores the PASSWORD as a SHA1. A unique ONE WAY KEY is sent back to them, using the SHA1 and our ONE WAY KEY.

When they upload, at the LOGIN_ID & PASSWORD, only the SHA1 is sent at first. If the SHA1 they send, matches the SHA1 we have... The process continues...

They use the ONE WAY KEY to encrypt the data, and send it. We use their ONE WAY KEY (Which is our key, and their SHA1), with our key, to decrypt the data. (Another SHA1 of the data, sent with the data, would confirm if it was valid.)

They use the INI file to play the game, and see recorded scores, but they ALSO record the undecryptable result, via the game play, not the INI. (For uploading purpose, if desired.)

You can simply request the "High score", to keep it simple. Any score lower than the high-score, is not encrypted.

(Remember, this is encrypted with the unique key... based off the name. So "Joe" can't use "Fred's" key to upload his score for a tie, or to cheat.)

**kryton9** · 30-09-2008, 16:16

Also another consideration is changing the source code to cheat for the game, I guess some sort of date check on the version of the program to make sure it has not been modified before it figures out the scores and sends them via the encrypted keyed format to the server.

So checks would be needed for:

1. The Game Source Code is not altered from the official release. That is only the official released version is verified before it can send the scores.
2. The scores can't be tampered with once calculated by the Game.
3. The upload to the server is secure and can't be altered or manipulated.

Are there any other steps where misdeeds can be done?

**ErosOlmi** · 30-09-2008, 18:41

Very very interesting.

So far the problem was not how to send, encrypt, verify data but how to be sure that the score was cheated when the game is released as source code. Having the sources everyone can change and add whatever code to cheat.

But if the game is distributed with a GAME CERTIFICATION FILE based on the original game source code ... a possible Hi Score module can check if:

GAME CERTIFICATION FILE exists
if exists, check if game source code is still unchanged (so the original one)
at that point the process of sending high score can take place even without too much complex data encription/verification

I will think about it.

Thanks a lot
Eros

**Petr Schreiber** · 30-09-2008, 18:51

The idea of hash key for source code seems ok to me,

I guess it could guarantee the code is the same.

Petr

**Michael Hartlef** · 30-09-2008, 21:38

Nice! I like what you guys talking about. Keep on going and I'm sure we will have something nice comming.

**ISAWHIM** · 03-10-2008, 04:14

Have two versions... Certified and Open

Open can only connect to the Open server...

Certified is a "Special" version that you compile with a KEY inside.

You can have a "TARGET VALUE", that PHP can find, and alter, or add to the file, prior to them downloading it.

If that file does not match a key on the server... it is invalid, and the game switches to the Open server for playing.

EG... The part of the program that holds the "Version" "Creator"... etc...

The KEY would be injected into there, so it could be found by PHP and a REPLACE is done, with an equal sized value.

Sure, they could HEX the EXE value... but you could do a SHA1 on the thinbasic file, from the EXE prior to loading. (That would tell you if they are using a valid key, with a modified thin-basic program. They could TECHNICALLY... modify the key, and run the program, but interrupt the loading of the files, after extraction, and replace the normal extracted code, with the modified code, while another file is extracting from the bundle.)

Other than that... they would have to actually alter your EXE by decompiling it... (If they are THAT serious about it.)

You could just kill a key of a cheater. (They would need to keep getting new keys. Since it would be pointless to give another person's key the high scores.)

The OPEN version would just use the standard thinbasic EXE, and any valid code. It would be up to them, to provide a security measure. Or... you could create a "Program certify program", which would create a similar setup, by doing the same modification to the bundles they make. Again, they would have to keep-up with the security and records, and generation.