Encryption for Glest?

[Travco]

As I have recently noticed the memory values for all the major Glest stores for every single faction are completely open to be changed by a simple memory search.  For the simpletons, its being stored as WYSIWYG (what you see is what you get) format. As in, 100 wood is stored as 100 wood.

Should we encrypt some of these values to deter the most basic, and easy of hacks, from ruining the little online play we have?

Currently, there is no encryption what-so-ever, and a basic memory scan of the program would yield anything you want. I'm suggesting at very least doubling, or tripling the values before they are stored. By doing this most "lazy hackers" would just give up instead of checking all the ways that the values could have been stored. It's always possible that determined hackers will succeed and find the way around the encryption but at least it's deterred.

I'm sorry that this is a very nerdy code-headed poll but i'd really like to hear the opinions of the target audience so thanks, i'll be monitoring this topic to answer almost all of questions regarding this.

[ultifd]

Well first thing first (What? )
Not Glest...Glest is not being worked on anymore...but I guess we'll talk about it as in general 
only Glest Advanced Engine, and Megaglest...
---
I'm pretty sure someone either from GAE or MG would think about security, but right now it is more about stability and features for glest related stuff...
Security is very very important, but not into we start spreading Glest around...
---
When they actually do improve it, how though? 
Encryption...they would have to change a lot of "stuff" right, in the XMLs or the code... 
This is why it is probably going to be improved on...later though 
---
Very good idea though, good reminder. 
So in the end, I'm probably not going to vote yet...not for now.
Thanks though   
---
WYSIWYG?
Haha I only thought that would apply to HTML editors...   

[Travco]

First, yes I ment the newer versions of glest.
Second, it shouldn't use more than a few lines of code per value.
Third, no the creators didn't put any protections that I could find on mega-glest so judging that GaE is supposed to be easy-edit, I imagine there is no encrypted values.
Finally, I'm sure they're likley working on it, but as soon as multi player was introduced encryption should be already embedded to prevent easy. hacking.

Thank you for your support on the idea, any more questions? I have a smart phone, so ill be here all day.

[Gabbe]

I voted for complete encryption, people that want to mod could contact the forum instead of not becoming a member, it would help the community if we encrypted it, but then let people who could be trusted mod it. This could affect the Open Source ofc. but you`ll still be able to change the source anyways...

Im pretty sure noone from GAE or MG would think about security, it is a reason for Open Source, well, you`ll have to be a coder to do anything, but...

For scenarios perhaps some encryption would be good, and have a challenging campaign instead of some "challenging" coding. I would suggest full encryption and perhaps some kind of file format change to the XML for campaigns, and i would suggest forcing people that makes mods come to the forum and publish it.

[softcoder]

In theory it may sound good to do, in practise it is really a lower priority. Regardless of the level of security we implement, it is open-source, meaning anyone can compile and change as they please.

But you are correct that some simple tricks would at least deter "Script kiddies" and thus make things a little bit better. One thing we have considered for Mega-Glest is that the Server side will have some small level of security features to check that the client and server are "allowed" versions so that people won't use modified binaries for online play. Even that can be bypassed by experienced coders, but honesty is assumed to a certain level.

[Travco]

Thank you for your input soft, to what I can assume your on the exact same page as I am. and the additional server side checks would be great. Seriously thanks for the input.

[Gabbe]

mhm we don`t have many dishonest coders here...

What about login system?
Could help the encryption system...

[Travco]

Although a sign in system would be nice that isn't going to do much interms of protection of values during sessions. Nice idea though..

[Gabbe]

If you could link the forums accounts to glest....

[softcoder]

Logins don't protect applications, they just facilitate another technology to "slow down" hackers. Having a server-side checking system may offer the best amount of protection since not everyone can change its contents like they can the client. However people familiar with the "protocol" can still get past all the security in the world, all security does as a general principle is "Slow down" attacks.

[Travco]

I agree with soft, again I'm not suggesting anything crazy major, just slightly tweaking how those important values are stored.

[Gabbe]

mhm i didn`t express myself clear enough i guess, make the login system with moderators, and administrators, it is like report people who abuse the system, with those, it will be much more likely they are caught, link this to the forums and make sure the server always remember who is administrators, then it will slow them down very much, anyways, not high priority i guess.

[Travco]

