Introversion

xander wrote:

torig wrote:Thanks for the clarification.
Indeed, I wasn't getting it that way. Even now, the purpose entirely defeats me.

Pondering on "Why have every client know about all units - could bandwith be saved by transmitting less?" solved it finally. Since there is no central server every client transmits unit movements and activities to all the others.
What falls in the orders category exactly? Attacking, moving units, changing modes, ... -anything you can "interact with" you could say?

I'm wondering if this model isn't prone to replay attacks, but will have to test that out.

Replay attacks?

Basically, every client and the server know where every unit is supposed to be, because they keep track of the units on their own. Thus, if a player gives a unit an order that shouldn't work, that player will fall out of sync. One of the side effects of the network model that IV is using is that it is very hard to cheat, as the cheating client will simply fall out of sync.

xander

Replay attacks, yes. You replay previously captured legitimate traffic in the hope the previous result will still be achieved to eg. bypass authentication, generate more data on a weakly-encrypted wifi network so it takes less time to crack the key.
I'm wondering what would happen if you launched 5 nukes, captured that traffic and then sent it over and over again.
Would all clients be fooled into thinking you kept launching nukes, or would you indeed fall out of sync?
Notice here you aren't giving orders that cannot happen ; you're repeating a previous order. And now that I think about it even more, I wonder if it will be detected.

Imagine you are nuking Washington DC from an area around Paris. You could potentially send 10 nukes from the same silo to Washington. Wouldn't it look the same, on a network level?

torig wrote:Replay attacks, yes. You replay previously captured legitimate traffic in the hope the previous result will still be achieved to eg. bypass authentication, generate more data on a weakly-encrypted wifi network so it takes less time to crack the key.
I'm wondering what would happen if you launched 5 nukes, captured that traffic and then sent it over and over again.
Would all clients be fooled into thinking you kept launching nukes, or would you indeed fall out of sync?
Notice here you aren't giving orders that cannot happen ; you're repeating a previous order. And now that I think about it even more, I wonder if it will be detected.

Imagine you are nuking Washington DC from an area around Paris. You could potentially send 10 nukes from the same silo to Washington. Wouldn't it look the same, on a network level?

You would fall out of sync. Each client knows how many nukes you have. If you try to launch more nukes than you have, you fall out of sync. Similarly, I would assume that each client knows how quickly you can launch nukes, so if you try to launch 10 nukes at once, you would fall out of sync. More importantly, I don't think that you actually give the order to nuke, you only give the silo a target. When it can launch, it does. Every client knows what your target is, and will simulate the movement of the nuke on its own.

xander

weird ... looks like theres an interesting discussion behind this rather pointless thread

"Imagine you are nuking Washington DC from an area around Paris. You could potentially send 10 nukes from the same silo to Washington. Wouldn't it look the same, on a network level?"

You can always send 10 nukes from a silo -.-

What you describe as replay attack would possibly work until the nuke counter of this object reaches zero, but there s no advantage for you ... More important is the simple fact that all clients have the same (=full) information, so this is the main vulnerability of the system already ! The ways Defcon presents you the data you are ALLOWED to see are rather rudimentary, and can be modified ... while not modifying the original networking data.
Really one of the big disatvantages !

cya
xray

xander wrote:You would fall out of sync. Each client knows how many nukes you have. If you try to launch more nukes than you have, you fall out of sync. Similarly, I would assume that each client knows how quickly you can launch nukes, so if you try to launch 10 nukes at once, you would fall out of sync. More importantly, I don't think that you actually give the order to nuke, you only give the silo a target. When it can launch, it does. Every client knows what your target is, and will simulate the movement of the nuke on its own.

xander

Sorry if I'm not making myself clear xander. I think you are missing my point though.
An intact silo has 10 nukes. So you have the potential to hit the identical target 10 times from that silo. (though no one does that).
If and when you do, on a networking level, wouldn't the "information" look the same? Nuke going from XYZ to ABC ?
But you answered my next question "If you'd capture that traffic and rebroadcasted it to all parties involved, would all clients think more nukes were launched?". by saying each client knows how many nukes you have. So it seems this has been thought of by the devs

