Server Help :: View topic - can some1 explain the ^Name ??

Server Help

General Questions - can some1 explain the ^Name ??

Sketter - Sun Jun 13, 2004 2:54 am
Post subject: can some1 explain the ^Name ??

When the biller is offline i noticed that in some zones players get ^ besides their names. And some don't. Why is that and how can it be set up?

Also

How come when the biller is down, some zones tell you about the no data base info, and some don't. Why is that and how can it be set up?

Thank-u!

Sketter

Mr Ekted - Sun Jun 13, 2004 3:51 am
Post subject:

Each zone runs a billing proxy--a program that sits between the biller and the server. It remembers the login info for the last 1024 players who logged in before the biller died. If you are not one of those last 1024, it cannot verify your password, so you get a ^ indicating that your actual name cannot be verified.

Mine GO BOOM - Sun Jun 13, 2004 2:34 pm
Post subject:

It means if someone named ^PriitK enters your zone, he isn't Priit, despite what he says.

CypherJF - Sun Jun 13, 2004 5:06 pm
Post subject:

Or ^JeffP for that matter..

(lol, i did see this one in TW)

Smong - Sun Jun 13, 2004 5:59 pm
Post subject:

How about ^Banned?
I suppose this proxy isn't available for download?

Mr Ekted - Sun Jun 13, 2004 6:18 pm
Post subject:

^Banned shows up when a banned player tries to login. I'm not sure why the protocol was designed this way. Is doesn't need to do this.

SuSE - Sun Jun 13, 2004 6:29 pm
Post subject:

just to make it easier to find the banned person I would s'pose

nintendo64 - Sun Jun 13, 2004 6:40 pm
Post subject:

SuSE wrote:

just to make it easier to find the banned person I would s'pose

^Banned is a way to tell the subgame to automaticly *shutup and *spec users with these nicknames, which were given by the Biller, the biller can change your nickname.

I've not checked but i believe a simple lockout will be better or not? after the Auth process, because i've not worked with billers before, i don't remember the protoccol as well as with Client-Subgame.

-nintendo64

Dustpuppy - Sun Jun 13, 2004 6:58 pm
Post subject:

Mr Ekted wrote:

Each zone runs a billing proxy--a program that sits between the biller and the server. It remembers the login info for the last 1024 players who logged in before the biller died.

I hear Qndre made a hacked billing proxy in asm that steals passwords.
True story.

Mr Ekted - Sun Jun 13, 2004 7:41 pm
Post subject:

That is why you don't trust your passwords to strange zones. Always use different ones for each biller domain. But I doubt Qndre made anything, much less in ASM.

nintendo64 - Sun Jun 13, 2004 9:26 pm
Post subject:

If he did one (probably in Visual Basic), it proves his real motives towards his client idea, he just wanted the "power", to feel he is "important". If that's confirmed then he will be netbanned, and his little tool to randomize machineID and permissionID won't do anything to stop the ban.

-nintendo64

Mine GO BOOM - Sun Jun 13, 2004 9:33 pm
Post subject:

nintendo64 wrote:

^Banned is a way to tell the subgame to automaticly *shutup and *spec users with these nicknames, which were given by the Biller, the biller can change your nickname.

^Banned was done originally because the billing-server protocol didn't have a nice method of saying "don't let this user in because he is banned." Thus, instead of just replying back saying their password was bad or something, Priit thought it would be better to just use the fact that the biller can rename the user (originally design to correct the casing of the name back in VIE days), then send him a message in the game saying they are banned, and send a billing-kick to the user to make him leave.

After a while, people figured out during that time they are entering the zone (because the billing had to wait a bit to make sure they actually got into the game before sending the message/kick), that they could flood ?cheater really bad to annoy the hell out of admins or send massive messages to the public or specific users. Thats when the *shutup too effect. Then some people figured out that they could get into a ship for about 5 seconds or so, and thats when the *spec type lock took effect.

Dustpuppy - Mon Jun 14, 2004 8:12 am
Post subject:

nintendo64 wrote:

If that's confirmed then he will be netbanned

Oh man, I was joking

Mine GO BOOM - Mon Jun 14, 2004 8:35 pm
Post subject:

Split some posts from here into Trash Talk.

Smong - Tue Jun 15, 2004 5:02 am
Post subject:

Actually I was thinking what if someone entered using 'Banned' when the biller was down, would the proxy then rename them to ^Banned? I suppose if it did the player wouldn't be able to speak or fly, but at the same time wouldn't get kicked.

nintendo64 - Tue Jun 15, 2004 1:06 pm
Post subject:

Smong wrote:

Exactly what it'll happen.

-nintendo64

Lumenesc - Tue Jun 15, 2004 1:42 pm
Post subject:

Quote:

It means if someone named ^PriitK enters your zone, he isn't Priit, despite what he says.

What if priitk enters the zone for his very first time ever when the billing was down o_O. Or if someone had been using the sn PriitK before the billin went off and you havent ever had more than 1024 players to log before he signed off so he has no ^.

Plus i thought it was possible to enter on someones name even if their logged on, and even with a different sn. I remember once there was 4 Lumenescs when mk's billin went down :/.

Cyan~Fire - Tue Jun 15, 2004 8:14 pm
Post subject:

Yeah, you can have duplicate names when the biller goes down. AFAIK, the server communicates to users completely through login-assigned IDs.

Mr Ekted - Tue Jun 15, 2004 10:33 pm
Post subject:

ID's are used for message sending in all cases except remote/chat messages across different zones, in which case the biller is involved.

Qndre - Wed Jun 16, 2004 7:28 am
Post subject:

Dustpuppy wrote:

I hear Qndre made a hacked billing proxy in asm that steals passwords.

You shouldn't believe in what you hear because it's not true. I don't want to steal any CONTINUUM accounts or other people's passwords. I didn't even write a billing proxy (??) but a proxy for use between client and subgame2 (on both, client and server side) to make the VIE Subspace more secure (524288-bit encryption with packet-checksums to avoid man-in-the-middle actions client side (aka cheating) as well as account thefts).

So proxy-system works like that:
[Subspace > Client-Hack] > ----- WAN connection (high-encrypted) ----- > [Server-Hack > subgame2]

Subspace (VIE encrypted packets) aren't directly sent to subgame2 server but through a client-side proxy or client-hack (which VIE-decrypts the packets and METAencrypts them).

These packets are sent over a WAN connection (internet) by the client-side hack. They are now high-encrypted and checksummed to avoid man-in-the-middle action by other servers as well as login-thefts or cheating.

These high-encrypted packets arrive on the server-side proxy or server hack (which METAdecrypts them, VIE-encrypts them and passes them on to subgame2).

Neither the server-side hack nor the client-side hack have spyware-like functions like sending the contents of a 00 09 packet to me. I don't know who told you things like this but it's definitally NOT true.

The connection subgame2 <-> oldbill (billing server) isn't being proxied.

_

The only thing that will be "hacked" (or spoofed) by some ASM code will be the sources Subspace uses for generating / reading MachineID and PermissionID. The client-hack itself does NOT modify the content of ANY PACKETS (yet) or spies the connection (so also not the MacID and PermID or any account data). I MAY OR MAY NOT (unsure) add a function to randomize the MacID and PermID before being encrypted by METAenc high-security-encryption and before being checksummed so it's possible to spoof identity (but not accounts) on zones which have the server-side hack installed to unban yourself (and only for THAT reason) without changing the sources where Subspace reads MacID and PermID out. That's the only kind of "hacking" which will be there.

WARNING:
I don't create a password-theft server but it's very easy for an ASM experienced person to do so. So please EVERYONE use another password for Subspace than you use for other things (email, dialup, firewall, ...) because it's really not too difficult to steal accounts in Subspace. The same thing for Forums or other private websites which require registration. Server-side scripts (at example PHP scripts) can be written to store the registration data in a database, ready to be read out by an administrator. My suggestion (like I do it) is: Use a very-secure password for dialup, a secure password for email and trusted websites (companies, etc.) and an insecure passwords for unimportant things like communities, Continuum or any other web service provided by a private person.

Dr Brain - Wed Jun 16, 2004 10:45 am
Post subject:

Qndre wrote:

WARNING:
I don't create a password-theft server but it's very easy for an ASM experienced person to do so.

What does ASM have to do with anything? I know only a small amount AVR ASM, but I could steal SSC passwords without problems, without using ASM. And I imagine that there are numerous others who could accomplish the same feat. While something like this isn't my style, it's a valid security concern.

Mr Ekted - Wed Jun 16, 2004 2:05 pm
Post subject:

Qndre wrote:

a proxy for use between client and subgame2 (on both, client and server side) to make the VIE Subspace more secure (524288-bit encryption with packet-checksums to avoid man-in-the-middle actions client side (aka cheating) as well as account thefts).

Let's get this straight once and for all Qndre. The number of "bits" in an encryption scheme is the number of bits in the KEY which is THE SAME AS THE SEED. 524288 is the number of bits in your KEY STREAM, which is pitifully small.

Stealing passwords in only easy if YOU are the one running the server. If you think otherwise, go ahead and steal my password, and post it here.

Qndre - Wed Jun 16, 2004 2:06 pm
Post subject:

Dr Brain wrote:

[..]

What does ASM have to do with anything? I know only a small amount AVR ASM, but I could steal SSC passwords without problems, without using ASM. And I imagine that there are numerous others who could accomplish the same feat. While something like this isn't my style, it's a valid security concern.

Because you cannot do spoofing like that in a high-level language such as VB but only in low-level programming languages. And since ASM is the lowest level (just above manually typing the opcodes into a COM file) ...

Mr Ekted wrote:

