Widget signing gadget (request)

[CarRepairer]

Noob question: let's say hypothetically, spring wasn't GPL. Now let's say every time there's a spring release, a closed source fork was created with some encryption code known only to the high devs. This "secure" version doesn't affect the development branch so people could still contribute, but it would refuse to sync with any (including hacked) versions of the open source branch. Would that effectively solve the problem?

[smoth]

talking to the devs it was believed by someone(I forget who) that if you needed a secret fork then your code was not that secure to begin with. i don't agree with that but there are decompilers and many other ways to dig into source for an exe...

[Kloot]

This "secure" version doesn't affect the development branch so people could still contribute, but it would refuse to sync with any (including hacked) versions of the open source branch

Any and all hacks (which, according to some people's definition of "hack", includes widgets) would by definition be in unsynced code. Thus the "secure" version would have no way of detecting them and saying "bad client, you do not get a syncookie". Encryption does not and can not solve this.

If the "secure" client contained modifications in its synced code section wrt. the open client builds to break sync on purpose, so as to only allow other binaries with the same synced "signature" in multiplayer, those could also be isolated and then faked by the "unsecure" clients. To a sufficiently motivated person, no program is closed source.

[jK]

Something like that breaks the GPL.
Also it would just make the build process of spring more complex as we would have to deliver binary linux builds etc., and an intransparent buildprocess is never good.

[CarRepairer]

Something like that breaks the GPL.

I know, that's why I said if spring was hypothetically not GPL. This question was purely out of curiosity

If the "secure" client contained modifications in its synced code section wrt. the open client builds to break sync on purpose, so as to only allow other binaries with the same synced "signature" in multiplayer, those could also be isolated and then faked by the "unsecure" clients. To a sufficiently motivated person, no program is closed source.

Of course anything if hackable as evidenced by warez. I was just wondering out loud if what I was thinking made any sense.

[smoth]

it would if people could not reverse engineer things.

[Argh]

There are other ways. Even if it's Open Source entirely, every day the Lobby clients could pass the latest sync keys to people, and without them Spring wouldn't play with others. Sync keys could edit sections of the engine.

So it would be Open Source, but rather difficult to hack.

Hackers would have to know what the sync keys expect, in terms of final signature, and that would be a moving target. They could hack it every day, using the same source, but it'd become rather difficult (in practical terms) to distribute it to lots of would-be cheaters. And a schema like that could have the algorithm building the sync keys as a closed-source tool, so that the sync keys aren't predictable from day to day.

It would still not provide perfect security, but it would make the barriers to entry for would-be hackers high enough that probably nobody would bother, other than demonstrating that they could, for the e-peen value.

Not that I'm advocating this approach in any practical sense, I'm just throwing out a theoretical. I see no real evidence that hacked executables are a major source of concern at this time.

[very_bad_soldier]

I am not totally sure if I have understand you right, but:
How would you prevent that a hacked executable would still generate the same "sync key" as the original exe? Sounds to me you want some sort of checksum for parts of the engine? If so, I dont think that would work.

[Argh]

How would you prevent that a hacked executable would still generate the same "sync key" as the original exe?

The engine wouldn't build the key, an outside source would build a small executable that would find the Spring.exe and alter it, so that it would express today's unique engine key.

There is no way to prevent hackers from finding the expected result of that operation and then switching out the Spring executable after passing the expected result back to other players, but it would require doing that every day, as opposed to once every stable release of the engine.

IDK, maybe that won't work- I'm not a security expert, so there might be some giant holes in that logic. Just thinking out loud about how other Open Source products attempt to secure themselves.

[CarRepairer]

I am not totally sure if I have understand you right, but:
How would you prevent that a hacked executable would still generate the same "sync key" as the original exe? Sounds to me you want some sort of checksum for parts of the engine? If so, I dont think that would work.

Yeah I also don't understand Argh's suggestion. But his concept of using closed source lobbies is an intriguing solution to getting around the the GPL license of spring. Not sure how it works though.

To clarify further on this subject there are two necessary challenges to overcome:

1) Spring should make its "unsynced codespace" be completely transparent to everyone in the game. My suggestion is that when it loads unsynced code, it transmits this code to all players.

2) Spring should not sync to other players unless the integrity of their build can be assured, verifying that (1) is in place and not discreetly hacked out.


Solving (2) is difficult because of spring's GPL license so I don't see a solution. Perhaps Argh's idea is plausible but I don't quite understand it.

Regarding (1) - I'm not sure I got a straight answer. In my mind this seems perfectly possible. Is it not? (If the answer is no, please explain to me why, but we are assuming (2) is in place).

