39 replies to this topic

[Volthorne]

Platinum Booger, on 04 December 2012 - 01:33 PM, said:

Your argument is based on one time event hacks and is not relevant here.

This is what ****** me off.

It is not simply a case of "one-time vs. recurring". Each shot, regardless of how many times you shoot per match is verified. Under your system, each shot would have a chance to be verified and that chance is non-accumulative. If there's a 1% for a packet to be hacked and verified, then it's a 1% recurring chance across the whole match, not accumulative per shot as you seem to think it would be.

Platinum Booger, on 04 December 2012 - 01:21 PM, said:

Let me give you an analogy in return: One is put in a room and the door is opened 1% of the time. Without fail, another would find the poop on the floor.

Nice general assumption, leaving out all the important details. Is the 1% broken down into shorter periods or one longer one? What's the time frame? Can the person leave the room when the door is opened? Etc.

Maybe you should actually know what you're talking about before you start talking about it.

Edited by Volthorne, 04 December 2012 - 04:16 PM.

[IamSeanConnery]

I didn't appreciate your tone from the start. I will not participate in a flame war. Support your opinion. It's easier to respect it that way.

Yes. Let's say 1% verified. Please explain to me how one could cheat 99% and not get caught on this random 1%. I'm all ears.

[Brandeis]

I think that this method would be too easily exploited. If, as you say, the constant validation does impact the server response time, then suddenly increasing one player to 100% validation would produce a drop in the server's performance, one that may be spotted by a sniffer checking ping times.

I could conceivably see a system wherein I have a script sending out altered damage packets, either on every shot, or maybe randomly to avoid the detection, and when a change in ping is noticed, such as would potentially happen when I'm flagged for 100% validation, the script automatically stops sending the bad packets.

[IamSeanConnery]

Brandeis, on 04 December 2012 - 08:33 PM, said:

I think that this method would be too easily exploited. If, as you say, the constant validation does impact the server response time, then suddenly increasing one player to 100% validation would produce a drop in the server's performance, one that may be spotted by a sniffer checking ping times.

I could conceivably see a system wherein I have a script sending out altered damage packets, either on every shot, or maybe randomly to avoid the detection, and when a change in ping is noticed, such as would potentially happen when I'm flagged for 100% validation, the script automatically stops sending the bad packets.

Good idea. But when data is sent you shouldn't know it will be validated or not. So a cheater will certainly encounter a failure detection in time. He might know after if he was validated but it's too late(due to ping or other sniffing). He's already been detected. And random cheating cannot avoid random checks...random 1% cheating is still 1% cheating.
Once the changed data is seen the account is flagged, might as well leave it at 100%. And as you say, the script would be turned off. Works out doesn't it? Plus that player has to deal with 100% validation now. Whoops. Even if you left the validation at 1% the cheat would be detected yet again, adding more failures to flag the account.

edit1:added ping

Edited by Platinum Booger, 04 December 2012 - 08:57 PM.

[IamSeanConnery]

Firstly, this suggestion is about making the system more efficient without losing it's inherent cheat detection properties within. I just think the current system is wasteful and causing latency that is contributing to the "netcode" issues complained about.

Let me reiterate my original assumptions which are pivotal for this to actually work:
1) The verification/no verification must be indetectable from the point of the client initially sending data. Once the data is sent, only then it's ok for the client to know whether it was verified or not. (This is not difficult since the verification can be done once the data is sent). The logic here is that if the client doesn't know if it will be verified, it could be verified at any time and has no defense to stop from being detected.
An example is a traffic officer hiding behind an overpass for a speeder. The speeder doesn't know which overpass the officer is hiding behind, so they always have the ability to be caught speeding at any time.

2) The "hacker/cheater", to be effective, must cheat over and over again to gain his or her desired results. Ex: Alter packets on a periodic basis. This is pretty much a gimmie when talking about altering data on shots and things like that. Again, I will use the officer and speeder example- The speeder WILL speed under more than one overpass. (Also, to cover myself on this example to one who might say they don't get caught speeding enough- that is because there are extremely few times they are "sampled" by an officer. And an officer generally doesnt case if you're going 7mph over and can only pull over 1 at a time, and isn't hiding always). Even a 1% verification would be over 10000 times fold increase on the current police force;P)

3) Decrease in verification results in lower latency and server loads. (Obviously, if this is not true then I concede!)

