Open Sourcing Soldat

[L[0ne]R]

How do you keep people from creating clients and servers which give them unfair advantages? 

I know this question wasn't for me, but:

If a game is open-source - there's still a place for closed-source security elements, server and client verifiers and such.

You can't keep people from creating such things, but you can prevent their use in public if we have a closed-source anti-cheat (BattlEye?) for both client and server if necessary.

[Veritas]

How do you keep people from creating clients and servers which give them unfair advantages?

Anti-cheat measures, same as any other game? Closed source doesn't prevent them from doing this in the first place, and while open sourcing the code does make development of hacks easier, it also makes developing good security measures easier as well.

itself structure is not coded to be "standard" and allow other ppl understand.

If this was true, the game wouldn't have been handed over to eC. Since he can make the transition to developer, there's no reason others can't do the same and make it easier for others to follow in their footsteps.

Like, openSoldat, will be coded to be opensource from the very start. So if Soldat become nice to play after some releases, oS will be even greater after some feedback. Just need a kick to things start on roll.

oS has been going for awhile now, and hasn't seem to built any momentum. Soldat proper has the momentum needed to get development done.

[FliesLikeABrick]

If BattlEye can successfully prevent or at least alert clients and servers when a non-default binary is being used, then I guess that'd be ok.  I guess my faith in being able to reliably catch and report these is not all that high.


All other things being equal, I'd rather see a completely open-source project like openSoldat succeed than Soldat be open-sourced at the risk of destroying it.

[SpiltCoffee]

Keep certain core components secret or somehow encrypted (like BattlEye's integration itself), so that no one except the official development team can actually build it. That way, people can still make contributions to the code, but the only thing you'd have to worry about then is possible forks that would probably be very unplayable because it's missing things the official version isn't.

[Veritas]

If BattlEye can successfully prevent or at least alert clients and servers when a non-default binary is being used, then I guess that'd be ok.  I guess my faith in being able to reliably catch and report these is not all that high.

I don't think anyone is suggesting that binary validation be the primary check to make sure things are legit, because that's pretty easily faked.

[jrgp]

If BattlEye can successfully prevent or at least alert clients and servers when a non-default binary is being used, then I guess that'd be ok.  I guess my faith in being able to reliably catch and report these is not all that high.

I don't think anyone is suggesting that binary validation be the primary check to make sure things are legit, because that's pretty easily faked.

How easy is faking the checksum of a binary?

[Veritas]

How easy is faking the checksum of a binary?

It depends. If we're talking about client-server communication: At some point the client says, "Hey server, the hash of my binary is: sha-1(soldat.exe)." You can easily change this to send a precomputed hash of a valid soldat.exe, rather than the hashing functions result. There are tricks you can play to make things harder to fake, but it's one place that being open-source makes things difficult to hide.

For something like BE hashing the client: This is harder, but still doable. For instance, patch the DLL that handles the hashing function to something like this:

Code: [Select]

string sha1(string filename){
  if(filename.equals("soldat.exe"))
    return "abc123"

  [calculate as before]
}


[FliesLikeABrick]

If BattlEye can successfully prevent or at least alert clients and servers when a non-default binary is being used, then I guess that'd be ok.  I guess my faith in being able to reliably catch and report these is not all that high.

I don't think anyone is suggesting that binary validation be the primary check to make sure things are legit, because that's pretty easily faked.

Right, I agree.  So I'm asking you how else it would be accomplished

[Veritas]

If BattlEye can successfully prevent or at least alert clients and servers when a non-default binary is being used, then I guess that'd be ok.  I guess my faith in being able to reliably catch and report these is not all that high.

I don't think anyone is suggesting that binary validation be the primary check to make sure things are legit, because that's pretty easily faked.

Right, I agree.  So I'm asking you how else it would be accomplished

Server validation of what the client is sending (e.g. if the client is saying he has +30 health, something is wrong here), continued BE integration to detect memory hooks, and active developers fixing exploits.

[FliesLikeABrick]

Right, and that's how Soldat should have been written from the start (which it isn't, which is one of my reasons for not open-sourcing it).

What about preventing other modifications being modded in client-side that improve the player's experience unfairly? 

Also, largely I've been talking about making server side modifications.  What you said is great and all, but what keeps someone from modifying the server source code such that it allows modified clients from a particular IP address or client, or gives certain players unfair advantages?

[Veritas]

Right, and that's how Soldat should have been written from the start (which it isn't, which is one of my reasons for not open-sourcing it).

I understand that reasoning, the problem is what you have right now is simply security by obscurity (which isn't really secure at all). I would have no problems if Soldat was phased into open source: have a couple of developers join in, fix the obvious exploits, and continue to open up the code.

What about preventing other modifications being modded in client-side that improve the player's experience unfairly?

My assumption is what BE does is monitor memory hooks, and this would continue to be necessary. I believe that PunkBuster plays a similar role with Quake 3 (which is open source).

Also, largely I've been talking about making server side modifications.  What you said is great and all, but what keeps someone from modifying the server source code such that it allows modified clients from a particular IP address or client, or gives certain players unfair advantages?

Can't you already do that with server side scripting? And I'm certain you could do that without scripting by editing the binary.

[FliesLikeABrick]

Right, I agree on all points. 


However
 1) servers indicate when scripting is enabled, so at least an end player will know when it is possible that something is being done
 2) This would pretty much bring an end to tournament play as we know it since we would no longer be able to trust any server binary anywhere.  at all.  Unless you can come up with a means for the clients to know that the server binary is trusted/verified.  Yes, in *theory* this could be done with modding the server binary now, but open-sourcing it would make it infinitely easier and infinitely increase the number of ways in which the server binary could be added (and increase the complexity of the evil things that can be done, instead of just nulling out parts of the binary or making simple changes)