xray wrote:More important is the simple fact that all clients have the same (=full) information, so this is the main vulnerability of the system already ! The ways Defcon presents you the data you are ALLOWED to see are rather rudimentary, and can be modified ... while not modifying the original networking data.
Really one of the big disatvantages !

Just a note -- the kind of attack that you describe is simple. Hook up a second client, and spectate. That is all.

xander

xray wrote:weird ... looks like theres an interesting discussion behind this rather pointless thread

"Imagine you are nuking Washington DC from an area around Paris. You could potentially send 10 nukes from the same silo to Washington. Wouldn't it look the same, on a network level?"

You can always send 10 nukes from a silo -.-

What you describe as replay attack would possibly work until the nuke counter of this object reaches zero, but there s no advantage for you ... More important is the simple fact that all clients have the same (=full) information, so this is the main vulnerability of the system already ! The ways Defcon presents you the data you are ALLOWED to see are rather rudimentary, and can be modified ... while not modifying the original networking data.
Really one of the big disatvantages !

cya
xray

Well no, I was misunderstood or either I simply didn't clarify my point well enough.
I meant: you can send 10 nukes from 1 silo to 1 target : fact. (but no one does that...)

Would it look like 10x "the same event?"
What would thus happen if after 5 times you replayed that traffic?
Would all clients know "10 nukes were sent" and make your counter reach zero ?
At lest your client should still show that you can send 5 nukes, and allow you to send them.

That's the point I was trying to make.
I see the expected behaviour would be that you fall out of sync.
But could you then not capture someone else's traffic (=some launches) and rebroadcast it by spoofing the source, so that HE instead of you goes out of sync?
There is no acknowledgement of received packets as UDP is stateless. If it were TCP/IP you'd have sequence numbers to worry about when spoofing, so it would make the attack pretty unfeasable.
A more elegant solution would be for the clients to drop repeated traffic and broadcast a "PLAYER X IS CHEATING!!!" message to all ; only problem is that I'm guessing there is no way to distinguish from 10 unique launches from the exact same origin to the exact same destination, which makes it impossible to distinguish between 5 unique launches and 5 replayed ones, if you're still with me on this

I thought of what you said also, but wouldn't it require modification to the game binary, instead of being a simple network attack?

If it didn't detect that the nukes you had sent hadn't been taken from your silo, there'd be sync errors when you tried to fire nukes which you shouldn't have.

KingAl wrote:If it didn't detect that the nukes you had sent hadn't been taken from your silo, there'd be sync errors when you tried to fire nukes which you shouldn't have.

Thus you could potentially craft packets making it look as someone else "fired more nukes than they did in reality".
When they would try to fire their real nukes THEIR client displays, they'd fall out of sync.

I'll try to find some time tomorrow to test a few scenarios out.

torig wrote:

KingAl wrote:If it didn't detect that the nukes you had sent hadn't been taken from your silo, there'd be sync errors when you tried to fire nukes which you shouldn't have.

Thus you could potentially craft packets making it look as someone else "fired more nukes than they did in reality".
When they would try to fire their real nukes THEIR client displays, they'd fall out of sync.

I'll try to find some time tomorrow to test a few scenarios out.

As soon as one client believes something happened that another doesn't, things fall out of sync. I'm assuming that the host relays all the info to each of the other clients, so presumably if the host relayed incorrect information, then only the client that knows what *really* happened would fall out of sync. However, the incorrect happening would have to be possible. The first and last sentences are fact, the rest is assumption.

KingAl wrote:

torig wrote:

KingAl wrote:If it didn't detect that the nukes you had sent hadn't been taken from your silo, there'd be sync errors when you tried to fire nukes which you shouldn't have.

Thus you could potentially craft packets making it look as someone else "fired more nukes than they did in reality".
When they would try to fire their real nukes THEIR client displays, they'd fall out of sync.

I'll try to find some time tomorrow to test a few scenarios out.

