Source port idea!

[Blzut3]

Indeed. While being completely closed source does give an advantage in making it more difficult to develop hacks (by allowing anti-cheat techniques such as delayed banning, etc), there is no solid way to prevent it. Odamex, and now ZDaemon, are less susceptible to cheating due to a smaller player base.

The Zandronum/Skulltag case really just shows that the only truly effective anti-cheat, given the resources of a few hobbyist programmers, is manual enforcement.

Lyfe said:

But, that doesn't mean you should be able to physically move at SR50 at all times.

Not to be that guy, but actually with a joystick you can move at SR50 speed all the time.

I still don't understand why you guys just don't accept unsupported third party utilities (I certainly never expected advertizement or endorsement from you. In fact if you answered all Doomseeker support requests with "please use ZLauncher or IDE" I would be just fine with that.), but there are plenty of good reasons to have an open protocol. Maybe someone wants to make a server monitor.

To use your Apple analogy, using the protocol is more like creating an App for an iOS device and not installing iOS on third party hardware. That would be more like Odamex acting as a ZDaemon client.

But whatever, your loss.

Ladna said:

Or are there other technical reasons you guys can't support Doomseeker?

Although I think this conversation may be over, I did want to point out that there is definitely no technical reason Doomseeker can't conform to ZDaemon's protocol. The 1.08 protocol (which can be seen in the ZDaemon plugin code) generates auth tokens as well.

[Ladna]

Lyfe said:

I do not think this word means what you think it means. If it does, you're just being a jerk.

No no no no, I was going for generous in forgiving an insult or injury; free from petty resentfulness or vindictiveness: to be magnanimous toward one's enemies. Not that I would consider you an enemy, nor do I feel insulted.

Lyfe said:

Strawman much? Obviously you missed the part about control. Apple likes to control its products. ZDaemon likes to control its resources. Any other implications you think I said are a product of your imagination.

Well you were using Apple as an example of the fruits of control, something like profit/community/brand protection and quality of experience. I was just pointing out that the difference in scale makes that comparison a serious stretch. For example, Apple is protecting billions in profits and millions of users. You guys are protecting zero profits and IDK, 80 users? I also pointed out that Doomseeker is a great experience, and I could get into the community/brand protection thing too, but to be honest I don't feel like it haha.

Lyfe said:

You're just going to have to live with the answer: "We don't want to."

I'm totally happy with that. It's way better than "it's Blzut3's fault".

Lyfe said:

Cheating stuff.

To get to your suggested solutions:
Aimbots: This strikes me as a completely client-side solution, which.. defeats the purpose in your open-source designs.
Wallhacks:
1- Difficult to implement. There are issues with prediction, edge cases, etc.
2- Because of the issues in (1), you still have to inform clients before they can see the other user, that the other user is approaching, which means your attempt to avoid transmitting needless data will not save someone who reacts quickly.
Speedhacks: Yes, we do some detection. However, SR50 is still a valid speed in the game. But, that doesn't mean you should be able to physically move at SR50 at all times. We found out that this was possible through a macro and removed the ability to do so.

Although I agree it's way easier to write cheats if the source code is open, I don't think it matters once a cheat is written, especially since it's hard to plug a hole to a cheat if it's closed source. Plus, you assume that you can plug the hole; some cheats just aren't exploits. Aimbots can't do anything that a human can't (by definition, they're using the same netcode the human is). You're talking about trying to figure out what an aimbot's behavior is versus a human's; the simplest example is "aimbot shoots 100%, human shoots 85%", but it's easy to either switch off an aimbot or program in some variance.

