How to stop this CHEAT - HACKED DEDI SERVER

Well, it seems that the most vital and useful security we need is to just make sure that it will always be possible to identify people via UCID and IP, and ban them. The number of folks out there that actually hack the game like this is very small- 1 person, seemingly. So long as the security of the UCID holds, and servers can always kick them, then they won't be a problem but once for each server. Banning by IP will be less useful, due to proxy servers, but it will add one degree of complication to the efforts of a hacking loser.

I suggest you to write a validator for A10C flight model.

From your responses it shows you are not getting my point (elaborated by Aldega to try make it clearer to you).

There are two kinds of validation you can do:

1) development time: unit tests, integration tests, and

2) runtime checking.

Clearly you wouldn't validate the A10C flight model at runtime - this would be done with hundreds of unit tests on the flight model trying all sorts of flight conditions from normal flight to negative airspeed tail-slides (you have these, don't you?).

At runtime would validate the *inputs* to the flight model, eg. do the parameters loaded from config make sense? these checks can't be a straightjacket, but checking against null or non-sensical values would help program robustness.

Also at runtime you can check the *input* from the client across the network. Has the client said he's launched a missile when the server knows he's already launched his complement of missiles. Has his position changed so much that he could only have got there are Mach 25 etc. These are really basic things that hackers are currently exploiting. It would take microseconds to check these.

Why are we making these unasked for suggestions? Well, the DCS concept is fantastic product and we want to make it better. The DCS implementation at the moment is improving but doesn't give a great experience in multiplayer. In some areas recent patches have made stability go backwards. We have noticed significant multi-player bugs that basically makes the multi-player experience unusable for our purposes. I have done the hosting and set-up for the three large-scale A-10C Fly-Ins, so possibly have more experience that anybody at running large-scale [30-50 player] DCS multi-player events. This makes me feel qualified to make some comments about the multi-player experience.

Now giving specific examples is hard since I have no source code. If I did I'm sure I would have many suggestions. I don't so can only give 'black-box' testing comments.

Here are some suggestions. They are meant in a spirit of constructive criticism. As a fellow developer I know that some criticism turns out to be invalid due to other concerns, but at least some of it is valid. Also, I don't think the security issues are totally isolated with the general approach to stability - since it is the overall experience that your customers see.

1) Validate all your inputs. From the network and everything read from disk. Concrete example: if you change monitors the program can't cope and crashes on startup (without displaying anything sensible or logging anything). A simple check comparing the configured value and the detected monitor resolution would prevent this problem. At the moment the forums frequently get questions about crashes on program startup because of the simple lack of checking. All parameters ought to be checked this way (if you'd used XML instead of Lua tables then an XSD would be a great help for validation, plus give information about the problem).

Unfortunately the choice of Lua means that many data input problems slip by without Lua warning you. Look at the 'options' files in the FC2 missions. They have a varied set of option fields (indicating the missions were probably developed during different internal FC2 builds where the options structure was changing). That means some parameters are not being set in some missions. If you have random initial conditions starting a game of course you are going to get stability and reliability problems. A validating check on mission load would have picked these up during 'development' and helped you write a more reliable program.

The information read from the network needs to be validated too - this includes coping with 'short reads' (getting fewer bytes than expected) and formatting inconsistencies (buffer lengths reported don't match actual buffer lengths).

It is interesting to hear you say that this has been done since LockOn 1, since the recent experience is that a few bytes sent to a FC2 (and presumably DCS) game server could crash it (thankfully fixed by the recent patch). Somehow I can't quite reconcile those facts - I must be missing something from the picture.

2) Clean up all the broken references to resources. In the logs there are all sorts of warnings about missing references to resources. Not only does this decrease the signal-to-noise of the logs (hard to pick out important messages from the general stuff), it also shows that the program can't be operating as expected, since some of the things it needs are not present or in a different place. The solution is not to suppress the logging, it is to get the people responsible for maintaining the references/paths to resources to go through and fix the paths. The program will never be stable without this.

3) Improve logging. In the case where the monitor resolution is blank or invalid no message is logged, the program simply quits. Since you are validating your inputs you'll log what the read value was and what the program thinks the valid range is (sometimes you can have a bug where the program is getting the wrong check values). Without having good logs it makes your job harder, since we can't give you the information you need to fix hard-to-find bugs.

4) Build for an imperfect network environment. Requiring continuous connection to the master server will always result in an unreliable program (in internet parlance this design is a 'fail'). No one can make the Internet perfectly reliable, so you mitigate this with ways to cope with the unreliability, while still achieving the aim of only allowing valid customers to use the software. I've already pointed out a way to do this.

So, I can't tell you which lines of code to change and can only give you suggestions. I hope I've given you some concrete examples to illustrate what I can see as issues that could be fixed pretty easily - improving both program reliability and hacker resistance.

