Technical solution to eliminate desync in single-player sessions

"

tadl wrote:

What is really scary about this thread:

* We don't know who actually knows what he is talking about or not
* We don't know who just speculates without/with basic knowledge
* We don't know who speculates without/with real knowledge

And most important

* We don't know who has practice knowledge than this is > all.

So, sry here is the internet failing because of the anonymity. If people really want to talk about it you have to give your background too. Or this is all pointless. Its not hard to convince people to believe that something will work. Its actually pretty fucking easy and if you do not believe it you somehow manged to ignore the RL completely.

For three years and some change, I was a MOS 25U in the United States Army, working for a S6 shop, including a tour to Afghanistan. What I did in practice was much more similar to MOS 25B, because we had a lot of tech (Aviation unit) and only moderate amounts of radios (helicopter radios are their own MOS). Although I did do some radios too.

I designed network topologies, routed a bunch of Ethernet cable, configured countless workstations, maintained a file server, configured switches, created user and email accounts, installed computerized communications systems in vehicles, made sure CNN was up for the operations people to watch, and pretty much solved any problem anyone had with any equipment which involved either a digital screen or network access.

Everything about my job had information security at the forefront. Data encryption, voice encryption, smart card authentication, physical security, separation of Secret and non-Secret, secure passwords. It was my team's job to make sure the keys to our communication networks did not fall in enemy hands.

A lot of people in my shop were kind laid-back. I wasn't. As a result, I ended up doing a lot of the work — in some months, with a shop of a dozen people, I had over 51% of the completed work tickets. I took care of everything I could; they didn't have to take care of much. Everyone was happy with that arrangement. I loved my job.

Didn't code much. Wrote a very angry ping-sweeper this one time in Notepad (as a batch file, with text output). Had to, couldn't download, Internet was down, needed it to diagnose. That was about it. Decent at reading code though; I've done a lot of experimental Registry edits in my time trying to fix obscure problems.

"

qwave wrote:

It's not hard to download a compiler and run the code. If you modify the Packet instance at all, the server will know it.

Not as written. And no, I won't. I read your white paper, I researched your bitcoins, and I read your laughable code. That's enough investment with zero payoff out of me. I'm done with this thread. Your "deterministic simulation" idea is good, when properly applied to a client simulation with a server true gamestate; your "trust the client" idea is shit. Final answer. Find someone else to argue with.

qwave, I don't have time for a full post, but your timestamp signing is unneeded. Just instead of allowing the client to say that it attacked a target at time t with some result, just make the client say player initiated attack on a target at time t with some result. That way no speedhack can be used, because if the client said that you managed 2 attacks at the same time, the server would not be able to reproduce it with same commands, and would detect it.

Haha, ScrotieMcB quits the thread once I write the code for the system. Classic. ;-)

"

ScrotieMcB wrote:

"

tadl wrote:

What is really scary about this thread:

* We don't know who actually knows what he is talking about or not
* We don't know who just speculates without/with basic knowledge
* We don't know who speculates without/with real knowledge

And most important

* We don't know who has practice knowledge than this is > all.

So, sry here is the internet failing because of the anonymity. If people really want to talk about it you have to give your background too. Or this is all pointless. Its not hard to convince people to believe that something will work. Its actually pretty fucking easy and if you do not believe it you somehow manged to ignore the RL completely.

For three years and some change, I was a MOS 25U in the United States Army, working for a S6 shop, including a tour to Afghanistan. What I did in practice was much more similar to MOS 25B, because we had a lot of tech (Aviation unit) and only moderate amounts of radios (helicopter radios are their own MOS). Although I did do some radios too.

I designed network topologies, routed a bunch of Ethernet cable, configured countless workstations, maintained a file server, configured switches, created user and email accounts, installed computerized communications systems in vehicles, made sure CNN was up for the operations people to watch, and pretty much solved any problem anyone had with any equipment which involved either a digital screen or network access.

Everything about my job had information security at the forefront. Data encryption, voice encryption, smart card authentication, physical security, separation of Secret and non-Secret, secure passwords. It was my team's job to make sure the keys to our communication networks did not fall in enemy hands.

A lot of people in my shop were kind laid-back. I wasn't. As a result, I ended up doing a lot of the work — in some months, with a shop of a dozen people, I had over 51% of the completed work tickets. I took care of everything I could; they didn't have to take care of much. Everyone was happy with that arrangement. I loved my job.

Didn't code much. Wrote a very angry ping-sweeper this one time in Notepad (as a batch file, with text output). Had to, couldn't download, Internet was down, needed it to diagnose. That was about it. Decent at reading code though; I've done a lot of experimental Registry edits in my time trying to fix obscure problems.

