ways to stop cheaters.

[Tropican8]

Are you trying to say that threads are completely useless unless you have a multiprocessor system? Give me a break.

Umm, yeah that's what we are saying pretty much. If you disagree, please prove it rather than flaming that we are wrong.

You guys have failed to bring up any good reason for not implementing trusted clients in BZFlag. Your arguments basically boil down to:

Oooo, a long one. I'm game.

1. What's that? Closed source? NO! This is an OPEN SOURCE game. I don't care if it's just linking with a 3-kilobyte binary-only .dll. Closed source is associated with proprietary software and monopolistic corporations. Down with closed source and anything associated with it.

Dude read the LGPL. By law you can't link anything closed source to something under the GPL in the way you suggest. And no you can't switch licences either. (You can add though as long as they don't contradict to my understanding).

2. Server admins are like police officers. Getting rid of all the world's criminals is a bad idea because then police officers would have nothing to do.

If you think your little plan will get rid of all cheaters forget about it. There is always someone smarter than you (which in this case includes everyone on the message board and my friend's pet hamster)

3. Adding a closed-source module to the game basically makes the whole game closed-source because it becomes impossible to freely and easily modify without breaking online functionality.

Yeah it does. Again actually read the thing called License.txt that comes with BZFlag.

My responses:

Another long one. You need to shorten your posts man.

1. This is no less than FOSS zealotry. You're against writing a closed-source authentication module because you associate closed-source with proprietary software and monopolistic corporations. This is bad thinking. Closed source has fair uses, too. In this case, we'd be using it to conceal a small part of the game from the public eye for the sake of fairness in online matches. We're not doing it to greedily conceal source code as a trade secret to crush industrial competition. An analogy: imagine arguing against giving police officers guns because many bad people use guns to murder innocent children.

Yeah great. Too bad we can't do it by law. Write your own game. Or think harder and make something that is impossible to crack yet is open source. Those encryption methods I posted are good examples. They all have open-source implementations yet are impossible to crack. Find a way to make one that does what you want it to do faster. This is open source. You can do anything really. Just get really good at coding and share your magic.

2. Server admins are not like police officers. There's more to running a server than banning players for cheating. The banning part of a server admin's job is largely a side-effect of BZFlag's crummy client-server architecture.

Umm I ban for other reasons too. Like really offensive players, people discussing highly illegal activity on a server, tkers, admin-askers, I'm sure there's more but those are the main problems. Speaking of how would your great new closed source .dll prevent all those things? In your example of not doing this because it would eliminate those cop jobs, it really doesn't. Most adminwork is not about cheating.

3. This simply isn't true. The spirit of open-source is still there. People still have the freedom to get the code, modify it, and contribute to the community. In fact, the only thing my "trusted client" model disallows is the modifying of a game client for malicious, cheat-related purposes.

Again, too bad you can't really do that because of that nasty GPL. Hey I bet you work for Microsoft, can you get me a job?

I don't understand why you guys have such a strong aversion to my ideas. It's just a tiny closed-source .dll, guys! Your rights are not being violated. The spirit of open-source is still there. The spirit of taking advantage of open-source for malicious reasons is not.

Umm the developers' rights are being violated. There's more than spirit there too. There's actually legal issues.

By the way Open Source does allow one thing. You can make another Open Source addin that prevents cheating. You got the code. If you don't you can easily. We'll show you how. All we are saying is that with our understanding of what is possible based on what we know about computers, we can't do it. It sounds like you don't believe us though that we can't make what you are suggesting. You might know more than us, feel free to start something to rid BZFlag of cheating. I don't know how good of a coder you are. There are things in code that people have said couldn't be done, and some talented person comes along and does it. Go ahead. Prove us wrong. That seems to be your goal anyway. I'm sure the devs won't mind more help. By the way remember none of the devs do this for a living and it is not their obligation to serve you. They do this for fun and for the good of their fans.

I'd like to close by saying you have been pwned, deal with it, and JeffM please lock this thread even if its the last thing you do.

[Teppic]

1. An executable file (the game client binary) has a header section that details which dynamic libraries have to be loaded. This will differ from client to client, true. So don't include it in the MD5 checksum.

2. Computing a new checksum for every new client release sounds like a hassle, but it can be automated. You're purposely not being creative here.

3. They could just "hack out" the MD5 response? Okay, you're purposely not being creative (again). Have you heard of a technique called encryption? One end turns the data into code and the other end turns it back (both ends agree on an encryption algorithm). It's really extremely common. Just make a closed-source server authentication module, a closed-source client authentication module, and you're set to go. No packet-sniffing hacker can "send the server the MD5 it wants to hear" because the agreed-on encryption algorithm will be different every time.

1) So what is going to be included if not the client binary? Correct me if I am wrong, but isn't that where the 'cheating' takes place?

2) Do you actually appreciate the number of links to variations of library versions and types that could go into making the client binary (we will ignore that you have previously stated this should not be included in the MD5 checksum). For example, I have, for at least four of the required libraries, more than 5 available versions to choose from, from the current package tree, meaning 1024 possible MD5's before taking into account the 6 compiler versions I might use, bringing the total up to 6144 MD5's, coupled with say 4 optimising flags of two options each, making the total number of possible MD5's FOR ONE OF MY SYSTEMS ALONE just under 100 thousand variations, hmm.....

