Triggers for LOMAC in 1.13?

[Moa]

Sorry, my current day job is software consulting and development for large corps and government. I was merely trying to point out how reasonably foolproof security would be done on an industrial scale. If that's not what you need then cool - but be aware your 'good-enough' security mindset has failed for the last five years and will continue to fail unless you get serious about it. It does affect gameplay (since some have advantage that others don't) which is why it keeps coming up in these fora. Looking at the unreliable log output from LockOn I'd say correctness and security were not a priorities (understandable with limited resources) and probably never will be so I'll STFU. Perhaps I should instead whinge at the Free Falcon folk.

 

Lag will always be an issue no matter where you compute it. Fortunately missiles are deterministic and their flight paths can be evaluated ahead of time much better than bullets. Worrying about lag is inconsequential to things like the fact that seeker fields of view are not properly modeled, so I guess that is much more of a priority.

 

Interesting about CS doing it victim-side, although that effectively worsens the relative lag for the attacker, yeah?. Thanks for pointing that out.

 

No worries Yoda, I won't touch the 169 export.

[104th_Crunch]

Why? Having tacview as is right now makes it so much more flexible.

 

My thinking was if you include an ACMI tool in Lock On, then you don't need to have exports on to do this kind of thing outside of Lock On. More security even if features for customization become limited. Multiplayer wise anyway. In single player you could have all the customization open.

[GGTharos]

Sorry, my current day job is software consulting and development for large corps and government. I was merely trying to point out how reasonably foolproof security would be done on an industrial scale. If that's not what you need then cool - but be aware your 'good-enough' security mindset has failed for the last five years and will continue to fail unless you get serious about it. It does affect gameplay (since some have advantage that others don't) which is why it keeps coming up in these fora. Looking at the unreliable log output from LockOn I'd say correctness and security were not a priorities (understandable with limited resources) and probably never will be so I'll STFU. Perhaps I should instead whinge at the Free Falcon folk.

 

I'm not trying to say you don't know things about security - you obviously do. The case is that 'good-enough' is, however, good enough. It's a matter of diminishing returns. A game isn't some system even remotely requiring a high-end PKI solution, just to take things to one extreme.

Again, if you're coding a game, developing a high-end security solution starts becoming a waste of time quickly.

 

It isn't like the devs aren't aware of this, and indeed they are working towards applying potentially better working solutions.

 

What you suggest though is simply overkill.

 

Lag will always be an issue no matter where you compute it. Fortunately missiles are deterministic and their flight paths can be evaluated ahead of time much better than bullets. Worrying about lag is inconsequential to things like the fact that seeker fields of view are not properly modeled, so I guess that is much more of a priority.

Missiles are not deterministic. I'm sorry do say but there are very many dynamic processes happening there to attempt and guide a missile onto target. While this isn't simulated in all its complex glory, the unfortunate truth is that positional accuracy is required not only to simulate missiles hitting things, but to simulate secondary systems (prox fuze, etc) as well as their flaws. Positional accuracy is one of the things required, anyway - there's more to it. Suffice it to say that random elements are both necessary and existant, even in the current missile implementation.

 

Interesting about CS doing it victim-side, although that effectively worsens the relative lag for the attacker, yeah?. Thanks for pointing that out.

 

No worries Yoda, I won't touch the 169 export.

Not sure what you mean about CS. Some things are better done on client side, some on victim side. In some cases, it'll never be right - there's plenty of problems to go around.

 

If you do it attacker side, the victim might not see the bandit already having lead, but suddenly he's taking damage.

Do it victim side, and the lag for the attacker might make it impossible to hit. Do it on the server, and it's just bad all around, for everyone; and the effects can potentially differ depending on what system you are trying to simulate. Unguided and guided weapons might well have different requirements for functioning against lag.

[GGTharos]

Security for tacview isn't too hard to do, if you really want delayed writing for example, or at least no reading of the file while it is being written. Both prevent real-time viewing.

 

There's no reason to sacrifice flexibility for security in this case, since you can easily have both ;)

 

My thinking was if you include an ACMI tool in Lock On, then you don't need to have exports on to do this kind of thing outside of Lock On. More security even if features for customization become limited. Multiplayer wise anyway. In single player you could have all the customization open.

[Vault]

