Widget signing gadget (request)

[JohannesH]

Regardless, you can block user widgets from your mod if you like.. you don't need any engine changes for that anyway. Its possible to hack around that by making changes to the engine but there's far worse cheating they could get up to by hacking the engine once you've forced them down that route.

Um, because you can do worse cheating with hacking exe, you should allow widget-based cheating? Of course custom widgets are not cheats if they are allowed by the game - but its silly to say that they should always be allowed. Could you imagine SC having customisable UI for example?

[Tobi]

Regardless, you can block user widgets from your mod if you like.. you don't need any engine changes for that anyway. Its possible to hack around that by making changes to the engine but there's far worse cheating they could get up to by hacking the engine once you've forced them down that route.

Um, because you can do worse cheating with hacking exe, you should allow widget-based cheating? Of course custom widgets are not cheats if they are allowed by the game - but its silly to say that they should always be allowed. Could you imagine SC having customisable UI for example?

Um, you didn't read what he said.

Disabling user widgets is already possible for a game developer (IIRC PURE does this). No need to fix/add anything.

[SinbadEV]

Could you imagine SC having customisable UI for example?

Wow, yes I can, can you imagine how crazy-nuts games would be if pro-SC players could queue orders and set up special selection hot-keys and store last-seen hitpoints for out of range units or auto set zerg spawn to become specific units after they are generated or create an overlord when your population reaches a certain number... never mind, that would be really frighting.

[zwzsg]

Could you imagine SC having customisable UI for example?

Never played it much myself, but I heard SC had customisable GUI as one of its feature, yeah.

What, by SC you didn't mean Supreme Commander?

[eyu100]

The original reason wjhy I requested a widget signing gadget was so that a mod maker (Caydr, maybe) could allow certain widgets without actually including them in the mod, saving disk space and screen space in the widget selector. So:

Is there a way to get the code of a widget as a string? If there's not, it's pointless to try to make a widget signing gadget. If there is, anyone who can implement RSA or another digital signature algorithm can make the widget...

EDIT: I don't know Lua, but I can write pseudocode.

Here is a description of the algorithm used: The public key (which everyone knows, and needs to be included in the widget) is a pair of numbers (n, e). You do not have to come up with the key--it is created by the mod maker. Usually, the public key is used to encrypt a message and the secret key (which no one except the mod maker should know) is used to decrypt it. In this case, the secret key is used to encrypt and the public key is instead used for decryption. The thing being encrypted is the hash of the widget and the result of the encryption is the signature. To verify the signature, it is decrypted with the public key. The result of the decryption must match the hash of the widget.

A very simple gadget can be made that checks each widget's hash against a list of allowed hashes. The disadvantage of this method is that a new version of the mod must be released every time the mod maker wants to allow a new widget. Pseudocode for the simple gadget:

Code: Select all

allowedhashes[] = {...}

bool allowWidget(string widget)
{
    hash = hash(widget);

    for (int i = 0 ; i < numelements(allowedhashes) ; i++)
        if (hash == allowedhashes[i]) return true;
    return false;
}

Here is the slightly more complicated (but more flexible) version. Note that all widgets for this mod MUST have two parts: a comment on the first line with a signature, and the rest of the widget. The signature only signs the second part, not the whole widget (otherwise, it would be nearly impossible to create a valid signature). Anyway, here is the pseudocode:

Code: Select all

pubkey_n = (...);
pubkey_e = (...);  // mod maker's public key

bool allowWidget(string widget)
{
    signature = (signature)(firstline(widget) - "--");
    hash = hash(widget - firstline(widget));

    if (hash == pow(signature, e) % n) return true;
    else return false;
}

(the variables n, e, signature and hash are all integers)

[Caydr]

Don't bother, it's really pointless. I've decided to give the current widget locking system a more serious try, in combination with including the most frequently-used non-cheating widgets. Hopefully it will prove to be adequate.

[eyu100]

Don't bother, it's really pointless. I've decided to give the current widget locking system a more serious try, in combination with including the most frequently-used non-cheating widgets. Hopefully it will prove to be adequate.

I just edited my post with an example right before reading this.

EDIT: There is a widget locking system?

[Kloot]