To more specifically address aimbots, I would definitely not implement a solution in the client. Client commands have angles, world indices and whether or not the client is shooting, during unlagged I can just look at P_LineAttack (or whatever, I'm too lazy to open up the source) and compare that to the positions of the other players. It's not like this would be CPU intensive at all, and keeping statistics like this is actually something players want (accuracy stats). Regarding the pixel stuff, I should have said "unit", that's probably what gave you the impression I would do a clientside thing.

Wallhack stuff yeah, the classic problem when withholding opponent positions is clientside prediction, or like you alluded to, packet loss (opponents just suddenly appear, BOO!, haha). I've generally been comfortable in competitive play mandating a certain level of connection quality; if your ping exceeds 200ms, you're gonna have a bad time, sorry. If your packet loss is so bad that you can predict your own movement all across the outside yard of D5M1, you might see your opponent frozen just inside the cave. Too bad. If you're hosting a friendly match, or you just aren't that serious about wallhacks, feel free to turn the feature off.

But you always know how fast a player could move at any given time. Just figure that out (radius), move them around the circle in however many degrees you want (resolution is up to you, 45 degrees, ANG_1, whatever), and if the player could ever see any opponent, send the message. I realize that effectively means you can write a wallhack that sees around corners, but I think that's an inherent limitation of the technique.

Lyfe said:

So, since we know it's a difficult thing (which it appears only ZDaemon has so far tackled), I can only look forward to seeing how you approach the issue of cheating in your open-source doom ports.

Cheating/netcode discussions are fun, I really enjoy them. Closed source clients have their advantages, they can include checks for running under a debugger, or detecting CreateRemoteThread, or require a CPU that supports DEP, but that stuff is sort of elementary.

You can also leverage a closed source launcher. It's not a perfect solution, and it doesn't address every attack vector, but a competitive event like IDL could probably issue a new launcher for every season that hashed & launched the Odamex client--this would essentially be the same system ZDaemon uses for anti-name-faking. Again it would only be a matter of time before the launcher got cracked, but it would probably take longer than an IDL season, and then it would be useless.

I don't know if ZDaemon does something like this. I traced IDE's system calls to try and figure out what kind of hashing it was using, and I saw that it was reading the whole EXE I had configured as the ZDaemon client (zddemotool.exe). I don't know if that's a normal part of CreateProcess or what. If it's part of anti-cheat, in that thread we agreed that a problem with that system was that the binary could be switched out between verification and execution. You have to set a breakpoint in the launcher (and it looks like IDE crashes under a debugger, hehe), but it's still very doable. It does require dedication and expertise though, so it's unlikely. Just something to consider, unless I'm mistaken outright.

Blzut3 said:

Although I think this conversation may be over, I did want to point out that there is definitely no technical reason Doomseeker can't conform to ZDaemon's protocol. The 1.08 protocol (which can be seen in the ZDaemon plugin code) generates auth tokens as well.

My guess is that they have the ZDaemon Launcher and IDE do a lot more stuff (like cheat detection). Add that to the new anti-name-fake required verification, and you're requiring users to run anti-cheat through the launcher. This stuff wouldn't really work in Doomseeker because it's open source. Like you said though, their loss :) .

[Quasar]

Ladna said:

Cheating/netcode discussions are fun, I really enjoy them. Closed source clients have their advantages, they can include checks for running under a debugger, or detecting CreateRemoteThread, or require a CPU that supports DEP, but that stuff is sort of elementary.

With enough work one can include such things just as easily in open source code. Integrated tightly enough, it becomes a non-trivial task to remove all of it, which is raising the bar of entry for hackers. Considering you can hack binaries to skip around or dummy out calls anyway, if you have enough dedication.

There is no magic silver bullet. As long as your code is running on the user's machine, there's some way they could find to fuck with it. Closed source code is just additional obscurity, and very little, at that. IDA Pro will cancel that advantage rapidly in the presence of a known open source base.

[Lyfe]

@The last few posters:
Thanks for the discussion. I still look forward to seeing how you go about implementing anti-cheat solutions.

[Csonicgo]

Lyfe said:

@The last few posters:
Thanks for the discussion. I still look forward to seeing how you go about implementing anti-cheat solutions.

Manual enforcement and a sane self-policing system would help a lot. Isn't that what Zandronum does now?

My question is, why wasn't this openly discussed from the start?

[Quasar]

EDIT: Never mind. Perpetuating it won't do any good.