Let's imagine we have a cheater with the knowledge about Stars! files decoding/structure. What kind of unfair things that person can do? And the main question: what can be done to prevent possible cheating? Obviously there is no possibility to prevent all kind of cheating, so here I'll just talk about possible cheating issues related to broken files encryption/structure.

In general there are two type of possible cheating with Stars! files:

1. Getting normally invisible info from your own m file
Example (it was discussed already on the forum) is knowledge on what Mystery Trader would give to you if you catch him. Once MT entered known space your m file contains exactly knowledge on that, but Stars! never shows it to you. This is just an example, but there is much more sensitive info about the universe, which some players have in their m files, that is never shown by Stars.

There is two possible solutions:
1) Make this info available to everybody (so, cheater wouldn't get any advantage here).
2) Make it unavailable or useless for everybody (specifically make it unavailable or useless to cheater).

Personally I don't see any problem with allowing everybody to know what trader gives (thus Stars! creators decided to hide it, so let's keep it this way), but I do see a big problem with another knowledge, which definitely shouldn't be available (I'll keep details for a while, what I can say now is that it could be a mission critical and a game winner if used properly). So, the only reasonable way to avoid this issue is to remove that knowledge from m file right after generation (before player can even access his m file).
IMHO, the best solution here is a tool that will automatically zeroes such hidden info in m files (i.e. it would always looks like trader gives techs, but it would actually gives something different).

Let's say I have a tool (I'll call it cleaner), which can find and remove any sensitive info I was able to find without knowledge of m file password. All other info will be kept in m file unchanged, I can obviously give it to Ron, so he can use it on SAH, but the question here is how to test it? I've done a number of tests and it works just fine on my old games, but I cannot state that it's bugs free. The funny thing is that anybody who ready to test this anti-cheat tool would need to know the way to actually cheat to be able to check that it actually works. Any thoughts/comments/suggestions?

2. Getting advantages of game bugs (using an x file to perform actions that would be impossible to do normally)
The best example here is a free pop hack done by using memory editor to get a lot of pop from thin air. Technically, this hack results in adding a command into x file, which orders host to load/unload more pop (or minerals) that your planet/fleet actually have.
I don't see any possibility to prevent this other than automatically verify each uploaded x file for things like that (so, it makes impossible to cheater to actually use it).
The best solution here is to have a tool that will load xy, hst files and then verify each player actions from x file.
Technically speaking there are just 23 possible actions in x file (for example: load/unload, change design, change production queue, change waypoints and so on). And about 17 of them could be destructive (could be used by cheater to get unfair advantage).

