iw4x-client icon indicating copy to clipboard operation
iw4x-client copied to clipboard

[Feature Request] Implement HWID GUID + GUID

Open Ayymoss opened this issue 3 years ago • 7 comments

Please provide server admins with an HWID GUID that's based on hardware such as CPU/HDD Serial Numbers.

We're getting multiple repeat cheaters that have a dynamic IP address with MASSIVE IP pools.

Now, we could ban their entire subnets or ASNs but now we'd lose a bunch of people and/or have to whitelist a bunch of people... And nothing is stopping the repeat offender from posing as an innocent player trying to get whitelisted.

The server should receive their normal GUID so their stats remain and the HWID GUID for ban-binding.

We need something other than a random GUID.

Ayymoss avatar May 10 '22 21:05 Ayymoss

the problem with this is that it would be very easy for cheaters to just compile their own dll that sends random hwid data to the server (or for one person to write code for that and publish the dll on cheating sites).

Dss0 avatar May 10 '22 21:05 Dss0

Couldn't you use the new Master Server to authenticate/validate clients in such a way? (I'm not exactly sure, but now you have some centralisation surely there's a way?)

Also, I understand people could just rebuild the .dll, but it's an additional barrier. Most cheaters just want an easily accessible cheat with absolutely no understanding of how it works.

I get nothing can be perfect now that source, and even then, is released.

I'm really just requesting something new to make cheating a lot harder or require a lot more steps to do.

// Mini rant // We're battling a cheater right now who's got requesting a new IP from his ISP down to about 2 minutes. They're quick... :( Within 2 minutes he's back on with a new name, GUID and IP. The only way I'm finding them is by checking recently joined players by country lol... Which may introduce a level of an error on my behalf, ie I may ban an innocent.

Ayymoss avatar May 10 '22 22:05 Ayymoss

There would be no difference, people can still send their own hwid data to the master server and pretend to be a new player with ease. The only way of preventing this being bypassed within a day would be to ship a closed source anticheat module that is somehow verified by the dedicated server. Not an easy thing to do and to ultimately avoid this being bypassed as well it would probably have to be protected with something like themida (which costs money). We had some internal discussion about an anticheat module before but ultimately i don't see it happening any time soon or at all. XLabs is also not aiming to become closed source and centralized, that kind of goes against the entire philosophy of the project. This should still be playable in 20 years without a master server present. You said this cheater keeps evading their bans within minutes so someone this "dedicated" (not that i'm giving him any credit for this behaviour) would quickly find a way to bypass the new system as well (especially if it just involves checking a cheating forum because someone else already did this and released a dll). Just block the entire IP range.

Leaving this open for comments from devs.

Dss0 avatar May 11 '22 09:05 Dss0

Refactoring the auth component to behave like it does on s1x would be a good idea. In my opinion the current Auth module is extremely bloated.

diamante0018 avatar May 13 '22 14:05 diamante0018

The usefulness of this functionality is not limited to just preventing cheaters. Having a persistent identifier through game reinstall/corruptions, not being able to be shared etc... would be very useful for players and server administrators.

Additionally, there are ways to deter "spoofing" of this ID. e.g. Algorithmic generation that's validated by the server ("random" guids wouldn't be valid). Loading closed source component to generate a hardware based GUID at runtime. Verification of the game dll is also not a impossible solution.

The switch to a master server could really supports a more authoritative approach to mitigate the vast majority of petty cheaters. No one is asking for a 100% foolproof system. I think too much credit is given to the average cheater.

RaidMax avatar Jun 06 '22 18:06 RaidMax

the problem with this is that it would be very easy for cheaters to just compile their own dll that sends random hwid data to the server (or for one person to write code for that and publish the dll on cheating sites).

Just a thought, I feel you're giving cheaters way too much credit. Sure, it may seem arbitrary to you and some to download source and recompile it. But as I mentioned earlier, cheaters are cheaters. The vast majority of them have no idea what is going on other than "copy .dll into a directory and start game", that's it.

Also, if you are so concerned about people recompiling from the source, releasing an integrated aimbot was a terrible decision. You can make a very minor change in source and now you've got aimbot on mouse and keyboard without any controller requirement.

The release of an aimbot goes directly against what you said.

I know you like the decentralised nature but I'm sure a lot of people would be perfectly okay with a more authoritative implementation. If you want both, maybe allow servers to opt-in for the more centralised 'security', and if they do, people who aren't connected to the authoritative server aren't able to join these opted-in servers.

In the event the authoritative server goes down, both the servers and clients fall back to p2p and generated GUIDs (or some flag to indicate the client isn't auth'd).

I'm just trying to help, the state of the game's banning is absolutely pointless and completely arbitrary to circumvent. Why even ban people? Currently, there's no point.

Small note, these people who can restart their router and get a new IP are not the people who know how to recompile from source. :)

Ayymoss avatar Jun 06 '22 18:06 Ayymoss

Just a thought, I feel you're giving cheaters way too much credit. Sure, it may seem arbitrary to you and some to download source and recompile it. But as I mentioned earlier, cheaters are cheaters. The vast majority of them have no idea what is going on other than "copy .dll into a directory and start game", that's it.

And they don't need to, that's like saying there can't be many cheaters because barely anyone has the skills to write an aimbot. A single person has to compile a modified dll and release it on youtube/cheating sites/wherever else. Everyone else just has to download and replace a file.

