Server Help :: View topic - bug/feature tracker

Server Help

Trash Talk - bug/feature tracker

Smong - Wed Sep 06, 2006 5:40 pm
Post subject: bug/feature tracker

If anyone comes across any bugs in the client/server or wants to submit a feature request they can now do so at: http://tracker.sscentral.com/index.php

If you have any old ideas please add them. It would save me a load of time going through old threads and backup CD's.

Note: This isn't an official tracker.

Doc Flabby - Wed Sep 06, 2006 6:21 pm
Post subject:

are we close to being able to get the client updated???

CypherJF - Wed Sep 06, 2006 9:32 pm
Post subject:

Great initative Smong! About time we got something like this going.

Smong - Thu Sep 07, 2006 3:24 am
Post subject:

@Flabby
The official client, I don't know.

Doc Flabby - Thu Sep 07, 2006 5:26 am
Post subject:

I havnt given up trying to hack the official client. First step im trying to do is work out how the exe is packed and unpack it....I might never work t out but at least its getting me to learn some assembly

Challenges are always fun.

i have managed to attach a debugger to the continuum process without continuum detecting it and exiting (as in i can play the game with a debugger attached, i have only done this in my own zone obviously dont want an SSC ban!) - i donno if that would help with the ball friction thing or whatever lol.

I can pm you how i did this and some long and boring debug traces/disassemblies i dont understand. I should think with these files and the information on how to attach a debugger it would be possible for someone competent at assembly and such like to reverse egineer the continuum encrptytion. if trusted people want (ie people like minegoboom

or similar im not gonna make anything i do "public" i dont want to damange the game, or in otherwords assist in creating another twister....). I just want to try to help the community to contine to develop the game and fix some of the bugs...

Smong - Thu Sep 07, 2006 2:24 pm
Post subject:

How would reversing the encryption let you develop the game?

If you are going to develop the client you should create a new encryption. That way if anything goes wrong we can still fall back to a relatively secure and uncompromised cont38.

BTW ball friction is and has always been in subspace.exe, I found most of the relative routines but got bored halfway through decoding them.

Doc Flabby - Fri Sep 08, 2006 7:59 am
Post subject:

thats a good point.

What we really need then is to start work on SubSpace 2

new server (or modified asss) and client would be needed.

In order to develop and opensorce client ( however the client will not be licenced under GPL but a different licence for a number of reasons), which would be the prefered way,

Why is opensource prefered, Look at continuum. No one can develop it further now prittk has abandoned it.

The new server would need to track greens,the number of items,position and status of each ship. The server willl only send information on ships you can see. The client will send its resolution to the server when you connect. So if you try to cheat and play at a higher res that allowed it wont help as you wont see any of the enermy, as the server wont sent you the information.

To futher protect the client the offical realiease will encrpyted with a public key (this will not be secret). The data/code required to play continuum will be encryped with this key. Connecting to a server which will contain the offical private key will do a key exchange with the client and run special code on the client to ensure the exe has not been modified. this check can of cource be disabled but this section of code i suggest will be closed source. Bascially if you modify the client you wont be able to connect to any of the main servers only dev or your own servers with they key security disabled.

subspace 2 needs a secure design such that cheating is not possible or/and is very easy to detect by the server. The server can be 100% trusted with regards to gameplay(not passwords

but i suggest maybe the players passwords should be encryped with something a lil stronger) TASpring (an open source multiplayer online game) exists in a situation where the server and client both cannot be trusted, yet cheating is very difficult. Its easier to secure continuum so i dont see why it will be a problem. It would however require some heavy modifcation of the server. Basically this would be creating a whole new game.

However backwards compatibiliy is desired in that lvl and lvz should be the same, the work done to extend them. Maps should be downloaded over HTTP to be more efficent.

Dr Brain - Fri Sep 08, 2006 11:26 am
Post subject:

Flabby, there is one glaring problem with your proposal: lag. If the client knows nothing, then it's going to have to ask the server for simple little things like current position and speed (and if it doesn't, then there is room for cheating).

Doc Flabby - Fri Sep 08, 2006 1:28 pm
Post subject:

Dr Brain wrote:

Ah thats not quite what i meant my idea is the server would know where the client SHOULD be.

the client tells the server where it is, if it shoots a bomb, or uses a rep, as it does now. The difference is the server decides if this is a valid action. For example the server knows your ship has 2 repels. you pick up a repel green. You use 3 repels. If you used a forth repel that would be detected as cheating. This would stop CE being used, or hacks of the source code to give infinate items, and upgrades

This would require a complete reworking of how greens work, as they are all client side i have been led to understand.....

So the client still does alot of the work the server just validates the actions.

The main problem i could see is the load on the server not being able to handle it......idk...

Dr Brain - Fri Sep 08, 2006 1:37 pm
Post subject:

And if there is a slight descrepency? If the client has been hacked to allow the player to go through corner tiles? Would the server really be able to tell the difference between a player that lags a little but still went around and a player that's hacking? The answer is not if you care about smoothness on the client.

You don't even have to go as extreme as wall hacking, you just need to have a client that gives itself a 1% or 2% speed boost to have the whole system collapse.

I wasn't even going to bring load up, but yes, it is an issue. A zone like TW would be impossible with your scheme.

I'm not trying to discourage you, I'm just letting you know WHY cont is closed source. These are the reasons, and they aren't trivial made up reasons either.

Smong - Fri Sep 08, 2006 2:07 pm
Post subject:

Are you going to start making this flabby?

Doc Flabby - Fri Sep 08, 2006 3:52 pm
Post subject:

Dr Brain wrote:

The existing continuum could never be open sourced i agree.. im trying to look at why it cant be and what would need to be changed in the server and client in order to make that possible. Developing a new game is pointless untill that issue and the logic of how the new game devloped in an open source way would be secured is addressed.

Cerium - Fri Sep 08, 2006 5:13 pm
Post subject:

Theres already another game thats very similar to SS that IS open source, and they have a number of problems with cheaters who modify the client.

A cheat-proof version of this game would be entirely server-side and laggy as all hell. Every toggle-ability would have to be done server-side, as would damage calculation and position/weapon checks.

Sure, its possible to do all of this; but it means retiring dialup players and requiring very optimized code and a hefty server.

Doc Flabby - Fri Sep 08, 2006 6:42 pm
Post subject:

i disagree it wouldnt all have to be done server side.

Its about striking a balance. I want people with 56k and pentinums still be able to play. The idea is not to prevent cheating, but to make it easy to detect. People will always cheat.

Something that seems to have been lost in what i said ealier is that an optional check would be created that would enable the server to verify the exe was an "offical" realease and not a modified version. This would be similar to how microsoft can digitally sign binaries to indicate they have not been modified and are orignal from microsoft.

The way i would imagain this would work work there would be a secure key exchange bascially this means the server would give the client a random 256bit code which is combined with a hash of the exe and any dll files. the client would then have to encrypt this code using the servers public key. Only the servers private key can decrypt this. It is decrypted by the server and the random 256bit code known to the server is removed. It then compared the hash of the exe and dll to the hash it is expecting. If they are not the same client is not allowed to connect. The important thing would be to keep the servers private key secret. But of course it would be easy to change the servers key if it was comprimised.

Bascailly im talking about having an open source client that has the same if not higher barrier to hacking it that continuum has, but the best difference is that its open source so it can still be modified.

I do think a few more things should be done server side especially greens.

Smong - Fri Sep 08, 2006 7:03 pm
Post subject:

You know I could use a modified client to run the security checks on legitimate binaries.

Without checking my facts:
I think the way windows driver signing works is MS hashes the driver and encrypts the hash with is private key. Then the OS decrypts the hash with the public key and compares it to a hash of the driver it makes itself. Same applies for X509/SSL/Public key certificates.

To bypass public key certificates you just have to find the one if statement in the assembly listing which decides what to do with hash mismatches.

BTW Doc Flabby, you seem new to the forum scene. I suggest reading this thread at SFN, it will probably answer some stuff and you can make a new thread with new questions:
http://forums.sscentral.com/index.php?showtopic=84

CypherJF - Fri Sep 08, 2006 7:42 pm
Post subject:

Can someone confirm/deny that Infantry used a non-linear memory model for storing data to fight off memory hacks? I thought I read it used a quadratic to scramble the locations where the data is stored client-side.

Cerium - Sat Sep 09, 2006 1:40 am
Post subject:

That doesnt do a whole lot once you get a program like cheat-engine. It just means re-searching for the values rather than conveniently saving them. You'd have to do something like scramble the value in memory so you can't use CE or similar to sniff out common values.

Doc Flabby - Sat Sep 09, 2006 6:09 am
Post subject:

Smong wrote:

I've read that thread before

. My idea wouldnt work like that. The subspace server would be comparing the hash of continuum. Continuum would send a hash of its exe files etc to the server. If hash didnt match or if the client is altered to not send the hash its just kicked off the server, not allowed to connect.

Now the hard part is ensuring the hash cant be faked.

But you can digitally sign emails (PGP) and such like to ensure the identity of the sender and the integrety of the message. If the continuum binary was signed as such it could be checked by the server if it was and offical binary or not i imagine....

Dr Brain - Sat Sep 09, 2006 9:58 am
Post subject:

And what's to stop a hacked version from keeping an official copy around to hash?