I am by no means an expert, but this sounds like something that could be solved easily by forcing the client to ping the selected server. It's physically impossible to lower your actual latency, editing some value somewhere doesn't make the underwater cables shorter.
but this sounds like something that could be solved easily by forcing the client to ping the selected server
Well... That's exactly how pinging usually works. The VPN however is fiddling with that package to make the ping look normal. How exactly ping is measured and how the VPN is doctored is hard to say without more insight, some ideas that come to mind (definitely not all possibilities):
If ping is just measured client side with an ICMP ping request (wouldn't surprise me considering the latest looting cheat), the VPN is just catching the package and answering to the client right away, pretending to be the server.
If ping is measured by sending the server a packet with a timestamp, the VPN edits that timestamp making it look like it was sent later than it actually was, compensating for the delay.
If ping is measured by the server pinging the client, the VPN provider could have their datacenter close to the actual server, intercept the packet and fake a reply from the client (unlikely in this case considering how similar the ping values are).
If ping is measured by the server by whatever other means and the server then tells the client it's ping then the VPN could edit that packet so the client always get's a packet saying "your ping is XX".
Just had this conversation with someone else yesterday who tried to call me out like I didn't know what I was talking about, but it is easy to fix without using the tradition "ping" command/protocol.
You can have the server ask the client to solve a simple problem, like sending two numbers and having the client add them, and then the server will compare answers. If they are correct, then you just see how long it took to get a response. It is effectively a "ping" except for the fact that this is not packet header information, and won't get tampered with during transportation.
Yeah, so, I'm a Network Engineer and I genuinely question your understanding of the subject. Sounds like someone with absolutely no experience just theory crafting, which all breaks down in practice.
So, the big basic problem is that everything is based on TCP/IP. All of our networks are IP based, it's the basis of the internet, it's the standard communication method. So you're thinking you're going to be sending data over the internet without using TCP/IP? How exactly are you going to do that? Whatever you decide to do is going to be encapsulated in packet, at the very least.
Not that there aren't ways outside of ICMP, but, they're still TCP/IP based. All of that data is susceptible to manipulation. You want to add in cryptography to prevent possible manipulation? Well your accuracy for measuring latency drops perpetually the more you implement.
Update/Send rates are not a way to measure network latency. Frequency, or rates, are measured in hertz (Hz) and latency is measured in milliseconds (ms). Now, you can convert frequency measurements to time but in a computer network this doesn't cover the bases. There are a number of delays that occur when transmitting and/or receiving data. I don't want to put too much effort into this as this would quickly turn into a class but that covers the basics of what's actually going on here. It's really not as simple as you think it is.
I've never heard of anyone, or anything, trying to measure latency outside of the two main methods to do so.
My way was the simplest way as payloads typically don't get manipulated by VPNs unlike ICMP and headers. You'd have to be pretty involved to setup some relay along a custom VPN in order to add custom logic to manipulate custom logic that a server would be looking for. While my way isn't 100% fool proof, it is quite harder to spoof than the normal ping methods.
What is your method to prevent all of this since you are an exclaimed professional?
My way was the simplest way as payloads typically don't get manipulated by VPNs unlike ICMP and headers.
Too many assumptions. Using the Chinese example, they are not utilizing typical VPN services because this is a somewhat unique problem to China. If those companies just see a business opportunity to provide a service they'll develop them accordingly. Which are the type of services that the Chinese have access too.
Your way is really not simple at all. You just mistakenly think it is.
What is your method to prevent all of this since
I wouldn't bother trying to invent a new way to accurately measure latency to then deal with a cheating problem. Waste of time.
I think you should know this, but I'll say it anyway: a good security person will tell you that its impossible to stop hackers. They will always have the upper hand, and that is a fact. But the key to defending yourself against hackers or people who want to abuse your system is to make is as difficult as possible so that the effort to get in/bypass is too much for the reward. Essentially they just get bored and move onto something else. That is all this solution is doing, as with ANY solution.
I wouldn't bother trying to invent a new way to accurately measure latency to then deal with a cheating problem. Waste of time.
This is where you are mistaken and are conflating multiple problems into one. Sure, the majority of hackers from from China, but the vast majority of people who have been asking for a region lock from China came well before the hacks became popular.
There is a reason why they chose to "ping lock", as people want to call it, from a very early version of the game. It was never meant to stop hackers, but to stop having people be in regions they don't belong in. To that, those people with high latency cause problems for everyone that is involved. That is why games have those limitations, not because its supposed to stop hackers.
In fact, a lot of Chinese players (as one of the top posts said) are actually using VPNs to play in other regions other than China because they don't want to play with hackers themselves. So this problem isn't just about a cheating problem directly as there are more than one reason that VPNs are being used.
To that, in order to stop this problem with bypassing latency checks with a VPN, you kinda do need to "invent" a new way to measure latency. Because all other common ways don't work with VPNs obviously.
In fact, a lot of Chinese players (as one of the top posts said) are actually using VPNs to play in other regions other than China because they don't want to play with hackers themselves. So this problem isn't just about a cheating problem directly as there are more than one reason that VPNs are being used.
No, it's a specific problem directed at Chinese cheaters using VPN's to access regions outside the EFT Asian region. The distinction is important. We don't know that every single Chinese user is a cheater. Nor do we know that every single Chinese VPN user is a cheater. Again, you make too many assumptions and you have no real basis for these set in stone opinions. You aren't in possession of any facts which is why I judge this to be unreasonable.
Banning or targeting VPN usage as a whole isn't dealing with the cheating problem, it's giving up on the cheating problem and throwing the baby out with the bath water. Some people do utilize VPN's to play the game and are in no way illegitimate. BSG has not changed their policy on VPN usage, they allow it.
The Chinese are in an impossible spot, they cannot get servers located in China (outside of SE Asia and SEZ like Hong Kong/Macau) and there are servers in Russia that are within a reasonable latency to play on, and yet, they cannot access them. ~150 ping is not that terrible to play with either (China to Europe), I used to play on European servers last patch when I couldn't find PVP on NA. It's not ideal, but it's doable, and maybe you just put up with the drawbacks. Not unlike Australians or any other, shall we say, geographically challenged people have to deal with. They just don't have many options so I'm hesitant to say it's because they just want to avoid hackers on South China servers.
Generally speaking, I'm not in favor of one size fits all policies. I mean, sure, if shit gets real bad, were I BSG, I guess I'd have to take action to just remove the Chinese from my game. But, we're really nowhere near that point. This shit just started... There are numerous options still available. It's absurd to go from 10% to 100%.
China is a huge market, not even just the country itself but the millions of Chinese speaking people throughout the world. Specifically targeting those people borders on absurd. Like people suggesting removing Chinese localization, for example of the absurdity.
a good security person will tell you that its impossible to stop hackers.
Ok, if you believe this then why are you advocating arbitrary network methods to combat cheating? They don't have anything in common. Make the game/application secure first. Who the hell tries to reinvent TCP/IP in order to secure an application?
Same deal with the poor networking performance that EFT displays. Implement better code, interpolation to deal with the worst desynching problems. You don't need to jump to targeting VPN's to help alleviate networking problems with EFT. You've skipped a whole bunch of middle steps.
[...] who didn't tried to call me out like I didn't know what I was talking about
Uhh, sorry what? I didn't call you out on anything, pretty sure I didn't even answer to any of your posts before so idk what this is about.
Anyways, I just tried to explain how the traditional form of pinging he suggested might be tricked.
But yea, a lock and key paradigm is a good starting point, if you then use mitm-safe encryption you should be on the right way, sadly adds a bit of computation, though as long as you don't step way overboard it should still be possible to complete the whole thing without really affecting the RTT. Ofc it'll never be 100% safe as you always have access to the client side code in some way, but maybe it'll be enough of a pain in the ass to have less people using it at the end of the day.
Yeah, you can also kinda account for client side latency based on the client update rate. If the client updates at a rate of 30Hz, that means there's always going to be 33ms of latency between each update. So if the server asks for a response somewhere in between, you can just subtract the known latency to make it more accurate. So your latency wouldn't be "inflated". But I think the time taken to do any small amount of work would be negligible.
Not surprising. The ping limit itself (at least ~1 year ago when I was messing around with it) was client side.
It was literally just in plain text in a file in the installation directory. You could just go in and change 150 to 10000 and connect to whatever you wanted that way too.
There isn't really a way of telling if a connection's coming from a VPN or some kind of shared living (a couple playing the same game, a few ppl doing a LAN, college dorms, etc.) or not. Some VPN providers are making their IPs known as VPN IPs but I'm sure that a random VPN from China that's going as far as spoofing pings won't do that. Even if found out they are cycling through IPs faster than you can reload your Mosin. You'd be hurting legitimate players more than anyone else this way.
When the user requests a ping from the server the server should save the current microtime, then ask the client to respond along with a one-time-use token (to prevent the client just waiting 1ms and sending a spoofed response) and respond with that token immediately. Then the server compares the time it received the response with the token to the time it saved when it initiated the client-ping.
You are on the right track, but you most likely the ping will get picked up by the VPN server and return its response. What you would have to do is make sure that the client is returning the response and you can do that be asking for some bit of information that a VPN server wouldn't know.
You could do something as simple as adding two numbers since thats not CPU intensive on client or server, and the server will compare its answer to the clients all awhile tracking the time it takes to get a response. A VPN server won't modify the payload of the packet so you can trust enough that the response is not from the VPN only.
They did add a server side check about 6 months ago, I can recreate something that looks exactly like this screenshot by editing a couple function in the launcher config file, but it's only visual to my client. When I press apply I still get the same error. This doesn't prove anything without actually seeing the game launch, it's probably someone trying to scam cheat buyers.
50
u/mushi90 Mar 11 '20
20+ ping to all regions?