Also, if you are so concerned about people recompiling from the source, releasing an integrated aimbot was a terrible decision. You can make a very minor change in source and now you've got aimbot on mouse and keyboard without any controller requirement.

The release of an aimbot goes directly against what you said.

I'm not really concerned about it, it's what's happening. So what i'm saying is it wouldn't be worth it putting 20 hours of work into code that will be bypassed and useless a week later. Community demanded controller support with aim assist so we implemented it (we weren't the first ones to do this, as you may know there was an unofficial fork of iw4x before that). hardly see anyone complaining either. Also a bit far fetched calling this an aimbot, you still have an advantage with kbm even with controller players using aim assist.

I know you like the decentralised nature but I'm sure a lot of people would be perfectly okay with a more authoritative implementation. If you want both, maybe allow servers to opt-in for the more centralised 'security', and if they do, people who aren't connected to the authoritative server aren't able to join these opted-in servers. In the event the authoritative server goes down, both the servers and clients fall back to p2p and generated GUIDs (or some flag to indicate the client isn't auth'd).

possible sure. i currently don't see the resources for that in our dev team tho.. this would require having a frontend to register, a database and way more advanced backend that connects the db to the game. not a task that can be completed in a couple days. this then also needs to be ported to the other games and the fallback p2p system would have to be rewritten. On top of that we'd prolly have to get a more powerful server to run the backend which results in higher costs. your idea of a hybrid system isn't bad but i just don't see it happening any time soon if at all.

I'm just trying to help, the state of the game's banning is absolutely pointless and completely arbitrary to circumvent. Why even ban people? Currently, there's no point.

sure it's easy to evade in most cases but still better than not having any ability to ban players at all.

Dss0 avatar Jun 17 '22 21:06 Dss0

Would it be possible to implement something like OAuth with Google or other account providers? For the player this should be optional, but servers could demand it. Then the client sends to the game server their auth data, which then gets verified by it. And to my understanding, the client would not be able to create fake keys as Google provides SDKs to verify those.

This would allow for persistent auth between game installs / machines and would make banning cheaters more efficient. Furthermore no central server from iw4x would be required for this, it could stay decentralised.

vdawg-git avatar Aug 23 '22 09:08 vdawg-git

Hello! I've been working on iw4x for a little bit and other open source projects/game clients before, so i'm just gonna add my two cents here about this whole issue.

Before working on iw4x I worked in another game client community for a completely different game, we had a huge smurfing problem / ban evasion problem because well, creating an account was free, although the system was quite centralized there was no way to make sure someone was a newcomer or someone previously banned.

The main two things we did to mitigate that were:

  • Generate obfuscated "hardware IDs" to compare them with existing HIDs of users to know if someone was a new user or not. This was extremely inefficient, because there's not a single thing in a computer that you can't spoof - would it be processor ID, motherboard vendor, you name it, nothing is reliable. So we had to collect lots and lots of stuff, but then it couldn't be open source otherwise evaders would know exactly what to spoof - so we had to close source it too. Not very elegant in an open source project. It was also extremely inefficient. Triggered false positives too, no matter how much information we collected. Looking back it might also have been a GDPR violation, before GDPR was a thing.
  • Require Steam account linking with our own accounts to prove you owned the game, which means basically, relying on an external centralized authority other than us. This was actually quite efficient (maybe cut down the amount of smurfing by 30%); but generated a bit of outrage. Lots of people pretendedly were "legit", but did not seem to own a copy on steam after all. It also hindered user acquisition. It was not a perfect solution either - each time the game went on sale, boom, we'd get a new wave of evaders. The cost of avoiding ban was no longer 0$, it was about 3 or 4 bucks - but some people were ready to pay that. So we added new conditions, like you must own the game and have X play hours on it on steam, or steam account must be older than a month, or whatever. All of that was inefficient, and also caught legitimate new users which was a hassle.

Now if we look at iw4x - we don't have an account system, because we're committed to a decentralized and open source system. Decentralized means no central authority meaning there is no way, no matter how hard you try to imagine it, to have a single effective way of banning cheaters durably. On a peer to peer system, moderation is handled per community and by reputation, and there is no good way of protecting against harmful users but crowd wisdom, which isn't terribly efficient when it comes to the use case you describe. Every "one fits all" solution either requires some closing of the source, intrusive data collection, or relinquishing control to a central authority (external or internal) - all of these are things we've purposefully avoided on this project, and will likely keep avoiding. Any of these solutions would likely only marginally help anyway, and like dss0 said we'd be short on hands to implement it.

...however you'd be in your absolute right to fork iw4x and modify it to work with centralized accounts requiring google oauth and whatnot, if you want. It won't be officially supported by iw4x, but open source project means you have the right & the power to do so. So feel free! You could even retain cross compatibility with iw4x, for instance ask players to type log in in the chat before spawning, and connect that with your own account system of your own website/clan (edit: i'm told this would be doable with iw4admin) Not very hard to do! But it might lower your player count... 😄

Rackover avatar Aug 23 '22 11:08 Rackover

You could do this via an IW4MAdmin plugin. Connect OAuth to IW4MAdmin and prevent the player from moving or doing damage when not logged in. Either way this isn't something we will implement.

Dss0 avatar Aug 23 '22 11:08 Dss0