As soon as one client believes something happened that another doesn't, things fall out of sync. I'm assuming that the host relays all the info to each of the other clients, so presumably if the host relayed incorrect information, then only the client that knows what *really* happened would fall out of sync. However, the incorrect happening would have to be possible. The first and last sentences are fact, the rest is assumption.

I'll grant you that, but the point I've been trying to get across is, that nothing in the protocol provides measures against clients relaying incorrect information.
So is must be dealt with in the application, the game here. If the dev's solution was to have all clients (and the server) keep track of the number of nukes and their use, then probably discarding duplicate packets is not happening.
And as I elaborated on above, the provisions to discard duplicate packets perhaps cannot even exist, as there are possibly scenario's in which duplicate packets are perfectly legitimate.

I actually don't think all clients relay all info directly to eachother. This would require direct connections to be set up between all clients, which requires all clients to become aware of each others IP addresses.
At the start of the game, you connect to a server - to one distinct IP address. So I'm guessing clients relay info to the server, which then relays it to all other clients.

torig wrote:I'll grant you that, but the point I've been trying to get across is, that nothing in the protocol provides measures against clients relaying incorrect information.
So is must be dealt with in the application, the game here. If the dev's solution was to have all clients (and the server) keep track of the number of nukes and their use, then probably discarding duplicate packets is not happening.
And as I elaborated on above, the provisions to discard duplicate packets perhaps cannot even exist, as there are possibly scenario's in which duplicate packets are perfectly legitimate.

I actually don't think all clients relay all info directly to eachother. This would require direct connections to be set up between all clients, which requires all clients to become aware of each others IP addresses.
At the start of the game, you connect to a server - to one distinct IP address. So I'm guessing clients relay info to the server, which then relays it to all other clients.