eyu: yes, but no. (It doesn't amount to much.)

Also, while nice, your system still falls apart because a gadget checking locally-installed player widgets has to use unsynced code to enumerate them.

[eyu100]

eyu: yes, but no. (It doesn't amount to much.)

Also, while nice, your system still falls apart because a gadget checking locally-installed player widgets has to use unsynced code to enumerate them.

I am aware that the gadget is possible to circumvent (like anything that restricts widgets), but I think the gadget will make circumvention harder. Also, what do you mean by "yes, but no"?

[lurker]

Yeah, you can definitely put an RSA module in the widget handler, but show me a mod maker that wants to generate a key pair and sign widgets...

If you're interested in code search for my post a while back on video, it makes md2 hashes and verifies via RSA.

[Kloot]

eyu: the lock mechanism can be bypassed by changing a single character in Spring's source (or a single byte in its binary). Hence, [yes] there is already a way of locking out user widgets, but [no] its effectiveness is near-zero. For anyone with programming ability, your sketched system would imo not be any harder to neutralize. For others, they can go to one of the former, as now.

[Regret]

eyu: the lock mechanism can be bypassed by changing a single character in Spring's source (or a single byte in its binary). Hence, [yes] there is already a way of locking out user widgets, but [no] its effectiveness is near-zero. For anyone with programming ability, your sketched system would imo not be any harder to neutralize. For others, they can go to one of the former, as now.

Maybe if you stopped repeating over and over how to bypass the lock very few people would actually know about it.

Cheaters always find a way to cheat, regular players will not recompile or edit their .exe

The lock works fine, it defines what is cheating and what is not for a game.

[REVENGE]

eyu: the lock mechanism can be bypassed by changing a single character in Spring's source (or a single byte in its binary). Hence, [yes] there is already a way of locking out user widgets, but [no] its effectiveness is near-zero. For anyone with programming ability, your sketched system would imo not be any harder to neutralize. For others, they can go to one of the former, as now.

Maybe if you stopped repeating over and over how to bypass the lock very few people would actually know about it.

Cheaters always find a way to cheat, regular players will not recompile or edit their .exe

The lock works fine, it defines what is cheating and what is not for a game.

I believe his point is that only those who would be capable of modifying it in the first place already know how to do it.

[eyu100]

If the gadget defines what is and is not cheating, it would be a large improvement. Currently, if a player extra info using GhostRadar, he/she may or may not get in trouble, but if the mod has a gadget that doesn't allow GhostRadar hacking around that would justify banning them from the autohost, or even from the server.

[REVENGE]

If the gadget defines what is and is not cheating, it would be a large improvement. Currently, if a player extra info using GhostRadar, he/she may or may not get in trouble, but if the mod has a gadget that doesn't allow GhostRadar hacking around that would justify banning them from the autohost, or even from the server.

No actually that's retarded.

[lurker]

Disk space is not an issue for a couple text files.
If the menu is clogged, use a better menu.
The only real reason for this is to add widgets without a new release, and have fun running security audits on every widget instead of just patching the VFS calls to be archive-only.

[Regret]

No actually that's retarded.

No actually he is right, cheating/hacking is bannable afaik. It's the same as modifying your spring to maphack.

It's just a matter of proving that someone is cheating to enforce it.

[CarRepairer]

I have come up with a foolproof anti-cheating system.

Go to the person's house. Verify they are using legit spring and allowed widgets by setting them up yourself. If they resist, hit them with a hurtstick.

There is absolutely no way to crack this system. Oh wait, what if they have a bigger hurtstick? The hurtstick system has been cracked before it was ever implemented.

[aegis]

and I can legally shoot you if you're threatening me or my family in my home afaik

[tizbac]

No actually that's retarded.

No actually he is right, cheating/hacking is bannable afaik. It's the same as modifying your spring to maphack.

It's just a matter of proving that someone is cheating to enforce it.

The problem is that you cannot prove it without using DRM or similiar shit , and DRM is not compatible with open source cause it's security is based on non-disclosure.
There are things like Punkbuster , that checks for the integrity of memory & exe , but they wouldn't work on spring cause it changes executables too frequently and it has a very high false positive rate, and it is commercial

Maphack isn't that serious, on other commercial rts that syncs by sending unit positions, they can also use speedhacks, unit spawn hacks etc.

Maphack on spring could be avoided by calculating LOS on server side but needs a lot of extra calculation on server to determine when it's necessary to send the gamestate of an unit and it will take a lot more bandwidth