3) Yeah, because reading the response before encrytption from system memory on your own system is sooo hard to do.

[Hannibal]

what happened to the button to delete a post?

[Dylan Sunderberg]

As was mentioned previously, any licensing problems will likely turn out to be non-issues. Perhaps the terms of the game's license can be changed, for instance.

[Workaphobia]

What if I want to modify my client (like I do) and don't want it to be in BZFlag?

Actually, you can still modify your client without it being in BZFlag. It just means you won't be able to take your modified client online, because quite frankly, the only real reason you would do that is to cheat.

What?! So utilizing the rights protected by the GPL makes a person a cheater? I refer you to my input mod. Are you saying that under your system I should have to get my changes explicitly blessed by a developer and/or each individual server administrator in order to use them online?


How about instead of focusing on measures that would make it difficult to play with unauthorized clients, we look more towards the future of server-side game control, which will eliminate all blatant cheats.

Are you trying to say that threads are completely useless unless you have a multiprocessor system? Give me a break.

Umm, yeah that's what we are saying pretty much. If you disagree, please prove it rather than flaming that we are wrong.

O_o?!! I can only assume that you meant, "For this particular situation." I'll let a more experienced programmer than me explain how threads work.


I'm not going to delve into CuddlyFuzz's three points and the response because there seems to be a bit of misunderstanding about who was implying what, and now you guys are just arguing semantics and taking it personally. But at least I've gotten my thoughts in before this thread is locked.

[JeffM]

CuddlyFuzz
the encryption will eventualy be broken. I've seen it done. It's not that hard for somone who knows what they are doing. And it is often seen as a "challenge" so they often work harder at breaking it.

There is much reasearch on this, and I do know what I'm talking about, I've had to do it for closed source comercial games. Obfuscation is not security, it just delays the inevatable. I'm not being uncreative, it's just all of us developers have looked down this road MANY MANY times, and discussed it at length.

People build from source all the time, your checksums have to be precomputed, we'd have to compute a checksum for each code commit since that changes the binary. And anyone could get anon CVS at any time and build. yes it could be automated, but it's a huge database of info, specialy when you consider that the various levels of optimisation and difrent compilers also change the final binary. Some systems link libs static, some link them dynamic, that changes things too. I'm not saying it's imposible, just unfeasable for our development style and resources. At the least developers would have to use special servers and system that would allow "dirty" clients, to do testing. Right now we make use of public test servers and players. This is a big change that limits us more then we are now.

on your open source thing, yes I understand you saing they main code is still open source, but if we include even a small cosed source part that is required to run, debian, and other major distros will take us out of there default package repositorys and move us into there "tainted" or "non free" package repositorys. Just like the nvida drivers ( they contain an open source part, and a closed source part). This lessens the exposure of the game and takes us out of the default package sets. Tim will never go for this. Linux clients still account for over 30% of the users, and many of them are built from source or source packages. Others find the game when it's preinstalled. Linux users/distro managers do not like closed source at all. The only reason they put up with people like nvidia and ATI is because they have no real choice( they make the hardware). And even then, they are trying to make there own open souce solutions for them(DRI). The linux world is very difrent from the windows world, trust me on this at least.

I'm not saying that a very cleverly designed client verification system will not lessen cheating, it can. I am just saying I do not feel it is worth the time, effort, and trouble it will cause. The system would have to be rather complex, very invasive into the entire build/distrobution system, and it would change how we are viewed by the open source comunity. I personaly feel that we can make the server verify all input with much less effort and change, while still maintaining 100% open souce, and allowing people to build there own code. Puting the onus on the server allows for clients to change and grow and still maintain a reasonable level of input verification/cheat protection.

I personaly have seen 2 games use ether a closed binary, or a closed auth module for security. They both got hacked right quick. A simple system level debuger shows the encryption code ( you just walk thru it at an asembly level ), and then they just build there own libs. A DLL type inteface makes it even easyer to repalce, you just add a new DLL with the same interface, and bam, it sends out known good encrypted checksums.

The ONLY place I've seen it work is systems that use a live updater and verify all files every time it's run. These are usualy the MMORPG games like everquest. They have the advantage of being able to update the game each time it's run and swaping out encription regularly. This makes your cheaters have to redo there work often. These are allmost allways binary only distrobuations for a single platform. For us we'd have to be building on every possible system and changing things a lot. It would be a lot of work to maintain.

In the end anything that happens will be up to who ever choses to implement it and if they can convince the rest of the developers to go along with it. But honestly I don't see Tim going for a closed source solution, even in only a small part.

Hannibal
if you can't say anything contstructive then just don't post. We've had this discussion before. He's allowed to state is reasons and ideas, just like any of us are. It's called a "discussion", it's something matture people do, get used to it. You arn't doing a good job of getting yourself off watch.

[Tropican8]

Are you trying to say that threads are completely useless unless you have a multiprocessor system? Give me a break.

Umm, yeah that's what we are saying pretty much. If you disagree, please prove it rather than flaming that we are wrong.

O_o?!! I can only assume that you meant, "For this particular situation." I'll let a more experienced programmer than me explain how threads work.

Yeah thanks, I just got a little upset at the "they do too help/they do not!" argument that was going back and forth.

[DTRemenak]

To clarify a couple things:

These are listed in order from general to specific.

1. A number of the developers value Free software VERY highly. We would instantly lose at least two, probably more active developers if BZFlag incorporated even one line of non-Free code. Considering that there are only about a half-dozen active devs, that's a huge chunk of labor to lose.

2. Copyright to BZFlag is carried by Tim Riker. It's relatively easy to relicense, since we wouldn't need to contact every single contributor. But, Tim will not approve ANYTHING that would get BZFlag knocked out of Debian Free, OR anything that would violate the spirit in which past contributors have made their contributions (and there are developers who feel very strongly about this, so he would almost certainly not change the license to accomodate a non-free component even if he personally was convinced it was the right direction to go).

3. Platform independence is one of BZFlag's greatest strengths. Who are you to say that the fellow running IRIX on his Indigo can't play bzflag online, just because we haven't built it for a MIPS32+IRIX platform? Check the SF binary downloads. Windows and Mac are up to date. That's IT. None of the linux binaries are up to date. Solaris is not up to date. IRIX is not up to date. We don't even distribute ANY binaries whatsoever for BSD, BeOS, or any of a half-dozen other potential platforms. We actively support five compiler families (comprising hundreds of compilers, since we support about ten years worth of versions of each of them), ten operating systems (comprising thousands of distributions), and eight cpu architectures. We support conditional compilation for four optional libraries. There are literally millions of possible configurations. Including a binary component and checksum of each compilation is foolhardy.

4. Look carefully at your "foolproof" authentication scheme. Now substitute a new #3: Compute the checksome of THE REAL CLIENT while running A MODDED CLIENT. You're sending the server what it wants to know, because you're checking against the real thing. Even if that part of the code is closed source too (getting bigger here), on Real Operating Systems, you can move executables while they're in use. It'd be trivial to write a hack that started the client thread, suspended when it requested to open the client binary, moved away the hacked binary, copied in the real one, resumed the thread, let it calculate, and moved the binaries back. There's a reason that commercial cheat checkers always scan for debuggers and system hooks running in the background. Now look at the complexity that your verification system is developing. Who's gonna write it and maintain it, since it's gonna be closed source? Who's gonna sit there and try to keep up with all the latest hacks?

Face the music. You CANNOT EVER trust ANYTHING the client says. EVER. The solution is to move more of the game server-side, and that's exactly what we're working on (slowly). The developers have been looking at this problem for a LONG time (think years), and many of our team are very smart, very experienced, or both. That's not to say your help and comments aren't welcomed, but do try to think about what you're suggesting for a little while.

Look at the balance here for the closed-source argument:
Pros:
Less cheaters (a really good system will get rid of 90% to be generous)

Cons:
Lose developer support (probably more than 50% by man-hours)
Lose placement in Debian for certain, others probably (loss of exposure, players, and goodwill)
Huge effort & cost to build binary components and checksums for many possible configurations every release (would need either a major cross-compiling setup, or many very trusted and capable volunteers)
Resources diverted from bugfixing and feature development to maintaining closed-source portion
Resources diverted from bugfixing and feature development to counter-hack development

Basically you'd be reducing BZFlag to rubble...seriously. It would be suicidal for the project. You're probably right that most players (windows + mac = ~70% playerbase, and some linux players would stick around) wouldn't care, at least at first. But developers would, and a stagnant game is a dead game; players trickle away.