You're essentially reiterating what I just said. Naturally, the host essentially mediates the transfer of information. If the host provides false information, then the client which believes otherwise - i.e. the client of the player whose units it affects - falls out of sync. Similarly, if a client sends information claiming that a unit has done the impossible, the host will detect that and they will fall out of sync. Discarding of duplicate packets may not be happening, but in most cases it will have no significant beneficial effect for the offending player. Players cannot get extra nukes or have units appear where they shouldn't, because both server and client keep track of them (# of units, speed, position, path, firing speed etc), and any disparity causes them to fall out of sync.
Thus, it seems the only way in which the system could be manipulated is if the host sends false information about a player's moves and essentially controls that other player. This is true of all network based games, as if there is to be one host through which all messages are sent, the host can naturally manipulate information.

KingAl wrote:You're essentially reiterating what I just said. Naturally, the host essentially mediates the transfer of information. If the host provides false information, then the client which believes otherwise - i.e. the client of the player whose units it affects - falls out of sync. Similarly, if a client sends information claiming that a unit has done the impossible, the host will detect that and they will fall out of sync. Discarding of duplicate packets may not be happening, but in most cases it will have no significant beneficial effect for the offending player. Players cannot get extra nukes or have units appear where they shouldn't, because both server and client keep track of them (# of units, speed, position, path, firing speed etc), and any disparity causes them to fall out of sync.
Thus, it seems the only way in which the system could be manipulated is if the host sends false information about a player's moves and essentially controls that other player. This is true of all network based games, as if there is to be one host through which all messages are sent, the host can naturally manipulate information.

Ok, I think we both agree it is possible in theory. And going by the understanding of current gaming mechanics -including cheat prevention- we can safely deduct the attack would be possible in practice as well.

However, I do not agree with "Thus, it seems the only way in which the system could be manipulated is if the host sends false information about a player's moves and essentially controls that other player. This is true of all network based games, as if there is to be one host through which all messages are sent, the host can naturally manipulate information."

It seems like common sense that a host can manipulate information passing through it, but there are previsions against that. Notice that in our discussion, it's not the host itself that is manipulating information. It is passing on manipulated information, which is something you can account for I'd say.

Let's make the discussion a bit less abstract.

Imagine Player 1 nuking Paris from 1 fixed silo at a known (to the clients, not necessarily players) location and shooting at a known target looks like this (in line with xander's explanation of not transmitting nuke flight path but only lift-off and impact coordinates) (but probably highly oversimplified):
XYZ,ABC,silo
silo coordinates,target coordinates,reconfirmation of unit type for range deductions and counting of nukes

Every time the player fires a nuke from that silo to that target a "XYZ,ABC,silo" packet is transmitted to the server ; thus to all clients, who start substracting a nuke from the defined number of nukes for a silo (10).

If we create a fake packet XYZ,ABC,silo it will be calculated and tracked by all clients.
Q1: as the attacked client did not originate this packet, but possibly gets confirmation broadcasted by the server, would it then determine for itself it is out of sync already?
If the client does not fall out of sync and continues to play, at some point he is bound to try an illegal move as he's got 1 less nuke according to the other clients than he himself believes to have.
--> the client falls out of sync at this point.

To complicate matters further, what happens if his silo gets hit 1 or two times in between, halving the number of nukes he had before he tries an illegal move? Would this be something that could save him from falling out of sync?

But on to the actual point (yes, sorry for disgressing....):
Imagine the packets looked like:
XYZ,ABC,silo,nuke10/10
You could still easily forge a packet to look like it's the next in the sequence so that would offer no protection.

You'd need a value -a checksum as it were, or an initialisation vector (IV)- that can be checked so the packet would look like:
XYZ,ABC,silo,157849467806941036
(or possibly XYZ,ABC,silo,nuke8/10,157849467806941036).
Now, if only the client and customer can verify this number the other clients can't be left to blindly trust everything from the server, or indeed your assumption anything can be manipulated is correct. On the other hand, if that level of 'trust' can already be achieved, you eliminate the possibility of being able to desync any other client when you are just a client (not the server though).

If however you had interclient -as opposed to client-server-client - communication, upon receipt of the packets you could perform a verification of the checksum at the originating client itself. Implementing such a system would a bit defeat the central server purpose and advantages though

But yeah, that's why if you have a central server which is under control of no player you can further mitigate the risks of such attacks occuring.

(not to continue a discussion that might possibly bore you, but other invalid moves -if the unit type is also transmitted- could be to change a sub in a silo and so on. Making the attacked client fall out of sync immediately, instead of when it itself tried the "illegal" move... )

an alternative is to claim you are receiving bad data from other clients, which knocks them out of sync heheh
but i must admit its more destroying the game than cheating

if you're so curious about the packet forging, why dont you try and report

oh , and by the way .. torig .. if you want to know what sort of data is transmitted, just take a quick look at those "synclog"s , they have a lot of information

xray wrote:an alternative is to claim you are receiving bad data from other clients, which knocks them out of sync heheh
but i must admit its more destroying the game than cheating

if you're so curious about the packet forging, why dont you try and report

Heheh that's indeed even easier

True, but it's also a "high-tech" way of pestering other players. I, if I were IV, would be less worried about cheating up to some extent - provided there are no easy ways of doing it, but more with causing grief to other players -provided it was easy enough to do it.
Arguably here, this is not the case, but easy in this context depends on your mileage

I try to break servers, applications, clients, ... for a living so it's nice to sometimes have the self-discipline to say "not today baby" And actually do other stuff However, as security is my hobby, main area of interest AND profession what I read about the lagging and the clients seeing everything immediatelly triggered me into starting to cover all possible "what ifs" (it's a job "deformity". Just consider yourself glad you were NOT the sales rep that was trying to sell me a new car with a bluetooth carkit )
Now that I know it more or less seems feasible, I'll make sure to test it AND report my findings here. You can count on that

(and thanks for a very interesting discussion xray! )

PS: Just searched the directory to see if I have a synclog, but all it contains is:
Begin Final Object Positions

This kind of looks like what I positted above: XYZ,ABC,silo/sub/bomber,doggy-style/69/Italian Chandelier/spoons/...

What in heavens name happened to my thread?