If any of these points are not met, then I agree this solution would never work and I would not want it implemented.

[Volthorne]

Platinum Booger, on 04 December 2012 - 07:48 PM, said:

Yes. Let's say 1% verified. Please explain to me how one could cheat 99% and not get caught on this random 1%. I'm all ears.

Oh, he's going to get caught eventually. Just not nearly as frequently as you think. Let me rephrase what you want into a simpler explanation:

Roll 1d100 (yes, they exist). On an 11-20, a damage packet gets hacked. On an 81-90, a packet gets verified. On 100, both happen (busted!). Reroll for each shot you make in a game.

Platinum Booger, on 05 December 2012 - 06:40 AM, said:

3) Decrease in verification results in lower latency and server loads. (Obviously, if this is not true then I concede!)

If anything it would INCREASE server loads, because you're now also asking the server to roll randomly for packet verification each time the client sends a packet, hacked or not, instead of verifying everything as it goes through.

Edited by Volthorne, 05 December 2012 - 07:39 AM.

[IamSeanConnery]

Volthorne, on 05 December 2012 - 07:39 AM, said:

Oh, he's going to get caught eventually. Just not nearly as frequently as you think. Let me rephrase what you want into a simpler explanation:

Roll 1d100 (yes, they exist). On an 11-20, a damage packet gets hacked. On an 81-90, a packet gets verified. On 100, both happen (busted!). Reroll for each shot you make in a game.


If anything it would INCREASE server loads, because you're now also asking the server to roll randomly for packet verification each time the client sends a packet, hacked or not, instead of verifying everything as it goes through.

Yes, your 1d100 example is accurrate. But keep in mind we are rolling the die over and over and over and over again during the game, and it is unavoidable 100 will come up. More than once. This is all that is necessary to detect because the cheater needs to keep cheating. If he just changes one packet and calls it a day and enver does it again then I'm wrong. But what are the odds of a cheater only cheating on 1 shot and that's it? Pretty much zero there. He will roll the 100 and be caught. From there we could look at him all the time then if we wanted to.

The act of measuring and calculating every time is more impactful to a server than a random algorithm to do it part of the time. Calculation and measuring with the client will take time for the signal to go both ways, along with the verification algorithm to compare data and ensure it is correct. If we do this a fraction of the time, and instead set an overlaying, simpler algorithm, we reduce workload.
Example: If you cook at home, you go to the grocery store to get food maybe once a week or so and not for every meal. The time saved driving, going through checkout, and the store for every meal would be more effort than to go once. And you still get all the food you need. The algorithm to plan out your list is vastly less work than doing it the other way.

[Wooden Booger]

Yawn.... Stop talking in metaphors all of you and lets PLAY!!

[Volthorne]

Platinum Booger, on 05 December 2012 - 08:07 AM, said:

Yes, your 1d100 example is accurrate. But keep in mind we are rolling the die over and over and over and over again during the game, and it is unavoidable 100 will come up. More than once. This is all that is necessary to detect because the cheater needs to keep cheating. If he just changes one packet and calls it a day and enver does it again then I'm wrong. But what are the odds of a cheater only cheating on 1 shot and that's it? Pretty much zero there. He will roll the 100 and be caught. From there we could look at him all the time then if we wanted to.

Except not. The way you're trying to argue your case is if the previous number that was rolled suddenly vanished and the d100 became a d99 for the second roll and a d98 for the third. Have you ever rolled 100d100? Theoretically the chance for rolling each number is 1/100, but in practice, you're going to roll lots of doubles and triples rather than one of each. This is exactly what would happen with %chance validation and hacks.

Or, for a more realistic (rather than simplistic) approach, get 2d100, and whenever they match up the hacker gets caught. Start rolling.

Quote

Example: If you cook at home, you go to the grocery store to get food maybe once a week or so and not for every meal. The time saved driving, going through checkout, and the store for every meal would be more effort than to go once. And you still get all the food you need. The algorithm to plan out your list is vastly less work than doing it the other way.

That's not even a relevant example...

Edited by Volthorne, 05 December 2012 - 11:07 AM.

[IamSeanConnery]

Volthorne, on 05 December 2012 - 11:06 AM, said:

Except not. The way you're trying to argue your case is if the previous number that was rolled suddenly vanished and the d100 became a d99 for the second roll and a d98 for the third. Have you ever rolled 100d100? Theoretically the chance for rolling each number is 1/100, but in practice, you're going to roll lots of doubles and triples rather than one of each. This is exactly what would happen with %chance validation and hacks.

Or, for a more realistic (rather than simplistic) approach, get 2d100, and whenever they match up the hacker gets caught. Start rolling.


That's not even a relevant example...

Firstly, your d100 d100 example is not accurate for cheating or hacking. Assuming the validation is a d100, cheating 1% of the time is much too low and not very useful for the case of changing data packets for shots. For example, if lets say damage was changed on 1% of the packets to be double or hit or whatever. That would only affect the overall damage output by 2%.
However, let's keep with that example since it is technically POSSIBLE however INPROBABLE. You case is technically correct, but the effect makes a very poor cheater who doesn't get much benefit.
Also, a validation of 1% is low as well. 10% may be better. Either may my solution can accomodate over 1% validation which you have not addressed;)

For the sake of your corner case example lets go with your d100d100 anyhow. Each game this cheater will shooting hundreds of shots and transferring hundreds and hundreds of packets per game. Lets say for this example 200 shots. Out of those 200 shots, he has randomly cheated around 2 times statisically, marginally increasing his overall damage. He was not caught this game. However, over the course of games he would certainly be flagged. And what cheater only cheats one game and leaves it at that? You give a very poor case for me to concider here.

It's important to think of the practicality of which one speaks and it's relation to the overall system. Your refutation does not describe the system in which we play. (Or at least much more roughly than mine, since everything is technically relative here).

You continue to assume cheaters rarely cheat and one must catch them every time to be effective. That is not the case. the important part is they are caught in a reasonable amount of time and dealt with appropriately. I concede to you they will not be caught on every single point of cheating. But that does not matter. It is the end result that matters.
Example: Why not hire 100x the amount of police to keep everyone obeying the law? you may catch more people in the act of breaking the law, but it does not serve the purpose of keeping order much more than having a reduced force that people are aware of and fear. Have 100x the police would a waste of resources. ( Plus really creepy to boot!)

edit1:typo

Edited by Platinum Booger, 05 December 2012 - 11:45 AM.

[Brandeis]

I still think that the system would be more vulnerable. If the act of verifying a shot informs the client after the fact that the shot has been verified, then there is quite a lot of potential for the system to be figured out. Likewise, if the act of verifying a shot slows the response more than the norm, then you can tell if you have been checked or not, and you can still get the data needed to beat the system.

[Ryvucz]

I see a lot of "if the server".

I have to say, out of all the games I have played in beta, and launch. These guys have the most solid servers I have ever seen.

Algorithmic values can be traced client side by those types of people that just enjoy breaking things.

[IamSeanConnery]

Brandeis, on 05 December 2012 - 11:52 AM, said:

I still think that the system would be more vulnerable. If the act of verifying a shot informs the client after the fact that the shot has been verified, then there is quite a lot of potential for the system to be figured out. Likewise, if the act of verifying a shot slows the response more than the norm, then you can tell if you have been checked or not, and you can still get the data needed to beat the system.

I agree it could be figured out when it was verifying, but not until after the data to verify had been delivered- Meaning that the cheat would be inable to know when the data it sent would be validated. Only know that it had been validated afterwards. If even possible for that.based on response times alone.

If there is some way for it to figure it out before it was verified then this suggestion should never be implemented.

As for figuring out things besides that, there is not a lot left able to be figured out. I think the only important part is using an optimal random source that is not predicable. This is possible currently.

Overall, the devs would have to do it right. Random source, optimal verification % chosen. Treat to be verified/ not be verified packets the same as they arrive to the server. It's quite possible the devs might be be able to do this. Or have not built the shot system to be compatible with these kind of things in mind. If so, again this is just a suggestion, if applicable.

[IamSeanConnery]

Ryvucz, on 05 December 2012 - 12:00 PM, said:

I see a lot of "if the server".

I have to say, out of all the games I have played in beta, and launch. These guys have the most solid servers I have ever seen.

Algorithmic values can be traced client side by those types of people that just enjoy breaking things.

The devil is always in the details. Poor coding can always throw things out the window.
That being said, algorithmic items stated prior are done server side. Hence the "if the server". That's a good thing. the idea is to push the gruntwork to the client and keep the smarts at the server.

[IamSeanConnery]

Anyways, I've said my peace. I'm checking out of this thread because I think it's run it's course from my perspective. Poke holes in it as much as possible(always a good exercise) but I won't be refuting any other points. If the devs have read anything they know whether it's viable or not. I apprecate the points that we're brought up and I respect the view of "don't fix what isn't broken" and contributors worry about not detecting cheaters. I share the same base values.

[TheRealPope478]

Reading these posts is kind of funny. I'm not trying to get involved, but the dude that originaly posted is actually right. 100% validation is going to slow down game play on an already slow game in order to catch cheaters who will just find a way around it anyways. Thats the problem with "gun control" theorys. Criminals don't care about your laws and delight in breaking them.

As far a 1% chance of the system seeing a cheater cheat being not a big chance I would totally disagree. You fire 10 shots in 10 games and statsicaly you are 100% going to get caught. Computers are made to find 1% chances. They don't get bored or distracted cause all they do is crunch numbers. Also letting the cheaters get alittle invested in there account before banning them will make them more likely to give up in the long run anyways. Because seriously even banning them won't stop them, they will just make new accounts and cheat again. It's a more serious blow to lose elite status then to just keep throwing away basic ravens you plan on losing anyways.

But honestly I really don't want to get involved in any debates. Everyone is entitled to there opinion on this. I'm just blown away that cheating is such an issue anyways. What are you bragging about from winning like that? That you have less of a life than me? Congratulations you are the biggest deuche in the universe.

[Durant Carlyle]

You're talking as if hit verification isn't already in the game, Pope. It IS in the game right now. Each and every shot you fire is verified by the server. So it won't "slow down game play" any more than it already has.

And what's with the "on an already slow game" bit? You and I must be playing two totally different games, because there's nothing slow about the MW:O I play.

Also remember, folks ... we will be getting regional server farms. Any load issues they may have right now (which I don't think is any kind of problem whatsoever), will be greatly lessened or eliminated entirely once even one other region is activated.

[Deathlike]

Here's a novel thought: If things aren't actually checked on the server side @ 100%, why even bother having any sort of state rewind or networking improvements? You're only going to "rewind" us back into the days where you HAD to lead your targets with lasers and other weapons. It only gets worse. Randomly checking is only good for increased whining about hit detection.

It does not solve server load (it's not even an issue in general), it only exacerbates existing problems.

Edited by Deathlike, 19 March 2013 - 06:54 AM.

[CallMeGunny]

When it comes to computing, there is no such thing as "random". Period.

There is always a script, which while it may appear random to us, is doing a specific job: Said script can be decompiled and understood to the point that it too, can be cheated.. Resulting in a lot of work, and no change in outcome.

I haven't seen any hackers. And it's far too early to be crying wolf, game hasn't even left beta yet. Short of PS2, haven't played a game yet with hacks before full release.

--Oh, and the game isn't slow. Me and my AC/20 have no problem greeting light windshields (except when thermal's on, but that's another subject entirely.)

Edited by CallMeGunny, 19 March 2013 - 07:22 AM.

[focuspark]

Platinum Booger, on 03 December 2012 - 06:12 AM, said:

Why validate every hit on every mech? It slows down the game and adds too much workload onto the server. Push the work back to the client and instead randomly validate a certain percentage of the shots.

If this validation is random enough and not predictable, this would curb any "cheaters" from editting client data. The only problem is PGI would have to take failed validation very seriously on this.

Another stipulation is that the client/netcode could not know whether the shot was being validated or not.

I think this solution would greatly increase how players felt about netcode and hit registration.

Um no. There's no peer-to-peer here so you're not saving anything while making it easier to cheat. This is a very bad idea indeed.