[Veritas]

1) servers indicate when scripting is enabled, so at least an end player will know when it is possible that something is being done

I doubt anyone checks this unless they're doing SCTFL, but true.

2) This would pretty much bring an end to tournament play as we know it since we would no longer be able to trust any server binary anywhere.  at all.

Dude, what?

I've done a lot of competitive play. I can't speak for Euros and their servers, but almost all of all the matches I've played against other NA guys have been on either U13, fracs, or nasoldat. Those are all places I can trust to put up a good server binary, and I expect the same for any other dedicated server provider -- which is where 99% of tournament play occurs.

Yes, in *theory* this could be done with modding the server binary now, but open-sourcing it would make it infinitely easier and infinitely increase the number of ways in which the server binary could be added (and increase the complexity of the evil things that can be done, instead of just nulling out parts of the binary or making simple changes)

It wouldn't actually increase the number of things you could do, but yes, it would make it easier. It's a question of tradeoffs, and in my opinion the benefit outweighs the possible downfalls.

[Michal Marcinkowski]

Here are my opinions, they are gradually changing so I update them:

zOMG HACKING EVERYWHERE

Quake 2 and Quake 3 are examples of multiplayer working with opensource. It is not easy but there are people that take care of the hacking aspect. Go play Q2 now and see how they do it. Last time I checked they had a tool which you had to run parallel to Q2 which checked for the binary version.

There will then be a billion slightly different Soldats, right??

I think at most 3 versions. That's how usually it happens with opensource. How many Mozilla projects can you name?

Won't this mean no registration, and therefore no money for MM?

This is an issue. The only solution I see is making a new license model where everyone using the code agrees to not change registration options and banners. The code would have to be left intact. At the same time I would agree to donate a percentage of the money for Soldat related things like website & lobby hosting.

[Veritas]

Do you have any plans for open-sourcing Soldat, or is it still just a "at some point in the future this may happen" sort of deal?

[Snow]

I was once opposed to open-sourcing Soldat, but at the time didn't understand much in the name of programming and networking. Now I'm for it, but because it is a complex project and there is a lot to keep in check and organized, my solution would be to:

1) Open it up only to about 10 to 20 trusted individuals first. People/programmers you know who only want to positively contribute to the game and could be trusted in keeping the source to themselves. The task would be to cover any loose ends, clean up what needs to be cleaned up and make sure everything is organized.

2)Then, gradually make it more open, until the project is fully open and there are enough who are working with the code that can protect it and keep measures in place to help reduce/eliminate hacking, just like with Q2, Q3.

3)Optional but very favorable - return the project to the state it was in version 1.2.1, however with all the bugfixes/improved code. Get rid of the new poly types... they can be part of 1 of the few Soldat alternative projects. Keep the exploding headshot though... I like that one.

[Illuminatus]

1) Open it up only to about 10 to 20 trusted individuals first.

He won't find that many. Neither 5.

2)Then, gradually make it more open, until the project is fully open and there are enough who are working with the code

The individuals from the first step are "enough". Imo it makes no sense to have too many developers for such a tiny game. It just becomes unorganized and messy.

3)return the project to the state it was in version 1.2.1, however with all the bugfixes/improved code.

You're funny. That's impossible.

at the time didn't understand much in the name of programming and networking.

Seems like you still don't. Face the truth.

[Veritas]

2)Then, gradually make it more open, until the project is fully open and there are enough who are working with the code

The individuals from the first step are "enough". Imo it makes no sense to have too many developers for such a tiny game. It just becomes unorganized and messy.

It becomes disorganized and messy if and only if the core team is disorganized and messy. Even smaller (and neither of us have any idea how big the codebase is) projects are scalable.

Seems like you still don't. Face the truth.

Interesting how you can be a judge of that with a short post on the internet! :I

[PQ]

2)Then, gradually make it more open, until the project is fully open and there are enough who are working with the code

The individuals from the first step are "enough". Imo it makes no sense to have too many developers for such a tiny game. It just becomes unorganized and messy.

It becomes disorganized and messy if and only if the core team is disorganized and messy. Even smaller (and neither of us have any idea how big the codebase is) projects are scalable.

If soldat becomes open source we might attract people who are not playing soldat at the moment. Open source seems to be quite hot at the moment. We as a soldat community don't have enough coding power to make a new/better soldat.
The whole idea of making it open source would be attracting a group of (semi-)professional coders to code in their spare time. (to fix some bugs and recheck the code)
I mean, ~99.95% of the soldat community is not able to help with coding soldat.

[SpiltCoffee]

1) Open it up only to about 10 to 20 trusted individuals first.

He won't find that many. Neither 5.

You won't know until you try. I can say for sure that at least one person would be interested... me!