I have a prototype of the tool (let's call it verifier) that verifies x file actions, it's more complex than cleaner, since it have to parse all file info, while cleaner just needs to parse and change a couple of blocks. So far, it's only verifies free pop hack (i.e. load/unload action), but I'm working on other actions to be verified. And again the most tricky question is how to test it (anybody who would test it needs to be able to learn on how to cheat)? Any thoughts/comments/suggestions?

It looks like I have to start creating a cheating files collection...

[Updated on: Mon, 28 February 2011 15:58]

Report message to a moderator

XyliGUN wrote on Mon, 28 February 2011 15:26

IMHO, the best solution here is a tool that will automatically zeroes such hidden info in m files

I second that.

You should probably ask Ron about it, since he would be the main user...

Suggestion: write a log of the changes/zeroings the tool does, just in case.

Quote:

I don't see any possibility to prevent this other than automatically verify each uploaded x file for things like that

Yes indeed.

Checking load/unload shenanigans would be great. Stomping bugs like the "free" starbase, the "starbase forces friends to attack eachother", the "dock armor overflow", the "pursuer fleet gets stuck" and similar would also be very good.

Did you start coding from scratch, or perhaps you used some older tools as starting point?

Report message to a moderator

Another interesting tool could be a racefile infodumper, to get complete race info in text / readable format, for sharing or archiving purposes. And the same for ship designs.

Report message to a moderator

I am always very interested when tools to prevent cheating get available. There is nothing more dishonorable to me than to have someone win a game by cheating. Or changing the rules of the game midway into the game.

I can safely say that I would never reap any benefits or even satisfaction from winning a game knowing I blatantly cheated. I guess I can't understand why other people would do it either... And expect them to do the same.

I know, wishful thinking...

Report message to a moderator

Report message to a moderator

Report message to a moderator

m.a@stars

You should probably ask Ron about it, since he would be the main user...

I will, but to just start thinking of deploying cleaner on SAH I need to find the way to test it, and this is where I need some good ideas. Currently I can only test it on my own (if I'd start teaching others on the ways to cheat... well, you know... I don't think it's a right way to go), which isn't enough. And I cannot ask Ron to deploy it on SAH, since it can damage someones m file (yes, there could be a backup of the original m files, just in case, and this way it could be tested in the real games, but I'd prefer to test it before it would affect someones game).

m.a@stars

Suggestion: write a log of the changes/zeroings the tool does, just in case.

Yep, will be done.

m.a@stars

Did you start coding from scratch, or perhaps you used some older tools as starting point?

Initially knowledge (encoding/structure), required to start working on these tools, was collected on and around SAH (so, at that point I was collecting what others already finds out). As of code itself it's started from scratch.

[Updated on: Tue, 01 March 2011 19:35]

Report message to a moderator

m.a@stars

Another interesting tool could be a racefile infodumper, to get complete race info in text / readable format, for sharing or archiving purposes. And the same for ship designs.

Well, this one could be done quite easily, but so far I'd concentrate on anti-cheating tools.

Report message to a moderator

magic9mushroom

Hmm... I assume the "much more sensitive info" is locations of other races' stuff, and what their designs are? Not that I'm a hacker, those just seem like likely ones.

It's more than sensitive, but let me keep it in secret until cleaner will be ready, so Ron will have a chance to prevent its' usage. Then I'll disclose what was that.

magic9mushroom

As long as the tool wouldn't actually patch Stars (hacking can be useful when setting up games, and a "hacker's game" may come up someday), then I think it's a good idea.

Stars! executable isn't affected at all. No patching, hacking, etc. Cleaner will just read m file, set everything that you shouldn't see to some sort of default values, keep all other data unchanged and than write new m file, which could be safely given to cheater - it would have nothing to steal, other than he already knows and can see in Stars! itself. Verifyer is more complex, since it have to parse all the data from hst file, than read each command from x file and analyse whether it valid or not. But it will only log if there is something wrong or not and return if file verification was succesfull, so no changes to any file will be done at all.

[Updated on: Tue, 01 March 2011 19:08]

Report message to a moderator

Report message to a moderator

Eagle of Fire

I'd advise against publicizing your results. Beside what everybody think (or may think), Autohost is certainly not the only place people play games together. Just a very quick example: any duels played without Autohost would be at risk. I am sure I do not need to remind you that we do have a duel club here... They are already at risk, to tell the truth... But by publicizing you take for granted that a lot more people would have access to what would otherwise be a very privileged information.

OK, I'll keep it in secret. Only Ron will know.

Report message to a moderator

Report message to a moderator

Report message to a moderator

Report message to a moderator

Report message to a moderator

[Updated on: Wed, 02 March 2011 18:11]

Report message to a moderator

nmid wrote on Thu, 03 March 2011 10:10

magic9mushroom wrote on Thu, 03 March 2011 01:02 I'm not saying you shouldn't use your tool. I'm saying you should add your list of hidden information in the .m file to the Known Cheats list. that would actually make the starsautohost server, the only safe place to play games/duels anymore.. A double-edged sword. If more people join and donate, great. If ppl join, but don't donate, more pressure on the server.

Are games not already run on what amounts to an honour system?

Has the Freepop Hack not been on the Known Bugs list for years?

[Updated on: Wed, 02 March 2011 20:30]

Report message to a moderator

magic9mushroom wrote on Thu, 03 March 2011 14:29

Are games not already run on what amounts to an honour system?

Pretty much. Its not a bad system imo.

Quote:

Has the Freepop Hack not been on the Known Bugs list for years?

Yes, although I had it in my head that it'd been fixed by jRC4 but that was the SS pop-steal. Given that a bug fixed version is extremely unlikely to be forthcoming tools such as this may well be the answer.

nmid wrote on Thu, 03 March 2011 12:10

that would actually make the starsautohost server, the only safe place to play games/duels anymore.. A double-edged sword.

Maybe not....


Feature request:
A tool that acts a wrapper for Stars.exe that allows creating new games and loading up the host dialog which suitable scrubs the new .m files as soon as they're created - using a password on the hst file that is not stored in a normally accessible way (perhaps a spare part of the hst file if there is any).

Something like

tool.exe -a game.def

to generate a new game and

tool.exe game.hst

to access the host dialog. The -g# parameter would also be useful.

As a further check it could have an option to only generate if all players are turned in.

Report message to a moderator

nmid wrote on Thu, 03 March 2011 00:10

that would actually make the starsautohost server, the only safe place to play games/duels anymore.. A double-edged sword.

But once the tools are deployed and tested, every host out there could use them. There would no longer be any need to hide sensitive info or tools, since there would be a safety net against cheating that nobody currently has.

Frankly, the sooner we break out of the stagnation in tool development that stems from the fear of opening the can of worms of boundless cheating, the better.

Report message to a moderator

m.a@stars wrote on Thu, 03 March 2011 09:24

nmid wrote on Thu, 03 March 2011 00:10 that would actually make the starsautohost server, the only safe place to play games/duels anymore.. A double-edged sword. But once the tools are deployed and tested, every host out there could use them. There would no longer be any need to hide sensitive info or tools, since there would be a safety net against cheating that nobody currently has. Frankly, the sooner we break out of the stagnation in tool development that stems from the fear of opening the can of worms of boundless cheating, the better.

I agree and I want those tools out.
(Especially that xylimerger.exe ! )

But it got me thinking, that means games have to played on secondary hosts. Any game played 1on1 would mean that it would be more vulnerable to these 'newly disclosed' hacks.

Though actually screw it..We'll face those problems when we come to it. Atleast it makes one method of playing more secure.

/clap.

Report message to a moderator

The issue is that Stars! is already on an honour system. Giving people more ways to break it isn't actually that big a deal.

I agree with m.a@stars.

And hey, this opens up possibilities too! You could have a privately hosted game with all these hacks (or some of them, if you're a wimp ) allowed!

[Updated on: Thu, 03 March 2011 04:18]

Report message to a moderator

I am not sure I like this hiding ostrich policy...

Sounds like typical American "let's do it and who cares about the rest of the world, we'll think about the outcomes later" thinking.

Report message to a moderator

[Updated on: Thu, 03 March 2011 17:43]

Report message to a moderator

Eagle of Fire wrote on Thu, 03 March 2011 06:11

I am not sure I like this hiding ostrich policy... Sounds like typical American "let's do it and who cares about the rest of the world, we'll think about the outcomes later" thinking.

LOL Okay, "typical American"... if you say so.
Stars!: born in the USA, Autohost: born in the USA
Except in this case it's the Russian Commander who is hacking the code and contemplating revealing the information.

Report message to a moderator

nmid wrote on Thu, 03 March 2011 05:05

Any game played 1on1 would mean that it would be more vulnerable to these 'newly disclosed' hacks.

Any game, played without any kind of cleaner / sanitizer tool, is already open to all kinds of things. With those tools at least some, or most games, can be protected.

It's time we abandon "security by obscurity" and opt for real security.

After that the game will evolve as it should have years ago to new heights, thanks to the new "advisor" tools, "merge/exchange" tools, AI tools, MM tools, "scenario" tools, MMORPG tools and whatnot.

Report message to a moderator