"

qwave wrote:

It's not hard to download a compiler and run the code. If you modify the Packet instance at all, the server will know it.

Not as written. And no, I won't. I read your white paper, I researched your bitcoins, and I read your laughable code. That's enough investment with zero payoff out of me. I'm done with this thread. Your "deterministic simulation" idea is good, when properly applied to a client simulation with a server true gamestate; your "trust the client" idea is shit. Final answer. Find someone else to argue with.

Since you very experience with security maybe instead of flaming him you should help him write a secure code? Take it as a challenge:D

The fail in this is astounding. Seriously.

Let's break this, shall we?

"

using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Cryptography;
using System.Text;

namespace POEExample {
class Program {

// This is the shared seed that the client and server both use for the simulation
public const int SharedSeed = 12345;

Overly simplistic. Seriously, a 32-bit integer as a seed? This is breakable (as in I can write a function to sniff data and reverse-engineer this) in microseconds.

"

// This represents the player's movement speed, he can only attack things in range
public const int MoveSpeed = 30;

Movespeed is not a constant. Quicksilver flasks, anyone? Or do you mean that the server generates and sends a new seed every time I drink a freaking flask? That's desync right there.

"

// This functions returns a list of mobs that the client/server knows about
static List<int> GetMobs() {

var mobs = new List<int>();

// Lets add mobs in a few locations, the number is their distance from the player
mobs.Add(10);
mobs.Add(15);
mobs.Add(30);
mobs.Add(50);
mobs.Add(70);
mobs.Add(100);

return mobs;
}

Mob location is always in an x, y format. I guess your 12 years in the computer industry never told you that cartesian coordinates need two numbers, otherwise you're stating a radius, not a location.

"

static void Main(string[] args) {

// This is the client seed
var clientSeed = new Random(SharedSeed);

Console.WriteLine(Environment.NewLine);

// Every snapshot requires a timestamp, which starts at the beginning of each snapshot.
// The client cannot change this without the server knowing!
var timestamp = DateTime.Now.Ticks;

This assumes a few things:

1) The server date and time are completely, perfectly in sync with the client. The client cannot even be a second late or early. (Which is stupid, anyone with 12 years of computing experience knows how hard it is to keep two electronic clocks completely in sync all the time).
2) The server runs at the exact same speed as the client. Slower PC = slower delta, for the sheer reason that it's slower, dumbass, it can't run the code at the same speed as the server.
3) Nothing overwrites client date/time state while the game is playing. Looks like I need to turn off core windows services, like, I dunno, Windows Time?

"

// This is the mob you decide to target, it must be valid and within distance or the server knows you cheated
var mob = GetMobs().First();

// Move to and attack the mob, you can insert ANY mob you want into here as long as it's a valid target
Attack(clientSeed, mob, timestamp);

I am pretty much sure that the targeting and attacking code is way more complex than this. Evasion? Armor? Range checks? How about block? Damage reduction? Pierce? Oh, and manual evade from movement too? Overly simplistic code is overly simplistic.
Also,

"Attack(clientSeed, mob, timestamp);"

What's to prevent me from standing in place, and not attacking, while a background process does