I had a look at DCS's network packets and they are encrypted which is standard security against attackers using packet editors, what I don't understand is why would you encrypt network data and not memory data? Does it really use that much more cpu cycles? I'm sure there's a reason for it but if you dont protect the raw data all an attacker needs to do is target and edit that raw data before it's processed by a certain .dll in DCS for encryption. When handling DCS's raw data all an attacker needs to be skilled at is hex, he doesn't need to know about encryption because DCS will decrypt/encrypt data for him, Forget ACMI exploits there for noobs, by editing the raw data it may be possible to execute more advanced cheats for example like turn aircraft labels on and off on MP servers on the attackers machine and you wouldn't know about it..

 

If it's impossible to encrypt the raw data because of MP lag then we need some form of program that'll read the clients PC for suspect running processes and a file integrity check that will run before DCS joins a server this isn't fool proof but it'll keep 99.9% of cheats away from the code.

Edited August 2, 2009 by Vault

[RvEYoda]

Moa its done SHooter side, not victim Side in CS. I was just giving it as

an example where it was not done server side. Most games have moved

away from a completely server centralized setup because doing these

things on a preferred client has very significant lag/delay improvements.

It Is one of the most major points in multiplayer games in my opinion,

and doing it on the defender's side you can really make it consistent

for the defender and attacker how a shot will perform.

 

We don't want the falcon setup where the missile explodes 100m behind you on

your screen and then you die *for no reason* because on the server it exploded

on you. This makes for terrible learning experience when it comes to defenses.

You risk having it become totally inconsistent. And worst of all it will vary

depending on your network ping to the server. Such a net code would at least,

for me, completely ruin gameplay.

 

And as many other games already do this a preferred client, i'm srue they have

also figured out viable ways to iron out cheating and similar things, being as

hugely popular as they are.

Edited August 2, 2009 by =RvE=Yoda

[GGTharos]

I had a look at DCS's network packets and they are encrypted which is standard security against attackers using packet editors,

 

While I haven't looked at them myself, are you certain they're encrypted rather than encoded, and that it might look this way to you because you don't know what's being sent?

 

If it's impossible to encrypt the raw data because of MP lag then we need some form of program that'll read the clients PC for suspect running processes and a file integrity check that will run before DCS joins a server this isn't fool proof but it'll keep 99.9% of cheats away from the code.

 

And this is exactly what's beeing implemented in the DCS patch.

[Vault]

While I haven't looked at them myself, are you certain they're encrypted rather than encoded, and that it might look this way to you because you don't know what's being sent?

 

 

 

And this is exactly what's beeing implemented in the DCS patch.

 

GG I'm pretty damn sure DCS encrypts packet data, the packet editor I used automatically decodes the hex inside the packets to plain text and all the plain text was random jargon which is a good sign that DCS's packets are encrypted, TBH I was more interested to see if DCS was wrapping raw data inside the packets to send over the network but there not. I confirmed my suspisions by sending some text into DCS's chat and recorded the sent packets and I couldn't decode any of the sent packets hex data back into plain text that corresponded with the message I'd sent into chat as it was just random jargon.

[GGTharos]

GG I'm pretty damn sure DCS encrypts packet data, the packet editor I used automatically decodes the hex inside the packets to plain text and all the plain text was random jargon which is a good sign that DCS's packets are encrypted, TBH I was more interested to see if DCS was wrapping raw data inside the packets to send over the network but there not.

 

You might be right, but lack of decoding into readable text does not imply encryption - it could just as easily be well packed raw binary data.

 

I confirmed my suspisions by sending some text into DCS's chat and recorded the sent packets and I couldn't decode any of the sent packets hex data back into plain text that corresponded with the message I'd sent into chat as it was just random jargon.

 

Alright - well, I don't know the answer, but I think it might be packing or compression at most. Perhaps Chizh can answer this one :)

[A.S]

If you have believe everybody behaves the same as you think then you'd be right, but most of the people that fly Lockon long term are a lot more mature than that.

A lot of people that just fly it as a sort of Airquake to pass the time didn't know anything about exploits etc. until it was broadcast for eveyone to see. Personally I can't understand what you write half the time because its made up of so many .... but seeing you telling other people to grow up and stop being so egotistical, for me smacks of hypocrisy.

 

Should i appologize now, that in the matter of this discussion YOUR knowledge has been "leaked" to airquaking noobs, what was suppossed to be only YOUR knowledge?

By issuing things and not maintaining in secrecy i proof right there, that i dont act EGOistic!!!

Are you afraid of somthing...:music_whistling:.. coming back to "growing up"?

 

gimme a break :doh: