How to stop this CHEAT - HACKED DEDI SERVER

[c0ff]

• When the offending player is kicked from the server the plane he flies dissappears, but the AI planes remain and will engage players
  

Does this actually happen? If it does, it means that those AI planes are created on the server, not on a hacked client...

[Case]

Does this actually happen? If it does, it means that those AI planes are created on the server, not on a hacked client...

 

Yes, as far as I can tell the AI planes stay after kicking the player you think is the hacker.

[4c Hajduk Veljko]

The cheat in 1st post looks like an attack from a specially crafted fake client.

Some determined guy took time to analyze network protocol.

 

Patch for DCS (as well as future FC3) will have a protection against this and many other kinds of network attacks.

I appreciate your comments which assures us that ED is working on a problem.

 

This attack, this hacker, is attack primarily on Fighter Collection and ED business. I wish the attacker could be traced and brought in the court of law for breaching EULA.

 

Nevertheless, please keep working on a problem, I will patiently wait for a proper resolution from Fighter Collection and ED.

[Speed]

Does this actually happen? If it does, it means that those AI planes are created on the server, not on a hacked client...

 

Yes, that's what the hosts said. He's creating AI aircraft that fly around after he's gone. Even if that's not true, he's definitely creating AI aircraft when he spawns. The favorite theory is that he's modifying the mission Lua environment on his machine, either while the mission is loading or after it has loaded, to tell the server that when he spawns, it should also spawn a lot of AI aircraft or wingmen as well. No one has actually checked if this works though. You'd know better than we would. I could perhaps give it a try in the current public version of the simulation engine and see what happens.

[Speed]

This attack, this hacker, is attack primarily on Fighter Collection and ED business. I wish the attacker could be traced and brought in the court of law for breaching EULA.

Agreed. He's deliberately harming a company, and he should face criminal charges. At the very least, ED could sue him if they could prove who he is. But perhaps their time is better spent just closing security holes.

[Sov13t]

Agreed. He's deliberately harming a company, and he should face criminal charges. At the very least, ED could sue him if they could prove who he is. But perhaps their time is better spent just closing security holes.

 

Yeah, while this can definitely be done in the U.S., in Russia... not so much. However, there are other means of fixing such situations in the Third Rome that are a bit more "brute".

[zipdigital]

Flight sims are a specialized type of game, thus limiting the types of players who enjoy them.

 

DCS takes it a step further by being a "study sim," limiting the players down to a comparatively small community of patient but technical few.

 

Multiplayer further limits the number of players who might play. (Some players avoid multiplay altogether for any number of reasons)

 

That said, I really don't understand why someone or some people would take the time to find out how the client communicates and functions in order to cause the issues listed in this thread, or take the time to ruin the enjoyment of said few.

 

As an ex network security engineer, I understand the method and purpose of the majority of hacks, viruses, malware and social engineering. Simply put: to make or steal money. That isn't happening with this type of hack, so I am dumbstruck as to why anyone wastes the time to bugger up a dedicated server that exists for enjoyment of the DCS community.

Edited February 15, 2012 by zipdigital

[GGTharos]

Money is just one obvious motivator. It doesn't need to be the only one or even the main one.

 

Anything from a power trip to a smile will do.

 

As an ex network security engineer, I understand the purpose of the majority of hacks, viruses, malware and social engineering. Simply put: to make or steal money. That isn't happening with this type of hack, so I am dumbstruck as to why anyone wastes the time to bugger up a dedicated server that exists for enjoyment of the DCS community..

[zipdigital]

 

Anything from a power trip to a smile will do.

 

Excellent quote!

[c0ff]

Actually, I'm surprised that it took 9 years since LOMAC for protocol-level attacks to show up.

Back then I decided to spend time on encryption only if/when it's needed.

 

Thanks to this guy(s) DCS now is a much harder nut to crack.

 

Game-level protection, currently implemented as integrity check, is still an open question, but we are working on a better system.

[Boberro]

Perhaps during 9 years there were no such *nub kids* who were willing to disable servers only for disabling them. There always must be the first time =)

[Moa]

Actually, I'm surprised that it took 9 years since LOMAC for protocol-level attacks to show up.

Back then I decided to spend time on encryption only if/when it's needed.

 

Thanks to this guy(s) DCS now is a much harder nut to crack.

 

Game-level protection, currently implemented as integrity check, is still an open question, but we are working on a better system.

 

Thanks for making DCS better Dmitry.

 

Is it possible for the Integrity Check to ignore whitespace and Lua comments? Rather than a bit-for-bit exact match normalize the server and client side Lua (compact whitespace and remove comments) before doing the comparison. If it is too hard then that is ok, but if it is easy then that means we can leave as comments the include for TacView etc even on servers where TacView is not permitted. Then you can just comment and uncomment stuff.

 

With regard to the protocol level stuff. Would it be too expensive for the server to validate the inputs from clients, or is that what you are doing now?

[Speed]

Thanks for making DCS better Dmitry.

 

Is it possible for the Integrity Check to ignore whitespace and Lua comments? Rather than a bit-for-bit exact match normalize the server and client side Lua (compact whitespace and remove comments) before doing the comparison. If it is too hard then that is ok, but if it is easy then that means we can leave as comments the include for TacView etc even on servers where TacView is not permitted. Then you can just comment and uncomment stuff.

 

With regard to the protocol level stuff. Would it be too expensive for the server to validate the inputs from clients, or is that what you are doing now?

 

Hmm... how would one do this though? One could read the file into a string, and use the rules we know for Lua comments to remove all commented space. But how does one distinguish between significant and non-signficant spaces?

 

Ah wait. I think I might have it. It might be rather easy:

file = open(<server's lua file>, 'r')
server_lua_string = file:read()
server_lua = string.dump(loadstring(server_lua_string))

--[[ the contents of the client's lua file are received over the network 
    and stored in the string variable "client_lua_string" ]]

client_lua =  string.dump(loadstring(client_lua_string))

if client_lua ~= server_lua then
  --integrity check failed
else
  --integrity check passed
end

 

loadstring compiles a string into Lua, and returns a function you can call that will execute that compiled code.

 

I've never used string.dump, but in theory, I know it's supposed to take a function defined in Lua, and decompile it into a string.

 

So in theory, this code will allow you two integrity check two files, and ignore all comments and insignificant whitespace, because instead of comparing the two files directly, you're comparing only the parts of those files that are significant in Lua. But will it actually work? Will string.dump always return the same string on the same Lua function?

 

And of course, this would probably actually be coded in C, not Lua, but I don't know how the Lua C API works. Maybe I should read that section sometime :)

 

Anyway, like Moa, I also had some ideas for the IC that I think would make it much more flexible and mod-friendly here:

 

http://forums.eagle.ru/showpost.php?p=1376380&postcount=121

Edited February 16, 2012 by Speed

[Speed]

Actually, I'm surprised that it took 9 years since LOMAC for protocol-level attacks to show up.

 

I donno... considering that the multiplayer flight simming community is much, much, MUCH more mature on average than the usual multiplayer community of a game, is it that surprising? Then again, more mature individuals would also be more likely to have the know-how to execute attacks like these.

 

And yes, thanks for your continuing work on the net code, c0ff.

[Moa]

> But how does one distinguish between significant and non-signficant spaces?

 

Not required. Simply compact all sequences of whitespace (space, tab, carriage return etc etc) into a single space charatecter. Also replace all Lua comments with a single space before this. Once 'normalized' in this way you can then do a bitwise comparison. This is the kind of thing compilers do (normalize space).

[c0ff]

Idea with string.dump(loadstring()) looks good.

[Heli Shed]

I donno... considering that the multiplayer flight simming community is much, much, MUCH more mature on average than the usual multiplayer community of a game, .................

 

True that.

 

http://forums.eagle.ru/showthread.php?t=85364

 

:thumbup:

[Speed]

> But how does one distinguish between significant and non-signficant spaces?

 

Not required. Simply compact all sequences of whitespace (space, tab, carriage return etc etc) into a single space charatecter. Also replace all Lua comments with a single space before this. Once 'normalized' in this way you can then do a bitwise comparison. This is the kind of thing compilers do (normalize space).

 

One problem this doesn't solve is that this:

t = { var1, var2, var3, } 

is the same as this:

t={var1,var2,var3} 

just for example. I can think of lots of other places where you can insert single whitespaces into your code and it makes no difference. I suppose you could come up with some rules for determining which are significant and which are insignificant, i.e., all spaces after a { and before a } are insignificant; all spaces before and after a ( and before a ) are insignificant, all spaces before and after a = are insignificant, all spaces after a , are insignificant, and so on.

 

But you see... that's why I think determining which spaces are significant and which aren't would prove to be a lot of work.

Edited February 16, 2012 by Speed

[Speed]

Idea with string.dump(loadstring()) looks good.

 

Thanks! Maybe I'm paranoid for being worried about string.dump not being deterministic; but damn it, the order that table entries are accessed with iterator functions like pairs is non-deterministic. I'm sure string.dump would return a string that could be recompiled into a function that would do the exact same thing as the original, but could it be trusted to do that exact same thing in the exact same way? Lua kinda loses my trust with regards to determinism with its non-deterministic table iterators.

 

I guess that even if the concept would work, and string.dump is deterministic, one would still have to make sure that loadstring() actually succeeded on the client's Lua string. My initial reaction to that thought is that they couldn't even be running the game if one of those Lua files failed to load, but then I remembered a way to dupe the (current) integrity checker into sending the wrong data.

[Joe Kurr]

Thanks! Maybe I'm paranoid for being worried about string.dump not being deterministic; but damn it, the order that table entries are accessed with iterator functions like pairs is non-deterministic. I'm sure string.dump would return a string that could be recompiled into a function that would do the exact same thing as the original, but could it be trusted to do that exact same thing in the exact same way? Lua kinda loses my trust with regards to determinism with its non-deterministic table iterators.

 

I guess that even if the concept would work, and string.dump is deterministic, one would still have to make sure that loadstring() actually succeeded on the client's Lua string. My initial reaction to that thought is that they couldn't even be running the game if one of those Lua files failed to load, but then I remembered a way to dupe the (current) integrity checker into sending the wrong data.

 

if loadstring doesn't succeed, just return false.

In that case you're comparing the orignal (working) script with an edited (non-working) script.

[Speed]

if loadstring doesn't succeed, just return false.

In that case you're comparing the orignal (working) script with an edited (non-working) script.

Of course. My point was you have to guard against loadstring() failing (most likely with just an extra if statement) because string.dump(loadstring(s)) would generate an error if loadstring failed. I didn't do this in the code I posted a few posts back, the approach I used was too simplistic (and error-prone).

Edited February 16, 2012 by Speed

[Moa]

One problem this doesn't solve is that this:

t = { var1, var2, var3, } 

is the same as this:

t={var1,var2,var3} 

 

By normalize I mean all comments removed, all whitespace compressed, and all tokens get exactly one space between them. Then it you can still validate the Lua no matter where your line breaks, spaces, tabs, comments, non-space (in your example) etc occur. Otherwise you are still stuck with the problem were Integrity Checking will fail due to trivial (that is, make no difference to the Lua) changes to the file.

[Speed]

By normalize I mean all comments removed, all whitespace compressed, and all tokens get exactly one space between them. Then it you can still validate the Lua no matter where your line breaks, spaces, tabs, comments, non-space (in your example) etc occur. Otherwise you are still stuck with the problem were Integrity Checking will fail due to trivial (that is, make no difference to the Lua) changes to the file.

 

Ok, you're obviously speaking in terms that are above my knowledge base then. I don't know of any way to easily do this in Lua, other than potentially string.dump(loadstring(s)), which will probably do exactly what you are asking for IF there are no syntax errors. If not with string.dump(loadstring(s)), then how do you suggest it might be done? Are there functions out there in C, C++, or any other programming language that you know of (*cough* Java :)) that are capable of removing comments and space normalizing, or would you write the function yourself? It sounds like this is an operation you've seen done before perhaps outside of a compiler or even had to do yourself.

