Server Help

CommieCausey · Posted: Tue May 30, 2006 12:34 am Post subject: SubSpace login: key handshake?

I have read Catid's subspace protocol text but I have a problem getting the key exchange to work. In Catid's paper it says that the Session key should be the Client key * -1 or else the key is not valid? In merv bot it seems to check that, in TW Core I think I couldn't find any check at all for the session key.

Ok I've tried to get the -key to be received and maybe I am screwing up something with the signed/unsigned variable. Here is a proxy I made to look at the packets but even Mervbot doesnt seem to receive a "valid" session key in response. Is the text I read incorrect/out of date?

Dr Brain · Posted: Tue May 30, 2006 1:21 am Post subject:

I have always understood (maybe wrongly) that TWCore is pretty loose about that kind of thing because subgame doesn't care as much about what sysop clients do.
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

Cerium · Posted: Tue May 30, 2006 5:08 am Post subject:

The client isnt a sysop until well after the key exchange...
_________________
There are 7 user(s) ignoring me right now.

CypherJF · Posted: Tue May 30, 2006 10:14 am Post subject:

It's actually ...

newKey = ~givenKey + 1

Just check it out, take the values form the integer/long, in both cases and make sure they match properly.
_________________
Performance is often the art of cheating carefully. - James Gosling

Cyan~Fire · Posted: Tue May 30, 2006 10:48 am Post subject:

Which is, Cyph, the negative. Two's complement?

MERV checks it right here (encryption.cpp):

Code: Show/Hide

Uint32 SS_ENCR::getSessionKey(Uint32 clientKey)
{
return ((~clientKey) + 1); // Two's complement, same as arithmetic minus on unsigned data
}

bool SS_ENCR::validateSessionKey(Uint32 serverKey)
{
return ((serverKey == sentKey) || (serverKey == getSessionKey(sentKey)));
}

_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

CypherJF · Posted: Tue May 30, 2006 11:40 am Post subject:

Oh my bad, I misread the original post, haha.

CommieCausey · Posted: Tue May 30, 2006 2:41 pm Post subject:

I also tried logging in using a C program. I usually get the same result as I mentioned. It is just a little different from the two's complement. Sometimes I receive the session key as the same exact client key I sent (this allows no encryption?). The unreliability adds to my confusion...

Mr Ekted · Movie Geek Gender: Joined: Feb 09 2004 Posts: 1379 Offline

The server doesn't respond to a connection attempt (0001) with a connection reply (0002) directly. It responds with a spoof check. The normal sequence would look like:

C: 00 01 k1 k1 k1 k1 01 00
S: 00 05 rr rr rr rr
C: 00 06 rr rr rr rr tt tt tt tt
S: 00 02 k2 k2 k2 k2 ...
_________________
4,691 irradiated haggis!

CommieCausey · Posted: Tue May 30, 2006 6:17 pm Post subject:

yes I know Mr Ekted thanks though for trying to help me.

I have found the cause of my problem! I made a function to write out the bits of the keys and what I thought the session should have been, and that made it easy to see what was up.

I just remembered Im using unix on a computer with a PowerPC processor that uses Big Endian so memcpy copies the variable in big endian! The Intel server uses little Endian! OMG I SUX.

CC

Mr Ekted · Movie Geek Gender: Joined: Feb 09 2004 Posts: 1379 Offline

The problem is your knowledge of memory and data. The DWORD value 0x12345678 would appear in Intel memory as:

78 56 34 12

The low bit would be the low bit of the first byte:

78<- 56 34 12

The code itself on the client or the server doesn't care about any of this. The packet is defined by a structure. Those 4 bytes are interpretted (read and written) as a single DWORD. The position of the bytes and bits is irrelevant.

If you look at MERV code, you may be led to think that you have to care about byte ordering at this level. This is not true. All the MERV packet handling code is compete and utter crap.

CommieCausey · Posted: Tue May 30, 2006 8:01 pm Post subject:

Sorry Mr. Ekted I had edited my post and removed my long ass moaning about the endianness, I didn't want to spam and had just remembered PowerPC is big endian. I didn't know you were responding.

My problem was caused by me assuming that SubSpace protocol uses Network byte order (Big Endian) like most network protocols. But because SubSpace was only made for Intel/Windows everything seems to use little endian. That makes things harder for me since my PowerPC processor uses big endian and that was the source of the problem because I was sending a key in big endian.

Now I know everything sent in the protocol is assumed to be little endian and that no conversion between endianness is performed by the server.

CC

Mr Ekted · Movie Geek Gender: Joined: Feb 09 2004 Posts: 1379 Offline

So your code now works?

CommieCausey · Posted: Tue May 30, 2006 9:33 pm Post subject:

Yup! I changed the python proxy to unpack the bytes using little endian and the session key comes out negative of the client key no problem. So I am thinking when I read in a raw packet or write a raw packet out I just need to make sure i pack or unpack specifying little endian. I hope!

Sorry to be a bother guys.

Now I'm trying to make my keystream match Mervbot's keystream

CC