Spring RTS Engine

This happened 3 times in a row.

[MARS]Hitze, [MARS]Lagronde and I ([MARS]AlbAtoR) were on teamspeak.
1) The game starts
2) Duiring the lauching of spring.exe, [MARS]Hitze crashes
3) Once I am ingame, I see the mouse spot of Hitze mouving, click on a start pos and ready up.

One of the replay can be founded here : http://replays.adune.nl/?act=download&id=1509

4) In this game, since we were aware of the hack cause we were talking on Team speak, [MARS]Lagronde tried to capture [MARS]Hitze commander.
5) Then lagronde got D-gun by hitze owner'scom

This proof than somone can take control of a player and play at his place. The only reason we were aware of that is because we were on Team Speak

I would like to know :
A) Who do you think can do that (a spec or a player)
B) If there is a way to prevent such a behaviour
C) If it is a know bug



PS : I suspect wombie cause Hitze and him dont like each other. But I am not suprised it happened to Hitze cause he has sometime a bad behaviour. Anyway I cannot prove anything, but I would like to know how to prevent player (or spec ?) to ruin the game because even if you know somone is hacking you cannot do anything : 3 game were screwed cause of that. Everybody was aware of tha hacking and noone could do anything.

Known bug, anyone can do it (doesn't even have to be in the battle) as long as the target player loads slower.

Host could get IPs (and please tell me this sort of shit qualifies for a permanent ban from the server?) and report them to a lobby moderator. But seeing as hosts has to be unbiased (unless it's possible to log battleroom connections by IP) I find it unlikely that this'll get solved that way.

albator wrote:One of the replay can be founded here : http://replays.adune.nl/?act=download&id=1509

Several failed connections attempts for "[MARS]Hitze" are shown.

This proof than somone can take control of a player and play at his place.

It's known, that this is possible.

A) Who do you think can do that (a spec or a player)

Everybody. No need to join the game.

B) If there is a way to prevent such a behaviour

At the moment not really.
In Spring 0.80 the host can read the IPs ingame to see who did that. Also it will be possible that random passwords are automatically send to each client to prevent such actions. But that needs lobby/server support too.

C) If it is a know bug

Missing feature. Spring lacks authentication.

Thanks for your answers. I hope 0.80 will come soon :p

Host being able to see IPs of joins doesn't really matter. If two different IPs connect as the same player, how would you know who is the actual player?

That and autohost owners are mostly afk so someone can still do some serious griefing before they're even noticed.

ZellSF wrote:Host being able to see IPs of joins doesn't really matter. If two different IPs connect as the same player, how would you know who is the actual player?

Ask lobby moderator. They can confirm at least the unmalicious IP.
If they are from different countries you can do it yourself.

That and autohost owners are mostly afk so someone can still do some serious griefing before they're even noticed.

Abandoned autohosts are a different issue.

SirMaverick wrote:

ZellSF wrote:Host being able to see IPs of joins doesn't really matter. If two different IPs connect as the same player, how would you know who is the actual player?

Ask lobby moderator. They can confirm at least the unmalicious IP.
Abandoned autohosts are a different issue.

This wouldn't help at all - I don't think Spring itself can accept only certain players based on IP. Even if the IP address of the hacker was identified there would still be no way to prevent him from connecting without lobby support.

eyu100 wrote:This wouldn't help at all - I don't think Spring itself can accept only certain players based on IP. Even if the IP address of the hacker was identified there would still be no way to prevent him from connecting without lobby support.

Assume he is still interested in unhacked games, moderators can take action if he is logged in.

When he is not logged in, the only one to handle this is the host. I think blocking IPs should be handled at OS level, but could be done in Spring, too.

SirMaverick wrote:

eyu100 wrote:This wouldn't help at all - I don't think Spring itself can accept only certain players based on IP. Even if the IP address of the hacker was identified there would still be no way to prevent him from connecting without lobby support.

Assume he is still interested in unhacked games, moderators can take action if he is logged in.

When he is not logged in, the only one to handle this is the host. I think blocking IPs should be handled at OS level, but could be done in Spring, too.

You can perform the hack without being logged in... And Spring can't do IP bans AFAIK.

eyu100 wrote:And Spring can't do IP bans AFAIK.

Right. I mentioned it as a second (to implement) possibility to OS level network restrictions.

is this the same bug?

http://replays.adune.nl/?1568

TradeMark wrote:is this the same bug?

http://replays.adune.nl/?1568

No dude this would definitely not be the same bug. The bug in this thread is the one where you can edit your script.txt to connect as someone else.

TradeMark wrote:is this the same bug?

No. They are all connected and playing/speccing. It's something else.

so, another questions: is this bug fixed in 0.8?

technically yes, but needs lobby support afaik.

The Ips are saved in autohost log now. Contact autohost admin to give those to an moderator, se he can start banning people.

nope, its not fixed yet, its still possible to take com by specs ^^

Wombat wrote:nope, its not fixed yet, its still possible to take com by specs ^^

Fixed in Spring. Needs lobby support.

If I understood the little info I got, it will need server support first.

It does need lobby support, not just using the rules table? Okay then. I'll commit to putting in the rather simple server support within 24 hours of any lobby being ready for it. If you want it first then you tell me exactly what data to send in what format and you'll get that, too. We need this to get done.