Edit: For example:

you cannot police unsynced code.

Is this assuming (2) is not in place and if so, what if (2) was a reality. Is my suggestion in (1) then possible?

[zwzsg]

Argh: And how do you force wannabee cheaters to use your altered spring.exe instead of the regular Spring.exe?

[Argh]

Argh: And how do you force wannabee cheaters to use your altered spring.exe instead of the regular Spring.exe?

They wouldn't sync, in-game, when everybody exchanges sync keys.

The idea of a sync key is that it's some exterior application's alteration to some dead areas inside Spring itself that alter the MD5 hash when it runs. The application itself can be Open Source- the only part that would be closed is whatever seed is used to generate today's permutation, so that guessing the keys months in advance is impossible.

So the sync key would not be stored in some text files, like the ordinary sync is, but created when the game state starts.

If your hash doesn't match the other people's hash, you don't sync, and drop out of play, and the other players are told you didn't sync due to key issues (so that they can have you banned, if necessary).

I think that's as secure as you can make something that doesn't use a server-client model or more intrusive countermeasures (which are all, in the end, variations on this idea + memory monitors to prevent hackers from altering registers in realtime).

[aegis]

linux portability, and my lobby would reverse engineer the sync key and pass it to my modified executable so as to sync anyway.

[Argh]

Linux portability wouldn't be insurmountable, unless you can't write even a straightforward hex-editing executable that will run under practically every flavor of Linux, which I kinda doubt.

As for the Lobby thing... the Lobby doesn't know what sync key is expected, until it's already done the first time. It wouldn't know what MD5 result is expected from the sync key until it was generated by the engine, because that's engine side. So you'd get caught in the act, the first time every day, and that would be enough evidence to ban with, if it was a repeated offense.

And of course, the central server could use a similar system to reject Lobbies that aren't willing to adhere to the security scheme, so you could play with like-minded people only.

[aegis]

you can guarantee a similar hex pattern on every compilation of spring on every platform?

you can make a universal executable I can't decompile?

you can implement something in the lobby server without the dev's approval?


you're pretty good.

[Argh]

you can guarantee a similar hex pattern on every compilation of spring on every platform?

No, but wouldn't all x86 come out the same way? If not, then wouldn't Linux builds on x86 be identical to one another, so at worst we just need two builds of said executable?

you can make a universal executable I can't decompile?

You can decompile it, but it's pointless, as it would change every day. So therefore you'd have to decompile it, figure out where it's storing what gibberish today, out of a large number of potential places, and then derive the correct sync key.

All of that could be automated, but again, the issue there is that it would be obnoxious enough that it would be pretty good practical protection.

you can implement something in the lobby server without the dev's approval?

Well, that depends. Are we using uberserver yet, or is it still vaporware? And who says that you have to have sole control over commits to same?

I guess my overall response is that if you spent more time thinking about how to solve security problems instead of thinking up ways to defeat them, we'd have a solution by now. I know that cracking comes with the territory of what you're doing, but just shooting everything down is pretty pointless- if you have a better idea, let's hear it. Don't tell me that it's impossible- we use a lot of secure stuff every day that's Open Source.

Aren't we all on the same side here? Does anybody actually think it's better if Spring remains completely un-secure?

Other than the difficulties presented, which are technical and may never get solved... the moral argument is clearly in favor. I'm only arguing theoretically here, and I have no idea if this idea's worth anything, in terms of the technical side. There are probably ways to defeat it in the end, but a system like this has served Steam pretty well for years now.

[aegis]

vaporware

you want to stop using that word now.

And who says that you have to have sole control over commits to same?

no commit will last without my approval, and I'm not going to approve a heavily flawed and proprietary system.

You can decompile it, but it's pointless, as it would change every day. So therefore you'd have to decompile it, figure out where it's storing what gibberish today, out of a large number of potential places, and then derive the correct sync key.

not really pointless - I just need to point it at a valid spring.exe and diff it before and after.

I guess my overall response is that if you spent more time thinking about how to solve security problems instead of thinking up ways to defeat them

my solutions didn't really require thought...

[Argh]

Is it what people are logging into right now, or not? I haven't followed this issue for a few months. Last time I checked, it was "any minute now, aegis will finally release something".

Anyhow... my point here is that if you have a better solution, let's hear it. Otherwise you're not contributing a lot here.

[aegis]

by your logic, pure is vaporware.

[Argh]

Hmm. Software that's available and released and has players vs. a product promised for over a year?

I think not.