The code base is too big to make validation changes to all at once. What can be done is that all *new* code gets unit test coverage where it can (sure, not all game code can be - especially rendering and GUI - but much can), and validation of critical inputs and state (known as 'checking preconditions').

Again, these comments are not intended to give you a bad day at work. I think DCS is a very impressive bit of software. I do think it could be made more reliable and some of the faults are fixable by using systematic practices rather than ad-hoc fixes later. From what I observe of the programs behaviour it appears that some development practices I have suggested (automated testing, validating inputs, making log quality important) could be used or improved. I do believe that it will make the life of ED developers easier in the long run, result in a better product, and give a better customer experience. More satisfied customers means more sales as the series progresses because *positive* customer buzz generates revenue.

Well, it seems that the most vital and useful security we need is to just make sure that it will always be possible to identify people via UCID and IP, and ban them. The number of folks out there that actually hack the game like this is very small- 1 person, seemingly. So long as the security of the UCID holds, and servers can always kick them, then they won't be a problem but once for each server. Banning by IP will be less useful, due to proxy servers, but it will add one degree of complication to the efforts of a hacking loser.

This is already possible to get a UCID on connection, as you probably already know. Sometimes the UCID seems to come through with a different value for the same person - I haven't checked whether that is a bug in my stats code (which logs all connections) or it really is sent with a different value sometimes (as far as I can tell it is the latter, but I can't rule out the former - I have to check the original log entries, which I also store for just such purposes).

The recent problem with the hacker was that they could send packets to the server and the server would accept them, and crash. I don't know whether the sending hacker/user was authenticated or not - from c0ff's reply it seems he must have been authenticated, so it would be nice if UCID's that send invalid packets are logged. This crash on a specially crafted packet has been fixed. Apparently the server drops all packets for unathenticated users, expect if it is a *valid* authentication request.

Unfortunately there is no information on how to derive UCID from an arbitrary packet. Perhaps the UCID is transmitted on each request, I don't know the network protocol so don't know whether client identification information is part of each packet or not.

If a UCID isn't transmitted then it makes it possible for packets to be sent anonymously (except the established connection means they must have authenticated in the past, but it doesn't mean modders can derive the UCID from the connection).

Note that better than a UCID is a 'session token' which can be resolved to a UCID. A session token has the benefits of being time-limited (unlike a UCID) and can contain an encrypted or hashed UCID so the UCID isn't transmitted in the clear. That way you don't have to use TLS for the rest of the packet (since TLS makes network comms slower if you are using encryption).

Is session id just an int? or is it more complicated, including a 'nonce' timestamp to prevent replay attacks?

Thanks for talking with us c0ff.

Let's say session id is a part of the encryption key.

Replay attacks are one of my current concerns. Thanks for reminding.

Excellent! please keep up the great progress.

The irony in those screenshots is enormous.

Exactly... after what was discussed on TS yesterday....the irony is truly enormous. So yesterday's assumptions go out the window? :D

LOL^ sssh. :D

Tushkan. Where is the video you promised... before you edited the post. I want to see the video. Also need some funny political slogan on it like last time. Thanks. :)

So your the hacker huh?

So your the hacker huh?

Only losers have to use Hack Mods to make themselves feel great...

I don't see any cheats in the video? AIM-120 on flankers are already legal on some servers, nothing new here... OK, not AIM-120, rather R-77,but soon, who knows...By the way, nice video. I see you're using ricardo HD pits, good choice ... :D

P.S. and you can't enter on servers with password...drop dead...:D

Again someone is hacking LO-servers... been on =RF=, someone came and started shooting us all down. Invisible. No kills in player-list, simply we all "crashed" or "killed by Building". Blue/Red, all.

Some of us locked him, he's been flying in 30.000m (!) 3000km/h (!). Then he crashed into ground deliberately, reflected undamaged like ball, flying further. PVO been firing on him dozens of missiles, without damage. And he had unlimited ammo/fuel. WTF???

IS THIS GAME GOING TO BE PLAYABLE FINALLY?

ED, WHAT DID WE PAY FOR? THIS CRAP???

I think baning this guy wont solve the problem... BTW, i loved that video...:D

@Rhinox, you always have singleplay...

aw, the guy is as stealthy on these forums as in the servers, hes gone :P

I don't see any cheats in the video?

Wasn't just referring to the video!

I think baning this guy wont solve the problem... BTW, i loved that video...:D

 

@Rhinox, you always have singleplay...

You must be blind not to see 20 AI wingmen beside him.

Damn I missed the video....

Hopefully this problem will be solved when that kid reaches adulthood. Could be some time ...

You must be blind not to see 20 AI wingmen beside him.

That was a joke Pilo.;) I tried to underestimate his "work"...