function DamageOptimizer {

for(x= timestamp; x < timestamp + (arbitrary amount of time); x + (very small time increment){
Attack(clientSeed, mob, x);
if(Attack.Damage=InstantKill){
waitFunctionToWaitUntilTimestampAndXAreTheSame(x, timestamp);
return Attack(clientSeed, mob, x);
break;
}
}
}

You did say that the client Seed was used to determine damage, right? Or will you pseudo-edit your quote here?

"

qwave wrote:

- The server can calculate every attack using the seed. If you run the code, you will see output for every attack value.

Your algorithm computed damage as a function of timestamp and seed. Vary the timestamp until you get an optimal result, and poof! Permanent critical!

But wait! The timestamp is used to compute what your attack did? Then stop attacking! The increments across timestamps are infinitesimally small, so what does it matter if your attack is 5ms late if you deal twice as much damage?

This is why engineers with 12 years of experience in coding games do not use time as a function to determine damage, because people will exploit that by playing only at times where damage is optimal. Remember, you said that you're using a "deterministic seed to generate pseudo-random numbers". Pseudo-random means that somewhere there you'll see an unusually high bunch of numbers.

"

Console.WriteLine();

// This is the packet that the client sends to the server. If you modify it, the server can identify that it's fake.
var packet = new Packet {
Timestamp = timestamp,
Signature = Hash(clientSeed.Next().ToString(), timestamp.ToString()),
Target = mob
};

I have a background process called InjectorForStupidAlgo. It does this

var packet = new Packet {
breakpoint
Function_That_Waits_And_Stands_Still_Until_You_Get_To_The_Timestamp_You_Want();

"

// Send the packet to the server to see if you cheated
ServerValidate(packet);

Console.ReadKey();
}

// In order to attack a mob, the player must perform 1 calculation per 5 distance of the mob. The server can determine if these calculations were performed or not.
private static void Attack(Random seed, int mob, long baseTimestamp) {
for (var count = 0; count < (mob / 5); count++) {

You said server validated if these calculations are performed or not. What prevents me from performing more than the usual number of calculations and looking for an optimal result? More complexity = more lag in the server, because every 5 computations you make the client do, the server has to do for each client that is connected to it. It therefore follows that the moment the advance computations become too taxing for the client to do, your server is already dead because it has to compute the same damned thing for THOUSANDS OF CLIENTS.

"

// The server simulates the attack
Attack(serverSeed, packet.Target, packet.Timestamp);

Console.WriteLine();

Trusting the client-appended timestamp, are we? Speedhax, I can easily forge a client timestamp. Remember, the client has both the seed, the timestamp, and the algorithm for hashing. Or are you saying that the client somehow magically does not have the seed or timestamp?


This exercise in mediocrity just proves how stupid this idea is.

Sachiru, I really don't understand how this continually goes over your head completely.

"

Overly simplistic. Seriously, a 32-bit integer as a seed? This is breakable (as in I can write a function to sniff data and reverse-engineer this) in microseconds.

The seed can be any value. It's not supposed to be secure. None of the client-side code can ever be secured, any hacker to get to these values.

"

Movespeed is not a constant. Quicksilver flasks, anyone? Or do you mean that the server generates and sends a new seed every time I drink a freaking flask? That's desync right there.

Change the move speed then, it doesn't matter. I just defined it as a const in the code, but you can change it to whatever you want. The server will validate it.

"

Mob location is always in an x, y format. I guess your 12 years in the computer industry never told you that cartesian coordinates need two numbers, otherwise you're stating a radius, not a location.

These are distances. This is just example code.



You have a complete misunderstanding of how the delta is calculated. It's 100% client-handled.

"

I am pretty much sure that the targeting and attacking code is way more complex than this. Evasion? Armor? Range checks? How about block? Damage reduction? Pierce? Oh, and manual evade from movement too? Overly simplistic code is overly simplistic.

Go ahead and add all those values in. It doesn't change anything.

"

Trusting the client-appended timestamp, are we? Speedhax, I can easily forge a client timestamp.

The timestamp doesn't matter, the delta does. The timestamp is generated so that the delta can be seeded.


Again, you have not understood a single piece of this system, and you obviously have not run the code. Try to change the input/output, go ahead.

"

Trusting the client-appended timestamp, are we? Speedhax, I can easily forge a client timestamp. Remember, the client has both the seed, the timestamp, and the algorithm for hashing. Or are you saying that the client somehow magically does not have the seed or timestamp?

This is what I immediately noticed. That the seed is 32-bit, mobs are lined up in a 1 dimensional space instead of 2 dimensional, etc. is just for purposes of example. That's not a big deal.

What I question is this:



The signature is computed by the client using a hash of the timestamp and the next value of the RNG. The code above checks to see that the packet was not modified afterward ... provided that whoever modified it didn't have access to that RNG value (they do), the timestamp (they do), or the method by which the hash was computed (they do).

As far as I can tell, this just stops some sort of man-in-the-middle attack from happening. Does this code have a purpose beyond that?

Just out of curiosity, what do you plan to hash against when I'm just moving, or attacking without a target (cleave, spec throw, etc)

"

qwave wrote:

The timestamp doesn't matter, the delta does. The timestamp is generated so that the delta can be seeded.

And as I tell you, because the delta is just a series of bits in memory, I can change the delta to whatever the hell I want. It's simply a matter of computing the optimal delta, then WAITING. Delta is time elapsed, so simply WAIT UNTIL THE TIME ELAPSES for your time to match.

[Removed by Admin]

P.S. I am so totally submitting this to thedailywtf.com

"

As far as I can tell, this just stops some sort of man-in-the-middle attack from happening. Does this code have a purpose beyond that?

The signature is an example of how to sign a packet. Technically you should probably sign the packet using the seed + timestamp + serialized packet. But I am just trying to illustrate how it's done.