Edited February 16, 2012 by Speed

[104th_Crunch]

Ok, you're obviously speaking in terms that are above my knowledge base then...

 

You guys both did that to the rest of us about 5 pages ago lol. Very nice of you guys to give your ideas.

[Moa]

@Speed: I don't think LUA has anything in its standard library to do this. I was thinking it could be done fairly easily in C++ using custom code. The nice thing is that the Integrity Check is does not have a per-frame requirement, so can be relatively expensive in computational terms if needed.

 

Doing a simple parse to find the LUA keywords and separators is not that hard - I had to do something similar (although simpler) to convert LUA tables to XML (and thence to objects via JAXB) for my lottu tool.

 

IMHO the benefits of having Integrity Checking work even when whitespace, comments, and formatting is changed would be well worth it.

 

The motivation for this (that is, the current situation) is the fact that Config/Export/Export.lua has a single space on the last line and if that space is removed (accidentally, such as enabling or disabling TacView so you can join various FC2 servers) then you'll fail the Integrity Check.

 

Worse, when you compare the files visually you'll have to notice that the (non-displayed) space has changed. Alternatively, you also can't simply comment out the TacView include line, since changed comments also currently causes an IC fail too.

 

This is why I suggest a normalization of the files to be compared before computing the bit signature (SHA-1, MD5 or whatever) of the file. Having the comparison resistant to changes in formatting or comments would prevent a lot of re-installations, since lots of people find it hard to work out what has changed in their modded installs and simply re-install to pass the Integrity Checks for various servers.

 

This ought to be done if ED is heading toward more modding of aircraft (which their changes to the aircraft description database files [eg. P-51 files in BlackShark 2] seem to allude to).

Edited February 16, 2012 by Moa