Stealing passwords in only easy if YOU are the one running the server. If you think otherwise, go ahead and steal my password, and post it here.

Of course it is very easy for the one who runs the server, but it's also possible for men in the middle in some cases, for example the proxy server you are using or your provider. It is possible that there are coming people in between who want to get that kind of information (of course not the password for an online-game but if your email was using the same one and your firewall, ...) It's impossible to forecast which way your packets come so it's impossible for someone to get someone specific's packets and servers which are usually used for internet data transfer are only the ones of ISPs but if you are in someone's LAN for example ... in your company, your employer could sniff the packets, if you are at school, your teachers can, if you are at a LAN party, the one who is providing the lan party can sniff, and so on ...
Of course the more important and major part of encryption in this case is keeping the user (the client-side player) from modifying/reading the packets, for example to keep the settings of a server secure or to avoid client-side spoofing (cheating).

Mr Ekted wrote:

Why do you think it's small? CONT also "only" has a 688128-bit keystream (because it doesn't use the whole "scrty1" as a key but only a 86016 byte part of it - depending on the server-provided (random) offset). Of course it's possible to extend keystreams to almost infinite length, but only expanding the keystreams doesn't really make an encryption secure.
_
If you think my keystream generator is weak, you are wrong. It's depending on the S.I.G.M.A. algorithm used in many other encryption shemes to generate the keystream. I modified that algorithm to provide a keystream of a suitable length and to make it hard-to-guess by modifying the seed tables and making one seed variable. The encryption algorithm itself is also strong. It picks the part of the keystream after an offset fully calculated out of the input data and pseudo-random (hashed version of the input / self-written hash algorithm with leftshift and xor (true 16-bit hash)). The offset cannot be spoofed client-side because server is able to check the data hash (so it also provides safety against modifying the data).

Cyan~Fire - Wed Jun 16, 2004 2:25 pm
Post subject:

Ummm someone client-side could not steal the password, at least for Continuum, because they don't know the protocol (encryption). Someone server-side, however, could steal passwords from the server-biller chatter, for which the protocol is known.

Qndre - Wed Jun 16, 2004 2:42 pm
Post subject:

Cyan~Fire wrote:

The encryption (combining data with key) is known, just the keystream generation is unknown. The encryption on the other hand isn't too complicated:
Two DWORDs are being initialized with the old data (feedback) and xorred with 8 bytes of the new data of the packet to be encrypted. Now a part of the key is taken, startpoint is the client-provided (0x0001) offset (while the keystream itself is calculated after a server-given (0x0010) seed). The dwords are being leftshifted x times while x is a value, got from the lowest byte of the dword not being leftshifted (so if dword2 contains a value like "0x12345678", dword1 is being leftshifted 0x78 (120) times and vice versa). Then both dwords are put one after the other so they build an 8-byte value (packets are encrypted in 8-byte blocks) and the next 8-bytes are being taken out of the packet to be encrypted and the keystream offset is being increased (+8).
The decryption is similar. Of course dword2 is leftshifted first because dword1's lowest byte is the number of leftshifts and dword1 is leftshifted after that because dword2's lowest byte isn't known before leftshifting it (so just the opposite direction).

Mr Ekted - Wed Jun 16, 2004 3:04 pm
Post subject:

The aim of encryption is to make the task of brute force attack take virtually forever. In this case, that is directly related to the size of the key. A 32-bit key can create 4 billion possible keystreams. It doesn't matter how long they are, only that they are as long as the data. Double the number of bits in the key, and you square the number of combinations (64 bit key = 16 quintillion combinations).

You really need to stop trying to implement encryption code or pretend you are an expert (ie make false claims because "someone told you something") until you understand it. You've spent well over 6 months now doing nothing but telling everyone who knows more than you that you are smarter than them, and you are still not past the very basics.

Smong - Thu Jun 17, 2004 7:20 am
Post subject:

Dr Brain wrote:

I know only a small amount AVR ASM, but I could steal SSC passwords without problems, without using ASM.

Have you run any tests to prove this? I thought when connecting to SSC the player's password is encrypted/hashed in some way, so server ops cannot see the plaintext password.

Cyan~Fire wrote:

the server-biller chatter, for which the protocol is known

Really? I have not seen any documentation on this protocol, please post some links.

Cyan~Fire - Thu Jun 17, 2004 10:04 am
Post subject:

I don't know where the documentation is... I basically take Catid's SSB2 code as the only docs out there.

Dr Brain - Thu Jun 17, 2004 10:58 am
Post subject:

Smong wrote:

Have you run any tests to prove this? I thought when connecting to SSC the player's password is encrypted/hashed in some way, so server ops cannot see the plaintext password.

No. But getting it back to cleartext isn't the only way to cause fake player havoc on the SSC biller. That I know for a fact. And there is always VIE connection's passwords.

But like I said, I have no desire to do anything of the sort, but the mere fact that it can be done should turn some heads.