Oh, well that's a much better idea, but this a encryption thread, not player moderator ideas, you aught to submit that as a seperate request.

[Gabbe]

iknow, still, i vote for full encryption, for scenarios and campaigns and stuff...

[Omega]

Actually, glest (and through inheritance, GAE and MG) has a method of doing this. Because of this, you must download the exact same techtree in order to play multiplayer. I never actually tested that for a long time, not since maybe last year when I forgot I modified magitech slightly and tried to play on online game, but I see no reason why anyone would remove it. While it is also possible for someone to download the source and modify it to prevent this check, I again don't see it happening (hard enough to find someone for multiplayer) and that would take a small degree of skill that apparently most people lack (we have a very small number of coders, all nice and honest  ).

I don't think encryption would work well here anyway.

[ultifd]

If you could link the forums accounts to glest....

Yeah...what Softcoder said.
another problem with that would be some people might not always have Internet access.
That would be listed as a CON when MG or GAE would be reviewed...if this was implemented 
Just sayin' 
----
Yeah, I don't know for GAE, but for MG, once we make multiplayer more stable...or make sure it is stable then this will be worked on...I guess 
----
semiOT:
Honesty, huh...
well that is a problem with now auto fog of war turned off in MG....
and in life. 
---
thanks.

[silnarm]

I see little if any point in doing this.

Map hacks cannot be stopped with the multiplayer architecture we have.

Memory hacks are of no concern.  You can change the values on your simulation only, changing your gold from 100 to 300 will only affect the game you are running, it will not change the value on the other peoples game, and so as soon as you issue a command that uses the excess gold, it will succeed on your simulation, and fail on everyone else's. End result? Sync error, game over.

Same goes for Omega's scenario, if your data only claims to be the same, and isn't really, you will just get an inevitable synchronisation error, because the simulations will not run the same.

Simply put, if you cheat in this fashion, you games will all end with error messages.

[-Archmage-]

I see little if any point in doing this.

Map hacks cannot be stopped with the multiplayer architecture we have.

Memory hacks are of no concern.  You can change the values on your simulation only, changing your gold from 100 to 300 will only affect the game you are running, it will not change the value on the other peoples game, and so as soon as you issue a command that uses the excess gold, it will succeed on your simulation, and fail on everyone else's. End result? Sync error, game over.

Same goes for Omega's scenario, if your data only claims to be the same, and isn't really, you will just get an inevitable synchronisation error, because the simulations will not run the same.

Simply put, if you cheat in this fashion, you games will all end with error messages.

Sounds like the best hacker protection ever, IT ACTUALLY WORKS!

[Travco]

Well perhaps the sync errors will deter most online hacks, however in terms of offline hacks there still is no protection. Perhaps laying it as a secondary line of defense for online isn't as important as laying the first line for offline play? The idea still stands use. And may i also suggest adding the protection of floating values?

[Gabbe]

I don`t care much for the offline in glest, really, but for our LAN events...

[John.d.h]

Why should we care if somebody wants to cheat in an offline game?  You're not going to hurt the AI's feelings, you know.

[Gabbe]

Why should we care if somebody wants to cheat in an offline game?  You're not going to hurt the AI's feelings, you know.

'

if that were possible, my AI would have taken suicide a long time ago...instead...sometimes it goes lazy...but offline isn`t really a matter, if you cheat there, you`ll only not learn how to play and in the end you`ll end up loosing Multiplayer games, i learned that from AoE.

[Travco]

Well period point its a good idea that should be put into practice, as a secondary defence online, or as a overall defence strategy. Just a good idea that's all.

[zombiepirate]

Voted for "No, hacking it is fun".

As far as offline goes, if someone has more fun cheating then playing "fairly" I see nothing wrong with it.

Online, as silnarm already said, you'll get a sync error. Even if you didn't crash the game, the online play glest does have is mostly done among friends over LAN. Friends playing each other over LAN generally find out quickly if one of them is cheating. In the case of a tournament game over WAN (assuming the game stays in sync through the hack somehow) hacking may be a problem, but in this case I still don't think encryption is a viable solution (read: glest is open source).

However, if encryption still makes it onto the todo list then I think it should be made optional. For offline play my first argument still applies, for online play if one client has it on then all clients would be required to have it on.

[-Archmage-]

I could care less whether anyone hacks their own offline game, go right ahead, cheat all you want.